Talk:CheckUser policy/Archive 5

Please run Special:PageMigration here

To migrate the translations, as we have migrated the Oversight policy, thx. --Liuxinyu970226 (talk) 02:33, 25 March 2015 (UTC)

Well, it's not as simple as just running that. There are lots of other things that needs to be done and it requires a lot of time. This page has more translations than OS policy too so more work needs to be done here. I'll maybe migrate this page one of these days when I have some spare time. --Glaisher (talk) 05:24, 25 March 2015 (UTC)

Bumping? 1 year and 9 months past. --Liuxinyu970226 (talk) 09:13, 25 December 2016 (UTC)

New steward practice?

[1] Sorry, but this just seems silly to apply to all projects. We have hundreds of projects with fewer than five active editors. Those projects shouldn't have to meet some arbitrary requirement for "discussion" of possible socking (most of which is spam production anyway). And let's be honest, stewards are doing those checks and blocking those accounts anyway. The broader community is responsible for coming up with the criteria, and it shouldn't be a discussion on a closed mailing list. The lack of a community discussion in communities with a small number (or no) editors shouldn't be the reason that a steward refuses a request for CU. Risker (talk) 04:31, 4 April 2015 (UTC)

@Risker: There is no change of practice, that edit should not be taken in isolation, the bigger change should be taken in account with Avraham's prior edit, and the better diff would be this. If you can think of improved writing that takes into account the long held wording, go for it.  — billinghurst sDrewth 04:43, 4 April 2015 (UTC)

It is a change in practice, and it is routinely ignored as well, though. Immortalizing a non-existent practice is terrible practice. And again, this is a very negative change for very small communities, which make up the majority of our projects. Risker (talk) 04:50, 4 April 2015 (UTC)

A policy change should come about through consultation, not edit creep. If you would prefer we go back to the pre-Avraham edit and restart the conversation. To note that the stewards conversation was that changes to policy should be made by the community, not by edit creep, hence the readdition.

The reality is that we never to rarely ever get CU requests from the small communities, we get them from the mid to larger without checkuser access. It is not unknown for (disgruntled) users to bring their requests to stewards without involving admins. The larger communities with checkusers have (community discussion) processes for requesting CU, so should we have the same rights for input on these mid to large size wikis? Instead your position could be that we only have discussion held at meta (hidden away) rather than where existing communities can see and have input.

There is no change of practice for stewards, it is about having an enabling policy where stewards can enable community input contrary to a policy that does not.  — billinghurst sDrewth 05:05, 4 April 2015 (UTC)

Well, that was the opinion of you and one other steward, even though James OKed the change. But by all means, edit war over the wording on the page. Regardless of what the policy says, there is no way that any steward in their right mind would request community consensus before performing a check, and no way we would honour a request to CU a user based solely on community consensus. As for the need for community consultation to bring this page up to current practice, I'll start an RfC tomorrow sometime to clarify these parts and also the loginwiki. Hopefully we can establish some sort of consensus instead of staying in limbo on these issues. Ajraddatz (talk) 05:19, 4 April 2015 (UTC)

"There is no change of practice for stewards" that is completely false. Maybe not a change in Billinghurst's practice, but no other steward follows that. --Rschen7754 16:12, 4 April 2015 (UTC)

I don't think such practice can be enforced. In case of uncontroversial checks (such as vandals or spambots) it will just take time to organise a local discussion (and the smaller is the community, the more time it will take to organise a meaningful discussion). In case of controversial checks (involving active users) there will most likely be no proper conensus, as an active user involved will naturally try to block the check. I think that instead of local consensus a better justification, and local discussion may be an option, but diffs by involved users or any other proof should be allowed as an alternative option — NickK (talk) 19:42, 4 April 2015 (UTC)

User:Billinghurst, if you are insisting that this "requirement" to have a local community consensus in order to fulfill a SRCU request is enshrined in the previous version of the policy, can you point to any sentences in the policy that back up your assertion? --Rschen7754 02:25, 5 April 2015 (UTC)

