Wikipedia:Requests for checkuser/Procedures

This page is primarily intended as a guide for checkuser clerks, but may also be useful for users curious or confused about the checkuser process.

Clerks

Checkuser clerks are experienced users who are available to assist with the formatting, filing, and archival of cases. The clerks are not mediators between users making requests and the checkusers, and (with the exception of #Non-compliant requests) should generally avoid commenting on the merits of any current, completed, or possible request. That said, questions about general process or the complicated maze of templates and subpages in the "checkuser namespace" can usually be handled by clerks.

Actions on request pages that go beyond general formatting should be tagged with {{clerknote}}, to make clear that the action is being performed by a clerk, and that clerking is going on.

There are no official requirements to become a clerk on any temporary or permanent basis, but users who clerk should be experienced, knowledgeable, and in good standing. Users should generally refrain from clerking cases with which they may be involved.

For more information, including a list of regularly active clerks and internal coordination, see Wikipedia:Requests for checkuser/Clerks or the clerk noticeboard.

Request pages

Listing stage

New requests should be included in Category:Checkuser requests to be listed, either by the templates {{checkuser requests to be listed}} or {{please don't edit this line (new rfcu case)}}, or manually. Once a request is made, it should be transcluded at the top of the main page's "Pending" section, and removed from the unlisted cases category.

The case should be named for the "sockpuppeteer" account (the oldest or most prominent), and should be located at Wikipedia:Requests for checkuser/Case/(sockpuppeteer). Common mistakes include naming a case for a sockpuppet, and creating a case named Foo 2 when Foo already exists. Cases can be moved and merged as needed to resolve this.

Users to be checked should be listed immediately below the section heading of the current request and {{rfcu box}} template, using {{checkuser}} for usernames and {{checkip}} for IP addresses.

A code letter should be provided, immediately below the list of users to be checked. Some code letters require specific information, possibly including links to diff evidence or closed arbitration cases -- where such evidence is explicitly requested by the provided code letter, but is omitted, the {{codeletter}} and {{moreinfo}} templates, as well as #Non-compliant requests process can be used, as appropriate.

Clerks should handle any general formatting issues, reformatting and refactoring as needed to ensure that the request's format conforms to current standards, that {{rfcu box}} is present and uses appropriate parameters (watch the case name, when moving pages), and should use {{unsigned}} for unsigned requests.

Intermission stage

Once a case is successfully listed as pending, and meets current formatting standards, it awaits a response from a checkuser. During this period, checkusers may request additional information (requests can be forwarded to the appropriate users by clerks), or may make other requests using the {{clerk request}} template.

Case subpages should not become arguments between accused users and applicants. Extensive discussion can be moved to the case's talk page or forwarded to the appropriate admin noticeboard. Any moving or refactoring of discussion in this case should be tagged with {{clerknote}} and should always provide a link to the new location.

Archival stage

Once a checkuser responds to a request, it should be moved to the appropriate section (depending on the indicator template used, either completed or declined). Transcluded case pages should be separated by horizontal rules (----). Resolved requests are generally archived three days after being completed, declined, or otherwise resolved. Depending on case load, this period can be adjusted slightly.

There are three steps to archiving a request:

At Wikipedia:Requests for checkuser/Case

• List the request using current format. The dates used represent the most recent checkuser finding on a case.

At the CheckUser Request Subpage

• If the to-be-archived request is the first at this page - add {{rfcua}} above the first line of the request, and {{rfcub}} below the last line.

• If the to-be-archived request is the second at this page - remove the previous {{rfcua}}, and place another one above the first line of the current request. The old {{rfcub}} should remain at the bottom of the page.

• If there are multiple requests at this page - combine the entire page into one shaded box by making sure that there is exactly one {{rfcua}} at the top line, and exactly one {{rfcub}} at the bottom line. Any duplicate templates should be removed.

---

• {{rfcu top}} and {{rfcu bottom}} are also shortcuts to the above-mentioned templates. Either is acceptable.

At the RFCU frontpage, et cetera

1. Remove any current transclusions of the to-be-archived case from checkuser pages.
2. In some cases, additional checks are requested after a checkuser response. In such cases, #Repeat requests may apply.

Special cases

IP check

• Wikipedia:Requests for checkuser/IP check is used to request that a checkuser identify and/or block the IP address(es) of a group of blatant vandal accounts where no registered user is acting as a puppeteer (i.e., code letter A). Requests for IP check do not need subpages, but should rather be created in page sections at the IP check page.
• Experienced users and clerks can move pages into or out of the IP check section as required.
• Following a checkuser response, the fulfilled Requests for IP check sections are archived to Wikipedia:Requests for checkuser/IP check/Archive. They can be deleted from that archive seven days after being moved into it.

Repeat requests

Further suspected sock puppets are frequently added to requests whilst they are still on Requests for CheckUser. Should this occur, users should select the appropriate section from below and fulfil its instructions, with assistance from Clerks and/or other experienced users:

If a checkuser has not yet responded

Simply add the names to the listing in the current request, with explanation as needed.

If a checkuser has responded, but the case has NOT yet been archived

Add the names below the current checkuser response. Avoid any possible ambiguity by making it clear that you are adding these names after the most recent checkuser response. Except in cases where a request becomes very long, a new section need not be created on the page. New sections, if needed in this circumstance, should be subsections of the current request.

If the prior request has been archived

Add an entirely new request above the most recent one, including users to be checked, code letter, section heading, rationale, and any other elements of current formatting standards as needed. Be sure to either include {{checkuser requests to be listed}} or list it as a pending case, yourself.

Outstanding requests for checkuser should be moved back to the pending section, and tagged with {{relisted}} if needed. General discussion need not require such a move: use your common sense.

Non-compliant requests

If a checkuser request does not meet specific guidelines, clerks or checkusers may remove it from the list of pending cases, and move it to Wikipedia:Requests for checkuser/Non-compliant. Clerks should use careful discretion when doing so, and should always provide a rationale for the move -- {{clerknote}}, {{delisted}}, and {{rfcu problem}} are all useful for this. Consider notifying the applicant of the move, and be prepared to provide assistance if they need it.

If a non-compliance issue is resolved, the case can be relisted as pending, and can be tagged with {{relisted}}. If the issue is not resolved within a reasonable period (usually, three to seven days), the case can be closed by a clerk and archived as normal -- note that this is the only circumstance in which a clerk may close a case without checkuser response.

Where problems with a request can be more easily or quickly resolved by other methods, including {{moreinfo}} requests, consider using those methods, first.

Requests may be non-compliant if they...

• Cite no code letter (or too many code letters)
• Do not include diffs explicitly requested by the code letter provided
• Do not list any accounts or IP addresses to be checked
• Are obviously and completely redundant to another current case (consider merging and/or redirecting, instead)

Enforcement

Typically, enforcement of policy (up to and including blocks for sockpuppetry) are the responsibility of the applicant. Applicants who are not administrators can forward requests to the admin noticeboard for enforcement, if needed. Clerks who are administators are invited, but not required, to assist with the enforcement of relevant policies.

Indicator templates

Below is a list of the case indicator templates used, their source code, and any notes associated with their usage. The table uses the abbreviation "UBCO" for space reasons, which means "Used by checkusers only".

Source code	Template	Notes
"Completed requests" templates
{{confirmed}}	Confirmed	UBCO
{{confirmed-nc}}	(See template page)	UBCO
{{likely}}	Likely	UBCO
{{possible}}	Possible	UBCO
{{unlikely}}	Unlikely	UBCO
{{inconclusive}}	Inconclusive	UBCO
{{unrelated}}	Unrelated	UBCO
{{IPblock}}	IP blocked	UBCO, mostly in "IP Check" section
"Declined requests" templates
{{declined}}	Declined	UBCO
{{unnecessary}}	Unnecessary	UBCO
{{thrown out}}	Rejected	UBCO
{{crystalball}}	CheckUser is not a crystal ball	UBCO
{{fishing}}	CheckUser is not for fishing	UBCO
{{StaleIP}}	Stale	UBCO, when a user or IP is too stale to check
Other templates
{{takenote}}	Note:	UBCO, Sometimes used by checkusers to annotate an unconventional result
{{clerknote}}	Clerk note:	See #Clerks.
{{moreinfo}}	Additional information needed	See #Listing stage and #Intermission stage.
{{clerk request}}	Clerk assistance requested:	UBCO, See #Intermission stage.
{{delisted}}	Delisted	See #Non-compliant requests.
{{relisted}}	Relisted	Can be used when moving cases back to the pending section of the main CU page.