User:Asilvering/Unblocks guide

Thank you so much for your interest in unblocks. I'll be honest: it sucks here, and we need all the help we can possibly get. Adminstats only lists successful block appeals, not unsuccessful ones, so it's hard to get a good picture of who's doing what, but unless things have gotten dramatically better by the time you read this, it's often just two or maybe three admins handling the bulk of the work, and only a dozen or so more really involved at all. This isn't great anywhere, but it's especially bad at unblocks, where bad admin actions can easily be compounded and AGF-meters can easily run dry.

I ended up working here in late 2024 because the backlog was horrific and it made me feel guilty every time I looked at {{Admin dashboard}}. Mostly I've been making it up as I went. This is a guide and FAQ so people don't have to do that. It's not the One True Way to handle unblocks. But it's how I handle them, and if I thought there was a better way, I'd be doing that instead.

Basics:

• Go read WP:ADMINGUIDE first. This guide assumes you know how to push the admin buttons.
• Install User:Novem Linguae/Scripts/UnblockReview.js, unless you want to do everything by hand. Note that this script is only for interacting with the unblock template and does not automatically unblock editors when you accept the appeal.
• You will also want to install the other recommended scripts, unless you already have a script that performs these functions. But I really recommend these specific ones.

Recommended scripts

• User:Novem Linguae/Scripts/UnblockReview.js - doesn't work 100% of the time, but far less buggy than previous unblocks scripts
• User:Daniel Quinlan/Scripts/Unfiltered.js - shows filter hits in contribs screen and in page histories
• User:Daniel Quinlan/Scripts/UserHighlighter.js - highly customizable user highlighter script
• User:Daniel Quinlan/Scripts/RangeHelper.js - essential for dealing with blocks on IP ranges and IPv6 IPs
• User:Daniel Quinlan/Scripts/Catatonic.js - helps you empty Category:Requests for unblock awaiting response from the blocked user at a glance. Once you've installed it, navigate to that category, click "page information" (in the tools menu), and then click "enable activity tags" (next to the page ID). You should now see a number next to each entry in the category; that's how many days it's been since the page was edited. Anything at 14 or higher can be declined as stale.

Basic workflow

1. Go to CAT:RFU. (Or this table or this table if you prefer.) Pick a blocked editor.
2. Find the most recent appeal.

   If they have made several, decline the surplus ones. You may need to do this by hand, because multiple requests can confuse UnblockReview.js. See {{Unblock}} and {{Unblock reviewed}}.

   If they have put it in a weird place on their talk page, you may find it helpful to move it and put a proper heading on top.

3. Read the appeal.
4. Look at the block. Is the appeal a reasonable response to the block?

   If it is completely useless and you have UnblockReview.js installed, simply hit "Decline", which will subst {{Decline reason here}} and close the review. Return to step 1.

   If it is abusive and the editor needs to be immediately evicted from the premises, explain why, hit "Decline", and edit the block to revoke TPA. Drop a {{uw-talkrevoked}} on their talk page. Contact WP:OS if required. Return to step 1.

   If this is a child giving you way too much personal info, redact it, leave them a neutral message about needing to appeal through WP:UTRS, revoke TPA, and contact WP:OS. Heavy-handed? Maybe. But safe. Return to step 1.

   If you see another admin has already been by and asked the editor a question, and you too would want to see that question answered before considering an unblock, edit the template to add |idletimestamp={{subst:CURRENTTIMESTAMP}}. This will move the block from the normal queue to Category:Requests for unblock awaiting response from the blocked user, where it will stay until an edit (any edit, by anyone) is made to the talk page. Return to step 1.

5. Investigate further. This may take a while.

   If you don't finish investigating, future admins will appreciate if you leave some notes or breadcrumbs. Keep WP:BEANS in mind.

6. [Optional] Talk to the editor and ask any necessary questions.

   Tip: if you want to figure out what the blocked editor thinks or understands, don't ask leading questions, or questions that can be answered with a yes/no. "Will you follow the guidelines?" will get a 'yes' whether that's true or not. "Please explain how you will follow the guidelines" will probably get you further.

7. [Often] Ask for input from the blocking administrator.

   In the very obvious, simple cases (silly vandalism, {{uw-spamublock}}, etc), where the blocking admin probably spent about two seconds thinking about the block in the first place, everything is resolved to your satisfaction, and drawing things out further would simply be a waste of everyone's time, you can skip this step. Give the blocking admin a courtesy ping when you accept the unblock. If you have even the slightest bit of doubt about whether this is an "obvious, simple case", do not skip this step.

   You have to consider the blocking admin's input, but you don't have to agree with it. Except in the "un-unblockables" cases below, the blocking admin does not have a veto - you do. Think very, very carefully before unblocking an editor over the objections of the blocking admin. If it's the right thing to do, you need to do it. Are you sure it's the right thing to do?

   The blocking admin cannot insist on any specific conditions. That decision lies with you too.

   Most of the time, the blocking admin will tell you "I trust your judgement." Don't prove them wrong.

8. Accept or decline the appeal. Give a reason and clearly state any conditions.

   If you declined, but you think the blocked editor has a chance in the future, tell them so, and give them some advice.

   If you accepted, you must now manually unblock the editor. It's a good idea to leave a diff or permalink in the block log. If it was a conditional unblock, you must state the conditions in the block log. You may also optionally list them at WP:EDR.

9. You're done! Well, not really. Return to step 1.

Who can unblock

As a general rule of thumb, a block can be lifted by the same community mechanism which imposed it:

1. Most blocks implemented by a single admin can be lifted by a single admin, though consulting the blocking admin is recommended;

   An arbitration enforcement block set more than a year ago by a single administrator can be treated as a regular block;

2. A block implemented as a result of community consensus (eg, at WP:ANI or WP:AN) can only be lifted after community consensus at WP:AN;
3. A checkuser or WP:COIVRT block can only be lifted with the consent of a checkuser/WP:COIVRT admin;
4. An ArbCom block can only be lifted by members of ArbCom.

Admins who unilaterally lift community-consensus blocks will probably find themselves at WP:AARV in short order. Admins who unilaterally lift active WP:AE blocks, CU/COIVRT blocks, or arbcom blocks may be summarily desysopped.

Your own blocks

