Wikipedia:Arbitration/Requests/Motions

Arbitration Committee proceedings

• recent changes
• purge this page
• view or discuss this template

Case requests

Request name	Motions	Initiated	Votes
Anachronist		16 June 2024	0/0/0

[edit]

Open cases

Currently, no arbitration cases are open.

[edit]

Recently closed cases (Past cases)

Case name	Closed
Venezuelan politics	25 May 2024

Clarification and Amendment requests

Request name	Motions	Case	Posted
Amendment request: Article titles and capitalisation	none	(orig. case)	7 June 2024
Clarification request: mentioning the name of off-wiki threads	none	none	4 June 2024
Amendment request: India-Pakistan	none	(orig. case)	7 June 2024
Clarification request: Contentious topics restrictions	none	none	10 June 2024

Arbitrator motions

Motion name	Date posted
Updates to appeals procedure	20 January 2020

Motions

Updates to appeals procedure

Foreword: this update changes the email address that some blocked users are given if they need to appeal their block to ArbCom. ArbCom has jurisdiction to "hear appeals from blocked, banned, or otherwise restricted users". In 2015, ArbCom decided that only blocks which were based on private or technical evidence would be appealable to it.

The volume of email – principally from {{Checkuserblock}}s – is still sizable. Last year, we received 215 appeals of which only around 12 were ban or sanction appeals.

Currently, the committee has a single email list that accommodates all committee business and email discussion. This update creates a secondary one that users will generally email directly, keeping the primary email list clearer for non-appeals business. Email directed into the wrong email list will still be handled. AGK ■ 12:57, 20 January 2020 (UTC)

Proposed motion:

The Arbitration Committee establishes a secondary mailing list for its correspondence, named arbcom-appeals-en. Users blocked or banned by the community for reasons that are unsuitable for public discussion (including blocks identified as CheckUser or Oversight blocks) may appeal to the Arbitration Committee only by emailing arbcom-appeals-enwikimedia.org.

For the avoidance of doubt, {{ArbComBlock}}s are applied by the committee itself and appeals should, therefore, continue to be sent to the main address for committee business, arbcom-enwikimedia.org.

The committee will try to forward misdirected appeals to the correct list.

This motion should be announced – at least at WP:AC/N, w:Wikipedia:Administrators' noticeboard, w:Wikipedia talk:Blocking policy, w:Wikipedia talk:CheckUser, w:Wikipedia talk:Sockpuppet investigations, w:Template talk:CheckUser block, and w:Template talk:OversightBlock – with the following:

The Arbitration Committee establishes a secondary mailing list for its correspondence, arbcom-appeals-en. Users blocked or banned by the community for reasons that are unsuitable for public discussion (including blocks identified as CheckUser or Oversight blocks) may now appeal to the Arbitration Committee only by emailing [email protected].

Appeals of an {{ArbComBlock}} should continue being sent to the main address for committee business, [email protected].

The committee is not changing the quorum or the procedure for deciding appeals. This change is broadly only a matter of mail management.

Vote:

For this motion there are 15 active arbitrators. With 0 arbitrators abstaining, 8 support or oppose votes are a majority.

Majority reference

Abstentions	Support votes needed for majority
0–1	8
2–3	7
4–5	6

Support

This is mainly a workflow improvement. –xeno^talk 14:49, 20 January 2020 (UTC)

I am indenting my support until it is supported by more of those who regularly take point on these requests (message moderation, acknowledgement, charting, etc.) as the testing has revealed it may actually make things more difficult. –xeno^talk 02:48, 7 February 2020 (UTC)

1. Der Wohltemperierte Fuchs ^talk 15:08, 20 January 2020 (UTC)
2. What xeno said. Regards SoWhy 15:18, 20 January 2020 (UTC)

   Minor tweak, no substantive change. –xeno^talk 18:22, 20 January 2020 (UTC)

   GorillaWarfare (talk) 00:14, 22 January 2020 (UTC) Moving to oppose, reasoning below. GorillaWarfare (talk) 19:38, 1 February 2020 (UTC)

   This should help with managing my inbox. – bradv🍁 16:37, 22 January 2020 (UTC)

