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. Consensus for accepting or rejecting a prospective clerk is typically reached through discussion on the functionary mailing list.Editors who have their application rejected should contact the removing CheckUser for feedback before re-applying.
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]
Ah, looking at it, it's slightly more complicated, since there are some conditionals in here. But, if I'm honest, I don't know that those conditionals are useful to have in any case. Right now it only allows admins to change from admin to open, and clerks from clerk to open. I'm pretty sure that whole section can be removed, and "new" added in the lines right above it. But I'll leave that for someone who knows what they're doing and has int admin. Like perhaps a certain @L235? --asilvering (talk)19:38, 29 October 2025 (UTC)[reply]
I made the changes above before seeing this warning, but given that GN is not active my assumption is that the syncing is no longer active.Sohom (talk)12:49, 30 October 2025 (UTC)[reply]
(Non-administrator comment) I just stumbled across this feature and I'm confused. Is "open" going to be anotherde facto backlog like what "CU completed" is? How does it differ from "CU declined", which is also used when the case requires behavioral evidence?ChildrenWillListen (🐄 talk,🫘 contribs)20:22, 31 October 2025 (UTC)[reply]
If it's "open", CU has not been performed and does not need to be. "CU declined" is used for cases where CU has been requested by the filer and declined by a CU or clerk. --asilvering (talk)22:44, 31 October 2025 (UTC)[reply]
There is a super secret reason where CU can be declined because CUs don't want to say anything even though CU might have been run.dbeef [talk]06:04, 1 November 2025 (UTC)[reply]
Yes. And, like I said, I think we'll end up having fewer CU-declines eventually because of other changes I'm hoping to (get consensus to) make in the future. But I'd rather do it one step at a time to see if any unexpected problems occur, rather than changing the whole workflow right at once. Also, having dug back through various discussions, CUs have previously strongly preferred that SPI statuses reflect the stage a case is at in the CU workflow, not a more instrumental "what needs to happen next in this case". I strongly prefer the latter, but you'll notice I first proposed this change before I became a CU. I'm waiting to see if having the goggles changes my mind. (So far: no.) --asilvering (talk)16:35, 1 November 2025 (UTC)[reply]
I also agree with your perspective. Anyway, I looked back at howWP:SPI came to be, and it seems to be a combination of two seperate processes,Wikipedia:Suspected sock puppets, andWikipedia:Requests for checkuser. The former used to examine behavioral evidence, and the latter, technical evidence. However, this difference slowly faded away after SPI was introduced (well, or even before, seethis for example), and the process has become much more focused on CheckUser, with behavioral cases being pushed aside into backlogs.ChildrenWillListen (🐄 talk,🫘 contribs)18:12, 1 November 2025 (UTC)[reply]
I've made two edits ([1],[2]) to remove the request CU part of the form. I believe @Chaotic Enby has put in a Twinkle pull request to remove it from that interface as well. The aim here is that all new cases will end up in "new" rather than some of them starting in "CU requested". CUs and clerks already pull CU-able stuff out of the "new" pile, so this won't change anyone's workflow on our end, though we may get some confusion from submitters for a bit. The aim here is to avoid things going into the "CU declined" bin, where they languish forever even though they could be easy to action. Hopefully this will speed up the SPI time for some of the easier cases that keep going stale for no good reason, and also make submitting a bit less confusing to editors. Also, it'll stop submitters from getting pissed at us for "closing" a "WP:DUCK" report because we declined a check for being against policy. --asilvering (talk)21:14, 17 November 2025 (UTC)[reply]
I mean I think the longterm endgame is to remove the "CU declined" status and replace it with "open". After all, status should describe whatneeds to happen (new = triage, open = behavioral investigation, endorsed = checkuser, closed = archive it, moreinfo = more info, etc.) rather than whathas happened ("CU declined"). Best,KevinL (akaL235·t·c)22:22, 17 November 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]
Just a comment. The AttackTheMoonNow - Brian K Horton connection has been obvious for a long time, and I can vouch for it based on CU stuff (not to mention the behaviour). Plus there's a few other SPIs dotted around. It's only laziness that has stopped me calling for or doing a merge. I can see the advantages of a merge. AttackTheMoonNow is the older of the two accounts, which is fortunate for the next point. It seems blindingly obvious to me that MickMacNee is also AttackTheMoonNow, though I don't have the CU to back that up. A complication previously noted arises because AttackTheMoonNow is the account that was WMF-banned. Merging AttackTheMoonNow into MickMacNee might be a bureaucratic stretch for the WMF. Merging the other way goes against our usual practices. How to properly resolve the MickMacNee angle? I don't know. Maybe we cope with adequate signposting (which is already more or less in place). --zzuuzz(talk)10:18, 7 November 2025 (UTC)[reply]
ArbCom has monthly meetings with the T&S, maybe they can discuss it there. Again, it's very obvious they're all the same person, and the WMF would probably agree.
I do think an LTA page in is order: they engage in predicable behaviors, off-wiki harassment, and are not immediately seen as vandalism-only accounts. However, I don't want to interact with them too much with to avoid being the subject of said harassment.ChildrenWillListen (🐄 talk,🫘 contribs)14:09, 7 November 2025 (UTC)[reply]
WMF doesn't care how we organize things locally, if anything it would mostly be confusing for local users who don't know the connection and later don't notice that the one account's socks gets locked a lot at minimum because of the global ban (IDK how crosswiki ATMN is, my sense is not very based on the locus of current disruption).Izno (talk)18:19, 7 November 2025 (UTC)[reply]
Frankly, the reason I haven't merged them is because I'm lazy. I don't think there's anything wrong with merging MMN into the ATMN archive - it's against our usual practices but those aren't policy, they're just usual practice. Everyone knows the guy as ATMN, it would be silly to rename the whole case to MickMacNee at this point. Also I'm not retagging that many socks. --asilvering (talk)18:34, 7 November 2025 (UTC)[reply]
Questions have been asked about tagging TAs. I'm inclined against as being excessively noisy in categories at the end of the day and from what I can see little to no benefit. But figured I'd start a discussion.Izno (talk)23:51, 10 November 2025 (UTC)[reply]
The main technical reason against tagging IP's, that they might eventually be assigned to someone else, doesn't apply to TA's so we don't strictly need a rule against it. In that context, I'd say let's wait three to six months to see what TA Loutsocking actually looks like in practice before making a firm decision, and in the meantime leave it to the discretion of the closer/archiver. I imagine most of the time, it won't be necessary, but I could see there being the odd exception, especially for TA's that were blocked without being report to SPI. Of course, that's all still speculation on my part.Sir Sputnik (talk)00:59, 11 November 2025 (UTC)[reply]
I see tags as signposts to the correct SPI, and relevant behaviour patterns, and leaving occasional signposts has its benefits. I plan on not ruling it out. As Sir Sputnik says, the user behind the tag isn't going to change. I'd add a bit caution here though - checkusers and TAIVs need to really think twice before and during any tagging of temp accounts, due to the privacy stuff. OurTAIV policy currently distinguishes LTAs and complex cases from other SPI cases. TheWMF policy talks about "reasonably believed to be necessary". --zzuuzz(talk)01:55, 11 November 2025 (UTC)[reply]
I've been tagging for the signpost value, myself, but I'm pretty equivocal about it. In some cases I haven't been tagging at all. I think it probably makes the most sense to meet in the middle with "you don't need to bother tagging accounts blocked at SPI, but should maybe consider it for ones you blocked in the wild"? --asilvering (talk)01:59, 11 November 2025 (UTC)[reply]
I like this standard. I do think that if someone indefs a temporary account for sockpuppetry they should either link the SPI in the block reason or tag if the reason is generic.dbeef [talk]02:26, 11 November 2025 (UTC)[reply]
The CheckUser team is seeking newSockpuppet Investigations (SPI) clerks. Clerks areresponsible for assessing the evidence available in SPI cases, endorsing SPI cases for CheckUser attention, resolving SPI cases by recommending blocks or other administrative action (if the clerk is not already an administrator), and generally managing the SPI process. Administrators do not need to serve as SPI clerks to adjudicate SPI cases, but the role comes with training and mentorship that can be helpful even for existing administrators who want to help out. Clerks and patrolling administrators are the backbone of SPI, and we are deeply grateful to them.
In addition to the typicalon-wiki application process, we will accept applications by email directly tocheckuser-en-wpwikipedia.org within the next two weeks (by approximately November 25).
In addition, if you are interested in the role but are not certain you'd like to apply, we invite you to reach out – I personally am always glad to talk about the role. Speaking personally, I served as an SPI clerk for four years becoming a CU (three years as a non-admin) and especially enjoyed the problem-solving nature of the role.This page also documents some useful advice for prospective clerks.
Is there a guide to initiating SPI cases? I have been trying to find proof that a certain account is a sock, but I have not been able to pin it clearly to anyone, and obviously cant indicate who I am referring to. I am not sure I am qualified for clerking, but if I had more experience in this sector, I am sure that would help. ←Metallurgist (talk)03:45, 16 November 2025 (UTC)[reply]
What I can say without dumping too many beans all over the place is that most people are really not very good at socking, and the ones who suck at it keep getting caught, so most socks you deal with around here are repeat offenders who do the same dumb shit over and over again. So in general what you end up looking for is a) something dumb the suspected sock did, and then b) someone who already did that dumb thing and got blocked for it. The cleverer ones last longer without getting caught, but they still tend to screw up at some point because their block-evadingWP:CLEANSTART isn't quite clean enough. Keep in mind that sockmasters are people who a) desperately want to edit and b) can't get unblocked for some reason. It's not a profile that lends itself to cleverness. The smart ones and the patient ones simply sweettalk an unblocks admin and go free. --asilvering (talk)06:42, 16 November 2025 (UTC)[reply]
Speaking as a person who has just started looking into this interesting behaviour relatively recently, doing some deep-sea diving and trawling, with regards to articles/topics/edits/syntax and general behaviour etc. Use excel or notepad to keep track and investigate like you're Columbo, or invetigate like you're Garth Keenan.Halbared (talk)21:29, 9 December 2025 (UTC)[reply]
Once you've finished reading all that you're probably not any closer to finding your master. If you are, do go ahead and file a report. If you aren't, send me an email with the suspicious account and as clear a description as you can of why it's bothering your sock senses, and I'll see what I can do. --asilvering (talk)05:09, 16 November 2025 (UTC)[reply]
@Asilvering Thanks I will start reading those. I did find WP:SIGNS, so good to know its a mess before I get started. I was actually thinking of asking you about this before I saw the post. ←Metallurgist (talk)06:20, 16 November 2025 (UTC)[reply]
I'veadded a |moot=yes argument to the{{SPI archive notice}} sandbox, whichsays to "avoid reporting accounts created by this sockmaster that are already blocked or locked if there is no suspicion of sleepers." This is mostly for the LTAs that create many throwaway accounts that are immediately blocked but then still reported, such asthe four cases here. Feel free to modify the wording. If there are no objections, I will add it to the main template next week.DatGuyTalkContribs20:26, 24 November 2025 (UTC)[reply]
if there is no suspicion of sleepers...: I do feel most people report blocked accounts solely to request a sleeper check, particularly in cases likeSalebot1 where these mass-created accounts are incubated and weaponized. What if the parameter also says something likeCheckUsers should run a scan on blocked accounts to discover potential sleepers?ChildrenWillListen (🐄 talk,🫘 contribs)20:51, 24 November 2025 (UTC)[reply]
I think most people report blocked accounts because they simply associate socks = SPI, but it's hard to determine that. As for sleeper checks, for the permission gamers it's trivial to be 30 days old, the difficulty is with the 500 edits. For theWP:LTA/ASPEs, the moot parameter shouldn't be added there. To be truthful I don't know how much utility the hundreds of checks spent on them even have on the encylopaedia, but I digress.DatGuyTalkContribs21:19, 24 November 2025 (UTC)[reply]
Never been in a cohort before. We'll need to come up with some really scary cohort name. I hear "Team Dragon" has a mixed rep...BusterD (talk)17:57, 8 December 2025 (UTC)[reply]
How about "Forces of Nature"? "octopus", "toad", and "pharyngeal" on the natural side; "buster" and "implosive" on the forceful side. Seems threatening enough for a clerk cohort, too. :PGiraffer (talk)18:52, 8 December 2025 (UTC)[reply]
New: Untriaged cases
More info needed: More info needed from the filer to ensure there are valid reasons to suspect sockpuppetry
Behavioral evidence needed: Cases needing behavioral analysis. Non-CUs can help out here by sleuthing around for evidence
Checkuser needed: Self-explanatory. If CUs fail to find anything useful, should be switched to the above state
Checkuser in progress: To avoid duplicating effort for some of the more difficult cases
Clerk assistance needed: if the CU is in a hurry and needs to perform case merges, blocks, G5 deletions, etc.
Closed
wikipedia.org within the next two weeks (by approximately November 25).