Taking this bug.

Code review: https://gerrit.wikimedia.org/r/#/c/11150/

Q. What rights will be included in the 'Patrollers' group?

A. Have one's own edits automatically marked as patrolled (autopatrol)

Mark others' edits as patrolled (patrol)
Quickly rollback the edits of the last user who edited a particular page (rollback)

Q. What this will change about add/remove groups?

A. Here the add/remove rights change:

Administrators

• Add groups: Autopatrollers and IP block exemptions

+ Add groups: Autopatrollers, IP block exemptions and Patrollers

Bureaucrats

• Add groups: Autopatrollers, Administrators, Bureaucrats and Bots

+ Add groups: Autopatrollers, Administrators, Bureaucrats, Bots and Patrollers

• Remove groups: Autopatrollers and Bots

+ Remove groups: Autopatrollers, Bots and Patrollers

You would maybe be interested by this discussion on Wikimedia Commons to grant the abusefilter-log-detail right to the patroller group:

(1) The problem and the idea:
https://commons.wikimedia.org/w/index.php?oldid=66349249#Abuse_filter_log_details

(2) The local consensus:
https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=68945723#Right-change:_Patroller

(3) The bug report:
bug #35545

Removing 'shell' keyword, adding 'shellpolicy' to get more community input.

I would like feedback to know:

• if it's or not a good idea to allow a project to get a "super subadmin group"
• if it's not symptomatic of an idealized sysop vision
• if it's not dangerous considering the recent hi. situation.

An alternative solution would be to create two patroller and rollback distinct groups.

It's the solution deployed on the following 12 wikis: bs.wikip, commons., en.wikt, es.wikt, fa.wikip, fa.wikinews, fi.wikip, ml.wikip, simple.wikip, sr.wikip, uk.wikip and zh.wikip.

(Thank you to bennylin for the suggestion)

From the dev's side, it would be easier to implement (doesn't need to create a new group which has patrol and rollback rights), and from the nn.wiki side, the crats (and admins) can give the rollback right as a package.

What I'm not sure, though, is that nn.wiki is actually asking for rollbacker right, and not patroller right (as per title), is that correct?

From the dev side (well.. as it's a configuration issue, more exactly the ops side), it's the exactly the same cost: in both case, we've to add a line in the config file for every custom groups. There are not "patroller" or "rollbacker" templates, there are customized to tailor the needs of each wiki.

The rollback right has been asked by Chistoffer in his bug report (see Description, the "first" comment). There is a reference to this rollback add in the local debate: "I tillegg til å patruljera, kan patruljørane rulla attende endringar og verta meir effektive enn vanlege brukarar i kampen mot vandalisme.".

chstole wrote:

Not everyone that wants to be able to patrol recent changes wants to be admins, and thus introducing the patroller group can make the patrolling more efficient as we can get more patrollers that way. As long as the rollback function is the *only* way of marking several edits as patrolled in one go, it is crucial to make the patrolling more efficient with patrollers. It also saves the patrollers from many manual reverts.

The abuse filter is not used very much on the nn.wiki; in fact I am the only user to have even as much as touched it; so I think we can safely skip that part for now.

Regarding the "super subadmin group"; the setup here is supposed to be copied from the nb.wiki, their patrollers also have the ability to roll back edits, see here: https://bugzilla.wikimedia.org/show_bug.cgi?id=11509

As a general statement, if a user is deemed trustworthy enough to mark edits as patrolled, why should he not be entrusted with the rollback function?

Concurrently to bennylin analysis, I looked the discussion on nn.wikipedia.

Their exchanges were constructive, and the reserves we could have have been discussed there, so the community knows what it does.

There isn't real rationale against to give a rollback right to patrollers if the community wants it, as this tool (i) could be emulated in a javascript gadget (ii) has a similar level of trust than patrolling (and in this I totally agree with the Christoffer last question).

[ Removing 'shellpolicy' and removing the code review -1 flag. Adding 'shell' keyword. ]

I have deployed the change on the live cluster.