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

Notification of upcoming changes to policy

The Wikimedia Foundation recently received a recommendation from the Ombuds Commission that this policy be amended. The issue at hand is the appointment of Checkusers and Oversighters and whether the group which appoints them on a project must specifically be an Arbcom or whether another, specialized committee could do it. After review, the Ombuds Commission believes, and the Foundation agrees, that there is room for a wider variety of functionary "Appointment Committees" beyond simply Arbcoms.

Accordingly, we plan to update this policy and the Oversight policy on 26 July 2022. The changes will be as follows for the Checkuser policy (removals in strikethrough and additions in bold):

On wikis with an Arbitration Committee (ArbCom)Appointments Committee 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 ArbitratorsCommittee. Any committee meeting these requirements, including an Arbitration Committee (ArbCom), may fulfil this role. After agreement, a member of the Committee should simply list the candidate on Steward requests/Permissions.

On a wiki without an ArbitrationAppointments 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. [...]

Suspicion of abuses of CheckUser should be discussed by each local wiki. On wikis with an approved ArbCom, the ArbCom can decide on the removal of access. On wikis without an approved ArbCom, the community can vote removal of access.

We plan to make this change on 26 July 2022. Kbrown (WMF) (talk) 15:17, 18 July 2022 (UTC)

@Kbrown (WMF): I thought this was a community policy. Shouldn't this change come from the community instead? While I do not substantiatively disagree with the change I think this sets a bad precedent. --Rschen7754 18:10, 18 July 2022 (UTC)

I agree with Rschen, and I also am worried that the proposed change is too ambiguous. How about something like the following: (– Ajraddatz (talk) 19:17, 18 July 2022 (UTC))

the community may approve local CheckUsers (stewards not counting as local CheckUsers) per consensus. Local CheckUsers may be appointed by their respective community by consensus. The CheckUser candidate status must request it must request the persmission 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% 75% in pro/con voting or the highest number of votes in multiple choice elections [note: should this be removed?]) in the local community, and with at least 25–30 25 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.

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. A community may also delegate the appointment and termination of local CheckUsers to a committee that is elected with the support of at least 25 members of the local community and which has received community consensus to manage access to the CheckUser permission. This may include an Arbitration Committee, and existing committees that already engage in the control of the CheckUser permission may continue to perform that function after this policy comes into force without requiring a separate community vote on their scope. After agreement to appoint a user, a member of the Committee should simply list the candidate on Steward requests/Permissions.

I guess the question is "who decides what counts as a valid Appointments Committee?" If I get some English Wikipedia WikiProject together and have them vote up an "Alternative ArbCom," who is in charge of deciding that that committee isn't a legitimate appointment body? GeneralNotability (talk) 20:54, 18 July 2022 (UTC)

Yeah, that seems a little strange. More to the point, what would stop me from getting 25 of my IRC buddies to hold an AppCom formation RfC on the Ships In Bottles Noticeboard at 3am on a Wednesday and appoint ourselves CUs by unamimous consensus? JPxG (talk) 09:47, 20 July 2022 (UTC)

Noting that Checkusers have also been discussing this on our mailing list. Some of the points are noted above. Using Chatham House Rule, I'll include additional points:

• The policy as a whole is outdated in significant ways that do not reflect current realities of our projects.
  • VOTING: Some discussion of whether the current minimum of 25 supports is sufficient for access to this highly sensitive tool. Some discussion of whether there should be higher/more specific requirements for voters to meet in order to participate in CU elections (e.g., similar or equivalent to those for stewards). This could include minimum number of contributions, limits to only voters with accounts registered a certain period before the election, or other local requirements.
  • WIKIS WITH ONLY ONE CHECKUSER: The policy poorly addresses what happens when one or more CUs on a project are removed according to local or global policy (e.g., insufficient activity, resignation, removal for cause, etc) so that only one CU remains. (Consideration of a proposal to reflect what is mostly current practice is addressed in the section above.)
  • USING GLOBAL POLICY TO ADDRESS AN ISSUE OF A SINGLE PROJECT: There is currently only one project that has proposed even considering the need for a separate "appointments committee". Some feel it is overkill to modify a global policy to accommodate one project.
  • NEED TO ADDRESS RELEASE OF CHECKUSER DATA IN ORDER FOR CHECKUSER TO COMPLY WITH LOCAL LEGISLATION: This issue has been previously discussed on the CU mailing list in the past few months, and many felt that a formal process could/should be included in the CU policy.
