Commons talk:Blocking policy

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

This is the talk page for discussing improvements to Commons:Blocking policy.
Archives: 1

Rewording the CheckUser block part[edit]

On 23:19, 25 March 2020, one of our admins undid a CheckUser block, one of his rationale being that Unblock requests for blocks marked with {{Checkuserblock}} will be reviewed by a checkuser. says that it is not required de jure for a CheckUser block to be reviewed by a checkuser, because of the word will. Despite this however, it seems de facto that CheckUser blocks should only be undone by checkusers themselves. I think we should prevent this from happening again, therefore I propose to change "will" to "must". pandakekok9 03:13, 26 March 2020 (UTC)

To be honest, I'm somehow confused. The reason why CheckUsers should review CU blocks is that they have access to the same level of data their fellow CheckUsers do, and so they can decide whether the CU block was justified or not. But there are two unblock requests for CU blocks: 1) the blocked user claims that they have not created a sock account, and that there has been a mistake in the CU process. 2) The blocked user accepts that they had one or more socks/alternative accounts (they accept the result of CheckUser), but they request unblock because they think the block itself is unjustified, even if they have socked. I think there is a big difference between these two: the first one must be reviewed by a CheckUser; it's actually double checking the first CheckUser's action. The second one, however, is a rather administrative decision. In the first case, the CheckUser action is controversial. In the second case, the administrative action, the block, is challenged. The CheckUser tool can reveal many things (it's not only limited to IPs), but it doesn't say if you need to block a user because they have created one or more sockpuppets or not. It's like when a CheckUser checks two or more accounts, confirms that they are sockpuppets, but doesn't block them (e.g. asks administrators to take action). The blocking administrator doesn't necessarily have access to CheckUser data, they just decide if the use of alternative account(s) was in line with the policy or not. Ahmadtalk 23:06, 26 March 2020 (UTC)
  • As above, a CU block is supposed to be reviewed by a CU because it may be based on non-public information that others do not have access to. My procedural concern in setting a precedent is when this become construed as not "a block" only one made by someone with additional access to information, but rather when it becomes effectively a super block, one made based on publicly disclosed information, only rendered a CU block because the action was performed by a CU.
You cannot unblock this user. You cannot comment on an unblock request. This is not subject to any consensus or community review, and if you do try to discuss it we will block you too. We feel no need to explain our actions. Don't bother to ping us. We also claim exception to the deletion policy, the protection policy, and the ability to enact a banning policy ex nihilo.
That effectively renders the CU team as Commons:Arbitration Committee, a concept that has been repeatedly rejected by the community. GMGtalk 12:31, 27 March 2020 (UTC)
  • I echo what Ahmad252 and GreenMeansGo told. CUs should be held accountable. The policy should be amended to cover the second scenario explained by Ahmad252. 4nn1l2 (talk) 12:40, 27 March 2020 (UTC)
  • @Ahmad252, GreenMeansGo, 4nn1l2: My version indeed will be prone to abuse by a rogue CU, as pointed out by Ahmad and GMG. How about this: Unblock requests for blocks marked with {{Checkuserblock}} may be reviewed by an admin who is not a checkuser only if the blocked user doesn't object to the findings of the CheckUser but oppose to the block itself. pandakekok9 12:57, 27 March 2020 (UTC)
    Good to me. Better than the current wording. 4nn1l2 (talk) 13:05, 27 March 2020 (UTC)
  • No, that doesn't quite work. Consider a scenario. I want to upload in-scope pictures of my home town, but I don't want to out myself. So I register an alt for privacy reasons. Suspicions are raised somehow and a CU is performed. They connect my two accounts, but what they also do is realize that I've developed a nasty meth addiction on the weekends and taken to vandalizing and harassing users as an IP. CUs can publicly connect the two accounts, but they can't connect me publicly with the IP for privacy reasons, which is the actual problem where I am violating policy. They can't confront me publicly even for me to confirm or deny.
