This page covers procedures related to processing requests for checkuser, and is primarily intended as a guide for checkuser clerks. It may be useful for other users curious or confused about the relevant process. This page is not a supplement to the checkuser policy itself; it describes only the processing of subpages, tangential to those requests.

Users submitting requests needn't worry too much about getting this perfect; the most important thing is getting the information down so that clerks and checkusers can respond to the request.

If you have questions or problems, consider asking for help at Wikipedia talk:Requests for checkuser.

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 are present for their assistance only; with the notable exception of #Non-compliant requests, clerks should generally avoid commenting on the merits (or lack of merits) of any current, completed, or possible request. Clerks are primarily valued for their expertise regarding the complicated maze of templates and subpages in the "checkuser namespace."

Actions on request pages which go beyond general formatting or other minor tweaks should be noted on the page with an appropriate template such as {{clerknote}} and a brief explanation, to make clear that the action is performed by a clerk and that clerking is going on. Specifically, merging or moving cases, moving or heavily refactoring comments, and marking a case non-compliant should be noted thus.

There are no official requirements to become a clerk on any temporary or permanent basis, but users who wish to clerk should be experienced, knowledgeable, and in good standing. New clerks are encouraged to keep an open mind and learn as they go.

Except for #IP check requests (described below), requests should generally be formatted as followed:

1. Each request should be topped with a ===third level=== heading, usually referencing the title of the subpage. More recently, these headings are usually piped links directly to the subpage. Repeat requests may have multiple third-level headings. Smaller headings may be used as needed, within requests. Larger headings should not be used.
2. Below its heading, each request should include the {{rfcu box}} template, with appropriate parameters. Note that the subpage name is a required parameter for this template.
3. Below the box template, a bulleted list of allegedly related accounts and IP addresses should be present, starting with the alleged master account. Use {{checkuser}} for accounts and {{checkip}} for IP addresses.
4. Below the list of users, a code letter should be provided. Some code letters require specific evidence.
5. Below the code letter, a brief summary and justification of the request should be provided. Supplementary evidence, requests, or discussion should go here.

Pages should be named for the alleged master account, and should be located at Wikipedia:Requests for checkuser/Case/CASENAME.

Counter to practice at WP:SSP, WP:AFD, and many other Wikipedia processes, we do not create a new page for repeat requests. Instead, refer to one of the following three scenarios:

If a checkuser has not yet responded to the current request

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

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

• Add the names below the current checkuser response, or otherwise make it clear that you're adding the names after a checkuser has already responded.
• New sections, if needed, should be subsections of the current request. Unless the request becomes very long, subsections generally are not required.
• If a request is currently listed as completed or declined, it may be necessary to {{relist}} it as pending. Use common sense.

If the prior request has been archived

• Add an entirely new section at the top of the subpage, including users to be checked, code letter, heading, rationale, and any other elements of a complete request.
• Be sure to include {{checkuser requests to be listed}} somewhere on the subpage, or list it yourself.

In a nutshell: while a request is still open, add to the bottom of it; once a request is archived, it's usually better to create a new request above it.

Located at Wikipedia:Requests for checkuser/IP check, this subpage is used when the "master" account is unknown or irrelevant -- the primary focus here is on listing blatant vandal or attack accounts so that underlying IP addresses (sometimes including open proxies or address ranges) can be investigated for possible blocking.

Unlike other request types, IP checks do not require individual subpages, and are instead created as sections of the IP check page itself.

Archival of IP checks is also a special case. These requests are archived immediately after their conclusion, and remain on Wikipedia:Requests for checkuser/IP check/Archive for seven days before being removed completely. The only enduring record here is page history.

New cases should be listed on the frontpage as promptly as possible. Clerks will want to check Category:Checkuser requests to be listed on a regular basis (note the category is mainly populated by {{checkuser requests to be listed}} and {{please don't edit this line (new rfcu case)}}). Generally cases will be listed in the pending section; if the case is non-compliant, it may instead be listed in the non-compliant section; if a checkuser has already responded, it may instead be listed as completed or declined, as appropriate. Once transcluded onto the front page, a case should be removed from the unlisted category.

At this point, clerks should fix any formatting or naming issues present to the best of their abilities, refactoring, reformatting, moving, and merging content as needed to maintain current standards. Try to avoid any substantial change in meaning, and be sure to note any significant changes on the case subpage.

Note that certain code letters require specific information, possibly including links to diff evidence or closed arbitration cases; where such information is explicitly requested (either by a code letter or a checkuser), but is omitted, clerks may notify users of this with the {{codeletter}} or {{moreinfo}} templates.

Once a case is successfully listed as pending and meets current formatting standards, it awaits checkuser response.

During this period, checkusers may request additional information or assistance (common examples include summarizing lengthy requests, merging redundant cases, or requests for additional information); be on the look-out for {{moreinfo}} and {{clerk request}} templates. Clerks may handle such requests themselves, or forward them to the users in question, as appropriate.

The case is considered pending until it receives a response from a checkuser which includes one of the indicator templates listed below. Once such an indicator is provided, the case should be listed as completed or declined, depending on the specific indicator used. If a follow-up request for checkuser is posted, clerks may {{relist}} the page as pending (note that general comments need not lead to relisting, only requests for further CU investigation).

Note in particular that 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 comments in this case should be noted with {{clerknote}} and should always include a link to the new location.

Once completed or declined, a checkuser request will be listed for a time prior to its eventual archival. This allows users to check the results, sometimes resulting in blocks or other policy enforcement, and to submit follow-up requests if needed.

If they are no longer pending, requests are generally archived three days after the most recent checkuser response. Depending on case load, this period may sometimes be adjusted slightly. Note that completed and declined cases are all archived identically.

While archiving a request, at least three pages will need to be edited:

At the case archive, Wikipedia:Requests for checkuser/Case

• List the request in the appropriate section, using the current format. Dates listed represent the most recent CU finding on a case.
• Specific information needed includes the case name, date of last response, and a list of alleged sockpuppets.

At the case subpage, such as Wikipedia:Requests for checkuser/Case/Example

• The subpage should contain exactly one {{subst:rfcu top}} (at the very top, above any current text or section headings) and exactly one {{subst:rfcu bottom}} (at the very bottom).
• For first-time cases, this means you'll need to place both templates; for older, repeat cases, you may need to remove old archival templates.
• {{subst:rfcua}} and {{subst:rfcub}} also work as aliases for the top/bottom templates. They are functionally identical, so use whichever is easier for you.
• Remember to subst. It really is important.

At the frontpage, Wikipedia:Requests for checkuser

• Remove any current transclusions of the to-be-archived case from the frontpage.

If a checkuser request does not meet specific guidelines, clerks or checkusers may remove it from the list of pending cases and list it in the non-compliant section. 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 and archived by a clerk -- 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)

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 administrators are invited, but not required, to assist with the enforcement of relevant policies.

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.