Talk:Gerrit/Privilege policy

Trusted organizations and the mediawiki group

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The event that triggered the drafting of this policy was the request from Wikimedia Deutschland to have new hires be added to the mediawiki group immediately. According to this policy, that would not be the case: WMDE hires would still have to go through the request process to get +2 on core. Is this intentional? I seem to recall that there was agreement that it would be ok to have staff of trusted orgs get +2 per default. The alternative would be to include the wmde group in the mediawiki group, but I would advise against this - WMDE may want to grant access to their own stuff to a volunteer, without granting access to *everything*. Also, WMF may withhold access to core from specific people who work at WMDE, while still allowing them to be a member of the WMDE group, and have +2 on repos managed by WMDE. DKinzler (WMF) (talk) 12:30, 19 December 2018 (UTC)

That's not how I read it. New WM Deutschland employees would be automatically added to the wmde group, which by my interpretation of this document, is assumed to automatically have +2 on the whole mediawiki/ tree. Mobrovac-WMF (talk) 13:02, 19 December 2018 (UTC)

I don't see wmde listed in https://gerrit.wikimedia.org/r/admin/projects/mediawiki,access Nikerabbit (talk) 15:19, 19 December 2018 (UTC)

@Nikerabbit is right wmde LDAP group is not yet included under mediawiki project.

My understanding was, that based on the new policy, as a next wmde group will be added there. This is a technicality, which I am not sure has not be made more explicit in the policy.

Regarding one point from @DKinzler (WMF): wmde LDAP group should only be for WMDE staff IMO. Same as wmf LDAP group is in my understanding for WMF staff only (with "staff" I also mean active contractors etc). for possible volunteer access, some other groups would be used etc. But this again seems to me be a detail, which is not really in the scope of the policy. Leszek Manicki (WMDE) (talk) 08:55, 3 January 2019 (UTC)

@Leszek Manicki (WMDE) originally, the idea was to make the WMDE group an "included" group of the MediaWiki group. However, this would make it impossible to have people in the WMDE group but not in the MediaWiki group. There have been cases in the past of WMDE staff being denied +2 on the mediawiki group, and that possibility should still exist.

Instead, the idea is to have a list of "associated" groups for trusted organizations, for which these organizations can request members to be added without the need for prior public discussion.

In effect, this means that WMDE staff can added to the mediawiki group per default at onboarding, but can also be removed from this group again without removing them from the WMDE group. DKinzler (WMF) (talk) 09:39, 3 January 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Wikimedia is ambiguous

I would suggest to consistently use term "code deploy deployed to Wikimedia cluster" or similar. On hand this removes the ambiguity between developed/maintained vs. deployed by WMF and on the other the ambiguity what is included: production cluster, beta cluster, other labs projects, chapter wikis hosted elsewhere.... Nikerabbit (talk) 15:19, 19 December 2018 (UTC)

About +2

Three things, which are tangential to the actual point of this proposal, so feel free to ignore:

• When picking up (stale) patches from others, I often seek at least +1 from someone else for my additional changes before I self-merge. Assuming this is acceptable, maybe it can be documented under self-review.
• It would be kind for code bases with clear maintainers to give the maintainers a chance for review. I have seen patches created and merged by non-maintainers while maintainers were asleep. Sometimes these do have issues that could have been resolved before merging if the maintainers had the possibility to give a look at them. Can we encourage this in the policy?
• A non-criticizing observation: due to these rules, I often ask others to create patches I could do quickly myself, because getting someone to review my patch would take even longer than having the other person figure out how to create the patch, and I sometimes basically tell how it needs to be written, which is actually a self-review if one thinks about it very strictly. Nikerabbit (talk) 15:31, 19 December 2018 (UTC)

I said something about the first point, and I also renamed the section and changed some language to make it clear that the problem is merging changes that have not been reviewed by someone else, not "self-review", whatever that is. You might naively think that self-review means reading your own code before you upload it to Gerrit, which seems OK to me. Tim Starling (talk) 06:04, 22 January 2019 (UTC)

I've also encountered all three of these situations, particularly the first and third. Along these lines, I'm reminded of a few more edge cases:

• The "virtual +2": If I'd be willing to merge the patch from another +2er as-is, but I also want to leave a suggestion for minor improvement, I'll leave the comment and tell the author to feel free to self-merge the patch if they don't want to make further changes, instead of having to wait for me to come back to do it.
• Transient Jenkins errors: I've sometimes self-merged a patch when a previous non-self +2 failed to merge because of some transient Jenkins error, for example when npm occasionally fails to download its packages.
  • I know I've been tempted to do the same if Jenkins failed only because of a conflict in the RELEASE-NOTES file, but I don't recall whether I've ever actually done it. I have sometimes +2ed after doing the needed manual rebase of someone else's patch for RELEASE-NOTES or blatantly obvious documentation typos. Anomie (talk) 18:27, 19 December 2018 (UTC)

I've hopefully covered this now. Rebasing RELEASE-NOTES could count as a trivial change not needing review. Tim Starling (talk) 06:05, 22 January 2019 (UTC)

• puppet and mediawiki-config are mentioned under the heading "Deployment branches", is that a mistake? I imagine for deployment branches (and more generally backports) we'd want to say that self-merging is fine because these patches already passed code review elsewhere.
• I think self-merge after a virtual +2 or real +2 and simple rebase / CI failure is normal and does not contradict the policy as currently phrased (note it talks about self-review, not self-merge).
• To generalize Nikerabbit's last point, what's the difference between someone with +2 self-merging a patch that has been +1-ed by someone without +2, and someone with +2 merging a patch from written by someone without +2? In both cases the code is reviewed by exactly one person who is trusted with and responsible for enforcing conventions etc.etc. and another person who is less trusted. So the arguments given in the self-review section don't fully make sense to me.
  • And then sometimes that leads to merging code written by a less experienced developer that's OK but not great, because directing them through all the necessary changes would take forever and would not be a great experience for either of us, and changing the patch would mean I'd have to find another person with +2.
• "Inline comments can be used to indicate issues with the code that should be addressed before it is merged. Exercising -1 or -2 is just as important as +2." - this should probably be in the previous section, not self-review? Tgr (WMF) (talk) 22:03, 20 December 2018 (UTC)

I removed the bit about -1 being as important as +2, because it seems a bit glib and confusing. Hopefully my change to the language to emphasize code review over merging covers this anyway. That change also hopefully answers your first point. Tim Starling (talk) 06:10, 22 January 2019 (UTC)

puppet and mediawiki-config are mentioned under the heading "Deployment branches", is that a mistake? I imagine for deployment branches (and more generally backports) we'd want to say that self-merging is fine because these patches already passed code review elsewhere.

I was given pause in reading the same bulletpoint. I made a note to myself that perhaps the wording, "In deployment branches and the Puppet repository, changes are merged by the person doing the deployment" could be modified to indicate that self-+2 is common in any repository (or branch within a repository) where +2 indicates deployment rather than review; e.g., Deployment branches, integration changes, puppet repositories.

I don't know how to improve that wording, or whether the wording necessarily needs changes. I will say I did not understand the current wording quickly. TCipriani (WMF) (talk) 20:38, 24 January 2019 (UTC)

> In both cases the code is reviewed by exactly one person who is trusted with and responsible for enforcing conventions etc.etc. and another person who is less trusted

Not really - in both cases the code has been viewed by one who is trusted with and responsible for conventions. But spotting one's own mistakes is a lot harder than spotting other people's mistakes. So I do think it makes sense to require review by another person with +2 rights who is not the author. DKinzler (WMF) (talk) 09:44, 3 January 2019 (UTC)

