[Home]RevertPage

MeatballWiki | RecentChanges | Random Page | Indices | Categories
When you stumble upon a page that has been defaced, proceed as follows:

  1. Click "View other revisions" at the bottom.
  2. From the VersionHistory, find the last good revision, and view it. Assume it is Revision 246.
  3. Click "Edit revision 246 of this page" at the bottom.
  4. Put "revert" or something similar into the summary and click "Save".

"What if it is a new page, or there are no good revisions?" -- Anon

See PageDeletion.

CategoryWikiConventions

Some wikis place a "Revert this page" link at the bottom of each page. While this may make reverting vandalism easy, it also makes it easier for attackers to revert legitimate changes, as well as klutzes to do it accidentally. Reverts are much harder to tell apart than normal edits. Although you could explicitly flag reverts in RecentChanges as such, the reason for reverts aren't always clear.

Since you can assume that your PeerReviewers know how to revert a page, and if you don't want to make it easier for passing vandals to cause a nuisance, you may not want to put such a link at the bottom of each page. Besides, since there is already a simple and obvious way to revert pages, this "shortcut" link worsens your FeatureKarma.

Nonetheless, if you feel that reverting is a frequent and critical action, you may want to consider adding such a link, and then evaluate the results.

"User-side" EditConflicts when reverting pages

There is a subtle but real EditConflict potential in the way all (I believe) wiki RevertPage systems currently operate. There are essentially three steps to reverting a page:

  1. View the edit history and decide which revision to blow away
  2. Edit that revision, adding an appropriate EditSummary?
  3. Save the new revision

Most mature wikis have solved the potential EditConflict between steps 2 and 3. However, there is also a possible "user-side" conflict between steps 1 and 2:

This conflict is just as dangerous as standard EditConflicts, though much less common. It is important to design a wiki engine to rule it out.

Therefore, modify your wiki engine to warn the user if there is an edit between steps 1 and 2 of the three-step page-revert process. The easiest way to do this is to add a parameter to the URL of any old revision–viewing page (both viewing the rendered HTML and editing the wiki text) storing the revision of the page that was current at the time that URL was presented to the user.

Whatever links you provide the user, it is vital that any link taking the user away from the most recent view of the site be appropriately tagged. On MeatballWiki, for instance, that means pretty much every link off the action=history pages. Wikis that provide a 'view last revision' link from a detailed RecentChanges page would need to tag that, similarly.

Another option is to very visibly show the current version of the page, or at least the last editor. Perhaps SideBarHistory? is sufficient. Another option is to show both reversions on RecentChanges as collated but independent actions. -- SunirShah

The nice thing about including the current revision number in the URLs is that you only distract editors in the rare case that there has been a conflict. Visibly showing the current version of the page relies on the user checking if there's been a conflict every time they edit, when it's trivial to get the wiki engine to do that grunt work for them. Showing both revisions on RecentChanges has similar problems to the merging-with-markers approach to EditConflicts?: if two people come along and try to fix the user-side edit conflict, they can both collide and create another user-side edit conflict, requiring an out-of-line method of conflict-resolution when, frankly, the engine should be doing it for them.

A similar mechanism would help avoid the "user-side" edit conflict of "I look at the current revision of the page, then I edit it, but it's been changed in between". This conflict is less evil because it can be spotted by the eagle-eyed editor, but fixing it can only help improve visibility of changes to the site the editor should be aware of. -- ChrisPurcell

We just had the first user-side edit conflict I've ever seen ([1] will show it until the end of July 2006). The squashed edit (mine) didn't have anything lost, but it's interesting to know this isn't pure theory. -- ChrisPurcell

CategoryWikiTechnology CategoryUnimplementedWikiTechnology

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: