GNU Free Documentation License

February 2019
Please refrain from making unconstructive edits to Wikipedia, as you did at O. Your edits appear to constitute vandalism and have been reverted. If you would like to experiment, please use the sandbox. Repeated vandalism may result in the loss of editing privileges. Thank you. Favonian (talk) 10:03, 27 February 2019 (UTC) You may be blocked from editing without further warning the next time you vandalize Wikipedia, as you did at O. Favonian (talk) 11:30, 27 February 2019 (UTC)

May 2019
Hello, I'm CLCStudent. I wanted to let you know that one or more of your recent contributions to Wikipedia:Relevance have been undone because they did not appear constructive. If you would like to experiment, please use the sandbox. If you have any questions, you can ask for assistance at the help desk. Thanks. CLCStudent (talk) 13:48, 7 May 2019 (UTC)
 * If this is a shared IP address, and you did not make the edits, consider creating an account for yourself or logging in with an existing account so you can avoid further irrelevant notices.

Please refrain from making unconstructive edits to Wikipedia, as you did at Wikipedia talk:Edit filter/False positives. Your edits appear to constitute vandalism and have been reverted. If you would like to experiment, please use the sandbox. Repeated vandalism may result in the loss of editing privileges. Thank you. CLCStudent (talk) 13:49, 7 May 2019 (UTC)
 * If this is a shared IP address, and you did not make the edits, consider creating an account for yourself or logging in with an existing account so you can avoid further irrelevant notices.

Please stop your disruptive editing. If you continue to vandalize Wikipedia, as you did at Wikipedia:Requests for page protection, you may be blocked from editing. CLCStudent (talk) 13:51, 7 May 2019 (UTC)
 * If this is a shared IP address, and you did not make the edits, consider creating an account for yourself or logging in with an existing account so you can avoid further irrelevant notices.

Hello, I'm CLCStudent. I wanted to let you know that one or more of your recent contributions to User talk:51.219.137.228 have been undone because they did not appear constructive. If you would like to experiment, please use the sandbox. If you have any questions, you can ask for assistance at the help desk. Thanks. CLCStudent (talk) 13:29, 24 May 2019 (UTC)
 * If this is a shared IP address, and you did not make the edits referred to above, consider creating an account for yourself or logging in with an existing account so that you can avoid further irrelevant notices.

Protected edit request on 19 August 2019
The page is created only for the information of the person who is involved in the dubbing industry more than 2 decades. The page is to display the works and the basic information of the dubbing films, which will be easy to the viewers who will try to know about the latest films in regional languages. This is not a promotional page or not used for any commercial purpose. Gowthamgda (talk) 07:09, 19 August 2019 (UTC)
 * ❌. This page is for changes to the speedy deletion template. If you want to contest the speedy deletion of a certain page, you need to state this on its talk page. Regards So  Why  07:24, 19 August 2019 (UTC)

Db-g11 white-space
I have created Db-g11/sandbox with a  to fix the horizontal scroll problem. Any objections to pushing it live? 21:05, 2 September 2019 (UTC)
 * What horizontal scroll problem? Why does it matter on a page that is about to be deleted in any case? -- Red rose64 &#x1f339; (talk) 22:36, 2 September 2019 (UTC)
 * Do you object to a trivial change that fixes the display of an informational template or not?  00:25, 3 September 2019 (UTC)
 * Could you provide more detail on the issue? I'm not seeing it. --Bsherr (talk) 00:53, 3 September 2019 (UTC)
 * The sentence that reads "However, the mere fact that a company, organization, or product is a page's subject does not, on its own, qualify that page for deletion under this criterion. Nor does this criterion apply where substantial encyclopedic content would remain after removing the promotional material as deletion is not cleanup; in this case please remove the promotional material yourself, or add the advert tag to alert others to do so" displays with, causing the template to stretch to vastly wider than most screens will show; that's a 2424px wide sentence (at  ) with an attempted 20% of the available page width dedicated to margin (10% either side) and some little extra padding. The result is a requirement to scroll sideways to read the information. Viewing Db-g11 on anything but an uncommonly wide monitor or an uncommonly dramatic negative browser zoom will show the problem. Users unfamiliar with the content of the template should not be expected to scroll sideways to read it. By adding a  container to the sentence, with   fixes the problem as can be seen clearly when viewing Db-g11/sandbox.   02:46, 3 September 2019 (UTC)
 * Apparently my own user CSS is applying the . No wonder you can't see the problem. Never mind *derp*.   02:53, 3 September 2019 (UTC)
 * Ah, very glad you've got it sorted out. I was just dragging my window wide to narrow and back, watching the text wrap, and wondering what I was missing! --Bsherr (talk) 02:57, 3 September 2019 (UTC)
 * Sorry about that. I don't even know why I have that rule (lesson to be learned: leave code comments). Something somewhere must have been annoying me at some point. I should probably take some time to review it all. Actually, I have 100% edit summaries so I might have said something useful at the time. Anyway, that's my problem now.  03:04, 3 September 2019 (UTC)

