User:AttemptToCallNil/Admin guide

If you are reading this, you are probably a newly-appointed administrator on a Gamepedia wiki. If so, congratulations! You have been granted an additional set of permissions to help you make your wiki a better place both for its readers and for its editors. This guide is intended to help you use your position responsibly.

Meaning of "administrator"
On most Gamepedia wikis, users with access to moderation tools have the wiki guardian role, while on some wikis, the standard MediaWiki administrator role is used instead. On wikis using the standard role, some administrators may also have the bureaucrat role that lets them promote and demote administrators.

In this guide, wiki guardians, administrators, and bureaucrats are all called just "administrators".

General guidelines
On public and open wikis, consensus is preferred to hierarchy. While this doesn't mean decisions are based on vote counts, this does mean that you should discuss a problem and try to find an optimal solution. Making a decision unilaterally and imposing it upon others is ill-advised.

Your administrator role makes others expect you to take responsibility for your community. That includes keeping discussions civil, helping make the articles as complete, accurate, and easy to use as possible, and other things. The following principles are thought to be "best practices" for administrators:


 * Assume good faith
 * When there's doubt about whether an edit was intended to help the wiki, assume it was and treat the editor that way. If an edit is obviously abusive, feel free to take appropriate action, but where's there is doubt, give the editor the benefit of that doubt.


 * Administrate users, not content
 * In content disputes, an administrator's voice should be viewed like that of any other user. Administrators should try to help others reach agreement peacefully, and only impose their opinions if the community fails to achieve consensus. Administrators may offer their opinion as well – while taking care not to sound as though they're enforcing it.


 * Be light-handed
 * Try to settle problems with the minimum possible use of administrative powers. For example, consider edit wars, which is when two or more good-faith users keep reverting each other on some page. To stop an edit war, try warning the warring users first and getting them to discuss the problem. This applies especially if you only need to get their attention. You might also need to briefly protect the page. Try to use blocks only when nothing else works.
 * You can, of course, block clearly bad-faith users at once. This includes spammers, vandals, and more. But even then, don't block IP addresses indefinitely or for too long. IPs change owners over time, and the longer the block, the more likely it is to affect good-faith editors. In most cases, blocking IPs after just one bad-faith edit is not useful; some people consider 3 recent edits a good rule of thumb for whether to block an IP. Should your wiki have major problems with malevolent editors, contact GRASP or your wiki manager.

Wiki design rules
Article information isn't the only part of a wiki. Having a visually appealing, easy-to-understand, and lightweight design is no less important. As such, the editor communities are encouraged to improve the appearance of their wikis. Administrators can change the design significantly for all visitors, however, there are some wiki design rules that you are required to follow. In particular, do not change or hide any Gamepedia or Fandom sections or ads. If you're not sure if something is allowed, contact staff via one of the methods below.

For information on how to edit the wiki skin, visit the skin customization page on the Help Wiki.

Where to request features and ask questions
If you wish to suggest a wiki feature, please contact staff via one of the means below. Gamepedia gets new features and improvements all the time.

For questions or concerns about wiki design, please visit our Gamepedia Support page or email [mailto:Community@Gamepedia.com Community@Gamepedia.com]. In addition, we also have a Discord server, and you may find help there.

Blocking
Blocking an account, IP, or an IP range makes the target of the block unable to perform most actions on the wiki. Blocked users can still read pages, but they cannot create, edit, or move pages, nor can they upload files. A block also disables all administrative permissions, except the abilities to block and unblock (including the ability to unblock self).

Blocks should be used not to punish people who misbehave, but to prevent them from harming the wiki. See Blocking guidelines for more details on blocking individual users.

By default, blocks make a user unable to edit any page on the wiki. A newer feature, partial blocks, lets admins prevent users from editing only some pages or namespaces.

To apply or change a block, use the form on the special page Special:Block. This form is usually reached from a user's user page, their contributions page, the recent changes page, or the watchlist.

When applying or changing a block, you need to specify appropriate settings first.


 * 1) Specify the IP address or user to be blocked. Fill in the "User" field of the form with the target of the block: the username of an account, the IP address, or the IP range. Note that a username can be blocked even if there is no such account, so be certain you have the correct username.
 * 2) * If you got to this page via a "block" link for some user, this field will be filled with the username or IP address automatically.
 * 3) Specify a duration for the block. You can select a predefined duration from the dropdown box labelled "Expiry", or you can enter a custom value, using the GNU standard format, in the "Other time" field.
 * 4) * To change what durations are predefined, edit the MediaWiki:Ipboptions system message.
 * 5) * Prefer blocks to be as short as needed to stop the disruption. 1 or 3 days for a first-time IP vandal should be enough. Do not block IPs or ranges for longer than 2 weeks; contact GRASP or your wiki manager if you feel that long-term abuse warrants a longer block.
 * 6) * The "Other time" field can use a lot of date formats. However, you should prefer using more common and understandable ones. "1 year, 6 months" is fine. "2020-01-01T00:00:00" (the ISO format) is good too if you need to write when a block expires instead of how long it lasts. On the other hand, "8.725 fortnights" should be avoided.
 * 7) Specify a reason for the block (strongly recommended). This reason will be shown in public logs (and therefore will provide clarity to other users and administrators). The blocked user will see the reason as well if they attempt to edit a page.
 * 8) * You can specify only a predefined reason from a list (MediaWiki:Ipbreason-dropdown), use one of these reasons with a custom comment, or write your own text entirely.
 * 9) * The more descriptive, the better (especially when using some of the blocking options below). If you can, provide evidence, especially when the blocked user has good contributions as well.