3. For what it's worth, I find the arb wiki infinitely more useful for tracking appeals, but if this helps others manage their inbox, I'll all for it. Maxim_(talk) 16:59, 22 January 2020 (UTC)
4. I personally don't especially care whether we receive e-mails via one list or two, but if colleagues believe separating out the appeals e-mails will make things easier for them, that's fine. Also, there's no plan to confuse appealing editors with "paperwork" rules; if an editor appealing in good faith inadvertently sends an e-mail to the wrong list, we might forward it the other list but we'll still consider the appeal. Newyorkbrad (talk) 20:23, 23 January 2020 (UTC)

   AGK ■ 14:11, 24 January 2020 (UTC)

   Maintaining support. GorillaWarfare and Bradv are ignoring the fact that the number of misdirected appeals will be next to zero. AGK ■ 22:06, 1 February 2020 (UTC)

   Switching to oppose: AGK ■ 22:06, 11 February 2020 (UTC)

   If people write the committee about content related issues -- and I would estimate 1 in 6 appeals to ArbCom do not fall within our jurisdiction, why do you think the rate of error will be "next to zero" from the people who correctly contact will also always be at the right email address? Anyone with experience at OTRS knows there are sufficient rates of errors by the public in using the right queues. We also already see this on the OS, CU, and Functionary list... Mkdw ^talk 02:02, 2 February 2020 (UTC)

   Many of the incoming appeals are repeats from six months ago or longer. Just this week we received an appeal that was still addressed to arbcom-l. Changing the email address on {{checkuserblock-account}} will only get the fresh appeals, and not those who have attempted an appeal previously. I don't know what proportion that is, but it's not next to zero. – bradv🍁 02:10, 2 February 2020 (UTC)

Oppose

1. There are a number of reasons why I think this will have the opposite effect than intended. I have expressed these privately, but since we are voting on this publicly, I will repeat them here.
   1. Nearly the entire Arbitration Committee, if not all, conduct their work via email rather than in the Google Group interface. Everything received on Google Groups is forwarded to everyone's individual inbox and it there that most people work from; it all ends up in the same place. This does not create a segregated workflow unless you are solely using Google Groups. So, the proposal that this will create a separate workflow which is the entire reason for adopting this new system does not seem to practically apply. Maybe I am missing something obvious in which case I am happy to be wrong.
   2. One of the most problematic issues we have on the list are multiple threads about the same individual. Quite often, we will close one appeal but fail identify other threads 'in process' from the same person. This usually happens if they send us multiple inquiries or appeals with different subject lines and when we have a large backlog. Frequently, we continue on investigating and assessing the other threads only realize much later that it has already been dealt with previously. By having two emails which people can contact us, I expect our rates for duplication and multiple threads will greatly increase. Either from people emailing us on both lists at once, or someone who does not receive an immediate response so they try the other email not realizing it just goes to the same distribution list and inboxes.
   3. We have no way in Google Groups to 'move' threads into the other queue. The only way to 'sort' the two lists is for the thread to be forwarded from one list to the other. This will create a new thread in everyone's email inbox thereby providing a third way threads will become regularly duplicated. Everyone will have to delete the old thread in their inbox which I expect won't happen among 15 people. The moment someone does not realize this and replies to the original thread, it will re-create the thread in everyone's inbox again. For example, we get people who still cast votes on threads that have already been closed further up the chain.
   4. Approximately 1 in 20 emails sent to arbcom-en are not even for ArbCom to review. Maybe it is even higher. Usually they are complaints about content and we direct them to OTRS or the Village Pump. For the 19 in 20 emails correctly sent to arbcom-en, we should expect a decent proportion of these emails will still be sent to the wrong email. It is important to remind ourselves that the vast majority of appeals we receive are not from experienced editors who have an in-depth understand of Wikipedia and the Arbitration Committee, but rather from relative newcomers (appeals from editors with fewer than 1000 edits; a lot of newcomers who are CU blocked).
   5. More than half of emails we receive are sent using the on-wiki email system via the account User:Arbitration Committee. If we create another account, such as User:Arbitration Committee Appeals, we should realistically expect a certain number of people will not send to the correct account regardless of attempts for clear instructions. As previously noted, we already have challenges about people writing us about ArbCom appropriate matters let alone the right queue.

   Overall, I am absolutely for any system that will make our lives easier, but this really does not seem like it will do it. I am totally happy to be proven wrong, but at the same time if I think something is a bad idea and will actually make our lives more difficult, I should say something. I think this change will make an already complicated process even more challenging for the people we are trying to deal with and any benefits seem extremely minimal when compared to the number of downsides. Mkdw ^talk 03:57, 27 January 2020 (UTC)

   Mkdw: The main reason - for me - is so that my email client can be instructed to apply an appropriate label to the appeals, and for that category of email to be placed into a separate inbox from the main list. I realize that this will be far from perfect due to errors at origin.

   Other possible solutions would be asking appellants to use a prefix, but such an instruction will not be followed at least some of the time, or labelling the emails manually.

   As for "not using the Google Groups interface": is that a hunch or something you’ve determined from asking colleagues? The Groups interface is necessary for new arbitrators to catch up and I found it particularly useful in identifying appeals that had fallen through the cracks (by looking for threads with only the initial post). It’s far from perfect, I will concede.

   It’s amusing, but also a little sad, that the same workflow issues that we were grappling with in 2011 are still trying to be solved in 2020. I guess we never got that CRM, eh Risker? –xeno^talk 14:23, 1 February 2020 (UTC)

   I agree with Xeno here. If appeals come from a separate list, I can instruct my email client to filter them into a separate folder. Currently, I have to do that manually and every new email restores it into the main folder. That some people might not use the right address and some mails might be duplicated is not really that big of a risk imho. Worst that could happen is that you get all those emails in the same inbox like you do now already. So there is a chance it could make things easier and even if it doesn't, nothing would probably change in practice. On a side note, we already have multiple mail addresses and most people manage to use the main one. Regards SoWhy 14:46, 1 February 2020 (UTC)

   If it is a useful data point, I primarily work out of my GMail inbox. I'm not strongly opposed to changing my workflow if it is useful, but that is the habit I've built. GorillaWarfare (talk) 19:40, 1 February 2020 (UTC)

   Experience. We tried using tags to sort the status of appeals inside Google Groups and very few people adopted it. It required time to maintain the tags which was not being done. If this new procedure requires people to use Google Groups for it to efficiently work, including sorting, it should have been identified at the beginning as a material requirement of the new procedure and process. My feeling is that the "hunch" here was that the potential problems were inexplicably not going to be an issue or addressed. The request for the system to be even lightly tested and troubleshot in advance was ignored until now; there was no due diligence to ensure that this was going to be a good idea and everyone would adjust their workflow. Mkdw ^talk 01:50, 2 February 2020 (UTC)

   I was under the impression that messages could be moved from one queue to another during the moderation phase. If that's not possible, this could result in an even messier situation than we have now. I've struck my vote while we figure this out. – bradv🍁 15:11, 1 February 2020 (UTC)

   I was also under this impression. Is there some way we can find out for sure? My googling has not turned up much. GorillaWarfare (talk) 19:19, 1 February 2020 (UTC) Update: I was able to do some testing, which I've outlined below. GorillaWarfare (talk) 19:40, 1 February 2020 (UTC)

