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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
