Wikipedia:Requests for checkuser/Procedures
historical reference. . Either the page is no longer relevant or consensus on its purpose has become unclear. To revive discussion, seek broader input via a forum such as the village pump |
Checkuser pages |
---|
Clerk pages |
Clerk Overview • Noticeboard • Procedures |
Shortcut |
This page can be quickly accessed through: WP:RFCU/C/P
|
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.
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 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 {{
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.
Case formatting
Except for #IP check requests (described below), requests should generally be formatted as followed:
- 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.
- 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.
- 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.
- Below the list of users, a code letter should be provided. Some code letters require specific evidence.
- 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.
Repeat requests
Counter to practice at
- 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.
IP check
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.
Case handling
Listing stage
New cases should be listed on the frontpage as promptly as possible. Clerks will want to check
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
Intermediate stage
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 {{
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 {{
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
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.
Archival stage
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 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.
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 list it in the non-compliant section. Clerks should use careful discretion when doing so, and should always provide a rationale for the move -- {{
If a non-compliance issue is resolved, the case can be relisted as pending, and can be tagged with {{
Where problems with a request can be more easily or quickly resolved by other methods, including {{
- 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 administrators 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}} | 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. |