Requests for comment/CheckUser activity RFC

The following request for comments is closed. While the global policies surely need to be updated in some points, this RfC obtained less than 35% of the consensus on more than 80 opinions in 9 months, therefore I'm closing it as unsuccessful. Thanks to all participants. --Superpes15 (talk) 17:56, 18 January 2024 (UTC)[reply]

Since the inception of the CheckUser policy, a key component has been that there is never one CheckUser on a project. This provision is so that there is at least one other person to review the actions of the other in a native language, should it be necessary. The current reading of the policy is that they are there to audit the other's use. The problem is that this only sometimes happens. There is a security concern also when an account becomes inactive. This proposal will assist in eliminating these concerns.

It is proposed that the CheckUser policy be amended to require that CheckUsers have a minimum of 5 checks during any 12 month period where:

The checks must not be on themselves, their bot, or for testing purposes
The user is not exempt by being part of a body that assigns, removes, or audits the use of CheckUser for that community
The user has been assigned local CheckUser
The wiki is a content project

Proposed by: -- Amanda (she/her) and User:Martin Urbanec 22:08, 15 April 2023 (UTC)[reply]

FAQ[edit]

What if someone loses their rights for inactivity? Can they regain them?

No, a fresh election would be required, as is standard practice when removing the rights of a CU at SRP.

Which wikis would be immediately affected by this policy should it come into force when it is proposed?

cswiki, dawiki, enwikinews, fiwiki, kowiki, mlwiki, and specieswiki would either have zero or one CUs remaining, requiring the removal of all CheckUsers on those wikis. 24 of 191 (~12.6%) CheckUsers that exist globally would be up for removal.

What does this change ensure?

That there are active checkusers on the relevant wiki, able to provide a second opinion should the community or another CheckUser need it.

This is going to remove all CUs from my wiki. What can we do to stop it? Can I exempt my wiki by a local vote?

No, the CheckUser policy is a global policy with no opt-out clause. The only way to retain CheckUsers locally is to have your local CheckUsers become active again or elect more to be CheckUsers.

Why is this RfC happening now?

Global Interface Editors, Global Rollbackers, Global sysops, Stewards, and Global Abuse filter maintainers/Global Abuse filter helpers all have clear activity requirements. This proposed change clarifies the inactivity wording.

Will this change not encourage CheckUsers to run inappropriate checks?

Usage of CU is strictly regulated by the CU policy, the access to nonpublic personal data policy, and relevant local policies. Should a CheckUser or Steward notice inappropriate use, especially to meet the requirement, they can report it to the Ombuds Commission.

Discussion[edit]

Support as proposer. -- Amanda (she/her) 22:08, 15 April 2023 (UTC)[reply]
Oppose. I do agree that inactive checkusers should be removed, but I don't think this is a good criterion for a global policy concerning a local role. I think it would be important to understand the dynamics of concerned wikis (like cswiki or dawiki) first. Because I can imagine a number of ways a CU can be active without doing checks, like discussing results on a mailing list or reviewing logs of checks made by more active CUs. I am not sure what is actually happening in these cases, so it would be useful to check with the concerned communities on how they handle this. It might also be the case that they have a valid removal process (e.g. via ArbCom), so I would rather support a policy more like AAR first — NickK (talk) 22:28, 15 April 2023 (UTC)[reply]

One of the proposers (Martin Urbanec) is a cswiki CU who will lose their local rights (though we don't know if they're the inactive one), so presumably they understand the dynamics there. Legoktm (talk) 03:51, 16 April 2023 (UTC)[reply]

Martin Urbanec is one of the main causes to be strictly oppose this proposal. He is one of these guys, who better should run much less CUs - or more better, should not have the right to access CUs at all. A success would give him more opportunity to CU also in other projects. Marcus Cyron (talk) 05:41, 17 April 2023 (UTC)[reply]

Well, he wrote himself that he discussed results with fellow CUs by phone and in person (none of which are logged). I would assume that there would have been no discussions if all other CUs in cswiki were inactive, or if he were inactive himself, thus we have a contradiction — NickK (talk) 13:09, 29 April 2023 (UTC)[reply]
Oppose as User:NickK above. Also: Inactive accounts may or may not be security issue - there are cases where active account with persistent cookies can be easily hijacked. But security of the advanced permissions account is a question orthogonal to the CU activity and the events logged there. « Saper // talk » 22:39, 15 April 2023 (UTC)[reply]
Support Mainly, I think this misses an important project-specific (as opposed to user-specific) criterion. Perhaps we should have a separate criterion that says that only projects that have made 10 or more CU requests to stewards for the previous two years should be eligible to create the CU position; and similarly, projects can only retain CUs if they can demonstrate there have been a minimum of 5 policy-based checks or series of checks PER CHECKUSER per year. I understand what NickK is saying. I think that it would be helpful to have some very generic statistics on CU usage on low-usage wikis such as those identified above. I'll point out that there is only supposed to be one Checkuser mailing list, the global one, on which any CU can post in any language; this is for security purposes. I think AmandaNP has not mentioned some of the reasons that it's worthwhile to have minimum use standards. They would include skills maintenance (particularly as the CU interface has been undergoing considerable change), and concerns re user security. Risker (talk) 22:45, 15 April 2023 (UTC)[reply]

"PER CHECKUSER" you mean for at least two checkusers? ~~~~
User:1234qwer1234qwer4 (talk) 17:59, 16 May 2023 (UTC)[reply]

Hello @Risker, regarding the mailing lists, FYI at least a couple of projects requested and were granted separate CU lists. As far as I can see these are: checkuser-ar and wikipedia-pt-checkusers. I don't know if more have been created. Sincerely, —MarcoAurelio (talk) 18:53, 16 May 2023 (UTC)[reply]

Oppose The problem exists, but the proposal doesn’t solve it. A CU can be checking activities without doing checks themselves, orcan be doing checks but not monitoring activities. With the proposal, the second CU can be inactive 11 months without consequence. I also see no reason why this should apply to CU but nit OS, which can have simular issues. --Krd 23:05, 15 April 2023 (UTC)[reply]

What could solve the issue could sond like „If on a project there are less than 2 CUs who each have done edits or logged actions within the last 30 days, all CUs are removed on that project. The same applies for OS.“ Krd 23:09, 15 April 2023 (UTC)[reply]

This is causes exactly the problem I'm trying to avoid where 1 CU has completely checked out of running any checks for like 4 years and is not active in CU business at all, but still has edits. -- Amanda (she/her) 23:24, 15 April 2023 (UTC)[reply]

Then perhaps a combination of both is needed. Krd 23:49, 15 April 2023 (UTC)[reply]

Question: aren't all local checkusers part of the group that "audits the use of CheckUser for that community" - one of the reasons multiple checkusers are required on a project, even if just one audits one other. — xaosflux ^Talk 23:17, 15 April 2023 (UTC)[reply]

I was trying to dive for simpler English than getting all English-legalistic for a cross language proposal. By technicality of policy, it's only meant for CUs to "mutually control and confirm their actions", not audit. -- Amanda (she/her) 23:22, 15 April 2023 (UTC)[reply]

The CUs of a project are not a "body" like arbcom, the french appointment committee or the ombuds commission. Der-Wir-Ing ("DWI") talk 23:35, 15 April 2023 (UTC)[reply]

Question: I'm unclear on what criterion 2 means. Should it be read as "the 5 checks per 12 months requirement does not apply to members of a body that [...] CheckUser" or should it be read as "members of a body that [...] CheckUser are not exempt from the 5 checks per 12 months requirement"? Wugapodes (talk) 23:42, 15 April 2023 (UTC)[reply]

The former. Bodies that take it under their wing to change permissions and audit are meant to be exempt from the requirement. -- Amanda (she/her) 23:47, 15 April 2023 (UTC)[reply]

