Talk:CheckUser policy

Archives Proposition 2005 (November 2005) Archive 1 (Prior to June 2005) Archive 2 (Prior to January 2006) Archive 3 (Prior to April 2008) Archive 4 Archive 5

Clarification on what Checkusers are allowed to do

Hello, is it allowed as a Checkuser, to use the Checkuser tooling for getting the IP address of a blocked account, and then block this IP address as well? I'm not talking about autoblock, but a Checkuser actually imposing a manual block of this IP address such that the IP address blocked becomes visible in the log files of blocked users. The fact that the IP address was blocked without any edits, the time it was blocked, the Checkuser who blocked it and the blocking reason could users who watch the log files lead to the conclusion which (recently blocked) account might be behind the IP address. Is this allowed or is this a violation of the Checkuser policy? Temp account II (talk) 09:00, 8 October 2023 (UTC)

Concerns about the Ombuds Commission's decision: is the French Committee community- and legally valid?

See Talk:CheckUser policy#Notification of upcoming changes to policy and Talk:Ombuds commission#French Wikipedia Nominations Committee

• Key Policies:
  • Confidentiality Agreement for Nonpublic Information (wmf:Legal:Wikimedia Foundation Confidentiality Agreement for Nonpublic Information)
    • Defines "Authorized community members" as users entrusted through a valid community- or foundation-run process with access to (...) Authorized Wikimedia community members may include, for example, oversighters, checkusers, volunteer developers, and other similar authorized roles."
  • Access to Nonpublic Personal Data Policy (wmf:Policy:Wikimedia Foundation Access to Nonpublic Personal Data Policy)
    • Outlines 5 minimum requirements for designated community members seeking access rights (see section).
  • Privacy Policy (wmf:Policy:Privacy policy#To Protect You,Ourselves& Others)
    • Highlights the community's role in selecting trusted users for administrative rights, emphasizing accountability and adherence to nonpublic data policies.
    • Excerpt: "Users are selected through a community-driven process and overseen by their peers through a logged history of their actions."
• French Wikipedia Nomination Committee (Comité de nomination):
  • is a valid, transparent and rigorous community process:
    • Established through a valid community decision (fr:Wikipédia:Prise de décision/Méthode de nomination des CU et OS).
    • Members are elected (fr:Catégorie:Wikipédia:Élection nominateur close) based on stringent criteria:
      • Minimum 25–30 participants in elections (which is the requirement for ArbCom members)
      • At least 70–80% support in pro/con votes or the highest votes in multiple-choice elections (fr:Wikipédia:Comité de nomination/Règlement#Alinéa 2 : élections ; which is a requirement for election, it's more restrictive than minimum requirements for ArbComs)
    • Eligibility Requirements for Members
      • Accounts must have a minimum of 5,000 edits and be at least 3 years old. This exceeds global requirements (e.g., wmf:Policy:Wikimedia Access to Temporary Account IP Addresses Policy#Patrollers and other users, which require only 300 edits and 6 months of account age)
    • Threshold for voters:
      • Accounts must have a minimum of 500 edits in main namespace and be at least 6 months old. This is similar to global requirements for voters (e.g., Stewards/Elections 2024/Guidelines).
  • has responsibilities:
    • Grants and revokes CU/OS rights.
    • Operates with a quorum of 5 members (fr:Wikipédia:Comité de nomination/Règlement#Alinéa 2 : élections).
    • Can be solicited in case of abuse (see fr:WP:CUABUS or wikipedia-fr-comite-nominationlists.wikimedia.org)
• Challenges with ArbCom definition:
  • The concept was introduced in 2005 (revision)
  • It remains inconsistently defined by meta community in CU/OS Policy
  • Arbitration Committee's page is not a global policy
  • Community discussions have failed to establish a clear global definition, e.g:
    • Talk:CheckUser policy/Archive 2#What is an arbitration committee?
    • Talk:CheckUser policy/Archive 3#What is "a wiki with a (Wikimedia-approved) Arbitration Committee (ArbCom)"?
    • Talk:CheckUser policy/Archive 3#Finnish Wikipedia and ArbCom
    • Talk:CheckUser policy/Archive 4#Arbcoms vs. elections for CUs
    • Talk:CheckUser policy/Archive 4#Appointed by ArbCom or elected?
    • Talk:CheckUser policy/Archive 4#Contradiction
    • Requests for comment/Amendment of CheckUser policy and Oversight policy
  • Implications:
    • The CU policy does not provide a definitive framework for what constitutes a valid ArbCom, nor a valid community process (see above: Key Policies)
    • Discussions highlight contradictions and regional variations in implementation (de, nl, en wikinews, fr, ...).
• Bias concerns about ArbCom:
  • As pointed out in this section: most members of the Ombuds Commission and WMF staff come from wikis where an Arbitration Committee exists, named under "Arbitration Committee". However, many wikis do not have an Arbitration Committee, or have a different separation of powers: French Wikipedia, de facto, has split Arbitration Committee: conflict resolution is handled by admins, while CU/OS granting and abuse concerns are managed by the Nomination Committee.
  • The definition of an Arbitration Committee is culturally related, whereas it should be policy-related, which is not yet the case in CU/OS Policies.

Overall arguments supporting the validity of the Nomination Committee:

• Nomination Committeemeets and exceeds requirements:
  • The election process and eligibility criteria on French Wikipedia are more stringent than global standards, fully meeting and exceeding the Wikimedia Foundation's (WMF) legal minimum requirements.
  • It combines both the restrictions inherent to an Arbitration Committee and those of an electoral system. Its practices align with the intent of WMF and CU/OS policies.
• The Ombuds Commission's role is limited:
  • The Ombuds Commission ensures compliance with policies and investigates abuses but should not define the concept of an ArbCom or valid community processes.
  • The assertion that "the current practice on French WP is neither" lacks justification without a clear definition of ArbCom within the CU/OS policy.
• WMF can validate or unvalidate the Nomination Committee:
  • If WMF (@Kbrown (WMF)) considers the Nomination Committee invalid, it should specify which criteria are unmet under the Legal Policies. In the absence of such clarification, the Nomination Committee should be deemed valid.
• Community should prevail
  • Trusted roles should be determined by communities through transparent and rigorous processes. Unless legal issues, objections, or dysfunctions arise, the principle of "if it's not broken, don't fix it" should apply.
• Global consensus is implicit
  • Since its establishment in 2020, the Nomination Committee has effectively functioned as a valid ArbCom or community process.
  • As its practices align with the intent of WMF and CU/OS policies (which aim to entrust users with privileged tools), it demonstrates its legitimacy in continuing to do so.

Therefore, the community must decide whether, under our policies:

• The Nomination Committee is valid, based on the arguments outlined above
• The Nomination Committee is not valid, if these arguments are not supported

LD (talk) 10:44, 20 December 2024 (UTC)

---

•  Support LD (talk) 10:45, 20 December 2024 (UTC)

  @LD Support what? :-)

  The current policy is very clear in only allowing Arbitration Committees to make appointments. The term Arbitration Committee is fairly clearly defined as well, cf. Arbitration Committee. French Wikipedia even used to have one – the Comité d'arbitrage, and it is clear that Comité d'arbitrage and the Nomination Committee are two separate committees. If you want a more formal source, Terms of Use and its description of ArbComs as "dispute resolution bodies that are established by the community for the specific Project editions" might be helpful.

  On the other hand, while interpreting policies, one must always consider the policymaker's intent, rather than just the text of the policy itself. If the text and the intent differs, the intent should prevail. In this case, the intent is to allow sensitive access (to CU/OS) to be managed by a group of people who have the ability to see what is happening, even if it includes private data. That gives that group of people a better position to make decisions, as they are eligible to see everything that might be relevant (while the general community cannot see those details).

  As it stands now, the Nomination Committee goes against the writing of the policy, but it follows the intent. Such situations are far from ideal, especially if they are supposed to be the norm. Even though the intent usually prevails over the letter, it easily starts lengthy discussions (like this one), where energy is spent by many people, while the same energy could be better used elsewhere. For that reason, situations of "ignores-letter-follows-intent" are generally only acceptable as oneoffs, where actually amending the policy would take far more energy and effort compared to going against the letter once.

  Since the French Wikipedia intends on using the Nomination Committee, it would be ideal to amend the CU policy to allow for that. There are many useful drafts and notes in the discussion you linked (as well as in the relevant CU-l conversations). Instead of discussing whether Nomination Committee could be allowed to operate under the current policy, can we talk about a CU policy change proposal that would make it more clear who can appoint CUs and who cannot? Martin Urbanec (talk) 13:19, 20 December 2024 (UTC)

  I agree with this. Instead of talking during weeks and weeks on definitions, a "simple" CU/OS policies revamp should be launched. Goombiis (talk) 13:29, 20 December 2024 (UTC)

  Thank you for your response, @Martin Urbanec. I’m a bit unclear about a few points:

  • Why should a "dispute resolution body" handle OS/CU matters, and why is it considered more appropriate than an appointing committee?
  • Why isn’t the Nomination Committee (CNOM) — which isn't entirely separate from the Committee of Arbitration (CAr), as some of the CAr's powers were transferred to it—considered a "dispute resolution body"? After all, it oversees granting, revoking, and resolving disputes related to CU/OS. This aligns with both the current definition and the Terms of Use (ToU) definition.
  • It seems there might be a misunderstanding or misconception, possibly stemming from the Ombuds Commission (OC).

  I don't believe the current policy needs to change, as long as the global community remains the sole authority to validate a 'valid community process' and agrees on the legitimacy of CNOM. This is what I invite the global community to support: CNOM is fully aligned with the current policy, both in letter and in spirit. LD (talk) 13:30, 20 December 2024 (UTC)

  Re first question) The policy is written as it is for mostly historical reason (and the enwiki example). A broader definition would definitely be reasonable, and I'd support a policy amendment that would go in that direction.

  Re second question) Because it is not a dispute resolution body, that is not the Nomination Committee's purpose. Just because someone/something does a small bit of dispute resolution doesn't make that someone a dispute resolution body. Otherwise, we could also call VRT agents a dispute resolution body, as they resolve disputes with the public. That said, do we really need to spend time on discussing this? Wouldn't it be more appropriate to clarify the policy in a way that makes it clear fr.wikipedia's way is okay? I think that would save us a ton of time.

  I do believe the change to the policy is needed, as this is not the first time a discussion like this happens (specifically involving fr.wikipedia). A policy amendment could make things clear to everyone, and we would be able to skip those discussions once and for all. That seems like a clear benefit :). ---Martin Urbanec (talk) 14:29, 20 December 2024 (UTC)

  I rather agree with you, Martin Urbanec, on the fact that what is an ArbCom is "fairly clearly defined". But be aware that what Faendalimas replied to us on fr-wp Village Pump about this was rather confusing, as he said that Cnom could be considered as an ArbCom, regarding the CU/OS nominations, even without any arbitration activity...

  
  

  I also agree that "while interpreting policies, one must always consider the policymaker's intent, rather than just the text of the policy itself", and that is not what the OC does here.
  

  In this case, the intent is to allow sensitive access (to CU/OS) to be managed by a group of people who have the ability to see what is happening, even if it includes private data.

