Page MenuHomePhabricator

Evaluate the secret "bot marks reverted edits as bot" feature
Open, Needs TriagePublic

Description

In 2003 a "secret" feature was introduced. When an account with bot flag performs a rollback, then reverted edit(s) get retroactively marked as if they were performed by a bot (@tstarling, r2203, 036ff960ce)

I assume the reason for this feature was as a first step towards a patrol system in which Special:RecentChanges could be reduced over time, starting with retroactively hiding obvious vandalism. I also assume that at this time there must'be been a way already to hide bot edits, and this was simply the hammer available to hit the nail with.

The next year in 2004, the first parts of the rc_patrolled feature were introduced (Arne Heizmann, r4619, 075396a961).

In 2005-2006, as part of improving the patrol system for wider use on Wikipedia, @brion applied the autopatrol feature to rollbacks (r12126).

I think that basically obsoletes the previous feature. I propose removing the older/secret feature as it seems surprising from a UX perspective that an edit by a vandal is retroactively changed to be as if it came from a bit. It also came up in a refactoring today where it is imho unclear what the expected behaviour is in relation to the patrol system. E.g. if 2 of the 5 rolled back edits are already patrolled by a human, should they still become "bot" edits for consistency? Only some? And more generally — Why? If the reason is only to let patrollers hide reverted edits, then this is already accomplished through "Hide patrolled edits".

Event Timeline

Change 773927 had a related patch set uploaded (by Krinkle; author: Matěj Suchánek):

[mediawiki/core@master] Make rollback not overwrite manual patrol status

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

For reference, I made the above patch after uncovering the "manual patrol status overwrite" bug in T302140.

RollbackPage has one more interesting "secret" feature: the method that possibly marks reverted edits as patrolled and/or "done by a bot" can run even if no new revision has been saved (reference: T64157). This typically happens when you rollback a vandal who undid their own changes.

To comment on the feature, I think it might be more useful for watchlists than for recent changes patrolling. Some people would like to hide edits that constitute "no change" (T224698). I think most users don't see bot edits and don't filter their watchlist based on patrolling either. So marking them as "done by a bot" sort of does that. But it doesn't happen often and I somewhat agree it goes against transparency and it's effect is surprising.

I believe that this is still helpful, specifically because of excluding from watchlists. This is what the markbotedits right exists for example - to allow normal rollbackers to revert vandals and hide the reverted edits from recent changes in the process. Not all wikis have patrolling enabled, but bot edits exist everywhere.

But they're not bot edits, are they? The revert is but the reverted edits are not. One could just as well make a case for wanting to see all edits by people and then these are unexpectedly hidden.

ClueBot is one of the most notable revert bots and it doesn't seem to mark its reverts as bot edits. On Recent changes with bot flag I could not find any reverts.

If a community wants to hide edits that have already been reverted or otherwise patrolled by their peers, they should enable RCPatrol. We can't have it both ways, I think. (See also my Essay on patrolling in which I point out that disabling this feature doesn't make sense).

But they're not bot edits. One could just as well make a case for wanting to see all edits by people and then these are unexpectedly hidden.

If a community wants to hide edits that have already been reverted or otherwise patrolled, they should enable RCPatrol. (see also my Essay on patrolling in which I point out that disabling this feature doesn't make sense).

Are there any cases of the status quo causing problems? Until T174349: Allow tag filter on Special:RecentChanges and Watchlist to be inverted (enable the not operator) is addressed there isn't an easy way to just exclude reverted edits without enabling patrolling and then excluding all patrolled edits.

Given that this is currently being utilized by patrollers (check recent changes for anonymous bot edits, eg meta or mediawiki) I suggest discussing this with editors first to see if the global community wants this change.

It's not that secret, e.g. documented in the respective enwiki manual: https://en.wikipedia.org/wiki/Help:Reverting#Bot_rollback
It can be useful to reduce the disruption from particularly nasty vandalism / trolling.

I don't see any "bot marks reverted edits as bot" feature in either the linked change or in the current master. The feature was and is allowing administrators to mark edits as "bot" using a request parameter bot=1. It's not necessary for the user to have bot permissions to do this. The rationale was that only rc_bot hides an edit from the default RecentChanges view. If patrolling an edit hid it from RC by default, then maybe that would be duplicative, but it doesn't. The hidepatrolled user preference is off by default.

As Tgr says, the point is that when you've got a wiki with 100 edits per day, and a vandal comes along and makes 100 edits with some all-caps obscenity in every edit summary, there is a desire to not show that 50 copies of that comment to everyone who clicks "recent changes" for the next day.

Change 773927 merged by jenkins-bot:

[mediawiki/core@master] RollbackPage: Make rollback not overwrite manual RC patrol status

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

Change 802765 had a related patch set uploaded (by Umherirrender; author: Umherirrender):

[mediawiki/core@master] rollback: Also adjust patrol status for revision with same timestamp

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

Change 802765 merged by jenkins-bot:

[mediawiki/core@master] RollbackPage: Include patrol status of revisions with same timestamp

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