db-empty in portal space
When transcluded in the portal namespace, should Template:db-empty invoke Template:db-p1 (with the "|A3" parameter) or Template:db-p2? Both could equally apply and be referred to. (I don't think it should invoke Template:db-a3, which is only intended for articles.) — Preceding unsigned comment added by Geolodus (talk • contribs) 09:40, 10 September 2019 (UTC)
 * Imho, db-p1 with A3 as a parameter makes more sense since it's the more specific criterion to P2. Regards So  Why  09:56, 10 September 2019 (UTC)

There has been no discussion yet besides SoWhy's comment. Should the change (so it displays db-p1 with A3) be done? Geolodus (talk) 12:42, 16 September 2019 (UTC)
 * I concur with SoWhy. Thanks. --Bsherr (talk) 14:03, 16 September 2019 (UTC)
 * Can someone make the change then? I don't know template markup well enough to do it myself. Geolodus (talk) 16:27, 16 September 2019 (UTC)

Wikipedia is built around/with the principle that anyone can edit it, and it therefore aims to have as many of its pages as possible open for public editing so that anyone can add material and correct errors. However, in some particular circumstances, because of a specifically identified likelihood of damage resulting if editing is left open, some individual pages may need to be subject to technical restrictions (often only temporary but sometimes indefinitely) on who is permitted to modify them. The placing of such restrictions on pages is called protection.

Protection can be applied to or removed from pages only by Wikipedia's administrators, although any user may request protection. Protection can be indefinite or expire after a specified time period.

The most commonly used types of protection are full protection, which means that a page can be modified only by administrators; and semi-protection, which means that a page can be modified only by users who are logged in and whose accounts have been confirmed (any account is automatically confirmed if it has existed for at least four days and has made at least ten edits). Other types of protection are detailed below. Protected pages are normally marked with a small padlock icon in the top right corner of the article page; different color padlocks represent different protection types, as shown in the images at the right. The template is usually placed on protected pages to display the padlock. Even when protected, the source code (text) of the page can still be viewed and copied by any user.

Placing the mouse pointer over a padlock icon produces an informational tooltip saying "This article is protected." If the padlock template's 'reason' parameter is specified, the tooltip also says why the page is protected. If the 'expiry' parameter is specified, the tooltip says for what duration the page is protected.

This policy explains in detail the protection types and procedures for page protection and unprotection and the reasons for which protection should and should not be applied.

Overview of types of protection
The following technical options are available to administrators for protecting different actions to pages:
 * Edit protection protects the page from editing.
 * Move protection protects the page from moving (renaming).
 * Creation protection prevents a page (normally a previously deleted one) from being created (also known as "salting").
 * Upload protection prevents new versions of a file from being uploaded, but it does not prevent editing to the file's description page (unless edit protection is applied).

The following technical options are available to administrators for adding protection levels to the different actions to pages:
 * Semi-protection prevents the action by unregistered contributors and contributors with accounts that are not confirmed.
 * Pending-changes protection (only available for edit protection) means edits by unregistered and new contributors are not visible to readers who are not logged in, until the edits are approved by a reviewer or administrator.
 * Extended confirmed protection, also known as 30/500 protection, prevents the action by users without 30 days tenure and 500 edits on the English Wikipedia. It is applied to combat any form of disruption where semi-protection has proven to be ineffective. It should not be applied as a protection level of first resort. Its use is logged at the Administrators' noticeboard.
 * Template protection prevents the action by everyone except template editors and administrators (who have this right as part of their toolset).
 * Full protection prevents the action by everyone except administrators.

Any type of protection (with the exception of cascading protection) may be requested at Requests for page protection. Changes to a fully protected page should be proposed on the corresponding talk page, and carried out by an administrator if they are uncontroversial or if there is consensus for them.

Except in the case of office actions (see below), Arbitration Committee remedies, or pages in the MediaWiki namespace (see below), administrators may unprotect a page if the reason for its protection no longer applies, a reasonable period has elapsed, and there is no consensus that continued protection is necessary. Editors desiring the unprotection of a page should, in the first instance, ask the administrator who applied the protection unless the administrator is inactive or no longer an administrator; thereafter, requests may be made at Requests for unprotection. Note that such requests will normally be declined if the protecting administrator is active and was not consulted first. A log of protections and unprotections is available at Special:Log/protect.

Full protection


A fully protected page can be edited or moved only by administrators. The protection may be for a specified time or may be indefinite.

Modifications to a fully protected page can be proposed on its talk page (or at another appropriate forum) for discussion. Administrators can make changes to the protected article reflecting consensus. Placing the template on the talk page will draw the attention of administrators for implementing uncontroversial changes.

Content disputes
Content disputes and edit warring may be addressed with blocks issued by uninvolved administrators while allowing normal page editing by other editors. Under the protection policy, an alternative approach is available as administrators have the discretion to temporarily fully protect an article to end an ongoing edit war. This approach may be better suited to multi-party disputes and contentious content as talk page consensus becomes a requirement for implementation of requested edits.

When protecting a page because of a content dispute, administrators have a duty to avoid protecting a version that contains policy-violating content, such as vandalism, copyright violations, defamation, or poor-quality coverage of living people. Administrators remain uninvolved when exercising their discretion, subject to this proviso, to decide whether to apply protection to the most current version of an article, or to an older, stable, or pre-edit-war version.

Protected pages may not be edited except to make changes that are uncontroversial or for which there is clear consensus. Editors convinced that the protected version of an article contains policy-violating content, or that protection has rewarded edit warring or disruption by establishing a contentious revision, may identify a stable version prior to the edit war and request reversion to that version. Before making such a request, editors should consider how independent editors might view the suggestion and recognize that continuing an edit war is grounds for being blocked.

Administrators who have made substantive content changes to an article are considered involved and must not use their advanced permissions to further their own positions. When involved in a dispute, it is almost always wisest to respect the editing policies that bind all editors and call for input from an uninvolved administrator, rather than to invite controversy by acting unilaterally.

Vandalism
Applying page protection as a preemptive measure is contrary to the open nature of Wikipedia and is generally not allowed if applied for these reasons. However, brief periods of an appropriate and reasonable protection level are allowed in situations where blatant vandalism or disruption is occurring and at a level of frequency that requires its use in order to stop it. The duration of the protection should be set as short as possible, and the protection level should be set to the lowest restriction needed in order to stop the disruption while still allowing productive editors to make changes.

"History only" review
If a deleted page is going through deletion review, only administrators are normally capable of viewing the former content of the page. If they feel it would benefit the discussion to allow other users to view the page content, administrators may restore the page, blank it or replace the contents with or a similar notice, and fully protect the page to prevent further editing. The previous contents of the page are then accessible to everyone via the page history.

Protected generic image names
Generic image names such as File:Map.jpg and File:Photo.jpg are fully protected to prevent new versions being uploaded.

Permanent protection


Administrators cannot change or remove the protection for some areas on Wikipedia which are permanently protected by the MediaWiki software:
 * Edits to the MediaWiki namespace, which defines parts of the site interface, are restricted to administrators.
 * Edits to system-wide CSS and JavaScript pages such as MediaWiki:common.js are further restricted to interface administrators.
 * Edits to personal CSS and JavaScript pages such as User:Example/monobook.css and User:Example/cologneblue.js are restricted to the associated user and interface administrators. Interface administrators may edit these pages, for example, to remove a user script that has been used in an inappropriate way. Administrators may delete (but not edit) these pages.
 * Edits to personal JSON pages such as User:Example/data.json are restricted to the associated user and administrators.

In addition to hard-coded protection, the following are usually permanently protected:


 * Pages that are very visible, such as the Main Page or File:Wiki.png.
 * Pages that should not be modified for copyright or legal reasons, such as the general disclaimer or the local copy of the site copyright license.
 * Pages that are very frequently transcluded, such as or, to prevent vandalism or denial of service attacks. This includes images or templates used in other highly visible or frequently transcluded pages. See High-risk templates for more information.

Template protection


A template-protected page can be edited only by administrators or users in the group. This protection level should be used almost exclusively on high-risk templates and modules. In cases where pages in other namespaces become transcluded to a very high degree, this protection level is also valid.

This is a protection level that replaces full protection on pages that are merely protected due to high transclusion rates, rather than content disputes. It should be used on templates whose risk factor would have otherwise warranted full protection. It should not be used on less risky templates on the grounds that the template editor user right exists—the existence of the right should not result in more templates becoming uneditable for the general editing community.

Editors may request edits to a template-protected page by proposing them on its talk page, using the template if necessary to gain attention.

Semi-protection


Semi-protection prevents edits from unregistered users (IP addresses), as well as edits from any account that is not autoconfirmed (is at least four days old and has made at least ten edits to Wikipedia) or confirmed. This level of protection is useful when there is a significant amount of disruption or vandalism from new or unregistered users, or to prevent sockpuppets of blocked or banned users from editing, especially when it occurs on biographies of living persons who have had a recent high level of media interest. An alternative to semi-protection is pending changes, which is sometimes favored when an article is being vandalized regularly, but otherwise receives a low amount of editing.

Such users can request edits to a semi-protected page by proposing them on its talk page, using the template if necessary to gain attention. If the page in question and its talk page are both protected, please make your edit request at Wikipedia:Request for edit instead. New users may also request the confirmed user right by visiting Requests for permissions.

Guidance for administrators
Administrators may apply indefinite semi-protection to pages that are subject to heavy and persistent vandalism or violations of content policy (such as biographies of living persons, neutral point of view). Semi-protection should not be used as a preemptive measure against vandalism that has not yet occurred, nor should it be used to privilege registered users over unregistered users in (valid) content disputes.

In addition, administrators may apply temporary semi-protection on pages that are:
 * Subject to significant but temporary vandalism or disruption (for example, due to media attention) when blocking individual users is not a feasible option.
 * Subject to edit-warring where all parties involved are unregistered or new editors (i.e. in cases in which full protection would otherwise be applied). This does not apply when autoconfirmed users are involved.
 * Subject to vandalism or edit-warring where unregistered editors are engaging in IP hopping by using different computers, obtaining new addresses by using dynamic IP allocation, or other address-changing schemes such as IP address spoofing.
 * Article discussion pages, when they have been subject to persistent disruption. Such protection should be used sparingly because it prevents unregistered and newly registered users from participating in discussions. A page and its talk page should not normally be protected at the same time. If a page and its talk page are both protected, the talk page should direct affected editors to Wikipedia:Request for edit, to ensure that no editor is entirely prevented from contributing.
 * Protection should be used sparingly on the talk pages of blocked users, including IP addresses. Instead the user should be re-blocked with talk page editing disallowed. When required, or when re-blocking without talk page editing allowed is unsuccessful, protection should be implemented for only a brief period, and not exceeding the duration of the block.

Today's featured article may be semi-protected just like any other article. But since that article is subject to sudden spurts of vandalism during certain times of day, administrators should semi-protect it for brief periods in most instances. For the former guideline, see Main Page featured article protection.

Creation protection


Administrators can prevent the creation of a page through the protection interface. This is useful for bad articles that have been deleted but repeatedly recreated. Such protection is case-sensitive. There are several levels of creation protection that can be applied to pages, identical to the levels for edit protection. A list of protected titles may be found at Special:Protectedtitles (see also historical lists).

Pre-emptive restrictions on new article titles are instituted through the title blacklist system, which allows for more flexible protection with support for substrings and regular expressions.

Pages that have been creation-protected are sometimes referred to as "salted". Contributors wishing to re-create a salted title with appropriate content should either contact an administrator (preferably the protecting administrator), file a request at Requests for page protection, or use the deletion review process. To make a convincing case for re-creation, it is helpful to show a draft version of the intended article when filing a request.

Administrators should choose the appropriate level of create protection—autoconfirmed, extended-confirmed, or full. Due to the implementation of ACPERM, non-confirmed editors cannot create pages in mainspace; thus, semi-creation protection should be rare, used only for protection of pages outside of mainspace.

Move protection


Move protected pages, or more technically, fully move-protected pages, cannot be moved to a new title except by an administrator. Move protection is commonly applied to:


 * Pages subject to persistent page-move vandalism.
 * Pages subject to a page-name dispute.
 * Highly visible pages that have no reason to be moved, such as the Administrators' noticeboard and articles selected as "Today's featured article" on the main page.

Fully edit-protected pages are also implicitly move-protected.

As with full edit protection, protection because of edit warring should not be considered an endorsement of the current name. When move protection is applied during a requested move discussion, the page should be protected at the location it was at when the move request was started.

All files are implicitly move-protected; only file movers and administrators can move files.

Upload protection


Upload protected files, or more technically, fully upload-protected files, cannot be replaced with new versions except by an administrator. Upload protection does not protect file pages from editing. Upload protection may be applied by an administrator to:
 * Files subject to persistent upload vandalism.
 * Files subject to a dispute between editors.
 * Files that should not be replaced, such as images used in the interface or transcluded to the main page.
 * Files with common or generic names.

As with full edit protection, administrators should avoid favoring one file version over another, and protection should not be considered an endorsement of the current file version. An obvious exception to this rule is when files are protected due to upload vandalism.

Pending changes protection


Pending changes protection is a tool used to suppress vandalism and certain other persistent problems, while allowing all users to continue to submit edits. Pending changes protection can be used as an alternative to semi-protection to allow unregistered and new users to edit pages, while keeping the edits hidden from the view of most readers until those changes are accepted by a reviewer.

When a page under pending changes protection is edited by an unregistered (IP addresses) editor or a new user, the edit is not directly visible to the majority of Wikipedia readers, until it is reviewed and accepted by an editor with the pending changes reviewer right. When a page under pending changes protection is edited by an autoconfirmed user, the edit will be immediately visible to Wikipedia readers.

Pending changes are visible in the page history, where they are marked as pending review. Readers not logged in (the vast majority of readers) are shown the latest accepted version of the page; logged-in users see the latest version of the page, with all changes (reviewed or not) applied. When editors who are not reviewers make changes to an article with unreviewed pending changes, their edits are also marked as pending and are not visible to most readers.

A user who clicks "edit this page" is always, at that point, shown the latest version of the page for editing regardless of whether the user is logged in or not.
 * If the editor is not logged in, his or her changes join any other changes to the article awaiting review – for the present they remain hidden from not-logged-in users. (This means that when the editor looks at the article after saving, he won't see the change he just made.)
 * If the editor is logged in and a pending changes reviewer, and there are pending changes, the editor will be prompted to review the pending changes before editing – see Pending changes.
 * If the editor is logged in and not a pending changes reviewer, then...
 * If there are no unreviewed pending edits waiting, this editor's edits will be visible to everyone immediately; but
 * If there are unreviewed pending edits waiting, then this editor's edits will be visible only to other logged-in users (including himself) immediately, but not to readers not logged in.

Reviewing of pending changes should be resolved within reasonable time limits.

When to apply pending changes protection
Pending changes may be used to protect articles against:
 * Persistent vandalism
 * Violations of the biographies of living persons policy
 * Copyright violations

Pending changes protection should not be used as a preemptive measure against violations that have not yet occurred. Like semi-protection, PC protection should never be used in genuine content disputes, where there is a risk of placing a particular group of editors (unregistered users) at a disadvantage. Pending changes protection should not be used on articles with a very high edit rate, even if they meet the aforementioned criteria. Instead semi-protection should be considered.

In addition, administrators may apply temporary pending changes protection on pages that are subject to significant but temporary vandalism or disruption (for example, due to media attention) when blocking individual users is not a feasible option. As with other forms of protection, the time frame of the protection should be proportional to the problem. Indefinite PC protection should be used only in cases of severe long-term disruption.

Removal of pending changes protection can be requested of any administrator, or at requests for unprotection.

The reviewing process is described in detail at reviewing pending changes.

Extended confirmed protection


Extended confirmed protection, also known as 30/500 protection, allows edits only by editors with the extended confirmed user access level, granted automatically to registered users with at least 30 days tenure and 500 edits.

Where semi-protection has proven to be ineffective, administrators may use extended confirmed protection to combat disruption (such as vandalism, abusive sockpuppetry, edit wars, etc.) on any topic. Extended confirmed protection should not be used as a preemptive measure against disruption that has not yet occurred, nor should it be used to privilege extended confirmed users over unregistered users in valid content disputes on articles not covered by Arbitration Committee 30/500 rulings. Extended confirmed protection may be applied by an administrator at their discretion when creation-protecting a page.

Until August 12, 2016, 30/500 protection applied only in topic areas determined by the Arbitration Committee, which authorized its use on articles reasonably construed as belonging to the Arab-Israeli conflict; as an arbitration enforcement tool by motion or remedy; or as a result of community consensus. In February 2019, the community authorized uninvolved administrators to place pages reasonably construed as belonging to the India–Pakistan conflict under extended confirmed protection as part of a general sanctions regime. As of September 23, 2016, a bot posts a notification in a subsection of AN when this protection level is used. A full list of the pages under 30/500 protection can be found [ here].

Users can request edits to a Extended confirmed-protected page by proposing them on its talk page, using the template if necessary to gain attention.

Office actions


As outlined in Office actions, pages may be protected by Wikimedia Foundation staff in response to issues such as copyright infringement or libel. Such actions override community consensus. Administrators should not edit or unprotect such pages without permission from Wikimedia Foundation staff.

Cascading protection


Cascading protection fully protects a page, and extends that full protection automatically to any page that is transcluded onto the protected page, whether directly or indirectly. This includes templates, images and other media that are hosted on the English Wikipedia. Files stored on Commons are not protected by any other wiki's cascading protection and must be temporarily uploaded to the English Wikipedia or protected at Commons, either manually or through cascading protection there. When operational, KrinkleBot cascade-protects Commons files transcluded at Main Page/Tomorrow, Main Page/Commons media protection and Main Page. As the bot's response time varies, media should not be transcluded on the main page (or its constituent templates) until after it has been protected. (This is particularly relevant to Template:In the news, for which upcoming images are not queued at Main Page/Tomorrow.) Cascading protection: The list of cascading-protected pages can be found at Cascade-protected items. Requests to add or remove cascading protection on a page should be made at Wikipedia talk:Cascade-protected items as an edit request.
 * Should be used only to prevent vandalism when placed on particularly visible pages, such as the main page.
 * Is available only for fully protected pages; it is disabled for semi-protected pages as it represents a security flaw. See 8796 for more information.
 * Is not instantaneous; it may be several hours before it takes effect. See 18483 for more information.
 * Should generally not be applied directly to templates or modules, as it will not protect transclusions inside tags or transclusions that depend on template parameters, but will protect the documentation subpage. See the "Protection of templates" section below for alternatives.

Superprotect
Superprotect was a level of protection, allowing editing only by [ Wikimedia Foundation employees who are in the Staff global group]. It was implemented on August 10, 2014 and used the same day to override community consensus regarding the use of the Media Viewer on the German Wikipedia's primary site JavaScript, common.js. It was never used on the English Wikipedia. On November 5, 2015, the WMF decided to remove superprotect from all Wikimedia wikis.

Cascading semi-protection
Cascading semi-protection was formerly possible, but it was disabled in 2007 after users noticed that non-administrators could fully protect any page by transcluding it onto the page to which cascading semi-protection had been applied by an administrator.

Pending changes protection level2
Originally, two levels of pending changes protection existed, where level2 required edits by all users who are not pending changes reviewers to be reviewed. Following a community discussion, level2 was retired from the English Wikipedia in January 2017. It was suggested then that "Pending changes level1" be referred to in the future as simply "Pending changes".

Article talk pages
Modifications to a protected page can be proposed on its talk page (or at another appropriate forum) for discussion. Administrators can make changes to the protected article reflecting consensus. Placing the template on the talk page will draw the attention of administrators for implementing uncontroversial changes. Talk pages are not usually protected, and are semi-protected only for a limited duration in the most severe cases of vandalism.

User talk pages
User talk pages are rarely protected, and are semi-protected for short durations only in the most severe cases of vandalism from IP users. Users whose talk pages are semi-protected should have an unprotected user talk subpage linked conspicuously from their main talk page to allow good faith comments from non-autoconfirmed users. A user's request to have his or her own talk page protected is not a sufficient rationale by itself to protect the page, although requests may be considered if a reason is provided.

Blocked users
Blocked users' user talk pages should not ordinarily be protected, as this interferes with the user's ability to contest their block through the normal process. It also prevents others from being able to use the talk page to communicate with the blocked editor. In extreme cases of abuse by the blocked user, such as abuse of the unblock template, re-blocking the user without talk page access should be preferred over protection. If the user has been indefinitely blocked from editing the talk page, they should be informed of off-wiki ways to appeal their block, such as the UTRS tool interface or as a last recourse, the Arbitration Committee. When required, protection should be implemented for only a brief period, not exceeding the duration of the block. Confirmed socks of registered users should be dealt with in accordance with Sockpuppetry; their pages are not normally protected.

User pages
Base user pages (for example, the page User:Example, and not User:Example/subpage or User talk:Example) are automatically protected from creation or editing by unconfirmed and IP users. An exception to this includes an unconfirmed registered user attempting to edit their own user page. IP and unconfirmed editors are also unable to create or edit user pages that do not belong to a registered user. This protection is enforced by a filter. Users may opt-out of this protection by placing anywhere on their own page. User pages and subpages may be protected upon a request from the user, as long as a need exists—pages in user space should not be automatically or pre-emptively protected. Requests for protection specifically at uncommon levels (such as template protection) may be granted if the user has expressed a genuine and realistic need. When a filter is insufficient to stop user page vandalism, a user may choose to create a ".css" subpage (ex. User:Example/Userpage.css), copy all the contents of their user page onto the subpage, transclude the subpage by putting on their user page, and then ask an administrator to fully protect their user page. Because user space pages that end in ".css", ".js", and ".json" are editable only by the user to which that user space belongs (and interface administrators), this will protect your user page from further vandalism.

Deceased users
In the event of the confirmed death of a user, the user's user page (but not the user talk page) should be fully protected.

Protection of templates
Highly visible templates, which are used on an extremely large number of pages or substituted with great frequency, are often semi- or template-protected based on the degree of visibility, type of use, content, etc. Protected templates should normally have the documentation template. It loads the unprotected /doc page, so that non-admins and IP-users can edit the documentation, categories and interwiki links. It also automatically adds pp-template to protected templates, which displays a small padlock in the top right corner and categorizes the template as protected. Only manually add to protected templates that don't use  (mostly the flag templates). Cascading protection should generally not be applied directly to templates, as it will not protect transclusions inside tags or transclusions that depend on template parameters, but will protect the template's documentation subpage. Instead, consider any of the following: Note: All editnotice templates (except those in userspace) are already protected via MediaWiki:Titleblacklist. They can be edited by admins, template editors and page movers only.
 * If the set of subtemplates is static (even if large), protect them using normal protection mechanisms.
 * If the set of subtemplates is unbounded, use MediaWiki:Titleblacklist to protect all subtemplates using a particular naming format (as is done for editnotice templates and subtemplates of Template:TFA title).

Sandboxes
Sandboxes should not ordinarily be protected since their purpose is to let new users test and experiment with wiki syntax. Most sandboxes are automatically cleaned every 12 hours, although they are frequently overwritten by other testing users. The Sandbox is cleaned every hour. Those who use sandboxes for malicious purposes, or to violate policies such as no personal attacks, civility, or copyrights, should instead be warned and/or blocked.

Available templates
The following templates may be added at the very top of a page to indicate that it is protected:

On redirect pages, use the Redirect category shell template, which automatically categorizes by protection level, below the redirect line. A protection template may also be added below the redirect line, but it will serve only to categorize the page, as it will not be visible on the page, and it will have to be manually removed when protection is removed.

Purpose and goals
Blocks serve to protect the project from harm, and reduce likely future problems. Blocks may escalate in duration if problems recur. They are meted out not as retribution but to protect the project and other users from disruption and inappropriate conduct, and to deter any future possible repetitions of inappropriate conduct. Blocking is one of the most powerful tools that are entrusted to administrators, who should be familiar with the circumstances prior to intervening and are required to be able to justify any block that they issue.

In general, once a matter has become "cold" and the risk of present disruption has clearly ended, reopening it by blocking retrospectively is usually not appropriate. In this situation, if an ongoing or serious concern persists, several dispute resolution processes exist to allow discussion and possible sanction of a user.

Blocks can be appealed (see ). Requests to be unblocked are also decided in light of prevention and deterrence. A user may be unblocked earlier if the user agrees to desist and appears to have learned from the matter, or if the situation was temporary and has now ended. Likewise, a user who has previously returned to inappropriate conduct after other unblocks may find their unblock request declined for deterrence reasons, to emphasize the importance of change and unacceptability of the conduct.

Blocks should not be punitive
Blocks should not be used:
 * 1) to retaliate;
 * 2) to disparage;
 * 3) to punish; or
 * 4) if there is no current conduct issue of concern.

