On Thursday, May 21, 2009 4:54:28 PM UTC-8, Mitchell Baker wrote: > I'll get to the punchline first, and then go through the rationale. I > believe the "not your employer" rule is harming us more than it's > helping us now. I also think the principles governing commit access > can be protected without this particular rule. I've put the rationale > below. > > As a result I'm proposing we retract the "one person must not be > employed by the same person as the candidate" rule for all candidates > for commit access. > > That leaves us with the following requirements: > > -- two vouchers (module owners or peers) working in modules in which > the candidate is working; and > -- one super-reviewer from a different module > > Looking for feedback. > > +++ > > > Detailed Rationale for Removing the "Not Your Employer" requirement > (long-ish) > > Here are the principles I think we are trying to implement: > > Principles: > > -- Commit access is earned by each individual based on his or her own work. > -- Employment status -- with any organization -- is irrelevant to commit > access. > -- Commit access is awarded by a decision of respected peers, based on > experience with an individual. > -- Commit access is awarded when an individual has demonstrated (a) > understanding and respect for operational rules (testing, checking in, > watching for problems, resolving problems with check-ins, etc) and (b) > acceptable quality code.* > > > *(Mike Connor has suggested that (b) -- acceptable quality code -- is > less important than it once was. In some sense this is true. In the > early days of Mozilla we had to fight long and hard to improve the > quality of code in our tree to something we were proud of. (Anyone who > remembers Netscape 6 will understand why improving the overall code > quality was so fundamental.) Commit access was one line of defense > here, where we knowingly slowed down granting of access in order to get > a handle on who was making our code better and how they were doing so. ) > > > Current Policy > > Many years ago we codified these principles into a process for obtaining > CVS access. We identified the "respected peers" that must support a > request for commit access as: > > -- two module owners or peers from modules in which the candidate has > been submitting patches (the two "vouchers"). These are the people who > presumably know the candidate best. They have been reviewing the > candidates patches. They may well be checking in the candidates patches > and have experience with how the candidate participates in the checkin > and follow up activities. > > --one super-reviewer from outside the modules in which you have been > working. The goal here was to make sure we didn't have unintentional > "group-think" or that a couple of module owners/peers being overly > optimistic as a result of being friendly with the candidate. > > --We also said that one of the three must NOT have the same employer as > the candidate. This aspect had a few goals. One was to explicitly > break the link in the minds of many organizations that employment = > source access. This may seem obvious now, but in the early days of > Mozilla it was a very, very contentious issue. Many organizations > simply could not understand how they could hire someone to work on > Mozilla and then not be able to provide source code commit access. A > second goal was to protect people with commit access from being > pressured by their employers. (Did I mention how contentious this issue > was?) A third reason was because the code review process was also > contentious and under great strain. Sometime poor code would be > approved by reviewers because they had already spent a lot of effort > reviewing, the code was still poor quality, the author of the code was > employed by someone to work on mozilla and so would continue to produce > poor quality code forever, and the reviewer would finally decide s/he > couldn't improve the code through the review process. It's harder to > understand this today but it was a live issue in 1999. A final aspect > was a concern that similarities of an employment setting would cause > "group-think" to outweigh independent technical judgment. > > Today > > I think most of the reasons for the "not your employer" rule are far > less valid today than when we adopted the current policy. The reality > that our invaluable source code asset is best protected by independent > technical judgment is ingrained in a way that simply was not true a > decade ago. > > One remaining potential value that I see is possibly protecting against > group-think. One never know what a different perspective will bring to > the discussion. Employees may share some things in common simply by > being employees. So the "not your employer" rule theoretically brings > some different perspective to the evaluation of whether a person is > ready for commit access. > > Against this we need to weigh the very real harm we're causing ourselves > today, where the "not your employer" rule prevents respected hackers > from getting commit access because there aren't enough module owners/ > peers not employed by Mozilla to review their code and make this > evaluation. > > This harms the project in a number of ways. > > -- Quantities of high quality code from known and respected peers must > be processed (checked in) by others. > -- The burden on module owners / peers who are not employed by Mozilla > to do the level of review required for commit access is high > -- The backlog of code that someone has to check-in means that new > contributors are in a much longer line to have their code checked in, > and face a lot of competition > > > We could approach this problem by consciously NOT hiring module owners. > I think this is a bad approach. It penalizes people for earning and > accepting the responsibilities of module ownership. Becoming a module > owner then makes someone ineligible to work for Mozilla. This seems > fundamentally backwards to me. And it creates pressure to make module > owners due to their (non) employment status, whether or not the module > makes sense on its own or we have an owner with the technical background > we want. To me, the bad incentives here are worse that relying on the > vouchers and super-reviewers to make independent judgments. We do need > to explore the development of new areas, new modules and new module > owners. But we should explore this for its own sake, not because we > have a rule about commit access. > > For the determination of readiness for commit access we can rely on the > core understanding that source code access must *always* be earned and > that one's own reputation will suffer for poor decisions about commit > access. If we find some individuals don't make good decisions without > the "not your employer" rule in place then we can either deal with those > individuals or reinstate the rule or find another, more targeted way of > addressing this.
_______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
