geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Monson-Haefel <>
Subject Re: committer process
Date Tue, 16 Sep 2003 04:51:10 GMT
+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