What they can do however is indicate unequivocally (preferably in the block log) that there is additional pertinent non-public information. If the community doubts this, then they can go to the Ombudsman who can review the information and confirm. If they will not confirm this, then it is not a CU block in a meaningful sense. It's just a block done by a user who happens to be a checkuser, based on public information. GMGtalk 13:10, 27 March 2020 (UTC)
@GreenMeansGo: In this scenario, CUs can at least inform the community that some IPs are also involved, without mentioning the actual IP numbers. Communication in needed. 4nn1l2 (talk) 18:04, 27 March 2020 (UTC)
And no reason to think it will be forthcoming that I can see. GMGtalk 18:17, 27 March 2020 (UTC)
@4nn1l2: Communication is always good but in some ways the hands of the CU are tied by the CheckUser policy. I suspect it would need to be clarified because otherwise the failsafe will operate (if in doubt, don’t reveal). -Green Giant (talk) 18:03, 7 April 2020 (UTC)
I expect that most people who have been active with OTRS have dealt with the issue of community relations with regard to non-public information. Maybe I'm in the minority, but I don't really see that it's that difficult to maintain open good-faith communication with the community while respecting privileged information. Half of the problem with all of this has been an utter lack of communication. That is not merely a standard expected of CUs and administrators, but a standard expected of all users. GMGtalk 13:43, 8 April 2020 (UTC)
I agree with Jee. If we are going to update the wording (which is needed), we should have a full section so any ambiguities are removed. The Oversight section looks like a good example. —-Green Giant (talk) 17:52, 7 April 2020 (UTC)
  1. Policy needs clarification to be absoutely clear who may review a checkuser block.
  2. To remove complete ambiguity, a full section should be written.
  3. We want to clarify policy, but we have concerns about giving checkusers absolute power to review their blocks, and think there should be exceptions.
  4. A process for direct review and scrutiny needs to be developed.
  • Issues #1 and #2 are easy fixes. I have proposed a section below, please comment and wordsmith. For #3, I think it is dangerous territory to explore exceptions in which case a non-checkuser may review a checkuser block. It puts an administrator in a tight situation where they may easily find themselves operating in the dark while they think they know the whole story. Regardless of what the scenario is, we need to remove complete ambiguity - this will not be accomplished by saying if x is y, a non-checkuser can unblock. X and y are grey variables and we will find ourselves in this situation again where an administrator is called to the stand and questioned in front of the community. We cannot afford to lose more administrators whether by walking or removal of permissions. The root cause of why you are all proposing exceptions is because you do not trust in the system due to a lack of #4. I think we need to focus on #1 and #2 right now, recognize that #3 & 4 is an issue and separately tackle them. Let's not blur policy and put administrators at risk of losing their permissions rather than directly address a systematic issue of a lack of policy (we don't even have an SPI policy) and scrutiny. Those are two big issues that will take a lot of work. For now, I can only refer to Green Giant's suggestion to encourage more people to stand as candidates. It sounds to me like some fresh blood is needed to put some trust back in the system. ~riley (talk) 19:39, 8 April 2020 (UTC)
Proposed section

Checkuser blocks[edit]

Checkusers may need to block an editor, on the basis of technical checkuser evidence, due to disruption caused by abuse of multiple accounts or IP addresses. These blocks must be marked as a {{Checkuserblock}} in the block log summary and must not be reversed by non-checkusers.

As checkuser data cannot be shared publicly and a checkuser block may involve other pertinent non-public information, an unblock appeal for a {{Checkuserblock}} must only be reviewed by a checkuser. A reversal of a check user block by an administrator may result in the removal of permissions.

  • Well, there is still the issue of oversight. Any way you cut it, Commons doesn't have an arbitration committee and doesn't want one. m:OMB has a limited mandate, and at some point runs into the en:FISC paradox: you can't enforce oversight regarding non-public information when you require access to that non-public information in order to enforce oversight. At the same time, Commons doesn't have an ARBCOM and doesn't want one, but without some oversight mechanism, the functionary team is effectively an ARBCOM, empowered to issue sanctions which have no appeals process, with no policy-based standard compelling communication with the community, and not in any way subject to community consensus.
