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]

Editor Engagement (meta-group)
This is a request for a new meta-group to be created for the Editor Engagement and the Editor Engagement Experimentation team (as they will be working on the same extensions). Instead of individually assigning extension access (for things like Page Triage) to each member, we can just request the meta-group be given control (like Fundraising does with the DonationInterface).

Group members:
 * Ryan Kaldari (already in the mediawiki group, but can't hurt)
 * Andrew Garret (already in the mediawiki group, but can't hurt)
 * Benny Situ
 * Ori Livneh
 * Matthias Mullie

This is not a request that the meta-group be given ownership of anything (yet).

Comments

 * This should be pretty straightforward to do--can't see any reason not to. ^demon (talk) 17:45, 12 June 2012 (UTC)
 * Chad, do you care what we name this, internally? I see we're being a little inconsistent in terms of capitalization, spaces instead of hyphens, etc. Do you care? Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 20:56, 12 June 2012 (UTC)
 * Created as Group "editor-engagement". ✅ Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 23:28, 13 June 2012 (UTC)
 * Alolita requested via email that we add Dario Taraborelli and Ryan Faulkner to this group. I accidentally removed my ability to add someone to the group; could one of the group members please do it? Thanks. Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 00:18, 14 June 2012 (UTC)

Merge Rights for Daniel Kinzler
Hi all

I would like merge rights for mediawiki/core/master and mediawiki/core/Wikidata. Since I had the right to commit to core in SVN, I supposed you can trust me with this.

Having these rights should help to ease the strain the Wikidata team puts on the core team, and also allows me to help out with the normal core review process for core.

-- Daniel Kinzler (WMDE) (talk) 14:19, 15 June 2012 (UTC)

In reply to some of the comments below: -- Daniel Kinzler (WMDE) (talk) 15:54, 15 June 2012 (UTC)
 * I'm pretty reluctant to submit anything to core just yet. I guess once i collected a bit more experience, i'll do it more often.
 * Whether I should be approving Wikidata-related changes - well, most of them are in our extensions, and we are reviewing them internally, as long as they are not deployed. And I am submitting/merging things there.
 * Core changes for wikidata should be rare and small once the WikiData branch has been merged. I'd not want to approve big changes to the core, but may merge the addition of a hook point or some such.
 * As to my rights on the Wikidata branch: apparently, I'm in the owner group and can submit, but I can't +2 changes, for some reason... maybe just an oversight.


 * I think we can trust him :) ^demon (talk) 15:35, 15 June 2012 (UTC)
 * Although I'm not sure you should be doing the review of precisely WikiData commits, on whose development you are participating at the same time. Platonides (talk) 15:43, 15 June 2012 (UTC)
 * Trusting Daniel to do some nice work. Please be careful since a merge in mediawiki/core is roughly equals to a deployment on the live site. Also you usually want to wait a bit to let a chance to other people to see the patches :-]  Antoine &#34;hashar&#34; Musso (talk) 15:44, 15 June 2012 (UTC)
 * Ownership for Wikidata is a no-brainer, it seems like he partially has it already but the permissions are messed up somehow. As for ownership of core, I don't think we should give this to someone who, by their own admission, is "reluctant to submit anything to core just yet" and doesn't need to approve anything in core except the occasional hook addition. If core changes for Wikidata are rare and small, I don't think they need a WD person with merge access, they can just go through the normal review process. So I'm gonna say yes to the Wikidata ownership request but no to the master request, unless someone convinces me otherwise. --Catrope (talk) 20:12, 15 June 2012 (UTC)

Project Ownership request for extensions: DiscussionThreading,NSFileRepo,NewUserNotif,StringFunctionsEscaped
Gerrit Username: Jpond  SVN/GIT ID: jdpond

It probably makes sense for me to at least be an authorized member, if not the owner for the following extensions(authored by me or got dumped into my lap). None of them have a current owner or any members. All are very stable, but still get update requests on their Talk pages and have corresponding bugzilla areas.


 * extension-DiscussionThreading: DiscussionThreading - a light weight forum-like extension to structure postings and replies on talk pages.  LiquidTheads is better, but this one works all the time and much less overhead.  Would like to sunset it, but several admins still have trouble gettin LQT working.
 * extension-NSFileRepo: NSFileRepo - Access protection based on Namespace for uploading and reading files/images
 * extension-NewUserNotif: NewUserNotif - New User Email Notification, Automatic email to admins when a new user registers (or needs approval)
 * extension-StringFunctionsEscaped: StringFunctionsEscaped - Allows String functions to work with escaped characters, e.g., \n, \t . ..

--jdpond (talk) 17:54, 16 June 2012 (UTC)
 * Partially done; NSFileRepo is maintained by Jpond per the extension wiki page and Jpond is the one who requested the move into Git, so I've added Jpond as an owner for that Gerrit project. Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 19:34, 16 June 2012 (UTC)
 * ✅ Jpond also requested the other 3 moves. Thanks! Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 20:16, 16 June 2012 (UTC)