geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
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.


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

> +1 for Private PMC voting.
> --
> Richard Monson-Haefel
> On 9/11/03 6:41 PM, in article, "Greg 
> Stein"
> <> wrote:
>> On Wed, Sep 10, 2003 at 06:02:51PM -0000,
>> wrote:
>>> ...
>>> From: "Jeremy Boynes"
>>> <>
>>> Subject: [vote] Process for adding committers
>>> To: <>
>>> Cc: <>
>>> 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

View raw message