Preliminary: education and warnings Some of the key precepts of this section may be explained using {{
Before blocking}}.
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.
Blocking is a serious matter. The community expects that blocks will be made for 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.
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.
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 oversighter 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. Private evidence involving undisclosed paid editing may be sent to
paid-en-wpwikipedia.org.
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.
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.
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:
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 are to reduce administrative burden; they are made under the 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.
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" or "permanent". 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.
Several options are available to modify the effect of blocks, which should be used in certain circumstances:
- Sitewide block will prevent the user from editing any page on Wikipedia with the exception of their own user talk page. This is the option that is set by default, and should be used when there is a reasonable assumption that the account would disrupt any page, such as vandalism-only accounts or users that are clearly not here to write an encyclopedia.
- Partial block will prevent the user from editing a specific set of pages, or from a particular set of namespaces. Either option may be set, or a combination of both may be chosen. There is a software limit of 10 pages per block; beyond this, sitewide blocking should be considered instead.
- 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 either the blocked user abuses it, or uses it to harass, threaten, intimidate, or cause disruption toward other editors. In instances when administrators feel that email abuse is extremely likely, they may use their discretion and enable this option to prevent it from occurring. 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. While this option can be enabled when blocking IP addresses or IP ranges, it serves no purpose in these situations, since anonymous users do not have access to the function.
- Prevent this user from editing their own talk page while blocked, if checked, will prevent the blocked user from editing their own user 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 cases of continued abuse of their user talk page, or when the user has engaged in serious threats, accusations or outing which needs to be prevented from reoccurring. The protection policy has further details in cases where other users[4] are repeatedly causing disruption to the user talk pages of blocked users.
- Prevent logged-in users from editing from this IP address will disallow all non-exempt user accounts from editing from the IP address or range 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.
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 (anon. only, 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.
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. Bots should be
softblocked (autoblock disabled) to ensure the autoblock doesn't affect other unrelated bots sharing the same IP. If only a single task is malfunctioning and the bot supports disabling individual tasks, it is preferable to disable the single malfunctioning task so that other bot tasks can continue running.
Bots that are unapproved, or usernames that violate the
username policy due to a resemblance to a bot, are immediately and indefinitely blocked if they violate the
bot policy, most commonly by editing outside the operator's or their own
userspace.
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.
