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 and leave the group type as "Internal group" and not LDAP.)

= 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]

A bunch of new groups
I'd like to have an $extension-trusted group (initially empty and with no rights assigned) for the following extensions: Validator, Maps, SemanticMaps, Push, LiveTranslate, SubPageList, Spark, IncludeWP, Survey, DidYouKnow, Gitweb (once created), DataValues (once created), Diff, SemanticWatchlist, SemanticImageInput and SemanticBundle.

These groups would be owned by their respective $extension-owner group.

This will allow me to manage my extension myself without posting a request here each time someone should get access :) --Jeroen De Dauw (talk) 19:25, 17 August 2012 (UTC)

Comments

 * Support. --siebrand (talk) 16:06, 21 August 2012 (UTC)
 * Since these are non-deployed extensions, I think this is fine. But I'd like to get input from Chad before we start introducing new group structures. --Catrope (talk) 18:02, 21 August 2012 (UTC)
 * I don't *like* it as proposed since this is very quickly going to explode the number of groups we have. Ideally all extension-$name groups should be owned by an extension-$name-owner (other than deployed exts, perhaps). The reason it's all currently owned by the "Project & Group Creators" was so people could process this page and add new users to their respective groups. What I'd like is either A) A way to manage all groups without giving out admin privs, or B) Multiple owners of groups. The former is probably easier. This all being said, perhaps we can go ahead with this structure for a few non-deployed extensions anyway and see if we really need this page at all for granting access to those. ^demon (talk) 14:05, 22 August 2012 (UTC)
 * Well then I suppose we'd be supportive of adding Jeroen as the owner of all those groups? Also, it seems to me that there are a number of them should be in some metagroup fro SMW. Tychay (talk) 20:56, 5 October 2012 (UTC)
 * Chad, sorry for being obtuse, but when you say "perhaps" is that a go-ahead for me to go ahead and create the "extension-Validator-trusted", "extension-Maps-trusted", etc. Gerrit groups, and when necessary, the "extension-[name]" groups to own the "trusted" groups? Thanks. Sharihareswara (WMF) (talk) 15:44, 8 October 2012 (UTC)
 * Jeroen, I set up the relevant groups for Validator and I think I set them up how you'd like. Is that right? Tried to ping you in IRC, haven't gotten a response -- let me know if that's the right model and I'll do the rest of the groups. Sharihareswara (WMF) (talk) 23:52, 9 November 2012 (UTC)

Thanks for setting that group up Sumanah. You made the group owner of itself. If this is an acceptable thing to do, then perhaps there is no point in having such extra groups, as you could just make the extension-name groups own themselves, solving the issue with less work and clutter. Think chad had some reason to not do this though. --Jeroen De Dauw (talk) 20:15, 12 November 2012 (UTC)
 * Yeah, the reason was that it made it impossible for people in the "Project and Group Creators" group to manage any group member. This is being solved in the near future. ^demon[omg plz] 15:58, 21 February 2013 (UTC)

