User:Tiptoety/Checkuser clerks

After a community discussion, consensus has determined that it would be beneficial to the smooth operation of the process of identifying sock puppets, to merge both WP:SSP and WP:RFCU into a single streamlined process. This would avoid confusion among users requesting aid, by providing a "one-stop shop" for reporting socks (at present, sock puppets are handled using behavioural evidence at SSP, and technical evidence at RFCU). The merger would also reduce the workload of administrators and CheckUsers responding to those requests, by keeping everything "central" and on the one page.

Because this new process will be more complex than SSP and RFCU was, and because it will rely on a knowledgeable, trustworthy group of users to "flag" cases for CheckUser attention (as described in the instructions, it calls for a significantly more active and responsible role of the RFCU clerks. Therefore, it is proposed to follow the Arbitration Committee Clerks model in building a pool of users willing to clerk, including using the "clerks and trainee clerks" system. Users may serve as trainee clerks by requesting to do so from a current, experienced clerk, subject to the approval of enwiki CheckUsers (the agreement of the checkusers is assumed); becoming a full clerk will require direct CheckUser approval.

The role of clerks is (working together with the CheckUsers) to be the users responsible in the first instance for day to day running of the SSP functions, and management of SSP and its case sub-pages. As was the case with the old RFCU system, their main role will be to keep the process page "ticking over," and as easy to use by the CUs and filing editors as possible. They do not have access to personal or checkuser information, and are expected to remain impartial when taking clerk actions.

Clerks

CheckUser clerks will be called upon to ensure the smooth operation of the new SSP/RFCU page and, as outlined here, they will be responsible for:

• Flagging requests for CheckUser attention, either independently or by request from other users;
• Assistance with housekeeping tasks, including archiving, merging and formatting of cases;
• Ensuring that proper evidence is provided for CheckUser requests, and requesting such evidence be presented in such instances that it is not provided;
• Assisting with non-private, operational aspects of cases, as needed

In practice, any user will be able to request CheckUser, and clerks will endorse those requests or refer them back to traditional means for resolution. In either case, the request will be categorized and available, and a CheckUser request need not be endorsed in order to be run; clerks only flag these requests for attention or do not. Ultimate discretion remains solely with the CheckUsers.

While clerks will not be dealing with any private or sensitive information, the CheckUsers must be able to trust the knowledge and judgement of users flagging requests for their attention, and should not be made to feel that they must continually check over their work.

Trainee clerks

Most experienced editors may become a clerk, absent consensus expressed by the CUs to the contrary. Trainee clerks may exercise all of the above, except:

• Endorse or decline requests for CheckUser attention;
• Formally decide and close a case (the actual decision part as opposed to observations or archiving);
• Posting of formal SSP/CU notices other than as agreed.

Requirements/process for a clerk

Clerks should be:

• In good standing with the community as a whole;
• Knowledgeable of the privacy and CheckUser policies;
• Knowledgeable of sock puppetry policy, and familiar with relevant procedures;
• Trusted by the CheckUsers to flag requests for their attention;
• Possessed of good judgement, discretion and communication skills, mixed with common sense;
• Reasonably reachable and active.

The Checkusers themselves will decide who they trust with clerking responsibilities, and how many clerks to have.

A few last notes

• Clerks (whether or not administrators) have no special authority beyond that which the user usually has. However, users disrupting SSP against clerk requests are likely to be blocked, as they are hampering the maintenance of the page as an easy-to-use, organised resource.
• Clerks are in position to ensure the smooth operation of the SSP/RFCU process and should strive to be as helpful as possible.
• What small authority clerks have ends with the SSP/RFCU process; it is not a status symbol , and nor does it grant the clerk immunity with regard to consensus or other policies.
• Clerks have no access to private information.
• Clerks actions can be overturned by the community, and by any CheckUser.
• Administrators are not by default clerks, and must request clerkship via the usual means.