Warning: file_put_contents(/opt/frankenphp/design.onmedianet.com/storage/proxy/cache/829a662efe2067759eb80c8566245046.html): Failed to open stream: No space left on device in /opt/frankenphp/design.onmedianet.com/app/src/Arsae/CacheManager.php on line 36

Warning: http_response_code(): Cannot set response code - headers already sent (output started at /opt/frankenphp/design.onmedianet.com/app/src/Arsae/CacheManager.php:36) in /opt/frankenphp/design.onmedianet.com/app/src/Models/Response.php on line 17

Warning: Cannot modify header information - headers already sent by (output started at /opt/frankenphp/design.onmedianet.com/app/src/Arsae/CacheManager.php:36) in /opt/frankenphp/design.onmedianet.com/app/src/Models/Response.php on line 20
Wikipedia:Arbitration/Requests/Motions - Wikipedia Jump to content

Wikipedia:Arbitration/Requests/Motions

Page semi-protected
From Wikipedia, the free encyclopedia

Motions

WP:ARBPIA EC by default adjustment

Looking to adjust the WP:ARBPIA preemptive EC protection to be allowed rather than required. There's a pretty significant burden on RFPP and the patrolling admins caused by the requirement to protect articles that will likely never see disruption. The aim is to allow admin judgement on whether or not articles need to be protected while still explicitly allowing preemptive protection while standardizing the preemptive protection language between PIA and CT/SA.

WP:ARBPIA EC by default adjustment: Clerk notes

This area is used for notes by the clerks (including clerk recusals).

Motion: WP:ARBPIA EC by default adjusted from mandatory to allowed

Remedy 1 of the Palestine-Israel articles 5 case ("ECP by default") is rescinded and is replaced with Administrators are permitted to preemptively protect articles covered by WP:PIA when there is a reasonable belief that they will be the target of disruption.

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

Support:

  1. I trust the judgement of our admins enough to give them the leeway to decide that although something may be covered by ARBPIA it doesn't need EC protection. This still allows preemptive protection when an admin believes there may be disruption. It also prevents someone dumping 60 articles at RFPP that technically must be protected. Lastly, it standardizes the language between the two topics that allow preemptive protection. ScottishFinnishRadish (talk) 11:24, 2 October 2025 (UTC)[reply]
  2. I believe that this was one of our biggest mistakes this year, leading to a near-overwhelming amount of work to the point that the list of protections had to be split off from the main log. I wanted to repeal it entirely and leave the extended-confirmed restriction in its place instead, but I don't think that we would have a majority for that and pragmatically I think that this is a significant improvement over the status quo. Sdrqaz (talk) 14:09, 2 October 2025 (UTC)[reply]
  3. Daniel (talk) 20:46, 3 October 2025 (UTC)[reply]
  4. Z1720 (talk) 22:16, 3 October 2025 (UTC)[reply]
  5. theleekycauldron (talk • she/her) 22:42, 3 October 2025 (UTC)[reply]
    Primefac (talk) 01:41, 4 October 2025 (UTC)[reply]

Oppose:

  1. When the idea was first floated, I assumed it was a somewhat procedural attempt to standardize wording. But this is instead an outright rejection of one of the central findings of PIA5: ECP is a must everywhere. We voted 13 to 0 to implement global ECP for PIA topics. It would be nuts for us to undo that. Sure it may have created some extra work, but once all PIA topics are protected, the work goes way down--folks can't create that many new pages in a day about it. If we need to do some technical work to fix the logs, lets do that rather than throw the baby out with the bathwater. Most importantly, this restriction is aimed at raising the cost for socking. Before we implemented this, 13% of PIA edits were from non-ECP accounts, and 7% were from socks. By releasing pressure, we are only going to invite trouble in our most troublesome topic. CaptainEek Edits Ho Cap'n! 06:48, 4 October 2025 (UTC)[reply]
  2. In every article whose main topic is extended-confirmed-restricted, it is reasonable to believe that they will be the target of disruption. This is not a mistake, this from practical experience. The disruption led to five ArbCom cases about the same topic; it led to the existence of extended-confirmed protection and to the fine solution we have today. If someone requests page protection for 60 articles and these articles' main topic is actually part of the Arab-Israeli conflict, then someone has found 60 pages that should actually be protected. Protection will never be requested again for these 60 pages, contrary to pages whose protection is individually examined, declined and later proven necessary. ~ ToBeFree (talk) 19:37, 5 October 2025 (UTC)[reply]
  3. Per CaptainEek. Primefac (talk) 20:39, 5 October 2025 (UTC)[reply]
  4. Per Eek. Unfortunately I don't think anything has substantially changed since the conclusion of PIA5 to warrant this change, which was shown to be necessary at that time. - Aoidh (talk) 22:19, 5 October 2025 (UTC)[reply]
  5. I don't agree that this currently needs changing. WormTT(talk) 09:42, 9 October 2025 (UTC)[reply]