Jeroen for core
I believe it's high time that Jeroen has core access. He's the author of dozens of extensions, tons of core features (including ContentHandler), and is generally a great guy. I think he's grown a lot over the years since coming to us as a GSoC student, and it's shown in both the quality of his code and the review he gives others. He knows how everything works, and he's got a good eye for making sure things are well-tested.
 * As nominator. ^demon[omg plz] 14:50, 17 April 2013 (UTC)
 * Weak Another one of those "Wait, we...haven't yet?" --MarkTraceur (talk) 16:21, 17 April 2013 (UTC)
 * Edited to add "weak" - Krenair's note is a bit concerning. --MarkTraceur (talk) 18:28, 20 April 2013 (UTC)
 * per MarkTraceur Yuvipanda (talk) 16:32, 20 April 2013 (UTC)
 * I'm a bit unhappy that he has been merging his own changes, in violation of Gerrit/+2: (mouseover the CR column on most of those rows). There were some other concerns raised in a conversation I saw in an IRC channel two days ago. I can share those log extracts in private but I'm not sure how everyone else feels about them being public (it is a public channel though). -- Krenair  (talk &bull; contribs) 16:52, 20 April 2013 (UTC)
 * Krenair, if it was a public channel, I think it is okay to link to the log and specify the timestamp. Sharihareswara (WMF) (talk) 12:41, 24 April 2013 (UTC)
 * When looking at Kreanir's link, please note that this Query will list all changes submitted Jeroen where he ever voted in any way, including ones where he has giving himself a -1 when he found an issue, even if the change got later approved by someone else. That being said, there are true self-approvals in there. Most of them are trivial, but some I also find worrisome. But not enough so to oppose him here. -- Duesentrieb ⇌ 20:31, 29 April 2013 (UTC)
 * Per Krenair. Self-+2s in extensions like SemanticMaps, which is undeployed and where there's no one else to review, aren't that bad. Self-+2s in extensions like EducationProgram are bad because it's deployed code, but I suppose it's understandable because there's not really anyone around to review that code (I believe self-review still isn't the answer in that case, but I can see the argument for it). Self-+2s in extensions like Wikibase are really bad, because the code is deployed and there are people around to review those changes. --Catrope (talk) 01:12, 25 April 2013 (UTC)
 * I agree with everything ^demon says in his initial nomination. It is time we do this.  However, I believe we first need to have a wider discussion about the architectural direction of MediaWiki, since I believe that Jeroen has a very different view of how it should be put together than many of the MediaWiki architects do.  Code review is one area that our architects can exert some control over the architecture, and I don't want to take that control away from them by creating a situation where new reviewers can pull the architecture in a different direction than our architects believe we should go in.  This isn't exclusively a danger with Jeroen, but because Jeroen is pretty prolific, he will have greater pull than most.
 * The self review on Wikidata is also troubling, but it may just be that we should have a conversation about that with the Wikidata team rather than specifically using this as a reason for blocking Jeroen's nomination. I doubt this was an explicit snub to our policy, but rather, a misunderstanding about the rules (where "rules" should be in quotes, because I'm betting we can find plenty of examples of self-review in other deployed extensions).  This is probably something that we should discuss on-list independent of Jeroen's nomination.
 * Since many of the key people will be at the Amsterdam Hackathon (including Jeroen, from what I understand), I would prefer to make that something we discuss there (with Jeroen) prior to making a decision about Jeroen's +2. I'm inclined to support Jeroen's nomination once we have that conversation.-- RobLa-WMF (talk) 17:38, 25 April 2013 (UTC)
 * As somebody not entirely aware of these architecture opinion differences, what exactly do you mean? (I understand the point, I'd just like to know what views you're talking about specifically.) Parent5446 (talk) 03:01, 4 June 2013 (UTC)


 * I think Jeroen is quite diligent; while he certainly has different views on what the code should look like, his ideas revolve about stricter review policies with respect to testability. That's a good thing. And I don't think he'd go on a unilateral refactoring spree. I also believe he'll stick to policy as stated, whatever it is. What keeps me from supporting him directly is only that I'm not sure that he's careful enough about performance issues (caching, indexing, etc). I fear something with bad consequences on that level could slip by him. -- Duesentrieb ⇌ 20:31, 29 April 2013 (UTC)
 * I went over the last 50 changesets with owner/review overlap, and I think the message has been received. I mostly see selfies on comments likewise cleanup, some testcase config stuff, plain reverts and a few other maintenance related tasks. I have no major concerns and trust that Jeroen is able to distinguish and curtail himself when it comes to differences in merge policies between core and his own extensions. TheDJ (talk) 20:29, 4 June 2013 (UTC)

Wikinaut for extension UserMerge
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)

Matma Rex (Bartosz Dziewoński) for mediawiki/core (again)
Okay, we made MatmaRex jump through enough hoops last time. I think we should reconsider him as +2 in core because that time I only heard objections coming out of my teams, he's been nothing but helpful since, and @MarkTraceur has volunteered to assist in mentorship should any issues come up. -Tychay (talk) 19:09, 31 May 2013 (UTC)
 * Given his positive contribution history, the time that's passed, and MarkTraceur's offered mentorship, I'm ready to support. Just for the record, people outside Features did object last time, though. Superm401 - Talk 19:23, 31 May 2013 (UTC)
 * Support per Superm401.--Jorm (WMF) (talk) 19:26, 31 May 2013 (UTC)
 * I've been a fan of Bartosz since he started hacking on UploadWizard and his core work has been even more varied and awesome. He's a clever programmer and a solid reviewer, and most importantly he gets stuff done. --MarkTraceur (talk) 19:46, 31 May 2013 (UTC)
 * I just wanted to note that I don't want to use "mentorship" to mean anything less than a whole-hearted +2. I feel that a mentor should be available if only if any issues come up and Bartosz needs some assistance/advice, of which I expect there to be none. That's why I worded things the way I did. :-) -Tychay (talk) 20:50, 31 May 2013 (UTC)
 * Has been very helpful with much of the collation stuff. Bawolff (talk) 22:44, 3 June 2013 (UTC)
 * --Ori.livneh (talk) 00:24, 4 June 2013 (UTC)
 * Parent5446 (talk) 03:01, 4 June 2013 (UTC)
 * per @MarkTraceur Yuvipanda (talk) 06:57, 4 June 2013 (UTC)
 * productive and diligent. TheDJ (talk) 20:31, 4 June 2013 (UTC)

Jan Gerber (J) for Score extension
Jan has been the primary developer working on this for the past month or so. -- RobLa (talk) 15:19, 12 June 2013 (UTC)


 * Bawolff (talk) 21:31, 13 June 2013 (UTC)
 * -Tychay (talk) 17:10, 17 June 2013 (UTC)