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 Git yet, use this form to create a new Gerrit project: 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)

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)

Nischyan branch owner in SemanticMaps
I tried making Nischyan owner of the nischyan branch of SemanticMaps by adding a group he's member of as owner of this branch. I want him to be able to happily merge in stuff without needing approval of someone else. Since this did not work, I tried giving him pretty much all other rights on the branch, but he says he's still not able to approve his own commits. Am I doing something wrong? https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/SemanticMaps,access
 * -- Jeroen De Dauw (talk) 15:04, 24 September 2012 (UTC)


 * Reviewing commits (Verified+1, CodeReview+2, Submit) needs to be assigned to the appropriate refs/for/* refspace, not the destination ref. Compare and . ^demon (talk) 19:23, 24 September 2012 (UTC)


 * So it should be refs/for/refs/heads/nischyan? --Jeroen De Dauw (talk) 18:26, 28 September 2012 (UTC)


 * Yes ^demon (talk) 18:21, 18 October 2012 (UTC)

This does not appear to work - can you check the settings to see if they are correct? --Jeroen De Dauw (talk) 18:53, 21 October 2012 (UTC)

2 new members for 2 groups
Please add jeroendedauw and markus to semanticmediawiki-trusted and semanticresultformats-trusted. --Jeroen De Dauw (talk) 18:54, 21 October 2012 (UTC)
 * I don't have the power to do this; Yaron, DanWe, Denny, Foxtrott, Kghbln, Mwjames, and Nischay are the ones who can. I've asked Yaron to look into it. Thanks. Sharihareswara (WMF) (talk) 21:15, 6 November 2012 (UTC)


 * It doesn't appear like I can do it either. I'm a member but not an administrator, or something like that. Yaron Koren (talk)
 * I'm told that Jeroen can add them himself. extension-SemanticMediaWiki is the owner of that group (as requested, so he could manage it). Go ahead, Jeroen! Sharihareswara (WMF) (talk) 16:25, 8 November 2012 (UTC)

Oh great, I can indeed manage these groups. Used to not being able to do this myself since this is the case everywhere else. Anyway, issue closed :) --Jeroen De Dauw (talk) 20:08, 12 November 2012 (UTC)

SPQRobin for translatewiki
I would like to have +2 access for the translatewiki.net group. I already have +2 access to MediaWiki core, and I am a staff member on translatewiki.net, though I'm not really active, but +2 access can still be useful. Thanks, SPQRobin (talk) 19:37, 15 November 2012 (UTC)
 * Confirmed. Raymond (talk) 19:41, 15 November 2012 (UTC)

Mwdumper
Please include me in the mwdumper group. I would like to merge some bug fixes, since no one seems to be interested. Thanks, Bean49 (talk) 09:51, 19 November 2012 (UTC)
 * Mwdumper could sure use some love. Ownership request looks good to me, provided the user is willing to stick around for awhile after merging in their own fixes, commenting on or reviewing changes other people might make.  -- ArielGlenn (talk) 06:22, 20 November 2012 (UTC)
 * . --ori (talk) 00:41, 28 December 2012 (UTC)

Request myself as project owner of mediawiki/extensions/SoundManager2Button
--Kroocsiogsi (talk) 22:33, 19 November 2012 (UTC)

Isarra requesting ownership of 5 unmaintained extensions
Something about ownership so I can more easily attempt to maintain these, or some such? I didn't write any of them or nothing, but apparently nobody wants them or something.

In the extensions pile:
 * DPLforum
 * MediaWikiAuth
 * RandomImage
 * Editcount
 * LogoFunctions

Thanks, I think. Although this is probably going to wind up smacking me in the face. Or something. -— Isarra ༆ 05:05, 24 November 2012 (UTC)
 * I'd link to them, but I'm not even sure what I'd link to at this point. I'm sorry, I have no idea what I'm doing, but hopefully I'll figure it out at some point. Yeah. -— Isarra ༆ 05:09, 24 November 2012 (UTC)
 * Isarra, is it correct to say that you are requesting ownership of these 5 extensions so you can improve them? The way you are writing makes it sound like you don't actually want that ownership and have no particular plans to improve the extensions.  Sharihareswara (WMF) (talk) 14:36, 25 November 2012 (UTC)
 * Improve, or at least maintain them as needed so they keep working with new versions. The notion of 'owning' the things is a little off-putting, but without anyone else around apt to look after them I don't see much for a better idea at present. -— Isarra ༆ 05:56, 26 November 2012 (UTC)
 * These extensions aren't deployed and no one else seems to have much love for them, so if you want to maintain them, knock yourself out. +1 for ownership rights. --Catrope (talk) 23:14, 27 November 2012 (UTC)
 * DPLforum is on Wikia and Uncyclopedia, Editcount is on Wikia. Odd that no one is maintaining these, but if you're willing to do so please go ahead. Carlb (talk) 01:48, 24 December 2012 (UTC)

Oh, this also goes for Jack Phoenix - as he is also on the project, he should have ownership as well. Whatever the case, however, at very least someone involved should or we're going to have some mighty trouble making changes... -— Isarra ༆ 18:07, 30 December 2012 (UTC)
 * I support the request for MediaWikiAuth, raising priority, as this extension has waiting reviewed commits pending a merge. --Dereckson (talk) 03:16, 3 January 2013 (UTC)

valhallasw (LDAP: Merlijn van Deen) for LabeledSectionTransclusion
LST on gerrit

Sumana suggested I should apply for (co)ownership of the LabeledSectionTransclusion extension. I am the author of the recent patch that added support for section tags in templates, and thus have some knowledge of the code base. As such, I think I could be helpful in reviewing & merging new patches. Valhallasw (talk) 08:50, 28 November 2012 (UTC)
 * +1 Tpt (talk) 14:08, 28 November 2012 (UTC)

Creation of a repository for my extension, PreloadContent
I am developing a new extension, Extension:PreloadContent and I want to have my code hosted on MediaWiki repos. --Milad Naseri (talk) 11:09, 3 December 2012 (UTC)
 * Can you please describe this extension in greater detail, or provide a code sample? --ori (talk) 00:40, 28 December 2012 (UTC)

carlb on extension-SpecialNamespaces
Am attempting initial check-in of extension:SpecialNamespaces (39720) and was sent here to request merge access to the repository to import existing code. I doubt that this extension is deployed on any major site outside the foreign-language Uncyclopedia set, where it originated in 2006 as what should have been a short-lived stopgap. Carlb (talk) 01:44, 24 December 2012 (UTC)

Krenair for MediaWiki Core
Alex Monk (Krenair) has demonstrated good care with code review and has been a prolific fixer of bugs, in core and other projects. He's a prolific reviewer and bug-fixer (in the last two days, he has patched four bugs in core). Back in March, our then-bugmeister awarded him the MediaWiki Bug Squad Barnstar for his bug fixes. Finally, he is also an active and helpful admin on mediawiki.org, and has made significant contributions to the documentation. --ori (talk) 10:40, 25 December 2012 (UTC)

Supporting material

 * Gerrit reviews (all projects)
 * +/- 1s (mediawiki/core)
 * Gerrit changes (mediawiki/core)
 * Gerrit changes (all projects) Bugzilla activity
 * Contributions on mediawiki.org

Discussion

 * As requestor. --ori (talk) 10:40, 25 December 2012 (UTC)
 * Sounds like a great idea to me. Kaldari (talk) 10:47, 25 December 2012 (UTC)
 * Krenair has been a great help. CSteipp (talk) 01:15, 27 December 2012 (UTC)
 * Yes -trusted, helpful and experienced. The  helpful  one  01:31, 27 December 2012 (UTC)
 * Tychay (talk) 05:06, 27 December 2012 (UTC)
 * Aude (talk) 07:31, 27 December 2012 (UTC)
 * He's not already? Let's fix that. Anomie (talk) 14:22, 27 December 2012 (UTC)
 * Jdlrobson (talk) 16:04, 27 December 2012 (UTC)
 * --MZMcBride (talk) 21:48, 27 December 2012 (UTC)
 * Haven't (yet) seen many non-trivial changes by other people that he has reviewed as +1 that were merged as-is (which ought to be an obvious requirement for merge rights as those CR+1 would generally become CR+2 and merge). We no longer require permissions for patch submission access, so assuming this request is for granting merge rights (and thus ability to approve patches that will not be reviewed by others and deployed/released as-is in 2 weeks), I'd rather see a little more reviewing in current status. He is very helpful in bug triaging and documentation maintenance, but that's not quite the same as merge approval on changes for mediawiki core. Opposing as "not yet". I'd expect him to become a core contributor within a few months. His contributions are almost equally valuable without merge rights (having merge rights does not change patch submission as one doesn't merge own code; reviewing other's code with -1 for improvement is very helpful and about as helpful as +2, both reduces review load from mergers). Krinkle (talk) 17:51, 28 December 2012 (UTC)
 * I don't feel our criteria needs to be having a lot of +1's on core that are merged, since we've given +2 to WMF employees. In the past I think we've been minimizing type II error, at the cost of type I error—the fear of "bad committers" has hurt made an unreasonably high bar for community involvement at certain levels (then again, I feel the bar you, Roan, and others cleared was unreasonably high too). Things like +2 to WMF engineering have changed this dynamic and I'd like to see that new order extended to the community. I see this request more along the lines of fixing the imbalance between his responsibility in Echo and those of the WMF vs. the same action/participation on core patches that are Echo related (and others). The main criteria is do we feel he may act to be irresponsibly with +2 or, conversely, is he as responsible as current +2'ers (he's certainly more responsible with +2 than I am ;-))? Having said that, there's no harm in holding off on +2 for a month, since Alex probably represents the first of, what I hope, is a tidal wave of more community +2'ers in core and extensions. Tychay (talk) 22:07, 31 December 2012 (UTC)
 * I think Krinkle makes a reasonable point, but I really enjoyed the first sentence of your reply. :-) I'd say that discretion is also fairly important to consider in this forming Git model. Some volunteer devs have +2 now, but they only review changes they're comfortable reviewing (as it should be with everyone, really) and it seems to be working very well. Code review is a long tail and you need as many helping hands as possible. In terms of Krenair's ability to distinguish what's appropriate to merge and not merge, I'm not concerned. --MZMcBride (talk) 00:51, 3 January 2013 (UTC)