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 | tylerromeo(a)gmail.com
On Thu, Feb 14, 2013 at 6:19 PM, Sumana Harihareswara <sumanah(a)wikimedia.org
wrote:
> 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
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_u…
> 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&…
>
> --
> Sumana Harihareswara
> Engineering Community Manager
> Wikimedia Foundation
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l