Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of ralph.goers@dslextreme.com
 designates 209.85.210.47 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: Flume Graduation (was Re: June reports in two weeks)
From: Ralph Goers <ralph.goers@dslextreme.com>
In-Reply-To: 
 <CANLc_9JYntnV1g6nFe8+BmD0HtdKRkp9rLOy9+6KVOis9rRW3w@mail.gmail.com>
Date: Wed, 23 May 2012 23:14:10 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D4D8287E-00AD-4856-A45C-76760CB54AF0@dslextreme.com>
References: 
 <CAOFYJNZY=Q3tf2aW+ch4yLNkYWvvSHjJGf2WASpFS8mFjHPfnA@mail.gmail.com>
 <CANLc_9+fn-cKFguawTQsuXY1jKrc-BHNTwHcN0o+hLQ-pMU7=w@mail.gmail.com>
 <CAAS6=7hf9Poep36Rm1fzJpp679bxH2xz2atK6=G26L+K1xEfkg@mail.gmail.com>
 <E62C4F80-5714-478C-B0BB-AE8338150EEB@dslextreme.com>
 <CALhtWkcmcbJejPHRQ=v3oTNrsA2CabnHLXDc9yNOwvHpGcscqw@mail.gmail.com>
 <13513D2B-1E4F-49C3-8CC6-82E69A2F821C@dslextreme.com>
 <CANLc_9JYntnV1g6nFe8+BmD0HtdKRkp9rLOy9+6KVOis9rRW3w@mail.gmail.com>
To: general@incubator.apache.org


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

> On Wed, May 23, 2012 at 10:36 PM, Ralph Goers
> <ralph.goers@dslextreme.com> wrote:
>>=20
>> On May 23, 2012, at 10:15 PM, Benson Margulies wrote:
>>=20
>>> On Wed, May 23, 2012 at 10:09 PM, Ralph Goers
>>> <ralph.goers@dslextreme.com> 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.
>>>=20
>>> 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.
>>=20
>> 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.
>>=20
>=20
> Hi Ralph, Benson, et. al., some background:
>=20
> 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):
> http://flume.markmail.org/
>=20
> Also note the extensive "new developer" type detail that's available
> on the web/wiki:
> https://cwiki.apache.org/confluence/display/FLUME/Index
>=20
> The team list can provide insight into the diversity issue
> http://incubator.apache.org/flume/team-list.html My understanding is
> that there are at least 4 separate organizations represented by active
> commiters.
>=20

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.

Ralph


> Regards,
>=20
> Patrick
>=20
>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>> FWIW, I found the post below to be 100% on target.
>>>>=20
>>>> Ralph
>>>>=20
>>>>=20
>>>>=20
>>>> On May 23, 2012, at 7:31 PM, Marvin Humphrey wrote:
>>>>=20
>>>>> On Wed, May 23, 2012 at 5:36 PM, Patrick Hunt <phunt@apache.org> =
wrote:
>>>>>> Perhaps someone will have some insight on how to gather new
>>>>>> contributors that hasn't been tried yet?
>>>>>=20
>>>>> Jukka's written on this subject multiple times in the past.  Here =
are two
>>>>> gems, one from a while back, the other recent:
>>>>>=20
>>>>>    http://markmail.org/message/o3gbgam4ny2upqte
>>>>>=20
>>>>>    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.
>>>>>=20
>>>>>    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.
>>>>>=20
>>>>>    http://incubator.markmail.org/thread/qpzg6wdoq7cwko55
>>>>>=20
>>>>>    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.
>>>>>=20
>>>>>    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?"
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Marvin Humphrey
>>>>>=20
>>>>> =
---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>=20
>>>>=20
>>>>=20
>>>> =
---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>=20
>>>=20
>>> =
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>=20
>>=20
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>=20


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