Talk:CheckUser policy/Archive 6

Draft:CheckUser policy

Hi, @Arcticocean, GZWDer, Galahad, Goombiis, Faendalimas, Barkeep49, Ajraddatz, RoySmith, Martin Urbanec, Боки, and Jules*:

To conclude our previous discussions, I have rewritten the policy: Draft:CheckUser policy.

If there are any specific points that need to be discussed, such as clarifying formulations, adding, or removing content, I invite you to discuss them below. LD (talk) 16:02, 10 January 2025 (UTC)

I have only looked at changes to the community run body section. Did you make other changes? To that end, I'd prefer the Ombud note to use language more identical to what's on that page. So something like, "Note: The ombuds commission investigates complaints about infringements of the Privacy Policy, the Access to nonpublic personal data policy, and the CheckUser policy on any Wikimedia project." I also find the wording "When a community-run body can appoint users with CheckUser access, it must have at least two active members, elected by the community with at least 25 supporters and 70% of votes in favor, or the highest number of votes in multiple-choice elections, in order to appoint new users." confusing. I think "highest number of votes in multiple-choice elections" means the fact that enwiki ArbCom has as low as a 50% threshold is OK because it's a multiple choice election? But I admit I don't understand that term and I'm not sure what the or is doing there. Best, Barkeep49 (talk) 16:12, 10 January 2025 (UTC)

Please notice that some ArbCom (e.g. fawiki) can be elected using some sort of candidate election system such as Schulze method. In such system, there is no oppose vote at all so "support rate" is meaningless. So what I propose is we need at least two and at least 50% member that has 25 support votes, regardless number of opposes (as long as they can be elected per local policy). GZWDer (talk) 16:25, 10 January 2025 (UTC)

Speaking as an individual member of the community, my understanding of your intent here is to create a way for a nominating committee to be apppointed outside of an arbcom. You've made a lot of changes which are unrelated to that goal, while makes it much more difficult to understand the impact. My suggestion is to come up with the smallest possible change which lets you achieve your goal. RoySmith (talk) 16:29, 10 January 2025 (UTC)

I agree with @Barkeep49 on the sentence which is long and confusing. I would remove the whole paragraph and add two conditions in the previous section: only one community-run body per wiki allowed and at least two members. Goombiis (talk) 17:11, 10 January 2025 (UTC)

I'd keep the minimum 25 people voting in the election. Best, Barkeep49 (talk) 17:25, 10 January 2025 (UTC)

@Barkeep49 it is already written in the previous section of the proposed policy. Goombiis (talk) 17:28, 10 January 2025 (UTC)

But "Its members have been elected with the support of at least 25 members of the local community" is still ambigous for whether it applies to some or all ArbCom members. e.g. In 2019 the Czech ArbCom consists of two members with more than 25 supports and two members with less than 25 supports; the Finnish one have 10 members and only 2 have 25 supports. In my opinion the ArbCom should have at least two and 50% member with 25 supports - this will make the Czech ArbCom valid but Finnish one invalid. GZWDer (talk) 17:40, 10 January 2025 (UTC)

@GZWDer I get your point and I am not opposed to that evolution. But, on that point, this draft does not change what is currently in the Policy. Actually, we (the OC) could say that Czech and Finnish ArbComs don't comply with the current policy (if they elect CU). Goombiis (talk) 17:56, 10 January 2025 (UTC)

So the current de facto practice is all members must have 25 supports? GZWDer (talk) 17:58, 10 January 2025 (UTC)

I am not a native English speaker so I can make a mistake but for me "On wikis with an Arbitration Committee (ArbCom) whose members have been elected with the support of at least 25–30 members of the local community..." means that each member should have at least 25 pro votes. Goombiis (talk) 18:03, 10 January 2025 (UTC)

Note "Its members : Received at least 70% support in a pro/con vote..." but the required support rate in enwiki ArbCom is 50%. GZWDer (talk) 05:21, 11 January 2025 (UTC)

