geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@coredevelopers.net>
Subject Re: committer process
Date Tue, 16 Sep 2003 06:14:16 GMT
If geronimo had its own PMC then things would be very different, but 
since it does not private PMC voting does not make any sense at all.

--jason


On Tuesday, September 16, 2003, at 11:51  AM, Richard Monson-Haefel 
wrote:

> +1 for Private PMC voting.
>
> --
> Richard Monson-Haefel
>
>
> On 9/11/03 6:41 PM, in article 20030911164110.A27012@lyra.org, "Greg 
> Stein"
> <gstein@apache.org> wrote:
>
>> On Wed, Sep 10, 2003 at 06:02:51PM -0000,
>> geronimo-dev-digest-help@incubator.apache.org
>> wrote:
>>> ...
>>> From: "Jeremy Boynes"
>>> <jeremy@coredevelopers.net>
>>> Subject: [vote] Process for adding committers
>>> To: <geronimo-dev@incubator.apache.org>
>>> Cc: <dims@yahoo.com>
>>> Date: Wed, 10 Sep 2003 10:21:21 -0700
>>>
>>> With two options on the table, I think we need to put this to bed 
>>> quickly so
>>> I am calling for a vote between the two following options:
>>>
>>> Option #1 from Davanum Srinivas:
>>> ...
>>> Option #2 from Ryan Ackley:
>>> ...
>>
>> I believe both of these are incorrect forms for voting in new 
>> committers.
>> My original statement was:
>>
>>> I would recommend coming up with, say, a list of four people and 
>>> submit
>>> that list to pmc@incubator for consideration.
>>> How about by end of week?
>>
>> The implied part here is that you're sending a list to the PMC. The 
>> PMC
>> then decides *in private* on whether to add the new committers, and 
>> whom.
>>
>> Currently, there are two general forms of adding committers at the 
>> ASF. I
>> believe one works, and the other fails.
>>
>> 1) httpd/apr style: somebody on the PMC sends a nomination to the PMC 
>> list
>>  and the PMC votes privately.
>>
>> 2) jakarta style: a committer sends a nomination/vote to the public 
>> dev
>>  list and the other committers vote publicly.
>>
>> There are two primary differences (and problems) here:
>> a) public vs private voting
>> b) committers vs PMC members
>>
>> With regard to (a), the biggest issue is that you will *very* rarely 
>> see
>> any -1 votes. People just don't want to do that in public. Especially 
>> in a
>> healthy and cooperative community. It is very hard for somebody to 
>> say,
>> "yes, they're good, but they just don't "get it" very well." What'll
>> happen is that they'll simply abstain. Or maybe vote, but without 
>> comment.
>> And dropping the comments means that other people don't get a chance 
>> to
>> consider those words and how they feel about them, and whether they 
>> may
>> resonate with those thoughts and want to change their own vote.
>>
>> Public votes about *people* just don't work. That needs to be done
>> privately for it to be successful. This is exactly why most countries 
>> have
>> secret ballots: to avoid repercussions against how people vote.
>>
>> With regard to (b), the set of committers does not always match the 
>> set of
>> people who are *responsible*. The Jakarta project is pretty bad about
>> this: the set of committers is way larger than those responsible (the
>> PMC). Within the Incubator, the separation is actually quite 
>> prevalent:
>> the committers are generally not on the PMC, yet the PMC is the group 
>> that
>> is responsible for this project. By moving the vote explicitly onto 
>> the
>> PMC's private mailing list, you are putting the vote in front of the
>> people who are ultimately responsible.
>>
>> In my experience, I have seen *many* private votes raise concerns 
>> which
>> are very valid. The usual result from these "edge" cases is that the 
>> group
>> simply decides to wait for a while and see where things go (with some
>> coaching for the person to help them remedy the concern). But I have 
>> never
>> seen a public vote raise the same kinds of concerns and the resulting
>> discussion. Mostly out of consideration for the feelings of the 
>> nominee,
>> but also so that the "contrary" position-holder is not embarrassed to 
>> post
>> their concerns. Net result: I see the private form succeed, and the 
>> public
>> one fail.
>>
>> Consider the situation where somebody who gets voted in as a 
>> committer via
>> the public mechanism. Since there isn't any real strong way to vote
>> *against* a person, then they will usually end up as a committer. 
>> Almost
>> by default. All you need is a *single* person to put a nomination out
>> there, and "ta-da!" you're in. Now what happens when you discover 
>> that it
>> really was a mistake. That you didn't have an opportunity to discuss 
>> the
>> problems with that committer. Now you have the unfortunate task of
>> figuring out how to fix that committer, or to remove their access. And
>> trust me: you *REALLY* don't want to go down that path. It is so
>> incredibly painful, that you want to have a very high confidence that 
>> when
>> you make somebody a committer, that they will make for a great 
>> committer.
>> While the "six month rule" doesn't truly exist, it is a very good
>> benchmark for being able to see how somebody interacts with the 
>> community
>> over a long period of time, to see whether they are dedicated, and to
>> get a good look at the quality of their code.
>>
>> The process of voting in new committers is a choice of the PMC. In 
>> this
>> case, that is the Incubator PMC. *However*, the intent is that the
>> Geronimo project will receive its own PMC which means that it will be 
>> able
>> to define whatever process it would like. Thus, I think the Incubator 
>> PMC
>> will defer to the community to choose the process that it would liek 
>> to
>> use. They will certainly help the community to choose a process that 
>> fits
>> in with the meritocratic principles of the ASF, and to show some of 
>> the
>> forms in use at the ASF.
>>
>> I would request that the community also considers and votes on my 
>> proposal
>> to use a private voting system. The mechanics of that would be a 
>> private
>> email to the PMC to nominate somebody for commit access.
>>
>> Thanks,
>> -g
>
>


Mime
View raw message