User:Blablubbs/SPI clerking cheat sheet
Appearance
![]() | This is an essay. It contains the advice or opinions of one or more Wikipedia contributors. This page is not an encyclopedia article, nor is it one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints. |
This page contains guidance regarding clerking procedures that I use (and teach) at SPI, intended as a reference for SPI clerks and clerk trainees – although the information about tools and tagging may also come in handy for patrolling administrators. It synthesises information provided elsewhere on-wiki (such as WP:SPI/PROC and template documentation pages), as well as (what I perceive to be) common, but unwritten, practice. These things can change over time, and the advice I give may not always be applicable.
Tools
[edit]Scripts
[edit]- User:GeneralNotability/spihelper.js: Essential SPI toolkit
- User:Writ Keeper/Scripts/cuStaleness.js: Shows registration date and date of last edit for accounts in {{checkuser}} or {{socklist}} templates. The registration date of the oldest account is bolded.
- User:Writ Keeper/Scripts/sockStaleness.js: As above, but for accounts in sockpuppet categories
- User:RoySmith/tag-check.js: Indicates whether and how accounts listed in a case are tagged
Websites
[edit]- spi-tools: SPI multitool
- ip-range-calc: Calculate the smallest range encompassing two or more given IPs
- editorinteract.py: Show page overlap for up to twenty accounts in a table
Templates
[edit]{{sockpuppeteer}}
tags for masters{{sockpuppet}}
tags for socks{{socklist}}
creates an arbitrarily long list of accounts, wrapping each in {{checkuser}} or {{checkip}} as appropriate. Highly customizable, including a|hidden=yes
option, useful for letting spihelper and spi-tools "see" socks that have already been listed outside of the templates they look for.{{maq}}
for inquiring about connections between large numbers of accounts{{uw-agf-sock}}
, usually used when closing as "warn"{{uw-sockwarn}}
, usually used when blocking a sock but not blocking the master- Non-admin clerks :
{{block request}}
, for generating a block link with the appropriate parameters - Trainee clerks :
{{caw}}
, a shortcut to your/ClerkAtWork
page
Tagging
[edit]Manual
[edit]Simple cases
[edit]- Suspected sockpuppet:
{{sock|name of sockmaster|blocked}}
(blocked
is a mandatory parameter)- Use in most cases where CU was not run or returns possilikely or worse
- Proven sockpuppet:
{{sock|name of sockmaster|proven}}
- CU-confirmed sockpuppet:
{{sock|name of sockmaster|confirmed}}
- Suspected or proven master:
{{sockpuppeteer|blocked}}
- Use except in cases where CU explicitly returns a
Confirmed result
- Use except in cases where CU explicitly returns a
- CU-confirmed master:
{{sockpuppeteer|blocked|checked=yes}}
- Use when a checkuser has
Confirmed the connection
- Use when a checkuser has
- 3X-banned master:
{{sockpuppeteer|banned|checked=yes}}
- Use when evasion has been confirmed by a checkuser on two occasions after an initial indefinite block is active
Dual-tagging
[edit]- Use when a group of accounts has a strong connection to each other, and a weaker but still meaningful connection to an older master
- For socks (adjust confirmed and suspected to "proven" whenever necessary):
{{sock|highconfidencemaster|confirmed|altmaster=name of low-confidence master|altmaster-status=suspected}}
- For masters: Either use both
{{sock|name of low-confidence master|blocked}}
and{{sockpuppeteer|blocked|checked=yes}}
, or use only the suspected tag
Using spihelper
[edit]Simple cases
[edit]Block/tag socks
→ Select the appropriate tag in theTag
dropdown menu → Hitdone
Dual-tagging
[edit]- Masters should be manually dual-tagged, or only tagged once (see above) because of an SPIhelper bug that places the wrong tag. The SPIhelper process is a little complicated, so consider also doing dual-tags for socks manually.
- For socks:
Block/tag socks
→ Select the appropriate tag for the higher-confidence, more recent master in theTag
dropdown menu → select the appropriate tag for the lower-confidence older master in theAlt Master
dropdown menu → hitDone
→ Confirm the name of the primary master → enter the name of the altmaster
What not to tag
[edit]- Throwaway vandal socks
- Any LTA sock that is obviously some LTA sock[a]
- Accounts that aren't blocked;[b] accounts that are globally locked are generally considered fair game even in the absence of a local block; use
|notblocked=yes|locked=yes
parameter in those cases - IPs[c]
- Accounts that are already blocked for unrelated reasons where a connection is plausible, but would not be strong enough to justify a block for sockpuppetry
Moves, merges, and splits
[edit]General guidance
[edit]- Generally speaking, cases should always be placed under the oldest account. Possible exceptions are:
- The oldest account has an inappropriate username (e.g. impersonation or attack accounts)
- A case is well-known under the name of an account that is not technically oldest, e.g. because it has by far the highest edit count, it has been banned by arbcom or the community, or because the case is extremely long-running
- When renaming a case to an account that was registered earlier than previously blocked socks, but is indefinitely blocked at a later date, it is often worth noting what the date of the first block was; this facilitates processing of WP:CSD#G5 requests by admins who may not be familiar with the case.
- Projectspace histmerges work by deleting the target page, moving the page to be merged over it, and then undeleting all revisions. This process can be reversed, but doing so is somewhat complicated and time-consuming. If you are unsure whether a histmerge is appropriate, hold off on performing or requesting one and ask for a second opinion first.
Scenarios
[edit]An entire group of accounts needs to be split from the case
[edit]- When a group of accounts is filed and it is found that they are related to one another (or a prior master), but not to the case at hand, a case split is needed. The procedure is the same whether or not they are split into an existing case, or into a new filing
- In the spihelper dropdown, select the relevant date → hit
move case section
→ enter the name of the new master → hitContinue
A partial group of accounts needs to be split from the case
[edit]- When a group of accounts is filed, and part of the group is found to have a connection to each other but not to the case at hand, make a new filing at the target case with only those accounts, and link to the original case in your closing comments.
An older master without a pre-existing case surfaces
[edit]- In SPIhelper, select
All sections
from the first dropdown → enter the new master's username, and hitContinue
- Retag all accounts; check both the archive and the sockpuppet categories, since some accounts may have been blocked outside of SPI
An older master with a pre-existing case surfaces
[edit]Without a histmerge
[edit]- If the two cases have, at any point in time, had active filings (this includes filings that are closed but not yet archived) concurrently, proceed without a histmerge; otherwise, the page history will get messed up. This applies to cases where the histories of the main casepage look something like this:
Case A: ------------- ------------------ ----------
Case B: ----------- -------
- Section-merge the currently open filing(s) into the target case
- Manually copy-paste the archive to the new case name, and reorder the cases to preserve the chronology. I recommend adding the name of the master they were originally filed under, along with the text
{{clerknote}} Original case name
to all merged sections to prevent confusion, then redirect the merged archive to the merge target - In the merged case, replace
{{SPIarchive notice|Name of old master}}
with{{SPIarchive notice|Name of new master}}
- Retag all accounts as needed; check both the archive and the sockpuppet categories, since some accounts may have been blocked outside of SPI
With a histmerge
[edit]- If the two cases have, at no point in time, had active filings (this includes filings that are closed but not yet archived) concurrently, proceed with a histmerge. This applies to cases where the histories of the main casepage look something like this:
Case A: ------------- ----------
Case B: ----- ----------
- In the spihelper dropdown, select
All sections
→ hitMove/merge full case
→ enter the name of the new master → hitContinue
→ confirm that you want to delete and restore the target - Manually reshuffle the archive to maintain chronology if needed. I recommend adding the name of the master they were originally filed under, along with the text
{{clerknote}} Original case name
to all merged sections to prevent confusion, then redirect the merged archive to the merge target - If you are a non-admin clerk, set the case status to
Request clerk action
and ask an adminclerk to perform the merge for you
See also
[edit]- User:Blablubbs/How to file a good SPI
- Wikipedia:Sockpuppetry
- Wikipedia:Sockpuppet investigations/SPI/Guide to filing cases
- User:NinjaRobotPirate/Identifying sock puppets