• That is not what the OC decision says, and Faendalimas explicitly said it was not the reason for the OC decision:

  I also said that this was not part of the consideration of the OC in this case. There are 12 ArbComs world wide and not all have this ability it is no problem. If they cannot do this themselves because they do not have the ability then it is done by the Stewards and OC.

• Moreover, if that was the problem, the solution should not be those which were proposed to us, but: give Cnom access to private data.

  
  To decide what we should do, having a real and clear explanation of the nature of the problem is needed. It is not the case currently. And the lack of communication since at least 2022 from the OC and the contradictory replies do not help.

  Best, — Jules* ^talk 13:42, 20 December 2024 (UTC)

  @Jules*: I think I described the problem above :). In my opinion, the problem is that it is apparently unclear whether NomComs can exist (and if so, under which conditions). Dozens of pages were written on that topic, but it is still causing discussions. Resolving this uncertainty by a policy amendment seems to be a solution to that problem. --Martin Urbanec (talk) 14:32, 20 December 2024 (UTC)

  "In my opinion, the problem is that it is apparently unclear whether NomComs can exist (and if so, under which conditions)." Yes, obviously, but the question is why. And you described what you understand the problem is and you may be right!, but you are not from the OC and there is no consistency between the different explanations we received about the why, as of now. To be sure if we need to amend the policies and how, we must know if the problem is:

  • the Cnom not having access to private data;
  • the Cnom not having a conflict resolution activity;
  • having both an ArbCom and a Cnom;
  • ...

  That is not clear. — Jules* ^talk 14:41, 20 December 2024 (UTC)

  I'm not from the OC, but I am one of the people responsible for deciding on CU/OS permission requests, and I am saying that from that perspective, the fact the policy asks for direct election or an ArbCom appointment (neither of which the frwiki NomCom meets) is problem in itself (regardless of whether there is an ArbCom, whether NomCom has conflict resolution activity and regardless of whether it has private data access). This problem can be resolved independently by amending the policy. Then, we can discuss what should be the requirements. Once that is decided, we can return to frwiki NomCom and determine whether it meets what we agreed on (and if not, it would need to change how it operates). Martin Urbanec (talk) 23:45, 20 December 2024 (UTC)