Blocks should be preventative
Blocks should be used to:
 * 1) prevent imminent or continuing damage and disruption to Wikipedia;
 * 2) deter the continuation of present, disruptive behavior; and
 * 3) encourage a more productive, congenial editing style within community norms.

Deterrence is based upon the likelihood of repetition. For example, though it might have been justifiable to block an editor a short time ago, such a block may no longer be justifiable right now, particularly if the actions have since ceased or the conduct issues have been resolved.

Common rationales for blocks
The following are some of the most common rationales for blocks.

As a rule of thumb, when in doubt, do not block; instead, consult other administrators for advice. After placing a potentially controversial block, it is a good idea to make a note of the block at the administrators' incidents noticeboard for peer review.

Administrators should take special care when dealing with new users. Beginning editors are often unfamiliar with Wikipedia policy and convention, and so their behavior may initially appear to be disruptive. Responding to these new users with excessive force can discourage them from editing in the future. See Do not bite the newcomers.

Protection
A user may be blocked when necessary to protect the rights, property, or safety of the Wikimedia Foundation, its users, or the public. A block for protection may be necessary in response to:
 * persistent personal attacks;
 * personal, professional, or legal threats (including outside the Wikipedia site);
 * actions placing users in danger;
 * actions that may compromise the safety of children, in accordance with Child protection;
 * disclosures of others' personal information (whether or not the information is accurate);
 * persistent copyright violations;
 * persistent posts of unreferenced, poorly or incorrectly referenced, or potentially defamatory information about living persons; or
 * an account appearing to have been compromised (as an emergency measure), i.e. there is some reason to believe the account is being used by someone other than the person who registered the account.

When blocking in response to personal information disclosures or actions that place users in danger, consider notifying the Arbitration Committee by e-mail (arbcom-en@wikimedia.org) about the disclosure or danger and contacting someone with oversight permissions to request permanent deletion of the material in question.

Disruption
A user may be blocked when his or her conduct severely disrupts the project; that is, when his or her conduct is inconsistent with a civil, collegial atmosphere and interferes with the process of editors working together harmoniously to create an encyclopedia. A block for disruption may be necessary in response to:
 * vandalism;
 * gross incivility;
 * harassment;
 * spamming;
 * edit warring, especially breaches of the three-revert rule;
 * deliberately tripping the abuse filter
 * breaching the policies or guidelines, especially the sock puppetry policy;
 * attempts to coerce actions of editors through threats of actions outside the Wikipedia processes, whether onsite or offsite.

Disruption-only
Some types of user accounts are considered disruptive and may be blocked without warning, usually indefinitely:
 * Accounts used exclusively for disruptive purposes, such as vandalism.
 * Public accounts (where the password is publicly available or shared with a large group).
 * Accounts with inappropriate usernames.
 * Bots operating without approval or outside their approval.
 * Accounts that appear, based on their edit history, to exist for the sole or primary purpose of promoting a person, company, product, service, or organization. See Conflict of interest and Spam.

Open or anonymous proxies
Open or anonymous proxies may be blocked on sight.

Non-static IP addresses or hosts that are otherwise not permanent proxies typically warrant blocking for a shorter period of time, as the IP address is likely to be reassigned, or the open proxy is likely to be closed. Many Tor proxies, in particular, are "exit nodes" for only a short time; in general, these proxies should not be blocked indefinitely without consideration. See Blocking IP addresses for further details.

There is also a Wikipedia project, the WikiProject on open proxies, which seeks to identify and block open proxy servers.

Enforcing bans
A Wikipedia ban is a formal revocation of editing privileges on all or part of Wikipedia. A ban may be temporary and of fixed duration, or indefinite and potentially permanent.

Blocks may be imposed as a technical measure to enforce a ban. Such blocks are based on the particulars of the ban. Bans that apply to all of Wikipedia—that is, they are not partial—may be backed up by a block, which is usually set to apply for the period of the ban.

"Not here to build an encyclopedia"
This often-used blocking rationale is described at.

Evasion and enforcement
An administrator may reset the block of a user who intentionally evades a block, and may extend the duration of the block if the user engages in further blockable behavior while evading the block. User accounts or IP addresses used to evade a block should also be blocked.

Edits by and on behalf of blocked editors
Anyone is free to revert any edits made in violation of a block, without giving any further reason and without regard to the three-revert rule. This does not mean that edits must be reverted just because they were made by a blocked editor (obviously helpful changes, such as fixing typos or undoing vandalism, can be allowed to stand), but the presumption in ambiguous cases should be to revert. However, in closed discussions, comments by blocked editors should not generally be reverted or struck through.

Wikipedians in turn are not permitted to post or edit material at the direction of a blocked editor (sometimes called proxy editing or "proxying") unless they can show that the changes are either verifiable or productive and they have independent reasons for making such edits. New accounts that engage in the same behavior as a banned editor or blocked account in the same context, and that appear to be editing Wikipedia solely for that purpose, are subject to the remedies applied to the editor whose behavior they are imitating. See.

Enforcement by reverting
While reverting edits, take care not to reinstate material that may be in violation of such core policies as Neutral point of view, Verifiability, and Biographies of living persons. Editors who subsequently reinstate edits originally made by a blocked editor take complete responsibility for the content.

It is not possible to revert newly created pages, as there is nothing to which to revert. Accordingly, pages created by blocked editors are eligible for speedy deletion. Any editor can use the template db-g5, or its shortcuts db-banned or db-blocked, to mark such a page. If editors other than the blocked editor have made good-faith contributions to the page or its talk page, it is courteous to inform them that the page was created by a blocked editor, and then decide on a case-by-case basis what to do.

Conflicts and involvement
Administrators must not block users with whom they are engaged in a content dispute; instead, they should report the problem to other administrators. Administrators should also be aware of potential conflicts involving pages or subject areas with which they are involved. It is acceptable for an administrator to block someone who has been engaging in clear-cut vandalism in that administrator's userspace.

Cool-down blocks
Blocks intended solely to "cool down" an angry user should not be used, as they often have the opposite effect. However, an angry user who is also being disruptive can be blocked to prevent further disruption.

Recording in the block log
Blocks should not be used solely for the purpose of recording warnings or other negative events in a user's block log. The practice, typically involving very short blocks, is often seen as punitive and humiliating.

Very short blocks may be used to record, for example, an apology or acknowledgement of mistake in the block log in the event of a wrongful or accidental block, if the original block has expired. (If it has not, the message may be recorded in the unblocking reason.)

Against the blocking administrator
A blocked administrator can block the blocking administrator, but should only do so in exceptional circumstances where there is a clear and immediate need, such as in the case of a compromised account. Use of the block tool to further a dispute or retaliate against the original blocking administrator is not allowed.

Requesting blocks
Disruptive behavior can be reported, and blocks requested at a specialized venue such as Administrator intervention against vandalism or, if appropriate, Administrators' noticeboard/Incidents. Users requesting blocks should supply credible evidence of the circumstances warranting a block. Administrators are never obliged to place a block, and are free to investigate the situation for themselves. Prior to imposing a block, administrators are expected to be fully familiar with the circumstances of the situation. See also.