• The majority of CUs commenting on this felt that this is a community policy and changes should be made in the usual manner for global community policies that are hosted on Meta. That is, unless there is a hardline legal reason that the policy would need to be changed, the WMF's role would be to suggest or recommend changes and/or to voice support or opposition to a proposed change.
• Unclear who would be responsible for determining whether any proposed "appointments committee" is actually accepted as such. The WMF? The local community via local policy? (And how would *that* policy be decided?) The Ombuds Committee, a non-elected body? Can a local Arbcom delegate this responsibility to a "subcommittee" that is the equivalent of an appointments committee?

My own opinion is that there's no value in modifying this section without revamping the policy as a whole; this is actually a lower priority than other updates that are needed. I also believe that this is a community policy and that, while the WMF is very welcome to suggest changes, there's no strong privacy-related or legislatively-related reason for this change that would justify that the WMF mandate this change. Finally, I would very much like to hear from the Ombuds as to their views on this proposed change, including the reasons for those views. Risker (talk) 05:45, 19 July 2022 (UTC)

• Two more issues that should probably be considered:
  • Inactivity: 1 year with no edits/logged actions (as the vague wording has been interpreted) is too lax, especially when there are only 2 CUs.
  • Voting: some wikis leave their CU nominations open for months in order to hit the minimum of 25. This is probably not a fair election. --Rschen7754 06:45, 19 July 2022 (UTC)

  In response to your two more issues you mention I agree that inactivity needs to be tightened, also on voting my view is the CU election should be a 14 day election, if they cannot hit 25 in 2 weeks then they probably do not need the tools on the wiki, such wikis can go to the Stewards when in need. Cheers Scott Thomson (Faendalimas) ^talk 13:17, 19 July 2022 (UTC)

Concerning your last point, "COMPLY WITH LOCAL LEGISLATION": in Confidentiality agreement for nonpublic information there is: Exceptions to nonpublic personal data. Nonpublic personal data does not include any information which (a) [...] (d) is required by law to be disclosed by you, but you promise to give WMF prompt notice of such legal requirement and comply with any protective order imposed on such disclosure. Der-Wir-Ing ("DWI") talk 08:42, 19 July 2022 (UTC)

• @Risker: as has been supposed in the chat on the mail list. Yes the actions of the French WP have caused this policy change. We received several requests over the their NomCom process. The OC does not have the mandate to recommend changes to policy at whim, this came about as a direct result of the case regarding the French WP and their NomCom process. What it came down to in the end was we had to determine if the process that the French WP had in place was in violation of policy and if so what to do about it. The problems with the French ArbCom are not something we have a say over it is outside our mandate. Many of the comments above were also raised by our various members and this led to a back and forth between WMF and the OC over this issue. In the end we recommended what Karen presented. It allows the process the French WP has developed to continue. I agree the whole policy needs an overhaul, and I do feel like we are playing catch-up here. I would be interested in a major overhaul of the policy and try to develop a workable document that is more to the communities needs. In the mean time we have to deal with issues as they arise. Chair Ombuds Commission Scott Thomson (Faendalimas) ^talk 13:40, 19 July 2022 (UTC)

  Hello @Faendalimas: By reading the above, it'd appear that it is the OC opinion that the French Wikipedia method to appoint or demote users to CU/OS access is against the global policies, otherwise no change in the policy would be necessary, right? —MarcoAurelio (talk) 14:03, 19 July 2022 (UTC)

  heya @MarcoAurelio: yes under current global policy there are two options in reality, appointment by ArbCom or Community Vote. What is the current practice on the French WP is neither of these. As such it is in violation of current policy. Hence the recommended changes above. Cheers Scott Thomson (Faendalimas) ^talk 14:16, 19 July 2022 (UTC)

  While I am no longer on the OC and live in a common law jurisdiction, is there any reason why frwiki's practice cannot be "read in" to the current text? IMO an appointment body that meets the voting requirements of an ArbCom would seem to fall within the intent of the policy, especially when you consider that the policy has not been updated in a long time. – Ajraddatz (talk) 16:26, 19 July 2022 (UTC)

  Question still pending, abd I've got the same. --Pa2chant.bis (talk) 11:20, 18 December 2024 (UTC)

Hi all, a quick update: as I'm sure has become obvious at this point, we've scrapped the intended 26 July implementation date. We're working on a big response for y'all. That response will probably make some suggestions as to what we could change in the proposed text to resolve the concerns that have been expressed, as well as talk about the reasoning behind the proposal and about the "whole policy needs an overhaul first" thing. I don't have an expected publish date for that response yet, but I'm hopeful we'll have it ready in the next week or so. Apologies for how long it's taking; Legal and I are taking extra time to make sure our thoughts are legally viable as well as consistent with community expectations. Kbrown (WMF) (talk) 12:34, 28 July 2022 (UTC)