• Don't decline an unblock request for a block you set. Ever. No exceptions. Someone else can handle it. If it's your AE block, you can decline to lift the block yourself, but then you have to take it to AE. (If you think it is vanishingly unlikely to succeed at AE, you're free to ask them if they're sure they don't want to try writing a better one.)
• Don't revoke TPA for unblocks-related reasons either. If it's warranted, someone else will come to the same conclusion.
• You can accept an unblock request, though.
  • I don't think there's a rule against this explicitly codified anywhere, but I'd strongly advise against conditional-unblocking someone you blocked. That would effectively be setting editing conditions unilaterally. Just don't. You can always suggest conditions to the unblocking admin, and they'll probably agree with them.

UTRS

Someday I will get frustrated or bored enough to make docs for this, but for now, the basics:

Green posts are admin-view-only, and you make one by typing in the comment box at the bottom of the appeal and pressing the green "submit" button. You can do this even after an appeal has closed.

Blue posts are communication from and with the blocked editor and can be seen by both of you. To make a blue post, you first need to press the green "Reserve" button, then scroll to the bottom, where you will now see a teal "Send a reply to the user" button. You can then choose to reply with custom text, or select a template from the list (click the template name to review the response). Before you hit "submit", make sure you've selected the correct option from the drop-down menu. If you want the blocked editor to respond, make sure you set it as "awaiting reply", otherwise other patrolling admins will keep opening up the case, seeing it's waiting on a reply, cursing you under their breath, etc. Remember that you've reserved the appeal - if you want other admins to be able to make blue comments, you'll have to hit the "release" button to send it back to the general pool. Other admins can always see the open appeals, and use green comments on them, but can't respond or action them if another admin has them reserved.

Do not press any of the red buttons at the top unless you want to immediately close the appeal without any comment. These buttons instantly apply the specified action and archive the appeal. Useful for when the "yamlafuck pooyo" guy shows up and you wish to be immediately rid of them. Otherwise, dangerous.

The yellow buttons, similarly, will disappear the appeal, but not without first asking you to type in a reason. Use "tool administrator" when an editor has exhausted the patience of all responding admins and you need a six-month vacation. Use "CheckUser" to punt the appeal to the CUs, but please try to solve the problem yourself first. (Chances are, no CU is needed.)

Accepting an appeal does not unblock the editor. You have to do this manually on-wiki.

Globally locked accounts

• Editors who are globally locked are unable to log in to their account, so they cannot respond on their talk page and the appeals need to be handled on WP:UTRS.
• Locks and blocks are fully independent of each other. That is, an account can be locked but not blocked, and your unblock will not lift a glock, nor is it prevented by one.
• Don't just give up and punt to the stewards. The stewards will want to know that you are planning to unblock/unban the editor before they lift the global lock.

Community consultation

Unblock requests are not a consensus process. A single administrator is expected to review the block and make a decision. If you see editors trying to "!vote" on an unblock, you can, and probably should, tell them to step off.

However, there are some unblocks that require community consultation:

• multiple admins are involved in the unblock discussion, and either cannot come to consensus or believe it ought to have broader input
• the editor has been caught by checkusers so many times they hit WP:3X and are de facto cbanned
• the editor was cbanned by community consensus (ie, the block was not a unilateral admin action, but exists to enforce the cban)

In these cases, you cannot unilaterally lift the block, though you can unilaterally decline the unblock request. Do steps 1-6 of the basic workflow as normal. Then, if you're satisfied that the editor can be unblocked - or, at least, satisfied that they ought to get a chance to make their pitch to the community - copy over the text of their unblock to a new WP:AN thread for community discussion and !voting. You can !vote in support if you like, or stay neutral. If editors ask questions of the blocked editor, the blocked editor will have to write answers on their talk page for you to ferry over.

As far as I can tell, there's no rule for how long these discussions have to stay open. I recommend at least 72 hours for the easy ones and a week for ones that look like there might be more reason for doubt.

A failed appeal to the community usually results in an embargo on further appeals for at least six months. Please consider this when you're deciding whether to take over an unblock/unban request that strikes you as insufficient. At some point, if the editor really insists, the best move may well be to say "your funeral" and carry over something you know will be rejected. But in general, you shouldn't be setting people up to fail.

[most editors suck at writing good cban appeals so here are some tips to elicit something better]

Un-unblockables

Unilaterally unblocking an editor in any one of the following situations is likely to lead to a summary desysop:

• Checkuser blocks
• Oversight blocks
• WP:COIVRT blocks
• AE blocks
• Arbcom blocks

The latter two are not your problem and you probably won't see them often, if at all. Decline the Arbcom block and tell the editor they need to email arbcom instead. For AE blocks, check the date and the reason: if it's more than a year ago and was a unilateral admin action, this is now for your purposes a regular block (absolutely do not skip the "consult the blocking admin" step). Otherwise, the blocking admin is supposed to be the first port of call, so if there's no evidence they've spoken to the blocking admin and no notes left on the block (eg, "appeal to AE"), procedurally decline, explain why, and call in the blocking admin. If they've already spoken to the blocking admin, but they're still using the unblock template for their appeal and that admin didn't take to to AE themselves, something has gone a bit weird, so be alert.

To take a block to WP:AE, simply open a new thread at that noticeboard as normal, copying over the text of the appeal and providing evidence that the blocking admin is aware that you're doing this. The AE admins may have questions for the blocked editor, the answers to which you'll have to ferry over from their talk page. You don't need to do anything else.

Do not unilaterally decline an AE unblock request in its first year unless you are the blocking admin. If the request sucks, you're well within your rights to (gently!) tell the blocked editor that it sucks and you don't think it will succeed. But if they insist, take it over. Let AE be the judge of whether the blocked editor is wasting their time.

Checkuser/COIVRT account blocks

• Non-CUs can be very helpful dealing with these, just like non-admins can be helpful dealing with regular unblock requests (see below). Don't be scared off by the summary desysop notice.
• Unlike other blocks, you must have CU input first before lifting these blocks. No exceptions. It does not matter if you think it's an obviously bad block. Get another CU to agree with you first, then lift it.
• Don't just bung a {{checkuser needed}} on it without doing anything to investigate. CUs are a) busy, b) grumpy, and c) unnecessary in most cases.
• Go read the section on sockpuppetry.
• [etc]

Checkuser IP blocks

• These are the ones marked with {{checkuser block}} and {{checkuserblock-wide}}. Not all blocks by CUs are CU blocks. If the block notice does not include the magic words "checkuser block", including IP blocks for spam, as a proxy, or for whatever other reason, it's a normal admin block and you can lift it without summary desysop. (However, it would be very stupid to do this without asking the blocking admin first.) If you see one of the CU block templates, that means the block was informed by CU data that you don't have, and which the CU will not give you if you ask. That doesn't stop you from dealing with these unblock requests, however.
• [how to investigate]
• [via referring to ACC]
• [via IPBE]
• [via asking the CU to switch it to anon-only]

Sockpuppetry

• Dealing with these usefully means understanding the basics of WP:SOCK- and WP:UPE-hunting. That is not as difficult as it may sound. Read: WP:GOODSPI, User:Spicy/SPI admin guide, User:NinjaRobotPirate/Identifying sock puppets, Wikipedia:Sockpuppet investigations/SPI/Guide to filing cases, User:Blablubbs/8ball, and User:ST47/8ball. Congratulations. You now understand SPI. You'll have to learn what UPE looks like as you go, for WP:BEANS reasons. Ask your friendly neighbourhood functionary what set off their UPE alarms when you're unsure, and soon enough you too will be cursed with the second sight. WP:LTA/OM has an overview of a particularly large case.
• We usually want the blocked editor to appeal on the "master" account. This is almost always the oldest account. If they no longer have access to that one, it's no big deal. If they do, but they're appealing from a different account, close that unblock and tell them to appeal on the master. Mostly this is so the paperwork is easier to keep track of.
• If the editor has already had checkuser-confirmed socks caught twice after the initial block, they are now WP:3X banned. You can go through all the same steps below, but instead of lifting the block yourself after getting CU approval, you'll first have to take it to the community at AN (see above).

If the blocked editor admits that they are a sock

1. Great news. This makes your life much easier. Ask them to list all the accounts they've used previously. This might line up with what we have at SPI or it might not. This is partly a trust exercise, partly to help us get our paperwork in order, and partly just to get them talking.

   If what they say lines up with what we have at SPI, you find their explanation and/or apology convincing, and this is a first-time block solely for sockpuppetry, jump down to the "summon a CU" step.

   If what they say is rank nonsense, spare a thought for your fellow unblocks admins and try to disentangle as much as you can before you give up and decline the request.

2. [there's more!]
3. Summon a CU with {{checkuser needed}} and ask them to determine whether there is any evidence of recent block evasion.
4. If they say no, you're clear to unblock. If they say yes, you're probably going to have to gently explain to the sockpuppeteer that they're being very stupid and need to take the standard offer.

If the blocked editor says they are not a sock

• SPI doesn't often get it wrong, but when it does, it can be very difficult to disentangle, and the editor in question will be having a really bad time. Many admins take a "that's what they all say" approach, and so the blocked editor gets stuck in an increasingly desperate, kafkaesque scenario where they are being asked to prove they aren't someone they've never heard of before. This is not helpful for anyone, including you and including the blocking admin. The most effective way to sort these cases out is to start from the presumption that what the editor is telling you is true.
• [more tips]

If they say they have completed the standard offer

• Great! First, look for any really obvious reasons to decline the appeal, so you're not calling out a CU for no reason. Has it actually been six months? Are there any more recent sockpuppets? (Check the categories, not just the SPI casepage.) Have they made at least a token attempt to address the reason for their initial block? (It probably wasn't for socking.)
• Ask a checkuser to check for any obvious signs of block evasion. {{checkuser needed}} will summon one. If they say there is confirmed abuse of multiple accounts, it's over. Decline, and give the standard offer again.
• The CU will probably say "No obvious signs of block evasion or logged out editing during the time specified." Now it's up to you.
• [the other things you need to check]

Special cases

Editors who are not actually blocked

• If they're appealing via UTRS, check if they're globally locked. Editors may describe this as "blocked" or "banned".

Philosophy

Every admin is going to have a different philosophy on when to unblock. Here's some of mine.

• Some blocks are very cheap. A kid who changed every instance of "rooster" to "cock" knows exactly what they did and will be caught in minutes if they reoffend. If they swear they're not going to vandalize anymore, just give them WP:ROPE and move on.
• Some blocks are not cheap. Close-paraphrasing copyright issues. Stealth pov-pushing. Source fabrication. These are hard to detect and hard to clean up after. Don't handle them lightly. {{2nd chance}} can be useful here, or converting the block to a p-block from mainspace.
• It doesn't matter whether they're sorry. It only matters that they're not going to do it again. Dragging apologies out of people is an ugly and unnecessary flex of power. If you feel compelled to do it, ask yourself why.
• Don't unblock someone until they understand what they did wrong. They'll just do it again. And this time, it will be your fault.

Advice for non-admins

First, I'm really glad you're here. Don't let anyone tell you that non-admins aren't welcome; you are. There's a lot of good that non-admins can do here. For one thing, most of the "work" at unblocks doesn't involve using any admin tools. For another, you can address the blocked editor as a helpful colleague or sympathetic ear in a way that admins can't do as effectively since we have the power to unblock and to revoke talk page access. However, please seriously consider whether you are the right person for this kind of thing. You need at least two of: deep reserves of patience, uncommonly good common sense, and long and varied Wikipedia experience. All three is preferable. If you read that and thought "that's me, no problem!!" unblocks is probably not for you.

Most blocks are good blocks. Most unblock requests are completely terrible. That doesn't mean most editors shouldn't be unblocked. As a non-admin helper, your aim is a) to make it as easy as possible for the responding admin to come to a quick decision, and b) to help ensure the blocked editor actually gets a fair shot at getting unblocked, if an unblock could possibly be appropriate. If the editor doesn't understand why they were blocked, but it's obvious to you, you can help them figure it out. If the editor hasn't answered some of the questions you know admins are likely to ask, you can try to elicit some useful answers. Keep in mind that your goal isn't to judge whether the unblock request should be accepted or not, but to make it easier for the responding admin to do so. Similarly, your goal isn't to ensure that the blocked editor is unblocked, but to make it easier for them to navigate the process themselves.