Dealing with off-wiki block requests
Administrators who use Wikipedia-related IRC channels are reminded that, while these channels have legitimate purposes, discussing an issue on IRC necessarily excludes those editors who do not use IRC from the discussion (and excludes all non-administrators from the discussion if it takes place in #wikipedia-en-admins), and therefore, such IRC discussion is never the equivalent of on-wiki discussion or dispute resolution. Consensus about blocks or other subjects should not be formed off-wiki.

As the practice of off-wiki "block-shopping" is strongly discouraged, and that except where there is an urgent situation and no reasonable administrator could disagree with an immediate block (e.g. ongoing vandalism or serious violations of the policy on biographies of living persons), the appropriate response for an administrator asked on IRC to block an editor is to refer the requester to the appropriate on-wiki noticeboard.

Self-requested blocks
Sometimes, people request that their account be blocked, for example to enforce a wikibreak. Such requests are typically declined, but there is a category of administrators who will consider such requests.

As an alternative to requesting a self-block, users may use the Wikibreak Enforcer, a user script that can prevent a user from logging in.

Preliminary: education and warnings
Before a block is imposed, efforts should be made to educate users about Wikipedia policies and guidelines, and to warn them when their behavior conflicts with these. Welcome newcomers, do not bite them, and assume that most people who work on the project are trying to help it, not hurt it. Newcomers should make an effort to learn about our policies and guidelines so that they can learn how to avoid making mistakes. A variety of template messages exist for convenience, although purpose-written messages are often preferable. Template warnings that state that a user may be blocked for disruption or other blockable behavior may also be issued by regular editors rather than by administrators only.

However, warnings are not a prerequisite for blocking. In general, administrators should ensure that users who are acting in good faith are aware of policies and are given reasonable opportunity to adjust their behavior before blocking, and it may be particularly desirable to communicate first with such users before blocking. On the other hand, users acting in bad faith, whose main or only use is forbidden activity (sockpuppetry, vandalism, and so on), do not require any warning and may be blocked immediately.

Explanation of blocks
Blocking is a serious matter. The community expects that blocks will be made with good reasons only, based upon reviewable evidence and reasonable judgment, and that all factors that support a block are subject to independent peer review if requested.

Notifying the blocked user
Administrators must supply a clear and specific block reason that indicates why a user was blocked. Block reasons should avoid the use of jargon as much as possible so that blocked users may better understand them. Administrators should notify users when blocking them by leaving a message on their user talk page. It is often easier to explain the reason for a block at the time than it is to explain a block well after the event.

When implementing a block, a number of pro forma block reasons are available in a drop-down menu; other or additional reasons can also be added. Users can be notified of blocks and block reasons using a number of convenient template messages—see Category:User block templates and Template messages/User talk namespace.

Other important information
If there are any specific recommendations or circumstances that a reviewing administrator would need to know, or that may help to avoid administrator disputes upon review of a block, the blocking administrator should consider including this information in the block notice. For example:
 * When there is information or evidence that may not be obvious, may not be fully appreciated, or may otherwise be relevant.
 * Prior endorsement that if any administrator wishes to unblock, or there is consensus for it, they may without consulting the blocking administrator.
 * Suggested conditions for an unblock.

Confidential evidence
If a user needs to be blocked based on information that will not be made available to all administrators, that information should be sent to the Arbitration Committee or a checkuser or oversighter for action. These editors are qualified to handle non-public evidence, and they operate under strict controls. The community has rejected the idea of individual administrators acting on evidence that cannot be peer-reviewed.

An exception is made for administrators holding Checkuser or Oversight privileges; such administrators may block users based on non-public information revealed through the checkuser tool, or on edits that have been suppressed ("oversighted") and are inaccessible to administrators. As such, an administrative action is generally viewed to be made in the user's capacity as an oversight or checkuser, although the action itself is an administrative one. All such blocks are subject to direct review by the Arbitration Committee.
 * Contact details: individual Checkusers and Oversighters are listed on the relevant pages; they can also be contacted via the functionaries mailing-list (e.g., if in doubt who to contact).

Implementing blocks
Technical instructions on how to block and unblock, and information on the blocking interface, are available at mw:Help:Blocking users. The following is advice specifically related to blocking and unblocking on Wikipedia.

IP address blocks
In addition to the further advice, there are special considerations to take into account when blocking IP addresses. IP address blocks can affect many users, and IP addresses can change. Users intending to block an IP address should at a minimum check for usage of that address, and consider duration carefully. IP addresses should rarely, if ever, be blocked indefinitely. You should notify the Wikimedia Foundation if the IP is related to a sensitive organization or a government agency.

Collateral damage
A block of a range of IP addresses may unintentionally affect other users in that range. Before blocking an IP range, especially for a significant time, you should check for other users who may be unintentionally affected by the range block: If any are found, an IP block exemption ensures they will not be affected.
 * unregistered users – Range Contributions – X!'s tools
 * registered users – ask a user with checkuser access to check.

Duration of blocks
The purpose of blocking is prevention, not punishment. The duration of blocks should thus be related to the likelihood of a user repeating inappropriate behavior. Longer blocks for repeated and high levels of disruption is to reduce administrative burden; it is under presumption that such users are likely to cause frequent disruption or harm in future. Administrators should consider:
 * the severity of the behavior;
 * whether the user has engaged in that behavior before.

Blocks on shared or dynamic IP addresses are typically shorter than blocks on registered accounts or static IP addresses made in otherwise similar circumstances, to limit side-effects on other users sharing that IP address.

While the duration of a block should vary with the circumstances, there are some broad standards:
 * incidents of disruptive behavior typically result in blocks of from a day to a few days, longer for persistent violations;
 * accounts used exclusively for disruption may be blocked indefinitely without warning;
 * protective blocks typically last as long as protection is necessary, often indefinitely.

Indefinite blocks
An indefinite block is a block that does not have a definite (or fixed) duration. Indefinite blocks are usually applied when there is significant disruption or threats of disruption, or major breaches of policy. In such cases an open-ended block may be appropriate to prevent further problems until the matter can be resolved by discussion. As with all blocks, it is not a punishment. It is designed to prevent further disruption, and the desired outcome is a commitment to observe Wikipedia's policies and guidelines, and to stop problematic conduct in future.

Indefinite does not mean infinite: an indefinitely blocked user may later be unblocked in appropriate circumstances. In particularly serious cases in which no administrator would be willing to lift the block, the user is effectively banned by the community.

Block log
If the block arose from a discussion per, please include a link to the discussion in the block log. If the block is enforcing a community sanction, please note this. If consensus was to allow for regular administrative review rather than requiring community review, per, that should be noted in the log as well.

Setting block options
Several options are available to modify the effect of blocks, which should be used in certain circumstances:


 * Autoblock any IP addresses used will apply an autoblock, or automatic block, on the IP address that the account was last using, as well as any subsequent IP addresses the account tries to edit from while they are blocked with this option set. If a different non-exempt user account logs in from an autoblocked IP address and tries to edit, the user account will also be added to the autoblock list. This option should typically be disabled when blocking unapproved or malfunctioning bots (so as not to block the bot's operator or any other bots using that IP address), though it should be enabled when blocking accounts for disruptive or malicious behavior. This option is enabled by default and is only available when applying a block to an account.
 * Prevent account creation will restrict the user from accessing the Special:CreateAccount function for the duration of the block. If applied to an IP address or range, it will also prevent all user accounts from being able to create additional accounts if they attempt to do so while behind the blocked IP address or range. If the autoblock option is also enabled on a block applied to a user account, it will also prevent accounts from being created on the IP address that the blocked user was using. It should typically be disabled when blocking accounts with inappropriate names (to allow the user to create a new account with an appropriate name), though it should be enabled when blocking bad-faith names (for example, clear attacks on other users) or vandalism-only accounts.
 * Prevent user from sending email will restrict the user from accessing the Special:EmailUser function for the duration of the block. This option is not checked by default and should not be enabled when blocking an account except only in cases where the blocked user is abusing the "email this user" feature (however, in instances when administrators feel that email abuse is extremely likely, they may use their discretion and enable this option). When enabled, efforts should be taken to ensure that the user's talk page remains unprotected and that the user is aware of other avenues (such as the Unblock Ticket Request System) through which they can discuss the block. This is often used in cases of a user who is likely to cause disruption through e-mail to other users.
 * Prevent this user from editing their own talk page while blocked, if checked, will prevent the blocked user from editing their own talk page (including the ability to create unblock requests) during the duration of their block. This option is not checked by default, and typically should not be checked; editing of the user's talk page should be disabled only in the case of continued abuse of their user talk page. The protection policy has further details in cases where other users are repeatedly causing disruption to the user talk pages of blocked users.
 * Prevent logged-in users from editing from this IP address will disallow any non-exempt user accounts from editing from the IP address during the duration of the block. This option should typically not be checked, and is typically only used in cases of long-term abuse, sock puppetry, for IP addresses with a history of significant and high level abuse, or for being an open proxy or location host. See hard block under the IP address common block list below. This option is disabled by default and is only available when applying a block to an IP address or IP range.

Common blocks imposed
There are two common blocks that may be imposed on registered accounts:


 * A soft account block (autoblock disabled, account creation allowed) will only block the specific account from editing. An autoblock is not applied to the IP address the account last used, and other accounts that log in from the IP address are allowed to edit as normal. This is generally used in situations such as blocking promotional usernames or to enforce other username policy violations. This allows the blocked account to register a new account with a username that is in compliance with the username policy, or simply choose to edit anonymously under the IP if they decide not to do so.
 * A hard account block (autoblock enabled, account creation disabled) will apply an autoblock to the IP address the account last used to edit. Any additional IP address that the account attempts to edit from during the duration of the block is also automatically blocked and added to the autoblock list, and any non-exempt accounts that attempt to edit from an autoblocked IP address will not be able to do so. Accounts cannot be created by any autoblocked IP address(es) or accounts nor by the original account while it is blocked. This is typically used in cases of blocking vandalism or to prevent other disruption.

There are two common blocks that may be imposed on IP addresses:


 * A soft IP address block (account creation blocked) is used in most cases of disruption – including vandalism and edit warring, and prevents only anonymous users from editing. It also restricts any account creation by the IP address or by any user accounts while behind the blocked IP address . Allowing account creation from a blocked IP is done under unique and special situations.
 * A hard IP address block (account creation blocked, prevent logged-in users from editing from this IP address) disables all editing and account creation from behind the blocked IP address, whether or not from logged in users (except accounts that are IP-block exempt—these users can edit while behind the blocked IP, but cannot create accounts). This is typically used when the level of vandalism or disruption via creation of "throwaway" accounts is such that all editing from the IP address is to be prevented except after individual checking of requests. Open proxies are hard-blocked on detection, and Tor IP addresses are automatically blocked by the Tor block extension.

Blocking bots
Automated or semi-automated bots may occasionally not operate as intended for a variety of reasons. Bots (or their associated IP address should the actual bot not be readily identifiable) may be blocked until the issue is resolved. Administrators should take care not to apply an autoblock to a bot as this will result in the autoblock propagating to all the other bots that share IPs on Wikimedia Cloud Services.

Bots that are unapproved, or usernames that violate the username policy due to a resemblance to a bot, are immediately and indefinitely blocked when discovered.

The edits of a bot are considered to be, by extension, the edits of the editor responsible for the bot. As a result, should a bot operator be blocked, any bot attributed to them may also be blocked for the same duration as that of the blocked editor.

Recording in the block log after a "clean start"
Editors may cite Clean start and rename themselves, asking that their previous username not be disclosed. If such editors have been blocked previously, the administrator who has been requested to make the deletion should contact a Checkuser so that the connection between the accounts can be verified. The Checkuser should then consider adding short blocks to the new account to denote each entry in the user's old account log. Such short blocks should provide protection in case the "clean start" was based on a genuine risk of off-wiki harassment, by not disclosing the previous username, while at the same time eliminating the possibility of avoiding the scrutiny of the community.

The short blocks should be described in the block summary as "previous account block" and the final duration of the block should be noted. Blocks placed in error and lifted early should not be noted at all.

Unblocking
Unblocking or shortening of a block is most common when a blocked user appeals a block. An uninvolved administrator acting independently reviews the circumstances of the block, the editor's prior conduct, and other relevant evidence, along with any additional information provided by the user and others, to determine if the unblock request should be accepted. Common reasons include: the circumstances have changed, a commitment to change is given, the administrator was not fully familiar with the circumstances prior to blocking, or there was a clear mistake. See "Block reviews" below for additional steps to take.

Unacceptable unblocking
Unblocking will almost never be acceptable: Each of these may lead to sanctions for misuse of administrative tools—possibly including removing administrator rights—even for first-time incidents.
 * When it would constitute wheel warring.
 * To unblock any of one's own accounts, except in the case of self-imposed blocks.
 * When the block is implementing a community sanction which has not been successfully appealed. The community may choose to allow a block to be reviewed in the normal way, by consulting with the closing/blocking administrator, rather than requiring a formal appeal to the community. If there is consensus to allow this it shall be noted in the closing statement and block log.
 * When the block is explicitly enforcing an active Arbitration remedy. Arbitration enforcement blocks may be appealed using the special appeal provisions.

There is no limit to the number of unblock requests that a user may issue. However, disruptive use of the unblock template may prompt an administrator to remove the blocked user's ability to edit his or her talk page. In this case, a block may still be appealed by submitting a request to the Unblock Ticket Request System.

Unblock requests
As part of an unblock request, uninvolved editors may discuss the block, and the blocking administrator is often asked to review or discuss the block, or provide further information. Since the purpose of an unblock request is to obtain review from a third party, the blocking administrators should not decline unblock requests from users they have blocked. Also, by convention, administrators don't usually review more than one unblock request regarding the same block.

Except in cases of unambiguous error or significant change in circumstances dealing with the reason for blocking, administrators should avoid unblocking users without first attempting to contact the blocking administrator to discuss the matter. If the blocking administrator is not available, or if the administrators cannot come to an agreement, then a discussion at Administrators' noticeboard is recommended.

Administrators reviewing a block should consider that some historical context may not be immediately obvious. Cases involving sockpuppets, harassment, or privacy concerns are particularly difficult to judge. At times such issues have led to contentious unblocks. Where an uninformed unblock may be problematic, the blocking administrator may also wish to note as part of the block notice that there are specific circumstances, and that a reviewing administrator should not unblock without discussing the case with the blocking admin (or possibly ArbCom) to fully understand the matter.

If users claim they wish to contribute constructively but there are doubts as to their sincerity, the 2nd chance template can be used to allow them to demonstrate how they will contribute to the encyclopedia, should their unblock request be granted.

Any user may comment on an unblock request; however, only administrators may resolve the request (either declining or unblocking).

Blocks in temporary circumstances
Some types of blocks are used in response to particular temporary circumstances, and should be undone once the circumstance no longer applies:
 * Blocks on open or anonymous proxies should be undone once it is confirmed that they have been closed (but be aware some open proxies may be open only at certain times, so careful checking may be needed that it really is apparently no longer in use that way).
 * Blocks of unapproved or malfunctioning bots should be undone once the bots gain approval or are repaired.
 * Blocks for making legal threats should be undone once the threats are confirmed as permanently withdrawn and no longer outstanding.

Unblocks in temporary circumstances
Users may be temporarily and conditionally unblocked to respond to a discussion regarding the circumstances of their block. Such temporary and conditional unblocks are made on the understanding that the users may not edit any pages (besides their user talk page) except the relevant discussion page(s) explicitly specified by the unblocking admin. The users are effectively banned from editing any other pages, and breaching this ban will be sanctioned appropriately. When the discussion concludes, the block should be reinstated unless there is a consensus to overturn the block.

CheckUser blocks
Without first consulting a CheckUser, administrators should not undo or alter any block that is specifically identified as a "checkuser" block, such as through the use of the checkuserblock or checkuserblock-account templates in the action summary. If an administrator believes that a checkuser block has been made in error, the administrator should first discuss the matter with the CheckUser in question, and if a satisfactory resolution is not reached, should e-mail the Arbitration Committee. A reversal or alteration of such a block without prior consultation may result in removal of permissions.

Oversight blocks
Appeals of blocks that have been marked by an oversighter as oversight blocks should be sent to the oversight team via email (Oversight-l@lists.wikimedia.org) to be decided by the English Wikipedia oversighters, or to the Arbitration Committee. Blocks may still be marked by the blocking oversighter as appealable only to the Arbitration Committee, per the 2010 statement, in which case appeals must only be directed to the Arbitration Committee. Unblocking or altering without consent of an oversighter may result in removal of permissions.

Conditional unblock
Administrators may, with the agreement of the blocked user, impose conditions when unblocking. Unblock conditions are designed to prevent recurrence of the behaviour that led to the block (such as a page ban to prevent further edit warring).
 * If the blocked user does not reach an agreement on proposed unblock conditions with an administrator, the blocked user may post another block appeal.
 * Administrators have discretion to set the expiry of unblock conditions, provided that:
 * The unblock conditions of blocks that expire after one year or less will expire after no more than a year,
 * The unblock conditions of blocks that expire after more than a year (including indefinite) may expire up to and including indefinitely.
 * Unblock conditions may include page bans, topic bans, interaction bans, revert restrictions, single account restrictions and other restrictions at the discretion of the unblocking administrator.
 * If editors breach the unblock conditions or engage in fresh misconduct, they may be blocked or further restricted.
 * After the blocked user has accepted the conditions and been unblocked, the conditions may be appealed only to the unblocking administrator or to Administrators' noticeboard.
 * The user will be notified of unblock conditions on their talk page when they are unblocked and a diff/permalink containing the restrictions must be included in the unblock log rationale.

Global blocks
GlobalBlocking is a MediaWiki extension available to stewards to prevent cross-wiki disruption from an IP address or a range of IP addresses. When an IP address or range of IP addresses is globally blocked, they are prevented from editing any public Wikimedia wiki, except for Meta-Wiki, where globally blocked users may appeal the decision. (A global block is not the same as a global ban.) When a user's editing is prevented by a global block, the contents of MediaWiki:Globalblocking-ipblocked (formerly MediaWiki:Globalblocking-blocked) are shown as an error message (analogous to MediaWiki:Blockedtext for locally blocked users). Registered users cannot be globally blocked. The analogous action is global locking, which prevents anyone from logging into the account.

A current list of globally blocked IP addresses is available at Special:GlobalBlockList.

Unblocking and appeal
Local whitelisting — An IP address which is globally blocked can be unblocked locally (to edit the specific wiki concerned only), by any local administrator, at Special:GlobalBlockWhitelist. It is not possible to override global locks locally.

Appeal against a global block — Globally blocked IP addresses and globally locked users may appeal through the email queue to. Globally blocked IP addresses may also appeal through their meta talk page, if their access to meta talk page have not been revoked.

Usernames implying shared use
Because Wikipedia's policy is that usernames should not be shared between more than one individual, usernames that imply the likelihood of shared use are not permitted. This means that:
 * Usernames that are simply names of companies or groups are not permitted (these also fall under above).
 * Personal usernames that imply shared access, such as "Jack and Jill", are not permitted.
 * Usernames that are names of posts within organizations, such as "Secretary of the XY Foundation", are not permitted, as such a post may be held by different persons at different times.
 * However, usernames are acceptable if they contain a company or group name but are clearly intended to denote an individual person, such as "Mark at WidgetsUSA", "Jack Smith at the XY Foundation", "WidgetFan87", etc.

Remember that promotional editing is not permitted regardless of username. The conflict of interest guideline advises all users to exercise caution if editing articles about businesses, organizations, products, or other subjects that they are closely connected to. If you choose to edit articles that are in any way related to your company or group, you will need to carefully follow Wikipedia's advice on editing with a conflict of interest.

Confusing usernames
Some usernames appear problematic without fitting clearly into any of the above categories. This is often the case with confusing or extremely lengthy usernames, which are highly discouraged but which are not so inappropriate on their own as to require action.

Confusing usernames can often be a red flag for other problems. An editor with a confusing username or signature may be blocked sooner than usual for other inappropriate behavior such as disruption or vandalism, if their confusing username contributes to the disruption.

Non-script usernames
Due to the difficulty with some web browsers in viewing non-language unicode characters and emoji, as well as concerns regarding the suitability of these characters as names, users registering after 6 November 2017 are not allowed to have the following usernames:
 * Usernames containing emoji
 * Usernames that are considered to be emoticons or otherwise "decorative" usernames
 * Usernames that use any non-language symbols. This includes:
 * Symbols and characters unrelated to the list of writing systems
 * Symbols and characters that are on the block lists at Unicode symbols

Users with such names should be offered the opportunity for renaming their account or creating a new one (see below). Before blocking, disagreements as to whether a particular username is acceptable should be discussed at WP:Requests for comment/User names.

Note that this restriction does not apply to signatures, which are governed by Signatures.

Exceptions
Some usernames that appear to be in breach of this policy have been allowed to stand by consensus because they were created before a change in the policy that would now prohibit such names (see grandfather clause). If you find an apparently problematic username being used by a long-standing editor, it is likely that the matter has been discussed before. Please search that user's talk page (and archives if applicable), and the archives of the administrators' noticeboards and requests for comment on usernames, before deciding to take action as described below.

Dealing with inappropriate usernames
If you encounter an inappropriate username as described above, there are various actions you might take. Use common sense in making your choice, and avoid "biting" newcomers.

Consider leaving well enough alone
If the name is not unambiguously problematic, it may be sensible to ignore it. Assume good faith, and also note the exceptions in the section on inappropriate usernames. Also, except in extreme cases, it is probably not worth taking action unless the user has made at least one recent edit.

Talk to the user
If you see a username that is problematic but was not obviously created in bad faith, politely draw the user's attention to this policy, and try to encourage them to create a new account with a different username. If you want, you can use the, or  template for this.

Request for comment
If, following an attempt to discuss a problematic username with the user, there is still doubt or disagreement as to whether the name is appropriate, you may open a Request for comment on the username, inviting other users to discuss the issue.

Report blatant violations
If you think a username needs to be immediately blocked and is an obvious case, report it to Usernames for administrator attention. Note that this should only be used for violations which you think clearly merit immediate blocks, without warning.

Do not both warn a user or discuss the matter with a user and at nearly the same time report at Usernames for administrator attention, as a warning or discussion is an invitation to the user to change names or otherwise fix the issue, while the report invites a block which would prevent this.

Report other problems
If the user with a bad username is breaching other policies, such as those against spam or vandalism, follow up using those policies rather than reporting the username. If the user is editing in a biased or promotional way on a subject they appear to have a connection with, report them at the Conflict of Interest noticeboard.

Usernames for administrator attention guidelines
Usernames for administrator attention (UAA) is a noticeboard for drawing attention to abusive usernames quickly. See Usernames for administrator attention/Instructions for information on how to place or resolve UAA reports, including the options that are available to administrators.

Remember that blocking a new user is not actually something we want to do, it is something we do when it is needed to protect Wikipedia from harm. Generally, editors whose usernames are a technical or borderline violation of the Username policy should be given an opportunity to discuss the username and how they may register a new username. However, users who are reluctant to register a new username and are otherwise showing a positive history of contributions to Wikipedia should be allowed to continue editing in a positive fashion and the matter should be dropped. But this exemption does not apply to editors who have a clearly offensive username, disruptive or vandalizing edits, or edits that show a history of problematic bias or conflict of interest.

Real names
Consider carefully before creating an account in your real name or a nickname which might be traced to you, as these increase the potential for harassment, especially if you edit in controversial subject areas. While it is possible to rename your account later (see Changing your username below), a record of your previous username remains permanently.

Do not edit under a name that is likely to imply that you are (or are related to) a specific, identifiable person, unless it is your real name. If you have the same name as a well-known person to whom you are unrelated, and are using your real name, you should state clearly on your userpage that you are unrelated to the well-known person.

If a name is used that implies that the user is (or is related to) a specific, identifiable person, the account may sometimes be blocked as a precaution against damaging impersonation, until proof of identity is provided.

If you have been blocked for using your real name, please do not take offense; we are trying to prevent somebody from impersonating you (or impersonating someone you share a name with). You are welcome to use your real name, but in some cases, you will need to prove that you are who you say you are. You can do this by sending an email to [mailto:info-en@wikimedia.org info-en@wikimedia.org]. Be aware that emails are handled by a volunteer response team and that it may take a while before you receive a reply.

Stage names
Users may use their stage name, pen name, or other nickname as their username, provided that it uniquely identifies a single person. This is not considered promotional, even if commercial performances or publications are made under such a name, unless the user makes promotional edits within Wikipedia about themselves, their projects, etc. However, a user may not use someone else's stage name as a username, as per the section of this page.

Usernames with non-Latin characters
There is no requirement that usernames be in English. Furthermore, contributors are welcome to use usernames that are not spelled using the Latin alphabet, but should bear in mind that other scripts (such as Arabic, Cyrillic, Chinese, Greek, Hebrew, or Japanese) are illegible to most contributors to the English Wikipedia, and sometimes the characters may not appear correctly. To avoid confusion and aid navigation, users with such usernames are encouraged to use Latin characters in their signature. Western-style numerals (0123456789) are also acceptable.

For technical reasons, usernames containing the forbidden characters  are not possible.

Similar usernames
Usernames that are very similar to existing ones cannot be registered normally – but if you do want to use one, you may request its creation at Request an account. Usernames that are similar only to unused or inactive accounts should not be a problem. Special:CentralAuth can be used to check for such usernames. The program that checks for similarity is a bit over-sensitive—if the username is different enough as to prevent other people from confusing the two users, the request should be approved. One should not choose a username that implies a relationship with an existing editor (unless the account is actually owned or the relationship is acknowledged by the editor themselves).

If your username is similar to that of another contributor or an article, you may wish to provide some form of disambiguation, such as by adding distinguish to the top of your user page.

Commonly misspelled usernames
If your username is commonly misspelled, consider helping people by adding redirects to your actual user page and talk page from the misspelled titles. You may wish to consider registering the misspelled username as a doppelgänger account to prevent it from being registered by someone else. The software prevents registration of certain names that are found to be too similar to existing ones; if you cannot register your doppelgänger username for this reason, you should visit Request an account.

UseModWiki-era anonymous users
UseModWiki, the software used on Wikipedia throughout 2001 and in early 2002, treated users who edited without logging in or providing a screen name differently from modern-day MediaWiki. Anonymous users in that time were treated in one of two ways:
 * Domain names: Up until about March 2001, an editor with an IP address "192.0.2.34" that was associated with domain name "host.2.34.example.net" would have their edit logged as being by "host.2.34.example.net". Examples of this are office.bomis.com, dhcp-22-128.lclark.edu, and cnts2p46.uwaterloo.ca. Contributions by users with these usernames are affected by T2323. These usernames are usually indefinitely blocked on sight, as a) they don't make good usernames in light of the above criteria, b) they were never true usernames in the first place and would thus have been abandoned with changing software, and c) modern software is such that an innocent contributor editing from the "host.2.34.example.net" server would not be affected by a block of "User:host.2.34.example.net".
 * Redacted IP addresses: An editor with that same IP address that was not associated with any domain name (or all UseModWiki edits after about March 2001) would have their edit logged as being by "192.0.2.xxx". The Phase II software also exhibited this trait. Examples of this are 209.69.30.xxx and 62.110.183.xxx.

Shared accounts
Any user account should represent an individual and not a group (and an individual should normally only have one user account; see next section). Sharing an account – or the password to an account – with others is not permitted, and evidence of doing so will result in the user being required to stop the practice and change their password, or in sanctions (up to and including the account being blocked), depending on circumstances. For accounts being used to represent a group or organization, see and  above.

Exceptions to this rule can be made for non-editing accounts approved to provide email access, accounts approved by the Wikimedia Foundation (see list), and bot accounts that are maintained by more than one contributor, provided the existence of such an arrangement is made clear and has consensus.

Using multiple accounts
It is recommended that contributors not use multiple accounts without good reason. For example, a user may wish to create an alternate account for use on public computers as a precaution to keep their primary account more secure. Contributors operating any sort of automated editing process should do so under an alternative bot account. It is recommended that multiple accounts be identified as such on their user pages; templates such as User alternative account or one of a selection of user boxes may be used for this purpose.

The use of multiple accounts outside of established policy for doing so is known as sock puppetry, and is not permitted. For example, multiple accounts may not be used to comment on proposals or requests, cast votes, or engage in edit warring. Because policies apply to individuals, not accounts, blocked or banned users must not use sock puppets to circumvent a block; doing so will result in an extension of the block or ban.

Changing your username
Usernames can be changed by global renamers; requests should be made at Changing username. User accounts with few or no edits might not be renamed, as it is quicker and easier to simply.

Once a username has been changed, existing contributions will be listed under the new name in page histories, diffs, logs, and user contributions. Signatures on discussion pages will continue to use the old name; while these can be changed manually, it is not recommended unless a contributor wishes to remove as much information as possible about their former name for privacy reasons. In such situations the old name will still be available in old versions of discussion pages. Username changes are listed in the user rename log and the global rename log.

Deleting and merging accounts
It is not possible to delete user accounts, as all contributions must be assigned to some identifier; either a username or an IP address. Editors seeking privacy per courtesy vanishing / right to vanish can usually have their accounts renamed and their user pages (and in exceptional cases user talk pages) deleted.

It is not currently possible to merge user accounts on the English Wikipedia.

Why was I blocked?

 * You may be an innocent victim of collateral damage, where you are accidentally affected by a block of some other user.


 * Alternatively, your account or IP may have been blocked because it appears to have been responsible for (or connected to) a serious breach of Wikipedia's policies.

If your account was blocked by mistake, it will be reactivated very quickly, as soon as you let an administrator know of the problem. Otherwise, there is a rapid appeal process which obtains quick review by other independent administrators, and brief discussion of the matter. One aim of blocking in some cases is to ensure the user learns from the incident, and that the issues don't happen again.

Common questions
 What is a block?

A block prevents a user or IP range from editing Wikipedia. (They can still read it). Blocks are used to protect Wikipedia from possible improper use, or other activity that may breach editorial policies. Once blocks are over, they become history unless problems recur. Blocks can apply to a user account, an IP address, or a range of IPs. Automated features also identify usage which apparently should be blocked; this can be quickly rectified if incorrect. 

I don't understand why I was blocked.

You may have breached a behavior rule without knowing it. The block notice contains the reason why an administrator has blocked you from editing, usually as a link to a policy or guideline; read it carefully and try to understand how your behavior did not follow it. A block is not intended as punishment; it's meant to prevent you from making disruptive edits, either in good faith or as vandalism. If you can show that you won't make those again, the block should be lifted.

If you don't understand some detail of the policy, you can ask the administrators that blocked you any clarification about their actions, and they're expected to answer them. Don't do such requests within the unblock request, though, as it should be used only when you already understand the reasons for the block.  Should I create a new account to appeal?

No. That is considered evasion. You get a lot of marks on Wikipedia for being honest and not "playing games". You'll do far better to appeal under your usual account (and take the block if that's what is decided) than to be banned for evasion.

