User:Spicy/SPI admin guide

This page is intended as a quick guide for admins who want to begin patrolling SPI. Further guidance is available at Wikipedia:Sockpuppet_investigations/SPI/Administrators_instructions.

SPI has a reputation as a complex and insular area of the project, but with the right tools, it's not actually that scary. Before you start contributing, please install User:GeneralNotability/spihelper as it will make things a lot easier.

Do's and don'ts

As a patrolling administrator, you can handle most of the routine tasks at SPI. There are only a few activities that are restricted to CUs and clerks:

Things you can do	Things you can't do
Block socks Tag socks Not block someone if you don't think they're a sock Close cases Add CheckUser requests Request additional information from the filer Request that a clerk merge or rename a case Request global locks	Endorse or relist CheckUser requests Decline CheckUser requests Archive closed cases Merge or rename a case yourself Tell someone that they suck at SPI and need to stop posting

"Endorsing" a CU request means changing the case status to endorse, which is essentially an affirmation by a clerk that the check is within policy and a CU should run it. Endorsement makes the listing on WP:SPI turn a pretty blue colour. You are not allowed to use the pretty blue colour, but you are permitted to informally say things such as "I think running a check would be a good idea", or to request a check by changing the status to CUrequest.

General advice on blocks and warnings

Further information: WP:BADSOCK and WP:GOODSOCK

Not all socks are created equal.