For some smaller projects, we can be in a situation where only one person has enough knowledge on the project to sensibly do +2, or, even more frequently, only one such person is available (e.g. there may be two but one is on a month-long leave, or buried under urgent workloads, otherwise inaccessible). In this case, if the person who has +2 authors a change, there would be no way to merge it without self-merging. Smalyshev (WMF) (talk) 01:45, 19 January 2019 (UTC)

@Smalyshev, I think that's covered by "For extensions (and other projects) not deployed to the Wikimedia cluster, the code review policy is up to the maintainer or author of the extension". DKinzler (WMF) (talk) 11:05, 2 April 2019 (UTC)

Automatic revocation for staff

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

It is WMF policy to revoke all privileges when staff members depart, even if those privileges were granted prior to the beginning of employment by virtue of volunteer work. Consistent application of this policy helps to protect the privacy of departing staff members: no fault is implied.

Automatically revoking privileges that were given as part of someone's job makes sense. Revoking privileges received as a volunteer seems pretty hostile and not a great way to encourage further volunteer contributions. I don't get the privacy reference at all. Is that about not disclosing the fact that someone might have been fired in a way that makes us not trust them with +2 any longer (and there might be legal restrictions on disclosing even that fact)? Tgr (WMF) (talk) 21:33, 20 December 2018 (UTC)

That seems to have been the argument when that was discussed at User talk:Tim Starling (WMF)/Gerrit group membership policy changes#h-Revocation_when_leaving_WMF-2018-11-29T17:19:00.000Z. I agree with you. Anomie (talk) 23:57, 20 December 2018 (UTC)

> I don't get the privacy reference at all. Is that about not disclosing the fact that someone might have been fired in a way that makes us not trust them with +2 any longer (and there might be legal restrictions on disclosing even that fact)?

Yes, this is indeed the reason. I don't see a good way around this, especially since there is a lot of grey between "fired for bad faith behavior" and "quit because they found a nicer place". DKinzler (WMF) (talk) 09:42, 3 January 2019 (UTC)

Ask people to indicate whether they need the permissions in the future, let them keep it if they do, and suggest people leaving under a cloud that they should let them lapse and spare themselves the embarrassment of being specifically denied. Unless you are considering the situation where the person leaving is not trusted but unaware of it, but in that case you will probably have to deal with it anyway when they re-request them. Tgr (WMF) (talk) 03:14, 4 January 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Phab projects for privilege requests

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Regarding future #MediaWiki-Group-Requests and #Gerrit-Privilege-Requests projects in Phab: phab:tag/repository-ownership-requests already exists (and is often confused with phab:tag/repository-admins, and mw:Gerrit/New_repositories for creating new repositories) so let's please reuse/rename to clarify, as far as possible? AKlapper (WMF) (talk) 18:30, 21 December 2018 (UTC)

We are proposing to rename "repository ownership" to "Gerrit privilege requests". This change in terminology has been made in the draft, and reflects a substantive policy change, so I think it should also be reflected in a change to the Phabricator project. Also, we are proposing to split off requests for access to the MediaWiki group into its own phabricator project, since that was requested in TechCom. Is that clear enough, or would you suggest a different scheme? Tim Starling (talk) 06:20, 22 January 2019 (UTC)

Thanks, sounds good. AKlapper (WMF) (talk) 09:11, 22 January 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Scope?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The document talks mostly about Mediawiki deployment and Mediawiki extensions, but there are more projects in Gerrit than this. I think it should be clarified whether these policies are to apply to them too and then they need to be written in a bit more generic way or just to "big Mediawiki" (i.e. Mediawiki plus extensions plus puppet, etc.) but not other code hosted on WMF Gerrit. Smalyshev (WMF) (talk) 01:40, 19 January 2019 (UTC)

It's intended to apply to all projects that are in WMF Gerrit. There are some bits that are fairly specific to MediaWiki, do you think they should be removed? Tim Starling (talk) 06:14, 22 January 2019 (UTC)

FWIW, I initially had the same reaction, many of the arguments surrounding the importance of +2 make direct reference to the particular configuration of MediaWiki and extensions Gerrit and Jenkins setups.