Wikipedia has users who were blocked for days or months, accepted it, and were welcomed back and "made good" as respected editors shortly afterwards. Once a block is over, it's over. 

I've never done anything wrong and I was blocked! Please advise.

Do you use an ISP or web accelerator that involves shared IPs? Common examples include Comcast, StarHub, schools, and colleges. If so, you may have been affected by collateral damage.

In such cases, you should request an account to be created for you so that you can edit despite the block, which only affects users who are not logged in. 

I did something a bit wrong, but how do I get unblocked now?

All blocks can be reviewed by, and discussed with, a different administrator who is not involved, if requested.

One common requirement for unblocking is simply "do you understand that what you did was inappropriate for this site, and confirm that you won't do it again".

In the case of shorter blocks, especially for good cause, the usual answer is to wait quietly until the block ends, then you may continue editing, putting it in the past – but learning from it. A repeat of a previous block is often longer than the first one, so it is important to learn from blocks – in a way blocks are intended to guide a user when words don't seem sufficient. 

It says I've been "indefinitely" blocked. What does that mean and how do I get unblocked?

Note that "indefinite" does not necessarily mean "long" or "infinite". It means "however long is needed for the user to address the issue". This can be minutes, hours – or indeed the user may never do so.

An indefinite block means the blocking administrator did not set a time limit on the block. The user needs to discuss the matter with an administrator before any unblock. It could be because the owner needs to confirm things are okay (and nothing's wrong). Or it could be due to some problem needing attention or the user needing to understand some behavior was inappropriate.

Typical examples are where the account owner must be contacted (e.g. suspected 'hacking' of their account), and users whose behavior was severely inappropriate (e.g. threats, "outings", repeated vandalism or edit warring, repeated failure to listen, etc.). Wikipedia is an encyclopedia community so behaviors like these are not acceptable. For some issues, a user may need to stop, learn our site norms, and confirm they will not repeat the behavior (or will edit in accordance with certain conditions), before an unblock can take place. </li>

It says I've been "autoblocked" because of another person whom I don't even know!

See Autoblock for an explanation. If you use a shared ISP (namely Comcast, StarHub, schools, colleges, etc.), you may be affected by collateral damage from other users who have edited disruptively. An administrator will sort this out as soon as it's drawn to their awareness – please follow the instructions under the "Autoblocked?" section on your block page, or alternatively here. </li>

I want to edit Wikipedia, but I keep getting blocked because of others on the same network as me!

If you are an unregistered user, it's recommended that you create an account. Shared IP addresses such as school and company networks or proxy servers are frequently blocked for vandalism which often affects many innocent editors on the same network. However, registered users in good standing can request existing blocks on their IP address be "softened" to only affect anonymous editors on their network so that they may continue contributing. See also Why create an account?.
 * Note: If your IP address is blocked, you may need to create your account at home, on another computer, phone or tablet using a different connection, or (in rare cases) in another country. You can also request that an account be created for you.
 * Note: Many rotating IP addresses of ISPs practising shared IP addresses are blocked as being "proxies" or "zombies" because of the large number of different users sharing the IP. On these computers, logged-in users will be automatically blocked immediately. If you encounter such a case, please follow the unblocking request steps or consult a CheckUser or administrator.

</li> </ol>

Requesting to be unblocked
The preferred way to appeal a block is to place on your talk page, which is only blocked if abused. If you cannot edit your talk page, you can appeal via the Unblock Ticket Request System. If there is something about your block you cannot discuss publicly, you can email the Arbitration Committee (see below).

To test if you are still blocked, click  [ here]  which tries to edit the Sandbox. If you are allowed to edit the sandbox then your block has already expired or been lifted and nothing more needs doing. If the block is still active you can resume editing when unblocked, or you can request a review of the block if you believe it is unfair or that you have put right whatever was the problem.


 * Useful links for helping blocked users:  Message seen by blocked users: MediaWiki:Blockedtext   Requests for unblocking: Category:Requests for unblock

What happens next
When you appeal, other editors – most of whom probably have no involvement in the matter – will review your editing history, which has been logged, as well as the reason for the block and the history leading up to it. Editors may leave comments on your talk page regarding your appeal.

Usually, if it's a clear cut case, any uninvolved (independent) administrator will make a decision. The blocking administrator may be consulted for their comments on your request (this is a common courtesy). The process can take hours or a few days; for major discussions sometimes it can take a week or more.

Administrators will carefully avoid blocking and unblocking fights, which are a serious breach of administrator policy. For this reason, blocks will not usually be allowed to become a source of conflict; rather, consensus will be sought, by means of a fair and objective examination of the matter and of any policies alleged to have been breached.

Routes to unblock
Blocks can be reversed with the agreement by the blocking admin, an override by other admins in the case that the block was clearly unjustifiable, or (in very rare cases) on appeal to the Arbitration Committee.

Types of appeal
In all cases, unblock requests should be submitted on your user talk page. Generally speaking, unblock requests will be one of the following two types:


 * 1) Requests for unblock in the event of a case of mistaken identity, misunderstanding, or other irregularity;
 * 2) Appeals for clemency, in which the appellant acknowledges the conduct that led to their block and requests a second chance.