Local policy cannot override global policy. Consequently, the presence of a CNom is only feasible if it is indicated as part of the Arbcom. The OC is interpreting global policy and recommending actions accordingly, with the intention of updating the CheckUsers/Oversights policy, which is currently outdated and may not accurately reflect the present situation. Instead of focusing our energies on critiquing the OC, we could redirect our efforts towards developing processes that involve modifying the policies that permit communities to establish bodies responsible for appointing such officials, as well as for revoking them if necessary. Meanwhile, it is important to recognize that policy specifies that only the Arbcom holds that authority, and the definition of the Arbcom has historically been consistent with that used by the global community. Best, Galahad (sasageyo!)^(esvoy) 13:57, 20 December 2024 (UTC)

Then, the process should not have been to not inform fr-wp community for two years to, in the end, ask it to change a process Legal did validate in 2020 and the OC was informed about in 2020.

I agree that those policies need a rework, but it's a bit easy to ask us to be focus our energy on something constructive when, precisely, the energy and the time we spent in 2020, alongside the effort to communicate with both Legal and the OC, are not respected nor aknowledged.

This is not a proper way to work between volunteers of several wikis, in an horizontal movement such as the Wikimedia movement, and it is not OK that the fr-wp community was not informed before.

Local policy cannot override global policy.

It does not. — Jules* ^talk 14:49, 20 December 2024 (UTC)

It seems that it might have been beneficial to address this issue sooner and to engage with the affected community prior to making any recommendations. Alternatively, it's possible that the affected community could have reached out to the OC for guidance, though I don't recall the specifics of that situation. I understand that a user did request a review of the compatibility of the designation method with the current policy. Nonetheless, I'm confident that we can take this as a learning opportunity and work towards preventing similar situations in the future. Best, Galahad (sasageyo!)^(esvoy) 15:02, 20 December 2024 (UTC)

Thanks. (And yes: the user was me; the exchanges were in Dec. 2019-March 2020 with Legal and the OC, even if the OC quickly requested to not be part of the exchanges.) — Jules* ^talk 15:30, 20 December 2024 (UTC)

Proposals by LD

Current version

Current CU policy

text

