User:Dbeef/One big SPI guide

Sockpuppet investigations (SPI) are often considered one of the most complex parts to Wikipedia administration. Well, here's one huge reference for everything that happens around SPI.

Purpose

SPI investigates whether several accounts/IP addresses have been abused by the same person. The community assumes everyone edits under a single account at a single point in time, with a few exceptions. Thus we use SPI if it is believed that the sockpuppetry policy was violated in some way.

Opening a case

Follow instructions at the top of WP:SPI to open a case. You can also use Twinkle and file a case by navigating to the sockpuppeteer's user page, then use ARV -> "Sockpuppeteer" to list other accounts you think the sockpuppeteer is using.

Provide as much information you need to convince someone to believe that the accounts are operated by the same person. Not providing enough information may cause significant delays to your case being processed, or the case may be declined outright. Writing too much uninformative text will also make it harder for people processing your case.

For when to request CheckUser, see #Requesting CheckUser.

Titling a case

Cases are titled after the sockpuppeteer. This is usually the oldest account the user was known to use. If an account was well known under a name that is not the oldest account, then the known name may be preferred. In the case where the oldest account has an abusive username, a different account's name may be used as the title.

Processing a case

If you are a user without elevated permissions, wait until someone processes your case. You may be asked to provide additional information or clarify in the mean time.

Information about the status of an SPI case is stored in the {{SPI case status}} template for every case. Most of the statuses are only changeable by administrators and/or clerks and CheckUsers.

User:GeneralNotability/spihelper is used by most editors when processing cases.

Patrolling as an admin

Admins get to block users. SPI is mainly about deciding when to block. At any point, admins can decide to block accounts listed at SPI. An admin can also decide that the evidence to not be enough to warrant a block.

For many cases, this decision alone is enough to close the SPI case. Leaving a note that you blocked the relevant accounts or providing justification for why you think blocks should not be handed would be helpful.

If blocking some accounts on sockpuppetry, proceed to tag the relevant accounts and close the case. If CheckUser was requested, it might be preferred to leave the request as-is even after the decision.

Tagging

We use tags to indicate multiple accounts as being connected in some way. The sockpuppeteer gets the {{sockpuppeteer}} template while the sockpuppets get the {{sockpuppet}} template. Sometimes a case should not be tagged because of reasons. Consult the relevant case page (whether there is a WP:DENY notice) and its archives for best practices.

Sockpuppets have different degrees of connection, based on parameters to the template:

• Use {{sockpuppet|Example|blocked}} (suspected) if a block was made based on behavior only, optionally with a  Possible or weaker CU result.
• Use {{sockpuppet|Example|proven}} if sockpuppetry was very obvious, or with a Likely CU result.
• Use {{sockpuppet|Example|confirmed}} if there is a Highly likely or Confirmed CU result.

Sockpuppeteers get different parameters based on their status:

• Use {{sockpuppeteer|blocked}} (suspected) if all of the sockpuppets should be tagged as suspected.
• Use {{sockpuppeteer|proven}} if CheckUser was not used and some sockpuppets are tagged as proven.
• Use {{sockpuppeteer|blocked|checked=yes}} if there is any sockpuppet tagged as confirmed.

Closing a case

A case should be closed if there's nothing left to do. Admins can close cases where the status is checked or open. Before closing a case, blocked sockpuppet(eer)s should be tagged and accounts that are listed but not blocked should be justified.

It is also helpful to review potential cross-wiki behavior before closing by checking Special:CentralAuth on the accounts listed. If there are socks active on other projects, it may be helpful to notify those projects or request global locks via m:SRG when necessary.

Requesting CheckUser

CheckUser allows retrieving an account's IP address and device data to help with processing a case. While anyone may request CheckUser for a case, it shouldn't be used unless necessary, and should always be justified.

Avoid requesting CheckUser, if:

• The case can be processed and decided with the evidence provided, i.e., if you think the accounts can be blocked purely based on their edits
• The only accounts listed in the case are temporary accounts/IP addresses (CUs can't tell you anything in that case)
• Past CU requests have not yielded anything useful for the case.

Do request CheckUser, if:

• The case is not entirely clear on whether accounts are indeed connected to each other, i.e., the accounts might not be blocked based on their edits alone.
• The sockpuppeteer has a history of creating many accounts, or if past checks on the case have yielded additional accounts (sleepers)

Interpreting CU results

A CheckUser may provide vague descriptions of the potential technical connections between the accounts. They are ordered from most likely to least likely to be connected:

• Confirmed
• Highly likely
• Likely
•  Possilikely (a mix between possible and likely)
•  Possible
•  Unlikely
• Unrelated

Sometimes the results may be Inconclusive: this is similar to  Possible in that behavioral evidence becomes the primary factor for block/no-block decisions, but the former may indicate a deliberate attempt to evade CheckUser.  Technically indistinguishable may be used for when accounts have the exact same data, but use of that template is generally discouraged as its meaning could be ambiguous.

Clerking

Clerks know a decent amount about SPI, so they get to do more things. At SPI cases, clerks' primary responsibility is in helping sort out the evidence for patrolling admins/CheckUsers.

Clerks can endorse CU requests (often accompanied with a comment that extracts the most damning evidence for faster review from an otherwise long-winded case) by setting the status to endorse if they believe CheckUser should be used. Clerks can decline CU requests by setting the status to decline if they don't believe CheckUser should be used. Clerks can close cases.

Archiving

After cases are closed, they can be archived by a clerk. A case should not be archived by someone who has processed it. Archiving looks at the full picture and catches any things that have not been properly done before closure. If you catch something that needs to be done when trying to archive a case, you should do the thing, comment that you have done the thing, and wait for someone else to archive.

Here are some things to look for:

• Accounts that should be blocked or should have global locks requested/placed.
• Accounts that should be tagged or accounts that have been tagged incorrectly.
• Accounts/evidence left unconsidered
• Wrong title for the case

Moving and splitting

Sometimes cases are opened under a wrong title. They should be moved to the correct title, see #Titling a case.

• If the target title does not exist yet, use spihelper, select "All Sections", then "Move/merge full case (Clerk only)"
• If the target title exists, but there was never an overlap in the timeline of cases (when there are non-archived cases on case A, case B was always empty and vice versa), select "All Sections", then "Move/merge full case (Clerk only)". You will be prompted to histmerge the cases (you must be an admin to do this, if you aren't, wait for someone else to do it)
• Otherwise, manually copy the cases yourself to the target title and merge the archives. Add the following line to the moved cases and archives:
  • {{checkuser|Example}} ({{ClerkNote}}: Originally opened under this user)

Sometimes cases should be split because two or more unrelated groups of accounts have surfaced under a single SPI. Ensure that the original case is placed at an appropriate title, then open new cases against sockpuppeteers in the other groups linking to the original case as "pro forma".