MediaWiki Administrator's Handbook/Print Version

This book is a guide for administrators of MediaWiki--the software that runs Wikipedia.


Preface

So you've become an administrator on a MediaWiki project, or you just want to know what the differences are between an administrator and a normal MediaWiki user? This Wikibook is intended to help with the job and try to explain the special functions available to an administrator. It also covers some of the things you need to avoid when trying to do your job.

This book is not a policy manual, although links to existing policies on several Wikimedia projects have been provided for reference purposes. This book is about How-to admin in the general sense and is appropriate to any project using the MediaWiki software.

An important point to note here is that while most Wikimedia sister projects use the term administrator or admin to mean a person who has been granted "Sysop" privileges with the MediaWiki software, most MediaWiki documentation usually uses the term Moderator instead. This Wikibook is not dealing with any of the software configuration issues that are associated with low-level operating system commands and configuration files directly associated with the use of the MediaWiki software. Most MediaWiki documentation calls these individuals administrators, but with Wikimedia sister projects these individuals are usually called developers instead, as the MediaWiki software developers also do the low-level software configuration for Wikimedia projects. Instead, the term administrator is going to apply to the project moderators and following Wikimedia sister project conventions and hierarchies.

The specific permissions granted to an administrator on a MediaWiki project can differ. This book covers the full set of permissions that might be granted but on the particular project you are interested in you may find that some functions listed here are unavailable.

See the MediaWiki Developer's Handbook for a book on how to "hack" Mediawiki to customize the software, add an extension, or contribute to Mediawiki development.


Explanation of Admin-specific Tools

Page Deletion

Sometimes it is necessary to hide a page rather than just fix it or redirect it elsewhere. Although this function is described as "deletion" it doesn't physically remove it from the underlying database. Instead the page is marked as delete and is hidden from view for normal users (that is, those without administrator privileges).

Once you have become an administrator one of the first things you will notice is a brand-new "delete" tab at the top of most pages in addition to the normal ones. This will take you to a deletion prompt.

Once there, fill in the explanation and click "Delete page". Some versions of MediaWiki have a "Yes, I really want to delete this" checkbox, so tick that before clicking delete otherwise it will not work.

What should be deleted depends on the project's inclusion rules, but generally:

Deleting specific revisions

If you wish to delete only some revisions of a page - for example someone's private contact details or a copyright violation -this can be done using the "revision deletion" functionality from the page history display. Select the revision you wish to delete then click the show / hide selected revisions button. You will be given the option of hiding the content of the revision, the account name that made the revision or the edit summary. One or more options can be selected. Enter a reason for hiding the revision then click apply to selected revision to complete the action.

Hidden revisions remain visible to other administrators. In some cases the revision may need to be hidden from administrators as well. This is achieved using the suppression function (called oversight in earlier versions of MediaWiki). On all Wikimedia projects the suppression function is only available to Oversighters and Stewards.

Restoring some or all deleted revisions

Once a page has been deleted it is invisible to normal users, but admins visiting that same "no such article" page will also see a line at the top saying "View or restore ## deleted edits?". This line also appears on the revision history page if the page still exists but has had some past revisions deleted.

Regardless of its location, clicking on the link will display the revision history. MediaWiki builds from before February 16, 2006 will show the last revision before deletion above the revision history. Each of these can be viewed on its own by choosing the appropriate date and time entry. MediaWiki builds from after February 16, 2006 will display the raw wiki source for the page (with a button below which can render it as it appeared), while those before this date will show the rendered page. Regardless of what version you are using the diff view function is currently not supported for deleted pages.

If you want to restore all deleted revisions merely click "Restore!", but if you want to exclude specific revisions you will need to check the boxes of every revision other than those ones before clicking Restore, at the moment there is no "restore all but selected" option. For pages that have had a lot of edits this can be a laborious process.

Revision restoration does not have to happen all at once however, and even multiple admins can simultaneously restore edits of the same page (although they will encounter some errors if they both select a matching revision).

Merging page histories

Sometimes when merging pages it is desirable to merge their edit histories together rather than simply using redirects. In this case you will need to delete the page in question, move one of the source pages over top of it, delete the page again, move the next over top, etc. etc. etc. Once completed simply restore all the revisions by clicking the history tab and going through the procedure described above.

