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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general

Reply via email to