Putting that aside, the section on merging without code review feels particularly prescriptive; however, it makes the point towards the end:

For extensions (and other projects) not deployed to the Wikimedia cluster, the code review policy is up to the maintainer or author of the extension.

I think I would prefer if that were easier to glean from an inspectional reading of the policy rather than a close reading.

Also, it's important to note that self-merge is common in some repositories (integration/config for instance), and there may be differences between projects in what exceptions there are to merging without code review; however, in these projects, +2 is still "a strong expression of trust", only the expectations are different. TCipriani (WMF) (talk) 20:28, 24 January 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Allow trusted users to be owners of repos

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi, we should allow trusted users (long time/wmf staffers) to be able to be owners of there repos. Paladox (talk) 19:38, 24 January 2019 (UTC)

Bump. Paladox (talk) 18:35, 25 February 2019 (UTC)

I don't think so. Tim Starling (talk) 23:51, 17 March 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Pair Programming Exception

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Under the bulleted exceptions to Merging without review, there is a point that "A commit in Gerrit may have two authors" mentioning "an owner and a reviewer who uploads and amendment"; however, there is no exception for pair programming explicitly. I am not sure how common this is for MediaWiki core and Extensions (cf: scope?), but it is common for several repos I work in.

That is, a patch could be written during a hangout/pairing session between two people, uploaded by one, and merged by the same. As a recommendation, it could contain a Co-Authored-By: snippet in the commit or two Signed-off-by: tags. TCipriani (WMF) (talk) 21:02, 24 January 2019 (UTC)

Isn't there a risk that pair-programmed code suffers from the same individual "group" think that we worry about for sole-author patches? Do we want to encourage the practice of pair-programmed code being merged by one of said pair? Jdforrester (WMF) (talk) 21:36, 24 January 2019 (UTC)

I think code review and pair programming both ensure that two people understand and endorse a particular patch. I view pair programming as a real-time review of code being written, whereas code review is asynchronous.

I think code review and pair programming are both equally subject to groupthink and/or power inequalities. I am unsure if one is more so than the other. TCipriani (WMF) (talk) 22:50, 24 January 2019 (UTC)

I agree that pair programming is kind of a live review process. There is no good way to represent shared authorship on gerrit, so one person should upload the patch, and the other can approve it right away. MAybe it would be nice to mention the fact that the patch was done in a pair programming session, but I don't think it's necessary.

In any case, the fact that there were "four eyes" on the code should be documented on gerrit. That's the essential part. DKinzler (WMF) (talk) 11:12, 2 April 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

mediawiki/extensions.git submodules additions/removals

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Can we continue to self-merge this kind of changes? Given that mediawiki/extensions.git changes mostly involve adding or removing submodules to track newly added or archived extensions, can I consider this, in light of this new policy, that this qualifies as trivial to self-merge? (exception for the python and shell files which do indeed require review and I wouldn't self-merge). It looks (and thus why I've been doing that) that most patches are self-merged there when it's just adding or removing a submodule as it's purely routine. Thanks.

Edit: other cases I need to self-merge is to when I am creating a new Gerrit repo or adjusting its permissions. —MarcoAurelio (talk) 12:03, 13 March 2019 (UTC)

If you're doing it already and nobody cares, it's probably fine. The section on self merging is merely descriptive of the current situation. It has plenty of wiggle room to allow things that are happening already.

I also want to emphasize that we're not going to suddenly revoke +2 access of a valued contributor for violating some narrowly interpreted clause in the policy. I can't speak for all situations or all committee members, but if someone complains that you shouldn't be doing a particular variety of self merges, the obvious outcome of that is to ask you to stop doing it.

The policy defines an escalation path for complaints which allows them to be handled with common sense and without needless public humiliation. Tim Starling (talk) 23:48, 17 March 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Clarify reference to "Gerrit Administrators"