Depending on the version of MediaWiki running the newest revision may become the current revision, so you may need to revert to an earlier revision where all the source pages had already been merged.

A step-by-step explanation is found in Edit History.

Mass page deletion

The mass deletion function (also known as nuke) can be used to remove a large number of pages quickly and easily. It is useful when combating page creation vandalism. The mass deletion function is accessed from Special:Nuke. Three options to filter the pages to be deleted are available:

  • All users or by username or IP address
  • All pages or by page name (using a pattern)
  • Maximum number of pages

Selecting go will bring up a list of pages based on your selection criteria. By default all pages are "checked" and will be deleted. Enter a reason in the description field then select delete selected to complete the mass deletion. Be careful with this function as there is no mass undelete!

Local Policies


Page Protection

Sometimes it is necessary to protect a page against vandalism or other unwanted edits.

First of all visit the page in question and click the protect tab. You will be presented with one of two boxes, depending on the version of MediaWiki your wiki is running. Both methods are presented below. For the record, Wikicities is currently running MediaWiki 1.4 while Wikimedia projects are running 1.5.

Page Protection in MediaWiki 1.4 and earlier

The protection screen in MediaWiki 1.4 and earlier (some very early 1.5 builds also have this style)


At this screen simply check "Confirm protection". If you only want to prevent people moving the page check that box (by default the page will be protected from both). In this version of MediaWiki you cannot choose to protect solely against page moves while leaving editing access open.

Page Protection in MediaWiki 1.5 and later

The protection screen in MediaWiki 1.5 and later


By default the left and right options both move to the same place when you change the left-hand one. If you check "Unlock move permissions" each may be adjusted independently. You can for example decide to allow only sysops to edit the page, but for non-sysops--the "(default)" category--to move the page if they choose to do so. In most cases you will want to protect against both, which is why this is the default. Some wikis also have a "new users" option (not shown).

If the page has been protected in the past, a "Protection log" will be displayed beneath the prompt.

Unprotecting in MediaWiki 1.4 and earlier

The unprotection screen in MediaWiki 1.4 and earlier (also some early 1.5 builds)


Simply give a reason and tick "Confirm unprotection", then click "Confirm". When using MediaWiki 1.4 this results in all protection restrictions being removed from the page.

Unprotecting in MediaWiki 1.5 and later

For this just see above and set the access type you're re-enabling to "(default)". You can also subjectively turn the two different permissions on and off at will.

If the page has been protected in the past, a "Protection log" will be displayed beneath the prompt.

Things to note

Note that the talk page of the page you are protecting will NOT be protected along with its sibling, and vice versa. If this is necessary you will need to do it separately.


User Block

Introduction

User blocking is perhaps one of the most heavy-handed things you can do as an administrator, and the one that can cause the most damage. An administrator must therefore be cautious in using this power. Often a user will spend quite a bit of time building up a reputation under a particular user name, and by blocking that user they will not be able to edit from their account. Blocked users can still edit their user talk page (and user talk sub-pages?) unless these pages are protected and the user doesn't have sysop or higher privileges.

It is also possible to block IP addresses from being able to edit text. This does not stop a registered user on that IP address from being able to log in, but only stops anonymous users from using the edit functions. If there is a problem where a registered user is unable to access the Wiki due to an anonymous IP block, then the user must unblock that IP and reblock with anonymous users only checked.

Performing the Block

The actual process of performing the block is rather straight forward. You can either go directly to Special:Blockip and get the page, or you can use your administrator's tools on the sidebar and then clicking on the Block User link. This is only visible when you are viewing either a user page or a user talk page.

BlockUser2.png

All this does is simply fill in the name of the user account or IP address so you don't have to worry about misspellings or getting the wrong IP address.

BlockUser1.png


Sidebar

Working with the Navigation Side Bar

One of the more esoteric features of MediaWiki software that is under the control of an administrator is the maintenance of the navigation side bar that appears (usually) to the left of the content on all MediaWiki pages.

Accessing the Side Bar Template

The main sidebar template is kept in the collection of standard MediaWiki messages that may be edited by or protected from ordinary users just like any other template. These pages are always protected from editing, however, unless you have administrator rights.

The typical page for this in the MediaWiki software is found at MediaWiki:Sidebar, and can be found on all MediaWiki projects.

