[Crossposted to wikien-l and wikitech-l.]
Guy Chapman aka JzG wrote:
On Wed, 12 Jul 2006 17:09:22 -0500, Jimmy Wales jwales@wikia.com wrote:
When I met Seth, he explained to me how this happened. The vandal used a classic trick... the double edit. The first edit was the vandalism, the second edit was innocent. So if you checked the diffs incorrectly, you would not see the attack paragraph.
Hell yes. I see that a lot.
Presumably this is something that could be countered by technical fixes. Admin rollback already automatically reverts multiple consecutive edits from the same editor; the manifest usefulness of this feature would be one more argument for granting rollback privileges to non-admins. But _seeing_ the sum of the edits should definitely be made easier: I think that the diff links in the watchlist, at least, should automatically show all the combined edits made by the last editor.
It'd also be nice if the diff view showed how many edits there are between the two revisions being compared; besides being, IMO, a good thing in general, this would help make the change I proposed above less confusing.
I don't think this should be particularly hard to implement. What I'd like is comments on whether this would actually be a good idea, and suggestions on where else, besides the watchlist, it should be applied.
(At the risk of [[WP:BEANS]], I'd like to note that there is another related problem; if a vandal blanks the section of an article containing the interlanguage links, a bot will often quickly show up to restore them, as a side effect hiding the vandalism itself from the watchlist. Making the bots smarter would help, but I'm not sure what can be done to solve this problem in general, beyond hiding bot edits from the watchlist by default and making the feature actually do what it should do -- i.e. show the last non-bot edit instead.)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
First of all, I believe rollbacks already revert all edits by the same user. But as I explain below, it's easy to bypass.
I'd just like to say this could be fixed by consulting the history tab. I don't like or use the (diff) link at all. But this takes more time and resources, and is unmanageable if you need to check more a lot of revisions.
Sum of diffs for one user would only partially solve the problem. The vandal would simply create two accounts, one of them vandalising and one of them innocent. With a little extra editing, the correlation could be made to be as cloudy as possible: valid editor in the wrong places at the wrong times, or vandal's assistant making good edits only? And if the vandal's assistant is indeed making /good/ edits, would there be any way to block them? (Someone's bound to make a mistake sooner or later).
I would push for the implementation of an "All Changes Since Last View" option for users. By encouraging users to check the last twenty edits, rather than just the last edit, they click the link, as usual, but instead see a comprehensive profile of changes and can selectively revert if necessary. Multiple diffs on one page would be nice too.
Selective reversion is a time-consuming process though, and would not work for RC-patrol.
This is from a social perspective. Technically speaking, I'm sure all of these features have been filed in Bugzilla, and that all of them have technical problems that make them undesirable performance wise.
On 7/16/06, Ilmari Karonen nospam@vyznev.net wrote:
(At the risk of [[WP:BEANS]], I'd like to note that there is another related problem; if a vandal blanks the section of an article containing the interlanguage links, a bot will often quickly show up to restore them, as a side effect hiding the vandalism itself from the watchlist. Making the bots smarter would help, but I'm not sure what can be done to solve this problem in general, beyond hiding bot edits from the watchlist by default and making the feature actually do what it should do -- i.e. show the last non-bot edit instead.)
Any anonymous user reducing the byte size of an article by more than 100 bytes should automatically set alarm bells off. The software should detect this (and similar patterns of probable abuse) and add them to a to-do list of dubious changes to be checked.
I'm vary wary of assigning important tasks like this to bots, as you never know when a bot will check any page, or when it will be down, or running on out of date data or whatever. Performing a couple of quick heuristic checks at the time the edit is made would be the best...
Steve
Steve
wikitech-l@lists.wikimedia.org