Click "Block this user" to apply the block. All blocks are recorded in the block log, and all currently active blocks are listed at the list of active blocks. Global blocks can be viewed on Special:GlobalBlockList.

Blocking options
The blocking page has several important options associated with the block:
 * 1) In "Actions to block":
 * 2) Account creation: Prevents the blocked user, IP, or IP range from making new accounts. On by default.
 * 3) * This option should generally be kept on. Disruptive users often make (extra) accounts to evade blocks.
 * 4) Sending email: Prevents the blocked user(s) from using Special:EmailUser to send email to others. Has no effect for IP blocks that won't affect registered users. Off by default.
 * 5) * The default option (allow emails) is useful if you wish to let the user appeal to you in private. Disabling emails is useful if this feature is abused, or if there are substantial reasons to suspect such abuse may take place.
 * 6) Editing their own talk page: Prevents the affected user(s)/IP(s) from editing their talk page while blocked. Off by default.
 * 7) * This should typically be left off to provide an opportunity to appeal. Talk page access can be revoked if the permission is abused.
 * 8) In "Additional options":
 * 9) Automatically block the last IP address used by this user, and any subsequent IP addresses they try to edit from (or "autoblock" for short): Only applies when blocking accounts. Will automatically apply 24-hour blocks to IPs this user logs in from. On by default.
 * 10) * This should typically be left on to not let the user make further bad edits from their IP. Disable autoblocking if you know the user you are blocking shares an IP with a good editor.
 * 11) * Autoblocks are listed at Special:AutoblockList. Autoblocks are identified by numeric IDs to prevent them from revealing the IPs of editors.
 * 12) Prevent logged-in users from editing from this IP address: Only applies when blocking IPs or IP ranges. If checked, registered users will be unable to edit from the IP(s). Off by default.
 * 13) * Should not generally be enabled, unless you're blocking an open proxy or a Tor exit node (but see Extension:TorBlock).
 * 14) * This option has no effect on a block of a registered user, but it does modify any autoblocks (see above) caused by that block.
 * 15) Add new or modify existing global block: If selected, the IP or user is globally blocked on all Gamepedia wikis. Cannot and should not be used on IP ranges. On by default.
 * 16) * Vandals and spammers often switch to other wikis when blocked. As such, blocks should generally be kept global, unless the issue with the user is unique to your wiki, and they can be expected to make good edits elsewhere.
 * 17) * Due to a bug, to make a local block global, you need to unblock, then re-block with this box checked.

Unblocking
To lift a block, visit the list of active blocks. Find the IP address or registered user account you wish to unblock in the list (you can enter the address or name in the "search" field to help you find the entry), and click the "Unblock" link displayed to the right of the block's expiry time.

This will lead you to a confirmation page. Enter the (optional) reason for unblocking in the "Reason" field, and click "Unblock this address" to remove the block. All unblocks are recorded in the block log.

Deleting
When deleting a page, make sure you check "What links here" and ensure that the deletion does not unwantedly break links on other pages.

Don't delete an image you're not sure is unused: images used as part of the wiki's design (skin) will not show up as used or linked. For that reason, it's preferred to have a placeholder page that lists images used in ways the software cannot detect.

Hiding individual revisions
Sometimes it is needed to suppress the visibility of a single revision only (its text, its summary, or the name of the user who made it). This operation, revision deletion, is allowed only for especially gross vandalism and sensitive information. If you see such revisions, especially if they involve private information, revert them immediately and contact your wiki manager to have them hidden.

If your wiki is one of the few that has bureaucrats, they also have access to the tool. Make sure they're familiar with the relevant policy.

Protecting
Protecting a page makes only users in a certain group able to change it in some manner. Protection varies in what actions are limited and to who they are limited.

Protection is mainly used for pages at a high risk of vandalism (such as the main page) or as a temporary measure to stop an ongoing revert war or a vandalism spree.

By default, there are two protection levels:
 * Semi-protection: Only registered users can edit the page. Any IP contributors will still be able to see the source code, but will be unable to make any changes.
 * Semi-protection can help for pages constantly damaged by IP edits if other tools can't work. If there is only one IP, or a small range, a short block can help. If there is a pattern to the bad edits, making an abuse filter can stop them.
 * Semi-protection is useless for moves and uploads. IPs can't perform either action anyway.
 * Full protection: Only administrators can edit the page.
 * Full protection should mainly be used on high-profile pages (such as the main page), pages that should never be changed by a non-administrator (such as key templates or images used in site design), or as a very temporary measure to stopping a revert war. Please note that protecting a page does not mean endorsement of the state it's protected in. Try to keep full protection as brief as possible.

An uncommon variant of full protection is known as cascading protection. It affects not only the page, but also all images, pages, and templates included into it.
 * Cascading protection cannot be used with semi-protection.
 * This is an emergency measure. It is typically used to briefly protect a key page (usually the main page) if a change makes the images/templates used vulnerable. Try and avoid this option if at all possible, as it may protect templates used elsewhere (create copies of such templates and protect them instead).

While protection is most often used to prevent edits to a page, it's not all it can do. Protection may restrict moving pages, creating pages, and uploading (or re-uploading) files.

Move protection
On the protection page, there's a checkbox saying "Unlock further protect options". If you check it, you can restrict move access separately from edit access. Move protection is most often used on Project pages that anyone should be able to edit, but that should generally not be moved.

Create protection
If a page does not exist, it can be protected against creation just like an existing page can be protected from moving and editing. This is usually only done for pages that are frequent vandalism targets with no reason to exist.

Note, however, that bad-faith page creation may be better to handle via abuse filters or MediaWiki:Titleblacklist. Imagine that some vandal keeps creating the page "Badword", and you protect it. The vandal will just create "Badw0rd", "Bad-word", "Bаdword" (that's a Cyrillic letter А), and so on. Protection can only affect individual pages, so if you need to restrict creation of any pages matching a pattern, it's not the tool for the job.

Protecting images
To protect an already uploaded image from being replaced with a newer version, you can use the Protect button like with any other page. Upload protection is common for images used on the main page, in widely used templates, or in site design.

You may also find that a file with some name should never be uploaded. Nonexistent files can be protected from uploading just like any other pages. Please note, however, that the same caveat as with create protection (see above) applies to files. Various devices and software may create files with uninformative titles matching a pattern (such as a timestamp: e. g. "File:2077-10-23 09:47.png"). You can't protect all such titles one by one, so a regex-based filter is likely a better solution.

Notes on protection
When used to temporarily stop a revert war, protection may be viewed as an endorsement of that particular version. This is not the case. Be careful to remind other users of this and start a discussion on the article's talk page to help resolve the conflict.

Rollback
Any user can undo edits on a page by going through its history. Administrators can also use the rollback tool to expedite the process. To revert the edits of one user to the last version by the previous editor, click the rollback link on the page history, the user contributions list, or on the diff page. The reversion will be marked as a minor edit and given an automatic edit summary based on the contents of MediaWiki:Revertpage. Rollback should only be used for clearly disruptive edits. If an edit is not such, assume good faith and leave a polite revert summary.

Impartiality
Many active administrators also often edit the wiki. This can cause conflict of interest. For example, if people start personally attacking you for one of your edits, blocking them yourself makes it look like you're using your admin tools to control wiki content.

Thus:
 * If you're editorially involved in a conflict, ask another administrator to intervene.
 * If you're personally involved with a member of a conflict, ask another administrator to intervene.
 * Only mention your administrator status when justifying or explaining an administrative action.

However, the first two points assume some other administrator is ready to handle your request. If there are no other admins, if they are inactive, or if the case is urgent, you will have to contact your wiki manager or handle the problem yourself.

Cultural reverence of administrators
Ideally, wiki administrators should only have as much say in the editorial process as any other editor. However, the voice of an admin invariably will carry more weight than that of a non-admin. This extra admin weight is not their fault, it stems from the culture of the world. People tend to look up to those of a higher "rank", such as administrators, and are less willing to dispute them. Every administrator should be careful to avoid abusing this extra editorial power that comes from reverence. Specific suggestions on how to do this are, by nature, controversial – thus, if you disagree with any suggestion below, please take your case to the talk page.

These guidelines can help you avoid abusing your accidental admin authority. They are listed (roughly) from easiest to hardest to follow.


 * Should someone bring up your admin role in an editorial discussion, negate its importance.
 * Explain your actions and opinions in more detail than usual. Post in talk pages when others might disagree with your actions. This is good advice for everyone, but it's crucial for administrators. If you leave the summary empty for a major edit, it can look like unilateral action.
 * Remind people that you are (mostly) just another user. For example, ask others to revert you if they disagree. You can say that in a summary or in your talk page post. People always may undo edits they don't agree with, but saying that plainly can help them overcome the fear of reverting an administrator.
 * When some article is the subject of an admin action you make, avoid being involved with its content for some time.

Other useful notes

 * Watching the admin noticeboard can help keep you aware of current requests. You can add it to your watchlist to get notified for new posts. Though keep in mind that, sadly, people often use such pages for issues that actually don't need admin attention.
 * Administrators should also let other users email them through the "Email this user" link on their user page. To make sure your email is accessible, go to Preferences, open the "Notifications" tab, and check that "Allow other users to email me" is on. This lets the community discuss issues (blocks, protections, etc.) outside of the view of the general public. If you get an email report of an issue that needs input from others, you should post it as appropriate.

Announcements
If it's needed to announce something to all wiki visitors, administrators can do this via the site notice. Adding content to the site notice makes an announcement appear at the top of all wiki pages, for anyone viewing them, until dismissed by the user. Site notices are usually temporary, and you should turn them off when they are no longer needed. To disable a site notice, revert it to its default content, a single hyphen.