Default Settings

The default sidebar information for most MediaWiki installations is as follows:


* navigation 
** mainpage|main 
** portal-url|portal 
** ict-url|ict 
** currentevents-url|currentevents 
** recentchanges-url|recentchanges 
** randompage-url|randompage 
** helppage|help 
** sitesupport-url|sitesupport

Explaining features

There are two sorts of links that can be added through this interface:

  • Predefined project variables
  • Direct project links

Both of these have advantages and disadvantages which will be explained below.

Predefined Project Variables

The default setup of the navigation bar is only the predefined variables, so a common misconception is that this is the only sort of item that can appear on the navigation bar. Indeed prior to MediaWiki 1.5 this was the only way that you could make changes to the navigation bar, so it is common for people to still use this approach.

The values for these project variables must be changed from the list of System messages directly. For example from the default example above regarding the current events link, currentevents-url can be changed at MediaWiki:Currentevents-url and currentevents at MediaWiki:Currentevents. Note that if you want to change the page links or even the text of the navigation bar for this one item, you don't even need to edit the navigation bar itself directly but simply need to edit the variable link instead.

An additional description is available if you edit MediaWiki:Monobook.js that is related to each project variable that appears as a "hint text" for each project variable.

Advantages

  • Displays hint text (not available for direct project links)
  • Standard translations are available for default multi-lingual configurations which include these variables

Disadvantages

  • Additional step of trying to hunt down variable pages if you want to make changes
  • Often the actual content in the variable has absolutely nothing to do with the name of the variable. For example, portal-url may in fact be a link to a self-referential parody group of pages or to the main project discussion pages.
  • Adding additional variables requires developer access/root access to the computer that is hosting the content.

Direct Project Links

This is a more recent feature for adding in the navigation bar, but is much easier to work with. Specific syntax issues will be addressed in the next major section.

Advantages

  • No need to create variables or edit outside of the main side bar template
  • Context of the content is obvious
  • Can be performed by somebody with sysop privileges
  • Less likely to mess up whole project (such as might happen if MediaWiki:Monobook.js is edited with the wrong syntax)

Disadvantages

  • Lack of hint text (is it really that important?) Note that even this may be fixed in a later version of MediaWiki software.

Sidebar Syntax

It is important to note that either naming convention can be used to help rearrange the order of the links on the sidebar, and both may be used simultaneously. You are not restricted to sticking to one naming convention.

MediaWiki software uses the unordered list syntax for keeping track of items in the sidebar. Major sections are delimited by a single asterisk (*) and individual links by two asterisks (**). Additional levels may be added depending on the nature of the link, but only affect indentation of links on the sidebar and should be used very sparingly.

Following the asterisk, the link is added by using the format of URL (or page link) followed by the public description of that link. There is no need to use the [[ or ]] brackets to form these links as the MediaWiki software will do this automatically.

Here is an example of a modified sidebar from the default:


* navigation 
** mainpage|mainpage 
** portal-url|portal 
** currentevents-url|currentevents 
** helppage|help 
** sitesupport-url|sitesupport
** Project:Village Pump|Village Pump

* tools
** recentchanges-url|recentchanges 
** randompage-url|randompage 

Note here that Recent Changes and the Random Page links have been moved to a completely separate section. As an example, a link to the main project discussion page has been added.

Other text or even images can be added to this sidebar, but you should be careful as it is used on every project page and has a major draw on server resources as a result. This is something that should be kept very simple and neat as a guideline.

  • Note: Keep in mind that these changes will be very visible to all participants of the project, and that experimentation with this feature is likely to confuse new users to the project. On larger projects with many users, you should try to get a general feel for what changes need to be made from the users rather than arbitrarily make changes on a whim.


Importing

Special:Import is a feature designed to accompany Special:Export. Importing allows manual or automated copying of a page from a remote project into another project. This is not necessarily available on all wikis.

If the feature is disabled on a particular wiki the page will instead say "No transwiki import sources have been defined and direct history uploads are disabled." If it is available, however, importing will have one of two appearances:

Importing from transwiki import sources

The Special:Import interface seen on Wikimedia projects.


This is the interface used on Wikimedia projects (other than those that still have it disabled entirely). For this interface, choose the one-letter code that represents the project to import from (w = Wikipedia, b = Wikibooks, etc.); the ones listed will depend on what projects have been added as import sources. Projects that do not have their codes on this list cannot be imported from. Next, enter the page name. Only one page can be imported at a time using this interface. Talk pages are not automatically included and must be imported separately. Unchecking "Copy all history versions for this page" will result in only the current revision being carried across (similar to Special:Export's "Include only the current revision, not the full history" feature). "Transfer pages into namespace:" allows you to choose a namespace; for a page that needs cleanup, using the Transwiki namespace, if there is one, is probably a good idea.

In the case of Wikimedia projects, the projects from which imports can be made must be specifically requested from bugzilla. The following Wikimedia wikis have automated importing enabled.

Importing from XML

The Special:Import interface seen outside Wikimedia projects.


Used on many wikis, this interface is less automated but more powerful. Pages must first be obtained from the source wiki's Special:Export. This variant of the interface does not feature a "Copy all history versions for this page" checkbox; this must instead be done with Special:Export's "Include only the current revision, not the full history" checkbox. Use "Browse..." to select the saved XML file and then click "Upload File" to begin the upload. The time this takes will vary depending on the size of the XML, how busy the server is, and your Internet connection speed. If all goes well it will say "Import succeeded!", and if not the error message will indicate what went wrong.

Unlike the Wikimedia version pages cannot be directed into a new namespace from this interface, however it can be manually changed with a text editor; for example if there is a "News:" namespace on the target wiki, changing the <title> entry "Foo" to "News:Foo" will automatically direct it into the "News:" namespace.

General Notes

  • pages in the File: namespace can be imported, but the images attached to them can't (although if it is a Wikimedia project and they are on Wikimedia Commons they will automatically be sourced from there).
  • pages are automatically attributed to users with the same username. Note that if a user has been renamed with Special:Renameuser and an edit under their old username is subsequently imported it will be attributed to the old username, not their new one.
  • If you import to a page name that already exists the most recent revision of the now merged history will be the one displayed, so be sure to check the pages to make sure a wanted revision hasn't been replaced.
  • when importing from an import source the action is logged on Special:Log/import (both where the XML came from, and how many revisions were imported) and the action shows up on Special:Recentchanges. XML imports are also logged, but only in MediaWiki 1.9.x. With earlier builds means the page won't show up on Special:Recentchanges unless it is more recently edited than some of the wiki's current content. Note that neither method logs the page on Special:Newpages unless its oldest revision is newer than some of the wiki's own content.
  • Sometimes the Special:Log/import logging will fail to register an imported page. Additionally, some projects maintain manual transwiki logs (usually in a Transwiki: namespace).
  • when using Special:Export, always check the very bottom of the XML. If the last line isn't </mediawiki>, don't use it.
  • if you import XML of a page that has already been imported there will be duplicate revisions in the history. This may or may not apply to the transwiki import sources method.
  • by default, the XML importing version of the interface limits filesizes to around 1.4 megabytes. This limit can be changed by the server admin (or you in php.ini in maxuploadsize=).


Block

Block prevents the user of a certain account or IP address from editing for a determined period of time.

Block tool.jpg

Range blocks

The MediaWiki software allows sysops to block entire ranges of IP addresses. Using CIDR notation, enter an IP range between /16 and /31 (inclusive; MediaWiki does not support blocking larger ranges). If you are unfamiliar with CIDR and binary arithmetic, then you should not block ranges.

A properly-applied range block will remove editing privileges from all persons who connect from an IP in the affected range. As a result, it may unintentionally block valued contributors, so it may be worthwhile to consult a checkuser before applying a range block.

Range blocks are a drastic measure, and should only be used for brief periods as a last resort. Poorly-applied range blocks can shut out entire nations!

Projects


Edit History

Edit History

See also: Meta: Help:Moving a page: Fixing cut and paste moves
See also: Wikipedia:How to fix cut-and-paste moves
See also: Help:Moving a page: Fixing cut and paste moves
WARNINGundoing this procedure is extremely tedious. Please read above links carefully and be sure you actually want to do this – it can get very messy and complicated.

To merge the edit history of two or more pages or to split up the edit history of single page into two or more separate pages you will need to use the Delete and Undelete tools.

Note that you can only merge or split edit histories – you cannot copy them (without the Duplicator extension), i.e., cannot create two duplicate copies of the same edit history.

Edit histories should generally be merged if pages in the main namespace copy contents from pages in the main namespace of a sister Wikimedia project in order to comply with the GFDL license. For similar reasons if a page in the main namespace is split into several pages such as from becoming big or due to reorganization it is generally a good idea to split the edit history among the new pages.

Some Wikimedia projects may include additional namespaces in which edit histories should be merged or split up.

  • Wikibooks - Cookbook

Merging

Merging the edit histories of two or more pages is easy. Follow these simple instructions to do so. Suppose you wish to merge "Foo" and "Bar" (and maybe "Bar 2") to "Foo".

  1. open the page you wish to merge the edit histories into and click the edit link – you will keep this open for a while. ("Foo" → Edit)
  2. open a window for each page whose edit history you plan to merge with step 1. ("Bar", "Bar 2")
  3. click on the move link of each page you opened in step 2. ("Bar" → Move)
  4. enter into the "To new title" field box for each page, the page name from step 1 and confirm deletion of the existing page. (Move "Bar" to "Foo"; confirm delete "Foo")
  5. close all windows open in step 2 and in a open a copy of the page in step 1 in a new window. (Close "Bar", "Bar 2", open a new "Foo")
  6. click on the history link and then the view or restore link. ("Foo" → History → View/Restore)
  7. confirm you wish to restore edit histories. (Confirm restore "Foo" History)
  8. go back to the page and click the edit link. ("Foo" → Edit)
  9. copy and paste the contents of the edit box in step 1 into the edit box in previous step. (Copy and paste from old "Foo" to merged "Foo")
  10. enter "restored current version" into the summary box and click save page to restore back the current version. (Save!)


Protect

Protect prevents changes to a page by users below a certain user level.

  • Default: anyone can edit
  • Autoconfirmed: No IP editing, no editing by the newest accounts
  • Sysop: only editable by administrators

Pagemove permissions are "locked" by default to match the edit permissions, but can be unlocked to allow editing without allowing pagemoves, or in theory vice-versa (though there's rarely any reason to set it that way). This is often done to project namespace pages which should be editable by anyone, but should not be moved around.

Protecting the main page does not automatically protect the talk page.

What should be protected depends on the project, but generally:

  • Project and help namespace pages should generally be protected against pagemoves.
  • Policy pages may be protected
  • Widely used templates
  • Frequent vandal or spam targets (the different projects have vastly different rules governing when this should be done)
  • User namespace pages, on request of the user.
  • For a more general discussion, see Protected pages considered harmful (on meta).

Local Policies


Rollback

Rollback quickly reverts all consecutive edits by the most recent contributor to a particular page. The edit summary is automatically set to read "Reverted edit of A, changed back to last version by B", and the edit is marked as "minor".

The rollback tool should only be used to revert blatant vandalism. It should not be used to revert good-faith edits, to resolve content disputes, or to enforce a particular version of an article.

The rollback tool may remove constructive edits, and it may also leave earlier vandalism intact. As a result, after using the rollback tool, sysops should always check recent revisions and ensure that all disruptive edits have been reverted and all constructive edits restored.

Finally, after using the rollback tool, sysops should leave a note on the appropriate User talk: page and explain why rollback was used. Many "vandals" are simply new users who are unfamiliar with the ways of the wiki; by gently correcting them, a good sysop may lead them to contribute positively.

If you are an administrator you can use bot rollback, which will treat rollbacks as bot edits so they don't flood recent changes, good if a vandal bot comes and vandalizes lots of pages. To use this, you need to go to the user's Special:Contributions page and put &bot=1 at the end of the url, like this, http://en.wikipedia.org/w/wiki.phtml?title=Special:Contributions&target=SomePersistentVandal&bot=1. You can then click the rollback buttons on the user's contribution page so that the rollbacks don't flood recent changes.


Special pages

Special pages are available to all Wikimedia users from a link on the sidebar. Administrators can access some special pages not available to non-administrators:


Editing in the MediaWiki Namespace

Editing pages in the MediaWiki namespace is one of the more complicated and serious abilities of an administrator, and must be undertaken with extreme caution because it can change the appearance of the entire website.

  • MediaWiki:Uploadtext – Text appearing on the upload page, including warnings about images without copyright information, etc.
  • MediaWiki:Sitenotice – Text that appears at the top of every page on the site, just below the tabs
  • MediaWiki:Copyrightwarning2 – The copyright warning that appears below the edit window.
  • MediaWiki:Common.css – Style sheet (CSS) defining site appearance, common to all skins
  • MediaWiki:Monobook.js – Contains scripts in JavaScript
  • MediaWiki:Edittools – Provides list of special characters appearing below edit box and save/preview buttons
  • MediaWiki:Sidebar – Defines 'navigation' box in top-left corner, and allows for the creation of other navigation boxes (such as the 'community' box on wikibooks)
  • MediaWiki:Revertpage – Text added to the edit summary when using the rollback tool.
  • MediaWiki:Monobook.css – Style sheet (CSS) defining site appearance in default skin.
  • MediaWiki:Licenses – List of available licenses for images/files appearing in a drop-down list on file upload page.
  • MediaWiki:Newmessagesdifflink
  • MediaWiki:Mainpage
  • MediaWiki:Sharedupload – Appears on the page of any image or file used in wikibooks but actually located on commons. Most wikis use a template linking to the commons page.
  • MediaWiki:Tagline – The text appearing just below a page title (on wikibooks, this currently reads "From Wikibooks, the open-content textbooks collection").


Aspects of Being a Responsible Administrator

Introduction

Sysops, more commonly known on various projects as administrators or custodians are users that have access to restricted software tools used for maintenance. These tools are not available to all editors because the tools can be used to create a rather more serious level of disruption than the generally-available editing tools. It's important that a track record of good-faith editing be established first before granting adminship.

The different Wikimedia projects have different ways of vetting users who request the tools. On most projects this is done through an election process, but new projects (which do not have any bureaucrats, who have use of the "makesysop" tool) need to make the requests on Meta, and at least some projects (such as en.Wikiversity) use a mentoring system rather than open elections.

Getting to know how the tools work is fairly easy, as for the most part they're quite intuitive thanks to our thoughtful developers and years of trial and error. Knowing how and when they should be used is a different issue, since there are a lot of things that should not be done, and each wikimedia project will have different policies and guidelines regarding their use.

The golden rule is simple: never use an administrative tool unless you are sure it's the right thing to do. If in doubt, just leave it to a more experienced administrator, or just ask for advice.


Being a Project Leader

The process that made you an administrator on the MediaWiki project that you are working on has made you one of the most visible members of that community. Either you are starting out a brand new project, or you have been elected from your peers to take a larger role in moderating discussion.

Becoming an Administrator

Starting a Completely New Project

If you have decided to take the path of starting a completely new project from scratch, as the founding member you are usually given administrator rights to get things going right away, and often even more. This founding user is by definition the older person on the project.

Other sections of this book will deal with how to get a project to grow, especially just simply trying to get something started at all, but it is important to remember the implications of your position as the founder of a project. Generally your opinion is going to be strongly considered, and you have available to you the ability to take drastic steps in controlling the community... particularly if you also have direct access to the physical computer equipment that is running the project.

Keep in mind that most people will have a sort of reverence toward the founder, even if the founder decides to go into semi-retirement and leave the main organization of the community to other people. This is deserved in part because any on-line community only gets to where it is at because of the efforts of this founder. It takes quite a bit of effort to get something going in the first place, and with enough different websites around the world nobody is simply going to get to a website simply because it exists. This is in particular where the leadership principles come into place on a social level.

Often what is needed is simply a model example for what you as a founder want the project to look like. In the initial stages, you need to demonstrate leadership both by showing examples, and gently trying to remind people when inappropriate content is being added. How permissive or how abrasive you are toward new users is going to have a huge effect on the growth and popularity of the project, regardless of the merits of what you do or the quality of the content.

It is also important to realize that you can't be pleasing to everybody on every point. The most successful leaders will always have detractors and possibly out right enemies. The successful leader will know when they are being abusive and need to pull back, and when perhaps they have gone too far and created too many enemies that should be their friends. Unfortunately, the only real way to learn how to do that is simply experience and getting opportunities to practice leadership ideas.

Being Chosen by Your Peers

There are several ways that you can become an administrator, but most likely you have been chosen by being an outstanding contributor to the project. Often this selection is made through some sort of formal nomination process where other members of the community also have a chance to support your nomination in a sort of election. The exact process is something that is specific to the project you are working on, but you should take the nomination as a sign of recognition that you have already done an outstanding job.

In this situation, you are going to need to learn the policies and procedures of the project in a little more depth. This is not exactly an easy situation, and it is surprising how many policies that you didn't realize existed prior to becoming an administrator, even if you were a very active user previously.

Moderate, Don't Dominate

One aspect of becoming an administrator is that you are now a part of the group that is enforcing policies. If you have been vocal in the past, you need to tone down some of the arguments from the style you have used in the past, understanding that you need to help moderate the tone of the discussions you are involved with.

As a general philosophy, it would be wise to not immediately implement drastic changes to the project, especially in areas that require the extra privileges that come from being an administrator. Seek input from the other people involved in the project before you make any major changes, and implement community decisions even if it goes against your own personal opinion.

Also, don't hesitate to admit that you might be wrong occasionally. You will be making mistakes along the way as an administrator, especially if you are new to doing this sort of task. Discover the different ways you can communicate to the other users in your community, including Water Cooler type pages, e-mail, user talk pages, article discussion pages, project e-mail lists, phone numbers and instant message accounts.

Innovation and Project Development

One aspect of project leadership also takes on the social responsibility of project innovation and development. It is likely that there was always some task you felt wasn't being adequately dealt with in some manner before you became an administrator, and now you have the opportunity to try and fix things in a way you couldn't before.

Innovation might also take many forms. You can start new sections of your project, or try to fill in holes that weren't covered before. In addition, if you were elected to become an administrator it is likely that you have a small group of supporters already who are interested in what you are doing, and it is possible to help motivate those supporters to work together and get some things accomplished as well.


Recent Changes Patrol

The Recent Changes Patrol consists of examining recent edits to the wiki for test edits, blanking of pages, vandalism, and other negative changes. Each wiki has a Special:Recentchanges page; most wikis have a link to "Recent changes" at the left. Any user can use this page and help revert vandalism. However, only sysops can block users and delete bad pages. Thus it is important for sysops to sometimes inspect recent changes and stop persistent spammers and vandals.

Every recent edit appears in Recent Changes. Thus, if a page is edited twice, both the top edit and previous edit appear. Thus, it is not possible to hide an edit by making another edit.

Some wikis let users mark edits in recent changes as patrolled edit. The idea is to mark every edit that does not harm the wiki. Some wikis let any user mark patrolled edits, but at Wikimedia, the wikis restrict it to sysops. On some Wikimedia sites, like Wikipedia, this feature is disabled.

Type of bad edits

  • Creation of new speedy deletion candidates. Many wikis have a deletion policy, such as Wikibooks deletion policy. Sysops are in position to delete obvious junk pages that some users create.
  • Creation of pages with bad names. Many Wikimedia wikis have naming conventions, such as Wikibooks naming policy. A sysop can move the page to a better name (if the page is not useless), then delete the redirect. For example, a page titled with ALL UPPERCASE LETTERS is probably bad.
  • Spam. Some users like to add WikiSpam to wikis, adding lots of links to their own web sites so that their search-engine rankings increase. This tactic is more effective on more popular wikis, and Wikimedia hosts most of the largest and most popular wikis. Thus Wikimedia wikis are favorite targets of Spam. A common tactic of Spammers is to use CSS to hide spam so that readers do not see it, but search engines do. However, such spam becomes obvious when editing a page or viewing a diff.
  • Blanking. Bots or vandals that delete chunks of pages, apparently at random.
Clipboard

To do:
MediaWiki Administrator's Handbook

Type of users

There are generally five kinds of users that make edits.

  • Frequent contributors make the most edits. Often, these users are most recognisable by users who patrol the recent changes. Thus, it is least likely that any user will check these edits. A user that does try to check edits is likely to only pick a few edits at random, and not examine the others.
  • Blue-shirt contributors have names that appear in blue, meaning that they have user pages. A user is more likely to check red-shirt contributors than these.
  • Red-shirt contributors have names that appear in red, because they have no user page. Many of these contributors are new users with good intentions. However, vandals and sockpuppets who want to hide their IP address or use the page-move feature often become "anonymous redshirts". [1]
  • IP addresses edit the wiki without creating an account. These users like to fix errors in pages. However, spammers tend not to create accounts. Thus users tend to check these edits most carefully and often. IP addresses cause so much trouble that sysops block them more often than other users. [2]
  • Brand new contributors are people who have their account creation very close to often a large number of contributions. These deserve some special attention because even when they are not doing vandalism, they are not likely to be familiar with policies on the project or do quite a bit of experimentation. Be extra careful with these people as they are more likely to become the regular contributors of the future and are the source of new help for the project. Still, watch carefully for vandalism from these editors or for sockpuppeting, especially if they create a user page as one of their first edits.

Mass reversions

Some users are so bad that sysops block the user, then revert all edits made by that user without checking them.

References


Spam and Spammers

On wikimedia wikis, spamming is the addition of unwelcome commercial links and/or language, either added to already existing pages, or added as an entire page.

The various projects have vast differences in what is defined as spamming, and what to do about it.

Extension:ConfirmEdit

The most common way to protect your wiki from spam is to use ConfirmEdit extension. Extension:ConfirmEdit offers several variants of capchas:

SimpleCaptcha

SimpleCaptcha is the default captcha in ConfirmEdit. This captcha prompts user to solve a simple math question to prove that they are not spam bots:

SimleCaptcha screenshot.png

SimpleCaptcha can be easily bypassed by simple script, so it is recommended to use more complex capchas.

FancyCaptcha

FancyCaptcha is a traditional graphic captcha, that prompts user to type letters that appear in the picture:

FancyCaptcha screenshot.png

To create captcha's images you will need to run a python script. But you will not need python on your web-server to use this captcha, you may create images on your desktop, for example, and just copy them to your wiki web-server.

MathCaptcha

MathCaptcha is another captcha mechanism for ConfirmEdit. To run it you will require TeX support within your MediaWiki.

ConfirmEdit Notes

Note that ConfirmEdit is quite sensitive to version mismatch. The last version of ConfirmEdit should work well with the last version of MediaWiki. If you want to use ConfirmEdit with a legacy version of MediaWiki, you might spend a lot of time looking for a matching version of ConfirmEdit in the SVN repository. Some version matches are mentioned on the extension home page but not all of them.

Extension:ReCAPTCHA

ReCAPTCHA is a captcha extension for Mediawiki. It offers strong visual and audio capchas.


How to Handle Copyright Violations

Copyright Violations -- usually referred to as "Copyvios" for short -- occur when copyrighted text or files are added to a wikimedia project. How this is dealt with depends on the type of material that was copied.

Copyright compatibility

Wikimedia projects are copyrighted using the GFDL. Some other copyrights are compatible with the GFDL for images and other files.

Copyrights that restrict the use of materials for any purpose are incompatible with the GFDL, and so including them in a GFDL document results in a violation of the material's copyright.

Image copyrights

All images uploaded to wikimedia projects must have their copyright status announced using one of the provided templates.

Public Domain, GFDL, and most Creative Commons licences are permitted.

"Fair Use" images are permitted on some projects, but not others.

Text copyrights

These can be harder to ferret out.

Text that is copied and pasted from other websites is the most common problem. In many cases the user who contributed the material will add a link to the source website. Most users are not familiar with how the copyright laws apply, so they should be dealt with kindly (but firmly).

Text from printed materials is less common, but much harder to catch.

Text copied from other wikimedia projects can be very difficult to catch.


Wikimedia-specific

Asking for help

When uncertain about whether and how to use a tool, there are various venues both within and associated with each project where assistance can be found.

By project (with a link to the project admin list):


Wikimedia projects

Projects


Pages to watch

These are pages administrators may wish to add to their watchlist or check frequently on individual Wikimedia projects.

Wikibooks

  • Bulletin Board - Wikibooks news, such as policy changes or new features.
  • Reading Room - where people needing help or general discussions with administrators happen.
  • Candidates for Speedy Deletion - frequently needs checked for pages that should be deleted, kept or changed to Requests for Deletion.
  • Requests For Deletion - pages people think should be deleted, frequently needs checked to see if pages should be kept or deleted.

Wikipedia

Wiktionary

Wikiquote

Wikinews

Wikiversity

Last modified on 24 August 2012, at 21:42