Wikipedia:Sockpuppet investigations/SPI/Clerk and checkuser procedures

Indicators and templates   (v  · e)
These indicators are used by Checkusers, SPI clerks and other patrolling users, to allow easier at-a-glance reading of their notes, actions and comments.
Case decisions:
IP blocked  {{IPblock}}	Tagged  {{Stagged}}
Blocked but awaiting tags  {{Sblock}}	Not possible  {{Impossible}}
Blocked and tagged  {{Blockedandtagged}}	Blocked without tags  {{Blockedwithouttags}}
No tags  {{No tags}}	Blocked and tagged. Closing.  {{Blockedtaggedclosing}}
Information:
Additional information needed  {{MoreInfo}}	Deferred  {{Deferred}}
Note:  {{TakeNote}}	In progress  {{Inprogress}}
Clerk actions:
Clerk assistance requested:  {{Clerk Request}}	Clerk note:  {{Clerk-Note}}
Delisted  {{Delisted}}	Relisted  {{Relisted}}
Clerk declined  {{Decline}}	Clerk endorsed  {{Endorse}}
Self-endorsed by clerk for checkuser attention  {{Selfendorse}}	CheckUser requested  {{CURequest}}
Specific to CheckUser:
Confirmed  {{Confirmed}}	Unrelated  {{Unrelated}}
Confirmed with respect to the named user(s).  No comment with respect to IP address(es).  {{Confirmed-nc}}
Technically indistinguishable  {{Technically indistinguishable}}
Likely  {{Likely}}	Unlikely  {{Unlikely}}
Possible  {{Possible}}	Inconclusive  {{Inconclusive}}
Declined  {{Declined}}	Unnecessary  {{Unnecessary}}
Stale (too old)  {{StaleIP}}	No comment  {{Nocomment}}
CheckUser is not a crystal ball  {{Crystalball}}	CheckUser is not for fishing  {{Fishing}}
CheckUser is not magic pixie dust  {{Pixiedust}}	The CheckUser Magic 8-Ball says:  {{8ball}}
Endorsed by a checkuser  {{Cu-endorsed}}	Check declined by a checkuser  {{Cudecline}}
Possilikely (a mix between possible and likely)  {{possilikely}}

The sock puppetry investigation procedures page covers the procedures for patrolling, clerking and CheckUser work on the Sockpuppet investigations pages.

General notes

These pages are used to discuss whether a user is likely to have violated Wikipedia's sock puppet policy, or breached other restrictions (e.g. blocks or bans) using multiple accounts or IPs. When reviewing cases, keep in mind that there are legitimate uses of multiple accounts, and that improbable things can happen by chance. Unfairly blocking someone as a sockpuppet is a harm not easily undone.

Patrolling

The following users may do the following:

Any capable user

• may:
  • help or contribute on an open case. This includes adding analysis, evidence, and comments, as well as making minor obvious corrections and improvements, and posting optional notices to users if their input is necessary in the case.
  • add a Request for CheckUser to a case, if one likely to be needed, by changing {{SPI case status}} to {{SPI case status|CUrequest}}.

Any administrator

• may:
  • make the decision in a case based on the evidence, if they feel capable, and tag as provisionally closed, changing {{SPI case status|<status>}} to {{SPI case status|close}}. A clerk will then review the case before archiving.
  • take administrator action as appropriate, noting such action on the case's page. Remember that blocking a "sockpuppet" who is really not a sockpuppet is unfair to the person you have just blocked. The sock puppet policy requires firm evidence or similar before blocking a sockpuppet; see Identification and handling of suspected sock puppets. When in doubt, don't hesitate to require more information, or ask for a second opinion.

• may not:
  • archive cases. This is restricted to clerks and clerk trainees.
  • endorse or deny a CheckUser request, or otherwise change the status of an SPI case to anything except close, moreinfo, hold, clerk or CURequest.

Trainee clerks

• may:
  • archive cases by removing the {{SPI case status}} template and moving the case to the /Archive page.
  • remove or refactor (within reason) any material by any user that is not strictly relevant to SPI. This material should not be reinstated by anyone other than Clerks or CheckUsers. Rather, if there is concern that a trainee has acted incorrectly, please contact a clerk to look into the matter.
  • endorse or decline requests for CheckUser by changing {{SPI case status|curequest}} to {{SPI case status|endorse}} or {{SPI case status|decline}}.

• may not:
  • take on another user as a clerk trainee or perform any actions not denoted by the clerk's trainer.

Full clerks

• may:
  • operate all SPI procedures including endorsing or declining CheckUser requests by changing {{SPI case status|curequest}} to {{SPI case status|endorse}} or {{SPI case status|decline}}.
  • ask users to cease patrolling or posting to SPI pages (other than to open a case or present evidence) if there are problems.

CheckUsers

• may operate all SPI procedures.
• have the sole discretion and decision whether or not the CheckUser tool will be used. This includes the decision to use it when not requested or declined, and also to decline (as denoted by {{SPI case status|cudecline}}) even if already provisionally endorsed by a clerk.

Process notes

Process overview for clerks

Please note that only clerks and CheckUsers may endorse or decline CheckUser requests

In broad, cases progress the same whether or not CheckUser is requested. The only difference is that if a case has CheckUser requested, and it is endorsed, then extra evidence will be added to the case.

I.	If you think a case merits a CheckUser investigation, on the {{SPI case status}} template, replace the curequest parameter with endorse or, alternatively, add the endorse parameter if no user has requested CheckUser, but you feel one is necessary. Then, in the "Clerk, CheckUser, and/or patrolling admin comments" section, add {{endorse}} or {{decline}}, followed by a short explanation as to why you have endorsed or declined a CheckUser request.
II.	After a CheckUser commented on the case (if applicable), replace the {{SPI case status}} parameter from endorse to checked. (Most CheckUsers do this for the clerks after a check is completed.)
III.	Review the case carefully. At this point, any administrator can make a determination as to whether sock puppetry or similar has occurred and take action if needed.
IV.	Tag the user page of the sockpuppet you have just blocked with {{sock|MasterAccount|blocked}} or {{sock|MasterAccount|confirmed}}.
V.	Once finished, add your notes (using {{clerk-note}} if desired), and replace the {{SPI case status}} parameter to close to mark the case as ready for final clerk review and archiving. It is general practice (with exceptions) to have another clerk review your work when you change the case status. As a rule of thumb, try to keep yourself from changing two case statuses in a row. A key responsibility of Clerks is to review the case before finally archiving, to see if anything else needs doing, if it is really closed, and so on. This helps detect any errors by non-clerks (or clerks), and/or incomplete handling issues. In particular, it is important to check that sockpuppets' userpages are properly tagged. Check for additional evidence or notes added after the case was closed. It is recommended that clerks use this script to help with changing states, and especially archiving.

Advanced clerking

Whilst the procedure above deals with run of the mill clerking of cases, there are cases where clerks need to "tidy up" a case that hasn't been properly filed, or perform some other out of the ordinary action. This section describes the correct procedures to be followed.

Cases filed under the name of the sock

Despite our best efforts in the instructions, many users file cases under the name of the newly discovered sockpuppet, and list the master as a sockpuppet.

In such cases, clerks must switch the case to the correct master. The procedure to be followed is different, depending on whether a prior case has been filed for the true master account;

No case has ever been filed for the account we wish to file the case as

1. Move the case page to the correct name.
2. Edit the case at the new name, switching all occurrences of the sock and master names as appropriate.
3. Edit the redirect at the old name, replacing the redirect with {{SPIarchive notice|newcasename}}.

No case is currently active for the account that we wish to file the case as, but a prior case has been filed

See also: WP:HISTMERGE

1. If you are a non-admin clerk, contact an admin clerk to merge the cases.
2. If you are an admin clerk, move the case page to the existing case page, leaving a redirect.
3. When it asks if you want to delete the target page, confirm that you do.
4. Click on the history of the new page. Click on the link that shows all the deleted revisions. Check all the deleted revisions and click on the Restore button.
5. In the new information on the new page, correct any occurrences of the sock and master names as appropriate.
6. Edit the redirect at the old name, replacing the redirect with {{SPIarchive notice|newcasename}}.

Cases where sockpuppetry has been found, but the listed master is unrelated

Just move it to the oldest sock in the confirmed list.

Clerk notes

Clerks are called upon to make procedural notes, along with constructive observations. Some types of notes that clerks are asked to make are:

• If the reporting party failed to sign the request (using ~~~~) clerks, for transparency reasons, should note who filed the request.
• Clerks should always note the reason why they are endorsing unless it's a well known sock.
• If the case requires more evidence (i.e. diffs), note it and request the filing party provides more evidence. This can be done using {{MoreInfo}} followed by a custom explanation, or {{DiffsNeeded|cu=no}} to provide a more detailed description of what is required.
• Clerks are also asked to watch cases closely, and if needed ensure the case remains focused and on track. Discussions here should be relevant to the topic at hand. Off topic comments may be collapsed or removed. If this is done, a note should be left on the case page, along with contacting the party whose comment(s) the clerk removed.
• If a patroller has blocked a sockpuppet, note that on the case page.
• Clerks can add notes to the case page under the section Clerk, patrolling admin and checkuser comments. {{clerknote}} is a template clerks can use.
• Clerks should not archive a case they closed. Another clerk or member of the SPI team should do so.

Closing a request

A case should be closed when there is no further action needed. Examples include requests that have been dealt with by a checkuser, checkuser requests that have been declined by a clerk, and requests in which the involved parties have been blocked or cleared of sockpuppetry.

• Please make a note of the action taken (or not taken) in the section Clerk, CheckUser, and/or patrolling admin comments.
• Replace the {{SPI case status}} parameter to close and make any additional comments in the clerks' section. For example, if a CheckUser has uncovered and listed several accounts, they will need blocking and tagging, so adding {{admin-note}}--All blocked and tagged comment would be a useful indicator.
• If you are reviewing a close requested by someone else, clerks can accept the close by archiving using the script. If clerks do not accept the close request, they can simply remove the close parameter from the {{SPI case status}} template, thus leaving the case open.

General notes

• Trainee clerks may undertake all of the usual clerk tasks, except:
  • Posting of formal SPI/CU notices other than as agreed;
  • "Coach" a trainee.
• CheckUsers will often be approached by clerks or users if there is a question about a sock puppet matter, and should advise as best they see fit.
• Any CheckUser, at any time, at their judgement, may
  • Use CheckUser in a case if they feel it appropriate
  • Decline to use CheckUser in a case if they feel it appropriate

CheckUsers are responsible for the use of the tools they have, and should never use those tools without checking personally that there is good cause.

Templates

For tagging

• {{sockpuppet}}
• {{sockpuppeteer}}
• {{checkedsockpuppet}}

For cases

• {{SPI case status}} (see Template:SPI case status/doc for complete documentation)
• See top of this page for the rest.

• Once a Checkuser performs a check they should update {{SPI case status}} to read {{SPI case status|checked}}.