Appointing local CheckUsers On any wiki, there must be at least two users with CheckUser status, or none at all. This is so that they can mutually control and confirm their actions. In the case where only one CheckUser is left on a wiki (when the only other one retires, or is removed), the community must appoint a new CheckUser immediately (so that the number of CheckUsers is at least two). 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, CheckUsers may be directly appointed by the Arbitrators. After agreement, a member of the Committee should simply list the candidate on Steward requests/Permissions. On a wiki without an Arbitration Committee that meets the criterion above, or in a project where there is a preference for independent elections, the community may approve local CheckUsers (stewards not counting as local CheckUsers) per consensus. The candidate must request the CheckUser status within the local community and advertise this request properly (village pump, mailing list when available, special request page, etc.). The candidate must be familiar with the privacy policy. After gaining consensus (at least 70%–80% in pro/con voting or the highest number of votes in multiple choice elections) in the local community, and with at least 25–30 editors' approval, the successful candidate should request access at Steward requests/Permissions with a link to the page with the community's decision. If there are an insufficient number of votes for at least two CheckUsers on a wiki, there will be no CheckUsers on that wiki.

Proposal

Main proposal

Proposal of the new CU policy

text

Appointing local CheckUsers access CheckUser access may only be granted to users appointed through a valid community process. A community process is considered valid if it meets all of the following global community-set requirements: Compliance with other requirements: While local communities may establish additional requirements to complement the global community-set standards, WMF-set requirements, or other Wikimedia Foundation policies, these additional requirements must not override or conflict with them. There must be at least two local users with CheckUser access per wiki, or not at all: The community must ensure that the wiki has at least two local users with CheckUser access to oversee and verify each other's actions. The community must ensure that CheckUser access are granted only to trusted users with broad consensus. The candidate must request CheckUser access within the local community and advertise this request appropriately (e.g., village pump, mailing list when available, special request page, etc.). Approaches to establish Trust and Consensus: Direct Community Approval: The community may grant CheckUser access to users through a consensus-based process. To ensure its legitimacy, the process must meet the following requirements: At least 70%–80% support in a pro/con vote or winning the majority of votes in a multiple-choice election. A minimum of 25–30 supporting votes from community members. The community has the authority to handle complaints regarding misuse of the tool and may revoke CheckUser access if necessary. Community-run body: The community may delegate the grant of CheckUser access to a legitimate community-run body (e.g., Arbitration Committee or Appointing Committee). Such a community-run body must meet the following conditions to be considered legitimate: The community-run body is active and has the authority to handle complaints regarding misuse of the tool and may revoke CheckUser access if necessary. Its members have been elected with the support of at least 25–30 members of the local community. Meta Community Discussion: Other forms may be discussed and validated within the Meta community to ensure there are no objections regarding the local consensual process. After gaining consensus, the successful candidate - or the community-run body - should request access at Steward requests/Permissions, providing a link to the page documenting the consensus. An appointment cannot take place if, at the end of the process, fewer than two users with CheckUser access remain.

About different CheckUser roles and conflict of interest

About different CheckUser roles and conflict of interest

text

rationale

While CheckUser access allows a trusted user to investigate, review tool logs, or access a private wiki, a community can appoint different types of CheckUser roles, provided the guidelines outlined in the Appointing Local CheckUser Access section are respected, particularly regarding conflicts of interest. For example, CheckUsers ('investigators') are responsible for preventing damage to Wikimedia projects, while members of community-run bodies (e.g., arbitrators from English Wikipedia ArbCom) may be tasked with overseeing the actions of CheckUsers 'investigators' to ensure they do not misuse their tools. This arrangement is permissible as long as the roles remain sufficiently distinct to prevent conflicts of interest or misuse of privileges in judging complaints fairly. Therefore, community-run bodies with CheckUser access should not include individuals who also act as CheckUser investigators.

The rationale behind this separation of powers is to maintain impartiality and prevent potential misuse of access. By ensuring a clear division between those with access to sensitive data and those responsible for oversight or dispute resolution, the community can uphold trust and accountability. It highlights that communities can grant community-run bodies CheckUser access, provided some guilines such as wmf:Policy:Universal Code of Conduct#3.2 – Abuse of power, privilege, or influence are respected.

What's new? Why?

What's new? Why?

idea	rationale
Emphasis on Legal and Privacy Requirements	This role involves legal considerations. The proposal emphasizes that a valid community process must align with Wikimedia Foundation's policies, such as the Policy on Access to Nonpublic Personal Data.
Clearer definition of the Appointment Process	The process must be consensual. Introduces the option for validating the local process through the Meta community to avoid objections, ensuring a more widespread check on the process.
Clarification on Roles and Revocation	Specifies that the community must have the authority to handle complaints about misuse of CheckUser tools and can revoke CheckUser rights if necessary.
Valid Process	A valid process is primarily defined by its legitimacy within the local community, openness to global scrutiny, and its ability to manage complaints and revocations.

Comments

General comments

This proposition seems great, it keeps all the conditions and alternative but removing the ArbCom mention to a more general name. The same find should be done for the section "Removal of access" --Goombiis (talk) 15:08, 20 December 2024 (UTC)

(ce) The proposal is intriguing, and I would like to...

...suggest a rephrasing of "Committee Appointment" to "Community-run body" This change could help clarify that a volunteer body—such as the "Commission of CheckUsers and Oversights"—falls within the guidelines established by the policy.

Since the ArbCom is indeed a Community-run body, it may also be beneficial to mention that "The Arbitration Committee can appoint or revoke the holders of the CheckUser and Oversight flags" in this section.

By making these adjustments, we could potentially streamline our discussions and eliminate the need for the third suggestion, simplifying things as long as new volunteer bodies meet the established requirements. This could help us reduce some of the bureaucracy involved.

Best, Galahad (sasageyo!)^(esvoy) 15:10, 20 December 2024 (UTC)

@Galahad I adjusted. This is the text for CU Policy, but I'll make the same proposal for OS Policy to highlight "can appoint or revoke the holders of OS rights".

In my opinion, a community could have a community-run body for OS and another for CU. A valid community-run body doesn't need to handle both per se, it just need to be trusted, active, etc. LD (talk) 15:22, 20 December 2024 (UTC)

I realize this is about modifying this policy, but since the CNom situation applies to both, my suggestion is relevant if we also choose to update the Oversight policy too. Best, Galahad (sasageyo!)^(esvoy) 15:28, 20 December 2024 (UTC)

I think it's great for frwiki to decide this for themselves, but I don't think it should be a requirement for any wiki looking to setup a nomination committee. I think each project should be able to make their own determination about whether or not checkusers could serve on a nomination committee. Best, Barkeep49 (talk) 01:28, 21 December 2024 (UTC)

@Barkeep49 Thank you for the feedback. The proposal outlines three "approaches to establish trust and consensus": direct community approval, community-run bodies, and other methods, provided a Meta community discussion is held to ensure there are no objections to the local consensual process. Each wiki can choose the option that best aligns with its local context —or even combine multiple methods, eg English Wikipedian processes for CU & ArbCom — as long as it adheres to the outlined principles of trust and consensus. The CU Policy continues to uphold the principle of self-governance. LD (talk) 09:46, 21 December 2024 (UTC)

@LD maybe I'm confused about what we're doing here. I thought we were approving a process for all wikis which might want to do community appointments. Are we instead approving a process for frwiki? Best, Barkeep49 (talk) 18:20, 21 December 2024 (UTC)

@Barkeep49:

It would be inaccurate to claim that I would make proposals if the situation on frwiki were less ambiguous and I were not serving as a frCU.

However, after reviewing the history of this page and related issues —some of which are only partially addressed— I strongly believe this policy should be improved to allow each wiki to express itself and propose solutions that work for everyone. LD (talk) 18:28, 21 December 2024 (UTC)

@LD:, I support what your trying to do here. Just remember this is a Global policy and must be applicable to any wiki with CU/OS including into the future. It should be light on certain specifics as that allows the local policy to deal with some issues according to their own preferences. Cheers Scott Thomson (Faendalimas) ^talk 18:35, 21 December 2024 (UTC)

@Faendalimas, where specificaly do you think it would be great to be lighter? I would suggest to remove the part about handling complaints for community-run bodies. I gonna make some other comments below. Goombiis (talk) 19:15, 21 December 2024 (UTC)

Боки's comments

• Comment

As a CheckUser on Serbian Wikipedia, I would like to share my perspective on how our community can manage CheckUser processes in a way that mirrors the rules and practices outlined below. These practices align with global Wikimedia policies and have proven effective without creating issues.
Translated Rules (from Serbian):
On projects without an Arbitration Committee (ArbCom) that meet the above criteria or where the community prefers independent elections, two options are possible:

Community Approval through Consensus:
The community must approve a local CheckUser via consensus.
The candidate must request rights within their local community and publicly announce their candidacy through appropriate channels (e.g., forums, mailing lists, if available, etc.).
The candidate must be familiar with the privacy policy.
After achieving consensus (at least 80% support or the highest number of votes in multi-candidate elections) and a minimum of 25 votes in favor, the editor should submit a request on the stewards' request list for granting rights, including a link to the community decision page.
Handling Insufficient Voters:
If there are not enough voters to elect at least two CheckUsers on a given project, that project will not have its own CheckUsers. Editors from that project will need to request user checks from stewards.
Requests for checks should be made on the stewards’ request page, providing justification for the check (with links).
Community consensus (as outlined above) will also be required.
The steward will then respond to the request, providing details such as whether two accounts share the same IP, proxy, network, provider, country, or are completely unrelated (refer to discussions about what details the steward is obligated to disclose to the editor).

My Perspective

As someone directly involved in the CheckUser process, I believe the Serbian Wikipedia community has a robust history of successfully implementing community-driven processes like the ones described above. These rules are practical, fair, and transparent, ensuring the trustworthiness of selected candidates.

Key points:
Community voting: This method has consistently worked well for other processes on Serbian Wikipedia. There is no reason to believe it would fail here, provided the rules are followed.
Simplicity and transparency: Announcing candidacy publicly and requiring consensus ensures clarity and accountability.
Avoiding unnecessary changes: As long as these processes are not causing issues, there is no need to disrupt or revise them.
The "if it’s not broken, don’t fix it" principle applies here. The Serbian community should continue using community voting for approving CheckUsers as described above. It meets all necessary standards and reflects the values of trust, transparency, and collaboration that Wikimedia projects strive for.

Warm regards, Боки ✉ 21:24, 20 December 2024 (UTC)

I sincerely thank you, @Боки, for sharing your perspective based on your experience with srwiki.

I believe your key points align with the ideas I intend to propose. Feel free to comment each step.

