concerted-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gaurav Shukla <gshukl...@gmail.com>
Subject Re: Ideas for Growing the Concerted Community
Date Wed, 13 Jan 2016 13:00:23 GMT
How about we start with the website ?
On Jan 13, 2016 6:09 PM, "Atri Sharma" <atri.jiit@gmail.com> wrote:

> Thanks Julian and Chris!
>
> Let us put these points into action. Yay for Concerted community growth.
>
> Regards,
>
> Atri
>
> On Wed, Jan 13, 2016 at 6:49 AM, Julian Hyde <jhyde@apache.org> 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 <cnauroth@hortonworks.com
> >
> > 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
> >
>
>
>
> --
> Regards,
>
> Atri
> *l'apprenant*
>

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