K6ka's Wiki:Blocking policy

Administrators on K6ka's Wiki have the technical ability to block users from editing. Blocks can be applied to accounts, IP addresses, and to ranges of IP addresses. and can be configured to expire at a specified time, or to expire only when removed by an administrator. Blocked users may continue to have access to K6ka's Wiki, but they will not be able to edit any pages, except usually their user talk page.

Purpose and goals
Blocks should be used to protect the project and its users from harm, and to reduce the likelihood of further problems. Blocks may escalate in duration if problems recur, but should never be used in a retributory manner.

Blocking can be a sensitive topic, and if issued improperly, blocks may actually worsen a situation rather than aid in resolving it. As such, administrators must exercise proper judgement and be familiar with the circumstances before intervening with a block.

Blocks can usually be appealed, and should also be decided in light of prevention and deterrence. If it is believed that the block is no longer necessary to prevent harm and the blocked user has learned from their mistakes, the block can be ended early. On the other hand, a user who has continued or escalated inappropriate conduct during or after previous blocks may find that their unblock requests receive more scrutiny and are much more likely to be declined.

When a situation has dried up and the risk of disruption has ended, reopening it via blocking is usually inappropriate. Processes exist for the resolution of disputes that should be used before a block is considered.

Common rationales for blocks
This list is not intended to be an exhaustive list of when blocks can be used. However, it should be noted that when there is doubt, blocks should not be used. Instead, discussion and consensus should be used to reach a conclusion.

Protection
A block may be necessary to protect the wiki and/or its users. A user may be blocked to prevent and protect against:


 * Persistent personal attacks;
 * Personal, professional, or legal threats;
 * Actions that place users in danger;
 * Disclosure of others' personal information, regardless of its accuracy;
 * Persistent copyright violations;
 * An account that appears to have been compromised (Taken over by an unauthorized user).

Disruption
A user may be blocked when their actions cause serious harm or disruption to the collaborative atmosphere of the wiki. This may be done in response to:


 * Vandalism;
 * Gross incivility and/or harassment;
 * Spamming;
 * Edit warring;
 * Deliberately violating or showing no regard for policies and guidelines;
 * Abusing multiple accounts;
 * Attempting to coerce users, either on- or off-wiki.

Accounts may also be blocked if they are deemed to be:


 * Used solely for the purpose of vandalism or spam;
 * Public accounts (Where the password is publicly available or shared with a large group);
 * Accounts with blatantly inappropriate usernames;
 * Bots operating without approval or outside their approval.

Open or anonymous proxies
Open or anonymizing proxies may be blocked on sight. This is due to the fact that open proxies are frequently used by vandals to cause disruption, and are blocked to prevent abuse.

Enforcement
If an editing restriction has been placed on a user and the user has violated the restriction, he or she may be blocked in order to enforce the restriction. Blocks should generally not be used if the user is not violating the restriction(s) placed on them, as this will revoke editing access to all of K6ka's Wiki; restrictions are generally narrower in scope and permit editing of other areas of the site.

Evasion of blocks
In most cases, users are expected to abide by any blocks imposed on them and must not attempt to evade or get around a block. Administrators may reset the block of a user who intentionally evades a block, and may extend the block if the user continues to engage in blockable behaviour. Any IP addresses and accounts used to evade the block should also be blocked to prevent disruption.

Reverting edits made by blocked users
Any user may revert an edit made by a blocked user in violation of their block; this is an exemption to the three revert rule, and can be done without providing a reason. However, be prepared to explain the reverts when asked. Note that common sense should be used before reverting; obviously helpful or minor changes, such as reverting vandalism and fixing typos, should be allowed to stand. In ambiguous cases, however, it is okay to revert. Comments in closed discussions made by blocked editors should generally not be reverted or removed.

If a blocked editor creates a page in violation of the block, that page is eligible for speedy deletion under G5; editors can use the db-g5 template on their pages. If other editors have contributed substantially to said pages, it is courteous to inform them about the situation.

Edits made before or after blocks were placed are not eligible for free reverting; the user must be violating a block at the time of the edit in order for this edit warring exemption to be valid.

Edits made on behalf of blocked users
Users are not permitted to make edits at the direction of a blocked editor (sometimes known as proxy editing) unless they can show that the changes are productive and constructive and that they have independent reasons for making such edits. Failure to do so may be considered a form of meatpuppetry, and users that engage in such acts may be blocked.

Conflicts and involvement
Administrators should not block users with whom they are engaged in a conflict dispute with, as doing so will grant the administrator an unfair advantage over the situation. Instead, the administrator should defer to other administrators for solutions if administrative action is needed. However, it is acceptable for administrators to block users that engage in clear-cut vandalism in the administrator's userspace or on any pages the administrator has created or worked on.

Cool-down blocks
Blocks should not be used to "cool down" an angry user, as they typically have the opposite effect. An angry user that is also engaged in disruptive editing, however, can be blocked to prevent further disruption.

Recording in the block log
Blocks should not be used to record warnings or other negative events in a block log, as doing so is humiliating and punitive. This is often done by imposing very short blocks for the sole purpose of leaving notes for other users and administrators perusing the block log in later disputes.

These short blocks, however, can be used to record an apology or acknowledgement of mistake in the block log, if the original block has already expired. If the block has not expired, the apology should be stated in the unblock reason.

Requesting blocks
At this time, blocks may be requested at the administrators' noticeboard. Users requesting blocks should supply credible and sufficient evidence of the circumstances warranting a block. Administrators are never required to place a block and are free to investigate the situation themselves.

Off-wiki block requests
Unless the situation is urgent and obvious where no other administrator would disagree that a block is necessary, block discussions should be held on-wiki. Consensus for blocks should never be formed off-wiki, such as on IRC or a social media website/forum/group, since it excludes editors who do not use these platforms from the discussion. Depending on the nature of the platform used, it may also be difficult or even impossible to obtain a record of the discussion; IRC logs are notoriously easy to fake. Administrators who are asked to perform a block on IRC or another platform should investigate the situation first, and if it is not urgent (e.g. obvious cases of vandalism) they should refer the requester to the appropriate on-wiki venue in question.

Self-requested blocks
Sometimes, people may request that their account(s) be blocked, either temporarily or indefinitely, usually to enforce a Wikibreak or a retirement. Administrators are not required to accept or even to respond to such requests. Administrators, however, should not come under scrutiny for making such blocks, and it is the requesting user's responsibility to request an unblock should they wish for a self-requested block to end.

Please note that, due to the nature of this kind of block, self-requested blocks should be made publicly on-wiki so that a record of the request can be kept. This is done to ensure that innocent users are not blocked based on an administrator merely claiming that they had requested a self-requested block through a private means of communication, such as private messaging on IRC or another social media platform.

Before blocking
Blocking is a drastic action as it revokes a user's ability to edit the wiki, and K6ka's Wiki prides itself in being editable by anyone. Blocks should almost never be used as a first resort; if a user engages in behaviour that conflicts with the policies and guidelines on K6ka's Wiki, efforts should be made to inform the user about this. Welcome new users, do not bite them, and assume that they're here to help out. In general, blocks should only be used after sufficient attempts at communication have been tried, and it is evident that the user is either editing in bad faith or if the project will be placed at greater harm if a block is not applied.

Do note that, while warnings are a prerequisite in most cases before blocking, it is by no means a hard-line requirement; administrators should use their judgement and determine whether or not a warning would be useful before blocking. Users acting in bad faith whose only or main activities are doing things that are clearly against the rules (e.g. sockpuppetry) may be blocked immediately without warning.

After blocking
Administrators should explain the reasons behind their blocks. When an administrator blocks a user, they are given the opportunity to supply a block reason. This reason should be kept clear and concise and avoid the use of jargon so that the blocked user may understand it. Administrators should also leave a message on the blocked user's talk page providing more details about the block; they may use one of several templated messages to do this.

If there is any information that other administrators may need to be aware of, the blocking administrator should consider including this information in the block notice. This is useful in cases where information or evidence may not be immediately obvious, or any suggested conditions for an unblock.