UK Transport:Blocking Policy

Blocking is the method by which administrators may technically prevent users from editing UK Transport. Blocks are used to prevent damage or disruption to Wikipedia, not to punish users.^[1]

Any user may request a block at the Admins User talkpages as the 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 themselves.

If you wish to contest a block, see UK Transport:Appealing a block for further instructions. Except in cases of unambiguous error, administrators should not undo other administrators' blocks without prior discussion; see below.

Purpose and goal[]

All blocks ultimately exist to protect the project from harm, and reduce likely future problems. When lesser measures are inadequate, or problematic conduct persists, appropriate use of a block can help achieve this in four important ways:

Preventing imminent or continuing damage and disruption to Wikipedia.
Deterring the continuation of disruptive behavior by making it more difficult to edit.
Encouraging a rapid understanding that the present behavior cannot continue and will not be tolerated.
Encouraging a more productive, congenial editing style within community norms.

Important note – Blocks are intended to reduce the likelihood of future problems, by either removing, or encouraging change in, a source of disruption. They are not intended for use in retaliation, as punishment, or where there is no current conduct issue which is of concern.

For the purposes of protection and encouragement, blocks may escalate in duration to protect the UK Transport Wiki while allowing for the cessation of disruptive editing and the return to respected editing.

When blocking may be used[]

The following are the most common situations when blocking may be used. This is not an exhaustive list; blocking may be used in other situations, particularly situations addressed by more specific policies dealing with particular issues.

Even though this is not an exhaustive list, if a situation is not listed below, then a block is more likely to be controversial than otherwise. A rule of thumb is when in doubt, do not block; instead, consult other administrators for advice. After placing a block that may be controversial, it is a good idea to make a note of the block at the Admins User talkpages for sanity checking.

Enforcing bans[]

Template:AnchorTemplate:AnchorTemplate:Details

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 implemented as a technical measure to enforce a ban. Such blocks are based around the particulars of the ban in question. Bans which revoke editing privileges 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 which the ban itself applies.

Evasion of blocks[]

Template:Policy shortcut 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 behaviour while evading the block. User accounts or IP addresses used to evade a block may also be blocked.

Recording in the block log after username change[]

Editors may cite the right to vanish and rename themselves, asking that their previous username not be disclosed and asking that their user and talk pages be deleted by an administrator.

When blocking may not be used[]

Disputes[]

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 of interest involving pages or subject areas with which they are involved.

An exception is made when dealing with unsourced or poorly sourced material. Administrators may enforce the removal of such material with page protection and blocks, even if they have been editing the article themselves.

Cool-down blocks[]

Template:Policy shortcut Brief blocks for the sole purpose of "cooling down" an angry user should not be used, as they inevitably serve to inflame the situation.

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. Bureaucrats occasionally make an exception to provide a link to the prior block log of a user who has undergone a username change.

Very brief blocks may be used in order to record, for example, an apology or acknowledgment of mistake in the block log in the event of a wrongful or accidental block, unless the original block has not yet expired (in which case the message may be recorded in the unblocking reason).

Unblocking[]

Administrators should not unblock users blocked in good faith by other administrators without first attempting to contact the blocking administrator and discuss the matter with them. It may not necessarily be obvious what the problem necessitating blocking was, and it is a matter of courtesy and common sense to consult the blocking administrator. If the blocking administrator is not available, or if the administrators cannot come to an agreement, then a discussion at the Admins User talkpages is recommended.

If a block is the result of an unambiguous error and not a judgment call (for example, if the blocking administrator obviously misspelled a username), and the blocking administrator is not available, then it is not necessary to discuss prior to unblocking. Where there is ambiguity, discuss the block before removing it.

Altering block options[]

Administrators may unblock a user in order to re-block them with different blocking options selected, where that is necessary (for example, if a block on a registered account is causing significant collateral effects to a shared IP address or a blocked user is abusing the Special:Emailuser function).

Education and warnings[]

Everyone was new once, and most of us made mistakes. That's why we welcome newcomers and are patient with them, and assume that most people who work on the project are trying to help it, not hurt it. We also ask that newcomers make an effort to learn about our policies and guidelines so that they can learn how to avoid making mistakes.

Before a block is imposed, efforts should be made to educate the user about our policies and guidelines, and to warn them when their behaviour conflicts with our policies and guidelines. A variety of template messages exist for convenience, although purpose-written messages are often preferable.

Warning is not a prerequisite for blocking (particularly with respect to blocks for protection) but administrators should generally ensure that users are aware of policies, and give them reasonable opportunity to adjust their behaviour accordingly, before blocking. Users who have been made aware of a policy and have had such an opportunity, and accounts whose main or only use is forbidden activity (sock-puppetry, obvious vandalism, personal attacks, and so on) may not require further warning.

Implementing blocks[]

Technical instructions on how to block and unblock, and information on the blocking interface, is available at Help:Block and unblock. The following is advice specifically related to blocking and unblocking on Wikipedia.

IP address blocks[]

Main article: Wikipedia:Blocking IP addresses

In addition to the advice below, there are special considerations to take into account when blocking IP addresses. IP address blocks can affect many users, and IPs 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.

If you propose to block a significant IP range, especially for a significant time, consider asking a user with checkuser access to check for collateral blocks - that is, for the presence of other users who may be unintentionally affected by the range block.

See the above links for more.

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 behaviour typically result in 24 hours blocks, longer for successive violations;
accounts used primarily for disruption are blocked indefinitely;
protective blocks typically last as long as protection is necessary, often indefinitely.

Indefinite blocks[]

Template:Policy shortcut An indefinite block is a block that does not have a 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.

If not one administrator will lift the block, the blocked user is effectively considered to have been banned by the community. In less extreme cases, however, the more usual desired outcome is a commitment to observe Wikipedia's policies and – if unblocked – to refrain from the problematic conduct in future.

Setting block options[]

Template:Details

There are several options available to modify the effect of blocks, which should be used in certain circumstances.

autoblock should typically be disabled when blocking unapproved or malfunctioning bots (so as not to block the bot's operator), though it should be enabled when blocking malicious bots.
prevent account creation should typically be disabled when blocking accounts with inappropriate names (to allow the user to create an account with an appropriate name), though it should be enabled when blocking malicious names (for example, clear attacks on other users).
block e-mail will disable the user from accessing Special:Emailuser for the duration of the block. This option should not be used by default when blocking an account, but rather it should only be used in cases of abuse of the "email this user" feature. 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-en-l mailing list) through which he can discuss the block.

A "softblock" is a block with autoblock disabled, account creation not disabled, and blocking only anonymous users enabled. The effect is to block anonymous users but allow registered users to continue editing. Softblocks are commonly used when blocking shared IP addresses.

Reasons and notification[]

Administrators must supply a clear and specific block reason which 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 also notify users when blocking them by leaving a message on their user talk page unless they have a good reason not to. It is often easier to explain the reason for a block at the time than it is to explain a block well after the fact.

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 Wikipedia:Template messages/User talk namespace.

Confidential evidence[]

If a user needs to be blocked based on information that cannot be made available to all administrators, that information is sent to the Arbitration Committee or a Checkuser for action. Those entities 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 which cannot be peer-reviewed.

An exception is made for administrators who hold Checkuser or Oversight privileges; such administrators may block users based on non-public information revealed through the checkuser tool, or edits of the blocked user deleted via oversight, 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.

Notes[]

↑ Blocks are not punitive in the sense that they aren't retribution. Blocks sometimes are used as a deterrent, to discourage whatever behavior led to the block and encourage a productive editing environment.

Template:New admin school