On 02/14/2013 03:19 PM, Sumana Harihareswara wrote: > On 06/15/2012 04:53 PM, Rob Lanphier wrote: >> On Fri, Jun 15, 2012 at 8:48 AM, Sumana Harihareswara >> <[email protected]> wrote: >>> If you merge into mediawiki/core.git, your change is considered safe for >>> inclusion in a wmf branch. The wmf branch is just branched out of >>> master and then deployed. We don't review it again. Because we're >>> deploying more frequently to WMF sites, the code review for merging into >>> MediaWiki's core.git needs to be more like deployment/shell-level >>> review, and so we gave merge access to people who already had deployment >>> access. We have since added some more people. The current list: >>> https://gerrit.wikimedia.org/r/#/admin/groups/11,members >> >> Let me elaborate on this. As unclear as our process is for giving >> access, it's even less clear what our policy is for taking it away. >> If we can settle on a policy for taking access away/suspending access, >> it'll make it much easier to loosen up about giving access. >> >> Here's the situation we want to avoid: we give access to someone who >> probably shouldn't have it. They continually introduce deployment >> blockers into the code, making us need to slow down our frequent >> deployment process. Two hour deploy windows become six hour deploy >> windows as we need time to fix up breakage introduced during the >> window. Even with the group we have, there are times where things >> that really shouldn't slip through do. It's manageable now, but >> adding more people is going to multiply this problem as we get back >> into a situation where poorly conceived changes become core >> dependencies. >> >> We haven't had a culture of making a big deal about the case when >> someone introduces a breaking change or does something that brings the >> db to its knees or introduces a massive security hole or whatever. >> That means that if the situation were to arise that we needed to >> revoke someones access, we have to wait until it gets egregious and >> awful, and even then the person is likely to be shocked that their >> rights are being revoked (if we even do it then). To be less >> conservative about giving access, we also need to figure out how to be >> less conservative about taking it away. We also want to be as >> reasonably objective about it. It's always going to be somewhat >> subjective, and we don't want to completely eliminate the role of >> common sense. >> >> It would also be nice if we didn't have to resort to the nuclear >> option to get the point across. One low-stakes way we can use to make >> sure people are more careful is to have some sort of rotating "oops" >> award. At one former job I had, we had a Ghostbusters Stay Puft doll >> named "Buster" that was handed out when someone broke the build that >> they had to prominently display in their office. At another job, it >> was a pair of Shrek ears that people had to wear when they messed >> something up in production. In both cases, it was something you had >> to wear until someone else came along. Perhaps we should institute >> something similar (maybe as simple as asking people to append "OOPS" >> to their IRC nicks when they botch something). >> >> Rob > [0] > > Now that we are being looser in granting access,[1] it's probably a good > idea to figure out how and when to remove access -- the D in CRUD, > right? :-) There should be social and technical procedures for removing > members from Gerrit project owner groups. As Rob said, if someone is a > chronic offender in breaking the deployment, then it's important to have > some consequence. Possible reasons to consider removing members should > include *persistently* breaking things through negligence or > incompetence, lack of respect for other community members, > anticollaborative behavior, and possibly "I have left the community and > have no plans to come back" (as opposed to "I am now going to take a > year off from MediaWiki to concentrate on my new baby" or a similar > hiatus). There were more thoughts on this in > http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/59681 > . > > I personally want clearer guidelines for this *so that we can be more > open to giving more volunteers +2*. > > [0] (original thread: > http://www.gossamer-threads.com/lists/wiki/wikitech/281340 . Summary: > let's not create solutions in search of problems; ideas for embarrassing > IRC nicknames and other shame-based norm enforcement; this is about fun > and responsibility, not humiliation; the need to balance caution and > decisiveness.) > > [1] Per > https://www.mediawiki.org/wiki/Talk:Git/Gerrit_project_ownership#Removing_un-wiki_part_of_this_policy > the policy for giving +2 for Git repositories is now "If there is > consensus from the existing project owners, then we'll approve the > candidate." This is a change to the previous policy, which allowed a > single existing owner to veto a candidate. Chad made this change to > policy on the 4th: > https://www.mediawiki.org/w/index.php?title=Git%2FGerrit_project_ownership&diff=640780&oldid=640776
OK, the policy is at https://www.mediawiki.org/wiki/%2B2#Revocation - RobLa reminded me that we already had had this discussion. :-) Thanks. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
