Wikipedia talk:Protection policy/Archive 18

Archive 15

Archive 16

Archive 17

Archive 18

The use of salting

In a recent discussion, it transpired that there are about 41,000 salted article titles (salting here refers to indefinite full creation protection). There's no doubt that the majority of these pages will never need to be created, but there is a certain number of titles that may later become eligible. For example, if an article about a person is deleted and salted at one point in time, ten years later a different person with the same name may become notable and the initial salting will get in the way of article creation. Or a different article may get created for which the salted title would make for a good redirect. It's hard to guess the numbers, but from the one page of log entries that were given in that discussion (presumably as an example of a set of particularly bad titles), it turned out that about 14% would make for acceptable redirects. Salting has undoubtedly saved us a lot of headaches, but it does come with its drawbacks.

The general understanding is that salting was mostly used in the past before extended confirmed protection was available. However, it still very much actively employed. I got curious and had a look at the last 20 saltings, going back about two weeks.

Salted pages of the last two weeks

Page Logs Creator editcount 1 Trilla Venus [1] 74 2 Gulf State Software LLC [2] 19 3 Marisa Peer [3] 327 4 Sasikanth Senthil [4] 8538 5 Harsh Beniwal (YouTuber) [5] 51 6 Jeff huber [6] 11 7 Aaryan Zaveri [7] 85 8 Melissa B. [8] 111 9 Naman Mathur [9] 57 10 Ashish Chanchlani [10] 179 11 Darajae J. Brown [11] 60 12 Sarojit Biswas [12] 19 13 Isaac Oladipupo [13] 3605 14 Laurence de Valmy [14] 154 15 Punta Gorda bus fight [15] 74 16 Hari Mari [16] 18 17 Baby Had an Accident [17] 28385 18 Sin Factor [18] 28385 19 Harpz Kaur [19] 332 20 Joe Tasker (Presenter) [20] 332 This was taken from the last page of the log. It excludes the three titles (Newton Arunaye‏‎, Soumita Saha‏‎, TerrytheVoice‎ ) whose full creation protection had a time limit.

Now, protection was probably justified in all of those cases. But in most of them, it's difficult to see why the protection was full rather than EC. For only four of the pages was the creator an extended-confirmed editor (and even then, for three of those cases it's not immediately obvious why full protection was used: the creator of #17 and #18 was indefinitely blocked, whereas for #4, a page speedied per G11, there appears to have been genuine disagreement on the creator's talk page about the notability of the subject). The remaining 16 pages were created by non-EC editors, and with a median edit count of 74, none look likely to pass the 500 mark any time soon. As far as I can see, for only two of the twenty pages the choice of protection level (full vs. EC) appears obvious: #13, where the creator has EC permissions, and #10, where the page had previously been recreated many times.

Is there anything I'm missing here? I would think that higher restrictions shouldn't be used when lower ones would do just as well. And how about the duration of protection? The assumption appears to be that salting should last forever: that's what the text in the policy page implies, and that's what appears to be done in practice (46 of the last 50 saltings were indefinite). But why is this so? Sure, some titles (like X is gay) will remain bad forever, but in the majority of cases salting appears to be used to tackle localised incidents of sockery, paid editing or vandalism, where it's not clear that the incidents would recur for years to come. Wouldn't it make sense to encourage admins to use protection for a long, but still limited, period of time? – Uanfala (talk) 14:23, 24 September 2020 (UTC)

100% agree with this analysis. #17 and #18 probably shouldn't be protected at all, given that (1) they weren't repeatedly re-created, only re-created once, and (2) both re-creations were by the same editor. That editor is blocked, and the block is all the prevention that seems to be needed for those titles. Plus, they are viable titles. "Sin Factor" may not be a notable album, but Googling it shows it's also the name of two books (probably not notable) and a plausible spelling of "sine factor", so it could make a useful redirect. A similar article, Sin Dome, was also re-created (once) by the same user; that title is not protected at all, it seems, and yet no disruptive re-creation. "Baby Had an Accident" might not be the name of anything notable that I can find right now, but it's hardly an offensive or disruptive title; it strikes me as quite plausible that "Baby Had an Accident" might be the name of some notable work, either now or in the future. BTW, the user wasn't blocked for re-creating the articles; from what I can tell, they were blocked for gross incivility, and these re-creations were all done on Sep 10, the same day as the gross incivility and block happened. I.e., this is not about problematic titles that consistently get recreated, it's about one user acting out, and the block, not the protection, is what prevents that disruption. I'd ask Floquenbeam to unprotect those two titles (and any other indef-full-protected titles that were only re-created by this one user).

I don't understand why #4 was protected at all, as it hadn't been repeatedly recreated either; judging from the logs, it looks like the "recreations" were redirects created as the result of draftification.) As for the rest, they didn't involve ECP editors, so I'm not seeing why we need a level of protection higher than ECP.

In my view, policy should be changed to this:

1. Full creation protection should only be used if there are 3+ ECP editors repeatedly recreating a "prohibited" title out of process. If it's only one or two ECP editors, just partial block those one or two editors instead. If the editors aren't ECP, then full protection should not be considered, only up to ECP protection.
2. If full creation protection is used, it should only be for a maximum of one year, at which point it should drop down to ECP (or no protection). If, again, there are 3+ ECP editors repeatedly recreating a title out of process, the protection can be bumped back up to full for up to one year. If it happens a third time, then indefinitely protect it (at that point, there will have been disruption by 3+ ECP over 2+ years, which is solid justification for full indef protection).
3. When it comes to ECP editors, blocks, not protection, should be the go-to tool. Lev!vich 16:38, 25 September 2020 (UTC)

I've unprotected the pages mentioned above. Fair enough. --Floquenbeam (talk) 16:47, 25 September 2020 (UTC)

Recent change to user talk

I just want to make sure we're all on the same page regarding the recent change to the wording regarding user talk protection. My understanding is that this wasn't a change in practice but a change to reflect practice. I support this, and other, such changes since policy and practice are intertwined. I just want to confirm that this is the best wording for that - I would hate for this new wording to inadvertently change practice. I don't have some other wording to suggest but throw this out there in case someone does. Best, Barkeep49 (talk) 15:20, 29 September 2020 (UTC)

Wrong description in tooltip

The full protection icon has the wrong tooltip text "This article is extended-confirmed protected", and the wrong alternative text "Extended-protected article" — Preceding unsigned comment added by 2A02:A313:A348:3780:E029:4D18:C077:F94D (talk) 02:15, 4 October 2020 (UTC)

Can you give an example of a page where the icon has the wrong tooltip? I checked one at random, and I didn't notice anything unusual. – Uanfala (talk) 13:19, 4 October 2020 (UTC)

Sure, for example, Margot_(activist)

<div class="mw-indicators mw-body-content">
	<div id="..." class="..."><a href="/wiki/Wikipedia:Protection_policy#full" title="This article is extended-confirmed protected"><img alt="Extended-protected article" src="..." decoding="async" width="20" height="20" srcset="... 1.5x, ... 2x" data-file-width="512" data-file-height="512"></a></div>
</div>

That's because Margot was extended-confirmed protected, later was full-protected, but the ECP icon was never modified. (CC) Tbhotch^™ 21:48, 4 October 2020 (UTC)

That shouldn't happen. It seems that {{pp-30-500}} is showing a tooltip that is appropriate for the name of the template, but displaying the correct icon for the actual protection level - a gold padlock marked "F", denoting full protection. I amended the article to use the generic {{pp}} template, which autodetects the prot level for both tooltip and padlock, but even so, Module:Protection banner (which is the module underlying Template:Pp-extended) needs investigating.

Note that this issue is nothing to do with this talk page, which is for discussing improvements to the page improving the page Wikipedia:Protection policy. --Redrose64 🌹 (talk) 22:20, 4 October 2020 (UTC)

Can admins edit all pages?

I have a question about your protection policy, can administrators edit all pages? Or are there pages that not even admins can edit? Gioguch (talk) 01:12, 7 October 2020 (UTC)

Gioguch, at the technical level, admins may edit any page except for users' personal Javascript and CSS pages, and those may be edited by interface administrators (which is an additional permission on top of "administrator" limited to a handful of trusted admins). At the policy level, the Wikimedia Foundation may "office-protect" pages, which means that only Foundation staff may edit; this is only a policy control, though, and admins are able to edit those pages (though if they do so, they may find their admin permissions removed in short order). Office protection is extremely rare. GeneralNotability (talk) 02:31, 7 October 2020 (UTC)

Most Special pages cannot be edited by anyone. There are also other interface pages which can be edited only by a certain user group. --Izno (talk) 02:34, 7 October 2020 (UTC)

And because there is always something else technical -- noone locally can edit in the Gadget namespace (such as the page Gadget:Invention, Travel, & Adventure) . — xaosflux ^Talk 13:57, 7 October 2020 (UTC)

But also from a "policy" perspective, if a page is fully protected out admins "may not" edit it except for certain reasons, admins do not have any extra "editorial" control of content than any other editor. — xaosflux ^Talk 14:03, 7 October 2020 (UTC)

@Izno and Xaosflux: Do you mean anyone and no one by "including administrators?" Actually, administrators technically can modify special pages, on Help:Special page it says:

Although special pages are not themselves editable, they generally contain standard text which is modifiable (although only by administrators).

And if Gadget:Invention, Travel, & Adventure can't be edited by admins by your definition, why does it say "fully protected?" By definition, fully protected means admins can edit. See Wikipedia:Protection policy#Overview of types of protection. Gioguch (talk) 23:44, 7 October 2020 (UTC)

Never mind, it doesn't say fully protected. It just tells you that you don't have permission to change pages in the Gadget namespace. Gioguch (talk) 23:47, 7 October 2020 (UTC)

Yes, on special pages there are often parts of them that use "messages" which are like templates - those are in the MediaWiki namespace, editable by admins. Some special pages don't have any messages though, for example Special:MathWikibase. — xaosflux ^Talk 00:25, 8 October 2020 (UTC)

Special pages aren't editable by anybody. This is because they don't exist except for a fleeting moment: when you follow a link to a special page, the server is triggered into running a query to collect the necessary information (an obvious example of this is with Special:RecentChanges which changes many times a second), assembles the page from the results of that query slotted into a kind of template that is partly built into the MediaWiki software and partly transcluded from pages in the MediaWiki: namespace (such as MediaWiki:Recentchanges-summary), then it serves the result to your client in the appearance of a "page", following which it is deleted again. So there is nothing physical which may be edited, except for those pages in MediaWiki: namespace.

Pages in MediaWiki: namespace are, by default, editable by admins only. This is not due to any protection - the restriction is built into the MediaWiki software: if I go to MediaWiki:Recentchanges-summary and select the option to change its protection level, it shows the present prot levels as "Edit: Allow all users" and "Move: Allow all users" - essentially, it's unprotected. There is a further restriction (which is also nothing to do with page protection) that pages in MediaWiki: namespace whose names end with either .css or .js can only be edited by WP:INTADMINs. Related to this, .css and .js pages in User: space can only be edited by their "owners" and by WP:INTADMINs - this means that I may edit User:Redrose64/common.js but nobody else's. At one time, all admins were also intadmins, but that changed in August 2018 when all admins lost the intadmin right and had to apply for it separately. Very few people have been granted it since then. --Redrose64 🌹 (talk) 08:17, 8 October 2020 (UTC)

Pages discussing Wikipedia's protection policy

• https://www.vox.com/recode/2020/11/2/21541880/wikipedia-presidential-election-misinformation-social-media
• https://slate.com/technology/2020/10/theresa-greenfield-iowa-senate-race-wikipedia-page.html
• https://thewire.in/tech/sushant-singh-rajput-death-wikiped-page-battle
• ...

CapnZapp (talk) 10:10, 3 November 2020 (UTC)

Is limited-IP-range page protection possible?

Is it it possible to directly range-block-protect a page, as a form of "limited semi protection"?

If it's not possible to do it directly, is it "within process" to do it by way of an edit filter ("if page is SMALL_LIST_OF_PAGES and IP address is in range Y-Zs and date is less than EXPIRATIONDATE then disallow and alert editor to log in and try again") as an "low-impact" alternative to semi-protection or pending-change protection, assuming one or both would be granted if requested?

I ask because some of the vandalism I've seen comes from IP ranges that are too big to block entirely and the vandals focus on a small set of articles. In some cases non-autoconfirmed editors outside that range have been making useful edits. davidwr/(talk)/(contribs) 14:57, 19 November 2020 (UTC)

@Davidwr: not technically a "protection", however one could place a page-specific partial block on an ip range (e.g. testwiki:Special:Redirect/logid/253570) - is that the affect you are looking for? — xaosflux ^Talk 15:01, 19 November 2020 (UTC)

@Xaosflux: Thanks for the answer. I see on WP:PBPOL and Wikipedia:Partial blocks that this is also an approved way of doing things.

However, its absence from the information page Wikipedia:Blocking IP addresses seems a bit glaring to me. What do you think?

If there is support for adding a sentence or two to Wikipedia:Blocking IP addresses, I'll propose something on that project talk page. davidwr/(talk)/(contribs) 15:22, 19 November 2020 (UTC)

@Davidwr: Wikipedia:Blocking IP addresses is only an information page, so you should be able to edit it to reflect useful info that is aligned with the WP:Blocking policy and the notes at Wikipedia:Partial blocks. — xaosflux ^Talk 15:46, 19 November 2020 (UTC)

In a small edit war, wouldn't it be a better idea to temporarily block the affected users from editing that article rather than fully protecting it?

Wouldn't it be a better idea to temporarily block the affected users from editing that article rather than fully protecting it? Full protection destroys any chances of almost any uninvolved person from improving it, especially in high-visibility ones. 4thfile4thrank (talk) 04:45, 5 December 2020 (UTC)

Blocking normally productive editors has bad side effects. It's kinder and better for the encyclopedia to fully protect the article for however long it takes for the heated blood to cool down. That's usually less than a day or two, or maybe a week for cases involving nationalism or other drivers. Johnuniq (talk) 05:49, 5 December 2020 (UTC)

RfC for a new protection level

I feel like extended confirmed protection is too over-powered. Going from semi-protection, that's 490 more edits to edit the page. I think we should have a new protection level, one that needs 100 edits and 10 days on your account, or something else for criteria. I still think that extended confirmed protection should still exist, as is, but not be the thing over semi-protection or Pending Changes protection. So, is this a good idea, or is it not needed? Arsonxists (talk) 16:58, 15 December 2020 (UTC)

Discussion

@Arsonxists: I think your RfC is premature, at the very least it should be further developed before you open a !voting survey. WP:VPI is a good place to get some general feedback. — xaosflux ^Talk 17:30, 15 December 2020 (UTC)

Oh, ok. Was actually thinking of going there, but I saw that changes to policy must be posted in the policy tab, so I posted it here. Arsonxists (talk) 17:41, 15 December 2020 (UTC)

@Arsonxists: eventually at least an announcement would go there, but the others at WP:VPI (and even here) will be able to help you build up your RfC in a format that won't be doomed to fail. Personally, I don't think this will gain much community support but new ideas are generally welcomed to be discussed! — xaosflux ^Talk 18:56, 15 December 2020 (UTC)

Protection table change

I am proposing a change to the {{Protection table}} used prominently in this policy article. At: Template talk:Protection table#Change the table proposal. I mention the changes there and would appreciate feedback. Thanks Terasail^[✉] 16:41, 11 January 2021 (UTC)

What's this user trying to do?

I saw that User:I am RedoStone was changing page protection tags, and couldn't understand why. Can someone with more knowledge in this area take a look? Curb Safe Charmer (talk) 19:57, 1 February 2021 (UTC)

PC lock is not white?

Unless I'm colorblind, the Pending Changes lock's shortcut is WP:WHITELOCK, but the lock face clearly isn't white:

, it's gray. WP:SILVERLOCK already exists for semiprotection, so should a shortcut for WP:GRAYLOCK be made? And if so, GREYLOCK too? WhoAteMyButter (📨│📝) 20:20, 5 January 2021 (UTC)

It used to be File:Padlock-silver-light.svg, see Wikipedia:Village pump (proposals)/Archive 155#Proposal/RFC: Redesigning page-protection padlock icons to be more accessible from October/November 2018. davidwr/(talk)/(contribs) 🎄 20:55, 5 January 2021 (UTC)

Please no punning on gray/grey. --Izno (talk) 22:42, 5 January 2021 (UTC)

There izno need for such levity. EEng 20:43, 1 February 2021 (UTC)

Text under Semi-protection

I would replace "as well as" with "or" in the phrase "..., as well as accounts that are not ...". --195.139.144.122 (talk) 16:28, 28 February 2021 (UTC)

Feedback requested at Template:Pp-vandalism

Your feedback would be appreciated at Template talk:Pp-vandalism#Proposed new param 'sandbox'. Thanks, Mathglot (talk) 23:00, 3 April 2021 (UTC)

Semiprotection

Vaunting of semiprotection is the way to wikipedia failure, censorship and forking. I mean, the use of the template {{pp-protected}} is mandatory according to Wikipedia:Rough_guide_to_semi-protection. This means that some user can express his preference to not display the padlock image by simply removing it, the better by discussing in talk page. Why was this type of edits contested as disruptive? Brainfrogk4mon (talk) 19:35, 7 April 2021 (UTC)

The template is there for WP:accessibility reasons. Just because you understand the reason why you cannot edit a page, doesn't mean everyone does it. The image of a padlock, which seems to be your only problem according to all your talk page comments in several places, is not a synonym of censorship, failure nor forking; if anything is a synonym of the failure of those editors that have managed to get a page protected because they can't behave there properly. Even if the padlock is hidden, the page will still be protected as they don't protect the pages, they merely indicate that a page is protected. Not using these templates, as the Spanish Wikipedia does, is a failure in itself, as it creates the presumption that a page is unprotected and anyone can edit it. And lastly, the image is so small that it cannot create loading problems as you said. The loading problems are created by the general size of the page. (CC) Tbhotch^™ 20:32, 7 April 2021 (UTC)

Appreciating your answer, several places consist of 2 places: talk page and VP. Anyway the image is an image and has an impact, if we consider billions of connections. The absence of Edit source already indicates you cannot edit. As well as the reason why you cannot edit a page is displayed in Page Information. The padlock is cool, but it's not symbol of freedom. Brainfrogk4mon (talk) 21:08, 7 April 2021 (UTC)

Okay we're past the point of WP:DE. No one can make heads or tails of what you're saying and even though I have somewhat of an idea, there is no consensus for it. No one forces you to "download" the lock image and you disliking the look of it or finding it discouraging isn't a good reason to remove it. Wikipedia is not synonymous with freedom, it's the free encyclopedia, meaning no one will ever be charged to edit it or read it. EGGIDICAE🥚 21:19, 7 April 2021 (UTC)

Permanent protection

It is said in the Permanent Protection section:

"In addition to hard-coded protection, the following are usually permanently protected: 'Pages that should not be modified for copyright or legal reasons, such as the general disclaimer or the local copy of the site copyright license.'"

Both of them are not permanently protected but only full protected. Shouldn't the text be either moved to the appropriate section or removed altogether so as to not be misleading or to best reflect the actual situation?

--OriginalKratos (talk) 04:00, 14 April 2021 (UTC)

It's under the subheader of full protection. I've reworded this to be a little clearer. ◢  Ganbaruby!  (Say hi!) 08:32, 14 April 2021 (UTC)

Move protection

I've always been curious why page movers can't move move-protected pages that aren't otherwise locked. Since there are thousands of indefinitely move protected pages in mainspace, a considerable number of articles like toast (food) and Plants vs. Zombies are moved occasionally after consensus in a requested move discussion (just to name two RMs that I closed in the last month). Page mover is a fairly high trust PERM and it can be yanked if the editor moves the page without consensus, so why is it the case that only admins can move move-protected pages? (t · c) buidhe 04:08, 19 April 2021 (UTC)

It depends upon the level of move protection. Move prot has the same five levels as edit protection (none, semi, extended-confirmed, template, full) although setting semi-protection for moves is pointless because unconfirmed editors cannot move pages whatever their prot level. So a pagemover who registered more than 30 days ago and who has more than 500 edits can move pages that are move-protected to EC level (or below), but not those that are move-protected to TE level. --Redrose64 🌹 (talk) 20:12, 19 April 2021 (UTC)

Proposed renaming of the word "silverlock"

Would it be more appropriate to say the semi-protection lock is a gray lock? So instead of it saying "WP:SILVERLOCK," in the info-box, it should say "WP:GRAYLOCK." Obviously trivial, but I just wanted to point that out. LucasA04 (talk) 18:45, 28 April 2021 (UTC)

This is there to remind us of the good old days when File:Padlock-silver.svg was the semi protection icon. WP:SEMI is the better shortcut anyway. —Kusma (t·c) 18:59, 28 April 2021 (UTC)

File:Map.jpg and File:Sound.wav

Praxidicae Why do you keep reverting my edits? Technically, both File:Map.jpg and File:Sound.wav are salted pages. Neel.arunabh (talk) 17:22, 15 May 2021 (UTC)

They are fully protected. It's out of context further in the policy and it discusses this specifically under the subheading regarding files. YODADICAE👽 17:23, 15 May 2021 (UTC)