Support While I appreciate the concerns above about a project not having a sufficient quantity of requests for CUs to be able to meet the activity requirements, in that situation I would question whether there is a sufficient justification for the project to have CheckUsers in the first place. This is especially the case when considering that looking into a single account would usually result in more than one logged action. I would support (in case it comes up later) a modification to the proposal that allows declining to run checks count for part (not all) of the logged actions but my support isn't conditional on that and I understand why it wasn't included. I would also support (in case it comes up later) lowering the number of checks to 3 in 12 months but my support isn't conditional on that either. Callanecc (talk) 00:00, 16 April 2023 (UTC)[reply]
Support GeneralNotability (talk) 00:17, 16 April 2023 (UTC)[reply]
Support this is a step towards resolving two problems with CU Wikimedia-wide: first, there are projects where one CU has turned the CU tool into a fiefdom and they are unchecked. Second, there are projects that used to be active enough to sustain CUs, but now do not have enough activity to elect new CUs, and where the existing CheckUsers only retain their permissions based on what amounts to a grandfather clause.
Should these be stricter as some have alluded to above? Yes. Would anything stricter likely pass? Probably not. This also doesn't solve problems such as projects that don't need CUs electing them anyway (example: simplewiki, where the CU position is essentially a stepping stone to a future steward campaign) but we shouldn't let the perfect be the enemy of the good. This proposal as a whole does good things, and I end up here supporting it. TonyBallioni (talk) 00:32, 16 April 2023 (UTC)[reply]

If the CU tool is being used as a fiefdom, shouldn't we be removing those users for cause rather than waiting for inactivity? Legoktm (talk) 03:46, 16 April 2023 (UTC)[reply]

I was speaking to the social part of it, which might not be a policy violation in itself. When people operate in a vacuum and have powers that no one else in their environment have, it becomes a fiefdom that has negative impacts on the social structure of a project even if used in a policy-compliant manner. Essentially when you have one person who is doing all the work in an area of restricted access, it can't help but become a fiefdom where one person views their positions as the policy rather than what the policy actually says. We see this outside of the CU sphere on content projects fairly regularly and it is a general problem Wikimedia has. The difference with CU is that when this happens, there's a risk to people's privacy, especially in countries with less than stellar human rights records and the like. Having inactivity requirements is a small check that ensures that at least two people are active, which helps prevent this phenomenon. I'd prefer it be a higher standard, but I understand the counterargument that you don't want to encourage unnecessary checks. TonyBallioni (talk) 04:27, 16 April 2023 (UTC)[reply]
Support. Inactivity was one of the major issues that led to Requests for comment/Site-wide administrator abuse and WP:PILLARS violations on the Croatian Wikipedia. --Rs chen 7754 00:41, 16 April 2023 (UTC)[reply]

I will note that if this fails, perhaps the solution is to simply bring the activity policy down to 6 months of complete inactivity. Rs chen 7754 05:49, 16 April 2023 (UTC)[reply]

Could be, although I don’t think that helps in cases when CUs regularly edit, but the last time they used CU was years ago (resulting in only one CU which regularly edits). Maybe an alternative proposal can be requiring 5 checks in two years, rather than a year? Martin Urbanec (talk) 10:12, 16 April 2023 (UTC)[reply]

Unfortunately I think anything requiring "minimum number of checks" is going to cause controversy. I don't mean to say that going to 6 months will solve every problem, but at least it would help. The other proposal that might help would be limiting how long requests to gain the permission remain open (if it takes months to hit 25 supports, they probably shouldn't have CU) - but I know that's already being done in some instances. Rs chen 7754 19:13, 16 April 2023 (UTC)[reply]
Comment Currently tend to oppose. It simply is a wrong incentive. Personal data should be handelt not only with strict words in policies, but also with a strict design of the function. Would support an ammended version, which specifies, that there must be a minimum amount of checks, whether to use the check user function. Habitator terrae (talk) 01:12, 16 April 2023 (UTC)[reply]

Your comment doesn't make sense. There are 5 checks minimum during a 12 month period to not be affected by the proposed rule. -- Amanda (she/her) 03:21, 16 April 2023 (UTC)[reply]

He doesn't like that the proposed rule basically forces every Checkuser to look at private data at least 5 times a year. The number of CU-requests would be a better indicator in his opinion, because you can also decline the request and therefore be an active CU without actually doing checks on accounts. Der-Wir-Ing ("DWI") talk 11:52, 16 April 2023 (UTC)[reply]

I might be misunderstanding something, but @Habitator terrae says they would support an amended proposal, which specifies there "must be a minimum amount of checks", which is exactly what this proposal does (setting the threshold at five a year). I don't understand the difference between the suggested amended version, and what this RfC seeks? Martin Urbanec (talk) 12:52, 16 April 2023 (UTC)[reply]

@Martin Urbanec: Do also declinicing a request for CU, counts as a "check"? If so, I will support. Habitator terrae (talk) 16:42, 16 April 2023 (UTC)[reply]
Support The CheckUser role has two halves. The first half is using the tool to investigate abuse. In my opinion, the more important half is reviewing CheckUser logs and their fellow CheckUsers' activities. This is the reason there must be, at an absolute minimum, two CheckUsers at any time. The expectation of activity is, therefore, required and expected. CheckUsers that are inactive should not retain the role as they are not fulfilling the more important function of monitoring their own. There may be some projects that have 5 or 6 CUs, but only 1 is active and, as such, is unmonitored. It's my opinion this RfC seeks to codify a "circuit breaker" to prevent this exact circumstance and is needed. Operator873 ^connect 01:41, 16 April 2023 (UTC)[reply]
Comment As far as I know, merely viewing Special:CheckUserLog doesn't get logged. It's a valid question as to whether a CheckUser who only keeps an eye on other CheckUsers' use of the tool is being active enough for the right, but I disagree that it means the other CheckUser is unmonitored per se. On my home wiki, I'm certainly the less active of the two CheckUsers, more of a backup/second opinion, but I take my responsibility to monitor the tool's use seriously. As worded, this policy would incentivize me to redundantly look at more personal information than strictly necessary, or it could delay some requests while the other CheckUser load-balances more of them to me to ensure he retains his own rights. If the goal is to ensure, at a minimum, use of Special:CheckUserLog, then maybe visits to that page should be logged? – Minh Nguyễn ^💬 02:15, 16 April 2023 (UTC)[reply]

Is "checks" here referring to all the usage of the CU tool required to respond to a request, or literally just checking a single user as part of a response to a request? If the latter, then I could see myself supporting this proposal, if only because most requests require so many checks these days. Minh Nguyễn ^💬 02:21, 16 April 2023 (UTC)[reply]

@Mxn: It's just 5 single user checks. So one investigation could cause 5 entries in the log and it would pass the requirement. -- Amanda (she/her) 03:20, 16 April 2023 (UTC)[reply]

I think it should, other than proposed, refer to any request, with a response by a check user, may it be by checking the user or declining the request. Otherwise the rights of CUs depent not only on wether they decide, but also on what. Habitator terrae (talk) 04:49, 16 April 2023 (UTC) PS: A compromise could be to also make a log-note for declining requests.[reply]
Oppose That would put pressure on volunteers, motivate harassing ‘inactivity’, and trigger unnecessary checks just to reach the minimum number. Furthermore, i doubt the problem. How do you know that audits “only sometimes happen”? —MBq (talk) 05:07, 16 April 2023 (UTC)[reply]
Strong oppose
1. You have your experiences from enwiki. In a smaller wiki in good periods there are not enough legal cases. We had times in Hungarian Wikipedia when there was relative peace. Given a CU is active enough, can do most of the checks, and the others will not have the possibility. We won't break the rules just to have one more check.
2. Checks are often time-consuming (including documenting). This is a volunteer project, and nobody may be obliged to do a work just for keeping the rights that they don't need personally; the community needs their rights.
3. Number of checks is in no way directly connected to activity of the account. They may be active on Wikipedia, on mailing list etc. They may audit if necessary without doing checks.
4. It is a valid case to have a trustable CU, who does not want to do this work continuously, but lives in an opposite time zone and can be activated in urgent cases when others are sleeping. There are nations who did not spread their languages throughout the globe, and thus work in a limited time.
5. Any community consists of mostly adult people, who can detect if a CU is inactive, and can elect another if they think it's a must.
6. Given there are 2 active and 1 less active CU, the whole case is completely invalid, because the first two may audit each other's actions. The 3rd one has no role in the described problem.
7. CUs would have an extra task to continuosly check each others checks and do calculations. They cannot be obliged to do so. How do you plan the implementation?
8. I never met these concerns, and I think the solution is worse and more complicated than the problem. If you have such a problem in enwiki, you may set a local policy.
Bináris^{tell me} 06:09, 16 April 2023 (UTC)[reply]

@Bináris: Before you accuse me of enwiki bias, please understand there was a second steward signing on to this. Beyond that, a third steward has already supported this. The issue is not with enwiki, and frankly, enwiki already complies with this proposed policy. The issue is other smaller wikis. The other angle here is that checkusers should be staying up to date what's going on with CU. It's very frequently changing. So are we going to permit a CU to edit once every two years without taking an admin action or a CU action to retain CU indefinitely? Because that is what the policy permits right now. The policy only asks for 5 log entries. Not 5 individual investigations, but 5 log entries which can be obtained through 1 single investigation very easily. So 1 investigation a year, and that is too much work? That's going to encourage people to break the rules?

