Page MenuHomePhabricator

Undo should auto-patrol reverted revisions, like a rollback does
Open, LowPublic

Description

Author: Wiki.Melancholie

Description:
Undos (&undo=) should auto-patrol the reverted revision, like sysop's rollbacks do for reverted edits in between!

Details

Reference
bz14439

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:10 PM
bzimport set Reference to bz14439.
bzimport added a subscriber: Unknown Object (MLST).

This feature has been requested several times on fr.wikipedia as well, since its activation a month ago.

Moreover, I had an undeletable exclamation mark after the renaming of this article: http://fr.wiktionary.org/w/index.php?title=magie_blanche&oldid=6771460, even if I restore and search for it.

  • Bug 44840 has been marked as a duplicate of this bug. ***
Izno updated the task description. (Show Details)
Izno subscribed.

Merging the other direction, since this is apparently not just a Wikidata-related request.

The problem I have with this task is that undo is not a functionality restricted to trusted users on most/all wikis. If we're going to count an undo as patrolled, then we need to change the set of people to whom undo is available.

However, from memory, undo was provided as a light alternative to any/every user to hunting in the history for a single-revision undo, so that desire to change the set of people seems antithetical to the goal of marking undo as patrolled.

My opinion: Mark as declined. No-one has hacked at this task in the 10 years of existence and frankly it doesn't make sense to do so.

And lastly, the "rollbacker" right has been shown to cover the case of pure vandalism and is in predominant use I would guess on most wikis (which this right was not available at this time or only available as part of the admin package).

Maybe it's less of an issue for other wikis and that's why nobody has worked on it yet, but people who are trying to do countervandalism work on Wikidata are saying the current behaviour is affecting how efficiently they can do that (I also agree). Declining it won't improve anything and it's in Wikidata's own interest to make countervandalism work easier. The only suggestion I've seen has been to use rollback, but rollback is not possible or appropriate in all cases, e.g. someone else has already edited the item, not all of the edits need to be undone or the edit is a good faith edit.

I don't think it makes sense to mark all undos as patrolled (particularly undos by users whose own edits aren't marked as patrolled) but I don't see why undos by people who can patrol other people's edits should not automatically mark the edit being undone as patrolled.

If we're going to count an undo as patrolled, then

I don't think it makes sense to mark all undos as patrolled

I don't think this is what this task is about. The task is not requesting the undo edit be marked as patrolled but the reverted edit. And it seems safe to me to do that.

Lets assume user A makes an edit on a page. User B undoes that edit. The edit of user A can be safely marked as patrolled: If the edit of A has been wrong, then it can be marked as patrolled because it it's been reverted. And If there is any other action needed then it should be enough to review B's edit. OTOH, if A's edit was right, it again deserves to be marked as patrolled. In this situation it's again the edit of user B which needs to be reviewed.

Sorry, I did understand it, but I worded my response badly. I should have written something like "I don't think it makes sense to mark all undone edits as patrolled (particularly when the edit is undone by a user whose own edits aren't marked as patrolled)" instead. You do have a good point though and if someone wants to make all undos mark the undone edit as patrolled, I wouldn't be against that.

@Izno It's easily possible to set edits as patrolled whenever they are undone by users who have patrolling privileges. If that's your objection it's easily addressed. In my experience, it's annoying to look at the patrolled list and see items that are already undone.

Per Dalba, it shouldn't be a problem to mark the undone edit as patrolled. It's either undone and can be patrolled, or it was right and can be patrolled. Only the reversion may need patrolling. (if the reverting user isn't autopatrolled) Also, marking undone edits could (if desired) be restricted to certain user groups. (in that case I would restrict it to autopatrollers I think)

The rollback feature has as benefit that it can undo multiple edits at once, and it is does not allow for changing the new revision. It cleanly and automatically restores a previous version.

Given the feature is only available to a subset of trusted users, auto-patrolling the reverted edits and the revert itself is as such fairly uncontroversial I think and beneficial to reducing patroller workload.

With undo its a bit more complicated because:

  • Undo allows the editor to change the page at the same time. This means it remains a judgement call on the patroller side whether the edit did indeed undo the change it claims to undo, and whether any additional changes are in acceptable state. Marking the original edit as patrolled and leaving the undo as unpatrolled is not sufficient because the undo might not even undo the original at all, a patroller would not likely not discover this and makes the overall process more complicated than it needs to be.
  • Undo allows older edits to be undone as well not just the most recent one.

This last one is a good reason in favour of making it connected with the autopatrol functionality because even trusted users (e.g. rollbackers) do not have currently an easy way to undo an older edit (if there are no conflicts) and mark it as patrolled.

Perhaps the following would make sense:

  • If the editor saving the undo has the patrol right,
  • and we determine the undo was saved without changes to the page or edit summary,
  • then we automatically mark the original as patrolled on the patroller's behalf.

That seems uncontroversial and is perhaps was what originally led to this idea, before being generalised to all undos.