Abstain:

Arbitrator views and discussions

  • Looking at the AE PIA log for this week alone, 33 articles had no human edits in 2025. Of those thirty-three: twenty-three were last edited by a human in 2024,[α] five articles were last edited by a human in 2023,[β] four were last edited by a human in 2022,[γ] and one was last edited by a human in 2021.[δ] Of the PIA protections this week, I already disregarded the many that had human AWB/JWB edits as well as those that had a single edit.
    When we actually look at what's happening at RfPP, I don't understand how all these articles being protected improves the encyclopaedia, don't understand how the PIA5 remedy is supposed to reduce workload, and don't see how we can say that the PIA5 workload was a one-off when this happened just this week. Sdrqaz (talk) 02:51, 11 October 2025 (UTC)[reply]

References

Community discussion

Statement by Guerillero

I'm not sure that playing whack a mole with whatever Twitter, Bluesky, Reddit, advocacy orgs, etc. is unhappy about on any given day is preferable to the January status quo --Guerillero Parlez Moi 16:39, 2 October 2025 (UTC)[reply]

Statement by Vanamonde

I like this change for coming around to the "discretionary" part of what we use to call discretionary sanctions: admins are not compelled to protect, but we can do so at the slightest sniff of disruption, which strikes the right balance in my view. Vanamonde93 (talk) 16:49, 2 October 2025 (UTC)[reply]

Statement by Amakuru

Huh? I'm baffled by the motivation for this. The blanket restriction seems to be something that's worked well, from what I've seen around the place. The temperature at discussions around Israel/Palestine is markedly lower as a result of having only experienced editors present and reasoned decisions can be made without noise from canvasessed groups and other partisan interests. As Guerillero says, this is just going to mean admins have to cast around disabling disruption when it's already happened in a whack-a-mole fashion rather than us simply being able to apply restrictions everywhere.  — Amakuru (talk) 06:29, 4 October 2025 (UTC)[reply]

Hi Amakuru, the remedy being amended only applies to articles and the extended-confirmed restriction would continue to apply to discussions (and articles) regardless of whether this motion passes. Sdrqaz (talk) 23:36, 4 October 2025 (UTC)[reply]
Ah, I see. But does that mean non-EC editors will be allowed to edit articles that haven't been protected, even though they can't participate in discussions on the talk page? If they're still prohibited, why would we not want to apply the protection to the page? It sounds like a recipe for confusion and potentially disrupting the relatively lower level of trouble we've had since the restrictions of the last big Arbcom case. I think I am of the same mind as CaptainEek here, it seems like we're risking increased disruption and increased potential for socks to cause damage, for largely bureaucratic reasons rather than because it's a good idea. If there's too much bureaucracy around applying ECP then we should address that, not roll back protections and hope for the best. Cheers  — Amakuru (talk) 16:39, 5 October 2025 (UTC)[reply]
Say we have an article on Settlement X. Sixty years ago it was the site of a battle that was part of the Arab/Israel conflict, and discussion of that battle is half of the article prose. The article has existed for 18 years and has had fewer than 100 edits with no disruption. Non-EC edits have been related to demographics and geography.
Right now, that article must be protected. Someone could find 60 such articles and dump them all at RFPP and they cannot be declined. What this change does is let an administrator use their judgement to determine if there is enough likelihood of disruption to protect it. The protection can still be preemptive, without any existing disruption, if the admin believes that there could be disruption. ScottishFinnishRadish (talk) 17:06, 5 October 2025 (UTC)[reply]