CUs would not have any additional duties (especially that are enforced) than what the policy currently requires. It's untrue this gives extra tasks. -- Amanda (she/her) 07:07, 16 April 2023 (UTC)[reply]

"So are we going to permit a CU to edit once every two years" Please dont pretend I told this. To oppose the obligation for running frequent checks and to let someone "to edit once every two years" is by no means the same or similar, and I don't like if somebody tries to alter my words. Additionally, CU changes are not so frequent and not so basic. Tell me one changes of the past years that would have been a serious problem for somebody who deals with IT or programming.

In my CU carrier there were happy times when I did not have to make 5 checks a year, because huwiki was a peacuful place. And there were times to run more than 5 checks per week. You definitely don't consider these periods.

Anyway, I wrote 8 points, and there is no point in further arguing 2 of these while the proposal has more opposes than supports. Bináris^{tell me} 08:02, 18 April 2023 (UTC)[reply]

Why is not enough to check himself in order to follow the changes of CU? Bináris^{tell me} 06:07, 19 April 2023 (UTC)[reply]

Because of guys like me who checked themselfes for over 80 times within 1,5 years. [1] (I also have regular checks on suspected socks) Der-Wir-Ing ("DWI") talk 12:12, 19 April 2023 (UTC)[reply]

Amanda said: "The other angle here is that checkusers should be staying up to date what's going on with CU. It's very frequently changing.". Not speaking about that changes are far not so frequent and basic, and if a newly elected CU can learn them, we may suppose this about an old one, what is the proof that self-checking is not enough to notice these changes? Bináris^{tell me} 09:03, 8 May 2023 (UTC)[reply]
Oppose Proposal does not cover worst case scenarios, like number of overall checks are not enough to lead to five checks per CU. This might lead to competition between CUs, lead to time pressure, inaccurate checks and are especially endangering the validity of administration in smaller projects. Potential bullying of volunteers are also expected by this policy.--Maphry (talk) 06:14, 16 April 2023 (UTC)[reply]
Oppose I have thought long and hard about this, long before this RFC came up. This issue has been raised on Ombuds several times. We have had to reach out to confirm whether some CUs even still made an appearance. I am in a difficult position here with this RFC as I potentially have a COI in commenting on it. I am a CU on Wikispecies for the last 6 years and I am the first to admit that the nature of that wiki does not attract the type or level of CU issues that ENWP attracts. What we do get are experts in their fields with chips on their shoulder who try to push for consensus on their world view. Using LTA's to accomplish this. These are not random vandals and honestly identifying them to the point where we can justify a check is difficult and requires expertise in the subject area of the Wiki. So yes we do not get a lot of these but they are very difficult to identify.

Switching gears and speaking as an Ombud, I recognise the issue at hand here and support the notion that something needs to be done. But a quota system applied to a proceedure that can in fact break the law if used inappropriately I think is inherently risky and could end up with more cases going to the OC or even Legal. This could put pressure on CUs from smaller wikis in particular to not excersise due dilligence with respect to the CheckUser Policy for no other reason than to meet their quota. Perhaps some periodic examination of whether their is enough demand for a wiki to continue to have these rights would be a better option, rather than put it on the CUs themselves. Examine the need for the tools by the wiki in question and not the CUs. I do also agree with checking in on CUs who do not apppear to have done anything for a long time. The OC has done this recently with several people,some with no Checks in years.

In summary I support the idea of looking at this issue and yes its real. But I cannot support a quota system on such a serious issue. Scott Thomson (Faendalimas) ^talk 06:37, 16 April 2023 (UTC)[reply]

@Faendalimas: First, I'll direct you to my reply above to Bináris. I'll highlight that this is not an enwiki consideration, nor do I have any sort of expectation that all wikis should have the volume of enwiki. Since your primarily speaking as an Ombud, I'll address that. The quota is 5 log entries. Just 5. It's not a large amount that is going to require people to make more checks.

Beyond that, you suggest that the OC has 'checking in' on CUs with minimal activity. The OC doesn't have an ability to remove someone for inactivity. You also say you have thought long and hard about this. Back when I was on the OC, I raised this issue. The issue died in process. But you have since thought about this. So in the 2 years that you have been the chair of the OC, and doing nothing (the status quo) has been your optimal solution to the problem? Now, you propose that examining this on a per project basis is a good idea. How would that work? You can put a quota on that too...but we are back to your concern about people inflating the numbers. So lets then say we do it by just our thinking that a wiki looks inactive...then we open ourselves to bias claims that we don't like the wiki, and the overall proposal fails in the global community because it tries to punish the CUs that keep up activity vs. props up those who may not be pulling their weight. So what's the proper alternative that the OC hasn't looked into in over 2 years with this being a problem? -- Amanda (she/her) 07:31, 16 April 2023 (UTC)[reply]

@AmandaNP: I agree with your response to Bináris I do not think you were implying anything with respect to ENWP or that you think there should be comparable volume. Regarding the OC. I am aware you raised this when you were on the OC. There is not a lot I can do on the OC about this at present. The OC currently is restricted by our mandate which as you know is to investigate breaches of the 4 policies we oversee. Among those relevant here is the CheckUser Policy. As such we investigate breaches of the policy. Technically not doing any work as a CU is not a breach of the policy. We have had discussions on this issue and occasionally someone raises a particular CU who seems to have been sitting on the tools for years and all we can do is check what they have done and confirm with other CUs whats going on. Yes under those circumstances there is nothing we can actually do. I cannot mention names but in a recent one we were asked to check and we wrote to another CU from the wiki to confirm the working arrangments between the CUs of that wiki. What can we do next. The person has not breached policy. So by "checking in" on this all we have done is if someone is brought to our attention we have gathered information. You are correct we cannot remove the tools from them. Letting people who do not use the tools keep them is a security risk, I totally agree with this. I agree with addressing this issue. I agree this is a hole in the policy. I guess what I am getting at is the only people who should directly have the tools taken off them are those who have breached the relevant policies. But I was thinking on my feet as I respnded but maybe each wiki should be examined to see if they need direct access to the tools with local CUs. It is basically a risk assessment, these people have done nothing wrong, but there is nothing wrong with controlling the availability of high risk tools based on demonstrated need. Who would do this and how that should be done, I do not know. We have discussed if we at the OC should take a more proactive role, nothing decided I am not proposing anything here, but its never gone further than some brief discussions. Also for the record if Wikispecies does not have valid justification for the tools fine, remove them, but do so based on a per wiki per need assessment. I am not a fan of a quota system thats why I opposed, to me thats also a risk assessment. But please do not think I disagree with you, this does need to be solved. Cheers Scott Thomson (Faendalimas) ^talk 08:05, 16 April 2023 (UTC)[reply]

Support: But we should have some provision for small projects to avoid them being always around the limit of activity. Let's say we implement the clause Risker proposed: xxwiki had 10 CU checks from stewards in 2022, they elect 2 CUs, they make 6 and 8 checks each in 2023, they keep CU, they make 4 and 5 checks each in 2024, one of them gets dropped. I think this flip-flop would be undesirable. I wouldn't care if it happens once in a while, but if the chances of this happening frequently are high, then something needs to be tweaked. Let's say we implement this rule and remove the current inactive CUs: how many projects had less annual checks than 2 x 5 x # of remaining CUs? --MarioGom (talk) 08:07, 16 April 2023 (UTC)[reply]

The way I read the proposal, if the small wiki had 2 CUs with 4 and 5 checks in 2024, both would be dropped because of the "at least two CUs" rule. Ivanvector (talk) 21:51, 17 April 2023 (UTC)[reply]
Oppose as per Maphry and MBq. If I would have just 4 checks after 11 months and have another request assigned to me, the pressure would be high to make the much needed 5th check. 'Meeting the quota' besides general activity (e.g. edit count) is not useful in this case. - Squasher (talk) 08:14, 16 April 2023 (UTC)[reply]

@Squasher Making a CU action with the sole motivation of keeping the CU bit would likely be a violation of the CU policy (which specifies what can CU be used for, and usage for keeping one’s rights is not allowed). It feels wrong to oppose a policy change because people might violate the policy. Martin Urbanec (talk) 09:35, 16 April 2023 (UTC)[reply]

It doesnt necessarily need to be the sole motivation. If I am 50:50 undecided if the check is justified, this detail could very likely give the deciding edge to make the check. Mandatory activity must not interfere with such decision-making, but we are humans, so we should avoid such a situation. The core issue itself is obvious to me, don't get wrong, and a reasonable solution is needed. The proposed solution just isn't one in my opinion. - Squasher (talk) 10:51, 16 April 2023 (UTC)[reply]

Thanks for the clarification. I still think that if a CU can finish an investigation without making a check, then that check shouldn't be made (regardless of whether it would help meet any activity criteria) though. However, I'm wondering, what kind of alternate solution do you imagine? I find it tricky to solve the issue of checkusers possibly being out-of-touch with CU norms, because they haven't used the tools in years, without tying inactivity to number of checks (tool usages) made. But I might be overlooking something! Martin Urbanec (talk) 12:55, 16 April 2023 (UTC)[reply]
Oppose CU activity can also consist in rejecting non-appropriate checks, and this would not be counted as activity at all in this policy. --MF-W 09:45, 16 April 2023 (UTC)[reply]
Support, as a co-proposer. The currently implemented activity policy is virtually defunct -- for the lack of clarity, it is interpreted as "total inactivity for a year", and users who were appointed CheckUsers generally make more than one edit per year (which doesn't indicate anything about their activity as a functionary). I can't get into specifics, but there are situations where CU is regularly used by only one CheckUsers (other CUs not making a single check in years). This is wrong, and it goes contrary to the idea of "at least two CUs per project, or none at all" -- the policy change proposed in this RfC fixes it. I'm not wed to the particular numbers AmandaNP and me suggested, but clearly, a year of total inactivity is way too little to avoid such situations. --Martin Urbanec (talk) 09:54, 16 April 2023 (UTC)[reply]

I'd support raising the "one action" per year threshold. — xaosflux ^Talk 10:03, 16 April 2023 (UTC)[reply]

@Xaosflux Would you support raising it to “one CU action per year”? Or raising to N actions per year (including edits)? Martin Urbanec (talk) 10:05, 16 April 2023 (UTC)[reply]

@Martin Urbanec I'd be open to values of N<=50 for "N actions per year" on the project as a measure of activity/inactivity of a contributor for this purpose. — xaosflux ^Talk 17:02, 16 April 2023 (UTC)[reply]

I'm wondering what your definition of "action" is. I'm asking, because this proposal does define inactivity as "[less than] N actions per year", where N is five. Martin Urbanec (talk) 17:31, 16 April 2023 (UTC)[reply]

@Martin Urbanec for this purpose any edit or any logged action, not exclusively checkuser actions (this proposal requires 5 checks during any 12 month period); I think if someone isn't doing much of anything at all, they are inactive. — xaosflux ^Talk 19:58, 16 April 2023 (UTC)[reply]

Understood. I find that problematic for several reasons I briefly mentioned in my original post, and which I described in more detail privately (I cannot get into specifics here at this point). Martin Urbanec (talk) 23:58, 16 April 2023 (UTC)[reply]
Oppose think this will encourage frivolous checks as proposed. The problems this is suggested to solve from the opening are that there isn't auditability - but that can be happening without generating more checks (such as by reviewing logs to ensure that the other checkuers are not running inapproriate checks, this does not generate more checks), and also that there are inactive accounts that are checkusers creating possible security problems - but this isn't looking for inactive accounts. I think there could still be improvement, but not as proposed. For the later, a general "inactive" accounts requirement could be used, not tied to this specific action. If there are other goals, they should be better specified (such as reasons why an entire project shouldn't have checkusers due to overall project non-use). — xaosflux ^Talk 10:02, 16 April 2023 (UTC)[reply]
How about requiring all projects with CU elections (rather than appointment/removal by Arbcom) to run reelections after a certain time? Most projects seem to elect their checkusers for an indefinite term, reelections would make it at least more likely that checkusers are active community members. --Johannnes89 (talk) 10:14, 16 April 2023 (UTC)[reply]
Oppose Unnecessary checks don't force anyone zu control checks of others. In de-WP, we elect CUs every two years, if anyone is inactive, he or she would not be reelected. Perrak (talk) 10:54, 16 April 2023 (UTC)[reply]
Oppose In projects that have regular elections for this function, it is unnecessary because inactive users are not elected. Rather, projects that are appointed for life should consider whether regular confirmation of the function might not make more sense. --Itti (talk) 11:10, 16 April 2023 (UTC)[reply]
Oppose Sorry, but that’s like terminating police officers if they haven’t made a sufficient number of house searches per year… --Brettchenweber (talk) 11:13, 16 April 2023 (UTC)[reply]

Regular elections and a minimum number of edits (edits, not CU actions) might be useful. Brettchenweber (talk) 14:13, 16 April 2023 (UTC)[reply]
Support 5 checks is basically one investigation. (Get IPs for account 1, get IPs for account 2, and look at the edits for a shared IP or three). Again, this 5 logged actions, not 5 investigations. If a project is so small that two CU can't do this once a year, the stewards should take over the responsibility. Beyond that, I have serious concerns about how technically up to date tiny project CUs are of the changes in the abuse landscape on Wikimedia wikis. --Guerillero ^{Parlez Moi} 11:41, 16 April 2023 (UTC)[reply]

For people who are going to use Amanda's home project as a foil, I would point out that a good quarter of en-wiki's arbitration committee would forfeit access to the CU tool through this policy. We are not the winners here that some are trying to make us out to be. -- Guerillero ^{Parlez Moi} 11:51, 16 April 2023 (UTC)[reply]

@Guerillero it looks like Amanda has specifically exempted those sorts of users from requiring activity (the counter argument is that they would just reappoint themselves every year anyway) - I think that is a different problem, but not something to solve this way. — xaosflux ^Talk 17:06, 16 April 2023 (UTC)[reply]
Oppose As per Xaosflux. I don't want to see any unmerited checks and checking to pander the stats, this can be dangerous as there are already admins doing actions to pander stats, if this spreads to CU the outcome might be a little worse. I do agree inactive CUs can be a problem, so I will think a total inactivity - no logged actions, no comments on local CU pages, no IRC appearance on CU channels, no mailing list discussions - this yardstick I can agree to remove the access as they have no interest whatsoever with CU area stuff hence they shouldn't hold the access as an hat. Camouflaged Mirage (talk) 11:48, 16 April 2023 (UTC)[reply]

@Camouflaged Mirage Hi§ Thanks for the comment. The good question is how to define "total CU inactivity". Using CU tools is simply to check for any Steward. Usage of (especially local) CU-specific discussion areas is nearly impossible to check. For instance, at my homewiki, we regularly discuss CU investigations in person or over the phone. That said, I wouldn't mind having a set of "approved" areas where CUs regularly appear (CU log, the wiki, CU-l, official IRC channel). It would make verification terribly manual, but it would at least be verifiable by an independent steward. Martin Urbanec (talk) 00:05, 17 April 2023 (UTC)[reply]
Oppose As per Krd, "the problem exists, but the proposal doesn’t solve it." Huji (talk) 12:16, 16 April 2023 (UTC)[reply]
Oppose. Per many above, that's not a solution. If you are concerned about security of CUs's accounts, make them all use 2-factor authorisation. If your concerns are that there're too few active CUs on small projects to review each other activity, than let that projects elect more CUs. Since sockpuppets' activity on different projects varies greatly, setting some hard quota of CU actions will encourage (or force) some CUs to do frivolous checks. Just like arrest quotas like "Arrest 10 thugs a month or you're fired" make police do frivolous arrests. Arado Ar 196 (talk) 12:51, 16 April 2023 (UTC)[reply]
Oppose Might prove useful for communities that do not have regular term elections for CU, but not for those that have. There should be different rules for the two. Regards, Aschmidt (talk) 12:58, 16 April 2023 (UTC)[reply]
Oppose - I don't think it's a good idea to mandate an action for being a checkuser. Better, then, to require periodic confirmation, as Johannnes89 suggested. Syunsyunminmin 🗨️talk 13:39, 16 April 2023 (UTC)[reply]
Oppose A minimum count of checks is a very bad idea. And it is also a very bad idea to just count checks. Rejecting a request is also a CU action. Chaddy (talk) 14:00, 16 April 2023 (UTC)[reply]

Yes, this is a very simportant argument! Bináris^{tell me} 07:53, 18 April 2023 (UTC)[reply]
Oppose -jkb- 14:28, 16 April 2023 (UTC) - per Krd, Squasher, MBq. Perrak, Itti et al[reply]
Support I'm not a fan of a minimum number of checks, but the level required is so low that if a project doesn't have sufficient problems to properly justify checks beyond the proposed activity levels, then it's highly questionable whether there should be local CUs on that project anyway IMHO. stwalkerster (talk) 14:32, 16 April 2023 (UTC)[reply]
Oppose There are strict rules, in some projects very strict rules, when a C/U is allowed to checkuse and when not, and in some countries those rules are resulting from local legislature, i.e. Datenschutz (which is not US "protection of data" but "protection of privateness"). You cannot enforce a level of activity, if this activity is reglemented by law. --Matthiasb (talk) 14:40, 16 April 2023 (UTC)[reply]
Support: any user not running five checks per year should have their CU access withdrawn, even if on some projects that ends local CU. The global policy implies that CU is only given as needed. Five checks is a good threshold for a project's need, although it could well be 2 or 4. Comments: (1) I am concerned that once established, in future the minimum requirement will be increased. I oppose any creep upwards, including changes to make the requirements more specific or elaborate. (2) If this proposal fails, an alternative could be to allow under-used CU access to be withdrawn by the Ombuds Commission (that includes me). That would allow local projects that are under-using CU to be assessed case-by-case. (3) Some comments suggest that CUs might be auditing or monitoring other checks, without running checks themselves. This opinion is expressed as an Ombuds, though not in an official capacity: 'audit-only' checkusers do not comply with the requirements of policy to have at least two checkusers. The two checkusers are needed because they will, in practice, duplicate one another's work in the course of dealing with requests and responding to abuse. The duplication is invaluable in flushing out ill-judgment and error. Merely monitoring the CU log is like assessing an aircraft pilot's skill by watching radar – you really need to be sitting beside them. AGK ■ 15:56, 16 April 2023 (UTC)[reply]

Concerning the risk of unmerited checks: any project skirting close to the minimum is likely to have each check scrutinised closely. Generally, it is bad policy-making to avoid a policy improvement because people might try to evade it. Unjustified checks, I assume, would be disregarded for the purpose of the minimum. Unjustified checks also per se justify suspension or removal of access. AGK ■ 16:03, 16 April 2023 (UTC)[reply]

@AGK Does your opinion on this extend to projects with more than 2 CU's where some don't perform checks (for example the ones this proposal is seeking to exempt from activity requirements)? I think that monitoring the CU log is certainly useful, as it could uncover CU abuse. — xaosflux ^Talk 20:12, 16 April 2023 (UTC)[reply]

Independent auditors holding the local CU right are useful, including for the reason you say. But they can't substitute for checkusers auditing one another naturally, in the course of the project's everyday operation. On larger projects, you have both, which is no problem, and indeed provides an added layer of scrutiny. AGK ■ 11:31, 17 April 2023 (UTC)[reply]
Oppose every little edit or button clicking is one that another person has noz to do any more Sargoth (talk) 16:07, 16 April 2023 (UTC)[reply]
Oppose - I believe that when it comes to local rights, decisions should be made by the local communities except where legal issues require otherwise (in which case the Foundation will decide this without asking us). And especially in smallish communities, you may have one main Checkuser, along with others who spot-check his results and respond to community claims of mistakes - summing up to less than 5 per year per Checkuser. Animal lover 666 (talk) 16:15, 16 April 2023 (UTC)[reply]
Support per Guerillero. This makes a lot of sense. This is basically one use of the tool in a years' time. Checking yourself, your bots, or otherwise testing should not be sufficient to 'opt out' of an activity policy. SQL ^{Query me!} 16:58, 16 April 2023 (UTC)[reply]
Oppose per Krd, Faendalimas, and Xaosflux. dwadieff ✉ 17:18, 16 April 2023 (UTC)[reply]
Support per Guerillero. BilledMammal (talk) 19:34, 16 April 2023 (UTC)[reply]

— Note: An editor has expressed a concern that BilledMammal (talk • contribs) has been canvassed to this discussion.

Strongest possible Oppose. This emergency tool is already being used far too much and too often. Introducing a mandatory quota now is a nightmare. That is just plain undemocratic. Wikipedia is not a surveillance state. This instrument may only be used with caution in selected cases. Catch and search quotas - the idea alone is pure horror. -- Marcus Cyron (talk) 19:39, 16 April 2023 (UTC)[reply]

It's not „mandatory“ and it's not a „catch and search quota“, but rather a proposed idea for making sure there are no inactive checkusers (because checkusers should be able to control each others CU activities). Even with the proposed change CU may still only be used in scope of the global & local policies.

If small projects simply doesn't have that much CU cases, they should probably not have any checkusers at all (like most small projects) and leave this to the stewards. Johannnes89 (talk) 19:46, 16 April 2023 (UTC)[reply]

I think this may be a useful metric (to possibly solve a different problem) - if a project has <N checks/period, perhaps it shouldn't require CU's. — xaosflux ^Talk 20:14, 16 April 2023 (UTC)[reply]

If you wanna know if a person is still active, just ask.Or bond it to other criterea than the worst ever possible. Marcus Cyron (talk) 21:11, 16 April 2023 (UTC)[reply]
Support We have processes for dealing with misuse of CU. We don't currently have a global process to deal with non-use by an individual CU, or for recognizing where a project no longer needs local CUs at all. On projects with an ArbCom monitoring CU use, there is at least a body empowered in principle to decide this. Likewise, projects that elect CUs for fixed terms can choose not to reappoint some or all of the CUs (although it may be difficult for voters to evaluate activity).

But for projects that elect CUs for indefinite terms, there is no meaningful way for them to say either "we don't think X is pulling their weight" or "actually, we don't need any CUs anymore." (Theoretically, fellow CUs could bring the former to the community's attention, but I only recall ever seeing CUs complain about their colleagues' misuse, not non-use. The CU policy says "the community can vote removal of access", but this is in a paragraph about "suspicion of abuses", and it also leaves unclear what the threshold for removal would be.)

As Aschmidt suggests, it might make sense to have this policy only apply on projects that elect CUs for indefinite terms. Or, as suggested by Johannnes89, we could do away with indefinite-term CU elections entirely, but the current proposal is more modest. Emufarmers (talk) 20:41, 16 April 2023 (UTC)[reply]

I would support a motion to change the policy that CUs have fixed terms. This takes care of two issues one if they are not doing the job they are unlikely to be re-elected and also if the wiki does not have the need its probably they could not keep meeting the election criteria also. I would hazrad either one or two year terms would be appropriate. Cheers Scott Thomson (Faendalimas) ^talk 23:33, 16 April 2023 (UTC)[reply]

Oppose. Checkuser rights should use a sparely as possible. If there is not need to check something it is a very bad idea to force the checkuser to run checks so he can remain his rights. --DaB. (talk) 20:47, 16 April 2023 (UTC)[reply]
Oppose I think that local communities should be allowed to locally handle activity requirements for local perms. — Red-tailed hawk _(nest) 20:54, 16 April 2023 (UTC)[reply]
Oppose Because of the legal aspects that come with checking users and that vary from country to country and because each project has different needs of CU functions, appointing and removing checkusers should be left to each project and should not be regulated with a cookie cutter approach. --Martina Nolte (talk) 22:19, 16 April 2023 (UTC)[reply]
Support And yes, I did read the entire discussion, and did not find any of the opposing arguments to be convincing; they were instead based on speculation that appears unlikely to happen and a form of idealism that history has proven did not work out. * Pppery * _{it has begun} 23:35, 16 April 2023 (UTC)[reply]

Still support this - the later opposes are mostly reiterations of the same points with no new arguments. * Pppery * _{it has begun} 19:13, 20 April 2023 (UTC)[reply]

OK. Und your ongoing support is based on new arguments, as we see. *gg*. Marcus Cyron (talk) 19:39, 20 April 2023 (UTC)[reply]
Oppose Not satisfied by the answers to "Will this change not encourage CheckUsers to run inappropriate checks?" Walt Yoder (talk) 23:40, 16 April 2023 (UTC)[reply]
Support, more in-line with norms for other permissions. I believe that more global policy regarding non-content matters is beneficial. I wonder if condition #1 could be amended to also specify doppelganger, alternate, etc, accounts, but my support is not conditioned on such. The argument that this would encourage unnecessary checks is also not convincing, as there are already robust measures and venues to prevent abuse. EpicPupper (talk) 04:34, 17 April 2023 (UTC)[reply]
Oppose I think this should be left up to the local community to decide.--BRP^ever 10:34, 17 April 2023 (UTC)[reply]

@BRPever Does your comment extend to cases when a community seems to be fine with having CUs who haven't used the tools for 5+ years? I'm borderline fine with that happening for +sysop, but CU is much more sensitive, due to PII access (plus, because a check/CU action cannot be undone at all; once you've familiarized with private data, you can't unfamiliarize, which requires CUs to be well-aware of current norms, something that is tricky to acquire with long-term CU absences). Thanks for clarification, Martin Urbanec (talk) 21:19, 20 April 2023 (UTC)[reply]

@Martin Urbanec My experience is that there are some communities which share the concern pointed out by Jasper below. I think communities which already have activity requirement for CUs, or those that do not wish to opt-in to this should be exempt from this.--BRP^ever 02:45, 21 April 2023 (UTC)[reply]
WeekOppose, although 5 checks per year minimum requirement seems reasonable, but encouraging user to comply with it on small communities seems unnecessary. similar to AAR both actively wiki editing checkuser could be enough instead of using checkuser.~aanzx ^✉_© 10:51, 17 April 2023 (UTC)[reply]
Oppose - leave it to the local communities - Jcb (talk) 15:32, 17 April 2023 (UTC)[reply]
Oppose - This is a nonsense proposal. Two concerns are purported: 1) auditing "only sometimes happens" and 2) "there is a security concern also when an account becomes inactive." The first is not at all addressed by the proposal. The second fails to consider alternatives such as two factor authentication, or even a mere activity threshold (an account making edits of any sort is inherently being supervised/not abandoned--measurement solely by CU tools is entirely unnecessary to address the "security concern"). The proposal thus not only fails to address purported concerns, but would do so in a way that both incentivizes unnecessary checks and removes a measure of sovereignty from local projects. It is difficult to imagine believing this a positive change. Эlcobbola _talk 17:46, 17 April 2023 (UTC)[reply]

