Wikipedia talk:Protection policy

(Redirected from Wikipedia talk:PPOL)
Latest comment: 4 hours ago by Daniel Quinlan in topic Awkward phrasing in WP:PREEMPTIVE

WikiProject iconCounter-Vandalism Unit
WikiProject iconThis page is within the scope of the Counter-Vandalism Unit, a WikiProject dedicated to combating vandalism on Wikipedia. You can help the CVU by watching the recent changes and undoing unconstructive edits. For more information go to the CVU's home page or see cleaning up vandalism.

Superprotect

I'd like to talk about the story we're telling in WP:SUPERPROTECT. Compare these two versions:

  • "where the MediaViewer had been deactivated in a wheel war involving two administrators...the community was discussing what to do"
  • "used the same day to override community consensus"

One of these is from our policy. One of these is from Meta-Wiki.

Here are the diffs that seem relevant to me, at 21:58, 22:13, 22:15 on 9 August. I believe that the technical change made it impossible to use Media Viewer, even if you wanted to use it yourself and enabled it in your own preferences. The admin who made the first and third edits was de-sysopped as soon as their policy allowed them to do so.

Additionally, this tool was used several times at other wikis, at the request of communities, to solve problems they were having.

I think that the story we're telling is ultimately misleading. Perhaps we should change it, or maybe just remove it? WhatamIdoing (talk) 01:12, 19 March 2024 (UTC)Reply

Would this be acceptable as a replacement for that paragraph?

Superprotect was a level of protection, allowing editing only by Wikimedia Foundation employees who were in the Staff global group. It was implemented on August 10, 2014 and removed on November 5, 2015. It was only used on two occasions on other Wikipedia editions.

I think that's sufficient for something that something that happened almost ten years ago. The current version of the paragraph is a little too editorial and the linked MediaWiki page and its talk page are the appropriate locations for a historical summary and any discussion on it. Daniel Quinlan (talk) 00:55, 20 March 2024 (UTC)Reply
Yes, I think that would be much better.
About the last sentence, I know it was used on Wikidata, and I'm not certain that it was only twice. (I heard once five total uses, but I don't know whether that's true.) Perhaps the more relevant point would be "never used at the English Wikipedia". WhatamIdoing (talk) 01:23, 20 March 2024 (UTC)Reply
That works for me. Daniel Quinlan (talk) 03:43, 20 March 2024 (UTC)Reply
Would you like to make the change? WhatamIdoing (talk) 03:47, 20 March 2024 (UTC)Reply
Done. Daniel Quinlan (talk) 03:54, 20 March 2024 (UTC)Reply

WP:ECR and WP:PREEMPTIVE

I've had some thoughts regarding the application of WP:PREEMPTIVE to articles covered by an extended-confirmed restriction that I'd like to hear other editors' opinions on. At the moment, my experience of WP:RFPP is that pages within the scope of an ECR are declined if there haven't been any edits to the page by non-XC editors. However, waiting until a non-extended-confirmed editor makes an edit to such a page (presumably innocently), just for that edit to be reverted and the page then protected, seems unnecessarily WP:BITEy to me.

The language in WP:PREEMPTIVE (that pre-emptive protection is contrary to the open nature of Wikipedia) suggests that the reason for it not being permitted is because we shouldn't be disallowing edits to an article from non-confirmed/XC editors when there hasn't been any disruption to said article from those editors. However, to me, the ECR falls in a different situation to this -- edits by non-XC editors to ECR-covered articles are already disallowed; therefore, applying protection in these cases is only enforcing a restriction that already exists, rather than creating a new one (as page protection would otherwise generally be doing).

I'd therefore suggest that it might be worth excluding pages covered by the extended-confirmed restriction from the policy against pre-emptive protection. To be clear, this wouldn't place any obligation on administrators to actively seek out and protect articles that are covered by an ECR; but rather, would mean that there isn't any policy forbidding them from being protected once an admin becomes aware of them (e.g. at RFPP).

I welcome others' thoughts on this, and let me know if there are any queries about anything I've said. All the best, ‍—‍a smart kitten[meow] 11:54, 7 May 2024 (UTC)Reply

There's no requirement spelled out in WP:ECR to always revert edits made by non-EC users if the topic area is covered by ECR. It says may be enforced and not "must be enforced", after all. Community-authorized extended confirmed restrictions such as the one in WP:GS/RUSUKR are similarly phrased.
Bearing that in mind, if a non-EC user's edit is good faith and improves the article, reverting the edit does indeed seem bitey and I personally wouldn't automatically revert such an edit even if I was protecting the article. And with that approach, if it's necessary to revert an edit then there should always be a good revert reason that can be put into an edit summary and a user talk page explanation such as NPOV, sourcing requirements, or some other good reason that explains the reversion rather than a bitey "you're not extended confirmed" reason.
Anyhow, I'm strongly opposed to the idea of adding this exception to WP:PREEMPTIVE. It's a core principle and there are a high number of articles falling under ECR right now that have zero disruption which also occasionally receive good faith and beneficial edits by non-EC editors. Making ECP a virtual requirement for those articles would open up the floodgates to create a deluge of article requests on WP:RFPP and I think increasing the number of articles under ECP by such a huge number would be much more bitey than the situation we have today. Daniel Quinlan (talk) 22:31, 7 May 2024 (UTC)Reply

Awkward phrasing in WP:PREEMPTIVE

The first sentence (Applying page protection as a preemptive measure is contrary to the open nature of Wikipedia and is generally not allowed if applied solely for these reasons.) is awkwardly phrased because there aren't multiple reasons stated. I'd like to tweak this in a way that avoids changing the meaning. One option is removing the if applied solely for these reasons. Another option would be changing these reasons to preemptive reasons. I'm open to other suggestions. Daniel Quinlan (talk) 03:21, 11 May 2024 (UTC)Reply

I would just omit the waffle leaving: "Applying page protection as a preemptive measure is contrary to the open nature of Wikipedia and is generally not allowed." If there are reasons to protect a page, then the page can be protected and WP:PREEMPTIVE doesn't need to hint that. We generally don't protect preemptively. WP:IAR is always available if, for example, a BLP needs to be preemptively protected due to social media drama. Johnuniq (talk) 04:30, 11 May 2024 (UTC)Reply
It seems like you and EEng are in agreement and that change has basically been made now (see below). Thanks. Daniel Quinlan (talk) 04:35, 11 May 2024 (UTC)Reply
@EEng: Given that your changes to WP:PREEMPTIVE seem to be in response to this discussion being opened and the fact that your changes could be interpreted as changing the policy, it might have been better to discuss them here first. Anyhow, thanks for the improvements and I think we got to a good place. While I did change some of your revised text back to a version closer to the original, I kept most of your changes. However, I believe two in particular need to be mentioned here to give people the chance to agree or disagree. Specifically:
  • The blatant vandalism was changed to vandalism. I think that's consistent with practice and the rest of the policy. Vandalism being subtle definitely isn't a reason we'd leave a page unprotected.
  • The aforementioned proposal to fix if applied solely for these reasons was effectively done by moving solely to earlier in the sentence and removing the rest.
The rest of the changes seem cosmetic, but are definitely an improvement. Daniel Quinlan (talk) 04:33, 11 May 2024 (UTC)Reply