Misplaced Pages

This is an old revision of this page, as edited by HagermanBot (talk | contribs) at 13:47, 28 February 2007 (Radiant! didn't sign: "→Dealing with non-clerks: suggested paragraph, please reword as necessary, it's just meant as a friendly advice and nothing mandatory."). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

General notes and scope

• Clerks are interested individuals who have volunteered to help keep RFCU clear, to expedite the processing of requests.

• Clerks are not checkusers, nor reserve checkusers; they are also not requests screeners, meaning clerks should not give an opinion on how likely a case is to be accepted.

• 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 maintenance work, not deciding the merits of requests.

• Clerks are expected to maintain decorum appropriate to their position, given that they represent the checkuser body as assistants. See #Decorum section for more information.

• Clerks must be very careful to note their actions with {{clerknote}}. 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.

Tasks and procedures

Listing stage

This is the stage when cases have been just created.

• Ensure that the case is located correctly. This means that the case should be created at Misplaced Pages:Requests for checkuser/Case/(sockpuppeteer). Two common locations for miscreations are:-

• Misplaced Pages:Requests for checkuser/(sockpuppeteer) (Less common in recent days as a new page of that form will cause a big red warning to show up)
• Misplaced Pages:Requests for checkuser/Case/(sockpuppeteer) 2 etc. (generally occurs when a sockpuppeteer has had a case about them prior)

If either occurs, the options are either:-

• If the proper target for a case already exists (ie. for a previous request), the best option is to copy-and-paste the request on the "bad" pagename to the "good" pagename, indicating that you are doing a copy-and-paste move in the edit summary. Once you have copied it across, tag the "bad" page for speedy deletion using {{db-reason}}.
• If the "good" pagename doesn't exist, simply use the "Move" function to transfer it to the proper location, then tag the redirect left in the "bad" pagename with {{db-reason}} as above.

Make sure you notify the applicant of the move, giving a link to the new pagename.

• Ensure that the {{checkuser}} and {{checkip}} templates are used correctly in the top area of the request, and that the list of usernames is bulleted.

• Ensure a code letter is provided, or that "none applicable, see below" is clearly stated by the applicant. If it isn't, post {{codeletter}} on the talk page of the applicant (see template page for usage details). Annoate the request for checkuser with {{moreinfo}}, stating that you have requested a code letter, to avoid confusion/doubling up between clerks.

• Some code letters specifically ask for diffs and/or links to other material (eg. ArbCom decisions). See Template:Requests for checkuser header for the list (which is transcluded onto the main RFCU page). If diffs are explicitly requested, and they are not given, add {{diffneeded}} on the talk page of the applicant (see template page for usage details). Annotate as per above.

• Once the page has been successfully listed at Misplaced Pages:Requests for checkuser/Pending, remove the category "Checkuser cases to be listed" from the page if it's still there - note, EssjayBot II lists cases, so there is no need to do this by hand; however, if the category is accidentally removed by the creator prior to EssjayBot II's refresh, it won't be listed.

• Fix other general formatting problems, including how diffs are added (RFCU prefers rather than http://www.example.org). Also used {{unsigned}} for requests which aren't signed, and remove any unneeded bolding etc.

Intermission stage

This is the stage when cases have been successfully listed (see above), but are waiting a checkuser to act on. Cases in this stage are located in Misplaced Pages:Requests for checkuser/Pending, which is transcluded to be the "Oustanding requests" section on the main RFCU page.

• Watch for checkusers requesting more information. If they do, follow the procedures in the above section regarding {{codeletter}} and {{diffneeded}}. If, somehow, both a code letter and diffs are requested, use {{codeletterdiff}} (see details on template page).

• Ensure that the requests don't become discussion/arguments between the accused and the applicant. Generally, let the accused respond with one comment. If then the applicant responds, remove both the initial response by the accused and the response by the applicant to the talk page, marking this by using "{{clerknote}} discussion moved to talk page" etc. under an appropriate header. Also, link to the talk page in the clerk note, to make naviagtion easier. Any further comments not made by checkusers/clerks should be moved there.

• Watch if checkusers request any other clerk assistance, which is generally marked by the {{clerk request}} template. Follow their requests and instructions to the best of your ability, and if applicable discuss at the noticeboard for assistance.

Answered/Archiving stage

This is the stage that begins when a checkuser case is answered.

• When it has been answered, move it to the appropriate section, as listed in the table in the #Indicator templates section. Cases are moved to the top of the section which the template relates to (see table), and separated by a horizontal line (----) from other cases in the section. Remember to remove the "pending" category from the case page, so the bot will not relist it on the pending page.

• It then sits on the main RFCU page for three days. After these three days, it can be archived. The steps of archiving are listed below.
  • Remove the transclusion from the main RFCU page.
  • When adding the archive templates, there are a number of possibilies:-
    • Where the to-be-archived request is the first made on that page: Place {{rfcua}} above the first line of the request, and {{rfcub}} below the last line.
    • Where the to-be-archived request is the second to be made on that page: Remove the top archiving formatting for the first request, leaving the bottom. Then add the {{rfcua}} (top) template above the first line of all the text. This will create one shaded box holding both requests.
    • Where the to-be-archived request is the third+ to be made on that page: In this situation, two possibilites can occur: the multiple requests haven't been archived as above (into one box), or they have been. If they have been merged into one box, simply remove the header code for the archive box that existed prior to the check, and then add {{rfcua}} above the first line of all text, creating one box. If it hasn't been placed in one box, do so using the procedure outlined in the bullet point above.
  • Add the listing to the archive directory, following the pre-existing format. The date we use is the one that the checkuser gave his/her findings. The list of alleged sockpuppets should not be Wikilinked, however appropriate use of the <tt> tags can occur when "bad letters" (eg. I l) are used in impostor accounts.

• A set of archiving/icon scripts can be found here.
• If, during the three days, a user presents more evidence etc. or requests a further check on more accounts, move the case back up to the pending queue, annotating your move with the {{clerknote}} template and a message. General trolling/dissent towards a checkuser decision does not require this move - use common sense.

Communication and co-ordination

Communication occurs through two main mediums: the clerk noticeboard, and IRC channel #wikipedia-checkuser-clerks on Freenode. Every clerk is expected to watchlist the former, and attend to any requests, either by checkusers or clerks, if possible. The IRC channel is generally populated by a small number of clerks, and often one or two checkusers. Every clerk is welcome, however not required nor expected, to be in the channel; that said, if you have access to IRC/Freenode, it would be great if you could idle in the channel, where you can be pinged if required.

Co-ordination is the duty of the Head Clerk, currently filled by Daniel.Bryant (talk). Although he still acts as a clerk, it is his duty to ensure that everything runs smoothly, and create contingency plans in the case of adversity/unique circumstances. It is also his job to mentor the new clerks which are added to the roster, and to run the clerk meetings (see below).

Clerk meetings will occur approximately once every three months (for a general meeting). Clerk meetings may also occur when needed, in times of adversity/unique circumstances, to help develop plans to resume the smooth running of RFCU. Although clerks are not explicitly required to attend, it would be greatly appreciated if you could. Notification/discussion on times will occur on the clerk noticeboard, and meetings will take place in #wikipedia-checkuser-clerks.

Dealing with non-clerks

Sooner or later you'll run into some user who is not a clerk editing the RFCU-related pages. In almost all cases these are well-meaning users just lending a hand. It is advisable to not send these users away with the message that non-clerk edits aren't welcome here; instead, tell them that the procedure is more complex than it seems at first sight, and point them to the instruction and sign-up pages if they're serious about wanting to help. If at that moment the RFCU process is not in need of more people helping out, you could suggest that they look over the backlogs instead. —The preceding unsigned comment was added by Radiant! (talk • contribs) 13:47, 28 February 2007 (UTC).

Enforcement

Clerks who are also administrators are invited, but not required to enforce checkuser results. Other administrators who are not clerks are also invited to partake in deciding how to deal with the users once the request has been answered.

If a clerk archives a page and notices that a request result hasn't been acted upon, they are invited to do so themselves if they are an administrator. If they aren't a sysop, or they aren't comfortable acting as an admin on the case, or for any other reason, feel free to either come to the IRC channel (if applicable, see above) or else request assistance by a clerk administrator (see list of clerks, admins annotated in "user rights" column), or any administrator. Still archive the request, following the steps outlined in the #Answered/Archiving stage section.

Decorum

All clerks are expected to maintain decorum appropriate to their position, given its' nature. This includes:-

• ...not commenting on the merits of any check, whether the discussion occurs on an RFCU case page, a user talk page, or any administrator noticeboard etc. This is to avoid giving the impression that clerks are intermediaries (see #General notes and scope).
• ...dealing with all their clerk duties professionally, and try to be polite even if the person you are dealing with is being a total dick.
• ...trying to avoid speculating on behalf of checkusers, including when questioned about the merits of a check by an applicant (see bullet point 1).

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
{{thrown out}}	Rejected	UBCO
{{crystalball}}	CheckUser is not a crystal ball	UBCO
{{fishing}}	CheckUser is not for fishing	UBCO
Other templates
{{takenote}}	Note:	UBCO, Sometimes used by checkusers to annotate an unconventional result
{{clerknote}}	Clerk note:	See #General notes and scope section, bullet point 5.
{{moreinfo}}	Additional information needed	See #Tasks and procedures section, sections 1 and 2, relevant bullet points.
{{clerk request}}	Clerk assistance requested:	UBCO, See #Intermission stage section, bullet point 3.