@GZWDer This part does not exist in the actual policy, so they can doo it like that. Goombiis (talk) 22:27, 11 January 2025 (UTC)

Note "So, a community-run body can't appoint its own members" is also against current practice - in English Wikipedia, all elected ArbCom members receives CU and OS and they can also keep them after departure. GZWDer (talk) 16:30, 10 January 2025 (UTC)

I think that's OK? Because ArbCom doesn't really appoint those people. The community is appointing them in the election. ArbCom files the paperwork but the appointment is the choice of the community not the choice of ArbCom. best, Barkeep49 (talk) 17:17, 10 January 2025 (UTC)

I think it is okay too. The sentence means that ArbCom members cannot elect on their own new ArbCom members, it should be done by community vote. Goombiis (talk) 17:20, 10 January 2025 (UTC)

I'll note there is a weird edge case around the U4C which could, if it wanted, grant itself CU, but that charter is a separate thing that has both community and board ratification and so probably not worth worrying about here. Best, Barkeep49 (talk) 17:24, 10 January 2025 (UTC)

OK, I have rewritten the discussed parts here. Such as:

• Note: The ombuds commission investigates complaints about infringements of the Privacy Policy, the Access to nonpublic personal data policy, and the CheckUser policy on any Wikimedia project
  • reviewed with ref/annotation: Note, however, that the Ombuds commission investigates complaints about infringements of the Privacy Policy, the Access to nonpublic personal data policy and this Global policy, on any Wikimedia project. They also investigate for the Board of Trustees the compliance of local CheckUser policies or guidelines with the global CheckUser.
• So, a community-run body can't appoint its own members
  • reviewed: Its members must not appoint themselves; they must be chosen through Direct Community Approval.
• For the Czech ArbCom and Finnish ArbCom, I have lowered the criteria for now (reviewed: At least two active members must meet the following criteria), but the current version of the CUP might imply all of the members. Which scenario is best for future appointments?

Note to @RoySmith, my goal is to review the policy as a whole, as the CUP is unclear. If needed, I can summarize the changes in a table, but the best way to compare remains to read both documents. LD (talk) 20:04, 10 January 2025 (UTC)

Doing it that risks the changes you really want (to allow frwiki to use its CU nomination committee) getting shot down because of other changes; for instance I notice you include activity requirements which were rejected last year (but which I support). Best, Barkeep49 (talk) 20:14, 10 January 2025 (UTC)

I'm not worried. This discussion aims to identify what we should improve or clarify in the entire policy. The community will notice it or ask for new changes if necessary, but we might still be able to validate some parts (we're not forced to submit it as a whole). Do you suggest 2 RFC: asking for comments then a validating one?

The Requests for comment/CheckUser activity RFC was about 5 checks during any 12-month period, which is different from not being active at all, as pointed out by NickK with the example: you can be active but have no checks to perform, which doesn't mean you should be revoked. LD (talk) 20:32, 10 January 2025 (UTC)

Under the policy, CUs are either appointed by arbcom or a community vote. The fact that arbcom hosts community consultations before appointing on enwiki doesn't make it a community process - at no point is there a vote with at least 25 supports and the required 70-80% support percent for non-arbcom CUs. – Ajraddatz (talk) 20:43, 10 January 2025 (UTC)

@Ajraddatz I don't understand what you are responding to. But it is not an issue what you are explaining. Goombiis (talk) 22:28, 10 January 2025 (UTC)

• Some concerns, focused on section 3 (CheckUser Access).

The proposal as written is quite convoluted, introducing concepts that need to be defined (valid community process, direct community approval, community-run body, trust and consensus, etc.) I think the section should be significantly simplified by removing those concepts and saying up-front what you mean.

How exactly is a community able to evaluate CheckUser actions? The community won't have access to the private data or logs necessary to do this. This is why it has always been the case that the appointing arbcom, other CUs and the OC provide the evaluation function.