On the other hand, I believe that it's a general principle in computer security that accounts should have all the privs they need for their normal activities, and no more. Keeping CU user rights when you are not using them at all does little more than paint a big "try to hack me first" sign on your account. Consider, e.g., the decision by some communities to keep the Interface administrators user right turned off normally. They set that right when you need to use it, not 24x365. Perhaps, if an individual CU doesn't appear to be using the right, it should be removed until such time as it seems likely to be used. This might not be the best proposal, but I think the general principle of privilege bracketing is sound. WhatamIdoing (talk) 00:07, 28 April 2023 (UTC)[reply]

You may not have read my comment, specifically "The second fails to consider alternatives such as [...] a mere activity threshold (an account making edits of any sort is inherently being supervised/not abandoned--measurement solely by CU tools is entirely unnecessary to address the 'security concern')." I do not for a moment believe that, in a hypothetical of two actively editing accounts, each with a CU flag but only one presently using those particular rights, a "hacker" would consider the "non-practising" CU to be wearing "try to hack me first" sign. This indeed is not the best proposal--it is a terrible one. Эlcobbola _talk 19:25, 28 April 2023 (UTC)[reply]

Question: - for wikis with two checkusers, if one is dismissed for inactivity, the remaining checkuser is also suspended since there have to be two checkusers. Does the remaining checkuser also have to be re-elected or re-appointed? Ivanvector (talk) 22:04, 17 April 2023 (UTC)[reply]