2. Moving to oppose, after doing some testing. I sent an email to the -c list to determine if I could move the email from one list to another before allowing the email through moderation. I determined that I was not able to move the email until after allowing it through moderation. So, to extend this example to the -en and -appeals lists: If someone emails an appeal to the -en list, moderators will have to allow it through moderation before moving it to the -appeals list. This will generate an email in all of the arbitrators' inboxes, from the -en list. Then the moderator will move the email to the -appeals list, which does not generate a new email notification for the arbitrators (so that's good, at least we wouldn't get duplicate emails). However, arbitrators working out of their GMail inboxes and not the Google Groups interface will end up replying to the original email, which is in the -en list. Google Groups does not appear to be able to detect that someone is replying to a moved thread, and so any replies will end up in a split thread in the -en list; meanwhile any arbitrators working directly in Google Groups will properly be responding to the -appeals thread (unless they respond to an email that an arbitrator working from their inbox has sent to the -en list). This will be absolute chaos, if you ask me, and is not worth the (fairly small) benefit of allowing us to more accurately tag emails in our inboxes. GorillaWarfare (talk) 19:38, 1 February 2020 (UTC)

   Thank you GW for doing the test on the c-list. My #3 oppose rationale was exactly this issue. I recall it had been an issue during a case where a person submitted private evidence to the main list and the case was being heard on one of the alternate lists because of recusals. Mkdw ^talk 01:54, 2 February 2020 (UTC)

3. Moved to oppose, per GorillaWarfare. – bradv🍁 19:43, 1 February 2020 (UTC)
4. Per all of the above opposes, this needs the bugs worked out of it so it actually helps the entire committee, as it stands I'm just not seeing it as an improvement. Beeblebrox (talk) 18:34, 6 February 2020 (UTC)
5. oppose, as unnecesary. We have had the usual January inflow of requests, and are dealing with them. And as harmful, the system for appeals is already overcomplicated. DGG ( talk ) 03:11, 11 February 2020 (UTC)
6. AGK ■ 22:06, 11 February 2020 (UTC)

Abstain

Comments