To share the experience of French Wikipedians (at least from the perspective of one of the 15,000+ active users, or as CheckUser): our “ailing” ArbCom led the community to transfer its CU/OS roles to the CNom after consulting the OC/WMF. However, the current policy appears, at least for interpretive or historical reasons and after long debates, incompatible with the CNom. This is because the CNom is not defined according to the model of the English ArbCom: it exclusively handles CU/OS cases and not broader community issues.

While one might argue that the French Wikipedia community should vote to grant CheckUser access, I think the French Wikipedia is already far too bureaucratic. With roughly 150 administrators, regular elections (patroller, abusefilter, ...), and ongoing discussions, the community chose not to elect CheckUsers and OS every six months directly. Transferring this responsibility to stewards could be an option, but in my view, with only two stewards fluent in French, it would quickly become challenging to manage legal issues — not to mention the investigations requiring a deep understanding of specific cases. To put it in other words: I don't think it would be humanly feasible for 2 stewards to replace 7 CheckUsers and 6 Oversighters, especially since explaining in English why a specific phrase or case raises concerns for Oversighters, that would be time-consuming and inefficient (eg OS concerns require responsiveness).

I am convinced that we should seek a pragmatic solution that addresses essential questions beyond the immediate concerns of French Wikipedia alone (e.g., who can determine which community processes are valid if the foundation of principles is not defined in the current policy or in Wikimedian policies? Why is the ArbCom allowed, but not another committee with the same clear principles? Why does a committee need to address community disputes to be competent in CU/OS matters? etc.). This proposal should also aim to resolve a range of accumulated criticisms regarding the current policy, which has seen few updates since 2007, despite significant changes in Wikimedian policies and the CheckUser extension itself. LD (talk) 22:12, 20 December 2024 (UTC)

Martin Urbanec' comments

Thanks for writing this down @Goombiis. I like the proposed version says the delegation to a committee needs to be explicit (while the current policy technically grants the appointment authority to all ArbComs, even on projects where that is not desired). However, I do think the proposal would need a bit of polishing.

Specifically: I don't think the CU policy should repeat what the ANPDP (or the Confidentiality Agreement) say. That can easily generate confusion, especially if those requirements change. In fact, the quoted requirements aren't 100% precise already (there is a process for waiving the age requirement, so there is a possibility of a CU not being at least 18 year of age). I think it would be more appropriate to just link to those other policies (as the current version of the CU policy does), rather than trying to summarize them. The CU policy doesn't need to mention everything – rules and requirements set by different policies continue to be valid regardless. In fact, not including the WMF requirements in the CU policy helps to maintain distinction between community-set requirements and WMF-set requirements (which is useful to know when a change is considered; it is important to know who can make that change, whether it is the community or the Foundation).

In addition to that, I don't think the CU policy should mention a foundation-run process. Firstly, I can hardly imagine the Foundation appointing a CU on a content project. Even if that happened, it would've happen under the Office Actions policy (the current version doesn't allow for such an appointment, but a future version might [although that feels highly unlikely]).

I also don't think the policy should allow for alternatives. The CU/OS access is highly sensitive one – the most sensitive access that can ever be granted to anyone. Let's enumerate the allowed ways in the policy itself. We can make it more generic (to accomodate needs we know about), but we shouldn't allow anything to happen. Martin Urbanec (talk) 23:56, 20 December 2024 (UTC)

@Martin Urbanec: Just a quick clarification: it's actually LD making the proposal, not Goombiis.

Also, it doesn't mean that the Wikimedia Foundation has to be part of the process; it simply states that [the CheckUser candidates] need to follow the ANPD policy. In fact, it really helps to clarify the appointment process. Best, Galahad (sasageyo!)^(esvoy) 00:05, 21 December 2024 (UTC)

Oh, sorry, I got confused by your signature being right under the proposal. Thanks for the correction, @Galahad! I was referring to this sentence: "CheckUser access may only be granted to users appointed through a valid community- or foundation-run process." (emphasis mine). I think that implies a foundation-run process might result in CU appointment, and I don't think that should be implied.

Regarding the ANPDP, I'm not opposed to mentioning that ANPDP (or the CA) exists. I just don't think we should summarize them within the CU policy, especially not in a factually-incorrect form. Martin Urbanec (talk) 00:14, 21 December 2024 (UTC)

@Martin Urbanec Does this version make the aim of this part of the proposal clearer? LD (talk) 10:57, 21 December 2024 (UTC)

Goombiis' comments

I got some comments on the proposal (which is imho a good draft). First, I would remove these strange intervals (25-30 and 70-80%). It's very weird not to have clear and definite thresholds. Because >25-30 is equal to >25 (the same for 70-80) and not to bother any local policies/practicies, I would suggest to only keep the 25 and 70% boundaries there. Also as mentionned above, I would remove the handling complaints thing for community-run bodies. I would say it is up to each wiki to decide how to proceed. --Goombiis (talk) 19:33, 21 December 2024 (UTC)

I agree with the idea of refining the thresholds (>25 and >70% are clear enough).

About the idea of not handling complaints, I'd say :

1. Since the OC is responsible for conduct related to the Global Policy, local bodies don't need to be responsible of it.
2. Nevertheless, since communities can establish additional requirements (e.g., lowering the inactivity threshold from 1 year to 6 months), they should at least have authority over these local requirements or be able to act accordingly.

So, I would rephrase

The community-run body is active and has the authority to handle complaints regarding misuse of the tool and may revoke CheckUser access if necessary.

as:

When the community establishes additional conduct requirements beyond the Global Policy, the community-run body must fulfill at least one of the following roles regarding local misconduct or misuse:

• Be capable of receiving and addressing complaints (e.g., Arbitration Committee);
• Be capable of receiving complaints and referring them to the appropriate body (e.g., Arbitration Committee, sysop-run body) or the local community (e.g., Request for Comment) for resolution;
• Be authorized to request the revocation of CheckUser access.

In any case, regarding CheckUser policy#Removal of access, a community-run body should have the authority to revoke access. If it cannot handle complaints per se, it may revoke access based on the precautionary principle (since CheckUser access is highly sensitive and the community-run body appoints them, making them partially responsible for their [mis]conduct). LD (talk) 23:47, 21 December 2024 (UTC)

Specific proposal comments

I suggest to discuss about other topics (quotes) --LD (talk) 15:32, 20 December 2024 (UTC)

Community-run body & conflict of interests

Members of a community-run body must not be CheckUsers to ensure there is no conflict of interest or misuse of privileges in judging complaints fairly.

Rationale: This is aimed at preventing conflicts of interest. A CheckUser has special access to sensitive information, which could be misused if the person is also involved in making decisions about complaints or disputes. To ensure impartiality and avoid any potential misuse of their powers, it's important to have separation between those who have access to such data and those who are responsible for judging or resolving disputes.

To adequately assess the actions of a checkuser, it is important for the volunteer body to have access to the tool and related sensitive information, including the tool's logs. Otherwise, we might encounter the same challenges that prompted our initial discussion on this topic. Additionally, please keep in mind that the OC holds jurisdiction over any breaches of the checkuser policy, Access to Nonpublic Information Policy, and Privacy Policy. Best, --Galahad (sasageyo!)^(esvoy) 15:43, 20 December 2024 (UTC)

To adequately address these two issues (conflicts of interest and CheckUser roles), I have rephrased the previous statement. You can find the updated version here: Talk:CheckUser_policy#About_different_CheckUser_roles_and_conflict_of_interest.

It comes to my mind that the previous quote needed clarification: CheckUsers and community-run body members can both have access to CheckUser but community-run body members aren't considered CheckUsers per se and shouldn't have the same duties. What do you think? LD (talk) 18:05, 20 December 2024 (UTC)

Responding to Galahad's statement above, "To adequately assess the actions of a checkuser, it is important for the volunteer body to have access to the tool and related sensitive information, including the tool's logs" (and speaking for myself, not in my official capacity as a member of OmCom), that's not quite correct.

The checkuser extension defines two (yeah, I know, it's really four) different rights as defined in mw:Extension:CheckUser#Granting right to use CheckUser: "checkuser" and "checkuser-log". When somebody is made a CU, they're put into a group which grants all of them. But it's possible to grant somebody just the checkuser-log right by itself. That would allow somebody to audit CU usage without being able to run checks themselves. The CU logs are still private data (and thus granting this right would require ANPDP) but it's less sensitive than being able to run checks so I would imagine there would be less resistance to granting it to the Cnom (or whatever it ends up being called) members than would be granting them full CU access. I'm not aware of any instances where these rights have been granted individually, but the fact that they exist as distinct capabilities makes it clear to me that such a scenario was envisioned when the tool was designed.

As a practical example, when the OC investigates complaints, pretty much all we're ever doing beyond reading publicly-available pages is examining the logs. If that level of access is enough for us to do our jobs, it should be enough for the Cnom to do theirs. I'm not saying this is what frwiki should do, just pointing out that the possibility exists and might be useful as you explore a way forward. RoySmith (talk) 20:01, 20 December 2024 (UTC)

@RoySmith I believe this CU policy should encompass all uses of the CheckUser extension, at least those commonly associated with investigations (given that AbuseFilter is also associated with checkuser-temporary-account, which seems to be a irrelevant matter here).

That being said, the CheckUser status section is ambiguous. It should clearly define what is "CheckUser access " — not just in terms of duties for CheckUsers and its associated rights. The current assumption that CheckUser access equates to being a CheckUser is problematic, especially when considering ArbCom or, potentially, new roles that might require CheckUser access or specific permissions related to policy or legal matters. For example, does ArbCom need the investigate right? Probably not. But does it need checkuser-log? Most likely, yes.

I don't think it's particularly relevant to highlight every possible combination of permissions. The primary goal of the CU policy is to ensure that only trusted users have CheckUser access, whether as a CheckUser per se, as an arbitrator, etc. and to ensure that each privileged action is governed by clear principles.

To address these issues, my first step for the Appointing local CheckUsers access section is to propose Talk:CheckUser_policy#About_different_CheckUser_roles_and_conflict_of_interest. While this proposal does not strictly define what a CheckUser or member is in a stricto sensu sense, it emphasizes the importance of ensuring that different roles can still be governed under the same policy framework and Wikimedian Policies.

The next step might be to tackle ambiguous issues, as highlighted in this discussion or more broadly in previous ones where some people have argued that the policy requires a comprehensive update.

Do you wanna comment this part in a new section? LD (talk) 21:05, 20 December 2024 (UTC)

@LD: If they can access the tool solely for checking irregularities, that makes sense. However, it should be implemented locally rather than globally, limiting the checkuser policy to access rights and removal procedures. This promotes community self-governance, so I recommend the removal of that part.

@RoySmith: Hi, from a former OC member! I understand the extension and its flags, but my recommendations on this proposal is solely on the specific usergroup in question. The creation of a special group with limited log-checking permissions is a separate discussion.

The group can exist, but it falls under local community governance rather than the Wikimedia CheckUser group, similar to OC permissions that have a separate policy.

Best, Galahad (sasageyo!)^(esvoy) 23:19, 20 December 2024 (UTC)

@RoySmith Unfortunately, the log right cannot really be granted separately. The only way to do that would be to create a whole new user group, which would have to be managed by the Stewards (as it would grant access to restricted data), and it is fairly difficult to manage a right that only exists on a single wiki. In theory, it might be done globally (group created at all wikis), but I don't expect such a proposal to pass unless there is a really good reason for it. Plus, purely having the logs doesn't need to be necessary – Ombuds also have access to the CU wiki, and logs sometimes do reference CU wiki pages (or CU-l). Granting access to CU wiki to someone makes them nearly a checkuser, as that wiki has raw CU data. Martin Urbanec (talk) 00:10, 21 December 2024 (UTC)

Martin Urbanec It really doesn't seem like it should be that complicated to implement. My understanding is that it's a matter of editing a config file and some interface changes to add the right checkboxes to the permissions assignment page. But we really shouldn't be worrying about that. I'm just looking for ways for the frwiki folks to navigate to a solution that keeps everybody happy. If they decide this is something that helps them get there, we can worry about the implementation details later. It is within the remit of the OC to "suggest suitable changes to ... software". I don't see any reason why cuwiki would be involved here. RoySmith (talk) 00:34, 21 December 2024 (UTC)

Hey Roy, its possible part of that individual application is for bodies like ours. I am not sure. But we have in the past had members who were not current CheckUsers to be OC they needed to access some information though do not need to run checks.

In any case I do not believe they need the tools. They just need to be able to receive the information derived from the tools. A CU/OS cannot share this information unless its first relevant to do so, but second that the person receiving it has signed the CA and ANPDP or equivalant, so they really do not need the tools, at least not all of them, but they need to be able to see the information. Cheers Scott Thomson (Faendalimas) ^talk 16:54, 21 December 2024 (UTC)

It would be possible to create such a local group, but it couldn't be granted directly from Meta so stewards would need to add themselves to the local frwiki steward group to grant the permission. Not the worst thing in the world, but ultimately probably unnecessary. – Ajraddatz (talk) 17:46, 21 December 2024 (UTC)

I agree entirely with Martin: that would be much difficulty for little benefit. Any benefit realised would not meaningfully affect the broader problem. arcticocean ■ 17:58, 21 December 2024 (UTC)

Minimum requirement for a valid community-run body

A community-run body must have a least <number> members.

Rationale: This ensures that no single individual or a small group holds too much power or influence over decisions. Having a minimum number of members helps distribute responsibility, reduces the risk of biases or personal interests driving decisions, and strengthens the legitimacy of the body's actions. It also ensures a broader range of perspectives, which is important for fair decision-making.

I think it shouldn't be too high (for small wikis), nor too low (for major wikis). Perhaps it can be phrased in a way that make sense for all of the wikis.

--LD (talk) 15:32, 20 December 2024 (UTC)

It would align the text with idea of wmf:Policy:Universal_Code_of_Conduct#3.2_–_Abuse_of_power,_privilege,_or_influence. --LD (talk) 15:36, 20 December 2024 (UTC)

Given that a successful candidacy requires a minimum of 25-30 users in favor, it might be beneficial to establish a minimum requirement for the composition of the volunteer body. For instance, if there are 30 voters, perhaps at least 10 could be present, and if there are 25 voters, then a minimum of 5 could be sufficient. This could reflect the number of voters in the community. Galahad (sasageyo!)^(esvoy) 15:47, 20 December 2024 (UTC)

(commenting as a community member, not an ombuds) I agree with this suggestion. Committees are a good way of checking the decisions of an individual volunteer (or small number of volunteers). arcticocean ■ 17:55, 21 December 2024 (UTC)

Since it is a global policy for all wikis, in my opinion it should be very light. Such as CU (they must be at least two local CU to be appointed), I would say at least 2 members in the community-run body. Then localy, each wiki can increase the number as it wishes. Goombiis (talk) 19:21, 21 December 2024 (UTC)

This is my idea in a 2019 proposed version:

To make an appointment valid, the ArbCom or equivalent panel must have at least 50% and at least two members satisfying:

• Elected, re-elected or confirmed in last two years
• The latest election or confirmation of the member must have at least 25 supports
• The member must not be inactive for more than one year

(the following is not part of proposed policy) this will rule out:

• ArbCom with not enough number of support (like the English Wikinews one) - This is already ruled out by current policy, but the current policy does not say whether some or all members should have been elected with such number of supports.
• ArbCom-equivalent body with no term limit (e.g. This 2006 nomination of Mediation Committee member is valid until its dissolution in 2018, we should not want an ArbCom with only members elected in 2006 to appoint a CheckUser or Oversight)
• Inactive ArbComs (similar to above)
• ArbCom with only one member (only hypothetical)

--GZWDer (talk) 13:50, 23 December 2024 (UTC)

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)