All three are salted, actually - File:Photo.jpg looks blue because there's a redirect on Commons. If there are any similar locally-protected images left, I haven't been able to find any. —Cryptic 17:40, 15 May 2021 (UTC)

The status quo is fine, I agree with the reverts. Can't see a good reason for the change. ~ ToBeFree (talk) 05:52, 20 May 2021 (UTC)

Possible exception to NO-PREEMPT?

This is for something pretty far down the road, but that thought has occurred to me now that the 2021 Atlantic hurricane season is underway with Subtropical Storm Ana. The fifth name on the list for this year is Elsa, which I anticipate will result in a lot of vandalism related to the movie Frozen. I see that preemptive semi-protection generally is not allowed, but would this instance be a possible exception when Elsa forms in a few months? It would only be temporary, for the duration of the storm and media coverage of any aftermath. TornadoLGS (talk) 01:33, 23 May 2021 (UTC)

No. We'll protect if and when necessary. Primefac (talk) 01:35, 23 May 2021 (UTC)

contributor=editor

Extended content

"Contributor" as well as "Editor" are used in WP:Protection policy and no definition is given... In a way or another a "clarification" must clearly be made on such a highly visited page (nearly 102,000 page views in the past 30 days, see Page information). Let's be precise and clear from the beginning for newcomers and non-editing readers (in their minds another name=another status, and this is even more true for non-native English speakers). A quick and short explanation that a contributor is an editor should be provided to them (if it is not stated, people will tend to think that they are different "status" — and it can be "confusing" because these 2 words are sometimes used together on Wikipedia pages). I have noticed that "technical" pages (for example: administrative pages) will try to push the usage of "Editor" (although you can find "Contributor" from time to time... even against the will of the editors because of transclusion; see example below). But in general, Encyclopedia articles (for example: Wikipedia) and legal pages (for example: Wikipedia:Copyrights) will mix "Contributor" and "Editor" words incoherently and randomly. Some uses found: "a community of contributors", "a major contributor", "foreign-language contributors" but "Template editor"... English is spoken all over the world and non-native English speaking readers will find no aid using a thesaurus to help them understand that contributor=editor: Contributor: [Merriam-Webster Thesaurus: contributor] — Wiktionary: contributor Editor: [Merriam-Webster Thesaurus: editor] — Wiktionary: editor According to Merriam-Webster Thesaurus and Wiktionary, "Contributor" and "Editor" are not synonyms! Example of transclusion: An informative notice Template:essay that can introduce "confusion" to newcomers and readers (especially when this notice is placed on top of articles only using "Editor" in their pages, for example: Wikipedia:Cherrypicking is using 33 times "Editor" and 0 time "Contributor"): Actual version: In some circumstances, pages may need to be protected from modification by certain groups of editors. My suggestion (or something better phrased from a native English speaker): In some circumstances, pages may need to be protected from modification by certain groups of editors. Please note that individual editors are also known as contributors. Antoine Legrand (talk) 22:10, 9 September 2021 (UTC) That is a rather clunky addition to the sentence, and I'm not particularly sure it needs to be added in. Primefac (talk) 22:46, 9 September 2021 (UTC)  Alternative found: improving consistency by renaming: contributors > editors; to avoid incoherent and random mixing of these two terms on the page (therefore no need to evaluate the opportunity to state contributor=editor for newcomers and readers). Antoine Legrand (talk) 23:33, 10 September 2021 (UTC) I'm amazed that anyone (even a non-native speaker) would think this is confusing, and do not believe we need to take any action here. But I am astonished that you have seen fit to add this concern to at least 20 other pages. I wonder if you will get to Wikipedia:Disruptive editing soon. => That's intended to be a strong hint. I also notice that while you are busy redundantly duplicating in a redundant way the words "editor" and "contributor" everywhere, you are ignoring "user", "account", "volunteer" and probably a few other equivalent terms. The versatility of English is both a blessing and a curse, and, IMHO, if non-English speakers can't understand that contributors are editors are Wikipedians, etc., then they should maybe stick to the Wikipedia in their native tongue (like French, for example), where things are clearer for them. — JohnFromPinckney (talk / edits) 01:20, 11 September 2021 (UTC) @JohnFromPinckney:Please use Ping next time, because if I had not taken the time to just take a quick look to this closed discussion, I would never have seen your message. Even if it was not a closed discussion, using Ping is a good habit to have a notification immediately sent to the concerned editor, that a new comment awaits him. First and foremost, I want to thank you for your advice/warning about disruptive editing, I didn't think about it and had not yet read that page. In my mind Be bold was my first consideration (except for policies as it is clearly stated on each of them that changes must meet consensus before being published - however, minor cosmetic alterations that do not affect the meaning are acceptable). So my first step about editing this policy has been to publish my "suggestion" on its talk page. In the meantime, I published "contributor=editor=Wikipedian" on Wikipedia as a second sentence of the whole article. Such a clarification was obviously necessary because the modification of such an important article (nearly one million views per month) was not immediately undone, especially since it concerned one of the very first sentences (6,500 page watchers and many editors and admins being instantly informed of such a modification). I did the same clarification on another high traffic page Wikipedia:About and even published "contributor=editor=Wikipedian" as first sentence on Your first article. Again if that posed a problem, someone would have reverted my changes and we would have continued the discussion on the talk page trying to reach a consensus. I don't consider redundantly duplicating in a redundant way the words "editor" and "contributor" everywhere. I only start replacing one term with another if the replaced term has a maximum of 4 occurrences, and then only if a term is already present in large majority. Until now, the majority term has always been "editor". And this is why I always put in "Edit summary" : "counted on this page before changes...". Otherwise, I try to publish "contributor=editor=Wikipedian" in the most appropriate place on the page, like on Wikipedia. My only aim is to make the terms easier to understand, and yes, some form of standardization is sometimes necessary. As stated in my initial post: "contributor" and "editor" are not synonyms, and until my recent contributions there were virtually no mention at all on Wikipedia that a contributor is an editor (and vice-versa), not to mention Wikipedians... — Antoine Legrand (talk) 21:01, 11 September 2021 (UTC) @Antoine Legrand: I would normally not add a ping to a page where the person to whom I am replying posted less than than two hours previous. I assumed you have this page on your watchlist, and that pinging you would be disruptive. Thankfully, your attempt to ping me failed because you did not sign your post, but I've seen your reply of an hour-and-a-half ago come up on my watchlist, so everything's fine. By the way, just because you add a {{done}} template to some indented code doesn't mean to me that a discussion is closed. I frankly didn't understand why you did that, or why you indented your texts, or why you kept changing your text after Primefac answered you. But then I still don't see the necessesity of your changes, but I'm not going to revert them all, because I think that would be disruptive, too. — JohnFromPinckney (talk / edits) 22:41, 11 September 2021 (UTC) Discussion will be centralized on: Wikipedia_talk:Project_namespace#contributor=editor=Wikipedian — Antoine Legrand (talk) 18:59, 12 September 2021 (UTC)

Moved to where it belongs: Wikipedia talk:Wikipedians#contributor=editor=Wikipedian. Lembit Staan (talk) 21:51, 12 September 2021 (UTC)

Question about protection policy

Can a title be creation-protected even if no-one has attempted to create an article with said title? Creation-protection is useful if someone has previously created, or tried to create, an inappropriate article; but is that a necessary condition for creation-protection? See Special:ProtectedTitles.--Solomonfromfinland (talk) 13:23, 9 October 2021 (UTC)

@Solomonfromfinland: creation protection does not require that the title previously existed or attempted to exist. See example on testwiki here: testwiki:Special:Redirect/logid/265396. — xaosflux ^Talk 14:39, 9 October 2021 (UTC)

Note, this is a technical answer about the protection system, not really a "policy" answer. Titles should only be protected for reasons covered by the protection policy here. — xaosflux ^Talk 14:40, 9 October 2021 (UTC)

It's a policy question if you view the question less of a technical "can we" and more of a hypothetical (e.g. "if there's a page name I want salted can I request it even if it hasn't been deleted?").

That being said, the answer to that question is "no, we don't do pre-emptive salts on inappropriate page names". I could list dozens of never-created pages that should ideally never be created, but all someone has to do is change a single character (or add something else inappropriate to it) to make that salt useless. No point in giving people ideas of inappropriate things to do by checking the page creation logs. Primefac (talk) 11:52, 10 October 2021 (UTC)

Sorry, i slightly misused the term "policy"; the more appropriate term was "technical". In other words, salting is physically possible even if no-one has even tried to create said title; but according to policy, that should not be done; salting should only be done for the reason listed here, namely if someone has tried to create an inappropriate article.--Solomonfromfinland (talk) 11:34, 11 October 2021 (UTC)

Correct. Primefac (talk) 19:37, 11 October 2021 (UTC)

Indefinitely, fully protected pages

Hey, all,

I just came across Wikipedia:Database reports/Indefinitely fully protected redirects pages. I'm sure this issue has come up before but is there a good reason for a redirect to have full protection for 15 or 17 years? I realize that it doesn't cause any damage for a page to be protected for over a decade but I'm also wondering if it's still necessary. I assume any edit wars over redirects have died down after 15 years and it could be that an editor now has a legitimate reason for changing a redirect or creating an article where there once was a redirect. I think it's good to periodically ask whether full protection of all of these pages is still warranted. Thanks. Liz ^{Read! Talk!} 18:36, 12 October 2021 (UTC)

@Liz: think it is fairly safe for admins to go unprotect these discretionarily if they are old, but case-by-case. For example Assburger syndrome and REDIRECT probably should stay protected, while Silver Trail Middle School is probably safe to unprotect. — xaosflux ^Talk 18:57, 12 October 2021 (UTC)

Add section: “Editing protected pages”

In most cases, if you do not have the sufficient permissions to edit a protected page, there is no way to edit it directly. However, there are ways for users that cannot edit the page to request to have an edit made using the {{Edit request}} template. Placing the template on the talk page with the requested change to the article can attract editors who may be willing to implement an edit request on a user’s behalf. 172.112.210.32 (talk) 03:41, 4 December 2021 (UTC)

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. ScottishFinnishRadish (talk) 11:36, 4 December 2021 (UTC)

Updating the protected page symbols?

I've added a note on WP:VPI#Updating_the_protected_page_symbols? about wp's page protection lock symbols versus the {{Closed_access}} {{Open_access}} symbology used by wider open knowledge movement. T.Shafee(Evo&Evo)^talk 05:28, 11 March 2022 (UTC)

WP:PREFER

