Wikipedia talk:Protection policy

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)

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)

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)

That works for me. Daniel Quinlan (talk) 03:43, 20 March 2024 (UTC)

Would you like to make the change? WhatamIdoing (talk) 03:47, 20 March 2024 (UTC)

Done. Daniel Quinlan (talk) 03:54, 20 March 2024 (UTC)

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)

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)

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)

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)

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)

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

Indefinite create and move protections

While long durations are discouraged throughout the policy, create and protection protections are often indefinite and the policy should be more consistent with standard practices. I did some analysis of the most recent 5,000 protections going back to 8 February 2024.

There were 328 create protections and 272 (83%) of those were indefinite. Of those, 247 were protected due to a page being repeatedly recreated. 7 had no reason, 5 were restoring previous protections, 4 were due to socking, 5 were the result of AfDs and RfDs, and the rest were reasons showing up just once. I think a good starting point would be updating WP:SALT to state that Create protection of any duration may be applied to pages being repeatedly recreated in violation of policy using the lowest protection level sufficient to stop the disruption.

There were 66 move protections that were ECP or higher (move semi-protection is basically a no-op), not cases where move protection was the same level as edit protection, and not done by TFA Protector Bot. 29 (44%) of those were indefinite (16 of those were ECP while 13 were full protection). The reasons for the indefinite move protections were more varied than with create protection as you would expect with 11 protected due to vandalism and disruption, 6 due to move or edit warring, 2 due to socking, and the rest were reasons showing up just once. I think a good starting point would be updating WP:MOVP to state that Move protection of any duration may be applied to pages being repeatedly moved in violation of policy using the lowest protection level sufficient to stop the disruption.

We can tweak the additions later if necessary. Daniel Quinlan (talk) 22:50, 11 May 2024 (UTC)

I'm not sure about documenting "lowest protection level sufficient to stop the disruption." IMHO it's often better, for example, to semi-protect an article for a week so the disruptors get bored and move on. In this context, I wouldn't think it helpful to salt a page for less than six months because once someone gets the idea they just have to wait a bit, they will wait more and more. Similarly, if a move war is going on, why not protect for a month to allow a move discussion plenty of time? I suppose a 48-hour protection could be applied and then block someone who moves it before a discussion is finished but I would prefer to avoid that. Johnuniq (talk) 00:39, 12 May 2024 (UTC)

I agree. I think a lot of what this section is off the mark and awkward as guidance. But I wasn't up to fixing that, just improving the exposition. EEng 01:15, 12 May 2024 (UTC)

Which section is off the mark and awkward as guidance? Daniel Quinlan (talk) 01:25, 12 May 2024 (UTC)

The lowest protection level sufficient to stop the disruption part is about to protection levels for create and move protection, not protection durations. For example, it's not necessary to use full move protection when the move vandalism is only from autoconfirmed users. Daniel Quinlan (talk) 01:24, 12 May 2024 (UTC)

Yikes, I don't know how I misread that. I agree that minimum level is desirable. Johnuniq (talk) 01:44, 12 May 2024 (UTC)

Both changes look good to me. Firefangledfeathers (talk / contribs) 01:18, 12 May 2024 (UTC)

Cascading protection and conditional transclusion

I haven't checked, but I think templates can be conditionally transcluded. If a cascading-protected page transcludes a template that conditionally transcludes another one, but doesn't use it in this case, is the third one protected (assuming there's no other reason to protect it)? Orisphera2 (talk) 18:28, 12 May 2024 (UTC)

If {{B}} is nested conditionally inside of {{A}}, and {{A}} is transcluded at Example, but the condition is not triggered, then {{B}} is not technically transcluded at Example so it would not be cascade-protected. Primefac (talk) 18:33, 12 May 2024 (UTC)

If it does, there may be a case when it leads to something I think isn't very good. I remember finding that trying to transclude a template recursively fails. (There was also a case where I was disappointed to find the same in CPP.) If a template in a transclusion loop (i.e., transcluding a template that transcludes it or another template that transcludes it or so on) is transcluded by a cascading-protected page, it can, depending on the implementation, stay protected when the protection is lifted or the transclusion is removed. I think it's better if it's not. Someone who has the power to cause this situation can also fix it, but they may just not notice. I don't have a good example of a use for a transclusion loop, but I think it would use conditional transclusion. The protection can be lifted if it was by mistake. In this case, it's likely to only be protected for a short time, but this doesn't apply to the second case (removing the transclusion). Orisphera2 (talk) 18:28, 12 May 2024 (UTC)

Correction: CPP. It's weird that it isn't red-backgrounded. Orisphera2 (talk) 18:30, 12 May 2024 (UTC)

Also, when I was writing this, a glitch happened and a lot of text disappeared and I had to reload the editor. This happened less than an hour before, though I'm not sure that it was here. I think it can also happen to other editors, so it's worth looking into. If it's a result of a captcha, it's a weird one. Orisphera2 (talk) 18:28, 12 May 2024 (UTC)