@Janabaevazizbek Please note that, per standardization, the "closer" usergroup doesn't exist on WMF wikis, and (looking at the flags) it should be called 'pagemover' (not 'mover', since you didn't ask to add 'movefile' too). Also, who should be able to add and remove users in these usergroups? Thanks

In T410121#11374209, @Superpes15 wrote:

@Janabaevazizbek Please note that, per standardization, the "closer" usergroup doesn't exist on WMF wikis […]

Maybe I'm missing something, but couldn't we create it? :p

In T410121#11374249, @A_smart_kitten wrote:

In T410121#11374209, @Superpes15 wrote:

@Janabaevazizbek Please note that, per standardization, the "closer" usergroup doesn't exist on WMF wikis […]

Maybe I'm missing something, but couldn't we create it? :p

yes it can be created, but it would convenient if they use available Usergroup instead of creating new user group

Indeed it would be slightly simpler to use an existing group (if I understand correctly, due to the fact that it wouldn't require an additional patch to WikimediaMessages to add the new group's system-messages).
However, personally, I am just very much not sure about the idea of overriding (what's been conveyed as) the wiki's wishes here just because the 'closer' group hasn't previously been added for another WMF wiki.

On the subject of the request itself, a couple of notes:

• As far as I can tell from looking at a machine-translated version of the on-wiki discussion (and of the linked project page), the autopatrol, move & suppressredirect rights haven't been mentioned onwiki.
• From looking at those pages, it seems like the proposal might have been for the new closer group to be able to delete pages; however, (e.g.) the delete right isn't currently requested in this task.

@Janabaevazizbek, is there anything that I'm missing here?

In T410121#11374294, @A_smart_kitten wrote:

Indeed it would be slightly simpler to use an existing group (if I understand correctly, due to the fact that it wouldn't require an additional patch to WikimediaMessages to add the new group's system-messages).
However, personally, I am just very much not sure about the idea of overriding (what's been conveyed as) the wiki's wishes here just because the 'closer' group hasn't previously been added for another WMF wiki.

I'm not saying this because it's simpler, I don't care about doing another patch and update sys-messages, we are actually trying to use some standard in config patches. There are projects that ask for certain private wikis or certain mailing lists and the names are changed by the deployers according to the currently used standards. I'll never oppose the community will, but there are still some practices to follow here, and obviously the sysadmins always have the final say on this matter. Please also note that adding a special usergroup in "small wikis" is a kind of change included in the "likely to be declined" list.

Also, another valid point, I see the request was made on wiki on January 2025 and last comment was posted over 5 months ago... Any specific reason why the task was only opened today?

In T410121#11375110, @Superpes15 wrote:

Also, another valid point, I see the request was made on wiki on January 2025 and last comment was posted over 5 months ago... Any specific reason why the task was only opened today?

Usually, experienced sysops (kywiki) would handle the task, but I think the sysops either didn't have an attempt at "Phabricator" or didn't want to do it. When a user opened the topic yesterday, I took on the task.

In T410121#11374209, @Superpes15 wrote:

@Janabaevazizbek Please note that, per standardization, the "closer" usergroup doesn't exist on WMF wikis, and (looking at the flags) it should be called 'pagemover' (not 'mover', since you didn't ask to add 'movefile' too). Also, who should be able to add and remove users in these usergroups? Thanks

The user who initially proposed creating these user groups on the Kyrgyz Wikipedia is Mirzoulug'bek. He is also known for his active and successful work on the Uzbek Wikipedia. He likely wanted a similar structure to the one used there to be implemented on Kywiki as well. I am simply serving as a bridge in this process.

Thanks! I fully understand, but this doesn't not reply the questions. Should we ping Mirzoulug'bek, asking them to intervene here? On uzwiki an 'eliminator' group exist (but with only delete flag and nothing more). I don't know why in this task it was asked for an usergroup with the same flags as movers!

In T410121#11375212, @Superpes15 wrote:

Thanks! I fully understand, but this doesn't not reply the questions. Should we ping Mirzoulug'bek, asking them to intervene here? On uzwiki an 'eliminator' group exist (but with only delete flag and nothing more). I don't know why in this task it was asked for an usergroup with the same flags as movers!

The page at https://w.wiki/G4kH
made me realize that users in this group only have the right to delete pages. Therefore, instead of the previously listed ‘move’ and ‘suppressredirect’ permissions, this group should only have the ‘delete’ right.

Gotcha! So they should be 'rollbacker' and 'eliminator'! @Janabaevazizbek Could you please edit the task description to fix the wrong usergroup and replacing 'autopatrolled - move - suppressredirect' with 'delete'?

In T410121#11375441, @Superpes15 wrote:

Gotcha! So they should be 'rollbacker' and 'eliminator'! @Janabaevazizbek Could you please edit the task description to fix the wrong usergroup and replacing 'autopatrolled - move - suppressredirect' with 'delete'?

Done!

In T410121#11375546, @Janabaevazizbek wrote:

Done!

Thanks!
Can you confirm if I read correctly and both flag should be assignable and revokable by sysops?

In T410121#11375654, @Superpes15 wrote:

In T410121#11375546, @Janabaevazizbek wrote:

Done!

Thanks!
Can you confirm if I read correctly and both flag should be assignable and revokable by sysops?

Confirmed!

Since it was not specified in the discussion, I won't add autopatrol to rollbackers, so, when a new rollbacker is flagged, you should keep autopatrol. In any case, using the rollback button will result in an already aupatrolled revert, because this is how rollback works. Thanks :)

Change #1205428 had a related patch set uploaded (by Superpes15; author: Superpes15):

[operations/mediawiki-config@master] [kywiki] Add new rollbacker and eliminator usergroups on kywiki

https://gerrit.wikimedia.org/r/1205428

In T410121#11376481, @Superpes15 wrote:

Since it was not specified in the discussion, I won't add autopatrol to rollbackers, so, when a new rollbacker is flagged, you should keep autopatrol. In any case, using the rollback button will result in an already aupatrolled revert, because this is how rollback works. Thanks :)

Could you tell me more?

In T410121#11376622, @Janabaevazizbek wrote:

Could you tell me more?

If you want to grant rollbacker flag to an already autopatrolled user, you should keep autropatrolled, that's it! Rollbacker flag only add rollback and not autopatrol flag (as per onwiki discussion that did not mention any other right) :)

In T410121#11375003, @Superpes15 wrote:

Please also note that adding a special usergroup in "small wikis" is a kind of change included in the "likely to be declined" list.

Hmm, this is true. Thank you for pointing this out (and apologies for having the reason behind your previous comment wrong)./gen
I guess personally (as a non-sysadmin volunteer), I currently wouldn't know how to fully interpret/apply what's written there (about new-user-group-requests) with respect to a specific task, though. …which makes things difficult, given that AFAICS it's primarily non-sysadmin volunteers who currently handle tickets like this :/
Maybe other folks find it easier to interpret than me, though

In T410121#11374209, @Superpes15 wrote:

[...] the "closer" usergroup doesn't exist on WMF wikis

(also, for what it's worth -- for some reason I didn't notice this earlier, but a closer group does exist on itwikinews & ruwiki)

In T410121#11377251, @A_smart_kitten wrote:

I currently wouldn't know how to fully interpret/apply what's written there (about new-user-group-requests) with respect to a specific task, though

I think it just takes a little common sense, and you'll always find a compromise. I've sometimes rejected extendedconfirm and the intermediate protection (extendendconfirm) in small projects that might have had in practice only one or two similar scenarios, but finding a middle ground can help (for example, adding the autopatrol flag or changing the autoconfirm settings). If in doubt, just contact a sysadmin; I'm fortunate in this regard, because my onwiki experience with small projects helps me a lot. The important thing is to always ask for other opinions to be sure you don't make a mistake.

(also, for what it's worth -- for some reason I didn't notice this earlier, but a closer group does exist on itwikinews & ruwiki)

Oh my bad, I only checked WikimediaMessages, I'll add asap a message for this group too (or maybe we'll merge it with eliminator) as per T139246... Thanks for pointing this out!

Change #1205428 merged by jenkins-bot:

[operations/mediawiki-config@master] [kywiki] Add new rollbacker and eliminator usergroups

https://gerrit.wikimedia.org/r/1205428

Mentioned in SAL (#wikimedia-operations) [2025-11-18T14:17:05Z] <esanders@deploy2002> Started scap sync-world: Backport for [[gerrit:1205428|[kywiki] Add new rollbacker and eliminator usergroups (T410121)]], [[gerrit:1205443|[dewiki] Enable SandboxLink extension (T410199)]]

Mentioned in SAL (#wikimedia-operations) [2025-11-18T14:22:52Z] <esanders@deploy2002> superpes, esanders: Backport for [[gerrit:1205428|[kywiki] Add new rollbacker and eliminator usergroups (T410121)]], [[gerrit:1205443|[dewiki] Enable SandboxLink extension (T410199)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-11-18T14:27:57Z] <esanders@deploy2002> Finished scap sync-world: Backport for [[gerrit:1205428|[kywiki] Add new rollbacker and eliminator usergroups (T410121)]], [[gerrit:1205443|[dewiki] Enable SandboxLink extension (T410199)]] (duration: 10m 52s)