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).
Stevens Institute of Technology, Class of 2015
Major in Computer Science
On Thu, Feb 14, 2013 at 6:19 PM, Sumana Harihareswara <sumanah(a)wikimedia.org
> On 06/15/2012 04:53 PM, Rob Lanphier wrote:
> > On Fri, Jun 15, 2012 at 8:48 AM, Sumana Harihareswara
> > <sumanah(a)wikimedia.org
> >> If you merge into mediawiki/core.git, your change is considered
> >> 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
> Now that we are being looser in granting access, 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
> I personally want clearer guidelines for this *so that we can be more
> open to giving more volunteers +2*.
>  (original thread:
> 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
>  Per
> 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:
> Sumana Harihareswara
> Engineering Community Manager
> Wikimedia Foundation
> Wikitech-l mailing list