There has always been ambiguity in this situation (i.e. 1 of 2 CUs resigned - how long does the project have before they have to elect 2 CUs instead of 1?), however with this policy, after a year there could not be any such reappointment as they could not meet the activity policy. Rs chen 7754 02:59, 18 April 2023 (UTC)[reply]
Oppose At the moment, may support if some conflict parts with MediaWiki Code of Conduct resolved by establishing a new committee for this purpose. --Liuxinyu970226 (talk) 03:43, 18 April 2023 (UTC)[reply]

Would you mind explaining how this conflicts with the code of conduct? * Pppery * _{it has begun} 19:13, 20 April 2023 (UTC)[reply]

@Liuxinyu970226, I am also curious how "don't keep privs you aren't using" conflicts with "don't harass people in technical spaces". WhatamIdoing (talk) 00:08, 28 April 2023 (UTC)[reply]
Comment I already opposed above in 8 items. Here is the nineth: one of Hungarian CUs works as an Internet service provider and knows everything about Hungary's ISPs and knows people there. His help in interpreting the CU results is very valueable. This is also a CU activity which is not logged! But if you unCU'd him because he himself does not run enough checks, we would not have the right to ask him for help. So this solution which is really inadequate to the problem, would cause tremendous harm for us. Bináris^{tell me} 08:13, 18 April 2023 (UTC)[reply]
Oppose Could lead to unnecessary actions. Leave it to the local communities. --Zinnmann (talk) 08:43, 18 April 2023 (UTC)[reply]
Support I don't see CU as an inherently local permission. Like it exists locally, but IP information (and other private info) isn't going to be in a vacuum.
I also don't see why a project with 50% or more of their CUs make less 5 logged CU actions really need local CUs in the first place. English Wikisource gets along just fine without any CUs, so I don't see why this is a problem.
Maybe it might be more helpful (or really agreeable) for the minimum amount of logged actions be determined at a project level? It wouldn't really solve the problem of one CU being active and the other CU never double checking, but at least it's a start. –MJL ‐Talk‐^☖ 16:34, 18 April 2023 (UTC)[reply]

I'd also be fine with just requiring a CU to make a single logged action in a given year to just get anything preventing complete inactivity. That's a single check to ensure a user is not logged out editing and finding out that they weren't.
I'm all cool with keeping the bar low, but there should be a bar (there should be a standard). It's kind of weird how we don't require local Check Users to use the tools at all in order to keep their advanced rights. Projects should continuously be able to justify needing users in these roles, and if they can't do that (or stop being able to) then they really should rethink having them. –MJL ‐Talk‐^☖ 16:58, 18 April 2023 (UTC)[reply]
Oppose --MarcelBuehner (talk) 21:58, 19 April 2023 (UTC); I think it is a wrong approach to prescribe a certain number of checks to be performed during a given time period. CheckUser should perform checks according to the need and situation, not according to a minimum number specified in time. --MarcelBuehner (talk) 22:17, 20 April 2023 (UTC)[reply]

@MarcelBuehner Hi, please note this is a RfC/discussion, not a voting. In other words, arguments is what matters when an uninvolved Steward closes the RfC, not the number of supporters/opposers. You might want to include a reason with your comment! --Martin Urbanec (talk) 21:13, 20 April 2023 (UTC)[reply]
Strong oppose Encouraging users to run checks that might not otherwise be needed is grossly inappropriate, especially considering that the tool returns data that otherwise is deleted after 3 months.--Jasper Deng (talk) 01:55, 20 April 2023 (UTC)[reply]

@Jasper Deng In my opinion, keeping CU permissions when one haven't done a single check in years (we've CUs who didn't use the tools for nearly seven years) is also grossly inappropriate. I'm, however, not sure how else to prohibit that, apart from introducing a lower bound on tool usage. If you have any suggestions, happy to hear about them! 5 checks/year is a single investigation per year, which sounds reasonable to me. Have a nice day, Martin Urbanec (talk) 21:16, 20 April 2023 (UTC)[reply]

