Right after I read Jukka's email that started this thread and I posted my reply 
and discovered to my shock that they had started a graduation vote.  I am 
shocked because I have pointed out repeatedly the project's complete lack of 
diversity.  Virtually all the active PMC members and committers work for the 
same employer.  I have told them several times that I would actually like to 
participate in the project but the way the project works is very different then 
every other project I am involved with at the ASF and the barriers to figure 
out what is actually going on is very high. Almost nothing is discussed 
directly on the dev list - it is all done through Jira issues or the Review 
tool.  While all the Jira issue updates and reviews are sent to the dev list 
most of that is just noise.  Feel free to review the dev list archives to see 
what I am talking about.

Needless to say, when the graduation proposal reaches this list, and I'm sure 
it will, I will strongly endorse the IPMC to reject the proposal.

FWIW, I found the post below to be 100% on target.

Ralph



On May 23, 2012, at 7:31 PM, Marvin Humphrey wrote:

> On Wed, May 23, 2012 at 5:36 PM, Patrick Hunt <ph...@apache.org> wrote:
>> Perhaps someone will have some insight on how to gather new
>> contributors that hasn't been tried yet?
> 
> Jukka's written on this subject multiple times in the past.  Here are two
> gems, one from a while back, the other recent:
> 
>    http://markmail.org/message/o3gbgam4ny2upqte
> 
>    Most of the cases I've been involved so far of podlings in the "hoping
>    some more people come along" have had symptoms of the project team not
>    paying enough attention on making it easy for new contributors to show up
>    and stick around. Things like complex and undocumented build steps,
>    missing "Getting started" or "Getting involved" guides, lack of quick and
>    positive feedback to newcomers, etc., are all too common. Fixing even just
>    some of such things will dramatically increase the odds of new people
>    showing up.
> 
>    Those are things that are very easy to overlook when you're working on
>    your first open source projects (it took me years to learn those lessons),
>    but we here have a massive amount of collective experience on such things.
>    That's what we could and IMHO should be sharing with the podlings. That's
>    what "mentoring" to me is about and that's where our most precious "added
>    value" is. Otherwise incubation just boils down to an indoctrination
>    period on how to apply and conform to the various Apache rules and
>    policies.
> 
>    http://incubator.markmail.org/thread/qpzg6wdoq7cwko55
> 
>    I've been involved with quite a few podlings with similar problems in
>    attracting longer-term contributors. In my experience the best way to
>    solve that problem is to change your mindset of expecting most such people
>    to be just one-off contributors. If you instead treat them as your next
>    new committers and engage with them as peers, many (though of course not
>    all) will respond in kind and actually become more involved.
> 
>    Many developers, especially from commercial backgrounds, tend to treat
>    such contributors as just users reporting a problem. A typical interaction
>    goes like "What's the problem? Do you have a test case? OK, let me fix it
>    (when I get around to it)." A better approach is something like "What's
>    the problem? OK, here are some pointers to the relevant bits in code. How
>    do you think this should be fixed?"
> 
> Here's another tip I picked up from Joe Schaefer: when you're voting in a new
> committer and they have a big patch set sitting in the queue, hold off and let
> *them* commit it so that they get the satisfaction, the new experience, and 
> the
> appreciation all at once.
> 
> It would be nice if stuff like this was collected in "Steps to building a
> community" documentation somewhere, rather than scattered through the email
> archives.  I suggest "Steps" as a format because different approaches are
> required at different phases of the project and sizes of the community.
> 
> Marvin Humphrey
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to