The section on a valid community-led body is confusing and would exclude all arbcoms that currently do CU appointments. I see no reason why the committee could not appoint its own members. On enwiki, CU appointments are done entirely by arbcom (despite the "community process", arbcom remains responsible for appointment and removal and at no point do non-arbcom candidates need to get 25-30 supporting votes as required by policy for direct elections). Also, why is there no requirement that the community actually approve the scope of this body? It's so vague that I worry almost any community body that meets the membership requirements could be considered in-scope.

The removal of access section says access will be removed for abuse of the tool, without defining what that is, how it is evaluated, who is responsible for making the decision, etc.

Overall I think there are some good parts here but this misses the mark. I would highly recommend going with a simpler re-formulation of the current policy, like what I proposed at Special:Diff/23533419. – Ajraddatz (talk) 20:39, 10 January 2025 (UTC)

@Ajraddatz thanks for feedback.

• Main concepts are defined within the policy itself, such as those cited, and are mostly understandable by context (e.g., minimum criteria for consensus). I don't understand why you find these concepts unclear. Instead of removing concepts, which is the aim of the Policy (defining how these specific users might exist, behave, be appointed), I rather recommend to have a Definition section, even if I don't find it necessary.
• This draft does not state that the community needs to evaluate CheckUser actions. It states that the community must handle complaints, such as by referring them to the competent body (e.g., OC). It's not about rights; it's about not remaining inactive when an issue is raised. In the current version of the CUP, wikis can ignore issues. Solving that matter is the point, a valid point.
• I see no reason why the committee could not appoint its own members: There's a misunderstanding. It was reviewed in light of Its [community-run body] members must not appoint themselves; they must be chosen through Direct Community Approval. This means that community-run bodies (e.g., ArbCom) shouldn't be allowed to appoint members of community-run bodies, i.e., their 'own members', not community members, CU members, nor other community-run bodies. In other words, co-option is prohibited (since it could lead to abuse of power, privilege, or influence). This doesn't exclude any actual committee but could prevent certain forms of illegitimate appointments.
• I don't understand what you mean by Also, why is there no requirement that the community actually approve the scope of this body? The following sentence: The community may delegate the grant of CheckUser access to a legitimate community-run body (e.g., Arbitration Committee or Appointing Committee). Such a body must meet the criteria outlined in #Community-run body. clearly states that the community creates (and hence approves) the community-run body.
• The removal of access section says access will be removed for abuse of the tool, without defining what that is, how it is evaluated, who is responsible for making the decision, etc.: Fair point, CheckUser_policy#Removal_of_access doesn't define what constitutes abuse or misuse, except for in particular, if checks are done routinely on editors without a serious motive. The exact same sentence still appears in the draft (Draft:CheckUser_policy#Removal_of_access, 2nd paragraph). What do you propose to make this clearer?

LD (talk) 21:30, 10 January 2025 (UTC)

But why have those terms at all? Make the text considerably simpler without losing the meaning by just introducing those concepts in the original narrative, rather than creating terms that need to be defined elsewhere. Just have one section with a few paragraphs that addresses all of this. I think most of my other issues with the text are caused by the fact that it is trying to do so much, through so many different terms, that it isn't particularly readable and a lot of nuance is lost in the volume and jumping back/forth between sections. I'm also not super happy with the "community may delegate" text, would prefer a simpler statement that community consensus is required, but that's alright I suppose as is. – Ajraddatz (talk) 21:45, 10 January 2025 (UTC)

The document also outlines robust mechanisms for appointing and overseeing CheckUsers, including minimum support thresholds and activity requirements, ensuring that only qualified and active users are entrusted with this responsibility. By allowing local communities to set additional requirements within the framework of global standards, the policy demonstrates flexibility while maintaining consistency. Clear pathways for addressing complaints, whether through local bodies or the Ombuds Commission, add layers of accountability. The distinctions between handling privacy violations and other concerns are particularly useful in maintaining clarity. Provisions for automatic revocation of access in cases of inactivity or misuse further reinforce the importance of responsible usage.