And here's that response:

Thanks for all your thoughts. We've reviewed the concerns people have expressed here and elsewhere and believe they have merit. We spoke with the Legal team and we want to address two points in particular, regarding how to amend the policy and how to ensure this amendment won’t be abused as well as some other points of feedback.

First, with regard to how to amend the policy, the checkuser and oversight policies are in a somewhat unusual position. They have some requirements that are dictated by law and other aspects that are open to community editing. For example, checkuser policies cannot permit data sharing that’s prohibited by the privacy policy and generally need to align with legal requirements for non-public data. Similarly, oversighted content presents a risk of abuse that could lead to legal claims against the Foundation or negligent users, so it needs a similar level of protection as to who can access the tool. On the other hand, details of the policies and how they’re handled are open to community tweaking and the Foundation does not dictate their precise wording. In this case, we found the review of the French language system for appointing checkusers and oversighters to be consistent with the Foundation’s legal obligations, but the Ombuds Commission expressed the concern that the checkuser and oversight policies as written did not permit the structure that French set up. The Ombuds Commission recommended that the policies be amended to allow this system (as it seems like it’s working well for French and there’s no legal reason others can’t do similar). We had intended to help effect their recommendation by making that change. Basically, our intention was to write into policy an already-existing appointment method that had been signed off on by OC and WMF Legal; this sort of descriptive (as opposed to prescriptive) policy-writing has been pretty common in the movement through the years. We still wanted to get community feedback from folks experienced with these tools though, and, we agree that given that there are objections to this proposal, it should go through a typical discussion process and be implemented by consensus. We’re hopeful that we can adjust the proposal to meet any concerns and reach that consensus. On re-reading the notifications we put out about this change, I think they may have been worded too bluntly and given the impression that we thought this was completely a WMF thing rather than a WMF-and-the-community thing, so apologies for that.

Second, regarding the concern of abuse, we suggest two additional language changes that may help address this point. First, we should add the following bolded language: “Appointments Committee whose members have been elected with the support of at least 25–30 members of the local community in an open election process.” This would mean that a project or group collecting 25-30 members to select a committee would not be able to do so unless they held a general vote on that wiki and were successful. Second, we suggest adding the following bolded language to indicate that there can only be one appointments committee per project: “Any committee meeting these requirements, including an Arbitration Committee (ArbCom), may fulfill this role, but there may only be one Appointments Committee per wiki.

In discussion elsewhere, people have noted that it's odd that the suggested changes say Appcoms can appoint but only Arbcoms can remove. That's also a good catch. It's written the way it is because that was Ombcom's recommendation; as we understand it, their reasoning is that if Appcom members don't hold CUOS - as they currently don't on Frwiki - then they cannot adequately investigate misuse of the tool(s). We're not 100% opposed to removals by Appcoms being allowed, but we also find the Ombcom reasoning persuasive on this and want to make sure those implications are considered.

I also want to acknowledge the concern that this number of voters may not be enough to accurately select checkusers and oversighters. We would be hesitant to raise this requirement too much given that many languages are small, but if there’s community consensus to raise it (or perhaps to raise it only for wikis having a certain number of active users) please feel free to do so via a distinct proposal as it would not be a legal problem for the Foundation if that requirement became more strict.

Lastly, there were a few comments that the policies need a bigger overhaul. This is a fair point but beyond the recommendation of the Ombuds Commission and not something we’ve looked into in detail in terms of what would be possible given current applicable laws. If there’s interest among community members in proposing other policy changes please feel free to do so and we’re happy to take a look at them to flag if they’d pose any legal problems for the Foundation. If there’s interest in having the Foundation spearhead a broader checkuser policy overhaul, we can look into what resources the Privacy and T&S teams would need to do that and try to schedule the project for the short to medium term future.

Could you let us know if these suggestions resolve the concerns that have been expressed? We are open to making further changes as needed to the proposed changes. Kbrown (WMF) (talk) 16:00, 3 August 2022 (UTC)

I appreciate the clarifications and explanation of the WMF's position. --Rschen7754 07:33, 4 August 2022 (UTC)

@Kbrown (WMF): Previously I have opened Requests for comment/Amendment of CheckUser policy and Oversight policy, which may contain issues and proposals you may concern. GZWDer (talk) 15:49, 13 August 2022 (UTC)

Hi folks! After considering your comments here and elsewhere, and incorporating some tweaks to our proposed changes based on those comments, we think there is consensus to implement the following changes (removals in strikethrough, initially-proposed additions in italics, and tweaked additions in bold-italics):

