User:Novem Linguae/Essays/Nuances of blocking

My notes on blocking. Rough and unfinished.

Blocking

Suggested gadget: WP:TWINKLE

Blocking IPs

• When blocking IPv6 addresses, always block the /64.
• IP block length
  • Never block IPs indefinitely
  • The default block lengths in Twinkle look like a pretty good guide.
    • For example, IP vandalism blocks in Twinkle default to 31 hours.
  • IP socks: the block length should take into account how long they've been using the account.
    • A sock with only one day of edit history can be blocked for a week.
    • 6 months of editing on one IP may justify blocking for a year.
    • In extreme cases, some very static sock IPs have been blocked for 10 years in the past.
  • Schools: similar to socks above, if the IP is stable (if the IP has been that school for years) should be taken into account
    • Schools can generate a lot of poor edits. If the IP is stable, a block of years may be justified.
  • Hosting infrastructure:
    • Default 2 year hard block.
• Don't WP:HARDBLOCK IPs unless specifically indicated in policy. Default to soft blocks.
• The type of IP should be taken into account. Blocking a mobile carrier IPv4 is much more likely to have collateral damage than blocking an internet service provider IPv6.

Blocking users

• Unlike IPs, you can indef (set an indefinite block) for user accounts.
  • Common use case: vandalism-only accounts.
• Indefinite does not mean infinite. All blocks are appealable. Indefinite means there is a very big issue that admins needs to be convinced will be corrected before an unblock will be considered.

Blocking experienced users

• In my opinion, unilateral blocks of experienced users are one of the most dramatic things you can do on this website. Unless you are a blocking expert, consider taking it to WP:ANI instead.

Unblocking

Suggested user script: User:Enterprisey/unblock-review

• While allowed by the wheel warring policy and not explicitly disallowed in WP:RAAA, you should almost never undo another admin's block without getting their permission.
  • There is extreme potential for drama here if you do a "bad unblock". This is a common behavior of legacy admins, and this also contributes to the WP:UNBLOCKABLE problem.
• Checkuser, oversight, and arbcom blocks are not allowed to be undone by anyone except members of those bodies, respectively.
• On a third failed unblock request, it is customary to revoke talk page access.
• Users with revoked talk page access who wish to appeal a block will be directed to WP:UTRS, a Toolforge-hosted, off-site tool for processing unblock requests.
• Unblock requests via the {{Unblock}} template
  • Not sure if there's a rule against it, but it's common practice to let other admins review these.
  • There are admins that specialize in unblock requests/UTRS and patrol those queues.
  • The default decline template is {{Decline reason here}}. This is a pretty good summary of what a good unblock request must include:

I am declining your unblock request because it does not address the reason for your block, or because it is inadequate for other reasons. To be unblocked, you must convince the reviewing administrator(s) that

• the block is not necessary to prevent damage or disruption to Wikipedia, or
• the block is no longer necessary because you
  1. understand what you have been blocked for,
  2. will not continue to cause damage or disruption, and
  3. will make useful contributions instead.

Please read the guide to appealing blocks for more information.