The third paragraph of "Content disputes" (WP:PREFER) currently reads "Protected pages may not be edited except to make changes that are uncontroversial or for which there is clear consensus." I assume this means "Fully protected pages", since it's a subsection of "Full protection". Would it be appropriate to make this change to avoid folks misreading it as a restriction on editing, say, a semi-protected page without consensus? –dlthewave ☎ 20:31, 27 March 2022 (UTC)

It would depend upon why the page was being edited. Say there's a section of a page that is subject to a content dispute between an IP and an autoconfirmed user. The IP makes an edit and then an admin semi-protects the page. If the autoconfirmed user makes an edit to the disputed section (not necessarily to revert the IP), that could be seen as abuse of rights; but if thy had made an unrelated edit to a different section, that could be seen as OK. --Redrose64 🌹 (talk) 22:34, 27 March 2022 (UTC)

Agreed; I try to put the minimum level of protection necessary, so if two AC-or-lower editors are warring, I'll put ECP on the page so that uninvolved editors can still edit. Similar for IPs and semi-prot. Primefac (talk) 07:43, 28 March 2022 (UTC)

Question about viewing source on protected pages

Why is it that some templates seem to hide their source text if they're protected?

I'm still learning a lot about editing and often want to look at examples in other articles for reference. Lately, I'd been working on an infobox so, in addition to reading documentation, I wanted to see how some other infoboxes implemented stuff. Looking at the template for Automatic taxobox (https://en.wikipedia.org/wiki/Template:Automatic_taxobox), if I click on "view source", all I see is

"<includeonly><nowiki/>{{#invoke:Automated taxobox|automaticTaxobox}}</includeonly><noinclude> {{doumentation}}</noinclude>"

The only way I can actually see the inner workings is if I go to "View History", open up an older version, then view the source for that older version. I found the same for some other "fully protected" and "template protected" templates like "Template:Cite web". Can someone explain this for me? Jasonkwe (talk) (contribs) 20:49, 10 April 2022 (UTC)

@Jasonkwe: This is not actually directly(*) related to protection. The '#invoke' syntax indicates that a module is run instead. You can find the list of modules near the end of the 'edit' version of the page. For Template:Automated taxobox, the syntax tells you it's calling Module:Automated taxobox. You will normally find this type of thing on the more widespread and complicated templates, (*) which are often protected. -- zzuuzz ^(talk) 21:12, 10 April 2022 (UTC)

Oooohhhhh, gotcha. Thanks! The #invoke syntax made me think it was protection-related and essentially saying "call self" and storing the inner workings elsewhere (which I could see in past versions). I see now that it's because the change to invoking the module was one of the last few revisions to the template so a few versions back actually showed the source text itself. Thank you!Jasonkwe (talk) (contribs) 21:22, 10 April 2022 (UTC)

Preemptive protection for Today's Featured Article?

Apologies if this has been discussed before (likely has), but has there been any broad community discussion of preemptively applying semi-protection to the current featured article on the Main Page? Or can the main page summary be protected separately from the article somehow? (Asking after seeing a block evader vandalize the featured article two days in a row.) Funcrunch (talk) 04:20, 13 May 2022 (UTC)

@Funcrunch: Semiing is on Wikipedia:Perennial proposals. Last I checked, there's consensus to preëmptively PC-protect but no one's set up an adminbot to implement that yet. As to the summary on the Main Page, that is fully protected. -- Tamzin^{[cetacean needed]} (she/they) 04:24, 13 May 2022 (UTC)

Hmm, I'm fairly sure I saw a vandalized summary of the featured article on the main page yesterday when I pulled up the app on my cell phone. (Didn't take screenshots and all the edits were quickly reverted and soon redacted) Funcrunch (talk) 04:29, 13 May 2022 (UTC)

Wikipedia:Village pump (proposals)/Archive 183#RFC: Pending-changes protection of Today's featured article, perhaps. --Redrose64 🌹 (talk) 21:52, 13 May 2022 (UTC)

Tracking things down, Wikipedia_talk:Today's_featured_article/Archive_15#TFA_vandalism seems to be the last discussion - Legoktm, did anything happen with that? Galobtter (pingó mió) 02:17, 14 May 2022 (UTC)

Because of IRL stuff, I'm roughly 3 months behind on my wiki commitments and slowly catching up. So, nope, no progress yet. Hopefully soon. Legoktm (talk) 06:42, 15 May 2022 (UTC)

@Tamzin and Redrose64: So how can this process be moved forward? Today's featured article was vandalized for at least the 12th (I think) day in a row, minutes after posting. Funcrunch (talk) 01:52, 14 May 2022 (UTC)

Pinging Paul Erik on this discussion since he's been dealing with the current streak of TFA vandalism. Funcrunch (talk) 06:10, 15 May 2022 (UTC)

Protection policy not fair to unregistered

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Semi-protection and up stops unregistered users from editing, and Pending Changes Protection prevents unregistered users from seeing their own edits. 71.237.21.218 (talk) 00:20, 16 March 2022 (UTC) Maggie Simpson lover

Conservatively 80% of vandalism is carried out by IPs. Absent the availability of page protection I am almost certain that editing by unregistered users would not be allowed at all. - Ad Orientem (talk) 00:29, 16 March 2022 (UTC)

80% of IP editing is constructive. Talk about throwing the baby out with the bathwater. 2A00:23C4:570A:600:B108:27BF:92F:5059 (talk) 17:29, 11 April 2022 (UTC)

Wikipedia can and reserves the right to prevent further disruption when required. (CC) Tbhotch^™ 18:15, 11 April 2022 (UTC)

Says YOU, Mr. REGISTERED user! 71.237.21.218 (talk) 16:21, 29 May 2022 (UTC)

That Ad Orientum guy, and maybe Tbhotch-who-I-don't-have-to-pay-royalties-to-just-because-his-name-is-TRADEMARKED. 71.237.21.218 (talk) 16:25, 29 May 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Why is this locked with wrong information?

According to the 2017 census, pashtuns make around 18% of pakistan's population. this is mentioned in detail in this page: https://en.wikipedia.org/wiki/Pashtun_diaspora#Pakistan

why is this page giving wrong figures and numbers? 103.125.178.198 (talk) 08:53, 12 October 2022 (UTC)

This is not the place to discuss this, but I cannot determine where you are intending to post this. Please go to that page's talk page and start the discussion there. Primefac (talk) 09:20, 12 October 2022 (UTC)

Semi-protected edit request on 14 October 2022

in section" First Voyage to Florida, 8th paragraph, it says: it would soon become the primary route for eastbound ships leaving the Spanish Indies bound for Europe Correction: ships leaving the Spanish West Indies, (https://en.wikipedia.org/wiki/Spanish_West_Indies) WeatherOrg (talk) 14:44, 14 October 2022 (UTC)

 Not done: this is the talk page for discussing improvements to the page Wikipedia:Protection policy. If possible, please make your request at the talk page for the article concerned. If you cannot edit the article's talk page, you can instead make your request at Wikipedia:Requests for page protection#Current requests for edits to a protected page. ScottishFinnishRadish (talk) 17:54, 14 October 2022 (UTC)

Why was this policy created?

24.59.254.203 (talk) 17:18, 19 October 2022 (UTC)

Because we need to be able to define when and why a page should be protected. Primefac (talk) 17:39, 19 October 2022 (UTC)

Why is this page only semi-protected?

Can't this very page talking about page protection itself have a higher protection? Cjjjkscratch (talk) 05:31, 27 November 2022 (UTC)

It *can*, but why should it? Writ Keeper ⚇♔ 06:15, 27 November 2022 (UTC)

What is the difference between Template:pp-reset and Template:pp-office?

I was unable to find a discussion explaining the difference between {{pp-reset}} and {{pp-office}}, and their documentation did not help to enlighten me. Does anyone here know the difference? Should they be merged?

Also, neither template has any transclusions. Are they still used/useful? – Jonesey95 (talk) 19:50, 4 February 2023 (UTC)

You can find the original meaning of 'reset' in the history.[21] In effect it's used to explain a 'blanking' and permit editing. Whereas the 'office' template is more generic and typically full protection, with all that full protection usually entails. Why 'reset' lost its explanation is a mystery to me at this time (maybe Mr. Stradivarius knows?). The 'reset' action probably hasn't been used for many years, but it's still a potential action so I wouldn't encourage a merge. For example it's still mentioned on meta In any case you'd first want to get an opinion from the office person, as that's all that will ultimately matter. -- zzuuzz ^(talk) 20:30, 4 February 2023 (UTC)

I'm pretty sure that I converted both templates to Lua without changing their contents appreciably, so you'll have to look further back for what the difference is. From the history I see that {{pp-reset}} was created first in 2006, and {{pp-office}} was created a year later in 2007. The creator of {{pp-reset}} appears to not be around any longer, but maybe AzaToth, the creator of {{pp-office}}, remembers something? — Mr. Stradivarius ^{♪ talk ♪} 23:54, 4 February 2023 (UTC)

From what I can recall, {{pp-reset}} is a subset of {{pp-office}} for when it's deemed possible to rewrite it instead of just locking it down fully. _→AzaToth 01:13, 5 February 2023 (UTC)

Oh, as to why the text of {{pp-reset}} stopped being displayed, that does sound like a Lua issue. I will have a look... — Mr. Stradivarius ^{♪ talk ♪} 23:57, 4 February 2023 (UTC)

The original text for {{pp-reset}} is still present, but the template now defaults to being just a protection icon. You can display the banner with the text by using {{pp-reset|small=no}}. (Note: the page has to actually be protected for the banner to show up.) If showing the banner by default would be better, this can be done by changing the default arguments in the config module. — Mr. Stradivarius ^{♪ talk ♪} 00:23, 5 February 2023 (UTC)

I've added the banner text to the documentation page: Template:Pp-reset#Banner. — Mr. Stradivarius ^{♪ talk ♪} 07:08, 5 February 2023 (UTC)

I'd recommend deleting both. In the rare event that a page is protected as an office action, the generic {{pp}} could be used. * Pppery * _{it has begun...} 05:53, 5 February 2023 (UTC)

Thanks for that link. It looks like {{pp|reset}} does the same job as {{pp-reset}} and the same appears to be true for {{pp|office}}. The {{pp}} template is better-maintained. When two templates perform the same function, we usually merge them. Given that neither pp-xxx template has any use right now, this would be a good time for a merge. – Jonesey95 (talk) 15:44, 5 February 2023 (UTC)

There's nothing to merge. The entire effective content of {{pp-reset}}, {{pp-office}} and {{pp}} is exactly the same: {{#invoke:Protection banner|main}}. --Redrose64 🌹 (talk) 21:29, 5 February 2023 (UTC)

Thanks, all. I have nominated the two templates for deletion at this TFD. – Jonesey95 (talk) 23:47, 5 February 2023 (UTC)

