Before applying, have a look at ouradvice for prospective clerks.Applications are discussed by the checkuser and SPI clerk team, and new clerks are added as needed. Applications where the editor has become less active on Wikipedia may be removed by a checkuser or SPI clerk.Applicants are encouraged to actively participate in SPI cases as this will increase their chances of being selected.Please add your request to the bottom of this section, using the following format:
Clerks/Checkusers - This is a list of editors who would like to become trainees.
Please leave endorsements/comments as appropriate, and remove each request once a consensus (either accepting or rejecting a prospective clerk) has formed.Editors who have their application rejected should contact the removing editor for feedback before re-applying.
Was seeing a couple of cases awaiting a close and wanted to help out! I've been trying to patrol wherever possible but most are being handled by CUs pretty quick and don't need behaviorals.qedk (t愛c)19:12, 23 April 2025 (UTC)[reply]
@0xDeadbeef: For sure, but just to confirm, I am waiting on CU/clerk assent before returning as one, will function as a patrolling admin for now. --qedk (t愛c)18:03, 12 May 2025 (UTC)[reply]
Any CheckUsers or SPI clerks interested in trying out a new script for tagging users on SPI pages?User:Daniel Quinlan/Scripts/SockTags enhances SPI pages by displaying visual tags next to usernames based on userpage templates. If that sounds familiar, it's essentially a drop-in replacement forUser:RoySmith/tag-check.js (the tagging logic, the icons, and the concept are very much based on that script). It's written in modern JavaScript to be fast, reliable, and easier to customize with CSS. It also handles all template redirects. Please also let me know if you have any feedback!
I wroteUser:Dbeef/One big SPI guide because I thought our current documentation is too fragmented and confusing as to what their scopes are.
Might have left out something or the language might not be good enough. Feel free to edit/provide feedback as you see fit. Comments welcomed! :)dbeef [talk]12:06, 30 June 2025 (UTC)[reply]
Nice guide. Some of my random personal suggestions on things you could potentially add:
Titling a case: Occasionally there will be a case where the oldest account has an extremely abusive username—in such cases we will obviously pick a different account to title the case.
Sometimes a case should not be tagged because ofreasons. If we are looking for more specific guidance on when to tag: I recommend avoiding tagging in cases where (1) the kind of edits the socks are making are obvious vandalism that theoretically could be handled atWP:AIV, or (2) the motivation of the user is specifically to get attention and frustrate the community (as evidenced by e.g. taunting admins, harassing editors, or literally asking for blocks). When in doubt, the default is usually to tag at SPI, especially for the sockmasters whose motivations are spamming or POV-pushing (i.e. not to feed some psychological desire for attention, but to promote some particular viewpoint or subject on Wikipedia—this is the most common motivation for socking, I think).
the "Strike out usernames that have been blocked" gadget
mw.loader.load("/w/index.php?title=User:Writ Keeper/Scripts/cuStaleness.js&action=raw&ctype=text/javascript"); – annotates usernames at SPI with whether CU data is likely available for that account (based on whether the account has had edits/log entries in the last 90 days).
If you are a checkuser,importScript('User:Stwalkerster/culoghelper.js'); is basically mandatory.
I have grown to really dislike Technicallyindistinguishable as a CU result because of how five different checkusers can give you five different ideas of what it means—I would encourage my fellow CUs to join me in boycotting that template. For example, I have heard some checkusers say that it is a level of confirmed even beyond confirmed (where literally every IP address and user agent string was identical between two accounts); other checkusers say it is somewhere in between confirmed and likely (as you have described in your guide); still others use it to emphasize that while the accounts may betechnically related, thebehavior still needs evaluation (we have{{behav}} for that use case).
Sometimes CUs will use the templatePossilikely (a mix between possible and likely)
Before you close out, I recommend also checkingSpecial:CentralAuth to see if there is any cross-wiki activity. If there is, it may be prudent to notify those other projects, or more commonly, if past socks have been globally locked already, you can request global locks atmeta:SRG. spihelper can do this for you. Add|crosswiki=yes to{{SPIarchive notice}} if you notice a new cross-wiki sockmaster.
Similarly, you can add|deny=yes and|notalk=yes to{{SPIarchive notice}} if you think that tags should be skipped or TPA should be revoked for a sockmaster.
I think just adding documentation to our templates would be enough to fix usage (and/or spending time on agreeing what all the little one liners mean :). I do not think{{behav}} is for use when technical data matches A and B. I have most seen it used when a CU is unwilling to provide a block or obviously-block-worth result from a technical review (and this is how I've used it). For{{tallyho}} I use it to indicate "data is the same", because that's literally what's on the tin. If you want to say something is confirmed or "no possible way this isn't X", I think that's provided by{{confirmed}}. I'd honestly take tallyho out of the 'ranking' and just note that it exists at least for "technically looks the same" without implying anything about behavior. (All in all I also don't use the specific templates, though my verbiage often matches.)
Spicy at least has in his 8 ball (or somewhere?) that he is trying never to use possilikely, I think on the premise that that's... still just "possible". I've also tossed it, tending toward the manual "possible tending likely" personally for what possilikely maybe wants to express. (This generalizes nicely to possible tending unlikely.)
I think you can check Special:CA, but I also think you can usemark-locked.js.
I am apparently using theL235 loghelper personally. Would be nice if we all got on the same page. Maybe we should get some of these gadgeted.
And at this point I suspect most admins (or edit filter types) will want to useUser:Daniel Quinlan/Scripts/Unfiltered.js (which is functionally a followup to an earlier script I used), though IDK if the recommendation should be made here. :')
spihelper can also manage the archive notice.
That all said, I'd really rather that any valuable content here get merged into the guide(s) proper. If things need an overhaul, that's fine, but this page at-present also doesn't appear to catch Everything the current guides do off the cuff.
Scattering/scope does seem to be a problem. I don't really know how to tackle that issue. Consolidating literally everything might fix it in some ways, but also might make it confusing for people who don't need to know clerk things. ArbCom's guide adjustment was nice because they had reasonable phases to attach things to, but SPI doesn't quite function like that.Izno (talk)20:36, 1 July 2025 (UTC)[reply]
I'm glad we're talking about it here. I also think some of these guide things are too long-winded to be effective.
I've been trimming down these pages a bit but I got a bit tired and also wondered if others feel the same. Will probably be bolder until someone tells me to stop.dbeef [talk]03:48, 2 July 2025 (UTC)[reply]
Hm, I think the "what happens in the case" bit is actually useful info to someone who isn't familiar with SPI, and it's currently pretty short. --asilvering (talk)23:05, 2 July 2025 (UTC)[reply]
Point is, if you wanted to know what happens after you file a case, you should read the other pages anyway. Otherwise they shouldn't be split and should be like mine, one big guide.dbeef [talk]02:46, 3 July 2025 (UTC)[reply]
Hi all, if you are a CU and have used CU for complex cases (spanning multiple accounts/multiple IPs), you probably have experienced the need to use a text editor to store sock lists, and to go back and forth between pages to collect all socks in a group.
You might be interested in this new script that I have developed:User:Dbeef/cplus which allows you to select accounts directly in the CU interface for much more efficient reporting.
@Dbeef: Just tried this out. Pretty cool! Would it be a heavy lift to also add support for "get users" too? I know that with the advent of the helpful summary table that appears at the top of the "get actions" and "get users" screens, some checkusers nowadays only use "get actions" and rarely "get users", but stubbornly, I still just do "get IPs" → "get users" in most cases, as that is just what I'm used to. I generally only look at "get actions" if I need to do a deep-dive on a particular IP's timeline.(Making manual{{checkuser|sock name}} lists, rather than using{{sock list}}, is also basically a muscle memory to me at this point whenever I need to report CU results... I'm starting to feel old, lol. The times they are a'changin'.)Mz7 (talk)04:05, 29 July 2025 (UTC)[reply]
@Dbeef: Oooh, thanks! That's awesome. I will try it out. @Salvio giuliano: Yeah... I can think of several changes that have happened in the last few years to Wikipedia's processes that have me shaking my fist saying, "Back in my day...." It's a weird feeling to feel like one of the old-timers instead of one of the up-and-coming newbies.Mz7 (talk)08:20, 31 July 2025 (UTC)[reply]
Hi everyone!User:Daniel Quinlan/Scripts/SockDecay is a new script that shows user activity on SPI case pages and sockpuppet category pages with compact color-coded indicators, highlighting users to indicate which are active and which are likely stale, assisting anyone working on SPI cases. It's a modern script with user-friendly configuration, improved freshness detection including abuse filter queries and IP range support, efficient API usage, and several other helpful features.
SockDecay is essentially a drop-in replacement forcuStaleness.js andsockStaleness.js. This script owes a lot to those scripts byWrit Keeper. For anyone who intentionally ran only one of the original scripts, there's also an option to disable automatic activation on SPI case pages, sockpuppet category pages, or both.
Please try it out and let me know if you have any feedback!
@Daniel Quinlan: Regarding the SockDecay script, one thing I found great about the old scripts is that it italicized/bolded the oldest and newest creation and editing dates. This was useful for (a) determining which account was the "master" account (for any case renames) and (b) which accounts have the most recent activity, to start checking. Is this something you're willing to incorporate into this script?KevinL (akaL235·t·c)17:58, 6 September 2025 (UTC)[reply]
@L235: Done! That seems like a useful feature. The activity indicator for the oldest registered account is now bolded, and the indicator for the most recently active user is italicized. Those styles can also be customized via CSS.Daniel Quinlan (talk)01:35, 7 September 2025 (UTC)[reply]
I'd like to propose a new SPI case status, which I hope can shave some bother off the process. Basically, the idea is that all new SPIs (or all new SPIs with checkuser=no?) start with this new case status, which we could call "new" or possibly something more creative, that represents a pre-triage state. "Open" would then be reserved for cases that a) have been glanced at by a CU/clerk/(patrolling admin?) and judged to be sane and reasonably complete, and b) were set to "more info requested" or "on hold" and have since had useful developments.
This would make the "SPI inbox" much clearer than it is at present. Right now it has brand-new cases jumbled in with old behavioural cases no one's had time to check out yet, leading to the following annoying waste of time:
Clerk1 looks at "open" SPI, determines that CU would not be useful but that sufficient info is present for it to be worth investigating, decides "I don't wanna rn", and moves on to the next "open" case.
CU1, looking to see if there's any easy CU-able cases to snipe out of the "open" bin, opens the SPI, is disappointed, and moves on to the next "open" case.
CU2 looks at "open" SPI, determines that CU would not be useful but that sufficient info is present for it to be worth investigating, decides "I don't wanna rn", and moves on to the next "open" case.
Sounds good to me. I think a better way to implement it might be to use something like "Open, triaged" to represent something that at a glance (a) does not need CU and (b) sufficiently reasonable enough for an investigation.dbeef [talk]03:28, 14 September 2025 (UTC)[reply]
I really like the idea and agree with Dbeef that the specific names could use some further thought but certainly support the broad change. Best,KevinL (akaL235·t·c)17:53, 18 September 2025 (UTC)[reply]
Perhaps we ought to leave "open" for the new arrivals, and sort the reasonable non-CU ones into a new status, "awaiting behavioural investigation"? I don't like how long that is, but I do think it's helpful to name the categories according to what actually needs to happen to them next. --asilvering (talk)20:13, 18 September 2025 (UTC)[reply]
Hmm. My original thinking was that changing the ways cases get filed is a bit hard, but I suppose you can just change the twinkle config. Newly filed cases as "new" and then clerks changing them to "open" is still fine I suppose.dbeef [talk]20:52, 18 September 2025 (UTC)[reply]
They actually get filed with an empty status by default, I believe! An empty SPI case status resolves to "open" right now, but it doesn't have to. Also, my hunch is that Twinkle adds SPI cases by substituting the template atTemplate:SPI_report, which we can also change.KevinL (akaL235·t·c)21:54, 18 September 2025 (UTC)[reply]
Okay, so what we'd need to do is:
rig the SPI report template to have a new colour etc for "new"
change whatever it is that resolves "empty" as "open" so that it resolves as "new" instead
make sure Twinkle and the form atWP:SPI both start new cases with an "empty" status so that the above works
add "open" to SPIhelper as one of the "change status" options
bonus: create clerk/patroller template for{{opened}} and add that to SPIhelper's change status behaviour
You can see what template wikicode Twinkle is writing by opening DevTools and checking the network tab while submitting an SPI report using Twinkle. One of the rows in the network tab will be the API query with the wikicode. If you need any help with that let me know. –Novem Linguae(talk)03:34, 20 September 2025 (UTC)[reply]
Over time I could make changes. I mean the majority of it just relies on the categories a case has, but I could see how there would be new ones. --Amanda (she/her)21:21, 19 October 2025 (UTC)[reply]
Clerks: you should all have just gotten an invite to a Discord server. If you missed it, either I don't know your Discord name or you're not on Discord. Send me a DM to get the link. Cheers! --asilvering (talk)16:41, 17 October 2025 (UTC)[reply]
Technicallyindistinguishable as a CU result because of how five different checkusers can give you five different ideas of what it means—I would encourage my fellow CUs to join me in boycotting that template. For example, I have heard some checkusers say that it is a level of confirmed even beyond confirmed (where literally every IP address and user agent string was identical between two accounts); other checkusers say it is somewhere in between confirmed and likely (as you have described in your guide); still others use it to emphasize that while the accounts may betechnically related, thebehavior still needs evaluation (we have{{behav}} for that use case).
Possilikely (a mix between possible and likely)