concerted-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nauroth <cnaur...@hortonworks.com>
Subject Ideas for Growing the Concerted Community
Date Tue, 12 Jan 2016 22:21:50 GMT
After the recent incubator-general@ thread about lack of Concerted project activity, I decided
to take stock of everything in the project right now.  I tried to approach this from the perspective
of an eager volunteer who wants to contribute to a new project.  I'd like to offer a few suggestions.
 I'm hopeful that implementing some of these ideas would attract contributors and boost momentum
in the project.

Community building might be the most critical aspect right now, because a larger community
would spread the effort and prevent bottlenecks when individuals in the community become too
busy to participate for some time.  (That's completely understandable and natural BTW.  Even
major contributors on the biggest projects have quiet periods when work or other life responsibilities
take them away from Apache.)

1. Focus work on the website.  It's still an empty placeholder right now.  This is the first
place those eager volunteers will go to see if this is the project where they want to participate.
 It also helps keep existing contributors focused on a shared vision.  This is marketing work
to some degree, which isn't fun for engineers, but it's important.  :-)  From a quick scan
of the CONCERTED-1 pull request, it looks like there is a great start in progress.

2. Adding some kind of user guide would help make the project more concrete too.  I find that
my initial read of a project's high-level architecture, examples and API docs are important
for stirring my own excitement.  If that initial contact goes well, then it might inspire
me to use the project or even contribute to it.  If Concerted is a do-it-yourself kit for
building custom in-memory data stores, then one approach would be to show a working end-to-end
example of a very simple application built on Concerted.  Maybe the codebase isn't ready for
that yet, but think about moving towards something like that.

3. I see you have started a project roadmap, which is great.  If you can expand on that and
describe specific features the community plans to implement, then that would help contributors
understand if they can help.  I know documentation isn't the most enjoyable part of software
engineering, but I've found that it's very important in open source development, where you
won't have the benefit of daily face-to-face contact with all of your teammates.

4. There had been mention in the past of prep work involving merging back private forks and
refactoring.  From what I can tell now, this either has not happened yet, or the effort is
happening privately.  If it's happening privately, then is there any chance of moving that
work publicly into Apache?  For example, if someone added an alternative data structure in
a private fork, then you could track the merge effort in an Apache Concerted JIRA that describes
the proposed data structure.

5. The lack of comments in the code may be a barrier for some people approaching and understanding
the project.  Consider doing a pass over the current codebase just adding API documentation.

6. For any work done, remember to track the effort in an Apache JIRA.  Having a backlog of
open, unassigned JIRA issues is a signal to contributors that there is an opportunity for
them to help.  It gives them a chance to pick up an issue, start working and explore how the
project and its community operate.  Newbie issues, which are very small in scope, are important
as an entry point for new contributors.

--Chris Nauroth

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message