If the appeal is of the first type, you should use the unblock template on your talk page or submit a request to the Unblock Ticket Request System (UTRS). If the appeal is of the second type, you should use the unblock template on your talk page, and only use UTRS if you cannot edit your talk page.

Direct appeal
Appeals will usually take place on your user talk page; use the unblock template on your talk page to initiate this process:


 * If there is agreement that you may have been blocked unfairly, you may be directly unblocked (if the block was clearly and obviously a mistake), but this is very rare unless there genuinely were no prospective grounds for the block. Usually the blocking admin's judgement is respected if there is any question of doubt.
 * You may be unblocked if the blocking admin changes their mind or can't be reached, and an unblock is considered reasonable.
 * When you are unblocked, you may then follow the dispute resolution process if you believe that you were treated unfairly.
 * If an unblocking needs discussion, reaching a consensus usually takes several days.

Other methods of appeal
In highly unusual cases, you may wish to utilize the dispute resolution process while you are still blocked. To do so, you may contact other Wikipedians by e-mail, or by editing your talk page (which you can usually do even if blocked).

Users may not appeal blocks to the Arbitration Committee by email, except if:
 * The block is an Oversight block or CheckUser block
 * The reasons for the block or information related to your appeal is unsuitable for public discussion
 * You have been blocked or banned by the Arbitration Committee or by an Arbitration Enforcement decision.

Abuse of the unblocking process
A usual block prevents users from editing all pages except their user talk page, in order to have a chance for appeal, and so that they are not shut out completely and are able to participate at least to some degree in Wikipedia, while the block is active.

Upon a request to seek arbitration, editing access may be restored to a limited number of other pages (such as those connected with their appeal) pending the formal decision, so that the matter (and any evidence, facts, mitigating circumstances, or corrections) can be presented as well.

A minority of editors who are blocked use these privileges poorly, for personal attack or to play games and make a point. Inevitably the response to such actions is simple – editing access is blocked in its entirety and without further discussion, whereas if the user had been responsible and reasonable, an entirely different result might well have happened.

Wikipedia blocks are usually warnings only. Once they are over and learned from, they are in the past (unless repeated). Wikipedia and its administrators and arbitration committee have a real wish for everyone who is capable of acting responsibly to be able to enjoy editing.

Users who are blocked are asked to use this as a chance to reflect, an opportunity to show their understanding and ability to act responsibly, and a period of time to let the matter pass and be learned from.

Appeals by third party
Appeals of blocks may be made only by the editor under a currently active block. No appeals will be considered without requests by the blocked user. However, if you are not under an active block but you have questions about blocks of other user, you are free to discuss the block with the blocking admin. (If you are blocked, you should appeal your block first; see WP:NOTTHEM.)

Before you request unblock
It's important that you understand the reasons why the administrator blocked you before starting an unblock request. A block is not intended as punishment; it's meant to prevent you from making disruptive edits, either in good faith or as vandalism.

Don't ask questions within your unblock request; that's reserved to explain why you will not be a problem to the project, not to request clarifications about policy. Before requesting to be unblocked, you can ask the administrators that blocked you any clarification about their actions, and they're expected to answer them, though first you have to read the policies they have linked as the reason for the block. If you need to attract the attention of an administrator, you can write   in your comment and they will get a notice, provided that you sign your edit with four tildes (~).

What happens when you request unblock
It may help with your unblock request if you understand how they are reviewed, and by whom.


 * When you save the unblock request to your talk page, it is automatically placed in a special category for administrator attention.
 * Administrators are volunteers. Be patient. Any review will be carried out by an administrator other than the one who blocked you.
 * An administrator reviewing your request will look at the reasons given for the block, and your unblock request, in light of relevant policies. The aim in each case is to reduce disruption, damage, and similar issues from affecting Wikipedia.
 * They may, if they choose, leave a note for the blocking admin if they feel they need more information and put your request on hold. If they are considering unblock, administrative etiquette requires they inform the blocking admin and allow an opportunity to comment.
 * Often you will find more than one user commenting on your block, or a mini-discussion happening. The administrator who blocked you may contribute, but any decision will be made by the reviewing administrator who takes all points made into account.
 * If your request is accepted, they will leave a templated response on your talk page and unblock. If it is declined, they will give their reasons in an edit to the request template.

Composing your request to be unblocked
Try to make it as easy as possible for the reviewing administrator to see why your block is not or no longer needed. Be clear, using easily readable English. Administrators are volunteers, and may have limited time or patience for trying to find out what you mean to say.

Understand what you did and why you have been blocked
To effectively contest your block, you must understand the reason for it. Also, if the reviewing administrator concludes that the block was justified, you will not be unblocked unless the reviewing administrator is convinced that you understand what you are blocked for, and that you will not do it again.

You are informed about the block reason in two ways. First, the blocking administrator provides a brief reason that you will see when you try to make an edit. Second, the administrator may leave a message explaining your block on your user talk page. These messages should include the names or abbreviations of those of our site rules (the "policies and guidelines") that the blocking administrator believes you have violated.

Before you make an unblock request, you should attentively read the policies and guidelines named in your block reason. They are usually one or more from among the following: vandalism, sockpuppetry, edit warring, violating the three-revert rule, spamming, editing with a conflict of interest or having a prohibited username. You should also review the blocking policy. If you have read these pages and don't understand, then a first step might be to request a clearer explanation. Attempts to work with others and understand their concerns will be seen positively.

Give a good reason for your unblock
As a user requesting to be unblocked, it is your responsibility to explain why you believe your block violates Wikipedia's blocking policy or should otherwise be reversed. Specifically:


 * 1) State your reason for believing your block was incorrect or for requesting reconsideration. It is not enough if you just say that the block was "wrong" or "unfair", or another user violated a policy first. You must explain why it was wrong to block you, or why it should be reversed.
 * 2) Address the blocking administrator's concerns about your conduct (the reason given for your block). As explained above, you have been informed about the reason for your block. You must address this reason in your request. This means that you must either explain why the block reason is incorrect or not applicable to your conduct, or you must convince the reviewing administrator that you won't do it again.
 * 3) Give evidence. If you state that you did or did not do something, or that the blocking administrator is missing something important, please provide brief details and a link in the form of a differential edit ("diff") if possible, or other evidence showing that you don't (or didn't) do what the block reason states.

Stick to the point

 * 1) Be brief.
 * 2) Stay calm. The use of profanities, ramblings, ALL CAPS SCREAMING and personal attacks will lead to the decline of your unblock request without further review of your edit history. The block duration may also be extended.
 * 3) Provide key information briefly. If a mistake has happened, show actual evidence or explain it (briefly). Don't make vague claims that cannot be checked, or allege conspiracies or bad faith unless there is clear good-quality evidence in the form of diffs.
 * 4) Focus on the concerns of the blocking admin and the situation going forward. Show that you understand the blocking administrator's concern and what he/she wants you to do better. Blocks happen because the community has to prevent certain behaviors, and we want you to understand some things matter to us. If you show willingness to appreciate our concerns, discuss the incident in good faith, genuinely learn from mistakes, and show you can keep to the spirit of community policies, often that is all that's needed. If the community still doesn't agree and the block isn't lifted, you will be seen positively when it's over for showing maturity, accepting the outcome, and showing that you are willing to abide by consensus.

Do not make legal threats and do not resort to coercion
You are blocked because of concerns about actions that are a problem. Responding by threats or attempts that show gross lack of understanding makes it worse; it suggests you will not learn in the future.

Genuine defamation, privacy breaches, copyright breaches, and misinformation, are taken very seriously. Gossip, unimportant information, and some private details may also be removed at times. Wikipedia has many ways of checking whether our policies or the law governing our website supports your position, and it fields many user teams for this purpose. We act very quickly in response to well-founded complaints. Often, however, people who think they have legal grounds for complaint actually don't according to the law that governs our content.


 * Wikipedia is not written by an editor-in-chief or paid staff. The Wikimedia Foundation does not act as "editor in chief". It is created and changed by volunteer editors worldwide, and other editors may differ with your view.
 * Wikipedia is a neutral reference work. If editors see your demand as one-sided, poorly supported, or inappropriate (for examples, a) the creation of a glowing article about yourself or b) the removal of a matter that others feel is appropriate, sourced to a high standard, and written fairly) then you may be unsuccessful. That is how it should be. Do not use Wikipedia for advocacy, PR/promotion, battles or writing about yourself and connected organizations.  Given Wikipedia's status as a neutral reference work, if others do not agree with you or do not feel our content policies have been violated, then it is very unlikely that a threat will accomplish any goal that you may have.
 * The Wikipedia community (editors) usually doesn't care about legal threats you make. They care about our content and our criteria for suitability, quality, and reliability. If they review your complaint and disagree, then a legal threat will not change their mind. The Wikimedia Foundation legal staff will simply decline to act because of threats if they believe there is no legal case; if there is a legal case or other fair reason they agree with, then a threat isn't needed anyway — they will be glad to quickly help.

If you don't know what to do, then the email team is a very good starting point. Do not make threats, and do not ask or hire a lawyer to write — doing so is no more effective than a simple personal email and may get you blocked if your message appears to contain any kind of implied legal or other threat.

If you did make a threat and were blocked, then taking it back is often a big part of being unblocked. A message to the effect of "I take back my threat and won't repeat it again; can anything be done to resolve this?" is a good approach. Ask for advice; don't shake a stick.


 * 1) Don't treat your unblock request like a legal proceeding. As explained here, a ban or block is a revocation or suspension of your privilege to edit Wikipedia. Because we are a privately owned website, your freedom of speech does not prevent us from enacting and enforcing our own policies and guidelines.  In order to prevent abuse, we may also check your IP address and other accounts using it.
 * 2) Don't threaten or imply legal action. Making a legal threat to get your way will almost always result in an immediate indefinite block since it conflicts with the principle of respecting consensus decisions, and also to prevent escalation happening here. Just don't go there:  If your concern is valid, other channels are sufficient to address it; if not, then no channel will be sufficient.
 * 3) Do not offer to make a donation to Wikipedia to get unblocked (or, for that matter, threaten to stop donating to Wikipedia unless you're unblocked). While the Wikimedia Foundation will certainly appreciate any donations, making one will not in any way impact your chances of being unblocked. The administrators reviewing your block are pure volunteers and do not work for the Foundation. They decide appeals based on concerns about behavior that may disrupt editorial activities; they are completely unaffected by whether or not you will donate. In any event, such an attempt amounts to an attempt at bribery and tends to confirm that you still do not understand why your behavior is a problem – a much more serious concern.
 * 4) Do not threaten or imply retaliation. It will not help you in the slightest but rather will lead only to a more comprehensive block or an escalation to a ban.

Talk about yourself, not others
You are blocked because of what you did, not because of what others did. For this reason:


 * 1) Do not complain about other people, such as editors you may have been in a conflict with, or the blocking administrator. Disagreements with others should be addressed through dispute resolution after you are unblocked, but your unblock request is not the place for this. The only thing that your unblock request needs to address is why you did not in fact disrupt Wikipedia or why you will no longer do so. Unblock requests that contain personal attacks or incivility against others will be declined and may lead to being blocked from your talk page.
 * 2) Do not excuse what you did with what others did. Two wrongs do not make a right. An unblock request that just asks administrators to block another editor will be declined.
 * 3) Assume good faith towards others. The other editors who may have reported you, and the administrator who blocked you, and everybody involved, are not part of a diabolical conspiracy against someone half a world away they've never met in person, and an unblock request that presumes they are will probably not be accepted.
 * 4) Assume others have assumed (and will assume) good faith towards you. The blocking administrator will have tried to assume good faith on your part, as did any administrator who had reviewed previous requests, and the administrator who will review your current request. There is not much need to remind administrators to assume good faith, or to accuse administrators of failure to do so.

Agree to follow Wikipedia community customs
If you are blocked for something you did wrong, and especially if you are blocked for a long time, you are more likely to be unblocked if you:


 * 1) Admit to it. All your contributions to Wikipedia are logged. There is no point in denying something that you did do (or that other editors examining the record agree it is very likely that you did), because your edits can and will be checked. Even if they were deleted, all administrators, including the one who will answer your unblock request, can still see it.
 * 2) Give people a reason to trust you again. Promise, credibly, that you will stop doing whatever got you blocked. Earn back our trust by proposing improvements to articles or proposing firm steps you will take so the issue cannot happen again.
 * 3) Don't do it again. If you were blocked for an offensive statement or legal threat, do not repeat it in your unblock request. Even if you feel that your conduct did not deserve a block, evidently at least one administrator disagrees with you on that point. Assume that the reviewing administrator will agree with the  block, and write your request in a way that cannot give further offense.
 * 4) Tell us why you are here. Say how you intend to help contribute to the encyclopedia after you are unblocked. See here for some ideas about what you could do.

If unsatisfied despite everything
In most cases, if others disagree with your request then it's best to accept it. Rarely, a situation may have become so heated or words exchanged, or there may be a genuine reason to worry that the blocking admin has misunderstood or is being extremely unfair. Do not "rant", "flame" or attack others even if you feel attacked yourself. It is the worst thing you can do.

If you have good cause for worrying, it is far better to check you have briefly and calmly made clear your concern and any evidence, and just ask for other independent opinions. Administrators asked to independently review a matter will come to it fresh - often more than one will respond - and may be able to explain or help. They will also consider whether or not the blocking admin appears to have acted reasonably, and what they think has to happen. If they disagree with you, then this can be useful reassurance that the initial view was not unreasonable.

Examples of bad unblock requests
Requests such as these are likely to be denied. If made repeatedly, they may lead to your block being extended or removal of talk page access by either a change of block settings or your talk page being protected from editing.

Arbitration enforcement blocks
Special rules apply to users who have been blocked because they violated an Arbitration Committee decision, or restrictions imposed on them (such as discretionary sanctions) by administrators in accordance with an Arbitration Committee decision.

A reviewing administrator acting alone, therefore, is not allowed to undo another administrator's arbitration enforcement block. (This does not preclude the blocking administrator from accepting an unblock request from the blocked editor.)