I am insisting on nothing beyond that a change to the policy is made openly by the community rather than by edit creep. If you are asking which bit of the policy disappeared the component is included in

“ If an insufficient number of voters vote for at least two CheckUsers on a wiki, there will be no CheckUsers on that wiki. Editors will have to ask a steward to check if UserX is a sockpuppet of UserY. To do so, simply add your request to Steward requests/Checkuser listing these users and explaining why you ask for such a check (with links). You also need a community consensus (like above). The steward will answer you if these two users are from the same IP, same proxy, same network, same country, or are they completely unrelated (see discussion for what the Steward should more precisely say to the editor). ” — Policy

my bolding in statement  — billinghurst sDrewth 03:17, 5 April 2015 (UTC)

Which is a bit different. Your text is "To do so, start by having a local discussion, as a form of community consensus", which is less inclusive than the wording "You also need a community consensus (like above)". (And it's not clear what "like above" refers to; certainly it can't require 25-30 editors supporting). For example, the community could have decided that socking was automatic grounds for CU in a local policy, like Wikidata did a while back. --Rschen7754 03:45, 5 April 2015 (UTC)

Maybe a bit off-topic, but I feel that this whole policy needs a new writting, of course, if there's community consensus for it and its approval. -- M\A 18:26, 5 April 2015 (UTC)

That and the OS policy too; I think there were some points made in the ML archives that might be useful. --Rschen7754 18:34, 5 April 2015 (UTC)

• I'm still not seeing the basis for saying that a community consensus, or even a community discussion, is required before stewards will consider doing a check. This is a new requirement that was not part of the initial expectations until...well, until a steward added it without discussing with the broad community. While local communities may have such rules (in fact, I believe even some communities with their own checkusers have such rules), they are local rules, not rules governing the entire Wikimedia constellation of projects, and they are unenforceable and undesirable on small wikis. They are probably unenforceable and undesirable on many "medium-sized" wikis (those with 20-200 users). I sense that what has happened is that some stewards are familiar with local rules for some projects they work on and are trying to impose those rules on other projects. Risker (talk) 22:29, 5 April 2015 (UTC)

  Risker. You are missing the aspect that it has always been in the policy since the beginning, and it was removed by copy edit, and it was returned. Now we are back to the original policy. There has been no change in practice and we are still at no change in practice.  — billinghurst sDrewth 22:36, 5 April 2015 (UTC)

  And I think you're missing that it was removed in the first place because it has no place in common practice. Instead of reverting it saying that discussion is needed, why not be positive and start that discussion? Ajraddatz (talk) 23:17, 5 April 2015 (UTC)

  Billinghurst, please provide a recent example of "There has been no change in practice and we are still at no change in practice." - specifically, where another steward besides yourself has declined a SRCU request for there being "no consensus" to run a check. --Rschen7754 00:26, 6 April 2015 (UTC)

  I have always thought that our policies are descriptive, not prescriptive, i.e. they describe common practices, not prescribe them. Ruslik (talk) 16:09, 8 April 2015 (UTC)

  Exactly, Ruslik.

  1. More stewards than not (a consensus, perhaps) already have expressed that "community consensus" is not part of their decision process when they decide to accept or reject a CU request.
  2. Requiring that discussions are held prior to requesting a CU on Meta would impose an extra, and unnecessary, burden on the small and medium wikis who require stewards to perform checks. Unnecessary, as the stewards, in my experience, have shown that they are pretty good at deciding which requests are valid and which are not without the need for extra bureaucracy.
  3. Not that it makes that much of a difference, but WM Legal did approve the change. Moreover, some, if not all, of our larger projects with internal CU processes (for example: EnWiki, Commons, Simple English, if Google Translate worked, then so too DeWiki, ) do not require "consensus" or discussion; merely a request. The CU (or clerk) decides whether or not to follow up on it.

  In summation, this is not "policy creep" but "policy clarification" as it reflects what I believe most of the stewards do (the consensus behavior, dare I say). It, combined with the other changes I made, makes more sense than the words that were there before, it is in line with how CU is used on other large projects, and it is accepted by Legal. To leave confusing verbiage, including words which are not carried out in practice, for the sake of no change without bureaucratic process is counterproductive in my opinion, and the clearer version I posted a few weeks ago should be used without further bureaucratic bloat. -- Avi (talk) 02:54, 14 April 2015 (UTC)

  Whether stewards choose to enforce that provision or not, or to what degree or method they choose to enforce it can vary. But we can't just remove a significant phrase like that from a global policy, even if we don't like it. It is a community policy and the fact that it was apparently discussed on a private mailing list is irrelevant as that cannot be used to gauge consensus, since private mailing lists are not open to all community members. --Rschen7754 04:57, 14 April 2015 (UTC)

  The historical reason (two revisions, @Anthere: and then @Datrio:) given for the addition of the phrase in question was "…probably means that no request may be done by one user only (but must be approved by others) and a motive always given.". It was from a time when Meta (and most projects) were much smaller than they are now. Moreover, it is no longer relevant as it is now handled by having an explicit reason given in the request, and the check run by a second party (the steward). I continue to believe that to enforce it would be counterproductive, bureaucracy for the sake of bureaucracy, and as it is more honored in the breach than the observance, it is time that it is removed so that the policy matches the practice. -- Avi (talk) 06:14, 14 April 2015 (UTC)

It has been about a week with no further responses. At this point,is there any reason not to bring the wording in line with what is the common practice? -- Avi (talk) 21:23, 21 April 2015 (UTC)

• With no further responses to the statements above, there appears to be no significant opposition to my restoring the wording I added previously, supported by a plurality of respondents, and approved by the WMF. -- Avi (talk) 21:22, 27 April 2015 (UTC)

Checkuser request

I hereby request to verify that I am not User:The Last Honest Man or User:2600:1017:B40B:560:5923:E719:3E34:A508 because I have been blocked for this false reason. 92.225.94.224 14:54, 2 October 2016 (UTC)

This is not a place to request a check. If you want to ask for a check on English Wikipedia you have to place the request over there. -- Tegel _(Talk) 15:01, 2 October 2016 (UTC)

Thanks for your answer, but I am blocked there and even my talk page, so I have no other possibilyties at all than here. https://en.wikipedia.org/w/index.php?title=User_talk:92.225.94.224&action=history It is really very discouraging to be blocked for no reason. 92.225.94.224 15:05, 2 October 2016 (UTC)

I can't go into the reason why you are blocked on another wiki. If the talk page access is removed, have a look here if that can help you in any way. This is the talk page for the CheckUser policy and not a place to discuss individual checks. -- Tegel _(Talk) 15:09, 2 October 2016 (UTC)

IP-block

Some users seems to not be able to think through the consequences of blocking whole ranges, and block telecom providers in their own country. I'm not quite sure how this should be handled, but when someone with access to IP-blocks hear that they can do a IP-block and be rid of a minor problem they think this is safe. Please DO NOT tell them to do so. A range block like /16 can easily escalate to several thousand users if they are NAT'ed. I even have examples on users blocking more than a million addresses and claiming that it is safe because some CU-user said so. Of course you don't. — Jeblad 19:16, 2 October 2016 (UTC)

As someone who's been doing this a lot I can say that my solution was to forward the affected users (via the block reason) to a page like this one, so they at least know what's wrong and what can be done about it. That being said, I mostly block that way networks, which are unlikely to host local users: not national and—at least as much as it can be guessed from whois and other similar info—not end-user networks, but rather collocation, hosting, etc. For the national networks and those that seem end-user related, the blocks are much shorter in duration and relaxed in their restrictions, but there is still an appropriate page with explanation and instructions. While this solution is far from ideal, it seems to work reasonably well for our project, cutting significantly on the open proxy vandalism and harassment with few complaints so far. But it likely wouldn't work that well on more active projects, where also many users are expected to edit from abroad, and it'll certainly not work at all on e.g. the English Wikipedia or Commons.
— Luchesar • T/C 06:28, 7 October 2016 (UTC)

