Gerrit/Project ownership

__NEWSECTIONLINK__ This page queues individuals' requests to be added to the Gerrit project owner groups for specific Gerrit projects (each of which corresponds to a Git repository). A Gerrit project owner has the power to approve changes for merger into that Gerrit project's master branch, and to veto changes (see +2).

"When/how we'll add, remove people from Gerrit project owner groups" has procedural details. Sumana Harihareswara will regularly look at new requests for project owner membership and contact the existing project owners. If there is consensus from the existing project owners, then we'll approve the candidate. For each new candidate the process shouldn't take more than two weeks, and usually much less. Ownership can be revoked.

If your codebase/extension/tool isn't in Git yet, use this form to create a new Gerrit project: Gerrit/New repositories

To see the current list of Gerrit project owners for a specific Gerrit project, visit https://gerrit.wikimedia.org/r/#/admin/groups/.

= Ownership structure = Example: an extension is named foo.
 * The Gerrit group "foo" should usually be an owner of the Gerrit project "foo."
 * Sometimes, meta-groups will be included in the group. This is for people have ownership over multiple extensions, so you can add/remove members in one place.
 * Rights to the group may be inherited from other groups (Look for a "Rights Inherit From:" in the project access.)

Specific example: the project "mediawiki/extensions/DonationInterface" is owned by group "extension-DonationInterface." This group includes the meta-group "fundraising." Also members of the group "mediawiki" has ownership via "Rights Inherit From: "mediawiki/extensions access"

By keeping the naming convention ("extensions/foo" is owned by group "extension-foo"), it'll make the "automatically setup a repo" process much more scriptable when we hit that bridge.

(Note to Gerrit group creators: remember to check the "Make group visible to all registered users." checkbox.)

= To make a new Project Owner =


 * Create a group
 * Give it ownership of a Project
 * Anyone in that group can now add more owners via https://gerrit.wikimedia.org/r/#/admin/projects/ (but we prefer to keep that process public via Git/Gerrit project ownership)
 * Click Groups
 * As long as you are a member of the group, you can edit the group
 * example: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki,access

MediaWiki core
We are maintaining a "WMF" branch of mediawiki/core.git. We use submodules for deployed extensions, and can pull from master as regularly as we want for deployments. At the start of the migration to git, the project owners of this branch are going to be the people who have the ability to deploy code to Wikimedia Foundation servers. gerrit will offer a list of the "Gerrit project owners" for this branch, except for the Operations (system administration) group, which is an LDAP group. Every member of the Wikimedia Foundation operations team will also be in the Gerrit project owners group insofar as they have code review rights globally, but in practice will rarely review code. We may add some existing code reviewers to this Gerrit project owners group. Details; you can request to be added.

At the start of the migration, this list of Gerrit project owners for the WMF branch is also the list of Gerrit project owners for the master branch. However, eventually, we will add to the list of Gerrit project owners for master, using as criteria the number and quality of developers' previous commits and code reviews.

Details and procedure for adding and removing people from the Gerrit project owners groups.

MediaWiki has release branches (19 so far) for core, and master (the default branch previously known as "trunk" in SVN). Example: ("heads" is gitweb's term for branches). MediaWiki core and WMF-deployed extensions will be tagging releases just as we did in Subversion, except they'll be Git tags instead of SVN tags. Any other extension will make its own decisions regarding tagging.

MediaWiki extensions that the Wikimedia Foundation deploys
Same procedure as for MediaWiki core, and the same Gerrit project owner groups.

Other MediaWiki extensions
Every extension author can choose between two choices here for non-master branches: the gated-trunk/push-for-review model, and a straight push model. For any given extension, we will honor the wishes of the person/s listed as the main author on the extension's mediawiki.org page.


 * The gated-trunk/push-for-review is the model that we are using for MediaWiki core, as mentioned above. A Gerrit project owners group (plus the above mentioned Gerrit project owners group for MediaWiki core) will be able to "+2" (approve and merge) changes to their extensions.  The extension author(s) will be able to define a Gerrit project owners group and add others to it.


 * The straight push model is similar to how we did things in Subversion; anyone can suggest a change and submit a pull request, and it will automatically be approved and merged.

Master branches must go through Gerrit and cannot be straight push. This is necessary to facilitate a number of Gerrit features, including replication, updating of the extension meta-repository, and ability of Translatewiki to provide localization updates.

We could define groups to make this easier for batches of extensions (e.g. SMW developers). Chad will offer your community a choice. Please let Chad what you would like via Git/New repositories.

Other Gerrit projects
Same procedure as for "other MediaWiki extensions" above.

= Requests =

[ Add a request]

Wikinaut for extension UserMerge
update: I think my request has been forgotten. I hereby re-apply for becoming UserMerge maintainer. I was that before the extension was moved from SVN to git, but then it was forgotten to set me up again as owner for the git version. --Wikinaut (talk) 18:07, 5 January 2014 (UTC)


 * previous discussion

Hereby I apply gerrit project ownership for the extension UserMerge, which I maintain since a while see https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/UserMerge and Extension:UserMerge. Further projects which I already maintain since a long time are OpenID, AJAXPoll, EtherpadLite, RSS, WikiArticleFeeds.

To support my request: there is a relationship between UserMerge and OpenID for example, when merging/deleting an account. I also added the needed hook some time ago to mw core.

--Wikinaut (talk) 19:18, 30 May 2013 (UTC)
 * Bawolff (talk) 22:51, 3 June 2013 (UTC)
 * Weak - I've worked with Wikinaut a bit on Extension:OpenID. He's a diligent maintainer, but he tends to do a lot of self +2ing. While I don't mind this much in most extensions, it seems Extension:UserMerge is deployed to WMF wikis (specifically WikiVoyage). I would support this if somebody else was added to the project with him. Parent5446 (talk) 03:01, 4 June 2013 (UTC)
 * @Parent: the +2ing was at least in some cases done after having had security chats with Ryan and CSteipp - who gave their "ok, go on". Just as a comment. --Wikinaut (talk) 19:28, 4 June 2013 (UTC)
 * In my opinion, +2'ing is ok if he's the only maintainer (or there is agreement among the maintainers that that is ok), and the extension is not being used by WMF. I don't see anything wrong with non-wmf extensions using different code review strategies (+2'ing is of course never ok on WMF extensions). Bawolff (talk) 21:04, 13 June 2013 (UTC)


 * Weak I was just witness to an instance where Wikinaut asked for advice, implemented the solution incorrectly, then self-merged. When someone else is involved in a change it's almost certainly important to wait for some followup feedback. That said I can't strong-oppose since it was basically an extension he builds on his own, hence "weak". --MarkTraceur (talk) 00:51, 5 June 2013 (UTC)
 * In my view not yet experienced enough in web development (PHP/JS) and MediaWiki-specific interfaces to review and approve code changes to Wikimedia-deployed software. Krinkle (talk) 04:42, 9 June 2013 (UTC)


 * I think the opposes above carry no value to this discussion and should be ignored. Wikinaut is among the main authors of the extension and probably the only person interested in maintaining it as of now (there are no true owners: ): not being given ownership upon creation of this repo is just a remnant of the past. The fact that this extension is marginally enabled on some WMF wikis can't stop its development: if WMF doesn't trust the extension/its maintainer(s), WMF should just disable it from Wikivoyage. It's always been a dangerous extension, that should not be normally present on WMF wikis anyway, and was enabled only to assist the temporary needs of migration: but that was a year ago! --Nemo 18:15, 5 January 2014 (UTC)


 * ✅ ^demon[omg plz] 21:05, 27 January 2014 (UTC)

