sumanah at wikimedia
Mar 19, 2012, 5:08 PM
Post #1 of 2
I talked with Tim, Chad, Roan, and RobLa to nail down how we're going to
When/how we'll add, remove people from Gerrit project owner groups
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,
=== 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):
(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
* 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
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
, it'd be Brion Vibber. But there are some edge cases here:
* There are a few extensions, ParserFunctions, who don't have specific
* 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
, 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
== 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.
Volunteer Development Coordinator
Wikitech-l mailing list
Wikitech-l [at] lists