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. [note 1]
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 |
---|---|
|
|
"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
.
On the main SPI page, cases are sorted by their status. Here is some guidance on how to handle cases according to their status.
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:
moreinfo
and request additional behavioural evidence from the filer.These are cases where a CU has run a check but has not fully actioned the case. This typically occurs because
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.
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. [note 4]
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.
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.
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.
These ones should just be left alone.
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.
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 [note 5] 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.
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. [note 1]
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 |
---|---|
|
|
"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
.
On the main SPI page, cases are sorted by their status. Here is some guidance on how to handle cases according to their status.
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:
moreinfo
and request additional behavioural evidence from the filer.These are cases where a CU has run a check but has not fully actioned the case. This typically occurs because
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.
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. [note 4]
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.
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.
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.
These ones should just be left alone.
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.
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 [note 5] 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.