1

Hey guys! Recently, BR got to the heart of a bug in RCP that involved “rollback” going back to the wrong version of the article. This turned out to come down to the way that MediaWiki’s built-in rollback function works (it can only do one editor at a time - whereas our RCP tool can bundle edits together to show you a the bigger picture of unpatrolled changes). We feared this would be a very hard thing to fix because rollback is so deep within the MW code, but the awesome news is that @Jordansmall has come up with another way to solve this! He essentially rewrote what the “Rollback” button does, just within the RCP tool, so that it now always restores the version you see on the left-hand side. This is pretty much how rolling back is supposed to work in RCP anyway, but there are a couple of things that experienced patrollers might notice. Before, when you pressed the rollback button on a “no change” diff like this:

1550×918 134 KB
It would sometimes rollback to an intermediate revision. Now, the left-hand side will ultimately be “king”, when it comes to rolling back; what you see there is what will be published when you rollback. So if you see one of those “nothing has changed” edits (from a rollback) and actually want to capture and re-publish the intermediate version (e.g. if it was a bad rollback), you’ll need to open up the history and do it from there. Just pressing rollback on an edit like this will let you know that there’s no change between the left and right versions. For those of you who patrol oldest to newest when the RC count is high, look out for this little arrow on the right:
1598×880 136 KB
If you’re dealing with any sticky old RC and there are multiple revisions on top of it (and you see the little arrow on the right-hand side of the diff), rolling back will republish that left-hand side version. These instances are pretty rare and only show up when a patroller has been unpatrolled, but in those cases, just keep an eye out to make sure that what you’re going back to is the best revision (and if you see any rollbacks like this when you’re patrolling, just use your best judgment about which one is the best version). Again, the instances above should be pretty rare, and this fix should actually return RCP behavior to what makes the most sense! If you rollback, you’ll republish what’s on the left - as the tool promises. We just wanted to give you guys a heads-up about some of the implications when it comes to rolling back a rollback or dealing with old edits, in case (like me!) you’ve actually unknowingly adjusted to the buggy behavior. Now that the bug is fixed, we’ll have to go back to doing it the way it was supposed to work:slight_smile:Three cheers to @Jordansmall for figuring out this tough situation - and nine cheers to @BR for gathering the information needed to fix it. Thanks to him and to all our careful and considerate patrollers out there, keeping article quality high every day!
2

Thanks @Br @Jordansmall and of course @Anna !

3

Thanks for letting us know, and thanks to @BR , @Jordansmall , and @Anna ! I’m glad that the bug is fixed now.:slight_smile:

4

In response to the edit summary it now leaves, it’s not the tool that’s reverting it, it should be the user who is. Here’s the edit summary it leaves for one like that. “RCP reverted edits by Gurpreet197897 (talk) to revision #13676509 by Gurpreet197897”

5

I saw this summary too. I also think it should be the user who reverted the edit.

6

Heh, that’s funny - it’s not intended to imply that the tool did it. The user is still very visible in the logs and history! It’s just telling you it came from RCP instead of the history/Special:Recent Changes rollback (this makes it easier to pinpoint any bugs and figure out where a rollback was done from, if something goes wrong with it). So think of it like “RCP-reverted edits by” as a compound verb, just to be more specific than the old/regular edit summary of “Reverted edits by” - but not like RCP did the revert:slight_smile:

7

Wouldn’t “Username reverted edits by username (talk) to revision by username through the RCP tool” be better understood of who did what in where, yet be simple enough as not be confused (you could add the revision umber to this, but for sake of simplicity of this message, you get the general idea).

8

Honestly, that seems redundant to me, and a bit long for a regular edit summary. Anywhere that you see the edit summary (in history, in contribution list, in a diff), you’ve already got the name of the editor right next to or above it. The old message never specified user there either. I don’t think I’ve ever seen an edit summary where the editor specified who they were, since that’s always obvious from the history - have you? It’s helpful to keep in mind, too, that even small changes take up engineering time and keep them from working on other things we want fixed or created. If it’s usable as is, particularly being similar to the old one (and just clarifying the tool/source of the rollback), I think we’re best off adjusting to it. Personally, I kind of like that it’s succinct and gets the message across:slight_smile:

9

I noticed this, too, while I was patrolling. Thanks for the update!

10

It looks great and works wonderfully well for me! Kudos to a tremendous trio - @BR originator, @Anna facilitator, @Jordansmall implementer Just curious -

  • Does the revision number help with trouble-shooting?
  • Does the revision number help any patrollers or editors?
11

@Serendipittee I definitely used them in bug-testing, so think they could be helpful in trouble-shooting (both for technical issues and editing) in the future. For example, if there are multiple recent versions by the same editor, it might be hard (from the history) to see which one a rollback went to – at least, without comparing each version to see which diff has no change. What I was doing in actual bug-testing was hovering over the date link in the history to see what revision number the link went to (in my browser, at least, it displays on the bottom of the window). I could see it being helpful, editing-wise, in trying to see whether the rollback had indeed gone to the “last good” (if the recent edit history was messy). It admittedly probably wouldn’t be too widely used, though! We thought about doing date or time instead of revision number, but since all contributors can set their own time zones in their preferences, that’d get really inconsistent for different people. Revision number seemed like the most helpful addition. Might not be necessary for most folks, though:slight_smile:

12

I have one question. Is it impossible to slow the page transfer so the notification (Edit rolled back to “this edit”?) is readable, or am I the only person who cannot read it in the second it appears before the next page loads? And, is the problem fixed? http://www.wikihow.com/index.php?title=Get-the-Crush-of-Your-Dreams&diff=13691133&oldid=13384163 makes me wonder… that is one of a dozen or so patrols that went to an intermediate revision today, a few days after the fix.

13

I agree with @BR that the notification should stay longer. What’s the purpose of it showing for a split second? In the old RCP (before the redesign/upgrade), after patrolling and moving on to the next article, pressing the back arrow in RCP would display the NEW current revision on the right side, and the rolled back/old revision on the left. Restoring this functionality would make it easier to check those intermediate revision problems, because the live revision would show on the right, making it easy to see if the correct revision was restored as expected. The issue is still present: http://www.wikihow.com/index.php?title=Draw-a-Grasshopper&action=history Ron’s rollback should have reverted both of the same anon’s contributions; instead, it rolled back to an intermediate (still bad) revision by the same anonymous contributor?!?

14

Thanks for the heads-ups, @BR and @Isorythmic . Any change on RCP is a tangle, so there’s always a possibility of edge cases or loopholes that the fix has missed, and it’s good to know about them so I can pass it on to the engineers! In the case of that first one, BR, it looks in the logs like that first bad anon edit was patrolled in by a fairly green patroller, about 45 minutes before Adelaide patrolled the next one. So I think that’s more down to a bad call on patrolling than a tool misfire. The RCP tool loads the last patrolled version on the left-hand side - so in this case, it seems like the newer patroller marked that first anon change patrolled, and then when the next anon edit came through RCP (from an edit 40 minutes after the first), Adelaide rolled back, so that reinstated the most recent patrolled version. Great thing that you caught the bad change that shouldn’t have been patrolled! Jeff, great catch on that, too. Looking at the logs there is interesting - it looks like Ron’s patrols were 1 minute apart, rather than at the same time. I wonder if he saw them separately or together? @Serendipitee , if you happen to remember anything about what RCP showed you there, that would be helpful to know, so we can pin down what the tool should have done and what it did! Jeff, on the same anonymous contributor front: because the rollback button was rewritten not to focus on just the one most recent editor, it won’t automatically undo all of that person’s edits, if one was previously patrolled in. The way it functions now, it actually republishes the wikitext of the last patrolled version: the left-hand side revision (hopefully, if patrolling has been top-notch, the last good!). If Ron saw both of these anon edits on the right-hand side and the previous clean version on the left, then yep definitely a misfire; but it won’t automatically undo both of the anon edits, if one was accidentally already patrolled in (and was on the left of the diff). I’m mostly offline on a mini vacation this weekend, but I’ll try to dig more on this when I have access to my computer and can patrol some more. Please keep me in the loop if you see more cases where it seems to be doing something “off” or not republishing what it shows on the left-hand side! While I don’t know about engineering feasibility on them, I will also pass on the suggestions about slowing down the message and the back arrow behavior. Thanks for them!

15

Good sleuthing, @Anna . I do think I saw those patrols individually, rather than grouped, but I have a bit of fog surrounding my memory of those patrols and my actions. I do have a suspicion that I opened a history in another tab to check out the edits and patrolled the vandalism @Isorythmic edited out (Thanks Jeff!) from that tab, then when back to RCP and rolled. I would not pin that non-optimal rollback on the software, but on me flat out missing the vandalism and using poor methods to patrol. I think there is the possibility is to open parallel queues of the same diffs in separate tabs. The primary tab might be RCP and the secondary tab traditional patrolling. The actions within the secondary tab do not get reflected with an update in the diffs that you see in RCP (the primary tab), but the actions performed within RCP actually reflect the most current state of the patrols and edits. The two end up out of sync - what you see is not necessarily what you get. Patrolling parallel streams is something I seldom do, but it is good to know that this is a poor practice and to be guarded against. Just conjecture here, but someone else could be patrolling or editing the article at the same time as you have it in RCP and there might be instances where what is shown in RCP does not reflect the current state. It might be that a software test could be done to verify that the data has not changed since it was rendered for the diff seen in RCP (and a flag thrown if it has). Like Anna relays from the engineers - RCP is a tangle. I only know enough to make presumptions about what might be possible. I trust that the engineers know when to wad up my suggestions and toss them toward the trash can. I agree with @BR and Jeff on the flash notices being of little use and would welcome the return of the back arrow functionality for rollbacks that Jeff suggested.