concerted-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
Subject Re: Ideas for Growing the Concerted Community
Date Wed, 13 Jan 2016 01:19:48 GMT
Thank you Chris; this is great. I'll add a couple:

7. Demonstrate public activity! For the purposes of building
community, private activity might as well not be happening. The best
place to demonstrate activity is on the mailing list. Start
discussions, send messages describing how your work on the code is
going (even if the work is in private). Think aloud, even if your
thoughts are not answered.

8. Twitter is another place to demonstrate activity. You'll probably
want to create an ApacheConcerted twitter handle, and use it to engage
with your community, announcing everything that's the slightest bit
newsworthy. People tend to forward tweets, and that gives you a lot of
reach in finding a community.


On Tue, Jan 12, 2016 at 2:21 PM, Chris Nauroth <> wrote:
> 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
> 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

View raw message