विकिपुस्तक:अवरोध नीति

Blocking is the technical method by which administrators can prevent users from editing Wikibooks.

Wikibookians can request a block in the reading room for administrative assistance. The request should supply credible evidence of the circumstances warranting a block. Administrators should investigate the situation themselves and may place a block if appropriate. Blocks can be appealed or reviewed; it is important that the blocking and reviewing administrators each communicate with and take care to inform the other.

Blocks should only be applied if all other possible attempts to resolve the issues have been considered.

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 Wikibooks from harm, and reduce likely future problems, 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. When lesser measures are inadequate, or problematic conduct persists, appropriate use of a block can help achieve this in four important ways:

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

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 Wikibooks, while allowing for the cessation of the disruptive editing.

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 reading room for administrative assistance for peer review.

Administrators should take special care when dealing with new users. Beginning editors are often unfamiliar with Wikibooks 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 Wikibooks:Please do not bite the newcomers.

Protection

A user can 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:

• persistently making personal attacks;
• making personal, professional or legal threats (including outside the Wikibooks 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 can 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 textbooks. A block for disruption may be necessary in response to:

• vandalism;
• gross incivility;
• harassment;
• spamming;
• edit warring;
• sock puppetry;
• persistently violating other policies or guidelines.

Disruption-only

Furthermore, some types of user accounts are considered disruptive and can 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.

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.

Recording in the block log after username change

Editors can cite the right to vanish and rename themselves, asking that their previous username not be disclosed and 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.

When blocking should not be used

Self-requested blocks

Sometimes people request that their account be blocked, for example to enforce a wikibreak. Typically, such requests are refused.

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 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 can 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 as the reason for the status alteration).

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 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 template message—see Template:Blocked.

Other important information

If there are any specific recommendations or circumstances that a reviewing administrator would need to know, or which 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, fully appreciated, or 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 a CheckUser 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 which cannot be peer-reviewed.

An exception is made for administrators who hold CheckUser privileges; such administrators may block users based on non-public information revealed through the CheckUser tool as such an administrative action is generally viewed to be made in the user's capacity as a CheckUser, although the action itself is an administrative one.

Contact details: individual CheckUsers are listed on the relevant page.

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, their 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, or there was a clear mistake.

Block reviews

As part of an unblock request, uninvolved administrators can discuss a block, and the blocking administrator is often asked to participate and provide further information. (see Information provided by blocking administrator.)

Except in cases of unambiguous error, administrators must avoid unblocking users without first attempting to contact the blocking administrator and discuss the matter with them. If the blocking administrator is not available, or if the administrators cannot come to an agreement, then a discussion at the general reading room is recommended. The blocking administrator should also wish to note as part of the block notice that there are specific circumstances by which the reviewing administrator should not unblock.

Administrators reviewing a block should consider that some historical context may not be immediately obvious. Cases involving sockpuppets, long-term disruption, harassment, or privacy concerns are particularly difficult to judge. At times such issues have led to contentious unblocks.

Altering block options

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

Temporary circumstances blocks

Some types of blocks are used in response to particular temporary circumstances, and should be undone once the circumstance no longer applies:

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

Temporary circumstances unblocks

As a form of discretionary sanction, a user can be temporarily and conditionally unblocked in order to respond to a discussion regarding the circumstances of their block. Such temporary and conditional unblocks are made on the understanding that edits (besides their user talk page) of other page(s) must be explicitly specified by the unblocking admin. The user is effectively prohibited from editing any other pages. Breaching this ban will be sanctioned appropriately. When the discussion concludes, the block should be removed unless there is a consensus to keep the block.

Checkuser blocks

CheckUsers are privy to confidential system logs not accessible by the public or administrators due to the Wikimedia Foundation's privacy policy, and therefore must be consulted before a block marked as a "checkuser block" can be removed.

Education and warnings

Everyone makes mistakes. That's why when we welcome newcomers, we are patient with them, and assume that most people work to benefit the project, not hurt it. We ask that newcomers make an effort to learn about our policies and guidelines so that they avoid making mistakes.

Before a block, efforts should be made to educate the user about our policies and guidelines, and to warn them when their behavior 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 behavior 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 attack, and so on) do not require further warning.

An administrator should consider that a user may not immediately notice the warning on his talk page until he has navigated to a new Wikibooks page. This may include the saving of a newly and also inappropriately edited page. Edits made immediately following a warning should be rolled back so as to allow time for the warning to be seen, before taking further action.

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

IP address blocks

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.

Collateral damage

When an IP range is blocked, other users who also use that range may be unintentionally affected. 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 damage on that range—that is, for the presence of other users who may be unintentionally affected by the range block. They should be given IP block exemption so they will not be affected.

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 long enough to discourage repeat incidents and should be made longer for successive violations;
• accounts used primarily for disruption can be blocked indefinitely without warning;
• protective blocks typically last as long as protection is necessary, often indefinitely.

Indefinite blocks

An indefinite block does not have a fixed duration. They should be applied when there is significant disruption or major breaches of policy to prevent further issues until the matter can be resolved by discussion. It is possible in some cases, to achieve the more usual desired outcome, in a commitment to observe Wikibooks policies and—if unblocked—to refrain from the problematic conduct in future.

Until an administrator lifts the block, the blocked user is effectively considered to have been banned by the community.

Setting block options

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

Anon-only

When blocking IPs, this setting should be checked unless necessary to stop disruption (ie the intent of the IP or range block is to block logged-in users). (Abbreviated AO)

Autoblock

Must be disabled when blocking unapproved or malfunctioning bots (so as not to block the bot's operator, or other bots operating from the same IP address), though it should be enabled when blocking malicious bots. (Abbreviated AB)

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 bad-faith names (for example, clear attacks on other users) or vandalism-only accounts. (Abbreviated ACB)

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, or where such abuse is likely.

Allow this user to edit own talk page while blocked

If unchecked will prevent the blocked user from editing their own talk page, including requesting unblock. This option should not be unchecked by default; editing of the user's talk page should only be disabled in the case of continued abuse of the talk page, or where such abuse is likely.

Partial block

Users should normally be blocked sitewide (that is, from editing any page), though if the circumstances justify (for instance, edit-warring on a particular page), admins may block the user from editing that particular (set of) page(s). Alternatively, admins can leave editing functionality intact but ban users from creating accounts or sending email.

The most common types of blocks when blocking an IP are commonly known as a soft block (autoblock disabled, account creation not disabled, blocking only anonymous users enabled) which block anonymous users but allow editing by registered users when logged in (commonly used when blocking shared IP addresses); soft block with account creation disabled (same but account creation disabled) used in most cases where vandalism or disruption is occurring via registered accounts; and hard block, which disables all editing whether logged in or not, other than administrators and other IP-block exempt users—used when the level of vandalism or disruption via creation of "throwaway" accounts is such that editing from the IP is to be prevented other than after individual checking of requests.