Jakobludwigfelixmendellshon block

i beleive that check user is complete rubbish.It blocked me for no reason--Jakobludwigfelixmendelsshon (talk) 13:33, 13 January 2017 (UTC)

The CheckUser extension can't block you. There is always some user behind of it, and blocks are not doing without a good reason. --Stryn (talk) 19:33, 13 January 2017 (UTC)

Porque não permitem criaçõe de contas? João Thiago Camosso Tchivela (talk) 02:22, 21 September 2017 (UTC)

Só quero resposta João Thiago Camosso Tchivela (talk) 02:22, 21 September 2017 (UTC)

Limited Checkuser for all users?

I think it would help prevent sockpuppets a lot more if all users had a limited check-user-like ability. Now, clearly not all users should have access to the actual content of the check user information (they shouldn't have access to the underlying technical data including client IP address, HTTP user agent, cookies, etc.). Instead, what if all users had the ability to see if any two accounts had ever shared the same client IP address? All you would get are "plausible" (they shared the same IP at least once), or "impossible" (they never shared the same IP). It wouldn't prove that the two accounts are actually the same person (more detailed look at the technical data by an actual check user would be needed for that along with their behavior), but it would be enough to at least examine it closer. Also it couldn't be used when one of the accounts is an IP account (as that would reveal the underlying technical data about the non-IP user). Can anyone identify any potential privacy problems with this? -Obsidi (talk) 18:31, 5 May 2017 (UTC)

too long

maybe 75 days. not 90

If anything it is too short. We have massive families of socks carrying out undisclosed paid editing work / spamming Wikipedia. We should really be considering lengthening it. Or at least saving data from large families of socks as when blocked they do not go away, they just change their tactics. Doc James (talk · contribs · email) 01:05, 30 July 2017 (UTC)

actual login

does check user log the actual log in? what about the log out?Shrian (talk) 00:02, 12 July 2017 (UTC)

They do not log logins. Ruslik (talk) 18:12, 30 July 2017 (UTC)

RfC

A RFC concerning this policy has been created and is being discussed at Requests for comment/Clarification to CU policy. —MarcoAurelio (talk) 12:27, 4 August 2017 (UTC)

CU policy - local

Hello, can any wiki make it's local CU policy, or all wikis must responds to the global one?

For example before few months in ar.wiki we define (Any user account with CheckUser status that is inactive for more than 6 month will have their CheckUser access removed.) in global one it's (one year) --Alaa :)..! 19:53, 1 January 2018 (UTC)

Yes, local communities can make local CU policies, but they can only be more strict than the global policy. For example, you can choose to shorten the inactivity requirement, but you cannot lengthen it. – Ajraddatz (talk) 19:55, 1 January 2018 (UTC)

@Ajraddatz: Thanks --Alaa :)..! 20:15, 1 January 2018 (UTC)

No problem! Good luck in the policy-making process :-) – Ajraddatz (talk) 20:16, 1 January 2018 (UTC)

Retention of data for cases resulting in indef blocks

Does Wikimedia keep data related to indefinite check-user blocks? Sometimes it does, but there is no such effort systematically. Look at Steward requests/Global/2018-05 #Global unlock for Solomon203 who did not yet. We see that check-users from en. and ja. wikipedias have nothing to say about the case. The account was globally locked and only a miraculous coincidence of factors caused the stewards to reverse. Check-users either squandered the data on Solomon203 or can’t now find them, and recently one the functionaries was busy arguing against me – not surprisingly, as they have nothing to review. A similar situation on c:Commons:Requests for checkuser/Case/Chyah. Trijnstel, a member of Wikimedia authorities, did nothing but referred to some SPI in fa.Wikipedia. Coincidence of which namely accounts did those Persians establish? There is a large IP range covering a geographically significant territory—hundreds km—and the case is further complicated by the use of proxies. Who of Commons admins or the Ombudsman commission did see those data?

Looking for a responsible admin to help with pushing for improvement in the current policies. All data related to check-user blocks, and especially to blocks against users with significant contributions, must be kept for no shorter than one year. Data for high-profile cases should be kept forever. Incnis Mrsi (talk) 12:56, 3 June 2018 (UTC)

Data retention guidelines is probably what you are looking for. — regards, Revi 14:08, 3 June 2018 (UTC)

Just for the record since the incompetence of en.wiki admins and functionaries is being discussed: the block above was reviewed today and Bbb23 found the account to be technically indistinguishable. (Also pinging Green Giant so he is aware of the local results.) TonyBallioni (talk) 14:46, 3 June 2018 (UTC)

@TonyBallioni: Thank you for the ping. To clarify, I've not seen any CU data on Solomon203 but the account was unlocked based on the arguments presented at SRG, and to facilitate unblock appeals on three wikis. I have avoided commenting on the block appeals to stay impartial. I cannot say if Solomon203 is NDC or not but I defer to the opinions of people better-placed to comment. Green Giant (talk) 15:39, 3 June 2018 (UTC)

Bbb23 may perfectly be right that two Solomon203’s en.Wikipedia edits in June do not make him technically distinguishable off hordes of the Nipponese Dog’s puppets storming Wikimedia servers from a huge pool of Taiwanese IPs. Guys, I speak of retention of data from October–November in this case. You must have some notion of statistics and should understand why large data samples are important. That’s exactly the point I made. Incnis Mrsi (talk) 17:11, 3 June 2018 (UTC)

CU-only accounts and their inactivity?

On bgwiki we're discussing a local CU policy (translation). The current proposal allows the CUs to have a separate user account for the CU-related (and possibly admin) rights only. My reasoning for this was that CU is rather more sensitive in its nature than all the other local rights (except, to an extent, for the interface-admin). At the same time, we tend to stay logged in with our “ordinary” accounts for very long time periods and often not only on one device, which inevitably makes such accounts more vulnerable. Sure, 2FA mitigates this problem substantially, but another layer of security rarely hurts. If the separate CU account stays logged off most of the time, being used only when CU checks are being made, then, together with the 2FA and, obviously, a strong password (and possibly tightening a bit the password reset with the new functionality to require the email address as well, which could have a random “ ” extension added to it), should provide an even greater peace of mind.

However, here's the problem: the global policy says “Any user account with CheckUser status that is inactive for more than one year will have their CheckUser access removed.”

I suppose that a reasonable explanation that this is a separate account of an otherwise active user, allowed by the local CU policy, with appropriate information on the user page, etc. would satisfy the stewards—as people—but since they also have their obligations as functionaries, not technically enforcing the policy might put them in some uncharted waters; “any user account”, the policy says—not “a user that is inactive”—must be stripped off of their CU rights.

So, TL;DR, should we possibly change the global policy here to rather refer to the inactivity of the user, not specifically of the user account? It's kind of a corner case, true, but I think it would make more sense this way. To me, it seems a bit rigidly phrased right now.