@Jonesey95 Any particular reason {{Pp-office-dmca}} isn't included in this? Terasail^[✉️] 00:19, 6 February 2023 (UTC)

Just my usual excuse of not being omniscient. Pesky thing, that. I have added it. – Jonesey95 (talk) 00:28, 6 February 2023 (UTC)

It's the worst when that happens... Why can't they teach us how to know what we don't when we need to in school? Terasail^[✉️] 00:40, 6 February 2023 (UTC)

Is it possible to create-protect all possible diacritic variations of a title?

I've recently been dealing with a persistent sockpuppeteer (Wikipedia:Sockpuppet investigations/Gsthae with tempo!) who likes to create nonsense drafts with similar titles (e.g. Draft:Gsthae with tempo! and Draft:Mixing Sailors). Now that many of those titles have been create protected, they continue by using variations of those titles with diacritics. Is there a way to prevent this? Partofthemachine (talk) 01:09, 14 March 2023 (UTC)

all possible diacritic variations - no. If an LTA is going so far as to make ridiculous pages like this, I would actually suggest un-protecting the original/primary title, if only so you don't need to play whack-a-mole all day. Primefac (talk) 08:36, 14 March 2023 (UTC)

@Partofthemachine: Apart from the fact that we don't pre-emptively protect pages, there are hundreds of characters which might be described as "letters with diacritics" and potentially millions of potential page titles. --Redrose64 🌹 (talk) 09:23, 14 March 2023 (UTC)

The title blacklist might be more efficient than move protection. HJ Mitchell | Penny for your thoughts? 10:17, 14 March 2023 (UTC)

The abuse filter can normalise text to remove diacritics etc. see "ccnorm" at mw:Extension:AbuseFilter/Rules format. So requesting a filter might be even better. the wub "?!" 12:45, 14 March 2023 (UTC)

Should there be spaces for the names of the locks? (for example, Silver lock instead of Silverlock)

Before I was going to edit a page about the locks for protections, I noticed that the names for the locks didn't have spaces. OMGShay 92 (talk) 13:35, 9 May 2023 (UTC)

OMGShay 92, not sure what you mean? Are you referring to pages like WP:SILVERLOCK? The lock itself is named File:Semi-protection-shackle.svg. (please do not ping on reply) Primefac (talk) 14:21, 9 May 2023 (UTC)

something like that, yeah. OMGShay 92 (talk) 08:13, 10 May 2023 (UTC)

See the comment by xaosflux below; our redirects/shortcuts are generally in ALLCAPS with no spaces. Primefac (talk) 08:42, 10 May 2023 (UTC)

Those are mostly references to the our standard WP:SHORTCUT syntax, which is mostly "WP:ABCDEF" (where ABCDEF is all caps, goes to a redirect page, and links to a better title or section of a page with a better title). — xaosflux ^Talk 18:21, 9 May 2023 (UTC)

Incorrect list of full protected pages

In the full protection section of the page, it lists 4 examples for full protected pages, but as far as I can tell, two of them (File:Map.jpg and File:Sound.wav) are not full protected, but have been salted. The second is actually listed right after as an example of salted pages. Fobilman (talk) 20:10, 22 May 2023 (UTC)

"Wikipedia:XPROTECT" listed at Redirects for discussion

The redirect Wikipedia:XPROTECT has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 May 29 § Wikipedia:XPROTECT until a consensus is reached. Q𝟤𝟪 07:09, 29 May 2023 (UTC)

This page should have more protection.

As this page itself talks about protections, this page must be as protected as possible. It should have more than just semi-protection. Cjjjkscratch (talk) 06:26, 10 May 2023 (UTC)

​ Why? The semi is just to keep it from being vandalised by un-confirmed users. I see no evidence or need for increased protection. Primefac (talk) 07:12, 10 May 2023 (UTC)

Then why do other pages have more protection? Cjjjkscratch (talk) 07:23, 10 May 2023 (UTC)

Probably because they receive more vandalism? You'd have to give specific examples for me to be more accurate in my reply. Primefac (talk) 07:28, 10 May 2023 (UTC)

It's covered by WP:NO-PREEMPT. Besides, the page has more than 2000 watchers, so if people do make inappropriate edits, they'll be reverted pretty quickly. --Redrose64 🌹 (talk) 20:26, 10 May 2023 (UTC)

@Cjjjkscratch that ain't mæk any sense whatsoevre 88.110.55.255 (talk) 11:28, 21 June 2023 (UTC)

Semi-protection

Semi-protection is where a Wikipedia page is protected against new Wikipedia editors and those who are not logged into Wikipedia at all. Semi-protection should not be used to protect a page about protection. This will make it a hot-spot for vandalism if they find out that the article on protection is kinda sorta protected-ish. SmorcePanamora (talk) 06:26, 13 July 2023 (UTC)

If a page is a target for vandalism, its protection level can easily be increased. Making a rule based on a hypothesis probably does not make sense. – Jonesey95 (talk) 20:32, 16 July 2023 (UTC)

Elaborating on how semi- and extended confirmed protection should be applied.

I would like to add "The number of times a page has previously been protected and the amount of time between subsequent protections after each expiry should be considered when determining how long a page should be semi-protected." to the semi-protection section and "Like semi-protection, extended confirmed protection should be set for the shortest duration possible while still remaining effective. If a lower level of protection was previously in place, it will need to be manually reinstated when extended confirmed protection expires." to the extended confirmed protection (as escalation from semi-protection) section. This addition was reverted when I added it before. Are there any objections? TheRichCapitalist (talk) 20:43, 2 August 2023 (UTC)

Call me a stick in the mud, but I tend to think WP:CREEP applies. Note the section on preemption: "The duration of the protection should be set as short as possible, and the protection level should be set to the lowest restriction needed". Let me ask what your addition would add. We have the rough guides for all the wordy stuff. There may be a useful note about 'multi-level expiries', which would include full protection, but this is not a 'need to' situation. IMO. -- zzuuzz ^(talk) 21:55, 2 August 2023 (UTC)

Often, extended confirmed protection is set to indefinite the first time it is applied if the page previously had indefinite semi-protection, so the sentence you're referring to in the preemption section isn't being followed in practice when it comes to ECP. This is why I think my addition is warranted. I have also found a number of pages that were indefinitely semi'd the first time it was protected (although this is relatively less common) when a temporary protection would suffice, which is why I believe my addition to that section is warranted.TheRichCapitalist (talk) 22:58, 2 August 2023 (UTC)

Pre-emptive protection policy for travel articles prone to external link spamming?

I know we don't usually preemptively protect articles. However, I just want to draw your attention to the series of "Visa policy of COUNTRY" articles. They all usually have an external link section linking to usually government sources of information on visas, travel info, etc. However, some IPs and newly created accounts like to use these articles as a base to spam their travel agency/visa agency websites, which is against Wikipedia's policies on external links.

These websites could also end up having inaccurate information, or worse; are fraudulent or scams in of itself, but more likely that they'll just overcharge for services that you could have just gotten through official government channels, e.g. for US ESTAs or soon to be implemented for the European Union and UK, their ETIAS and ETA, respectively.

Just an example I've seen outside of the wiki; I've seen websites advertised on Google searches who will even charge you to fill in an online Singapore arrival card on your behalf, when you could have done it yourself for free! Personally, I find it a little weird relying on Wikipedia for this info, but if someone were to rely on this for actual travel information, and give their credit card info to some scammer and then showing up to a country and being deported for not having a valid visa -- I don't think we should be enabling this.

Examples of diffs where I've removed external links: United Arab Emirates, Kazakhstan, Qatar, Saudi Arabia, Thailand, Azerbaijan, Tanzania, Oman, Kuwait, Japan. With all of these, I have absolutely no idea when or who added these links, as I just did a quick scan of every single country's external links section.

These articles are rarely watched by anyone, so I'm wondering if possibly we could make a few small exceptions to the preemptive policy for this? Maybe just by pending protecting some of these articles, possibly starting with the ones I just listed? Fork99 (talk) 23:04, 9 August 2023 (UTC)

While I don't know exactly who added some of these links as I didn't check the article's entire history for every single case, all users that I have warned are either new users or IPs. Fork99 (talk) 23:06, 9 August 2023 (UTC)

I think this would be better handled via https://en.wikipedia.org/wiki/MediaWiki:Spam-blacklist or https://meta.wikimedia.org/wiki/Spam_blacklist. There are already a number of "visa" domains blocked and it wouldn't be too hard to write a regex to cover these more broadly using the examples from those diffs. Daniel Quinlan (talk) 00:19, 10 August 2023 (UTC)

There might be something in this, but I think we would need a larger consensus and potentially something along the lines of a WP:GS regime, expanding it maybe to also include "phone numbers in X" articles - spam is one thing but I have also noticed (both in the visa and phone number articles) that people have a really bad habit of putting incredibly personal info in these pages (visa ID numbers, phone numbers, etc), to the point where protecting it not only stops the spam but also decreases the proliferation of personal info that needs to be suppressed. Primefac (talk) 08:09, 10 August 2023 (UTC)

In the meantime, I made a request to blacklist the links mentioned at MediaWiki talk:Spam-blacklist. @Primefac: is there somewhere else we could take this further? Fork99 (talk) 08:38, 10 August 2023 (UTC)

Per Wikipedia:General_sanctions#Community_sanctions, such discussions are generally taken at WP:AN, but since this is less of an admin issue WP:VPR might be better. Primefac (talk) 08:44, 10 August 2023 (UTC)

I’ve taken this to the Village pump idea lab, link is here. Fork99 (talk) 09:15, 10 August 2023 (UTC)

"Extended Confirmed Protection" listed at Redirects for discussion

The redirect Extended Confirmed Protection has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 August 26 § Extended Confirmed Protection until a consensus is reached. #prodraxis ^connect 22:44, 26 August 2023 (UTC)

Differentiating types of protection from levels of protection