The policy currently refers to "Gerrit Administrators" as being responsible or empowered to perform certain actions by this policy. It would however be more useful to associate these powers and responsibilities with gerrit permissions rather than a specific group, allowing the granularity of groups and permissions on gerrit to be improved as discussed on phab:T219012#5057232.

I propose to replace all references to "Gerrit Administrators" with "people with the necessary permissions on gerrit", (or an equivalent but less clunky phrase). DKinzler (WMF) (talk) 10:36, 2 April 2019 (UTC)

On one side there is the administration of the Gerrit software itself. That is the Administrators built-in group in Gerrit which is https://gerrit.wikimedia.org/r/#/admin/groups/1,members This is the equivalent of having read/write access everywhere (disk or database).

On the other hand, the Gerrit Managers group https://gerrit.wikimedia.org/r/#/admin/groups/119,members is for administration of policy / access lists / repositories etc. It is less privileged than the administrators of the software itself, but is still a very large set of permissions. The group was originally named Project and Group Managers but got renamed to Gerrit Managers in Feb 2018 by https://gerrit.wikimedia.org/r/plugins/gitiles/All-Projects/+/10107cf5056eb6ef3903f49d59cd27387831c5b5%5E%21/#F0 It is semantically broader and might be confusing :D Antoine "hashar" Musso (talk) 11:26, 2 April 2019 (UTC)

I think changing it to "Gerrit Managers" would be the most reasonable change. Jdforrester (WMF) (talk) 15:38, 2 April 2019 (UTC)

> I think changing it to "Gerrit Managers" would be the most reasonable change.

It sounds reasonable, but in T219012 there is talk of creating a mediawiki-administrators. And further groups may be created in the future, for other repos, or with different rights.

This is why I want to avoid any group names in the policy. The policy should apply to whoever has the respective rights.

DKinzler (WMF) (talk) 17:12, 2 April 2019 (UTC)

Then call it "the 'Gerrit Managers' group of individuals, or whatever it's called this week". Let them bike-shed in peace. Jdforrester (WMF) (talk) 17:36, 2 April 2019 (UTC)

The link that is currently on the page links to https://gerrit.wikimedia.org/r/#/admin/groups/1,members which is not very helpful. Should it be removed or changed to something else? Nikerabbit (talk) 17:43, 13 May 2019 (UTC)

I believe the current group is https://gerrit.wikimedia.org/r/admin/groups/119,members. Jdforrester (WMF) (talk) 17:48, 13 May 2019 (UTC)

Gerrit Managers can change group membership only for groups they own, which is only 201 groups out of 1630. I volunteered to update the policy to say that Gerrit Managers can change groups, but I'm not going to do that when it's not true. 201 is suspiciously close to a round number, is it possible that someone tried to edit all the groups to be owned by Gerrit Managers but it failed due to a batch size limit? If I do the following query on the Gerrit database:

select group_id,name,owner_group_uuid='93b1e277b72d0e0a883afbc0a87948dd6dd0d7b7' as managed from account_groups where name like 'extension-%';

I get 1022 such extension-specific groups, of which 118 are owned by Gerrit Manager. The groups owned by Gerrit Manager are not contiguous when sorted by ID, UUID or name. Tim Starling (talk) 21:21, 18 September 2019 (UTC)

Uh, that does sound odd...

I think the policy should just say "whoever has the permission to do it". DKinzler (WMF) (talk) 23:32, 18 September 2019 (UTC)

How about we make all groups be owned by Gerrit Manager? Then we will actually be able to explain who has the ability to do this. Tim Starling (talk) 01:36, 19 September 2019 (UTC)

I thought the idea was that no single group should have all the power, for security reasons. Wasn't that why the Administrators group was changed, after we had vandalism on Gerrit? DKinzler (WMF) (talk) 09:28, 19 September 2019 (UTC)

No. The built-in Administrators group has powers that shouldn't generally be wielded, and which we can't remove or restrict (but would almost never need to use). The idea was to reduce the number of accounts with world-ending powers; it wasn't related to the kinds of actions this policy covers. Jdforrester (WMF) (talk) 15:44, 19 September 2019 (UTC)