Aude +2 for wikimedia/wikimania-scholarships
Aude is listed as a member of the project and the owner of the GitHub project that the current application was forked from. She has recently been granted +2 on mediawiki/core and I believe that it should be an uncontroversial decision to allow her to the same rights on this project. --BDavis (WMF) (talk) 18:37, 20 December 2013 (UTC)
 * Legoktm (talk) 16:26, 14 January 2014 (UTC)
 * seems obvious --MarkTraceur (talk) 18:28, 14 January 2014 (UTC)
 * Experienced contributor in general, and since she started the project, she clearly has experience here. Superm401 - Talk 20:01, 27 January 2014 (UTC)


 * ✅ ^demon[omg plz] 21:06, 27 January 2014 (UTC)

aarcos +2 for UploadWizard
User:aaron_arcos has been working with the Multimedia team on Extension:MultimediaViewer, we gave him +2 on it last month (see the section above), but now he's moved on to working on Extension:UploadWizard and it would be good to give him +2 on that too. --MarkTraceur (talk) 18:55, 9 January 2014 (UTC)


 * --Tgr (WMF) (talk) 01:23, 24 January 2014 (UTC)

Isarra for mediawiki/skins
Isarra is a skilled designer and ShoutWiki's current design/UX person. She's written several nifty skins on her own as well as collaborated with other developers (most notably yours truly) on various design and UX matters. I'm absolutely confident in her skills and therefore it'd only make sense for such an expert to belong to the mediawiki/skins group. --Jack Phoenix (Contact) 22:23, 9 January 2014 (UTC)
 * Matma Rex (talk) 22:54, 9 January 2014 (UTC)
 * Legoktm (talk) 16:26, 14 January 2014 (UTC)
 * of course. Isarra has been a tireless and sometimes underappreciated force in the design sphere of MediaWiki. Giving her more ability to effect change in the skins would definitely be useful! --MarkTraceur (talk) 16:39, 14 January 2014 (UTC)
 * per MarkTraceur Yuvipanda (talk) 18:19, 14 January 2014 (UTC)
 * -- Krenair (talk &bull; contribs) 18:13, 14 January 2014 (UTC)
 * clearly has relevant experience. Steven Walling (WMF) &bull; talk   22:14, 14 January 2014 (UTC)

Is there any reason this hasn't gone through yet? --MarkTraceur (talk) 18:45, 22 January 2014 (UTC)


 * ✅ ^</b><b style="color:#000">demon</b><sup style="color:#c22">[omg plz] 21:04, 27 January 2014 (UTC)</i>

Sam Smith (phuedx) to staff group
Sam Smith (phuedx on-wiki, Gerrit, and IRC, samsmith@wikimedia.org) is a new staff member in Features Engineering/the Growth team. Please add him to the staff group? Thanks, <font style="font-family:Georgia, serif;">Steven Walling (WMF) &bull; talk   23:39, 24 January 2014 (UTC)


 * Tychay (talk) 20:43, 27 January 2014 (UTC)
 * ✅ <b style="color:#c22">^</b><b style="color:#000">demon</b><sup style="color:#c22">[omg plz] 21:04, 27 January 2014 (UTC)</i>

Addshore for mediawiki/core
Addshore is a longtime Wikipedian who is now a MediaWiki contributor, working on the Wikidata team. He's also contributed a lot to core (merged patches), especially in the area of writing unit tests. I think him having +2 will be beneficial. Legoktm (talk) 22:10, 25 January 2014 (UTC)
 * Matma Rex (talk) 17:51, 27 January 2014 (UTC)
 * he has submitted numerous core patches, improving test coverage, etc. (in addition to work on Wikibase and various other extensions) Aude (talk) 02:11, 28 January 2014 (UTC)