Error: This page is not currently protected. Please
request protection
or remove the protection template.
Shortcut
:
COM:BP
Os
administradores
tem a capacidade de
bloquear
usuarios quando apropriado. Um usuario bloqueado esta restringido de editar ou carregar arquivos, alem de outras coisas. De modo geral, bloqueios sao o ultimo recurso para comportamentos que tem potencial para danificar o Commons ou perturbar a atmosfera de camaradagem. Dessa maneira, o bloqueio e uma medida
preventiva
e nao uma
punitiva
; bloqueios para "se acalmar" nao sao tolerados.
Uso
Os bloqueios podem ser aplicados por diversas razoes. As mais comuns sao as detalhadas abaixo:
- Vandalismo
. Edicoes ou carregamentos destrutivos podem resultar num bloqueio. Por exemplo:
- Insercao de vulgaridades.
- Insercao deliberada de informacao falsa (como fontes falsas de imagens).
- Guerra de edicoes numa pagina de usuario alheia.
- Violacoes de
copyright
. O carregamento continuado de media sem uma licenca adequada e base para o bloqueio de uma conta. Devem ser dadas explicacoes e avisos claros sobre as politicas do Commons antes e depois de se efectuar um bloqueio a uma conta por problemas de licenciamento.
- Copyright violations
. Repeated uploading of inappropriately licensed media is grounds for blocking an account. Clear explanations and warnings about Commons policy should be engaged in before and after blocking a user for license problems.
- Harassment
. Accounts and IP addresses which are used primarily to create a hostile environment for another user may be blocked. Good faith disputes between users, however, should be brought to
Commons:Village pump
for outside input. Tracking a user's contributions for policy violations is not harassment.
- Unauthorized or non-responsive
bot
accounts
. Bot accounts not authorized by the Commons community are not allowed to operate on Wikimedia Commons, and questionable bot-like editing that cannot be explained by the user should be blocked until discussion takes place. Bot proposals can be discussed at
Commons:Robos
or
Commons:Village pump
. Bots may not be operated on Commons without prior approval (which can be sought at
Commons:Bots/Requests
).
- Approved bot accounts that are temporarily malfunctioning
. This is to prevent additional damage until the bot-owner can address the problem.
- Inappropriate usernames
.
- 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 behaviour while evading the block. User accounts or IP addresses used to evade a block may and should also be blocked.
- Abusing multiple accounts
to mislead, deceive, disrupt, distort consensus or to evade blocks or other sanctions. Secondary accounts are typically blocked indefinitely. The primary account may or may not be subject to new or extended blocks depending on the circumstances.
- Open or anonymizing proxies
are typically blocked upon
detection
in accordance with
Wikimedia-wide policy
. The normal duration of such blocks is one year.
Instrucoes para administradores
Antes de bloquear
- For blocks based on disruptive behaviour, such as vandalism, repeated copyright violations and manual promotional activities, ensure that the user has been appropriately
warned,
preferably using a
block warning template
. No warning is necessary when blocking open proxies and users with inappropriate usernames. Accounts and IP addresses used solely for severely disruptive purposes such as automated spamming, serious vandalism or harassment may also be blocked without prior warning.
- Controversial blocks
may be discussed at the
blocks and protections noticeboard
, preferably before they are applied if at all possible. As a rule of thumb, when in doubt, do not block.
- Range blocks
are especially powerful tools, and discussion of these is particularly encouraged. Range blocks with a duration longer than 24 hours should be discussed with a
checkuser
to assess the likely impact.
Quando bloquear
- Blocks can be applied to
registered users, IP addresses or address ranges.
- As blocks are preventative rather than punitive, use a block
duration
that is proportional to the time likely needed for the user to familiarize themselves with relevant policies and adjust their behaviour. Also consider the user's past behaviour and the severity of the disruption. When blocking IP addresses, keep in mind that innocent third parties sharing the same addresses may be affected.
- Provide a
reason
for the block. The rationale should preferably use links to relevant policies to help the blocked user understand why they have been blocked. Where appropriate, diffs or
permanent links
documenting the reason for the block are also helpful.
- Account creation
should be prevented in most cases, but may be allowed when blocking an inappropriate user name to allow creation of a different name.
- Autoblocking
of IP addresses used by the blocked user should typically be enabled for users who were blocked for disruptive behavior. It should be disabled in most other cases, like blocking malfunctioning bots and usernames that don't follow the
username policy
.
- Only prevent the blocked user from using their
talk page
or sending
e-mail
if they are likely to abuse these privileges.
Depois de bloquear
- Notify
the blocked user, preferably using a
user block template
.
- Watch
the blocked user's user talk page and ensure that
requests for unblock
are attended to.
- Blocks based on disruptive behaviour should be
lifted
if there is reason to believe that the disruptive behaviour will not resume.
- Controversial blocks
may also be discussed at the
blocks and protections noticeboard
after they have been applied. To avoid
wheel warring
, another administrator should lift a block only if there is consensus to do so, even if there is no clear consensus in favor of the original block.
Checkusers
may need to block an editor on the basis of technical
checkuser
evidence, due to disruption caused by abuse of multiple accounts or IP addresses. These blocks are marked as a
{{Checkuserblock}}
in the block summary and must not be reversed by non-checkusers without consulting a checkuser.
As checkuser data cannot be shared publicly and a checkuser block may involve other pertinent non-public information, an unblock appeal for a
{{Checkuserblock}}
must only be reviewed by a checkuser. A reversal of a check user block by an administrator without consulting a checkuser may result in the removal of permissions.
In exceptional cases, there may be a need to block an editor on the basis of oversighted information that cannot be shared publicly. In such a case, the available
oversighters
may jointly act on the basis of group consensus. If there are insufficient oversighters available or if additional input is required they may consult the
Wikimedia stewards
.
Except in an emergency, non-oversight administrators should not block on the basis of information known to them that has since been oversighted. An administrator believing that such a block is required should contact one of the oversighters privately or email
oversight-commons
lists.wikimedia.org
.
Any block made under this section should be reported by the oversighters to the community at the earliest opportunity, with as much background material as can reasonably be provided.
An editor who is blocked under this section may not be unblocked without the approval of the oversighters. An editor who wishes to have their oversight block reviewed should approach the oversighters privately, who will consider the request as a group. Public ‘appeals’ on the talk page of the blocked editor should not be used, and any that are posted may be removed.
Blocked users are
informed
that they may
request unblocking.
They may do this by adding
{{
unblock
|
reason for the request
}}
to their
own user talk page
.
Alternatively, they may request unblocking with an appropriate reason via
e-mail
to the blocking administrator or another administrator.
An
appropriate reason
will almost always include one of the following:
- An
acknowledgement
that the block was appropriate and a
credible promise
that the behaviour that led to the block will not be repeated
- An explanation of why the block is
not appropriate
based on this and other relevant policies and guidelines or is
likely to be a mistake or an unintended side effect
An unblock request may be
granted
or
declined
.
Before granting a request to lift a block placed by another administrator, the reviewing administrator should
consult with the blocking administrator,
except in obvious, uncontroversial cases.
Requests made on user talk pages
may only be declined by an
uninvolved administrator.
Unblock requests for blocks marked with
{{
checkuserblock
}}
will be reviewed by a
checkuser.
Making repeated unblocking requests without appropriate reasons may be considered abusive. As noted above, users who have abused or are likely to abuse the ability to edit their own user talk page and/or send e-mail in this or any other way may have either or both of these privileges revoked, which also prevents these privileges from being used for unblocking requests.
Ver tambem