Page MenuHomePhabricator

hide mediawiki/wmf sub-groups from the gerrit groups section
Open, Stalled, LowPublicFeature

Description

Why

  • Reduce the amount of noise in the Gerrit groups section.

What

  • If a user is in the mediawiki or wmf group, suppress all minor groups that inherit mediawiki and wmf, such as everything except mediawiki and extension-PageTriage and Trusted-Contributors in the below screenshot:

image.png (377×2 px, 67 KB)

Event Timeline

Chlod subscribed.

No way to do this right now with the existing Gerrit API without downloading a really big amount of data per group, as far as I can tell. This is why this includes all groups in the first place. This needs an upstream change on Gerrit's API (and of course, we have to update to that version of Gerrit when it comes out).

Chlod triaged this task as Low priority.May 7 2025, 12:31 PM
Chlod moved this task from Backlog to Enhancements on the Tool-techcontribs board.

Could do it the hacky way:

if ( groups.mediawiki || groups.wmf ) {
    delete groups.AhoCorasick;
    delete groups.at-ease;
    delete groups.base-convert;
    delete groups.CLDRPluralRuleParser;
    // etc.
}
Novem_Linguae renamed this task from hide mediawiki sub-groups from the gerrit groups section to hide mediawiki/wmf sub-groups from the gerrit groups section.May 7 2025, 4:44 PM
Novem_Linguae updated the task description. (Show Details)

Noting here that it's possible to build an inheritance tree with the Gerrit REST API /groups/{group}?o=INCLUDES option, but this seems to be disabled in Wikimedia Gerrit, because I'm not getting a list of direct included subgroups. It'd be nice if this were enabled, though I'm not an SRE so I have no clue of the ramifications of that. The alternative to this is calling /groups/{group}/group (subgroups) on every single group that we initially get from Gerrit, but that would suck as well since we have to make a lot of requests to Gerrit, even if we started culling detected subgroups before we get their subgroups.

Could do it the hacky way:

if ( groups.mediawiki || groups.wmf ) {
    delete groups.AhoCorasick;
    delete groups.at-ease;
    delete groups.base-convert;
    delete groups.CLDRPluralRuleParser;
    // etc.
}

This is less than ideal, and doesn't consider changes to subgroups. We'll be implementing a continuously moving target with a low yet sustained maintenance burden if we run with this method. I'd prefer not doing this.

Chlod changed the task status from Open to In Progress.Nov 21 2025, 4:08 AM
Chlod claimed this task.

On second thought, either of these would require one request per group anyway. 🤦 Did not think of the request logic that far ahead. I guess that's the only option here if we really want this. Might just add a lot of caching in to prevent a flood of requests.

Chlod changed the task status from In Progress to Stalled.EditedNov 21 2025, 4:49 AM

Putting this on stalled because this can't continue without a Gerrit account with authorization. At the very least, the code does exist now. The /groups/{group}/group endpoint appears to require non-anonymous access (unlike many other endpoints) and will toss you a non-JSON error if you try to make a request without access. I could use my own account but I assume that's discouraged because Gerrit bot accounts are a separate concept and there appears to be a distinction on what threads can be used for user interactive work and bot work. Maybe I should request a Gerrit bot account (with just read-only access) for this? 🤷