@Martin Urbanec: I would argue that if you are concerned with a particular CU's activity level you should nominate them for removal. This makes no sense as a global policy because of the need to go case by case; different projects have differing standards.--Jasper Deng (talk) 00:56, 21 April 2023 (UTC)[reply]
Abstain for now. I was leaning towards oppose per Krd and Xaosflux, but I'm unsure. Certainly, I don't want inactive accounts retaining checkuser rights, and I don't want a project with one unchecked CU (I am recalling recent discussion of how a certain LTA nearly passed RFA and was angling for CU on en.Wikipedia, and imagining if that happened somewhere less scrutinized). But I'm inclined to agree with the many users above who argue quota systems encourage making checks for the sake of making checks, especially if you know that if you don't meet the quota, not only will you lose CU rights, but your wiki's other CU will also lose CU rights (if she's doing most of the checks, you're mainly auditing them, and there are no other CUs on your wiki). On the other hand, in trying to think what alternative approaches might be better, I thought: what if whenever a CU is 'inactive' by the standard proposed above, the community is notified and has a chance to (hear if maybe that CU has in fact been active auditing but not performing checks, and) vote to remove the CU if they want... or even, what if the 'inactive' CU is automatically put to a reconfirmation vote and loses CU rights if they lose the vote... and then I realized, that's not so much different from just dropping their CU rights (and the wiki's other CU's rights) and requiring them both to be voted on again. As long as it'd be OK for a wiki to keep re-electing the same CUs that just lost their bits due to inactivity, I guess this proposal might actually ensure CUs continued to be active enough on their wikis to have the support of those wikis. -sche (talk) 03:50, 21 April 2023 (UTC)[reply]
Oppose This is partly written to much with bigger wiki's in mind. Also limits are just set per wiki, which doesn't make sense. What if a checkuser from let's say enwiki is also active on a smaller wiki, has checkuser there, should he be taken away checkuser on that smaller wiki, while he has the experience, just because there is not a lot to do. I would be more in favor of having local checks by for example the local arbcom. Akoopal (talk) 15:23, 23 April 2023 (UTC)[reply]
Oppose This proposal is way too enwiki-centric (and more towards larger wikis as a whole). Smaller medium-sized wikis (e.g. en.wb) often don't have the need to regularly use CUs, which could lead to deliberate sprious and frivolous checks just to meet the 5-check rule. --SHB2000 (talk | contribs) 06:24, 25 April 2023 (UTC)[reply]
- Not really. At de:WP we have only 2-year-terms and then elections/re-elections. So this also did not adress the realities at our Wiki. This has not necessarily to do with size. Just with the organization status. -- Marcus Cyron (talk) 09:26, 25 April 2023 (UTC)[reply]
  
  Okay, but my point still stands – it's centred for larger wikis (and by nature, larger Wikipedias), giving little regard to smaller medium-sized projects with CUs. SHB2000 (talk | contribs) 11:10, 28 April 2023 (UTC)[reply]
It's clear to me that some baseline global inactivity policy is needed. Martin Urbanec mentioned above that we apparently have checkusers who have not used the tool in seven years [2]. That indicates that those editors do not actually need the sensitive level of access that they hold; in other words, it violates the principle of least privilege. It seems that the main concern is that this will encourage checkusers to make tenuous checks just to meet a quota. I think that's a fair argument. What if we loosen the threshold? Perhaps 5 checks every two years, or three years? Or perhaps we could require checkusers in every community to periodically publish aggregate information about tool usage in a similar manner to w:en:WP:AUDIT/STATS. That way, individual communities can audit their own checkusers to determine if they still need the access they hold. Mz7 (talk) 02:06, 29 April 2023 (UTC)[reply]

Or we just stop to give user rights for a life time. Rugulary elections fix this problem. As we do at de:WP. Elections all 2 years. Inactive users will net be elected again. Marcus Cyron (talk) 07:08, 29 April 2023 (UTC)[reply]

I would be very much against this. It's up to the local community to decide this. One of the solutions might be to inform the community regarding the inactivity and letting them come up with a way to deal with it, or something like AAR.--BRP^ever 10:00, 29 April 2023 (UTC)[reply]

What is more worse? More democracy to these communities - or less? -- Marcus Cyron (talk) 12:45, 29 April 2023 (UTC)[reply]

@Marcus Cyron: CheckUsers need to have some independence in order to ensure impartiality and objectivity, much like court judges who are often not elected. The role is already a stressful one for volunteers who may face death threats for enforcing local policy and we do not need added load on the backs of right holders. The German Wikipedia's CheckUser policy is frowned upon by virtually all the rest of the languages and is not to be used as a model here.--Jasper Deng (talk) 07:56, 11 July 2023 (UTC)[reply]

Adding onto this, I just remembered that the stewards already publish similar aggregate information at Stewards/CheckUser statistics for loginwiki. Many editors above and below argue that local communities should be the one to review their own checkusers. To aid local communities in this effort, we should require local checkusers on all projects to publish the same kind of aggregate statistics. Mz7 (talk) 01:51, 9 May 2023 (UTC)[reply]

@Mz7: I would respectfully counter that not using the tools is not evidence that you don't need the access. The principle of least access falters when there is a disagreement over "minimum access". It could alternately be implied that a "sudo" mechanism is needed whereby CheckUser access is obtained when and only when a check needs to be done. That's impractical, with my point being that the principle of least access cannot be used to support either side of this debate. The only metrics that do not encourage spurious use of the tool are those that do not depend on how often one does checks. Involvement in local socking investigation processes is a much better proxy, but since those are not standardized there is not a way to make a global policy about this that results in automatic removal. What could still globally address the problem of having someone with the tools inactive for seven years would be to set a time based metric and have proposed removal: if no checks or edits in something long like 3 years, then that would trigger a talk page notification on the local wiki; if they do not reply to that message in a set amount of time (say 6 months), then removal can proceed, otherwise the matter is deemed to be a local affair.--Jasper Deng (talk) 07:56, 11 July 2023 (UTC)[reply]

@Jasper Deng: I would be happy to discuss this further, but I also get the feeling we have long passed a w:WP:STICK point for this particular RfC, and it's pretty clear that no global CU inactivity policy is forthcoming. Mz7 (talk) 04:23, 12 July 2023 (UTC)[reply]
Oppose this creates an incentive to misuse CU. It also seems cumbersome to check whether a use of CU is for "testing purposes", which couldn't be determined manually (surely?). I don't necessarily oppose removal of the tools based on inactivity, but that could be determined by number of edits in a time period. — Bilorv (talk) 09:02, 30 April 2023 (UTC)[reply]
Question: What activity is considered one check that counts towards the 5 required checks per year? Just one “tool usage” (one request) or one investigation? A single large investigation – e. g. involving a large number of suspected sock puppets – could easily require 5 or more requests. Do they all count, even if they are part of the same investigative process and perhaps even conducted on the same day? Troubled @sset ^{[ Talk ]} 09:49, 1 May 2023 (UTC)[reply]
Oppose - Regardless of project, per User:Bináris, this is absolutely not how you retain good CU's and a quota system is inappropriate. Especially because it'd be difficult to regain those rights after a period of inactivity. Not all Wikis require the constant use of the CU tool, not to mention that use of this tool has to be done very carefully and scrutiny is imparted on those who use it. And this proposal mandates 5 CU uses a year (with specific requirements behind when it can be used at that)? No thanks. Per above, let this be resolved locally because a blanket rule like this isn't going to end well. That Coptic Guy (talk) 19:23, 1 May 2023 (UTC)[reply]
Comment I see a gap in practicing the proposal in Wikipedia language editions. As others said, there is not much work to do with CUs in small wikis. In contrast, it is unacceptable for a CU in large wikis to have a few edits in a year. I recommend changing the proposal to adopt the wiki editions by editor sizes more than to have many waste-of-time arguments here. A l p h a m a ^Talk 01:16, 3 May 2023 (UTC)[reply]

Again: this is not acceptable! At de:WP we have CU/OS/B-Elections biennially. We sort out those people by ourself. And we have strict rules für using the tools. It is inacceptable, that an other rule comes over us from outside. This attempt at influence is intrusive, unnecessary, and only leads to more frustration among more volunteers. Marcus Cyron (talk) 14:04, 3 May 2023 (UTC)[reply]

