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 14:46:55 GMT
I haven't signed the icla yet. Moreover I am traveling right now.
On Jan 13, 2016 6:33 PM, "Atri Sharma" <atri.jiit@gmail.com> wrote:

> Why don't you go ahead and commit it?
>
>
> On Wed, Jan 13, 2016 at 6:30 PM, Gaurav Shukla <gshukla66@gmail.com>
> wrote:
>
> > 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*
> > >
> >
>
>
>
> --
> Regards,
>
> Atri
> *l'apprenant*
>

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