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.

"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 the candidate gets zero vetoes and at least one yes 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.

If your codebase/extension/tool isn't in Gerrit yet, use this form: Git/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.)

= 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)
 * 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)

Jeroen De Dauw for MediaWiki core ownership
And yes, I will only approve stuff of others that I'm qualified to review :) -- Jeroen De Dauw (talk) 18:14, 3 August 2012 (UTC)


 * -- Daniel Kinzler (WMDE) (talk) 16:15, 21 August 2012 (UTC)
 * We went over this in April, and the consensus was to grant +2 for certain extensions but not for core. I still have the same opinion. --Catrope (talk) 23:40, 21 August 2012 (UTC)
 * I love Jeroen changes, but I would prefer having a safeguard before landing them in production :-) Antoine &#34;hashar&#34; Musso (talk) 19:53, 23 August 2012 (UTC)
 * ❌ Sumana Harihareswara, Engineering Community Manager (talk) 15:09, 24 August 2012 (UTC)

As I understand it, the reason for not giving me merge rights is because I would supposedly go and merge my own stuff without discussion and break core. I understand that I should not merge my own code very well, and think I am quite responsible enough not to break things by being sloppy. I have merge rights to quite a few extensions, including WMF deployed ones, and AFAIK I have not merged in a single change that needed to be reverted since the git migration. So the argumentation against granting merge rights here seem invalid to me. At the very least, I'd like to ask for giving me a chance and revoking the right as soon as I merge in any of my own commits (which I guarantee you I will not do). --Jeroen De Dauw (talk) 20:07, 27 August 2012 (UTC)
 * It's not about merging your own changes, it's about about trust in general. We only give +2 access to people if the other reviewers trust their judgment. Once we actually have a process for revoking +2 access, I guess we could be more liberal about giving people access and taking it away from them if they break certain yet-to-be-determined rules, but right now we don't have such a process and we don't have those rules spelled out very well. So currently we can't really say "here's your access, but don't do X or we'll take it away", we can only say "here's your access, we're confident you'll use it well" or "sorry, you don't get merge access". I think that middle ground option should exist, and if and when it does that's what I'd vote to give you, but since it doesn't exist right now I'm voting conservatively. --Catrope (talk) 18:33, 31 August 2012 (UTC)

Semantic Watchlist
Ownership for SemanticWatchlist repo:


 * Nischayn22
 * yaron
 * markus