I know this is pretty obvious, but self-merging pretty much any change should be grounds for removal (or at the very least no second chance).
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Thu, Feb 14, 2013 at 6:19 PM, Sumana Harihareswara <suma...@wikimedia.org > wrote: > On 06/15/2012 04:53 PM, Rob Lanphier wrote: > > On Fri, Jun 15, 2012 at 8:48 AM, Sumana Harihareswara > > <suma...@wikimedia.org> 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 > > -- > Sumana Harihareswara > Engineering Community Manager > Wikimedia Foundation > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