So Gerrit Manager should indeed own all groups? DKinzler (WMF) (talk) 16:55, 19 September 2019 (UTC)

However Gerrit Managers don't have the ability to add people to the MediaWiki group. If you go with Gerrit Managers, we should also empower them to add/remove people from there or leave things as they are and let the LDAP group gerritadmin people to add people to the mediawiki group as it happens now AIUI. —MarcoAurelio (talk) 09:53, 22 September 2019 (UTC)

Specify application process for people who have been denied or lost privileges in the past

On phab:T218135, Leszek raised the question of trusted orgs requesting access for people who had requested but had been denied merge rights in the past, as well as people who have held but lost merge rights in the past.

I propose to amend the policy to state that gerrit admins(*) should be advised to not use the "abridged" process without community discussion for people who have been denied before or lost privileges. Trusted orgs should, to the best of their knowledge, inform gerrit admins about such cases.

There is one case for which this would be annoying, though: people who lost their privileges per default, due to their contract or employment ending. It would be nice if they could be exempt from this rule, but that problematic as well: The policy requires privileges to be revoked per default so no information is exposed about whether the revocation happened due to any fault. So there might indeed have been an issue, we can't know.

I cite myself as an example: had this policy been in place when I left WMDE and joined WMF in October, I would have lost all privileges per default, and, with this amendment, would have to go through a community discussion before re-gaining them. Perhaps that could have been avoided if the gerrit admin in question had checked back with WMDE to ensure that there were no trust issues with me re-gaining the privileges. That however raises the question whether it would be legal for WMDE to share information about any issues I might have had working there, or the reasons for leaving.

(*) "admins" being gerrit users who have the necessary permissions to grant or revoke privileges. DKinzler (WMF) (talk) 10:51, 2 April 2019 (UTC)

! [remote rejected] HEAD -> refs/changes/79/550379/2 (cannot add patch set to 550379.)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

(transplanted from https://www.mediawiki.org/w/index.php?title=Topic:Vayass3b7l22mjxt&topic_showPostId=vayn7p2ps4ofdpkl&fromnotif=1&markasread=1034884&markasreadwiki=mediawikiwiki#flow-post-vayn7p2ps4ofdpkl)

Who can amend other's changes? How to deal with the message above the best way? « Saper // talk » 09:35, 12 November 2019 (UTC)

Hi @Saper,

changes (in this case patches) which are not your, can't be amended by you or me. Only by original uploader or user which have +2 in related repository.

Best regards,

Zoran. Kizule (talk) 16:59, 17 November 2019 (UTC)

@Saper Please try again. I made something. —MarcoAurelio (talk) 17:26, 17 November 2019 (UTC)

@MarcoAurelio thanks, what has changed? The original change got merged, but I tried this on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/118981 (not sure how it works, since previously I have participated in this).  « Saper // talk »  23:11, 18 November 2019 (UTC)

@Saper What Zoran mentioned above is true. Due to abusive use in the past of the ability to add patch sets to the work made by others, this ability is now restricted to patch owners, repository owners and members of some gerrit groups. This includes a group called Trusted-Contributors. I added you yesterday to test if my lecture of the gerrit permissions was right. I have removed you for now from said group because with this new Gerrit Privilege Policy in place it looks each and every Gerrit permission must be discussed and approved in advance. I have filed phab:T238649 requesting that you be formally added. Sorry for the bureaucracy, but it looks those are the rules now. I hope it won't take long to have you formally approved. Best regards. —MarcoAurelio (talk) 11:39, 19 November 2019 (UTC)

Thanks... the policy says nothing about "trusted users" so I was a bit baffled if this is a glitch or intentional thing. Thank you again - will follow on Phab!  « Saper // talk »  21:29, 19 November 2019 (UTC)

The policy is not quite clear for me in what a "privilege" is or how that should be interpreted. I opted to follow the safests of the paths. If the discussion results in that there's no need for Tasks to add people to that group, I'll be more than happy to follow that consensus. Regards. —MarcoAurelio (talk) 13:43, 20 November 2019 (UTC)

@MarcoAurelio I appreciate your approach and the efforts. It worries me that this has become so burdensome. So much for "attracting new developers to the project" etc. etc. Although I am a pretty old one :)  « Saper // talk »  11:20, 22 November 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

