Also wondering who to review/discuss/perform actions like adding repos to a group (see T273927) in the future...

• We need someone on the team to join the Gerrit admin group (?) to be able to hand out +2.
• We need to update the docs on-wiki.
• Optional: Review criteria to get +2, e.g. non-trivial contributions.
• When does our scope end? See previous comment.

Update:
As the Wikimedia Technical Committee (TechCom) has been superseded by the Technical Decision Forum, the Developer Advocacy team now owns the process of handling Gerrit+2 permissions.

In a recent meeting the Developer-Advocacy team discussed whether some team members should become members of the Gerrit admin group solely to hand out +2 in case of successful proposals/applications. We decided that it's against the principle of least privilege.

We had a quick sync with Tyler of WMF's Release-Engineering-Team. To paraphrase: Proposal is to (continue to) use the Gerrit-Privilege-Requests workboard which has some Gerrit admins watching it, and to tag both Release-Engineering-Team and Gerrit-Privilege-Requests on such requests.
The current shared "SLA" understanding is that we'd like to handle positive proposals within approximately two weeks.

Developer-Advocacy will have to more closely monitor tasks on that board, and regularly discuss and follow up on open +2 proposals.
It would also be up to Developer-Advocacy to reach out for further input on +2 proposals.

In T273164#6867044, @Aklapper wrote:

Update:
As the Wikimedia Technical Committee (TechCom) has been superseded by the Technical Decision Forum, the Developer Advocacy team now owns the process of handling Gerrit+2 permissions.

...decided by who?

Hey @Legoktm Not all of TechCom’s former responsibilities - or perceived responsibilities - are routed through the new Tech Decision Forum. One of these is the Gerrit Privilege Policy. Those types of decisions are listed in the technical decision type matrix, along side with new responsible parties. “Ownership” means that the team is responsible for ensuring process continuity for Gerrit Privilege requests in the post TechCom world, and to step into TechCom’s former role where required. Handling privilege requests is in most of the cases a self-running system supported by many - Gerrit Privilege policy applies. This ticket explores what needs to be done to make sure the process always works - I.e. in cases where there is not enough input, or not a clear outcome, or when no one acts on a positive decision (which I’d assume, is seldom the case, but we should plan for it regardless). The other aspect that needs discussion is which process we should establish for making changes to the Gerrit Privilege Policy in the future.

In T273164#6875449, @Bmueller wrote:

Those types of decisions are listed in the technical decision type matrix, along side with new responsible parties. “Ownership” means that the team is responsible for ensuring process continuity for Gerrit Privilege requests in the post TechCom world, and to step into TechCom’s former role where required.

Thanks for clarifying, I had read that part and thought it was examples ("Below are typical decisions from the existing RFC process..."), not explaining who the new owners are.

• Also see the proposal to add a sentence for new WMF staff in https://phabricator.wikimedia.org/T277797#6938491

The lack of progress in this task blocks slows down development work, see e.g. T286084.

T237618 should probably also get looked at and resolved when working on this

See also T313399#8110051 for lack of process how to add a trusted organisation. I'm repeating myself saying that this task unresolved for 18 months slows down development.

Per confusion in T314061, docs could also clarify that going for LDAP-Access-Requests is the way to go in case that +2 is wanted by a member of a trusted org.

In T273164#8127289, @Aklapper wrote:

See also T313399#8110051 for lack of process how to add a trusted organisation. I'm repeating myself saying that this task unresolved for 18 months slows down development.

I concur, especially for new extensions in early stages of development and not currently deployed, it feels there is an unnecessary inflexibility in the process.

Its also not clear what the process should be for contractors access to places like core.

A company like ThisDot who has been actively supporting MediaSearch, Design systems and Abstract Wikipedia with our have clearly built up enough credibility to warrant the designation.

I drafted a Gerrit Privilege Policy amendment in https://www.mediawiki.org/wiki/User:AKlapper_(WMF)/T273164 .
It replaces non-existing TechCom (T273164) with Developer Advocacy; picks up amendment proposals in T237618 (cover corner cases, remove ambiguity), defines "Trusted Developers", covers cases in T273927/T314061/T313399, adds links to relevant docs, and involves Release-Engineering-Team when appropriate.

Full diff (minus the {{Draft}} header in line 1):
https://www.mediawiki.org/w/index.php?title=User%3AAKlapper_%28WMF%29%2FT273164&type=revision&diff=5404150&oldid=5403859

"Amendments to this policy must be approved by the CTO, in consultation with TechCom." The latter does not exist anymore. (Main reason why this task exists.)
@mseckington / @Bmueller: What's next? Someone to contact WMF CT(P)O and ask for documented approval of this amendment, e.g. public comment in this task? Amendment section does not imply an announcement to e.g. wikitech-l; I'd say a heads-up (before or after?) to wikitech-l is welcome and good to have.

(PS: I also boldly updated the header in https://www.mediawiki.org/w/index.php?title=Template%3ADevelopment_policy&type=revision&diff=5404107&oldid=5007679 . And updated the description of MediaWiki-Gerrit-Group-Requests at https://phabricator.wikimedia.org/project/manage/3956/ that WMF staff shall use LDAP access requests instead.)

In T273164#6875449, @Bmueller wrote:

Those types of decisions are listed in the technical decision type matrix

For the records, hat link is now https://www.mediawiki.org/wiki/Technical_decision_making/Background#Decision_type_matrix

Hi @Bmueller, could you please provide a status update here? Thanks in advance!

My apologies for the delayed update. As a next step, we'd like to document how we use the policy in practice—e.g., looking at stalled cases—to inform potential policy updates before getting this to the CTPO for review and approval. If folks have thoughts on that, input is welcome!

In my understanding this is currently blocked on conversations in the subtask thus punting

Adding project tag so this task shows up on a workboard

Lack of progress on this task bit us again in T372073#10138127 - a volunteer would like to take over maintainership of an unmaintained non-deployed Gerrit repository while https://www.mediawiki.org/wiki/Gerrit/Privilege_policy#Requesting_Gerrit_privileges is ambiguous about this and still instructs to pass such a situation to a non-existing body (TechCom).

To share some additional long forgotten, non-documented context:

• I remember that @mseckington told me in May 2022 that she planned to followup with @Bmueller on the next steps.
• Then this topic ended up in the FY2022/23 plan for the (now de-funct) "Technical Engagement" WMF team as "Objective: Clarify responsibilities around Gerrit privilege handout workflow".
• At some point in 2022 due to lack of progress I had also drafted https://www.mediawiki.org/wiki/User:AKlapper_(WMF)/T273164 which turned out to be too naive. :)
• Then two meetings took place about this topic (and related T237618: Amendments to the Gerrit Privilege policy) in late 2022. Meeting notes are available.
• After that, I am not aware of tangible outcomes or followups on this past WMF annual plan goal.

Also giving a heads-up to @Lferreira.

A random example how to announce a (different) policy change on the wikitech-l list can be found here.