However, there are areas where the draft could be improved. The language in some sections could be simplified for clarity, as phrases like “Confidential information may only be accidentally and implicitly disclosed” might confuse readers. Additionally, ambiguous terms such as “a valid reason is required to conduct an investigation” would benefit from examples or guidelines to provide clarity. Consistency in terminology is also important, as terms like “community-run body” and “relevant body” appear to be used interchangeably, which could create confusion. Moreover, while the policy mentions resources like mailing lists and IRC channels, it does not explicitly recommend mandatory training or onboarding sessions for new CheckUsers, which could be an essential step in ensuring they are well-prepared for their roles.

The overlap in authority between community-run bodies and the Ombuds Commission might lead to confusion regarding complaint resolution. Adding examples or a flowchart to illustrate the escalation process could help clarify roles and responsibilities. Transparency and trust could also be improved by including guidelines for periodic reporting of aggregated CheckUser activities without compromising privacy. Additionally, technical details such as placeholders like "⧼right-investigate⧽Question" need to be finalized to maintain professionalism in the document. Finally, to better support local communities, the policy could offer recommendations for adapting global standards to fit cultural and linguistic contexts while maintaining alignment with overarching principles.

Overall, this draft provides a strong foundation for the CheckUser policy by emphasizing privacy, accountability, and operational clarity. Refining the language, addressing ambiguities, and incorporating stronger provisions for training and transparency will further enhance its effectiveness and ensure alignment with the needs of diverse Wikimedia communities. For Serbian Wikipedia, a localized adaptation of this policy could help address community-specific requirements while staying true to the global framework. Proactively engaging the community in discussions and providing clear guidelines for complex cases will be crucial to fostering trust and ensuring successful implementation.

Боки ✉ 20:15, 11 January 2025 (UTC)

Regarding the 'investigate' flag, it is not included in the checkuser toolkit and this setting is not activated either. Best, Galahad (sasageyo!)^(esvoy) 21:54, 11 January 2025 (UTC)

A couple of points here to make. As most know I am a long term member of OC but my comments here are my own view in particular trying to look at the interaction of different policies.

One thing that is best avoided is repeating too much from other policies such as the Privacy Policy. That policy may evolve as the world changes and as such its best to just refer to the Privacy Policy as much as possible rather than state things from it. The reason is that if Privacy Policy evolves then the OC Policy must also be updated if you have essentially quoted it, rather than just refer readers to the Privacy Policy for explanations as much as possible.

A second point here and I do not think this needs to be addressed within the CU Policy, but a question do you envisage similar changes to the OS Policy regarding appointments? They are no doubt separate Policies but the methods of electing members are somewhat similar at present.

As you have taken efforts to inform of the CU-list and the IRC Channel it may also help to inform CU's they should also take note of this page on Meta in particular. I am aware of the language issues and I totally agree that better language options are needed on Policy pages and their talk pages when they are of such Global import. The language issue is beyond the scope here and I am hoping to improve this in the upcomming year. That said CU's should be watching the Global CU/OS Policy pages and their talk pages on Meta for announcements. They could also keep an eye on the OC Page as well for announcemnts.

Cheers Scott Thomson (Faendalimas) ^talk 02:05, 12 January 2025 (UTC)

I totally agree with the first two points of @Faendalimas. We should avoid repeating ourselves (leading to inconsistency). And similar changes should be applied to OS policy. Goombiis (talk) 12:17, 17 January 2025 (UTC)

Poorly written and confusing paragraph

The last paragraph of the “Use of the tool” section is poorly written and confusing. That paragraph ends with the phrase “… note, however, that requesting a CheckUser in these circumstances is sometimes part of the attempt to disrupt.” The paragraph goes from talking about how an editor might request the CheckUser tool be used to show that the editor isn’t a sock puppet and then, without any reference, it talks about “the attempt to disrupt”. What is meant here by “the attempt to disrupt”? I think the paragraph should be rewritten or at least clarified. Thanks. CarlStrokes (talk) 22:06, 26 May 2025 (UTC)