[General] Initial draft of committer policy

[Ted Leung]

On Feb 17, 2006, at 8:02 AM, Mitchell Kapor wrote:

> To have a fully-baked policy, I think we need more definition  
> around the private "vetting" process.  Ted, can you say more about  
> what this is like at Apache?

The "vetting" (perhaps a poor word choice) involves looking at the  
patches that a person has contributed to determine whether they  
demonstrate the necessary level of technical skill and good  
judgement.   There is no fixed number of patches required to  
demonstrate merit, since the size and difficulty of patches can vary  
widely.   A frequent interaction with a new contributor involve  
submission of a patch (usually via e-mail), and then possibly a  
dialogue with one or more existing committers.  The dialogue would  
ensue if the patch needed to be altered in some way before an  
existing committer would feel comfortable committing it (i.e.  
vouching for it).

The other major component of evaluating a potential committer is  
their ability to work within "The Apache Way", which involves making  
proper use of voting, the ability to gauge consensus, and so forth.   
At Apache, we value the ability to work as part of the community at  
the same level as the ability to crank out high quality code, so this  
is weighty criterion, but also involves some amount of squishyness.

>
> Also, I think the nature of the voting needs further explication.   
> "Pro-forma" usually means in this context, for the sake of the  
> form, i.e., something non-substantive.  Is this what you meant?  If  
> not, can you say more about what it takes for a vote to "carry"?

The "real" vote to grant someone commit access takes place on the  
private list, which is only readable by the existing committers.    
Maintaining the meritocracy is very important at Apache, so the  
person must obtain at least 3 +1 votes and no -1 votes in order to be  
voted in.   (We don't have any projects at the ASF with less than 3  
committers).  If this vote is successful, then a public vote will be  
called, but since the only votes which are binding are those of the  
existing committers (who voted in private), this public vote is  
usually just a formality, since those people will vote as  they did  
in public.

The use of the private list is to avoid discussing issues about  
people in the public forum, especially if it is decided that the  
person either will not be granted commit privileges or that they need  
more time to work in the project before being granted commit  
status.   Also, the usual pathway is that an existing committer  
proposes that a contributor be granted access as opposed to the  
contributor making that request.

Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/general/attachments/20060217/7792e0f1/attachment.html