Wikipedia:Requests for checkuser/Clerks/Guide/Old1

Scope

The scope of the clerk position is to perform routine maintenance and summarizing of checkuser requests.

Clerks are:

Interested individuals who have volunteered to help keep RfCU clear, to expedite the processing of requests. Clerks do not have any special authority.

Clerks are not:

checkusers; they do not have access to the checkuser permission, or to any private information. They are also not reserve checkusers; checkuser is assigned by the Arbitration Committee at their discretion.
empowered to remove or deny requests. Clerks are empowered to remove long discussions and summarize posts, but must link to the full discussion in the history. They must leave the original request post, or if it has been shortened, a complete summary of the request with link.
request screeners: Clerks should not comment on the merits of any check, and should not offer opinions about the liklihood of a check being completed or declined. Clerks should also avoid requesting additional information; if a checkuser believes more information is needed in order to justify a check, they will request it. Clerks should remain impartial and neutral at all times.
professional checkuser enforcers. They may choose to act on reports, and are encouraged to do so, but individuals making requests should not expect that someone else will deal with the results. It is the responsibility of the individual making the request to see that the results are acted on.

Tasks

Clerks should:

Review requests in the request queue for clarity and completeness.

Review Wikipedia:Requests for checkuser/Clerks/Noticeboard for specific requests from checkusers for help or clarification, and to coordinate with other clerks.

Notify the individual making the request that additional information is needed when a request does not provide required information. This takes two forms:

When basic information is missing: which accounts should be checked, an explanation of the cause for suspecting sockpuppetry (only if there is no explanation; if one is provided, clerks should not make judgments on whether the explanation is sufficient). This is very important: Clerks should not decide for themselves whether a request is valid, or contains sufficient explanation; this is a checkuser task. Clerks should only request additional information if no information is provided (i.e., a request with nothing but usernames).
When a checkuser specifically requests more information.

Correct the basic formatting of requests; if the accounts to be checked have not all been listed in a bulleted list at the beginning of the request, or the {{checkuser}} and {{checkip}} templates have not been used, then the clerks should correct this. If a request has not been signed, they should add the {{unsigned}} template. If the wrong headers have been used == == instead of === ===, clerks should correct them.

Where a request is long, especially those that contain discussion or arguments, clerks should remove the material (preferably cutting everything after the first post), provide a link to the full version in the history, and summarize any important points (see examples).

When a checkuser has closed a request, either by declining or providing a result, it should be moved to the top of the correct section (complete or declined). If additional information is provided on a closed request, requiring further action from a checkuser, then the request should be moved back to the "Outstanding Requests" queue. When a request has been acted on, or is more than a week old, it should be archived off the main page into the archives.

To archive a closed request, add {{subst:Rfcua}} to the top of the request and {{subst:Rfcub}} to the bottom. Remove the subpage from the list on the main RFCU page and add it to the alphabetical list on Wikipedia:Requests for checkuser/Case. Be sure to list the names of alleged or proven sockpuppets as well, following the existing format.

Clerks should be careful to note their actions with {{Clerk-Note}} (an alternative is {{clerknote}} ), which will produce Clerk note:. This will serve as a public indicator that the action was a clerk action, and will be a signal to the checkuser that there is clerk activity going on. (Minor or "transparent" actions, like correcting the formatting, do not have to be noted on the main page; a comment in the edit summary is sufficient.)

Clerks must be very careful to avoid giving the impression that they are intermediaries between those making requests and the checkusers. Clerks should not express opinions on the merits of checks, and should remain mindful of the impression their clerk actions convey. It is imperative that the checkusers remain accessible to the community, and that clerks be recognized as neutral, unbiased parties who are assisting with maintenence work, not deciding the merits of requests.

Enforcement

Clerks who are also admins are not expected, but are invited, to enforce checkuser results. (That is, decide what to do with the users once the report has been made.) Other admins, particularly those who are not serving as clerks, are strongly encouraged to watch RfCU and act on requests that have been completed. Additionally, admins are needed to watch RfCU and the talk pages of checkusers (and possibly clerks, if it becomes a problem) for disruptive users acting in retaliation. (Having to deal with the disruptive user provides a conflict of interest when checking, and the need for such intervention is frequent enough to make individual reports impractical.) If there is interest, a subpage "noticeboard" for checks requiring enforcement can be organized.

Another Task Summary

(I wrote this for a prospective clerk and I think it has some useful explanations Thatcher131 (talk) 01:46, 1 August 2006 (UTC))[reply]

At the listing stage, check that the subpage is transcluded properly, that the {{checkip}} and {{checkuser}} templates are used, and fix any other formatting problems. Some cases get created under the wrong name and need to be moved (from Wikipedia:Requests for checkuser/Lightbringer to Wikipidia:Requests for checkuser/Case/Lightbringer, for example). The new subpage template includes a tag reminding users to list the page for transclusion; this tag also contains Category:Checkuser requests to be listed. The tag can be removed once the page is listed if the user doesn't do it themselves. Clerks can check the category to see if any cases were created but not listed properly.

At your discretion, you may want to ask a question to help the requester format their request better, or add a comment to provide some piece of information that might be useful to the checkusers (for example, links to related cases, or to note when alleged sockpuppets have already been blocked). This is entirely optional and clerks should avoid giving the impression that they are acting to screen or pre-approve requests. Clerks also try to keep the arguing to a minimun. (I usually let the alleged sock make one statement in his/her own defense, but if it gets more conversational than that, I move the conversation to the talk page.)

After a request is answered, the case gets moved to the proper section (declined or completed). Clerks who are also administrators are invited, but not obligated, to issue warnings or blocks as appropriate, which may be especially helpful if the requester is not an admin. Cases are usually archived after 4 days, but may archived sooner if it is clear that the parties have seen the answer, or if there gets to be a lot of trolling on the page. The request gets enclosed with closing templates, removed from the CU page list, and added to the alphabetical list at WP:RFCU/Case, as described above. Current discussion and coordination is at Wikipedia:Requests for checkuser/Clerks/Noticeboard, and the archives have past discussions where the procedures were worked out.

Case indicator templates

Here is a table listing the various templates available to checkusers and clerks in formatting and answering requests.

Template	Makes
{{Confirmed}}	Confirmed
{{Confirmed-nc}}	Confirmed with respect to the named user(s). No comment with respect to IP address(es).
{{Likely}}	Likely
{{Possible}}	Possible
{{Inconclusive}}	Inconclusive
{{Unrelated}}	Unrelated
{{MoreInfo}}	Additional information needed
{{TakeNote}}	Note:
{{Declined}}	Declined
{{Fishing}}	CheckUser is not for fishing
{{Thrown out}}	Rejected
{{Crystalball}}	CheckUser is not a crystal ball
{{Clerk Request}}	Clerk assistance requested:
{{Clerk-Note}}	Clerk note: