[General] Initial draft of committer policy

[Alec Flett]

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?
>
I'll answer this too by explaining what it is like at Mozilla, because 
we have a couple "levels" of access. The full process is described here: 
http://www.mozilla.org/hacking/getting-cvs-write-access.html but I can 
offer some more of how it works from both sides because I've spent time 
helping make the decision on whether a contributor gets access or not.

The basic idea is that bugzilla is used to have a paper trail of almost 
everything, and its done through a process of specific, recording 
instances of a few people vouching for another.

First, folks get started by attaching patches to bugs (optionally filing 
those bugs to begin with) - they get reviewed using the bugzilla patch 
system. Since all commits must originate as a patch in bugzilla and be 
marked as reviewed by a committer, this mechanism provides a queryable 
paper trail of the contributor's history within the bug system.

Over time the contributor wants commit access - they have to have 
submitted around  5 "significant" patches - more than just one liners or 
code cleanup. This number isn't set in stone, and it is less formal than 
that. In fact some folks actually end up getting commit access because 
all they do is cleanup code.. but they clearly demonstrate good judgment 
as to when that is really important or not.

To start the process, the contributor actually files a bug against 
product "mozilla.org", component "CVS Account Access" The default 
assignee is the person who will actually create the account - i.e. the 
IT guy/gal. In the bug, the contributor CC's some of the developers they 
have worked with, who they assume will vouch for them.They then also 
list the bugs that they have contributed to as evidence of their work. 
The advantage of having a bug is that it is easy to do a query against 
open "CVS Account Access" bugs to see the queue of users awaiting approval.

https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=mozilla.org&component=CVS+Account+Request&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=DUPLICATE&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

General public discussion happens within the bug - the more positive 
stuff goes there. There will be occassional stuff like "The guy seems 
good, but I'd like to hold off and see more from him before we give him 
access." This all takes place within the bug and the contributor sees 
it. potential vouchers may CC other potential vouchers, i.e. "Lets see 
what Darin thinks - Darin can you take a look at his patches in this 
other bug?"

For serious problems with contributor, the private mailing list for 
"Super Reviewers" is used. (these are sort of the general architects of 
the product, though the role of this particular group has gone down as 
the product's development has gotten more decentralized.)
Long ago in the Netscape days we actually had a super-reviewers summit 
every week or two where we'd review the individuals requesting access, 
and also discuss other people issues. For instance, we had a committer 
who started a small side project within his module which ballooned into 
something we didn't want in the main project - we had to discuss how to 
get him to move it to become an extension.

Ultimately, the decision to grant account access is given by a series of 
"r=" in the original CVS Account Access bug, by a super-reviewer, when 
they have reviewed patches. The r= comes from the bug review process and 
means "I reviewed this" i.e. if I were to vouch for a contributor, I'd 
put "He sounds good to me. r=alecf" in the bug. The general rule (last I 
checked) is that you needed three r='s from super reviewers.

The "r=" string itself is important because its considered a true stamp 
of approval and there is no ambiguity about whether or not someone is 
actually vouching. i.e. I might be in a rush and say "His code looks 
good to me" - but am I vouching for him or not? it's not clear from just 
that. When I put "r=alecf" then it is clear as day that I'm vouching and 
again we have a paper trail.

Anyway, once that happens and the paperwork is filed, the bug is marked 
FIXED by the guy who created the account. Mozilla does have a 
review-before-commit policy, so there isn't any real danger of someone 
accidentally thwarting the system once they have commit access unless 
the person is really malicious, but that's another story...

Hope that helps.

Alec

> 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"?
>
>>
>> After the new committer has been voted in, they must sign a 
>> Contributor License Agreement (CLA).  Once this document is on file, 
>> the IT Staff at OSAF will create the necessary accounts, etc.
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "General" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/general
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "General" mailing list
> http://lists.osafoundation.org/mailman/listinfo/general