Thanks, Sterling. And thanks to Greg for the thoughts captured below. As the person who provoked the discussion, I’m fine with #2 below.
best, James On Dec 14, 2015, at 9:55, Sterling Hughes <[email protected]> wrote: > 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."