How to get added to "Trusted Contributors" on Gerrit?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Cannot find that term on this page. File a ticket under https://phabricator.wikimedia.org/tag/gerrit-privilege-requests/ ? Some other way? Brought up in PS6 on https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/574865/. AKlapper (WMF) (talk) 16:31, 14 May 2020 (UTC)

Hello. I opened a discussion on Phabricator regarding this subject on January 2020. You can see it at https://phabricator.wikimedia.org/T238651. Regards. —MarcoAurelio (talk) 18:30, 14 May 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Email address to reach all gerrit admins

Hello,

I have since retired from development so this does not affect me much, if any, nowadays. But in the past, each time I was in need to request something to the gerrit administrators (mostly settings, or when clerking on MediaWiki +2 granting/removal Tasks) there was no easy way to reach the Gerrit administrators as a group; so I had to send some emails here and there until someone replied; which made me feel rather bad as I felt I was always putting the burden on the same couple of people that were responsive.

Given that now -and since some time- Gerrit adminship is managed through an LDAP group, I was wondering if we could create an email alias (EXIM? Wikimedia Google group?) such as "gerritadmin[at]wikimedia[dot]org" and subscribe all Gerrit Administrators there (except the bot I guess) so in case anyone needs an admin there's an easy way to reach 'em all through a single email to a single place.

I think that a gerritadmin[at]wikimedia[dot]org address exist or existed per phab:T54150 and got deleted per phab:T220843. If I remember rightly, I discussed the idea briefly with Hashar or Tyler a while ago in the RelEng channel. I can't remember. The later task also mentions a gerrit-admin[at]... address too.

Thanks. —MarcoAurelio (talk) 19:55, 2 December 2020 (UTC)

Scope of "Requesting Gerrit privileges" secion

It seems common sense that the section would only apply to code in Wikimedia production, just like the +2 policy, but the text doesn't actually say so. Could that be clarified? We don't want to force people to go through Phabricator privilege requests for repos under labs/tools (Toolforge), for example. Tgr (WMF) (talk) 04:33, 16 December 2020 (UTC)

On Gerrit/Privilege_policy#Requesting_Gerrit_privileges it says that "To request membership in another group, create a new task under the Gerrit-Privilege-Requests project in Phabricator", "If there is a consensus of trusted developers on the Phabricator task, any of the Gerrit administrators can resolve the request" and "Gerrit administrators should not grant repository ownership to ordinary developers". Labs/Cloud is not part of Gerrit/Privilege_policy#Expedited_process_for_trusted_organisations and in light of Talk:Gerrit/Privilege policy#h-Allow_trusted_users_to_be_owners_of_repos-2019-01-24T19:38:00.000Z as well, it looks to me that (common sense or lack thereof) all access requests shall go through a Phab task. —MarcoAurelio (talk) 12:28, 16 December 2020 (UTC)

Wikimedia Technical Committee

Should this be changed to the new body? wargo (talk) 21:46, 15 April 2024 (UTC)

If we had a new technical standards setting/reviewing body to change it to that would be excellent. BDavis (WMF) (talk) 22:01, 15 April 2024 (UTC)

Technical decision making/Forum? wargo (talk) 22:11, 15 April 2024 (UTC)

That group has no met for about a year now... Technical decision making/Technical Decision-Making Process Retrospective and Consultation plan BDavis (WMF) (talk) 22:14, 15 April 2024 (UTC)

As Bryan Davis said, the committee has been disbanded a few years ago without a replacement body and the forum is not quite the same. Last July 2023 a group was formed to analysis the forum and they have published their report yesterday:

• announcement: https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/message/VF47G6YTYRDUQTNTGOY4YPZDV7PUB5TH/
• report: Technical_decision_making/Technical_Decision-Making_Process_Retrospective_and_Consultation_plan/Retrospective_and_Consultation:_Results_and_Analysis Antoine "hashar" Musso (talk) 06:21, 24 April 2024 (UTC)

Require a wikitech-l email for +2 nominations for Wikimedia deployed extensions

Right now the policy only requires a wikitech-l email for requests for mediawiki/* +2 rights. I think we should expand that requirement to all Wikimedia-deployed MediaWiki code, as that access is sensitive enough so that requests should be seen by the wider developer community and not just the people who happen to follow the Gerrit privilege request tag. An email to wikitech-l has been sent for the past couple of such requests and I think it's worked fine. Taavi (talk!) 11:00, 20 April 2024 (UTC)

This seems pretty reasonable. In the case of Wikimedia-deployed extensions that have no real stewards, I'd imagine a similar level of engagement as we get on the tasks (little to none), but there's a better chance of running into the request via email vs the privilege request board. Opening that to broader discussion/same vetting period seems like a good way to approach this. +1 from me. TCipriani (WMF) (talk) 18:41, 23 April 2024 (UTC)

Proposal: Lack of consensus for privilege in "other" group, send an email to wikitech-l

There is a problem when no consensus is reached for a request. The policy states that the next step is to refer the matter to TechCom. As noted elsewhere on the talk page, there is no current TechCom equivalent.

This is rarely a problem for privilege requests to mediawiki since the email to wikitech-l is usually sufficient to spur discussion on a task that is unambiguous in its recommendation.

This is a problem for requests to other groups because there may be no discussion whatsoever on the phabricator task.

It could be argued that this is a negative endorsement; however, for abandoned extensions, it may be that few are paying attention.

I'd like to amend the policy to direct people to email wikitech-l in the case that there is no feedback on a task requesting privileges in a non-mediawiki group within the two week period tasks must remain open. And in the case that no objections are raised, to grant the privilege (fail to open). TCipriani (WMF) (talk) 15:35, 24 September 2024 (UTC)

I'd like to amend the policy to direct people to email wikitech-l in the case that there is no feedback on a task requesting privileges in a non-mediawiki group within the two week period tasks must remain open. And in the case that no objections are raised, to grant the privilege (fail to open).

Should this still be restricted in some way to "known contributors" with some history of activity on the projects, or at least some clear history of participation in the broader FOSS community? BBearnes (WMF) (talk) 18:16, 24 September 2024 (UTC)

> Should this still be restricted in some way to "known contributors"

@BBearnes (WMF) are you thinking about this as a way to slow down things like the XZ Utils supply chain attack or do you see other justifications for limiting who an abandoned project is passed on to?

I feel personally pretty torn between wanting to help anyone who is motivated to support an otherwise unsupported extension/skin/library/tool and wanting the downstream folks who use that software product to be able to trust that the software will not become malicious. Hopefully it it obvious that in an ideal world we would get both outcomes from every decision. When we are talking about attempts to adopt code where nobody has been able to make contact with the original authors I think that in the abstract I would support any maintainer over no maintainer, but I'm not sure how to condense that feeling into a scoring rubric of some sort for evaluating requests. BDavis (WMF) (talk) 20:09, 25 September 2024 (UTC)

Yeah, that was pretty much my thinking. I guess I feel like "any maintainer who's not gonna (for example) backdoor unsuspecting users", but I too am unsure how to most usefully set up rules that best help ensure that. BBearnes (WMF) (talk) 20:54, 25 September 2024 (UTC)

If a repo is truly abandoned enough for nobody to care then it probably doesn't have any users checking the repo specifically (as opposed to checking the MediaWiki.org page which could be edited by anyone to point to a backdoored repo). * Pppery * _{it has begun} 21:16, 25 September 2024 (UTC)