On wikis with an Arbitration Committee (ArbCom) Appointments Committee whose members have been elected with the support of at least 25–30 members of the local community in an open election process which, at a minimum, meets all the same requirements as an election for each individual checkuser, CheckUsers may be directly appointed by the Arbitrators Committee. Any committee meeting these requirements, including an Arbitration Committee (ArbCom), may fulfil this role, but there may only be one Appointments Committee per wiki. After agreement, a member of the Committee should simply list the candidate on Steward requests/Permissions.

On a wiki without an Arbitration Appointments 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.

[...]

Suspicion of abuses of CheckUser should be discussed by each local wiki. On wikis with an approved ArbCom, the ArbCom can decide on the removal of access. On wikis without an approved ArbCom, the community can vote removal of access.

We'd make the corresponding update to the Oversight policy, as well.

We don't believe there's currently consensus in this discussion for implementing any general CU policy overhauls (though as noted previously, we're open to working on that in the future if there's a desire), for stating at a global level exactly how AppComs should function, for changing how CU is removed (Arbcom vs AppCom), or for raising the bar for required support for CU appointments. Of course, if you feel strongly that any of those should happen, you are more than welcome to open a discussion with the community (and, ideally, pinging user:WMFOffice so we're aware) on those topics; we're just proposing making an update, not saying this is the only update that can happen.

We'd like to implement these policy updates in the near future unless there are continued objections or unless we've missed any dealbreakers. Could you please give this revised proposal a read-through and let us know what you think? Thanks so much! Kbrown (WMF) (talk) 14:06, 19 September 2022 (UTC)

"in an open election process which, at a minimum, meets all the same requirements as an election for each individual checkuser" - frequently arbitrators on enwiki get below 70% in SecurePoll which would fail that wording. Rschen7754 18:05, 19 September 2022 (UTC)

Oh, a very good point Rschen7754! I'm compiling thoughts about this revised proposal for review by Legal, so I'm adding that one to my list for us to think about. Currently also on my list are:

• What about projects that don't elect their CUs at all (i.e. they use Arbcom appointment)? What standard does this policy require from them?
• Not every project has exact thresholds and procedures for CU elections that could be applied as laid out here, so what standard does their AppCom use? Kbrown (WMF) (talk) 12:56, 20 September 2022 (UTC)

If I may make an observation here. In the part "Suspicion of abuses of CheckUser should be discussed by each local wiki. On wikis with an approved ArbCom, the ArbCom can decide on the removal of access. On wikis without an approved ArbCom, the community can vote removal of access. Suspicion of abuses of CheckUser should be discussed by each local wiki. On wikis with an approved ArbCom, the ArbCom can decide on the removal of access. On wikis without an approved ArbCom, the community can vote removal of access." This may be a little problematic. If a CU goes rogue its likely that it will require investigation of their logs, which requires access to the CU tools. In which case issues such as this are more likely to need to be sent to the Stewards or OC as the case may be. In the absence of an ArbCom that is.

"In the absence of an ArbCom that is." How would an Arbcom help? I mean, only one of the 12 arbcoms can read the CU logs on their project.

Anyways, including a list of persons and groups who are technically able to do some investigations could help here.

Also, the text more or less implies, that on a project with arbcom the community can not decide. That would lead to some cases where the arbcom is not allowed to grant CU right (insted done by public voting) but the arbcom would be responsible for removing them. --Der-Wir-Ing ("DWI") talk 14:55, 29 September 2022 (UTC)

There may be Arbcoms whose members are not even have the sysop flags, or which intentionally consist of members who have expertise in conflict resolution but not too much technical understanding. In any case most Arbcom members outside the English Wikipedia may have not sign any confidentiality agreement. I think it doesn't make any sense at all to entitle them to make any call based on evidence they may not even see. I think the whole approach is moot except for one wiki were it already is the status quo. --Krd 15:10, 29 September 2022 (UTC)

Fair point, yes it would require that at least one ArbCom member could investigate. I had been told ArbComs could handle this. If that few can actually do this effectively then investigating the actions of CUs in those cases its needed will have to be with the stewards or oc as relevant. Cheers Scott Thomson (Faendalimas) ^talk 15:44, 29 September 2022 (UTC)

Wording

Hi. In CheckUser policy#Appointing local CheckUsers it says
"The CheckUser candidate status must request it within the local community [...]". I assume it's meant to be something like
"The CheckUser candidate must request the status within the local community [...]" or perhaps
"The candidate must request the CheckUser status within the local community [...]" since a status cannot make requests, but a candidate can. TilmannR (talk) 13:50, 5 March 2023 (UTC)

Thanks for pointing this out. Done. Emufarmers (talk) 00:14, 18 April 2023 (UTC)

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)