• I think we should try to briefly clarify what types of appeals are handled and have edited that in (and changed "should" to "may"). What about AE blocks? –xeno^talk 13:50, 20 January 2020 (UTC)
  • As it stands, we receive 7 types of appeal:
    1. Blocks imposed by ArbCom
    2. Site bans imposed by ArbCom
    3. Non-siteban restrictions imposed by ArbCom
    4. Sanctions imposed under delegated authority (AE)
    5. Community blocks based on private evidence; marked {{checkuserblock}} or {{oversightblock}}, or based on non-public evidence
    6. Community blocks of any other kind
    7. Outside of jurisdiction
    The blocking policy and our procedures contain clear definitions of these six types of appeal. What sort of clarification were you thinking we should make? The motion simply proposes changing the email address given out to Type E users… Might be easiest separately voting on substantial changes. AGK ■ 14:08, 20 January 2020 (UTC)
    • Like in Special:Diff/936703314. Feel free to tweak. Are you counting AE blocks as "imposed by ArbCom"? –xeno^talk 14:22, 20 January 2020 (UTC)
      • Got you. That looks good to me! No, so make that 7 types (and edited the list, reflecting that). AGK ■ 14:28, 20 January 2020 (UTC)
        • Great- which list should AE block appeals go to (assuming they can't be handled onwiki)? –xeno^talk 14:29, 20 January 2020 (UTC)
• AGK: Supported as this will improve workflow. The only other thing I would suggest is perhaps a trailer notice as to where other blocks/bans may be appealed (i.e. WP:GAB or WP:UTRS). –xeno^talk 14:51, 20 January 2020 (UTC)
• Here's my attempt at simplifying this. I'm sure someone will let me know if I've missed something:
  1. Appeal of blocks and bans issued by Arbcom – arbcom-en
  2. Appeal of blocks and bans issued under delegated authority (checkuser, oversight, AE) – arbcom-appeals-en
  3. Appeal of blocks and bans issued by the community or individual administrator – referred to AN

In rare cases there will be appeals that fall in two categories, such as checkuser blocks where there is also an automatic three strikes ban. In this case the appeal will still go to arbcom-appeals-en, but will then be posted to AN for an unban discussion.

For appeals within Arbcom jurisdiction (types 1 and 2), the arbitrators may choose to vote on the appeal at WP:ARBM. This is done in order to allow for comments from the community, and can only be done with the approval of the appellant. – bradv🍁 16:33, 22 January 2020 (UTC)

@AGK: Could you clarify the meaning of the sentence that Last year, we received 215 appeals of which only around 12 were ban or sanction appeals? Do you mean that only around 12 were appeals from bans or sanctions imposed by ArbCom as opposed to someone else? Thanks, Newyorkbrad (talk) 15:31, 23 January 2020 (UTC)

@Newyorkbrad: The point was about type of appeal as opposed to origin. Except for those 12, all appeals in 2019 related to blocks rather than to bans and other sanctions. AGK ■ 19:51, 23 January 2020 (UTC)

@AGK: Thanks. Regards, Newyorkbrad (talk) 20:20, 23 January 2020 (UTC)

• I've been quiet on this so far and basically going along with those who seemed to have a better idea of what this is supposed to accomplish than I do. However, reading the discussion below and the new oppose by GW I'm starting to feel like I don't see any benefit to this for the committee as a whole. It is starting to seem like it would primarily benefit only those of us who do the majority of their arb business through google groups, which so far I have not even been able to log into successfully and we've not been able to resolve why that might be. And I know I'm not that stupid. I'm not opposing just yet, but I do find the opposes compelling. Beeblebrox (talk) 00:43, 2 February 2020 (UTC)

Discussion and comments

All users – not just committee members – are welcome to comment here.

• I suggest tweaking the announcement to specify that it's the Arbitration Committee, as this is not necessarily going to be obvious in every venue. I'd also suggest adding Template talk:OversightBlock to the announcement locations. Thryduulf (talk) 20:40, 20 January 2020 (UTC)

  Good point, I've changed committee to Arbitration Committee on the first mention and added that notification location. (No substantive change.) –xeno^talk 16:16, 21 January 2020 (UTC)

• Regarding having an appeal motion only when approved by the appellant: I understand if the arbitration committee wants to do this for specific appeals, such as when there are potential privacy issues to consider, but I'm unclear if this should be a hard rule for all cases. Surely the committee can set the conditions for granting an appeal, including receiving feedback from the community beforehand? isaacl (talk) 17:21, 22 January 2020 (UTC)

  Isaacl generally what we are hesitant on is posting the appellant's written text without their permission. If they didn't give permission to post the text of their appeal, we could still seek opinions as to whether an appeal should be granted (though that might be somewhat awkward). –xeno^talk 17:28, 22 January 2020 (UTC)

  I agree with that, but it's already covered under existing privacy policy. Personally I'd prefer not to tie all possible appeal motions to this issue. The committee can consider it of course for any specific appeal. isaacl (talk) 17:33, 22 January 2020 (UTC)

  Isaacl, emails sent to the committee are held in confidence. We will always check with the appellant before posting their appeal onwiki. (Note also that this is not part of the motion, it's just my explanatory comment.) – bradv🍁 17:37, 22 January 2020 (UTC)

  Yes, as I said, I understand this is already covered by existing privacy policy. I thought you were proposing a simplification that would get incorporated into the appeals procedure somewhere, but if not, then of course the exact wording isn't as important. isaacl (talk) 17:45, 22 January 2020 (UTC)

  Oh no, I'm not proposing to change the motion, just making sure we're all on the same page. Sorry if that wasn't clear. – bradv🍁 17:47, 22 January 2020 (UTC)

• Hmmm. I'd suggest you're not really solving any problems by creating a new mailing list. The real issue is the number of requests. (It's a ridiculously high number, which I think is even higher than when Arbcom addressed *all* types of unblock requests before limiting itself to Arbcom-related or privacy-related unblock requests.) And if most of the requests you're getting are coming through the "email this user" interface, they're still going to wind up on your main mailing list. As someone who is both a checkuser and oversighter, I'm pretty surprised to see the frequency of these requests, because the CU and OS teams have no idea that this many of their blocks is being questioned.

  Consider leveraging the Functionary and Oversight lists to review the CU/OS blocks. This will resolve several issues: Someone other than arbitrators will carry the bulk of the workload (even just the data collection will reduce Arbcom's workload); CU and OS will become more educated on when blocks are being appealed and may identify issues, behaviour patterns, and opportunities to change blocking practices; and knowing that these unblock requests are being looked at by people who are genuinely expert in the tools involved may reduce the number of frivolous or inappropriate requests. Now, I don't really have an objection to a separate mailing list, although if it's really not going to change your work patterns (i.e., if everyone is on both lists) then I don't really think you're solving anything. And yeah...CRMs. We had great opportunities to make use of CRM systems that the WMF had rights to, but as often happens, "perfect" became the enemy of good and the few arbitrators who cared enough to try to address it couldn't come to a mutually satisfactory conclusion. Risker (talk) 16:22, 1 February 2020 (UTC)

  Discussion based on this comment has been copied to a new section below. GorillaWarfare (talk) 22:00, 2 February 2020 (UTC)

• Does ArbCom not have a ticketing system for these requests? Could the WP:UTRS system be cloned for use by ArbCom to improve workflow and reduce the redundancy that MKDW mentions? — Wug·a·po·des​ 23:16, 1 February 2020 (UTC)

  We do not. I have in the past suggested we move to a CRM or something along those lines, but unfortunately moving systems is extremely disruptive for the Committee, and burdensome on the WMF and on those trying to get in contact with us. The shift from mailman to Google Groups was a drawn out and painful process, and even though I would love to have a better system I dread the thought of repeating that fiasco. It would also leave us with archived emails in three places and not just two, unless we found a system that was particularly capable at importing a very tangled email history. (As a side note, I feel that I ought to mention that although I do work for a company that develops and sells CRM software, I have not recommended that we adopt it.) GorillaWarfare (talk) 23:29, 1 February 2020 (UTC)

  To be fair, we should also count the three “archive-only” lists from our arbcom-l days! AGK ■ 23:44, 1 February 2020 (UTC)

  Yeah, I was referring to archives in mailman and the archives in Google Groups, which themselves are split up into several locations... :/ GorillaWarfare (talk) 23:59, 1 February 2020 (UTC)

Discussion about checkusers handling some ArbCom appeals

Copied from discussion section above. GorillaWarfare (talk) 22:00, 2 February 2020 (UTC)

• Hmmm. I'd suggest you're not really solving any problems by creating a new mailing list. The real issue is the number of requests. (It's a ridiculously high number, which I think is even higher than when Arbcom addressed *all* types of unblock requests before limiting itself to Arbcom-related or privacy-related unblock requests.) And if most of the requests you're getting are coming through the "email this user" interface, they're still going to wind up on your main mailing list. As someone who is both a checkuser and oversighter, I'm pretty surprised to see the frequency of these requests, because the CU and OS teams have no idea that this many of their blocks is being questioned.

  Consider leveraging the Functionary and Oversight lists to review the CU/OS blocks. This will resolve several issues: Someone other than arbitrators will carry the bulk of the workload (even just the data collection will reduce Arbcom's workload); CU and OS will become more educated on when blocks are being appealed and may identify issues, behaviour patterns, and opportunities to change blocking practices; and knowing that these unblock requests are being looked at by people who are genuinely expert in the tools involved may reduce the number of frivolous or inappropriate requests. Now, I don't really have an objection to a separate mailing list, although if it's really not going to change your work patterns (i.e., if everyone is on both lists) then I don't really think you're solving anything. And yeah...CRMs. We had great opportunities to make use of CRM systems that the WMF had rights to, but as often happens, "perfect" became the enemy of good and the few arbitrators who cared enough to try to address it couldn't come to a mutually satisfactory conclusion. Risker (talk) 16:22, 1 February 2020 (UTC)

  I've said this on the ArbCom email list, but I'll repeat it here since you or others might have thoughts: I do really like the idea of the checkusers being the ones to handle checkuser block appeals. In general, although a handful of arbitrators tend to become skilled with the checkuser tool, our most qualified checkusers are not on the Arbitration Committee. Since the majority of the appeals we hear are checkuserblocks, I think specifically moving that category of appeals would solve both the problem of volume and it would allow the most adept checkusers to look into what are often technically complex appeals. The biggest blocker to making this a reality is a venue in which these appeals can be heard. checkuser-en-wp (the relatively recently-created checkuser queue) could potentially work, but do we have any information on how many checkusers regularly check the queue? My thought: have we considered trying to leverage UTRS for this? The additional data collected by the system could be valuable when considering checkuser block appeals, and it has a similar ticketing system to OTRS that is much preferable to an email list such as ours (in my opinion). GorillaWarfare (talk) 20:04, 2 February 2020 (UTC)

  I'm intrigued by this idea. I would be on board with including checkusers in the appeal process for checkuser blocks, assuming they're willing, and assuming we could find a process that works well. The obvious solution would be to use the checkuser queue in OTRS, which already includes all the checkusers and arbitrators. It also allows for side comments and votes, and the system is already secure enough to protect private data. The big problem with OTRS is that it doesn't allow people to interface with it only from their email. They actually have to log into the OTRS interface, which has its limitations.

  I'm curious about using UTRS for this instead, although I'm not sure if it's set up with all the features we would need to handle voting on appeals, and managing the private data inherent in many of the requests. What would we need to make that work? – bradv🍁 20:29, 2 February 2020 (UTC)

  I think the two biggest limitations of UTRS that we would need to overcome are a lack of voting mechanism (although this could be approximated in comments on a ticket), and a lack of a separate queue where appeals containing private information could be visible only to checkusers. I also think UTRS has the pitfall of OTRS in that you must log in to the system to handle tickets. Also, credit where credit is due to Wugapodes below for the UTRS idea. GorillaWarfare (talk) 20:46, 2 February 2020 (UTC)

  GorillaWarfare and Bradv (and everyone else, for that matter), we already have 28 of 43 checkusers subscribed to the checkuser-en-wp OTRS queue. It's been my observation that we've had occasional requests directed to that list already, although I think most of those have been in relation to IP blocks rather than account blocks. I haven't discussed this with other checkusers, but it would probably be the right place to send those unblock requests. Checkuser wiki can be used to store data and discuss, where applicable; it would also be an appropriate place to keep track of accounts that have made requests to have CU blocks lifted, because everyone with access has signed the applicable confidentiality agreements. I suspect that, just as with Arbcom, only a segment of checkusers will actively participate in reviews of CU blocks. There are notably fewer CUs who participate in UTRS than OTRS. On the other hand, there have definitely been some CU block reviews requested on UTRS that have been reviewed by CUs. I'll note in passing that most CUs don't have this page on their watchlist and are unaware of this discussion; I was flagged because of my past history of trying to get a CRM for Arbcom. I think it might be a good idea to ping the functionaries mailing list to bring more voices to this discussion.

  I will note in passing some concern that there are so many requests for review of checkuser blocks; based on what various arbitrators are saying here, I'm guessing that it's somewhere between 10 and 18 requests/month. That's a LOT of requests. With that number of requests, we should be able to identify patterns and commonalities. It may also reflect a more liberal "request again" process being used by Arbcom, since someone has mentioned people re-requesting at six months. I'd suggest one year is more appropriate. Risker (talk) 21:15, 2 February 2020 (UTC)

  I'll drop a note on func-en about this discussion. Thanks for providing numbers about the CU queue, that's useful information to have. I do agree that the six month re-appeal timeline is often too short—we've actually been discussing that somewhat recently. @Risker: Do you mind if I split this discussion out into a separate section below so it's easier to link to from the functionaries email? GorillaWarfare (talk) 21:19, 2 February 2020 (UTC)

  Sounds like a good idea to me, GorillaWarfare. Risker (talk) 21:40, 2 February 2020 (UTC)

  Great, I've split this out (but left a copy of your original comment above, since it does pertain to the separate ArbCom list). I've also emailed the functionaries to alert them of the conversation here. GorillaWarfare (talk) 22:03, 2 February 2020 (UTC)

• Can I review appeals of my own blocks? I don't know about other CUs, but I am "subscribed" to UTRS but really only use it to read, not to comment.--Bbb23 (talk) 22:11, 2 February 2020 (UTC)
• Copying what I said when GW notified the list: I think it makes sense for ArbCom to completely remove itself from OS blocks before looking at CU blocks.
  Those are already subject to peer review, we have an en-only mailing list, the OTRS function is actively used, and there’s significantly more institutional memory of how blocks came about there than on the committee.
  Not really sure my views on CU blocks yet, but the OS appeals are 100% something that can be offloaded. TonyBallioni (talk) 22:24, 2 February 2020 (UTC)

  And copying my on-list reply: We get next to no oversight block appeals, whereas checkuser block appeals are the primary category we receive. In practice it's very easy for us to just reply to the OS-l thread started when an oversight block is placed, and solicit input from the enwiki oversighters when we get an appeal like that. I agree that we can (and probably should) formally divest OS blocks, but not much will change in practice if we do. GorillaWarfare (talk) 22:29, 2 February 2020 (UTC)

• If appeals are such a large burden, you could restart WP:BASC as a real subcommittee, instead of as a sort of committee of the whole as it was before, with non-Arbitrator functionaries. I could easily see 1 Arb, 2 OSers, and 2 CUs with 1 year terms as an appeals panel. Having every person on functionaries-en as a sort of senate would also be an option per Risker. --In actu (Guerillero) ^{Parlez Moi} 17:09, 3 February 2020 (UTC)
• I don't think Arbcom needs to review checkuser blocks. We already have Category:Requests for unblock and WP:UTRS. If we need something else to handle appeals with private information, it could go to any number of places besides Arbcom, such as an independent BASC, a CU-only queue on UTRS, functionaries-en, OTRS, etc. NinjaRobotPirate (talk) 00:38, 4 February 2020 (UTC)
• I like Guerillero's suggestion above, of restarting BASC. Ideally in conjunction with some sort of professional CRM, and the option to toss requests to functionaries-en for wider discussion if needed. I don't think OTRS is ideal for the job, I might be wrong, but I don't really see an easy way to use it for internal discussion / commenting on requests. A private UTRS queue might work, but I'm not sure that it would be implementable at this time, DeltaQuad, and TParis are both not active on enwiki at the moment, and I don't have the time / experience to implement it at this time either. SQL^{Query me!} 16:32, 5 February 2020 (UTC)

• (guy who blew up BASC completely by accident) Since BASC was disbanded by community consensus, it would be extremely poor form for the committee to reconstruct it without consultation. I would note that my intent when I opened the RFC that ended it was that we would agree on some sort of hybridized version of it, to lessen the workload for the full committee, but that was not the outcome. I would personally still support such an effort. Beeblebrox (talk) 16:40, 5 February 2020 (UTC)

  Beeblebrox, Ah, I wasn't aware of the history. Here's the RFC for anyone curious, as well as motions and discussion. SQL^{Query me!} 16:46, 5 February 2020 (UTC)

  For what it's worth, I floated the idea of resurrecting BASC on the list about a month ago and it wasn't received positively. The block appeals are reasonably burdensome right now, because we're catching up last year (this is entirely understandable and by no means should this be considered a slight against the post-Fram-incident 2019 committee), but we're making good progress on them. It looks like we get about 15-20 appeals per month. Most of these are checkuser blocks; there is an occasional oversight block or two, and I don't see any arbcom blocks in the table. Roughly 5 or so appeals a month are not our jurisdiction - these either don't involve personal information, or there's a global lock involved (so stewards have to be contacted first). Of the (roughly) 15 appeals of CU blocks a month, easily half, if not more, are without any merit and get quickly rejected. The rest do require more research. Speaking for myself only here, if I'm stuck on following the evidence or conclusion for a CU block, I will reach out to the blocking CU to get clarification. (As a career bureaucrat I never quite intended on doing checkuser investigations, but here we are.) Otherwise, yes, we're somewhat opaque with the checkuser team in terms of how things are done, and that's probably not a Good Thing. Maxim_(talk) 17:04, 5 February 2020 (UTC)

  It seems like people want less work, but don't want to give up control. I think that restarting BASC (with outsiders to the committee) to hear only the kinds of appeals that arbcom currently hears wouldn't be against the spirit of the RFC. The problem points would be arbcom blocks (99% of which will never be lifted if you read the archives) and arbcom bans (a few a year are normally lifted, but letting non-arbs be an appeals body to the committee would make committee members twitchy). Returning control of community bans to the community was a big part of the RCF and it has turned out well. --In actu (Guerillero) ^{Parlez Moi} 17:15, 5 February 2020 (UTC)

  I'm not sure that's accurate—I'd love to give up control, at least of the checkuser block appeals. I think if we could manage to siphon the CU blocks off to the checkusers and leave the other kinds of appeals with the Committee, we would achieve the goal of significantly reducing the number of appeals the Committee needs to consider. This would also benefit the appellants and the community, I think, as the most qualified CUs tend not to be the Committee members who happen to hold the tool. GorillaWarfare (talk) 02:56, 6 February 2020 (UTC)

• I spoke with @Bradv: and @GorillaWarfare: the other day about UTRS with a seperate ArbCom queue (or whatever type of queue) possibility. It's definitely a possibility as I am building UTRS 2.0, and that's one of my projects I will remain on. If anyone is wanting this or specific parts of this to be features, then this is the time to say so, so that they can be ready for launch. That said, I can't offer anything in a speedy manner. I'm in cycle of being slammed every two weeks for about two weeks, then two weeks to do everything else I want. That will be till the end of April or so. An interim solution should still be considered if there is an existing problem for ArbCom. -- Amanda (aka DQ) 17:34, 5 February 2020 (UTC)

• @DeltaQuad: Amanda, could you give an update on UTRS 2.0? I haven't been able to get ahold of you other than that short discussion the other day, but I'm interested in how far along it is. Is 42 SV still supporting it?--v/r - TP 00:00, 6 February 2020 (UTC)

• While at lunch today, I had a thought. If someone else has already suggested it, forgive me. What if CU block appeals still went to the Committee but they were screened before going to the full Committee? A bit like the US Supreme Court. A single arbitrator (that position would rotate) would screen the appeal and determine the merit of the appeal. If they felt it did, they would pass it on to the Committee. If not, it would be rejected. This wouldn't reduce the number of appeals, but it would considerably reduce the workload on the members.--Bbb23 (talk) 00:18, 6 February 2020 (UTC)

  Not a bad idea Bbb23 and somewhat similar to how it’s handled now. Any given appeal will usually get looked at by a single arb at first (there’s a few really diligent arbs who try to stay on top of the flood) and get the ball rolling with their initial thoughts. Usually if they’re in favour of an unblock then the appeal will get a bit more attention faster, and it only take net four arbitrators to come to a decision rather than the whole or a majority of the committee. –xeno^talk 00:52, 6 February 2020 (UTC)

  @Xeno: If that's how it's handled now, then it obviously isn't working well enough or there wouldn't be this push to use a different system. Any stats on (a) how much time is spent by the initial arb and (b) how often the initial arb recommends an unblock?--Bbb23 (talk) 02:06, 6 February 2020 (UTC)

  Bbb23, I can only speak for myself, but if I'm doing a thorough investigation maybe half an hour to an hour? Not counting getting stuck and emailing the blocking CU, which I'm starting to avoid nowadays. :-) Feel free to take a look at my CU logs - there's an example from 5 February in there. I usually don't recommend an unblock with checkuserblocks. What will typically happen is that I retrace the steps that blocking checkuser took and (a) come to the same conclusion and (b) suggest that appeal is without merit as a lot of them in such cases tend to be. To paraphrase a lot of the appeals, "my block is very unjust/unfair and I was making productive edits". Maxim_(talk) 03:09, 6 February 2020 (UTC)

  Maxim, any idea how many baseless appeals vs. ones with merit?--Bbb23 (talk) 18:54, 6 February 2020 (UTC)

  Bbb23, that's tough to say. For checkuser blocks, the appeals we get are on a spectrum from "why did you block me fuck you" sort of appeal to "it wasn't me" with no further explanation (and it still looks like sockpuppetry or sometimes it's still ongoing) to cases where it is explained as meatpuppetry to users admitting it and asking for a second chance. The latter two have a chance to be successful, whereas the first two don't really. Speaking for myself, there's been a few cases where I couldn't put together the evidence for the checkuser block, so I contacted the blocking checkusers, who, so far, have set me straight. Maxim_(talk) 01:30, 7 February 2020 (UTC)

  Maxim, I lost you. You mention the first two and the latter two, but I count only three. Regardless, do you spend any time on the "fuck you" and "it wasn't me" appeals? I guess the way I'm leaning is more appeals should be summarily rejected, although I'm not sure the Committee would go for that.--Bbb23 (talk) 01:57, 7 February 2020 (UTC)

  It usually doesn't take long to get to net 4 decline on an obviously frivolous appeal. –xeno^talk 02:16, 7 February 2020 (UTC)

  Bbb23, sorry, the four examples were "fuck you", "it wasn't me", meatpuppetry, and "second chance". The point I was trying to make is that it's generally a spectrum of appeal types, so it's tough to tell how many appeals are baseless versus ones with merits. Some are totally baseless, some are reasonable, and some are in between. There's appeals where the user shouldn't be unblocked regardless of the checkuser block (e.g. UPE). (Apologies in advance if I made it even more confusing.) Myself, I do take a look at the baseless ones - not as much to find a reason to unblock but more to find ongoing socking. Keep in mind there are many flavours of baseless appeal; the ones that don't deal with private info (i.e. a straightforward unblock request) we just tell them to use talkpage or UTRS. Maxim_(talk) 03:36, 7 February 2020 (UTC)