In conversations like this (see Xaosflux's comment and replies), there is confusion stemming from the fact that this page does not currently differentiate well between levels of protection (e.g. semi, EC, template, full) and types of protection (e.g. edit, move, upload). I propose that this page be restructured a bit so that there are separate level-2 sections for levels and types to help clarify this. {{u|Sdkb}} ^talk 03:37, 2 September 2023 (UTC)

I'm not sure how much it will help reduce confusion in discussions, but I think one additional header and a few careful rephrasings might help so I went ahead and made a few changes. I'm not in favor of any long-winded additions, though. Daniel Quinlan (talk) 05:07, 2 September 2023 (UTC)

As a part of my edit, I also undid this good faith, but unhelpful change. Daniel Quinlan (talk) 05:12, 2 September 2023 (UTC)

Sdkb, I understand what you were trying to do with the large text move, but it didn't help with the usability of the page. Less frequently used information was better placed lower down in the article. Let me see if I can add a bit more structure without making the page less usable. Daniel Quinlan (talk) 05:58, 2 September 2023 (UTC)

Is that better? I was able to keep the overview information up top and it's still followed by the details on protection levels that's used the most often. I also grouped levels and types into their own sections. I also created an uncommon protections section to keep the least frequently used protections lower down in the article. The structure of the middle of the policy looks like this now:

• Overview of protection

• Protection types
• Protection levels
• Requesting protection
• Comparison table

• Details on protection levels

• Pending changes protection
• Semi-protection
• Extended confirmed protection
• Full protection
• Template protection

• Details on protection types

• Creation protection (salting)
• Move protection
• Upload protection

Daniel Quinlan (talk) 06:31, 2 September 2023 (UTC)

I had debated moving the protection levels above the protection types because I had noticed the same thing. I decided not to, since on a page like this most people will get to where they want to go by searching rather than reading the whole thing, but it certainly doesn't hurt. I'm not a huge fan of sections labeled "overview" within any page, since the lead is supposed to be the overview, but that applies less to non-article pages. Overall, I think the re-organization is an improvement, so thank you, and further tweaks can always be made over time. {{u|Sdkb}} ^talk 13:48, 2 September 2023 (UTC)

You're right. While it is an overview of sorts, the section is primarily aimed at users requesting protection so that seems like a better way to label it. This also allowed me to make a few minor simplifications of the text.

I also removed the link at [[WP:IAR|Exceptions to this principle]] becaue it's silly. Protecting the main page and TFA were discussed ad nauseam, not the result of someone ignoring rules. Daniel Quinlan (talk) 20:35, 2 September 2023 (UTC)

I made a few more minor changes to clean things up and make everything more consistent. The overall article length is thankfully only ~70 words longer than it was before this flurry of changes. In the interest of stabilizing things, I'm going to try my best to stop here for now.

For anyone reading this, please note that no changes have been made to the actual policy. Daniel Quinlan (talk) 21:20, 2 September 2023 (UTC)

@Daniel Quinlan: A couple of observations on the the above. First, edit protection is missing from your "Details on protection types" section. Second, Pending changes is not a protection level - it is an independent setting with two levels - OFF: Accept all revisions and Review revisions from new and unregistered users. It applies only to edits (you can't have creates, moves or uploads restricted under pending changes) and is probably best seen as a supplement to edit protection, in parallel with it. You can, for instance, have a page that for editing is "Review revisions from new and unregistered users" indefinitely and is also edit-protected "Require extended confirmed access" for one month. --Redrose64 🌹 (talk) 11:36, 3 September 2023 (UTC)

For the sake of completeness, I actually added a brief section for edit protection yesterday.

I'm aware that PC is a separate option. The text already notes that it only applies to edits, but it's effectively treated as a protection level: in practice on WP:RFPP, in the comparison table, and with how protection icons function. I do think it is worth noting that it has a separate duration from edit protection. I'll try to work something into the article without making it too complicated. Daniel Quinlan (talk) 17:43, 3 September 2023 (UTC)

I added a brief note about the implementation of pending changes. I think any further detail beyond that is probably better suited to the Wikipedia:Pending changes article. Daniel Quinlan (talk) 19:40, 3 September 2023 (UTC)

Move protection of drafts

Under what circumstances is it acceptable to move protect a draft? The only circumstance I can think of is where there is an explicit consensus that something should be in draftspace. Usually, a challenge to a page being located in draftspace is handled by the draftifier opening an WP:AFD discussion per WP:DRAFTOBJECT. Why would it be acceptable for the draftifier to use their admin tools to win the debate over where the page is located? Iffy★Chat -- 14:48, 25 August 2023 (UTC)

I would say that if a draft has been submitted to AfC and rejected, and is then moved to mainspace without addressing the issues raised, then moved back on the grounds that it had been rejected when still a draft, and the pair of moves is then repeated at least twice with no intervening improvement to the draft, that could be grounds for move-protection. --Redrose64 🌹 (talk) 23:21, 25 August 2023 (UTC)

Why wouldn't AFD be the better solution in that instance? Most users don't have to use draftspace and that doesn't change if they choose to use AFC as a review mechanism. Iffy★Chat -- 09:11, 26 August 2023 (UTC)

You are correct. It is better to send the page to AFD rather than move-war over a draft. Primefac (talk) 14:59, 26 August 2023 (UTC)

But whilst it is in draftspace, AfD is not available - MfD is the process, and they tend not to delete drafts that have potential. --Redrose64 🌹 (talk) 07:44, 27 August 2023 (UTC)

If they are move-warring to put it into the article space, you nominate it when it is in Article space. Primefac (talk) 11:37, 27 August 2023 (UTC)

• AfC is not an official process outside of COI users and IPs. Anyone who is autoconfirmed has the right to create an article directly in main space. If someone publishes their AfC draft on their own, there's functionally no difference between just creating it in main space. The solution would be AfD, not move protection. TonyBallioni (talk) 19:05, 27 August 2023 (UTC)
• Would anyone object if I added Drafts should not be move protected. to this page? I don't see any good reason to move protect drafts aside from a clear consenus in favour or exceptional circumstances. Iffy★Chat -- 19:11, 12 September 2023 (UTC)

  Yes, I would object. I think we need some evidence that there's a significant problem or something to be gained by changing the policy. I only see 8 pages (after excluding Draft:Sandbox) that have been move protected for various reasons by 5 different administrators across the entire English Wikipedia. The policy does not need to be updated. If there's a specific page you need unprotected, please submit a request at WP:RFPU. Daniel Quinlan (talk) 20:34, 13 September 2023 (UTC)

  Well, 8, if you only count non-redirects, which is reasonable. And fully-protected pages, which probably isn't; there's 11 at extendedconfirmed and 7 at autoconfirmed. And, in particular, pages that are move protected rather than "have been", which really isn't: there's been about 400. Still, I too would like to see more evidence that stuff's being protected specifically to keep it from being an article; an awful lot of those protections are explicitly marked as move-warring, and a bunch more were move-protected along with edit protection. —Cryptic 21:14, 13 September 2023 (UTC)

  I assumed full move protection is the main issue based on User:Iffy/prot, but even with the additional 11 ECP pages, it still seems like this is a rare case, and WP:RFPU is the right way to unprotect any pages that no longer require move protection. (Autoconfirmed rights are required to move a page so the 7 autoconfirmed pages aren't actually protected beyond the default.) Daniel Quinlan (talk) 21:31, 13 September 2023 (UTC)

  As discussed above, the best practice for dealing with move warring is to open an AfD while the page is in article space and to allow the community to come to a consensus on the issue. Of the currently move protected drafts, the most questionable use of the admin tools is at Draft:Guillermo Rojas Bazan, the admin who protected it said they did so because To ensure that this rather fawning article goes through the full submission process, rather than being dumped into article space uncritically (my follow-up response was ignored), which to me sounds like a classic content dispute that the admin "won" with the use of admin tools. Iffy★Chat -- 22:03, 13 September 2023 (UTC)

  That article is clearly problematic and not appropriate for article space. It also doesn't look like Orangemike was involved in a content dispute prior to taking administrative actions. If the article gets fixed, you can request unprotection following the guidance in the policy.

  @Orangemike: Looping you into this discussion. Daniel Quinlan (talk) 23:29, 13 September 2023 (UTC)

  What happens if the page would be speedyable in articlespace, but not draft:? Beside the article-only criteria, drafts are typically given more latitude with G11 in particular than mainspace pages are, and G4 is also namespace-sensitive. Is it somehow better to stop a move war by moving it to mainspace yourself and then immediately deleting it? And even if it's not a speedy, it's still going to be a worse experience for the move-it-to-mainspace side of a move war to have the page deleted at afd than to have it be stuck in Draft: for a while.

  What if there's edit warring on a draft? Are administrators expected to edit-protect but then disable the default move protection (this is probably where the move=autoconfirmed protections I mentioned above came from)? Admins aren't going to remember that, it's hardly ever done, and I've seen edit wars before where I'm sure that - if the page were edit- but not move-protected - would've just had the fight shift into the title instead.

  This is going to look very out-of-place at WP:PREFER, and admins are going to accidentally violate it all. The. Time. Any admin is going to know not to move-protect a page while it's currently at John Doe did 9/11, but this is pretty esoteric. Certainly all the pages in draftspace I can remember move protecting, I did so there solely because that's where they were when I observed the move war; and failing that, the usual thikning would be to look back a day or so to see which title was the stable version.

  What if there's move warring between different titles, both in Draft:? Are we to just sit back and watch?

  I'm not going to say that there haven't been pages that might've been viable in mainspace move-protected in draft, or even that I haven't seen such pages, but I don't think the case that a blanket ban on move protection in this namespace has been made. I'm not even really convinced yet that a weaker statement like "Drafts should not be indefinitely move protected solely to prevent them from being moved into the main namespace" is needed: you'd need to show that the overwhelming majority of move protections in the namespace have been abusive, not just that some have.

  Going back to the original questions at the top of this section. The only time I think it could even be argued that it's ok for the draftifier themself to moveprotect would be if the page was speedyable in mainspace but not draft, and even then I'd still think it an abuse. I do think we could do a better job educating new users about WP:DRAFTOBJECT, probably either in the AFC templates or with the new pagenotice extension currently in beta. (I had occasion to bring up the same idea recently in a different context; it didn't get any traction there.) —Cryptic 00:22, 14 September 2023 (UTC)

Editor requests for unprotection

The policy currently states that:

Editors desiring the unprotection of a page should, in the first instance, ask the administrator who applied the protection unless the administrator is inactive or no longer an administrator; thereafter, requests can be made at Requests for unprotection. Note that such requests will normally be declined if the protecting administrator is active and was not consulted first.

In practice, most users go straight to WP:RFUP and few if any administrators on WP:RFUP direct users to ask the protecting administrator first. I think we can simplify this to read:

Editors desiring the unprotection of a page should make a request at Requests for unprotection. If you wish to loop in the administrator who applied the protection, you can leave them a talk page notice or ping them in your request.

Daniel Quinlan (talk) 21:33, 2 September 2023 (UTC)

It might be better to not even mention a talk page notice. It's overkill and a ping is more than enough if the requestor wants to do that. Daniel Quinlan (talk) 23:37, 2 September 2023 (UTC)

I am opposed to this. I haven't worked WP:RFPP in a while, but administrators there should absolutely be directing users to ask the protecting administrator first. (There are naturally common-sense exceptions to this, such as if the protecting admin is no longer an admin or has been inactive for a while.) When you un-protect a page, you are basically reversing another administrator's action. It is a matter of good practice and courtesy to have a quick discussion with the original admin before reversing their action—see WP:RAAA. Mz7 (talk) 08:17, 3 September 2023 (UTC)

I think there's a difference between reversing a recent action and revisiting a page's protection level months or years down the road. I'm not sure how much there is for an administrator to add, especially after a year or more:

• Most page protections initiated from WP:RFPP involve just a few minutes of investigation.
• Protection logs are pretty detailed in a consistent way, especially compared to some other administrator actions such as block actions.
• The article history is also easily examined.
• It's easy to reprotect a page if needed.

It's also worth pointing out that most unprotection requests are appropriately declined, especially when they are a request to reverse a recent protection action. I'd rather just decline a dubious request than send the requestor off to hassle an administrator that might not even remember protecting the page. Daniel Quinlan (talk) 18:10, 3 September 2023 (UTC)

Well, there's nothing in the policy that says you can't already decline a dubious request at WP:RFUP right away already rather than send them to hassle the protecting administrator—feel free to do that. The intent is that even if it's pretty clear in your eyes that a page should be unprotected, it's just a good courtesy to get the OK from the protecting administrator first if they're actively editing—who knows, there might even be something you missed. I would not be surprised if this policy exists as a learning from the past because administrators were unprotecting pages without knowledge of important context that the protecting admin could provide. The best way to make this process most efficient is if the requester approaches the protecting administrator in the first instance, so we should be encouraging that wherever it makes sense to.

I'm also not sure how we are getting the impression that "most users go straight to WP:RFUP"—that page has a warning highlighted in yellow that states, "Before posting, first discuss with the protecting admin at their talk page. Only post below if you receive no (favourable) reply." If an editor actually heeds that advice, then I suspect in most cases the request will never have to actually reach WP:RFUP, so we'll never see it there. Mz7 (talk) 20:33, 3 September 2023 (UTC)

Protection logs are pretty detailed in a consistent way, especially compared to some other administrator actions such as block actions not really. If a user is renamed, any block log moves to the new name. But if a page is moved, any prot log stays behind at the old page name. Pages subject to multiple moves and multiple protection actions over a period can end up with several separate logs scattered about. A so-called "round robin" page move makes the situation worse. --Redrose64 🌹 (talk) 21:21, 3 September 2023 (UTC)

You make a good point about there being a potential "unseen iceberg" of users actually following the policy. My observation only applies to the requests that reach WP:RFUP. Perhaps the best option is enhancing MediaWiki:Request-page-protection-form.js instead. Daniel Quinlan (talk) 21:41, 3 September 2023 (UTC)

There is definitely some tension here between the recommended practice and the de facto reality, so I would support making some change (either to guidance or to practice) to bring them into alignment. Perhaps there could be a requirement to ping the protecting admin at RFUP, and a bot that would comment on unprotection requests and attempt to ping them if the requesting editor forgets. The admins at RFUP would then wait until the protecting admin has a chance to respond before acting on requests. {{u|Sdkb}} ^talk 13:56, 3 September 2023 (UTC)

Don't know if this would be CREEP or it would just be ignored, but there could be an added parameter where the editor has to provide a link to the original admin's talk page indicating that they have been asked. Primefac (talk) 14:01, 3 September 2023 (UTC)

Requiring a ping instead of a prior discussion would be an improvement on the policy, especially if the bot was able to help bridge the gap between the policy and what users actually do. Daniel Quinlan (talk) 18:16, 3 September 2023 (UTC)

I for one usually ping the protecting admin if he wasn't informed in some way about the request; if they don't chip in after a certain amount of time (1 or 2 days), one can still make a decision. Requiring a ping by the OP will, imho, be ignored most of the time, and will not change the status quo (the edit-notice/warning being ignored, that is). Lectonar (talk) 11:49, 25 September 2023 (UTC)

Protected talkpages

Talk:2023 Israel–Hamas war has a bluelock, discreetly marked in the upper right corner. Would it be a good idea for visibility to make such talkpage locks bigger, with some explanatory text, or automatically add an explanatory banner to protected talkpages? Why, extent and length of protection, something like that. Gråbergs Gråa Sång (talk) 15:27, 3 November 2023 (UTC)

Use of a non-iconified template is already in the protection policy: In exceptional cases, if a page and its talk page are both protected, the talk page should direct affected editors to Wikipedia:Request for edit through the use of a non-iconified page protection template, to ensure that no editor is entirely prevented from contributing.

I updated the template on that particular talk page. Daniel Quinlan (talk) 02:57, 4 November 2023 (UTC)

General sanctions updates

Not filing a formal {{edit semi-protected}} since I'm not sure what the exact language should be, but at § As general sanction enforcement, the ECR imposed by WP:GS/KURD is missing and the note on the WP:GS/AA ECR should probably be updated to include its modification in September. 129.170.197.119 (talk) 09:17, 4 November 2023 (UTC)

Examples

I think it would be a good idea to put on examples of pages that have x lock TonyBaboony (talk) 17:12, 4 December 2023 (UTC)

See Wikipedia:Lists of protected pages linked at the very top of the page. Daniel Quinlan (talk) 21:30, 4 December 2023 (UTC)

I want to edit a few Wikipedia pages, but I don't want to be blocked from editing.

There are a few things that I would like to edit in Wikipedia, but I'm afraid if I'm going to be blocked from editing if I add any irrelevant or unnecessary information. Any registered user is capable to edit any page on Wikipedia and Fandom, whether they are a moderator or not. Why do moderators always get notified when someone edits an article in those websites? Do they need to make sure nothing prohibited is written anywhere? Lazar Alabic 2005 (talk) 18:52, 5 December 2023 (UTC)

Anyone is welcome to edit here, but Wikipedia has higher standards around requiring sources and citations, notability, and what is considered appropriate as an external link. This is the wrong place to ask about it, though. I've left some introductory links on your user talk page and I'd also recommend reading through the links I've left here. Daniel Quinlan (talk) 21:43, 5 December 2023 (UTC)

Add Templum Domini instead of "a church"

"turned it into a church" - please replace with "converted it into the Templum Domini. — Preceding unsigned comment added by 100.10.33.141 (talk) 13:00, 7 December 2023 (UTC)

Please post your message on the Talk page for the article in question. – Jonesey95 (talk) 17:24, 7 December 2023 (UTC)

Semi-protecting this page

IP edits on this page are almost always off-topic or disruptive, and it never seems to end. I tried reordering the warning headers and it has had no measurable effect. Multiple other Wikipedia talk pages with similar issues are also semi-protected, and it was time to do the same here. Rather than using progressively longer temporary semi-protections, I'm ignoring the rules and jumping straight to the almost inevitable conclusion: an indefinite semi-protection. Daniel Quinlan (talk) 00:35, 20 December 2023 (UTC)

Updates to WP:ECP section

In response to an edit request to add WP:GS/KURD to the list of ECR sanctions, I made some updates to WP:ECP. The listing of ECR sanctions has been out-of-date more often than not, we don't provide any other listing of protection-related sanctions on this page, and it seems like it is just creating unnecessary future maintenance work so I removed the list entirely. In its stead, I added some more information from WP:ARBECR and linked WP:GS for a more well-maintained list of active sanctions. I also reorganized the subsections based on usage frequency and made some general improvements to the section. Note that I did not make any changes to Wikipedia policy with these edits. Please let me know if you have any feedback or concerns about the edit. Thanks! Daniel Quinlan (talk) 22:56, 6 January 2024 (UTC)

I thought better of quoting from WP:ARBECR and replaced that with a brief overview that links the policy and a recommendation to read the policy before enforcing it. That's also more consistent with the rest of the policy (and every other policy). Daniel Quinlan (talk) 21:08, 7 January 2024 (UTC)

Removing lock color labels

@Redrose64: The edit needed an explanation, but referring to the various protection levels and types using colors is non-intuitive and poor design from an accessibility standpoint. I agree with the editor that removing the color labels is an improvement so I removed them from the icon table and elsewhere. The visual clue of the colors is helpful on articles and the icons are great, but the alt text for the icons is the protection level or type and not a visual description of the icon for a reason. Daniel Quinlan (talk) 23:29, 25 January 2024 (UTC)

The textual lock colours (Goldlock, etc.) were added by BWikiBW02 (talk · contribs) on 17 May 2021 (to Template:Padlock list, which was transcluded to Wikipedia:Protection policy at that time); you need admin rights to view its history. It doesn't seem to have been discussed at that time, nor indeed over the ensuing year during which Template:Padlock list remained substantially unchanged before being sent to TfD. Personally I think that they're harmless, even helpful.

The shortcuts (WP:GOLDLOCK, etc.) on the other hand are longstanding, having been added by Purplebackpack89 (talk · contribs) fourteen years ago. They should definitely be reinstated and not removed without consensus. --Redrose64 🌹 (talk) 15:04, 27 January 2024 (UTC)

The shortcuts still work. I simply want do discourage people from using the color code shortcuts because they are bad for accessibility and add an extra layer of jargon that is unhelpful when they are actually used on Wikipedia. Also, bear in mind the WP:LINKBOXES guideline that they generally should list only the most common and easily remembered redirects.

I'll restore the shortcuts for the time being since there is disagreement, but I'll pose the question about whether they should be removed below. Daniel Quinlan (talk) 00:17, 28 January 2024 (UTC)

The color labels should be retained. I disagree with Daniel Q's removal of them. RedRose has a point that this is a longstanding listing. pbp 15:28, 27 January 2024 (UTC)

The shortcut names, and thus the labels of the shortcuts, should be maintained - as they are used. — xaosflux ^Talk 00:21, 28 January 2024 (UTC)

 Question: Should the color code shortcuts be removed from the shortcut boxes in order to discourage their future use? (Redirects will be maintained for backward compatibility, of course.) Daniel Quinlan (talk) 00:25, 28 January 2024 (UTC)

Reviewing the entire WP:RFPPI archive from 2023, the color-code shortcuts were used 12 times over the course of the entire year. That isn't exactly common usage given there were ~16,000 page protection requests last year. Daniel Quinlan (talk) 03:49, 28 January 2024 (UTC)

Support removing them to discourage use. I've actually considered taking at least some of these to Redirects for discussion in the past.

According to Wikipedia:Manual of Style/Accessibility#Color we should Ensure that color is not the only method used to communicate important information. One of the reasons for the widely supported 2018 redesign of the padlock icons was to add symbols and ensure they were not solely distinguished by colour. Here is a great simulation of what the locks look like for the large number of people with red-green colour blindness. Can you tell me what "GREENLOCK" refers to there?

Additionally there isn't any meaning to the colour choices (with the exception of gold and silver). Without looking, does anyone actually know what a turquoise lock means? Is WP:TURQUOISELOCK a helpful shortcut when we have WP:CASCADE? the wub "?!" 23:36, 28 January 2024 (UTC)

TFA protection

I just semi-protected the current featured article following a request by A smart kitten at page protection permalink. Apparently the bot that would normally do that is not working at the moment. The discussion to semi-protect the current TFA is archived here. The August 2023 close by CaptainEek includes "There is overwhelming consensus to semi-protect each TFA from the day before it is on the main page and through the day after." Does that wording mean a TFA should be semi-protected for 72 hours (24 hours before, during and after)? If so, Wikipedia:Protection policy#Preemptive protection should be updated with more detail, perhaps in a footnote and including a link to the RfC. Johnuniq (talk) 02:22, 5 February 2024 (UTC)

Courtesy ping: Legoktm as botop for TFA Protector Bot. Best, ‍—‍a smart kitten_[meow] 02:29, 5 February 2024 (UTC)

I added some detail to the protection policy. Firefangledfeathers (talk / contribs) 02:41, 5 February 2024 (UTC)

@Johnuniq Yes, 72 hours was the consensus chosen there. CaptainEek ^{Edits Ho Cap'n!}⚓ 17:29, 5 February 2024 (UTC)

Long term semi of article talk?

WP:ATPROT does say that Talk pages are not usually protected, and are semi-protected only for a limited duration in the most severe cases of disruption. Are there cases outside of WP:CTOP where long term protection for an article talkpage would be within policy without the need for a larger discussion/RfC?

My specific example is Talk:Hacker. I can count on one hand the number of productive edits from IPs over the last few years, and there's a persistent problem with IPs either trying to hire computer hackers, advertising their own hacking services, or just random vandalism. Of the 477 total edits to the talkpage, 256 were either reverted edits or automated/semiautomated reverts of those edits. That's about 54% of the edits since the page was created in 2008, and the ratio is getting significantly worse over the last few years. I also went back and checked out the last 100 edits to the page (going back to April 2023), and only 3 were productive edits about the page itself for a whopping 97% vandalism/reversion rate.

I know semiprotection for article talkpages is frowned upon even short term, but it seems like there are some edge cases where it could be appropriate. The Wordsmith^{Talk to me} 18:53, 8 February 2024 (UTC)

I don't think you'll find anyone (other than the IPs) complaining about long-term semiprot for pages like this. Primefac (talk) 19:00, 8 February 2024 (UTC)

I agree, but the wording of the policy made me hesitate and discuss here first. Maybe it's worth adding a line to that section? Something like In rare cases where most non-autoconfirmed edits over an extended period are disruptive, long term semiprotection may be used. The Wordsmith^{Talk to me} 19:20, 8 February 2024 (UTC)

I was just thinking IAR until someone say something. Primefac (talk) 19:44, 8 February 2024 (UTC)

Trying a long, but limited, duration (like one or two years) first is often a good idea assuming shorter protections have been ineffective, but I agree with Primefac about IAR. I don't think we need to change that part of the policy at this point, but if we were to change it, I don't think it needs to be that wordy.

If you decide to go ahead, in some cases where this has been done, I've seen the protection log refer people to the Teahouse like this. Daniel Quinlan (talk) 20:59, 8 February 2024 (UTC)

File mover / Page mover

@Daniel Quinlan: Re Special:Diff/1210478149, they're not quite the same: to move a file you need to be an admin or file mover, to move a category you need to be an admin or page mover. -- John of Reading (talk) 07:47, 27 February 2024 (UTC)

Thanks. Without it being linked, I didn't see it being a different term. Fixed. Daniel Quinlan (talk) 13:56, 27 February 2024 (UTC)

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)

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)

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)

I was thinking in particular of protection is used when vandalism, disruption, or abuse is occurring by multiple users and at a level of frequency that requires its use in order to stop it – at the end it refers to two different things, and for whatever reason I lacked the enegry to untangle that (probably because this is a policy so I didn't want to do anything that shaded the meaning even slightly differently. There was some other stuff as well that's gone now. EEng 02:52, 13 May 2024 (UTC)

You have a point. We could replaces requires its use in order to stop it with warrants intervention. I would also suggest removing level of which is unnecessary. The result would be Instead, protection is used when vandalism, disruption, or abuse is occurring by multiple users and at a frequency that warrants intervention. Daniel Quinlan (talk) 03:07, 13 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)

@Johnuniq: @Firefangledfeathers: Thanks. I went ahead and made the changes. I ended up merging the create protection sentence with another sentence to avoid some redundancy. I also added a short sentence about semi-move protection not having any effect, based on a similar sentence from the create protection section. Please let me know if you have any concerns. Daniel Quinlan (talk) 01:37, 13 May 2024 (UTC)

"Full protection" listed at Redirects for discussion

The redirect Full protection has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 May 24 § Full protection until a consensus is reached. Mia Mahey (talk) 04:55, 24 May 2024 (UTC)

"Semi-Protection" listed at Redirects for discussion

The redirect Semi-Protection has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 May 24 § Semi-Protection until a consensus is reached. Mia Mahey (talk) 18:52, 24 May 2024 (UTC)

"Wikipedia:PDP" listed at Redirects for discussion

The redirect Wikipedia:PDP has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 July 6 § Wikipedia:PDP until a consensus is reached. — AP 499D25 (talk) 05:52, 6 July 2024 (UTC)

Bot proposal

This may be of interest to watchers of this page: Wikipedia:Village pump (proposals) § Bot to restore long-term protections after shorter-term higher protections expire. Please post any comments or feedback there. Regards. Daniel Quinlan (talk) 02:49, 24 July 2024 (UTC)

Policy should define "inactive" administrator

WP:UNPROTPOL doesn't define what "inactive" means here: Editors desiring the unprotection of a page should, in the first instance, ask the administrator who applied the protection unless the administrator is inactive or no longer an administrator; thereafter, requests can be made at Requests for unprotection. To provide more clarity and less room for personal interpretation and disagreements on WP:RFUP, I suggest that we add a simple definition for this section that users can easily interpret such as no edits within the last 30 days. Daniel Quinlan (talk) 21:31, 16 July 2024 (UTC)

How about just link to active users list for who is active? — xaosflux ^Talk 22:27, 16 July 2024 (UTC)

That's an interesting idea, but that would rule out administrators who are available, but not performing actions in the last 30 days. That would even include administrators participating in administration-related activities, but only via edits. It seems like the intent of excluding inactive administrators is to make sure the process is not delayed due to the unavailability of the protecting administrator which is why recent edits seemed like a good approach. It's pretty hard to have a significant number of actions without making any edits. Daniel Quinlan (talk) 22:57, 16 July 2024 (UTC)

Wikipedia:List of administrators/Inactive is an option. After all, all the policy requires is that users ask first. Now that we are more aggressive about desysopping inactive administrators, it makes sense to favor asking in borderline situations. Daniel Quinlan (talk) 23:53, 16 July 2024 (UTC)

Honestly, not a bad idea...but become an active administrator again? Frozen902 (talk) 19:59, 23 July 2024 (UTC)

but how do you become an active administrator again Frozen902 (talk) 20:00, 23 July 2024 (UTC)

@Frozen902: Carry out an action that non-admins cannot do - block/unblock, delete/restore, protect/unprot. --Redrose64 🌹 (talk) 20:48, 23 July 2024 (UTC)

Should the policy also specify the method of contact and how long users are expected to wait before making a request at WP:RFUP? Something like Editors desiring the unprotection of a page should first ask the administrator who applied the protection on the administrator's user talk page. If the administrator is inactive, no longer holds administrative rights, or has not responded within 1 week, then a request can be made at Requests for unprotection. would be clearer and also doesn't try to fit so much into a single sentence. Daniel Quinlan (talk) 00:17, 17 July 2024 (UTC)

@Daniel Quinlan I wonder how many people actually ask first or even read that. Doug Weller talk 20:23, 23 July 2024 (UTC)

@Doug Weller: I receive a fair number of unprotection requests on my user talk page so I think it might be higher than it sometimes seems. Also, the text could be clearer. Daniel Quinlan (talk) 20:58, 23 July 2024 (UTC)

@Daniel Quinlan Good to know. Not my experience, but then I'm not at all active at RPP so don't do a lot of protection. Doug Weller talk 07:45, 24 July 2024 (UTC)

Slightly revised to be a bit less wordy: Editors desiring the unprotection of a page should first ask the protecting administrator on their user talk page. If the administrator is inactive, no longer has administrative rights, or does not respond within a week, a request can be made at Requests for unprotection. I'd be fine changing "within a week" to something else if that seems too long or too specific. Daniel Quinlan (talk) 21:00, 23 July 2024 (UTC)

Personally, I think I would prefer being more explicit about the administrator's role, rather than using "protecting" to describe them. I suggest the following: Editors seeking to unprotect a page should first ask the administrator who protected the page, using the admin's user talk page. If the administrator is inactive, no longer has administrative rights, or does not respond within a week, then ask at Requests for unprotection. isaacl (talk) 21:19, 23 July 2024 (UTC)

Okay, I retained the more explicit phrasing and went ahead with the update. I also included a mention of reductions in protection level, but I left out the one week timeframe because there was limited discussion about that, and the main issue has always been users asking the protecting administrator first. The primary change is defining inactivity based on the list of inactive administrators. If anyone has any concerns, please let me know. Thanks. Daniel Quinlan (talk) 22:54, 23 July 2024 (UTC)

Clarification on pending changes vs. semi-protection

The pending changes review process states that The protection policy limits pending changes protection to clear-cut cases, so interpretation issues should be minimal. and guides reviewers to focus on obvious issues, but the protection policy was less than clear about this. Therefore, I made this change. I think that helps improve the guidance while also further explaining some protection decisions we're already making as administrators. If you have any questions or feedback, please let me know. Thanks! Daniel Quinlan (talk) 04:15, 31 July 2024 (UTC)

Position of lock

Could we revert to how the position of the "pending changes" lock looked before? Now it looks like this, with "Pending" wording next to it with a crossed out eye. The previous lock was a simple compact lock icon with a tick, did not include text or other additional features (like the crossed-out eye) and was less obtrusive and didn't draw as much attention. I'd like to restore the lock to its previous visual format whilst making sure users can still understand its meaning (that there are pending changes, which should already be handled by users pressing "Edit source" and the note coming up). Best, 750h+ 16:54, 15 September 2024 (UTC)

@750h+: I also dislike the change. It's too "busy", the eye icon seems out of place, and it's not visually pleasant. However, this is the wrong place for design feedback. I suggest you start at WP:VPT. Daniel Quinlan (talk) 22:49, 15 September 2024 (UTC)

Will move. 750h+ 23:24, 15 September 2024 (UTC)