incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: Flume Graduation (was Re: June reports in two weeks)
Date Thu, 24 May 2012 06:14:10 GMT

On May 23, 2012, at 10:48 PM, Patrick Hunt wrote:

> On Wed, May 23, 2012 at 10:36 PM, Ralph Goers
> <> wrote:
>> On May 23, 2012, at 10:15 PM, Benson Margulies wrote:
>>> On Wed, May 23, 2012 at 10:09 PM, Ralph Goers
>>> <> wrote:
>>>> 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.
>>> I don't follow flume, but I'd propose to soften your objection only
>>> slightly. I've met other groups of people who like a JIRA centric view
>>> of the world. I suspect that if they did a bunch of other good things
>>> called out below, you or others would find the JIRA business
>>> digestible. Also, on the other hand, I fear that the co-employed
>>> contributors are collaborating in the hallway, and the lack of the
>>> context in JIRA or on the list is contributing to the problem.
>> I have reason to doubt the collaboration in the hallway aspect and I certainly do
not doubt everyone's good intent.  I'm not objecting to the collaboration style as an issue
preventing graduation. I'm just saying I find it difficult to participate with that style
and that simply makes me wonder if that is making it harder to attract new committers.  I
fully realize that that issue might just be with me, but the fact remains that there is practically
no diversity in the project and I cannot in good conscience recommend graduation for a project
in that situation.
> Hi Ralph, Benson, et. al., some background:
> Flume is similar to Hadoop and other related projects in that it is
> very jira heavy for development activity. No slouch in terms of
> mailing list traffic either though (1200 last month):
> Also note the extensive "new developer" type detail that's available
> on the web/wiki:
> The team list can provide insight into the diversity issue
> My understanding is
> that there are at least 4 separate organizations represented by active
> commiters.

The team list is incorrect and is somewhat misleading.  To my knowledge at least two "separate
organizations" represented in that list are now employed by Cloudera.  Others signed on when
the project entered the incubator but have never participated.  This all became clear to me
during the last release vote when, as I recall, I cast the only binding vote that didn't come
from a Cloudera employee.


> Regards,
> Patrick
>>>> 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 <>
>>>>>> 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
>>>>> gems, one from a while back, the other recent:
>>>>>    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
>>>>>    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
>>>>>    positive feedback to newcomers, etc., are all too common. Fixing even
>>>>>    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
>>>>>    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
>>>>>    That's what we could and IMHO should be sharing with the podlings.
>>>>>    what "mentoring" to me is about and that's where our most precious
>>>>>    value" is. Otherwise incubation just boils down to an indoctrination
>>>>>    period on how to apply and conform to the various Apache rules and
>>>>>    policies.
>>>>>    I've been involved with quite a few podlings with similar problems
>>>>>    attracting longer-term contributors. In my experience the best way
>>>>>    solve that problem is to change your mindset of expecting most such
>>>>>    to be just one-off contributors. If you instead treat them as your
>>>>>    new committers and engage with them as peers, many (though of course
>>>>>    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.
>>>>>    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
>>>>> community" documentation somewhere, rather than scattered through the
>>>>> archives.  I suggest "Steps" as a format because different approaches
>>>>> required at different phases of the project and sizes of the community.
>>>>> Marvin Humphrey
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> For additional commands, e-mail:
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message