Undoubtedly the place where you can save the most admin time is the promo and promo+username blocks. Almost everyone who has been blocked for one of these reasons is blocked simply because they did not understand what was expected of them. Once they understand, they can be unblocked. If you can get the blocked editor to identify their specific connection to the topic they're writing about, and to understand WP:COI and WP:PAID, you've already done most of the work an admin would otherwise have had to do.

Sometimes the most helpful thing you can do is talk to an editor after their appeal has been declined, not before an admin has made a decision. If you've spent enough time watching CAT:RFU and read the rest of this guide, you'll know what admins are generally looking for. A sympathetic, understanding, and realistic evaluation of the blocked editor's potential next steps can go a long way.

Tips:

• Lurk before you leap. Requests will automatically disappear from CAT:RFU when the template is accepted or declined, but you can use discussiontools to subscribe to the heading above the unblock request, and then you'll get a notification when someone responds. You can also search unblocks admins' contributions to User talk pages for likely edits. Edits made using UnblockReview.js will have an edit summary that contains "(unblock-review)".
• Shadowing a more experienced unblocks helper's contributions might help too.
• Blocked editors tend to assume you are an administrator unless you tell them otherwise. {{non-admin comment}} is useful for this purpose.
• You're probably going to keep saying the same thing over and over again. Save yourself time by making yourself some template responses.
• You may find phrasing like "admins usually like to see..." and "I'm not sure this appeal will be accepted, because..." useful. Up to you. Personally, I think it's helpful to put some distance between your words and your opinions.
• For an active appeal, the less you give and the more you elicit, the more helpful you'll have been. The unblocking admin wants to know that the blocked editor understands what they did wrong and isn't going to do it again. If you tell the blocked editor what to say, the unblocks admin has nothing to go on.

