Wikimedia Meta-Wiki

Requests for comment/Amendment of CheckUser policy and Oversight policy

< Requests for comment

The following request for comments is closed. After half a year, no support has emerged for changing the policies in the proposed way. --MF-W 00:16, 21 June 2020 (UTC)[reply]

Note: The final policy will not contain underlines.

Proposed amendments edit

Appointing local Checkusers edit

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) or an equivalent panel, CheckUsers may be directly appointed by the Arbitrators. After agreement, a member of the Committee should simply list the candidate on Steward requests/Permissions. 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

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 CheckUser candidate status must request it 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% in pro/con voting or the highest number of votes in multiple choice elections) in the local community, and with at least 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. The vote must not last for more than one month.

Local community may adopt a stricter policy of CheckUser access, but users are also required to satisfy the global policy to be granted CheckUser access.

Oversight access edit

...

On wikis without an Arbitration Committee, the community must approve oversighters by consensus. The candidates must request it within the local community and advertise this request to the local community properly (community discussion page, mailing list, etc). After gaining consensus (at least 70% in pro/con voting or the highest number of votes in multiple choice elections) in their local community, and with at least 25 editors' approval, the user should request access on Steward requests/Permissions with a link to the community's decision. The vote must not last for more than one month. Local community may adopt a stricter policy of Oversight access, but users are also required to satisfy the global policy to be granted Oversight access.

On wikis with an Arbitration Committee or an equivalent panel, users may also be appointed by the Arbitration Committee, unless the local community prefers independent elections. After agreement, a member of the local Arbitration Committee should place a request on Steward requests/Permissions. 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

Comments edit

See Wikimedia_Forum#Voting_requirement_in_CheckUser_policy_and_Oversight_policy for original discussion.

I added a requirement for ArbCom, 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)

The Czech ArbCom consists of two members with more than 25 supports and two members with less than 25 supports, this will be a baseline of a valid ArbCom. The Ukrainian one (3 members with 25 supports) is also valid. On the other hand, The Finnish one (only 2/10 with 25 supports) will not be considered a valid ArbCom.

--GZWDer (talk) 14:15, 21 December 2019 (UTC)[reply]