Of course, it goes without saying that the connection between the user accounts should be openly and unambiguously disclosed (this is even explicitly mentioned in the proposal for our local policy, although it's also kind of obvious, since the editors who vote need to know who they vote for). Or, in other words, the burden of proof would be entirely on the user—we are *not* talking here about forcing the stewards to go out of their way and perform some extensive checks if an inactive account is associated with some active user if that's not already clearly and unambiguously stated. It's just that if there's a clear connection between an active user and an inactive account, the stewards wouldn't feel compelled to remove the rights of the account just because the global policy explicitly says so.

Now, an argument could be made here, I guess, that it would be more confusing to have such separate accounts. But I think that having two (or, in some cases, even more) accounts is a generally accepted practice when there are good reasons for it and when this is publicly disclosed. However, there may be other reasons to not encourage people to have a second, CU-only, account. If you know such, or could think of some, please, do share them.

Thanks,
— Luchesar • T/C 12:15, 1 July 2020 (UTC)

If someone hasn't used the CheckUser tool in a year, why should they not have the userright removed? ST47 (talk) 19:38, 15 July 2020 (UTC)

ST47, that's a good question, even if about something slightly different. The policy has a requirement for any account activity, not specifically for CU activity. IIRC, this was explicitly discussed at some point in the past and the consensus was that the CUs shouldn't feel forced to do checks to keep their rights—even if otherwise there are no cases that justify such checks. Such counterproductive “CU misuse encouragement” would be especially pronounced in the relatively smaller projects, where the number of cases that clearly justify CU checks may fluctuate a lot. On bgwiki, for example, we've had years with literally hundreds of strongly suspected sockpuppets, and also years with almost none. It wouldn't make sense to strip the otherwise active (as editors/sysops/'crats/etc.) CUs from their rights just because this year there hasn't been enough cases for each one of them to do at least one check, when the very next year they could, contrastingly, be even overwhelmed with the number of required checks. And the whole point of requiring activity is really more about: (a) knowing that the people with such rights are, indeed, around and can react when and if their help is needed, and (b) knowing that they hadn't abandoned their accounts, which could have security implications.
— Luchesar • T/C 10:11, 16 July 2020 (UTC)

Login attempts

According to phab:T253802, it looks like the CheckUser tool already records login attempts (both successful and failed), which is not mentioned yet here. I propose the changes below:

-Determine from which IP addresses that an account has performed edits, logged actions, or password resets on the Wikimedia wiki;
 Determine from which IP addresses that an account has performed edits, logged actions, login attempts, or password resets on the Wikimedia wiki;
-Determine all edits, logged actions, and password resets that were performed on the Wikimedia wiki from a specific IP address (including users who were logged in with an account);
 Determine all edits, logged actions, login attempts, and password resets that were performed on the Wikimedia wiki from a specific IP address (including users who were logged in with an account);

In fact, if there are even more kinds of information are missing and should be mentioned, the list would be too long and we might want to make the language here more open-ended instead (using something like "operations including but not limited to"). But I'm not aware of those, hence the proposal. whym (talk) 13:27, 15 February 2021 (UTC)

I went with the second change only. [2] I left out the first one because 'an account has performed...' implies someone already logged in. whym (talk) 10:17, 12 March 2021 (UTC)

Requests for comment/Ombuds Commission inactivity

I have started a RFC about the persistent inactivity of several members of the OC. --Rschen7754 02:01, 1 March 2021 (UTC)

Blocking of user without any checking, verifiable reason and evidence for Sockpuppetry

Hi all, I want to know what is the check user policy about Sockpuppetry and blocking of user without any verifiable reason and evidence. I want to know what is the policy of inspecting the user and closing it without providing a documented and valid document. Can the inspection manager close the user indefinitely without providing proof of inspection? And state the reason that "because your account is old and has not been active for some time and now your edits are professional", close it indefinitely and abuse this management opportunity. What is the policy if he does not provide documentary evidence of his abuse, and his violation? In Fawiki they have closed my account without any document Based on doubt only. I ask them to check with tools but they Refues it. Then I want to check global policy of wiki about this please. Thanks all. — The preceding unsigned comment was added by Shahramrashidi (talk) Hi all, Why anyone dont response? Shahramrashidi (talk) 17:42, 9 April 2021 (UTC)

you might want to contact the ombuds commission. See the Submission section in particular. whym (talk) 14:04, 15 April 2021 (UTC)

Hi all.

I sent a complaint to OC and reported that my account " shahramrashidi" has been blocked and banned in Fawiki as nominating Sockpuppetry, without any evidence. Even the user checking has not been requested by any in check user page. But the checkusers have blocked my account according to doubt only as their declaration. Which policy of WP tell you can block unlimited any user without evidence and with doubt only.

This is the response of OC: "The Commission is responsible for investigating complaints about infringements of the Privacy Policy, the Access to nonpublic personal data policy, the CheckUser policy, and the Oversight policy, on any Wikimedia project. The OC pays close attention to policies and their violations. Regarding the complaint relating to the block of User:Shahramrashidi for sockpuppet, the commission has found no violation of any of the aforementioned policies.

Shahramrashidi was blocked according to the Persian Wikipedia's (fawiki) sockpuppetry policy, which provides that a sockpuppet can be blocked without needing to identify the "sockmaster". The Commission is not an appeals body for blocks. The local community's appeal processes should be used in this case."

How do i tell and prove my account is not sockpuppet and the response of OC is about sockpuppet user only, then when my account is not sockpuppet, this policy is not applicable for my account. I asked OC to check my account is not sockpuppet and check users have abused from their facility and access, but instead of checking my account and their action has replied as a/m.

My question is can any check user block and bann any account as sockpuppet even it not to be sockpuppet? Who check this and stop their abuse? I never stop this to prove my account is not sockpuppet and check users abuse from their access. Please check my account in Fawiki and if my account to be sockpuppet, block me in all wiki projects else stop their abuse. Thanks Shahramrashidi (talk) 07:04, 4 July 2021 (UTC)

Should the test.wikipedia.org be added?

Hello, is there something missing, in the list of user with CheckUser access? The test wikipedia has two CheckUser accounts, too. Maybe, we can insert them into the list. --Indoor-Fanatiker (talk) 09:57, 6 June 2021 (UTC)

2 users with CheckUser access? 2 of the users in question have been inactive on that wiki for about a month now. DarkMatterMan4500 (talk) (contribs) 20:41, 6 October 2021 (UTC)

"must"?

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).

Is it a formal requirement that local communities must appoint a new CU immediately? I mean, if they don't want to, the only CU left will be demoted anyway, so there's no harm either. Not to mention stewards will always revoke both CU-ship at once. NguoiDungKhongDinhDanh 11:53, 29 May 2022 (UTC)

I've been thinking for a while that the wording of that section could be improved as it is not reasonable to require an immediate election. I discussed this with @Risker a while ago and she wrote w:User:Risker/Sandbox42 as a proposed rewording which addresses both the "must" issue you mention and, in addition sets a maximum time of CU-suspension. I'd like to open an RfC about it and get the policy changed on that point, but I'm a bit busy right now. —MarcoAurelio (talk) 18:55, 7 June 2022 (UTC)

@MarcoAurelio: sorry for slow reply on this. Yes I also agree this could be reworded to say something like "within 6 months" and in the meantime I think the remaining checkuser can request assistance from Stewards in order to meet verification requirements, or something similar. Cheers Scott Thomson (Faendalimas) ^talk 14:00, 19 July 2022 (UTC)

wording: "that"?

Hello User:Oshwah, hello readers all, how do you think about deleting the word "that" from the phrase "Determine from which IP addresses that an account has performed edits, logged actions, or password resets on the Wikimedia wiki;"? After the deletion, the phrase would read "Determine from which IP addresses an account has performed edits, logged actions, or password resets on the Wikimedia wiki;". I am de-N, en-2, maybe my point of view is affected by the 2 (<4) in "en-2". --Himbeerbläuling (talk) 13:18, 4 March 2023 (UTC)

Himbeerbläuling - I don't see the use of the word "that" in the particular sentence to be unnecessary. I think it supports the sentence just fine in this context, but I also don't feel that keeping the word is mandatory or essential in order for the sentence to retain the same meaning. I stand neutral with the idea of removing the word. ~Oshwah~^{(talk) (contribs)} 01:51, 13 April 2023 (UTC)

I think it's better without it and have removed it. Emufarmers (talk) 00:08, 18 April 2023 (UTC)