To request that such a block be lifted, you may:
 * Address your appeal to the blocking administrator either on your talk page or by email (using the "Email this user" function on their talk page).
 * Address your appeal to either the arbitration enforcement noticeboard or the administrators' noticeboard by using the unblock template, asking the reviewing administrator to initiate a community discussion. You should prepare the appeal in the form provided by the template Arbitration enforcement appeal on your talk page, below the unblock request, so that the reviewing administrator may simply copy it to the appropriate community forum.
 * Address your appeal to the Arbitration Committee by sending an email to Special:EmailUser/Arbitration Committee (or, if email access is revoked, to ).

Banned users
Banned users, too, have special rules for their appeals. See WP:UNBAN for procedures of ban appeal.


 * Users banned by Jimbo Wales must appeal either to him or the Arbitration Committee.
 * Users banned by the Arbitration Committee must appeal to the Committee (normally by sending email to arbcom-en@wikimedia.org.) For users also under community sanction, ArbCom usually will consult an unblock condition with the banned user, and place it either at Arbitration Committee/Noticeboard or as an amendment request to allow community to comment. The ban will not be lifted without sufficient community comment.
 * Users banned by the community (but not under ArbCom bans or blocks designated to be appealed to ArbCom only) are normally unbanned only after a community discussion at the administrators' noticeboard determines whether there is consensus to lift the ban. You should read Standard offer before appealing an community ban. Users may be considered banned by community for repeated abuse of multiple accounts. Such users may either appeal to community or Arbitration Committee, but after a CheckUser being consulted they will usually be deferred to administrators' noticeboard

Compromised accounts
If you state in your request that the edits that led to your block were made by someone else who accessed your account, we will have to leave it blocked. You may have changed the password, but unless they've met you at a meetup or otherwise know you personally, administrators have no way of knowing that you are indeed back in control of your account. (And even if you meet someone in person, without seeing some strong evidence like a passport, how can you prove they are who they claim to be?)

For this reason, if your account is blocked as compromised, do not make unblock requests unless you can demonstrate that you have regained control of your account. Instead:
 * Create a new account and make sure to choose a strong password. If an autoblock prevents you from doing that, use a computer in a different location (that is, with a different IP address).
 * With your first edits, clearly identify the new account as a successor account of the blocked account, for example by adding the code to the user page of the new account (replace "Old Username" with the username of the blocked account). If you do not do this, your new account may be blocked as an abuse of multiple accounts.
 * Follow the advice in Personal security practices to prevent your new account from becoming compromised again.

If you create a new account while you are blocked not only because your old account is compromised, but also for other reasons, your new account will likely also be blocked to prevent you from evading the block of your old account. In this case, you will need to request to be unblocked with your new account and address the other reasons for which your old account was blocked.

Sockpuppetry blocks
Accusations of sockpuppetry result in many blocks and almost as many unblock requests, as Wikipedia policy calls for the sockpuppet account to be blocked indefinitely and the sockpuppeteer to be blocked for some length of time (possibly also indefinitely). Users confirmed or believed to have engaged in the practice must request unblock at their main account. Meatpuppets will be blocked indefinitely, too ... don't edit on behalf of someone else, no matter how well you may know them.

Reviewing admins will usually defer to the blocking admin in a sockpuppetry-based block, especially if the sock account has minimal edits. Even without the use of the Checkuser tool, or with a result of "unrelated", an account that makes the same edits as a different blocked account, has the same linguistic peculiarities and the same general interests may remain blocked under the "quacks like a duck" test.

Wikipedia admins can never be absolutely sure about sockpuppetry, and the most abusive users can be very devious in attempting to evade detection. If you are improperly blocked for sockpuppetry, you should realize that it may not always be easy or even possible to correct the situation.

If you actually are guilty of sockpuppetry, and want to get a second chance at editing, please do as follows:
 * 1) Refrain from making any edits, using any account or anonymously, for a significant period of time (e.g. six months).
 * 2) Make the unblock request from your original account. Sockpuppeteers aren't often unblocked&mdash;since they've acted dishonestly, it's hard to believe them&mdash;and the administrators certainly aren't going to unblock the sockpuppet account.

See also guides for appealing CheckUser blocks and bans for repeated abuse of multiple accounts (you should still follow the advice above if you are guilty of sockpuppetry).

Checkuser and Oversight blocks
A small number of administrators also known as functionaries have access to additional technical tools. The CheckUser tool may be used in special circumstances to determine whether multiple accounts or IP addresses are used by the same person. The Arbitration Committee has [//en.wikipedia.org/w/index.php?title=Wikipedia:Arbitration_Committee/Noticeboard&oldid=374236853#Statement_on_checkuser_blocks explained] the procedure to be followed with respect to the review of blocks based on CheckUser data as follows:

"The Arbitration Committee would like to remind administrators that those with Checkuser permission may sometimes block accounts as a result of findings that involve confidential Checkuser data. When such blocks are appealed, non-Checkuser administrators will generally not be privy to all the information that the Checkuser relied on in deciding to block. Moreover, in many cases the Checkuser may not be able to share such information because doing so would violate the privacy policy. Therefore, in most cases, appeals from blocks designated as "Checkuser block" should be referred to the Arbitration Committee, which will address such appeals as promptly as possible. If an administrator believes that a Checkuser block has been made in error, the administrator should first discuss the matter with the Checkuser in question, and if a satisfactory resolution is not reached, should email the committee. As appropriate, the matter will be handled by the Ban Appeals Subcommittee, by the Arbitration Committee as a whole, or by an individual arbitrator designated by the committee. When an unblock is appropriate – either because the reviews disagree with the initial checkuser findings, or for other reasons – it will be granted. This policy applies only to blocks designated as "Checkuser blocks", that is as blocks relying on confidential checkuser findings. It does not apply to ordinary blocks by an administrator who happens to be a Checkuser, but is not relying on checkuser data in deciding to block. These blocks may be reviewed on-wiki or on unblock-l, the same as any other block. Checkusers are reminded that because designating a block as a "Checkuser block" means that it cannot be reviewed on-wiki or on unblock-l, this term should only be used when confidential information has been used in the blocking decision."

- Statement on checkuser blocks and reversal thereof. Emphasis added.

Do not make an unblock request that includes a request for checkuser to "prove your innocence" ... as indicated at Sockpuppet investigations those are so rarely done that you're better off not asking (besides, it is difficult to use it to prove that two editors are different people). Most administrators consider such an unblock request a sure sign of a sock account (particularly one with very few edits otherwise) and will decline on that basis.

A similar situation applies to blocks relating to Oversight. If your block relates to Oversight issues, then it concerns edits or log actions you have made which had to be suppressed. This is an extreme form of deletion used for removing potentially defamatory material, serious copyright violations, and non-public personal information including but not limited to addresses, phone numbers, or identities of pseudonymous or anonymous individuals who have not made their identity public. Suppressed edits and log entries can only be viewed by Oversighters, and like CheckUser-based blocks, Oversight blocks can also neither be reviewed on-wiki or on unblock-l for similar privacy related reasons, nor be reviewed by most administrators. The Arbitration Committee has stated:

"Appeals of blocks that have been marked by an oversighter as oversight blocks should be sent to the oversight team via email to be decided by the English Wikipedia oversighters, or to the Arbitration Committee. Blocks may still be marked by the blocking oversighter as appealable only to the Arbitration Committee, per the 2010 statement, in which case appeals must only be directed to the Arbitration Committee."

Edit warring blocks, including "Three-revert rule" blocks and others
Many established users who request unblock do so because they have been blocked for edit warring. They often post lengthy explanations, with many linked diffs, of why they did not actually violate the three-revert rule. If this is what you intend to do, be advised that such unblock requests often take longer to review than others. Given that many edit warring blocks are for a short duration (36 hours or less), long and detailed unblock requests will often go unanswered or will take so long to investigate that the block will expire on its own. Also, be aware that 3RR is seen as an "electric fence" and that with VERY few exceptions (such as reverts of patent nonsense/vandalism or of egregious libel violations) most admins see any violation of the three-revert rule as justifiably blockable. Being "right" is not an exception to the three-revert rule, and claiming that your version is the "better" version is not a reason that will get you unblocked.

Also, be aware that there are many situations in which it is possible to be blocked for edit warring even if you did not break the "three revert rule". For example, if you have made the same revert a large number of times over a long period, you may be blocked even if there was never a period of 24 hours in which you made four reverts. Also, any sequence of edits that violates the "spirit", if not the "letter", of the three-revert rule are just as worthy of a block. Intentionally gaming the system by waiting 24 hours before your fourth revert, or subtly changing your version each time so it is not a perfect revert, or otherwise edit warring over the article is seen to be editing in bad faith, and your block is unlikely to be lifted in these cases, even if you did not revert more than three times in 24 hours.

"Bad username" blocks
Accounts with usernames that do not conform to the username policy are often blocked indefinitely, regardless of their editing behavior. Most commonly this is because of a name that wholly or closely matches the subject of an article or a link added as spam or otherwise in violation of the external links policy.

Most such accounts are soft-blocked, meaning a new account may be created while the old one is blocked. This is done because it is the account name, not the behavior of the person behind it, which is the problem. While it is possible to request a change in username, this takes a little longer and requires that a user with global rename access do so. Whichever method you choose, it is a good idea to have some review of the proposed new username first, to avoid ending up in the same quandary.

An account with a username that uses hateful or obscene language or otherwise indicates disruptive or provocative intent will be hard blocked, meaning that an unblock request will be required.

Advertising-only accounts
Accounts that seem to exist only to promote somebody or something ("spamming") are normally indefinitely blocked, because Wikipedia may not be used for promotional purposes. Such promotion may include posting articles that read like advertisements or inserting inappropriate links to other websites.

As an advertising-only account, you will not be unblocked unless you indicate that you will stop your promotional activities. In addition, you must convince administrators that you intend to make constructive contributions to Wikipedia that are unrelated to the subject of your promotion if unblocked. To do so, your unblock request should include specific examples of productive edits that you would like to make.

Blocks directed at a problem generally ("collateral damage")
A number of blocks exist because they are preventing abuse from a given source, such as a proxy server or a particular ISP used by many people. In such cases some users will be responsible for the problem; others may be unavoidably blocked by the solution.

An administrator or checkuser will investigate and consider whether it is likely this has happened.

Open proxy blocks
Wikipedia policy on open proxies is clear: editing through them is blocked without exception once identified. While some users can use them to circumvent censorship or filters, they have been used far too many times by far too many blocked vandals for Wikipedians to assume good faith on their part. This includes Tor nodes. If your server has been blocked as an open proxy, you will probably need to edit via another connection: in most cases, proxies are "hard blocked", which prevents even logged-in users from using the connection to edit.

The only way such a block can be lifted is if it can be determined that it is no longer an open proxy, or was erroneously identified as one. If you believe this to be the case, say so in your unblock request and the administrator will refer it to the open proxies project, where verified users can determine if it is indeed an open proxy.

Shared IP blocks/Range blocks
Occasionally readers who have never or rarely edited before, or not from that location, with no intention of registering an account, click on edit only to find that editing from their IP address is blocked, for something they didn't do. If you are here because this happened to you, there are two possibilities.


 * Range block. Wikipedia administrators can choose to block a range of IP addresses rather than just a single one. This is done if a vandal, sockpuppeteer or otherwise disruptive user has taken advantage of dynamic IP or other situation (such as some LANs) where it is possible to evade blocks by hopping from IP to IP or physically moving from one terminal to another. Yes, this inconveniences many users (the longterm rangeblocks imposed on some large ranges mean that, in certain geographic areas, some users cannot edit without using a registered account). But the Wikipedia community does not take these actions lightly, and while some rangeblocks may be reduced in scope if they were imposed on too many users, it is only done if other methods of protecting the project and its users have failed. If you are affected by collateral damage from a long term range block, consider creating an account either from another computer or via an email request.
 * Shared IP block. This affects large institutions, most commonly schools, that route all their Internet traffic through one or two servers. Since many users can edit through them and we have no way of knowing if a vandal or disruptive user on a shared IP has been prevented from doing so again, or what security arrangements are in place on the other end, administrators are wary of unblocking shared IPs. Those that are blocked (again, primarily schools), are commonly blocked repeatedly and for long periods (up to a year at a time) for blatant vandalism. If the reviewing administrator sees that reflected in the talk page, block log and edit history, the unblock request will likely be declined. If you are the systems administrator at a site with a shared IP, and you can identify and take action against users whose conduct on Wikipedia led to the block, we may consider an unblock if you can prove this. Most commonly, though, the best solution for Wikipedia and users alike is to simply create a registered account and edit with it. This can be done by connecting to Wikipedia through another internet connection that is not blocked, or by making a request via the process at Request an account.

Types of bans
The following are the common types of bans; other bans may be used when appropriate.

Site ban
Unless otherwise specified, a ban is a site ban. An editor who is site-banned is forbidden from making any edit, anywhere on Wikipedia, via any account or as an unregistered user, under any and all circumstances. The only exception is that editors with talk page access may appeal in accordance with the provisions below.

Article ban or page ban
An article ban forbids an editor from editing a specific article or set of articles. The text of the ban should state whether the ban includes or excludes the article's talk page. Editors subject to an article ban are free to edit other related pages or discuss the topic elsewhere on Wikipedia.

When the word "page" is used in a ban it means any page on Wikipedia, including for example user, talk, discussion, file, category or template pages. The word "article" usually refers only to mainspace pages. If any other related pages (such as the page's talk page) are to be covered it will usually be stated explicitly.

Topic ban
The purpose of a topic ban is to forbid editors from making edits related to a certain topic area where their contributions have been disruptive, but to allow them to edit the rest of Wikipedia. Unless clearly and unambiguously specified otherwise, a topic ban covers all pages (not only articles) broadly related to the topic, as well as the parts of other pages that are related to the topic, as encapsulated in the phrase "broadly construed". For example, if an editor is banned from the topic "weather", this editor is forbidden from editing not only the article Weather, but also everything else that has to do with weather, such as:
 * weather-related articles and lists, such as Wind and List of weather records, and their talk pages;
 * weather-related categories such as all of the categories that are associated with Category:Weather;
 * weather-related project pages, such as WikiProject Meteorology and Portal:Weather;
 * weather-related parts of other pages, even if the pages as a whole have little or nothing to do with weather: the section entitled "Climate" in the article California, for example, is covered by the topic ban, but the rest of the article is not;
 * discussions or suggestions about weather-related topics anywhere on Wikipedia, for instance a deletion discussion concerning an article about a meteorologist, but also including edit summaries and the user's own user and talk pages (including sandboxes).

Interaction ban
The purpose of an interaction ban (IBAN) is to stop a conflict between individuals. A one-way interaction ban forbids one user from interacting with another user. A two-way interaction ban forbids both users from interacting with each other. Although the interaction-banned users are generally allowed to edit the same pages or discussions so long as they avoid each other, they are not allowed to interact with each other.

Editors subject to an interaction ban are not permitted to:


 * edit each other's user and user talk pages;
 * reply to each other in discussions;
 * make reference to or comment on each other anywhere on Wikipedia, directly or indirectly;
 * undo each other's edits to any page, whether by use of the revert function or by other means;
 * use the thanks extension to respond to each other's edits.

A no-fault two-way interaction ban is often a quick and painless way to prevent a dispute from causing further distress or wider disruption.

Exceptions to limited bans
Unless stated otherwise, article, page, topic, or interaction bans do not apply to the following:


 * Reverting obvious vandalism (such as page content being replaced by obscenities) or obvious violations of the policy about biographies of living persons. The key word is "obvious" that is, cases in which no reasonable person could disagree.
 * Engaging in legitimate and necessary dispute resolution, e.g. addressing a legitimate concern about the ban itself in an appropriate forum. Examples include:
 * asking an administrator to take action against a violation of an interaction ban by another user (but normally not more than once, and only by mentioning the fact of the violation)
 * asking for necessary clarifications about the scope of the ban
 * appealing the ban

As a banned user, if you think your editing is excepted from the ban according to these rules, you should explain why that is so at the time of the edit, for example in the edit summary. When in doubt, do not make the edit. Instead, engage in dispute resolution or ask whoever imposed the ban to clarify.

Decision to ban

 * See also: Category:Banned Wikipedia users and Long-term abuse. Note that the absence of editors from these lists does not necessarily mean that they are not banned.

Authority to ban
The decision to ban an editor can be made by the following groups or persons:


 * 1) The Wikipedia community can impose a ban by consensus, as described in the section below.
 * 2) The Arbitration Committee can use a ban as a remedy, usually following a request for arbitration.
 * 3) The Arbitration Committee may delegate the authority to impose bans. It has authorized administrators to impose "discretionary sanctions" (including bans) in certain topic areas (see Arbitration Committee/Discretionary sanctions).
 * 4) Jimbo Wales retains the authority to ban editors.
 * 5) The Wikimedia Foundation has the authority to ban editors (see meta:WMF Global Ban Policy and Category:Wikipedians banned by the Wikimedia Foundation), though it has rarely exercised this authority on the English Wikipedia individually.
 * 6) Users may be globally banned from English Wikipedia and all other Wikimedia projects, either by the broader Wikimedia community or by the Wikimedia Foundation. In case of the former, English Wikipedia users will be explicitly invited to participate in the Meta-Wiki discussion to ban the user in question.

Except as noted above, individual editors, including administrators, may not directly impose bans.

Community bans and restrictions
The community may reach a consensus to impose various types of sanctions on editors:


 * If an editor has proven to be repeatedly disruptive in one or more areas of Wikipedia, the community may engage in a discussion to impose a topic ban, interaction ban, site ban, or other editing restriction (which may include a limited-duration or indefinite block) via a consensus of editors who are not involved in the underlying dispute. When determining consensus, the closing administrator will assess the strength and quality of the arguments made.
 * In some cases the community may review a block or an editor's unblock request and reach a consensus of uninvolved editors to endorse the block as a community sanction.
 * Editors who are or remain indefinitely blocked after due consideration by the community are considered "banned by the Wikipedia community".

Community sanctions may be discussed on the Administrators' noticeboard (preferred) or on Administrators' noticeboard/Incidents. Discussions may be organized via a template to distinguish comments by involved and uninvolved editors, and to allow the subject editor to post a response. Sanction discussions must be kept open for at least 24 hours to allow time for comments from a broad selection of community members. If the discussion appears to have reached a consensus for a particular sanction, an uninvolved administrator closes the discussion, notifies the subject accordingly, and enacts any blocks called for. Except for a site ban, the sanction should be logged at the appropriate venue if necessary, usually Editing restrictions or Long-term abuse. If a block is administered to enforce a community sanction, please include a link to the discussion and note that the block is enforcing a community sanction in the block log.

Editors without usernames may be banned by the community (example), but bans of editors using only IP addresses are rare.

Bans for repeated block evasion
Editors who are confirmed by a CheckUser to have engaged in sockpuppetry on at least two occasions after an initial indefinite block that is active, for any reason, are effectively site banned by the Wikipedia community. CheckUser findings must be documented on Wikipedia before a user is considered banned. Users who have been banned in this way are subject to the same unban conditions as users banned by community discussion.

Administrators or sockpuppet investigations clerks will normally tag the master account's user page with. If the user made substantial good faith contributions before being banned, a notice should be placed on the administrators' noticeboard alerting the community to the ban.

Recidivism may lead to a ban
In 2012, the Arbitration Committee decided that "Users who have been sanctioned for improper conduct are expected to avoid repeating it should they continue to participate in the project. Failure to do so may lead to the imposition of increasingly severe sanctions."

Duration of bans
Bans are not intended as a short-term measure. Sometimes a ban may be for a fixed period of some months. More often no period is specified, because the ban is a decision that the editor may not edit or participate in the specified matters on this site.

Appeals of bans imposed by the community
Bans imposed by the community may be appealed to the community or, where there are serious questions about the validity of the ban discussion or its closure, to the Arbitration Committee.


 * Editors who are banned from a topic area or certain pages but can otherwise edit, may appeal (and comment in an appeal discussion) on-wiki, either at the administrators' noticeboard, or, if there are serious questions about the validity of the ban discussion or its closure, by filing a case request.
 * Editors who cannot edit any page except their talk page may:
 * Post an appeal unblock template or comment there, by email or other off-site means such as the Unblock Ticket Request System (UTRS), and ask for it to be reposted to the appropriate discussion board. This is a voluntary act and should not be abused or used to excess.
 * Submit an appeal to UTRS and ask an administrator to post it to the appropriate discussion board. This is a voluntary act and should not be abused or used to excess.
 * Where there are serious questions about the validity of the ban discussion or its closure, appeal by email to the Arbitration Committee. An email appeal must specify the banned editor's Wikipedia username and any other usernames he or she has used to edit Wikipedia in the past two years. (Using Wikipedia's email feature to email Arbitration Committee automatically reveals the account used for sending it.) The appeal should clearly but succinctly explain the reasons the editor feels the ban should be overturned, such as what lessons the editor has learned since the ban or block was imposed, how the editor would conduct himself or herself differently in the future if they are allowed to resume editing, or why they believe the ban was unfair. The editor should also include links to any relevant on-wiki discussions and any other information necessary to understand the grounds for the appeal.
 * Editors unable to edit any page (even their talk page) should appeal through the Unblock Ticket Request System asking an administrator to post their appeal to the appropriate discussion board. This is a voluntary act, and should not be abused or used to excess.
 * In some cases, a banned editor may be unblocked for the purpose of filing an appeal. In such cases, editing of any unrelated page or other matter is grounds for immediate re-blocking. Editors banned by the Arbitration Committee must appeal to the Committee.

Appeal to the Arbitration Committee

 * Editors who are banned from a topic area or certain pages but can otherwise edit, may appeal (and comment in an appeal discussion) on-wiki, by filing an amendment request.
 * Editors who are blocked from editing by the Arbitration Committee can appeal by emailing the Arbitration Committee using the EmailUser function or, if email is disabled, by emailing . An email appeal must specify the banned editor's Wikipedia username and any other usernames he or she has used to edit Wikipedia in the past two years. The appeal should clearly but succinctly explain the reasons the editor feels the ban should be overturned, such as what lessons the editor has learned since the ban or block was imposed, how the editor would conduct himself or herself differently in the future if they are allowed to resume editing, or why they believe the ban was unfair. The editor should also include links to any relevant on-wiki discussions and any other information necessary to understand the grounds for the appeal.

Appeal to Jimbo Wales
Any arbitration decision may be appealed to Jimbo Wales. While it is not unusual for him to consider an appeal, it is exceedingly unusual for him to overturn such a decision. A topic-banned editor cannot discuss the topic ban or topic on Jimbo's talk page, but is allowed to appeal the topic ban to Jimbo Wales. An appeal should be lodged at his user talk page within one week of the ArbCom decision.

Arbitration enforcement bans
The following are the applicable parts from the standard provision for appeals of arbitration enforcement bans:

Evasion and enforcement
Wikipedia's approach to enforcing bans balances a number of competing concerns:


 * Maximizing the quality of the encyclopedia.
 * Avoiding inconvenience or aggravation to any victims of mistaken identity.
 * Maximizing the number of editors who can edit Wikipedia.
 * Avoiding conflict within the community over banned editors.
 * Dissuading or preventing banned editors from editing Wikipedia or the relevant area of the ban.

As a result, enforcement has a number of aspects. While all editors are expected to respect the enforcement of policies by not undermining or sabotaging them, no editor is personally obligated to help enforce any ban.

Bans apply to all editing, good or bad
Editors are site-banned only as a last resort, usually for extreme or very persistent problems that have not been resolved by lesser sanctions and that often resulted in considerable disruption or stress to other editors. A site ban is not merely a request to avoid editing "unless they behave". The measure of a site ban is that even if the editor were to make good edits, permitting them to re-join the community is perceived to pose enough risk of disruption, issues, or harm, that they may not edit at all, even if the edits seem good.

A number of banned editors have used "good editing" (such as anti-vandalism edits) tactically, to try and game the banning system, "prove" they cannot be banned, or force editors into the paradox of either allowing banned editing or removing good content. Even if such editors make only good edits, they will be rebanned for evasion.

On very rare occasions, a limited exception may be requested; for example, to participate in a particular discussion.

If there is any doubt whether a limited ban prohibits any specific edit, the banned editor should assume that it does, unless whoever imposed the ban expressly clarifies that it does not. If clarification is not sought before making the edit, the banned editor assumes the risk that an administrator takes a broader view of the scope of the ban and enforces it with a block or other sanction.

Blocks
In the case of project-wide bans, the primary account of any banned editor may be entirely blocked for the duration of the ban.

If the banned editor creates sock puppet accounts to evade the ban, these usually will be blocked as well. When evasion is a problem, the IP address of a banned editor who edits from a static IP address may also be blocked for the duration of the ban. If a banned editor evades the ban from a range of addresses, short-term IP blocks may be used.

Reset of ban following evasion
It is customary for the "ban timer" to be reset or extended if a banned editor attempts to edit in spite of the ban. No formal consideration is typically necessary. For example, if someone is banned for ten months, but on the sixth month attempts to evade the ban, then the ban timer may be reset from "four months remaining" to "ten months remaining", so if the editor does not subsequently evade the ban again, his or her eventual total duration would be 16 months. Repeated evasion may lead to a longer or more serious sanction.

An editor who has been banned or has had their account blocked, and tries to evade this by creating a new account, is known as a reincarnation of the old account. Obvious reincarnations are easily dealt with—the account is blocked and contributions are reverted or deleted, as discussed above. See sock puppet for policy on dealing with unclear cases.

Edits by and on behalf of banned editors
Anyone is free to revert any edits made in violation of a ban, without giving any further reason and without regard to the three-revert rule. This does not mean that edits must be reverted just because they were made by a banned editor (obviously helpful changes, such as fixing typos or undoing vandalism, can be allowed to stand), but the presumption in ambiguous cases should be to revert.

When reverting edits, care should be taken not to reinstate material that may be in violation of such core policies as neutrality, verifiability, and biographies of living persons.

Pages created by banned users in violation of their ban, and which have no substantial edits by others, are eligible for speedy deletion under the G5 criterion. If editors other than the banned editor have made good-faith contributions to the page or its talk page, it is courteous to inform them that the page was created by a banned editor, and then decide on a case-by-case basis what to do. If the edits by the good faith editors are substantial, G5 no longer applies.

Since categorization can impact many pages, and deletion of a category without merging can leave pages orphaned, you should carefully consider what to do with categories created by a banned user. Blatantly useless categories can be speedy-deleted, as well as any categories which clearly violate existing category standards. Care should nonetheless be taken to see if articles need to be merged to a parent category before the speedy deletion. Categories created by a banned user which may be useful or fit into a larger category scheme should be tagged for discussion and possible merging using the categories for discussion process instead of deleting them outright.

Proxying
Wikipedians in turn are not permitted to post or edit material at the direction of a banned or blocked editor (sometimes called proxy editing or proxying) unless they are able to show that the changes are either verifiable or productive and they have independent reasons for making such edits. Editors who reinstate edits made by a banned or blocked editor take complete responsibility for the content.

New accounts which engage in the same behavior as a banned editor or blocked account in the same context, and who appear to be editing Wikipedia solely for that purpose, are subject to the remedies applied to the editor whose behavior they are imitating. See also the policy on sockpuppetry and meatpuppetry.

User pages
Banned editors' user and user talk pages should be updated with a notice of the ban, linking to any applicable discussion or decision-making pages. The purpose of this notice is to announce the ban to editors encountering the banned editor's edits. Indefinitely site-banned editors may be restricted from editing their user talk page or using email.

Further enforcement measures
Serious, ongoing ban evasion is sometimes dealt with by technical means or by making an abuse complaint with the operator of the network from which the edits originate.

Difference between bans and blocks
The standard distinction is that a ban is a social decision about the right to edit; a block is a technically imposed enforcement setting.

The MediaWiki software does not have the capability to prevent editing selectively. Editors who are banned from specific pages or topics must immediately cease editing these pages or topics. If they do not, then a block will be used to enforce the ban. Such a block will necessarily prevent their editing of the entire site, but they are not banned from the site and remain members of the community.

An editor who is "sitebanned" (which may sometimes be described as a "full ban") has been completely ejected from the project. For the duration of their ban, their edits are subject to reversion, although personal attacks towards them remain unacceptable.

Conduct towards banned editors
Wikipedia's hope for banned editors is that they will leave Wikipedia or the affected area with their pride and dignity intact, whether permanently or for the duration of their ban. It is unacceptable to take advantage of banned editors, whether by mocking, baiting, or otherwise abusing them. Personal attacks, outing and other behaviours remain unacceptable even if directed towards a banned editor.

Scope and reciprocity
The English-language Wikipedia does not have authority over the Meta-Wiki, Wikimedia sister projects, or Wikipedias in languages other than English. As such, bans issued by the English Wikipedia community or Arbitration Committee are not binding on other projects.