"The vote must not last for more than 3 months." IMO should also be in OS policy, unless I missed the diff... — regards, Revi 14:23, 21 December 2019 (UTC)[reply]
Nevermind, it was on different part. — regards, Revi 14:26, 21 December 2019 (UTC)[reply]
Whatever, 3 months are exceedingly long and should be closed (or automatically considered stale) within less than 4 weeks timeframe. — regards, Revi 12:07, 22 December 2019 (UTC)[reply]
I have change it to one month.--GZWDer (talk) 16:20, 22 December 2019 (UTC)[reply]
I'd go with 3 weeks (21 days). 3 months is too long and would likely be an extension of the de facto current practice on most wikis. I'd be willing to go to 30 days if absolutely necessary, but think 21 days is a much better number. We want to keep this long enough to give people a chance to raise negative feedback, but short enough that people can't bug their non-active friends to support. TonyBallioni (talk) 14:27, 21 December 2019 (UTC)[reply]
3 months is Billinghurst's idea. I personally support one month.--GZWDer (talk) 14:30, 21 December 2019 (UTC)[reply]
Three months is an exceedingly long time and even the most inactive wiki could find a way to get 25 votes in that period if they really wanted active CUs. 30 days is still on the long-side for me, but I'd be fine with it as a compromise/reasonable period even though I'd prefer 21 days. TonyBallioni (talk) 14:34, 21 December 2019 (UTC)[reply]
  • "Local community may adopt a stricter policy of CheckUser access, but users will not be granted CheckUser access if they do not meet the global policy." Why would we delete these sentences? On plwiki we have strict criteria for granting permissions even to administrators (80%). For checkusers we have 85%, so if we remove these regulations from meta, we would have an 80% mininum for sysops and 70% minimum for CU (and OS). This is an aberration. Ptjackyll (talk) 14:53, 21 December 2019 (UTC)[reply]
    • I have reworded the sentence.--GZWDer (talk) 15:02, 21 December 2019 (UTC)[reply]
      • That didn't change anything. I didn't want these sentences to be rewrote. I wanted them to be kept (now they're still underlined so eventually will be deleted form policy). Ptjackyll (talk) 19:10, 21 December 2019 (UTC) Sorry I totally misunderstood the note above. I thought that "The underlines are to be removed in the final policy." meant for the underlined text instead of the underlines itself. Sorry for the confusion. The previous version was indeed better. Sorry once again. Ptjackyll (talk) 19:27, 21 December 2019 (UTC)[reply]
  • Comment: There is a possible conflict, the proposal says that 50% support + 25 voters in support can be an ARBCOM. For non ARBCOM project it need to be 70% support + 25 supports. Hypothetical situation is that a wiki can set up an ARBCOM if there is 25 support and 25 opposes which will mean the ARBCOM is established, members received CU rights (or delegated) but then if it's a direct CU election the member will not receive CU tools. This will make the 70% support rule quite redundant. 2 ways I propose to solve this, make there to be a minimum voting requirement for ARBCOM elections or minimum number of voters in the ARBCOM election. In addition, if passed this strictly the voters and etc, we need to put it clearly who can vote and who can't vote. Per common dramas at SRP, we have people saying what defines community and etc. For admins, we can let the current guidelines work, for CU/OS, let us have some clarity. I don't want to see people creating 25 socks to vote in an otherwise desolate wiki and then use this guidelines to wikilawyer, neither I want to see people saying that their community is overwhelmed by people with less than significant contributions. I think I will have more, but that about it for now. Thanks for this RFC. --Camouflaged Mirage (talk) 12:27, 22 December 2019 (UTC)[reply]
    • The minimal support rate in English Wikipedia ArbCom is 50% and we have elected member with only 55% support. In small wikis there will not be many users opposing, so it's probably enough if we require a minimal number of supports (not total votes). However it may be possible for some ArbComs not to use a support/oppose system, but a candidate election system.--GZWDer (talk) 16:20, 22 December 2019 (UTC)[reply]
      • I will think enwiki a 50% support is reasonable (not too sure, as I am not part of that community), but this doesn't mean all the wikis. I am not speaking about small wikis, I am speaking about middle size wikis (e.g. enwikibooks / simplewiki). Will 25 supports and 25 opposes be accepted to be CU? I do not feel comfortable. But based on the proposal, the community / member can then propose to create an ARBCOM and then get voted in with this same support, subsequently requesting for CU. This cannot be it. I feel that we can make it in this way, the arbcom support should be the same per the standard support (with exceptions). The exceptions are clearly established wikis ARBCOMs like enwiki, fawiki and etc. --Camouflaged Mirage (talk) 10:28, 23 December 2019 (UTC)[reply]
  • I feel requiring a minimum of 70% of support in community votes is tad low for CU/OS and should be raised to at least 75%. As I said elsewhere, 70% of support in most projects means that a simple RfA won't pass. Given that the current wording of the policy is to require 70-80% of support, I feel putting a clear 75% threshold would not be controversial, and would make stewards work easier on some cases. Local wikis can continue to establish a higher number of votes or % of support. I am also unease about allowing bodies analogous to ArbCom to be able to appoint members to this positions. And I am also not happy with the maximum voting limit of 3 months. That's a whole lot of time. Consensus must be present and achieved in a reasonable period of time, and three months in "wiki time" is too much. I'd go with three weeks as maximum as TB suggested above. I may make further comments at a later date but this is all for now. —MarcoAurelio (talk) 20:20, 22 December 2019 (UTC)[reply]
  • "users are also required to satisfy the global policy" - who are the "users", which "global policy"?  « Saper // talk »  22:33, 27 December 2019 (UTC)[reply]
  • "On wikis with an Arbitration Committee (ArbCom) or an equivalent panel, CheckUsers may be directly appointed by the Arbitrators." This should say that wikis with an ArbCom may appoint a policy that CheckUsers may be directly appointed by the Arbitrators. It should not automatically mean that the mere presence of a body similar to ArbCom should give that body the right to appoint the CUs or oversighters. It should be clearly stated as a policy option, not an automated policy change.  « Saper // talk »  22:33, 27 December 2019 (UTC)[reply]
  • Could you provide more reasoning behind this proposal? The discussion that has been linked here refers to a proposal much narrower in scope. What problem are we going to fix here?  « Saper // talk »  22:36, 27 December 2019 (UTC)[reply]
    • As status quo, wikis with ArbCom which meets some not well defined threshold may appoint CheckUser and Oversight; They may also be elected by community votes. However, it's not clearly stated that which ArbCom is eligible.--GZWDer (talk) 17:35, 28 December 2019 (UTC)[reply]

Comment Comment I find the whole proposal pretty much abhorrent, and will only favour very large wikis. The commentary here clearly only comes from those familiar with very large projects, without an understanding of the smaller sister projects and how they work. No one has demonstrated how the current system is being gamed or not working. This proposal is a solution in search of a problem. — The preceding unsigned comment was added by Billinghurst (talk)

Actually I understand small projects and how CU / OS works for smaller projects, I just hesitate to comment on that part as this RFC is highly slanted to large wiki needs. I will be happy to discuss from the perspective of small wiki if needed. Speaking of small wikis, is there a need to notify all potentially affected wikis of this RFC? This will allow for more input. --Camouflaged Mirage (talk) 09:28, 31 December 2019 (UTC)[reply]
  • The policies need to be rewritten, but I am not sure that this is the right proposal. The only teeth that this has would be limiting the length of a vote for CU/OS, which would help (I can name two projects who have tried to get CU/OS rights within the last month and who should not have them) but I am not sure that this would be worth the effort. --Rschen7754 18:46, 4 January 2020 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Requests_for_comment/Amendment_of_CheckUser_policy_and_Oversight_policy&oldid=24961038"