Page MenuHomePhabricator

FlaggedRevs does not give sysops the review right
Closed, ResolvedPublic

Description

While looking into T275017, I noticed that FlaggedRevs does not give sysops the review right. Unsure whether that's intentional, but IMO they should have that right, as it's an access level granted by sysops anyway.

Event Timeline

Change 665547 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/extensions/FlaggedRevs@master] Grant sysops review and unreviewed pages right by default

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

Change 666013 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/extensions/FlaggedRevs@wmf/1.36.0-wmf.31] Grant sysops review and unreviewed pages right by default

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

Change 665547 merged by jenkins-bot:
[mediawiki/extensions/FlaggedRevs@master] Grant sysops review and unreviewed pages right by default

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

Change 666013 merged by jenkins-bot:
[mediawiki/extensions/FlaggedRevs@wmf/1.36.0-wmf.31] Grant sysops review and unreviewed pages right by default

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

Mentioned in SAL (#wikimedia-operations) [2021-02-22T12:20:48Z] <urbanecm@deploy1001> Synchronized php-1.36.0-wmf.31/extensions/FlaggedRevs/extension.json: a4cd98e7a581fe18634da05ba04eaf8035023c26: Grant sysops review and unreviewed pages right by default (T275293) (duration: 00m 55s)

This should "fix" some cases when sysops are not able to set pending changes (which also require review right) on some wikis (that's why I backported it). Resolved.

Mentioned in SAL (#wikimedia-operations) [2021-02-22T13:36:19Z] <urbanecm@deploy1001> Synchronized php-1.36.0-wmf.31/extensions/FlaggedRevs/extension.json: a4cd98e7a581fe18634da05ba04eaf8035023c26: Grant sysops review and unreviewed pages right by default (apparently i forgot to rebase the first time, resync; T275293) (duration: 00m 57s)

4 admins of 80 in ruwiki deliberately refused review right, because review interface interferes with them. I think this change shouldn't be released, the system works with current settings more than 10 years and suits everyone.

4 admins of 80 in ruwiki deliberately refused review right, because review interface interferes with them. I think this change shouldn't be released, the system works with current settings more than 10 years and suits everyone.

If ru.wikipedia wishes to change this settings, they can fill a task. Note that due to T275334: Changing user groups from $wgExtensionFunctions no longer works reliably, it's not currently possible to change FR-introduced rights per wiki :/.

In all other cases, sysops already have rights they can grant to others (be it rollback, patroller at other wikis, eliminators, account creators, ...); it makes no sense for flaggedrevs to be an exception.

ukwiki also had a process for existing admins to agree to the new patrolling rules (which were completely different from new page patrol rules) back in June 2012 or so when FR was enabled. It is by design that some admins can potentially lose their editor flag and not be able to patrol. The communities should be notified about this change (perfectly the order should have been the opposite and the change done only after communities agreed). I will create a ticket for ukwiki to explicitly remove the permission from sysop later.

The logic "sysops can grant those rights, therefore they should have them by default" is kinda flawed. Would you apply it to bureaucrats or stewards as well? I don't like to see such a drastic change being implemented without consulting or even notifying the communities that actively use the FlaggedRevs extension.

I agree with Piramidion, such changes must be discussed with the communities that actively use the FlaggedRevs extension or they must be informed widely and openly at least.
This zone of community's interest, this is more than technical feature. This is also social feature, which can not be resolved in back office silently.
This is not security problem, like it was with separated flag for interface administrator, which was excluded from sysop flag.
If these changes are uncancelable and now sysops are patrolers as default, the communities must know about it in the open from, because then patroler flag should be removed from sysops as unnecessary and superfluous.

Maybe it's late for User-notice, but adding it anyway.

As I said above, it makes no sense to me for sysops to already having patrol but not review, while both are effectively the same stuff, just implemented by different parts of code. I merely fixed what I consider to be an inconsistency in code.

Also note that this also means sysops are able to use special:stabilization now (as not having review prevents sysops from using Special:Stabilization). Since per-project overrides of flaggedrevs settings is currently broken (mainly due to T275334), this change also fixes this for other projects, who want sysops to have review.

As I said above, it makes no sense to me for sysops to already having patrol but not review, while both are effectively the same stuff, just implemented by different parts of code. I merely fixed what I consider to be an inconsistency in code.

You say "it makes no sense to me" and "I consider". Why didn't you ask for other opinions first? You have 2 communities unsatisfied with your decision already. On ukwiki we don't use 'patrol' rights, we have only 'review', and it took a separate (from adminship request) community process to receive those rights, and we could take those rights away from admins that misuse those rights. Now you just took that possibility away from us.
P.S. actually we have an active community discussion about removal of "review" rights for a certain sysop, and this change just made that request impossible to fulfil.

User-notice is still notice behind the doors of the back-office.
You have changed system that had worked fine more than 10 years.
Was it urgent necessity? Nope. Was it security vulnerability? No, as I know.
Patroler and rollbacker/mover (and other flags built in sysop flag) are not similar.
Rollbacker/mover/etc. are the technical managers, they manages content on technical level (technical issues and compliance with Five pillars and derivative rules), but they do not define quality level for content.
Patrolers are the first level of content managers, they define quality level for content indeed.

I've decided to check bewiki policy, https://be.wikipedia.org/wiki/Вікіпедыя:Догляд#Зняцце_сцяга_даглядчыка . It also goes:

Адміністратары маюць права на атрыманне сцяга даглядчыка без дадатковага абмеркавання (у тым ліку, могуць прызначыць яго сабе самі), калі толькі яны не былі пазбаўленыя яго раней у сувязі з парушэннямі дзеючых правілаў.

Administrators have the right to get the editor flag without additional discussion (including can self-assign it), but only if it was not removed from them before for violation of current policies

So Belarusian Wikipedia also has process which makes it possible for administrators not to be able to review by design. This makes this at least 3 communities.

On the other hand it seems that the change makes sense for Macedonian WP, per https://mk.wikipedia.org/wiki/Википедија:Барања_за_оценувачки_статус it seems that they tie together administrator and review rights: "Администраторите се автоматски и оценувачи".