Wikipedia

User:Blablubbs/SPI clerking cheat sheet

< User:Blablubbs

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

Websites edit

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}}
    • Use when CU returns   Likely but not confirmed, or in cases where it is essentially impossible to appeal the block based on its merits (such as when the connection is admitted – be careful to rule out joe-jobs though)
  • 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
  • CU-confirmed master: {{sockpuppeteer|blocked|checked=yes}}
    • Use when a checkuser has   Confirmed the connection
  • 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 the Tag dropdown menu → Hit done

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 the Tag dropdown menu → select the appropriate tag for the lower-confidence older master in the Alt Master dropdown menu → hit Done → 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

this section presumes that section moves are enabled in your SPIhelper config; see User:GeneralNotability/spihelper#Config file

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 → hit Continue

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 hit Continue
  • 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 → hit Move/merge full case → enter the name of the new master → hit Continue → 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

Notes edit

  1. ^ However, consider tagging impersonation accounts to avoid confusion.
  2. ^ See WP:HSOCK.
  3. ^ Ever. I mean it.
Retrieved from "https://en.wikipedia.org/w/index.php?title=User:Blablubbs/SPI_clerking_cheat_sheet&oldid=1109271031"