There is the possibility of forming a local OMB: a panel of community members who are temporarily granted CU access only in cases where the community requests review of CU actions. But that probably runs straight into the issue that comes up any time someone discusses unbundling of advanced permissions: if you could be elected to a local OMB, then you should just run for CU and skip the middle man all together.
I would much rather that this had all been handled a great deal better, with at least the appearance of consideration for the community, and this wasn't a problem we needed to talk about solving. GMGtalk 11:15, 9 April 2020 (UTC)
The local OMB sounds like a good idea to me. Just because you could be elected to a local OMB doesn't mean you automatically qualify for CU permanently. Quite the opposite I think. A local OMB watches the CUs if the latter can't watch themselves. If the local OMB becomes a CU and the issue is about CU abuse which happened during the time the local OMB is CU, there would be conflict of interest. A CU shouldn't be allowed to be a local OMB until 3 years have passed since they are no longer a CU. pandakekok9 05:56, 10 April 2020 (UTC)
@GreenMeansGo, Pandakekok9: This is great discussion and I like how you guys are going outside of the box here in trying to address this problem. I seriously like where this idea is going but I also have some concerns with how it could be made an effective system. That said.. Addressing the concern of scrutiny and a process for direct review is not going to be accomplished by this discussion; I fully agree it does need to be addressed though. That will take a lot of discussion, consensus building and a community RfC to figure out and implement. Can we steer this discussion back on track to improving the blocking policy? If we can keep this discussion focused on improving the policy, and building consensus here on the talk page, I think we can avoid a long-drawn out RfC for this policy. Where do you guys think we can take the discussion of building a direct review/scrutiny process? I think this needs a place of it's own where we can really dig into it. In the meantime, do you have any comment on the above-proposed revision? ~riley (talk) 19:36, 11 April 2020 (UTC)
Since I initiated this discussion to clarify the CU blocks and prevent future unfortunate incidents like an admin reversing a CheckUser block due to literally interpreting "may" as "may", I have no problems with your version, other than the possibility of abuse. But those issues should indeed be solved through another discussion first. I agree we have to address issues 1 and 2 immediately. Thank you for helping us improve this policy. pandakekok9 01:44, 12 April 2020 (UTC)
  • Pictogram voting comment.svg Comment I think this proposal is a good attempt to make clarity on the CU Blocks. This will help the CUs to stand strong and to save further admins from running into the troubles as ~riley stated above. I understand the concerns raised by GreenMeansGo above and Natuur12 in some other places. I remember such concerns were there while we were setting up the "Oversight blocks" part too. Oversighters acted without any formal prior community approval first, and then repeated. Then one of the OS stepped in to initiate a discussion. Still there were a lot of resistance; but we ended up in a policy update. Now we need one for the "CU Blocks" too. It is better to have a policy to avoid the vagueness which will help the CU/OV teams to act firmly with confidence in a timely manner even if there may be some lack of transparency.Jee 05:37, 11 April 2020 (UTC)
  • Thank you Jkadavoor for digging up those archives; this is something I was not aware of. ~riley (talk) 19:36, 11 April 2020 (UTC)
  • I have some concerns regarding this. It's quite frequent for the functionary team to consult other members of the team before making a decision. That's why we have mailing lists, IRC channels, OTRS queues and private wikis for them (to my knowledge, there is a CheckUser wiki, and there are also wikis for ArbCom members). Because of this, sometimes the entire CU/OS team members decide to take an action based on the private data. There should be something that can review such blocks. In this recent case, an important factor was a misunderstanding where a comment was interpreted as a death threat (I used to think of it that way as well), and there are apparently other misunderstandings as well (e.g. death threats toward the CU team while there is apparently no evidence indicating that). There are two key differences between the English Wikipedia and Commons, in terms of CU blocks: 1) the English Wikipedia has an ArbCom; and 2) there are 43 CheckUsers on the English Wikipedia, while there are only 5 here on Commons. I'm not being specific about the current CU team. I support having more CheckUsers, but regardless of that, I think we need something that can review CU/OS blocks. Maybe, in special cases, administrators can consult at least one CheckUser and ask if there has been any significant private evidence (e.g. other socks) other than what that has already been revealed, and if there isn't such evidence, review the unblock request themselves (read more about this at my comment above). Maybe we need the "local OMB" as explained above, or maybe something totally different. My point is that we should have some means to review CU blocks. That being said, I think it doesn't actually make much difference if we change the "will" to "must" in the policy. I agree that, based on the current policy, CU blocks should always be reviewed by CheckUsers. Ahmadtalk 01:08, 12 April 2020 (UTC)
    • @Ahmad252: Did you read the above-proposed text? What are your thoughts on it? It is a considerable change as opposed to just changing "will" to must". I quite agree that we need a process in place for direct review and also need additional CUs. Where do you think is the best place to discuss this further? COM:VP? ~riley (talk) 07:29, 12 April 2020 (UTC)
      @~riley: Yes, and I support it, as it clarifies things. I think the spirit of the current policy is to forbid non-CUs from reviewing CU blocks. Therefore, I think it's a good idea to replace the old wording with this section to avoid possible confusion, at least for now. Thanks for proposing it, works for me.
      The best place would be the village pump, I guess. Policy talk pages would not be enough, and the administrators' noticeboard isn't that relevant. Ahmadtalk 13:26, 12 April 2020 (UTC)
Since nobody seems to oppose riley's proposal here, I will be taking this to VP/P. pandakekok9 06:50, 18 April 2020 (UTC)
Proposed at Commons:Village_pump/Proposals#Proposal:_Modify_block_policy. ~riley (talk) 07:18, 18 April 2020 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons_talk:Blocking_policy&oldid=421417739"