Hi, I wanted to get a conversation started on this list about how a potential contributor becomes a committer. There has been some discussion on the private@ list about this topic, so let me summarize here first.
When somebody requests to become a committer, we discussed two options: 1- Require them to submit patches, and then over time, as they demonstrate a track record of solid work, we enable commit access to the project (or a specific portion of the project.) 2- Enable commit access for the person, but only to the specific module they are going to make changes. Over time, grant them access to the entire repository based upon solid work. (note: this would be a social contract, not administratively enforced with ACLs.) *I'm going to propose that we adopt approach #2.* Greg's description of this (in detail), is below, because I think it was helpful. I'm going to suggest we use lazy concensus, and that if nobody has any objections, we adopt this approach. But, feedback is welcome and encouraged! Please read this, and ask any questions you might have, or feel free to disagree. Cheers, Sterling Greg's desc: What is the best way to get new people? Empower them. Appreciate their time, accept their work, and give them the ability to contribute. When you do this, they will enjoy working on the project, and contribute more. And drop the barriers! Let their creative energy run free. (reference: my earlier notes about CTR vs RTC) So what we're looking for is a VERY low bar to empower new people. Get them to be committers. Let them contribute as easily and as often as they want. Now, remember: we are using version control. There really isn't anything that anybody can do, to mess up the project's codebase. "Whoops, we made a high school kid a committer, and he didn't understand git right, and deleted the master branch." ... We can fix that. But people arriving at the door aren't *quite* trusted enough to do things as the project/community (and, ultimately, the PMC) would like. A bad commit here or there can be dealt with. But if somebody arrives and commits 50 changes a day, there is no way to keep up. The answer is to *narrow* any possible repercussions. In Subversion, we call this "partial commit". A new committer is allowed to commit to one area/directory. For example, we could give Tim Tempo commit to the *docs*, but ask him not to commit to the actual code. We don't have to wildly track changes all over the code base ... he'll only touch the docs. Of course: we'll want to carefully review those! But that review process will also provide insight into Tim's' abilities, habits, communication, etc. So now [Tim] is a committer. And he's working away on the docs, then he finds a problem in some header commentary/docstrings. He crafts up a fix, and asks "can I commit this?" Somebody on the PMC says +1, and he commits it. Remember: we only *asked* him to stick to the docs. He still has rights elsewhere, and with this setup, he can do the commit legwork. Somebody just needs to give him the +1. After a while, we see he's making some great commits all over the codebase. Great! That was our goal. Give the room to succeed, watch it, and then respond to it. At that point, tell Tim "feel free to commit anywhere. No need for a +1 first, we trust you." And here is the second step: in Subversion, we associate this right to "commit anywhere" with PMC membership. If you can touch *anywhere* in the codebase, then why aren't you part of the PMC governance over that entire codebase? You've demonstrated you're doing great work, understand the direction of the whole codebase, and your work is part of releases. So in Subversion land, what we call "full committer" [as opposed to "partial committer"] is also a PMC member. The existing PMC votes on whether to move [Tim] from partial commit to full commit / PMC, and if that passes we go through the mechanics (notify Board, adjust perms/records, send invite, etc). Okay. That is a description of the *roles* we use in Apache Subversion. A way to quickly get people in, contributing, and their path to PMC membership. One more item about this: we allow *any* PMC member to permit a partial committer unilaterally. Just one person to say "hey! let them commit to some/path/over/there", and that's enough. Obviously, a heads up and maybe a query is good. Also note this isn't always in the master branch. A lot of times, we provide commit access to a *branch*. Why not? It's a freakin' branch! They aren't gonna hurt the codebase. For partial committers, the concept is they can do no real/actual harm to the codebase, so if you trust your PMC peers, then let them make a judgement call. "She looks good. Let's give her a branch to create that new tool." "He's great! Let's let him fix up the USB subsystem."
