I talked with Tim, Chad, Roan, and RobLa to nail down how we're going to manage membership in Gerrit's project owner groups (people with the permissions to merge code into the master branch). Caution: long. TL;DR: we'll start off with a small set of Gerrit project owners for everything, and then aim to be consistent, thoughtful, and transparent in how we add people to and remove people from those groups.

Three major areas to cover: * MediaWiki core * Extensions that WMF deploys * Other extensions/projects, including new repositories

== MediaWiki core ==

This is core.git, https://gerrit.wikimedia.org/r/#admin,project,mediawiki/core,branches or https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=summary .

=== Who gets to merge things into core, and how? ===

Right now, it's shell & root. It's the people in https://gerrit.wikimedia.org/r/#admin,group,11 once that group gets set up properly (see https://bugzilla.wikimedia.org/show_bug.cgi?id=35148 ). That group right now:

From Ops (via an LDAP group):

fvassard dzahn jeluf kate lcarr mark midom py robh ariel laner asher jgreen ben sara pdhanda

From development:

brion tfinc tstarling catrope andrew awjrichards aaron nikerabbit nimishg rfaulk demon hashar reedy preilly robla

(removed zak and neilk as they are now dormant in our projects) (added myself so I can do administrivia like adding & removing people)

So, we are currently limiting this to those who have cluster access, because these will be the people who have to get interrupted to fix things when something is screwed up. They will be married to the consequences of their mistakes. This helps change the current situation, where any developer can merge bad code in but it costs developers time to back it out.

However, we may expand the group in the future, or change how we do branches, to allow smaller-scoped commits to get merged more easily. As Aaron put it, large commits are scary no matter who writes and commits them, whereas some authors we can trust to merge in smaller changes.

Also to avoid: * creating circular communities of people who give hasty, shoddy reviews to each other's work and sidestep quality control * the habit of cherry-picking friends' or colleagues' commits to review and leaving strangers' commits to rot in the merge request queue * being so cautious about adding people to the Gerrit project owners groups that we build up an unsustainable merge request backlog * letting big changesets into the codebase without accompanying unit tests (counterexample: testing on FileBackend helped a lot) * being jerks

=== How will we add Gerrit project owners? === The current thinking is that individuals can request to be added to the project owner groups for specific Gerrit projects. We will create a queue ( https://bugzilla.wikimedia.org/show_bug.cgi?id=35347 ) to process requests from people who want to join the MediaWiki core Gerrit project owners group, and I'll manage the process as I now manage the commit access requests process. When someone requests membership, I'll contact the existing project owners, and if the candidate gets zero vetoes and at least one yes from the existing project owners, then we'll approve the candidate.

We will also need to proactively add new people into the Gerrit project when they get suggested by existing project owners. The shortlist would also include experienced developers with good MediaWiki code review skills, like Timo, Trevor, and Nikerabbit. We've already added Platonides to the Gerrit project owners group since he fits these criteria.

After we run through the usual suspects, we should make regular efforts to find underpublicized high-caliber code reviewers to suggest as candidates. We should develop some kind of proxy for "has done a bunch of good code review work" so we can check statistics to find candidates -- perhaps "number of statuschanges they OK that do not later get FIXMEs, proportional to the lines-of-code size of changes reviewed," or something like that. Please do not bikeshed this right now! Chad will propose something far more sensible sometime in April, I think.

Also, in the future, we may create another "unstable" branch (more forgiving than master but still not wide-open). The purpose would be to pull in all reasonable-quality pushes, and to provide a venue for code reviewers to gain experience so they can eventually graduate to master.

=== Why might a project owner be removed? === We are also creating some social and technical procedures for removing members from Gerrit project owner groups. After all, if you are a chronic offender of breaking the deployment, then we have to have some consequence. Reasons to consider removing members: * inactivity (a few months or more without commits, code review comments, or merges) * lack of respect for senior community members, and anticollaborative behavior * breaking things through negligence or incompetence

When do we revoke access? We're still figuring that out. Of course in most cases the other Gerrit project group owners would warn the relevant person first, but after that, what?

I floated a "two strikes" rule (the second time a big problem happens, we strongly consider revoking ownership) but we're iffy about it. After all, the severity of an incident is often not proportional to negligence! And who defines "big problem"? So, the criteria are likely to be somewhat subjective, but we aim to nevertheless apply them fairly, consistently, and we hope rarely!

== Extensions that Wikimedia Foundation deploys == There's a big list of them: https://gerrit.wikimedia.org/r/#admin,projects under mediawiki/extensions/ .

Each extension gets its own Gerrit project. All MediaWiki core project owners are also project owners for all the Gerrit projects of WMF-deployed extensions. Additionally, if someone is the maintainer of an extension, they should generally have Gerrit project owner rights on that extension.

How do we determine who is the maintainer or the primary developer? We look for the person credited in that extension's $wgExtensionCredits or in a CREDITS file; for example, for CentralAuth, per http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/CentralAuth/Centr... , it'd be Brion Vibber. But there are some edge cases here:

* There are a few extensions, ParserFunctions, who don't have specific reviewers. * Sometimes the primary author is not experienced or skilled enough to be a Gerrit project owner if that means basically being able to approve something for deployment. * Sometimes there are very old extensions, or extensions where the original authors/maintainers listed in the credits have left the project (like ThomasV with ProofreadPage).

So, over the next few weeks, the current MediaWiki core Gerrit project owners will go through the ~100 extensions that are deployed on WMF sites, and make judgment calls based on the extension owners' reputation and experience. In most cases those extensions maintainers will also become Gerrit project owners, but in some cases they will simply be reviewers who get asked to review important changes.

The ones that are most important to cover sooner are the ones that have been under active development in the last few months.

=== Changes === If someone wants to apply to be a Gerrit project owner of an extension that the Wikimedia Foundation deploys, then we'll follow the same procedure that we do for MediaWiki core, with that queue (follow https://bugzilla.wikimedia.org/show_bug.cgi?id=35347 ) and checking with existing Gerrit project owners. And removal will work the same way as mentioned for core.

== Other MediaWiki extensions == As mentioned in https://www.mediawiki.org/wiki/Git/Conversion#Affected_development_projects , the extensions that WMF doesn't deploy (there are about 675 of them) have some more time before deciding whether to switch to Git or move to another repository. We do want to be proactive about communicating with them (emailing people mentioned in their credits) and find guinea pigs. :-)

For example, we know who the Semantic MediaWiki/Semantic extensions developers are, so we could easily reach out to them and know who the Gerrit project owners would be. In contrast, for somewhat older extensions with little traffic, we can wait a little longer. RobLa suggested that, in those cases, we can just let people have Gerrit project ownership of the extensions if they're listed in $wgExtensionCredits or CREDITS and have done a substantial percentage of the commits in the last three months or so; if not, we'd poke around a little and ask for an ok from the people who are listed as the extensions; authors.

== Changes == The addition procedure will probably be through that same queue. And as for removing people from project owner status of a non-WMF deployed extension, we would basically follow the same guidelines as core -- vandalism or proprietary licensing or anticollaborative behavior -- except that the "breaking the deployment" reason would not be applicable.

=== Newly created extensions/Gerrit projects === When anyone wants to create a new extension, they will by default be an owner of it.

We aren't going to let people create new repositories completely automatically, since that might lead to pointlessness, spam, or non-Wikimedia-related code living on our servers -- see the model in action at https://www.mediawiki.org/wiki/Git/New_repositories . In most cases a request will be rubberstamped, as long as the Gerrit project will be under an open source license and the work is related to MediaWiki and/or Wikimedia in some way.

I hope this has been helpful. I suspect we won't have too much to discuss but if there are clarifications needed please speak up; then in a day or two I can put this up on the wiki to make it easier to reference.