concerted-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Atri Sharma <>
Subject Re: Ideas for Growing the Concerted Community
Date Wed, 13 Jan 2016 12:39:24 GMT
Thanks Julian and Chris!

Let us put these points into action. Yay for Concerted community growth.



On Wed, Jan 13, 2016 at 6:49 AM, Julian Hyde <> wrote:

> 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.
> Julian
> 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 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



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