Statement by Bluethricecreamman

I saw SFR's statement in Amakuru's section [1]. I think I've seen less shenanigans in general in the topic area, possibly due to the automatic ECR. I think if arbcom gave some guidance to confirm what they expect should always be protected vs. where admin discretion matters, it could be helpful. Maybe any page created within the last two years or so is given automatic ECR and the rest is admin discretion? The newest articles are the most prone to scatter fire, while older ones will have enough history to be properly judged as necessary for protection or not. User:Bluethricecreamman (Talk·Contribs) 23:59, 8 October 2025 (UTC)[reply]

Statement by Callanecc

This seems like a good fix for something that always seemed strange. It always seemed a odd that ArbCom would compel rather than empower volunteer admins to do something even when their experience (and in some instances the page history and specific subtopic noting SFR's example in response to Amakuru) tells them it's unnecessary and the admin policy says that they are never required to use their tools. While I understand why having the same wording as IPA might be useful if there's a stronger desire for ECP to be used here perhaps "(strongly) encouraged" instead of "permitted" would still leave it to discretion but be a little stronger. Callanecc (talkcontribslogs) 06:21, 9 October 2025 (UTC)[reply]

Statement by Zero0000

When a PIA editor makes the effort to list a page at RFPP it is because there is either trouble existing or trouble likely. The resolution doesn't force any particular admin to run around protecting multiple pages, but the principle that an editor in good standing can have a PIA page protected by asking for it is a valuable one that helps to keep the temperature down. This protection only prevents edits from people who are already not allowed to make them. Zerotalk 11:24, 9 October 2025 (UTC)[reply]

The argument that the resolution forces admins to do things doesn't seem to follow from the wording of the resolution. The resolution says what the "default" state of PIA articles should be, not who is compelled to make them that way. Also, protecting an article takes much less time than studying recent activity there to decide whether future disruption is likely. Zerotalk 11:32, 9 October 2025 (UTC)[reply]

I think that it's clear that the Committee entrusts the power of arbitration enforcement in administrators, especially since only they have the ability to protect pages. Sdrqaz (talk) 02:51, 11 October 2025 (UTC)[reply]

Statement by Smallangryplanet

As someone who is active in this CTOP and frequently submitting articles in it to RFPP I think the workload from not enforcing this provision would be far more substantial than continuing to enforce it. We see a substantial number of contentious edits in even protected articles, and when an article pops up that is not protected, either a new or long standing one, it invariably becomes a hotbed of BLP / NPOV issues. This is a heavily-canvassed topic area and the quality of edits, even contentious ones, increases dramatically when articles within it are protected. Maintaining this provision better respects both editor and administrator time. Thank you. Smallangryplanet (talk) 14:46, 9 October 2025 (UTC)[reply]

Statement by Sean.hoyland

For me, the remedy, ECP by default, is not a mistake. It's an acknowledgement that a) there is an elevated risk of non-compliance with the EC rules in the topic area, b) that no one can reliably predict if or when PIA related EC violations will occur and c) prevention/enforcement is better handled by machines rather than people who happen to have a page watchlisted and are paying attention at the right time. There is already a layer of subjective fuzziness in answering the relatedcontent=yes/no, section=yes/no questions for the templates that defines whether an article is within scope of the ECP by default rule, whether the talk page is only in the 'Wikipedia pages subject to the extended confirmed restriction' category or whether it is also (it seems weirdly) in the 'Wikipedia pages subject to the extended confirmed restriction related to the Arab-Israeli conflict' category (assuming I understand how that categorization is working right now...I haven't looked at Wikipedia for a while). Introducing another layer of subjectivity seems like a move in the wrong direction to me - more complexity, more arbitrariness. Sean.hoyland (talk) 06:31, 13 October 2025 (UTC)[reply]

Statement by {other-editor}