For years, Meta has had a tradition of honoring and valuing local communities, granting them significant autonomy. However, this approach can sometimes result in increased bureaucracy compared to establishing a universal standard across all language editions. I have observed many instances where local communities have expressed their dissatisfaction with having to voice their concerns on Meta [3] instead of within their own communities due to the bureaucratic processes involved. Personally, I find it unacceptable that a few edits in a year for a CheckUser (CU) in a large language edition would be considered adequate. A l p h a m a ^Talk 16:26, 3 May 2023 (UTC)[reply]
Oppose This is essentially encouraging inappropriate checks for smaller wikis. Quotas shouldn't be implemented to keep access. If anything, inactivity by an editor with local rights should be handled by the local community whenever possible. EggRoll97 (talk) 19:52, 8 May 2023 (UTC)[reply]
Oppose mainly because we don't have enough CU's for elimination via "quota". I'm basing this exclusively on personal experience at: Steward_requests/Global_permissions#Requests_for_global_IP_block_exemption where I put in a request for IP block exemption, but noticed a backlog where people appear to have not been assisted with this since mid-April. On English Wikipedia, the request is made via email to CU's, and I don't know what the backlog is there, but I have been waiting just as long as my case with the stewards on global, so I can imagine it must be similar. I have not checked, but it would not surprise me at all if the CU's (especially on enWiki) had backlogs in other areas too. If CU's are eliminated from lesser active projects, then CU's from more active projects will be taking up the burden of those extra loads, and they can't even keep up with the job they already have in front of them themselves. [According to the FAQ on this proposal that could be up to more than a 12% increased workload.] I also agree with the points made by other opposers here. Huggums537 (talk) 23:24, 13 May 2023 (UTC) Comment updated on 23:40, 13 May 2023 (UTC)[reply]
Oppose – a fearsome idea – it is a local issue and the best CU is a CU which isn't necessary –see also Bináris, Maphry, DaB, Matthias etc --Trollflöjten^αω 15:33, 14 May 2023 (UTC)[reply]
Support Dwain 08:59, 16 May 2023 (UTC)[reply]
Oppose per Elcobbola. ~~~~
User:1234qwer1234qwer4 (talk) 18:39, 16 May 2023 (UTC)[reply]
Support --Novak Watchmen (talk) 19:33, 16 May 2023 (UTC)[reply]
Oppose per Krd and Xaosflux. Let the local stuff be managed locally as is said for everything. ─ The Aafī ^{^(talk)} 16:45, 22 May 2023 (UTC)[reply]
Oppose - The result of this proposal would be the removal of many small-wiki CUs. I think there is value in keeping them: many smaller communities have tightly-knit communities, so checkusers (even those who don't have frequent occasion to use their access) may have more local context/institutional memory that would be lost if their access is removed. Similarly, many community members may be less comfortable going to Meta to request some random steward investigate rather than going to a local user that they trust. They may not even have enough knowledge to go to Meta, while they are able to access local CUs through other means (like a Telegram channel). As I've said to many of these proposals in the past: I just don't see a need to deprive smaller communities of advanced access more than we already do. Stewards can always check on wikis with local CUs if needed in emergencies or to address cross-wiki problems, so the existance of local CUs should never actively interfere with anything under our current policy framework. – Ajraddatz (talk) 19:17, 23 May 2023 (UTC)[reply]
Support - I think this is very fair. All other groups have a requirement to fulfill their respective duties so CU should not be any different. I too have seen the conversations (mentioned above) about editors from other wikis having issues with the administrative (for lack of a better word) volunteers. For those who are opposing this your solution is pretty easy. Make sure the CU is doing their jobs they were elected to do by looking at their contributions and hopefully you will see them placing a CU block notice or responding to possible sockpuppet complaints on your respective boards. 2600:8801:CA05:EF00:B8AD:279A:C136:BF69 00:38, 25 May 2023 (UTC)[reply]

First: would you please log in? Second: you talk about global active right holders. We talk about local CUs. Marcus Cyron (talk) 09:48, 25 May 2023 (UTC)[reply]
Support. Removing inactive users is for everyone's security.--Jusjih (talk) 01:37, 25 May 2023 (UTC)[reply]

The request is not about inactivity. Marcus Cyron (talk) 09:46, 25 May 2023 (UTC)[reply]
Support. Not giving sensitive rights to people who don't need them is an important aspect of any security system. – bradv🍁 14:47, 26 May 2023 (UTC)[reply]
- Support. Per Bradv. --Ooligan (talk) 06:33, 21 November 2023 (UTC)[reply]
Support --Coffins (talk) 15:15, 2 June 2023 (UTC)[reply]

Oppose Too many gray-shaded WM communities that would be affected as not enough cases are produced (even worse if only one CU checks them all).--A09 (talk) 13:27, 6 June 2023 (UTC)[reply]

Support per bradv. --Victor Trevor (talk) 16:11, 16 June 2023 (UTC)[reply]
Oppose because I think that is bad for medium and small wikis. Not using rights is not misuse of rights. Perhaps there is another way to avoid security problems. For instance, I do agree with the periodic checks. --Tmv (talk) 11:45, 23 June 2023 (UTC)[reply]
Oppose - I appreciate what is trying to be done here, but forcing someone to make CU checks - that is, looking at private information - just to retain the tools, seems like a bad idea. And reading the thoughts of those above, both for and against - several of whom, hold my sincere respect - suggest to me that while this seems well meant, perhaps it's not the way to go for this specific tool. Unlike something like deletion or blocking, this is a tool where the action cannot be undone. Once someone sees the private info, they cannot then "un-see" it. And the stories we've been hearing about abuse, especially on some smaller wikis, does give me pause. I think the suggestion for reviewing current requirements for granting (and use) might be a better first move. - Jc37 (talk) 00:31, 3 July 2023 (UTC)[reply]
Oppose - leave it to the local communities --2003:C7:DF1D:6400:914B:816F:463C:773F 15:38, 6 July 2023 (UTC)[reply]
Oppose As others have written, this is not the best solution to the underlying problem. Moreover, such a rule should not be implemented in wikis that have a working Checkuser re-election mechanism. --Filzstift (talk) 09:59, 10 July 2023 (UTC)[reply]
Oppose Judging the activity of a CU by only counting his checks is silly, especially, when you plan to include a mechanism, that can not be opt-outed by small wikis, that perhaps simply don't have enough CU-cases, to give every CU "his 5 checks" per year.--Emergency doc (talk) 21:15, 18 July 2023 (UTC)[reply]
Support I have always believed that if you have a certain flag then you should be active in its use. I wrote the initial policy regarding inactive admins on simple wiki. If you don't use it, you should lose it. fr33kman 17:10, 27 October 2023 (UTC)[reply]

Additional comments[edit]

There are a few issues that aren't well-covered in this RFC that deserve the attention of the broad, global community.

If a project doesn't need the services of a checkuser on a regular basis (at least several times a year), then it probably doesn't need to have its own checkusers. Many *large* projects have no checkusers, relying on the services of the stewards for the occasions that they require that type of assistance. This is, after all, what stewards are for. [This is only partially addressed in the RFC]
Lack of consistent training and oversight is an issue, as has been seen repeatedly through the reports and actions of the Ombudsman commission. Given that all Wikimedia accounts are SUL, this has the potential to cause adverse outcomes on users who may be mistakenly blocked and/or identified as a sock on a project they don't frequent. [This is not addressed at all]
Over 80% of projects have so few vandalism or socking issues that they are easily addressed by 10 or fewer administrators. These encompass both small and middle-sized projects. It would be very difficult to justify having 20% or more of the administrators on a project having the CU bit; if they have that big of a socking problem, local CUs aren't enough to solve that issue. As an aside, there is not a single project right now that has local CUs and fewer than 10 administrators which pretty much refutes the theory that *any* "small wiki" projects would lose their current local CUs. [Not well addressed in the RFC, and responds to some of the points in the discussion]
There is a genuine security concern about expansion of the global CheckUser corps, as they have access to cross-wiki data on an ongoing basis.
Current standards for projects to appoint a CheckUser team is ridiculously low, and has not been updated since nearly the creation of the tool, despite all the changes in policies, the SUL project, the external pressures of privacy legislation, and so on. I think the primary focus should be more on the requirements projects need to meet before considering appointing/electing CUs than on whether or not the existing CUs achieve a certain level of activity. Activity can be looked at once we've sorted out which projects should and should not have local CUs.
- Having local CheckUsers is NOT a right of each project. The service is provided, in orderly and appropriate manner, by stewards, as it has been since stewards were first given these rights.

--Risker (talk) 02:23, 24 May 2023 (UTC)[reply]

I think these are all interesting points that are probably worth looking into. - Jc37 (talk) 00:31, 3 July 2023 (UTC)[reply]

I'm more in favor of updating the CU policy in line with what it takes for a project to have CU's at all, more than dealing with individual community members. — xaosflux ^Talk 16:38, 11 July 2023 (UTC)[reply]

A point-by-point rebuttal:

That is not the case, because local communities have different standards for what warrants use of CU and stewards are neither truly available 24/7 nor are they usually familiar with the local community. Local CheckUsers do not have that drawback, no matter how infrequently they use their rights.
This is orthogonal to this proposal. Global training should be offered and required, but would not be addressed by an inactivity policy.
Over 95% of projects don't have the community to have local CheckUsers, including the vast majority of those for which 10 admins or less deals with vandalism and socking issues.
This is a concern to be addressed by amending election requirements in the global CU policy, not by a one-fits-all inactivity policy.
It's not "ridiculously low". Some large wikis would struggle to elect local CheckUsers if it were increased to, say, 40 support votes. Only on the very largest wikis like enwiki is that low bar, but those wikis also tend to use arbcom for appointment instead.
- "Orderly" is not a correct descriptor considering that steward coverage is highly biased towards the European day, greatly slowing down investigations of east Asian or western hemisphere cases for those wikis without local CheckUsers.

--Jasper Deng (talk) 22:17, 15 October 2023 (UTC)[reply]