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: