Wikivoyage:Administrators' handbook

This is a basic how-to manual for administrators, not a policy page.

The Administrators' handbook is a manual for how to use sysop-level tools.

The rollback button is essentially the same as the "undo" tool, except it removes some steps and has added functionality to help administrators and patrollers handle unwanted edits. Clicking the rollback button will automatically undo the last edit to a given page and any consecutive previous edits made by the same editor to that page and will also mark the edits in question as patrolled. There is no additional confirmation step for rollbacks, so make sure you want to do this before clicking the button. There is also is no way to leave a comment when rolling back edits, so consider using the undo tool if you would like to leave an edit summary. If you would like to use rollback with an edit summary, consider using the TwinkleGlobal extension.

The rollback button is available from "edit differences," article histories, and user contributions. The biggest advantage of this tool is the ability to quickly revert all edits from one user, by simply clicking all the rollback buttons so that they open in new tabs.

Rollbacks are a hard (and potentially insulting) measure, and should mostly be used for vandalism and spam. Good faith edits should be undone with an explanation in the edit summary.

Global rollbackers and Stewards also have the rollback tool.

Administrators can delete any page, per the rules outlined by the deletion policy. Pages with over 5000 revisions have to be deleted by stewards and that can be requested on meta.

If an article was improperly deleted, or was successfully voted for undeletion, an administrator can restore the page from the deleted page itself, or from the Deletion log.

Page protection is generally a tool of last resort. We are a wiki, and allowing anyone to edit any page at any time without exception is a guiding principle of how we operate. If an article is being repeatedly vandalized, it is almost always better to simply add that article to your watchlist and revert the edits. Over time, this discourages most vandals. One might object, on the basis that there are some unusually persistent editors, who just won't give up, and continue to add their unwanted edits daily, even for years! But this is a very small subsect of Wikivoyage contributors, and it is not worth it to compromise our basic principles for their sake. We can and do control these problems through watchlisting the affected pages, reverts, occasional additions to the spam blacklist, and coordination at Project:Vandalism in progress.

Exceptional cases do exist, for which we have established consensus on the corresponding article talk page, but these cases are governed by the (strict) Wikivoyage:Protected page policy, and are rare.

Administrators may, at their discretion, temp protect a page undergoing high volume unwanted edits (i.e., a revert war), but the time spans on such temp protects should be short, no more than a cooling-off period.

To protect a page, simply click the protect tab at the top of any article, and fill out the confirmation form. You can set the expiry time either by setting the duration or the end time. Examples:

2 hours
3 weeks
1 day 4 hours 32 minutes

05:44, 8 December 2012 (UTC)
8 December
22:14

Semiprotection

User bans/IP bans are perhaps our least favorite tool of all, and extraordinarily ineffective in the anonymous, dynamic IP-loving world of the internet. Their use is governed by Project:How to handle unwanted edits#User ban.

Users can be blocked from their respective pages, Special:Recentchanges, Special:Watchlist, page histories, edit differences, and the logs, by clicking on the block button. Don't institute bans without adding an entry to Project:User ban nominations. If you have any doubt at all as to whether you should institute a block, definitely wait through the 3-day process on the nominations page before instituting it. Recently applied blocks can be seen from Special:Log/block.

Permanent blocks are very rare.

Blocks exempt from the nominations process include spambot blocks (which should be permanent except in the case of IPs, which should normally be blocked for 1 month, since the same IP could be used later by a completely innocent party); and temp blocks to halt extremely high-volume vandalism (i.e., move vandalism), in order to create space to clean it up. Temp blocks may not exceed a span of one day—longer blocks must first be nominated at Project:User ban nominations.

Expiries are set the same way as protects, described above.

The form's boxes "Prevent account creation" and "Automatically block the last IP address used by this user, and any subsequent IP addresses they try to edit from" are automatically checked, and almost always should be left checked. "Prevent user from sending e-mail" is optional—do you suspect the user would abuse this privilege? "Prevent this user from editing their own talk page while blocked" should almost always be left unchecked, so that users have a way to petition their ban. Only in rather extreme cases should they be blocked from editing their talk page, and should in such a case have a way to email admins.

It is also possible to block a range of ips, see mw:Help:Range blocks for guidance, but don't try this unless you understand what you are doing! The policy governing their use is here.

The AbuseFilter extension allows administrators to set specific actions to be taken when actions by users, such as edits, match certain criteria. For example, an edit filter could be created to prevent anonymous users from adding external links or warn (or temporarily block) new users who are blanking entire pages.

This is usually used to block specific patterns of vandalism; the sites advertised by spammers are more readily blocked by adding them to the Mediawiki:Spam-blacklist.

The abuse filters often give false positives; mistakes can make them block loads of good-faith edits. Therefore, Special:AbuseLog should be checked regularly, or at least from time to time, and closely monitored after any changes. You can also check how a modified filter matches recent edits before saving the modifications.

If a user complains about a blocked good-faith edit, check the abuse log link from their contributions page. There you can see what filter is the culprit (the "warning" or "disallowed" entries), and what the tried changes were. The edit might have been blocked for a reason (a bad wording, a blocked URL) or, if the edit seems innocent, it may contain keywords caught by a too tight filter (compare the Scunthorpe problem) or a plain error in it.

See also: Wikivoyage:How to handle unwanted edits, Mediawikiwiki:RevisionDelete

It is important that administrators follow policy developments that affect the use of these tools. To be sure you do not miss important policy changes and discussions, add the following pages to your watchlist:

• Wikivoyage:Administrators
• Wikivoyage:How to handle unwanted edits
• Wikivoyage:Consensus
• Wikivoyage:Deletion policy and Wikivoyage:Votes for deletion
• Wikivoyage:Protected pages and Wikivoyage:Protected page policy
• Wikivoyage:Spam filter and MediaWiki:Spam-blacklist
• Wikivoyage:User ban nominations

Less crucial, but still worth monitoring are:

• Wikivoyage:CheckUser
• Wikivoyage:Edit war
• Wikivoyage:How to revert a page
• Wikivoyage:No real world threats
• Wikivoyage:Vandalism in progress
• Wikivoyage:Votes for undeletion

Bureaucrats used to watch the following pages, which are now superseded by Single Unified Login (SUL):

• Wikivoyage:Changing username/Open requests
• Wikivoyage:User account migration