• Usage of multiple accounts is not necessarily abusive. Users who are soft-blocked (blocked with account creation enabled) for username violations are permitted to create a new account. Sequential use of accounts (i.e. one account starts editing after the other stops) is generally not considered to be a policy violation, even if the relationship between the accounts is undisclosed; the user may have just forgotten their password or wanted to change their username. Consider whether someone who appears to be editing while logged out is "IP socking" or if they merely forgot to log in.
• Sometimes people use multiple accounts or IPs inappropriately but are not necessarily intending to mislead or disrupt. The templates {{uw-agf-sock}} and {{uw-login}} are useful for this purpose.
• Sockpuppet accounts are blocked indefinitely. Sanctions for someone who's caught socking for the first time are subject to admin discretion and may include:
  • A warning such as {{uw-sockwarn}} for minor offenses
  • A temporary block (generally lasting a few days to two weeks)
  • An indefinite block if the socking is particularly disruptive, or if there are other serious conduct issues
  • A partial block (rare, but sometimes useful for COI editors or people who are obsessed with a certain page)
    • If you are going to block sockpuppet accounts but leave the master unblocked or partially blocked, block the socks with autoblock disabled (there's a checkbox for this in SPIhelper). Otherwise the master will be unable to edit.
• If someone socks again after a previous block or warning, they should probably be blocked indefinitely.
• IPs should only be blocked at SPI if they are actively editing (i.e. have edited within the past 24-48 hours) or if there is evidence that the IP/range has been used by the sockmaster for at least a week or so. Otherwise an IP block is unlikely to accomplish anything. If an IP made 2 edits a week ago, just close the case.
  • As a general rule, I will usually block IPs for the length of time that they seem to have been used by the sockmaster. If they've been on the IP for a month, block it for a month. If they come back on the same IP, block it for a few more months this time. If an IP has only been used for a day or so, you probably shouldn't block it for much longer than that. Some IPs are static and some are dynamic but if you don't want to get into that I think this rule is OK as a first approximation.
• If you're not convinced that someone is a sock, but you are convinced that they're a spammer, vandal, etc. you can just block them for that.
• As blocks are meant to be preventative, it is usually not worthwhile to block accounts that have not edited in several months.

Handling cases by status

On the main SPI page, cases are sorted by their status. Here is some guidance on how to handle cases according to their status.

Open

These are cases where CheckUser has not been requested. You should approach these by evaluating the behavioural evidence presented. If you are convinced that the reported user is engaging in sockpuppetry, block and/or warn as appropriate and close the case. If you don't find the evidence convincing enough, you have a few choices:

• If the reported users are clearly different people, or the behaviour is not a violation of the sockpuppetry policy, or the totality of the evidence is not enough to be reasonably certain that sockpuppetry is occurring, simply close the case without action and explain why you are doing so.
• If the behavioural evidence suggests a connection, but is not quite enough to block on its own, and at least one previous account has edited in the past few months, you can request CU to compare named accounts. Please leave a comment to explain your CU request. Do not request CU to connect accounts and IPs as this is forbidden by the privacy policy.
• If the case isn't completely meritless but there isn't enough behavioural evidence to block or request CU, or if CU is not possible, you can change the case status to moreinfo and request additional behavioural evidence from the filer.

Checked

A lazy CheckUser engages in recreational activities instead of blocking socks

These are cases where a CU has run a check but has not fully actioned the case. This typically occurs because

• The CU result was not conclusive and behavioural evaluation is needed
• The CU result was conclusive but the CU is undecided on which sanctions to apply
• The filing involves IPs and CUs will not connect IPs to accounts
• Some of the accounts in the case were stale for CU
• The CU is lazy

In these cases, you should evaluate the behaviour in conjunction with the CU result (if applicable). User:ST47/8ball and User:Blablubbs/8ball provide some guidance on how to interpret and action CU results. For IPs, see the comments on IP blocks in #General advice on blocks and warnings. For the most part, stale accounts can be left alone.

CUrequest

These are cases where CU has been requested but not yet run, endorsed or declined. If the socking is obvious, you can just block the user. However, you should leave the case open for a clerk or CU to evaluate the CU request. Closing a case in this situation is effectively declining the CU request, which is a no-no.

Awaiting admin

Non-admin SPI clerks can request that an administrator block users at SPI. Any admin can act on this. The clerk will often specify how long the account/IP should be blocked, which makes things easy for you. Clerks typically know what they're talking about, but you are ultimately the one responsible for the block, so don't feel obligated to act on one of these requests if you're not confident in it.

CUdecline

These are cases where CheckUser was originally requested but was declined by a clerk or CU. These can basically be handled like "open" cases, except you can't request CU again.

Moreinfo

These are cases where a clerk, CU or admin has requested additional evidence from the filer. Sometimes the filer will provide more evidence and you can treat this as you would an "open" case. Sometimes they won't, and if it's been a week or so and they haven't responded you can just close it.

Endorsed, relisted, on hold, clerk request

These ones should just be left alone.

Tagging and other clerical matters

See also: User:Blablubbs/SPI clerking cheat sheet § Tagging

As a patrolling admin, you don't necessarily have to tag socks. You can change the status to clerk and have an SPI clerk do it if you want. However, this might make the clerks sad and SPIhelper's dropdown menu makes tagging pretty easy.

An example of dual tags

• Most accounts blocked at SPI should be tagged. Four exceptions:
  • Don't tag accounts that are only temporarily blocked.
  • Some LTAs like the attention and will have a notice on their SPI page saying not to tag them.
  • Don't tag accounts with egregiously offensive usernames. This only serves to publicize the inappropriate username.
  • I don't always bother to tag low effort spam/vandalism socks but it's fine if you do.
• Generally, the oldest account is tagged as the master.
• If the CU says the accounts are "confirmed" or "technically indistinguishable", tag as confirmed.
• If the CU result is a bit weaker but still supportive of socking (e.g. "likely" or "possilikely") you can tag as "proven".
• Proven tags can also be used if CU was not run or was unhelpful but the behaviour is extremely obvious (e.g. User:Spicy gets blocked and the next day User:Spicy2.0 shows up to make the same edits).
• Otherwise, tag as suspected.
• Clerks can do some weird stuff with dual tags but that's generally not worth worrying about.

Cases should generally be filed under the oldest account. If this is not the case, you can change the status to clerk to request that a clerk move the page.

If the master account is globally locked or there is a notice on the SPI page about cross-wiki abuse, it's a good idea to request global locks on the sock accounts and note that you have done so. There's a checkbox for this in the "Block/tag socks" dialog of SPIhelper. But if you don't want to do this, don't worry as the archiving clerk will probably catch it.