Test Wiki:Blocking Policy

Blocking Policy
Blocking is the method by which administrators may technically prevent users from editing. Blocks are used to prevent damage or disruption to the site, not to punish users. Blocks sometimes are used as a deterrent, to discourage whatever behavior led to the block and encourage a productive editing environment.

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

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 block that may be controversial, it is a good idea to make a note of the block at the administrators noticeboard for peer review.

Administrators should take special care when dealing with new users. Beginning editors are often unfamiliar with Test Wiki 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.

Protection
A user may be blocked when necessary to protect the rights, property or safety of the administrators, its users or the public. A block for protection may be necessary in response to:


 * persistently making personal attacks;
 * making personal, professional or legal threats (including outside the Wikipedia site);
 * performing actions that place users in danger;
 * disclosing personal information (whether or not the information is accurate);
 * persistently violating copyrights;
 * persistently posting unreferenced or potentially defamatory information about living persons;
 * accounts that appear to have been compromised, as an emergency measure.

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. A block for disruption may be necessary in response to:


 * persistent vandalism;
 * persistent gross incivility;
 * persistent harassment;
 * persistent spamming;
 * edit warring, in particular breaches of the three-revert rule;
 * evading blocks by creating new accounts;
 * persistently violating other policies or guidelines.

Disruption-only
Furthermore, 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;
 * 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.

Enforcing bans
A Staff ban is a formal revocation of editing privileges on all or part of Test Wiki. 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 Test Wiki—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
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 may also be blocked. [edit] 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. If such editors have been blocked previously then 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 add 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 "right to vanish" 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.

Self-requested blocks
Sometimes people request that their account be blocked, for example to enforce a self requested break. Typically, such requests are refused.

Conflicts of interest
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.

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. 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).

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 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 convenient template message.