Templates

Remember to subst these if you're putting them in an unblock decline.

• {{subst:2nd chance}}: basically impossible for newbies and results in an unblock request that sits in the queue forever because it looks complicated and patrolling admins don't want to be bothered. Avoid in general, but very useful for copyright, LLM misuse, etc blocks.
• {{checkuser needed}}: use this to enlist the services of a checkuser. Only when you're sure you need one.
• {{subst:Decline reason here}}: boilerplate decline. Only any good if the appeal is really, really useless. Otherwise, highly patronizing.
• |idletimestamp={{subst:CURRENTTIMESTAMP}}: use this to move the block from the normal queue to Category:Requests for unblock awaiting response from the blocked user.
• {{uwl}}: a quick link to the unblock wizard. Currently still in testing. Good to hand out to editors who appear to be having trouble understanding what is expected of them in their appeal.

FAQs

1. I closed an unblock and the formatting went to hell, what gives?

   There is probably a : in front of the unblock template. Open the source editor and remove it.

2. I keep seeing appeals with bolded questions and answers. Is this some kind of LLM slop?

   No. (Well, the answers might be.) This is an editor who is using Wikipedia:Unblock wizard to write their appeal.

3. What if an appeal looks like it's AI-generated?

   If you're sure, decline it out of hand and tell the editor why we don't want to hear from their pet robot. If previous appeals were declined for this reason, consider making "no LLM use" an unblock condition. But please think twice before declining for this reason, especially if the editor is likely to be an Anglophone from South Asia or Africa and you are unfamiliar with those idioms. Both native UK/US Anglophones and AI-detectors tend to have high false positive rates here.