Wikipedia talk:Protection policy

A few weeks ago I made an edit (Special:Diff/1334471711) that changed Note that such requests will normally be declined if the protecting administrator is active and was not consulted first. to Note that such requests may be declined if the protecting administrator is active and was not consulted first. ("such requests" referring to requests for unprotection). This was reverted by @Daniel Quinlan on the grounds that this is a change to policy and should be discussed. Here is that discussion.

This policy is attempting to describe common practice at RfPP, and failing miserably. Searching the RfPP archives of January and February 2026 for "Unprotected:" shows that not a single unprotection request was declined because the protecting admin had not been consulted, which the current wording portrays as the "normal" result. Many requests were granted despite no consultation taking place (perhaps even most requests – I didn't keep count). In some cases the protecting admin was pinged to offer an opinion, but ultimately the failure to consult them never seemed to affect the outcome of the request.

Policy should also follow common sense and WP:NOTBURO. The change I made still allows admins to decline solely for a failure to consult the protecting admin, but does not state the frequency of that decision. A failure to exactly follow the recommended procedure should not stand in the way of fulfilling reasonable requests. Toadspike [Talk] 19:28, 19 February 2026 (UTC)

I don't think the history shows what you're saying. In the vast majority of cases (46 out of 48 44 out of 46 (updated 11:41, 20 February 2026 (UTC)) requests in the sample I analyzed, see below), the protecting admin was no longer active, the (active) protecting administrator was pinged and responds, or the request is quickly declined making a ping superfluous. More importantly, the archives don't show the requests that never reach RFPP because the user followed the process and made a request to the protecting administrator.

The two cases in this sample where an unprotection was done without consulting an active protecting sysop were both pages that were unnecessarily fully protected over 15 years ago.

Finally, will normally be declined is not trying to describe the RFPP outcome in a vacuum. It sets an expectation: if you bypass an active protecting sysop, you should not expect success. That shapes behavior upstream and it's a fairly accurate prediction of the outcome. It also helps reduce the load on RFPP by allowing administrators with more context to quickly decline or accept requests on their user talk pages.

And it helps discourage administrator shopping and dubious requests. Daniel Quinlan (talk) 22:37, 19 February 2026 (UTC)

More information Article, Outcome ...

January 2026 requests^[1]

Article	Outcome	Protecting sysop status	Notes
Iron Man 2	Declined	Active	Declined outright
Love the Way You Lie (song)	Unprotected	No longer sysop
Garrulax milnei	Unprotected	Active	Fully protected redirect?
I Kissed a Girl (Katy Perry song)	Declined	Active	Edit made by sysop
Ronen Segev	Declined	N/A	Office action
Ronnie Segev	Declined	N/A	Office action
Template:Infobox ballet company	Unprotected	Active, but pinged	Unprotected by protecting sysop
Template:Infobox law school	Reduced	No longer sysop
Lamar Odom	Reduced	No longer sysop
Enes Kanter	Declined	Active	Declined outright
Template:Glottolog	Declined	Active, but pinged	Declined by protecting sysop
Ray William Johnson	Reduced	No longer sysop
Fuel Freedom International	Unprotected	No longer sysop
Staples High School	Unprotected	N/A	Failed previous unprotection
List of Canadian Hot 100 number-one singles of 2011	Unprotected	No longer sysop
Triple J Hottest 100, 2000	Unprotected	Active, but pinged	Okayed by protecting sysop
User:Mcjakeqcool	Unprotected	Active	Fully protected user page?
User:TheRescuers	Unprotected	No longer sysop
Anti-pedophile activism	Declined	Active	Declined outright
App Store (Apple)	Declined	Active	Declined outright
Atlanta	Declined	Active	Declined outright
Bob the Builder	Declined	Active	Declined outright
Caracalla	Declined	No longer sysop	Declined outright
Charli XCX	Declined	Active	Declined outright
Chitral	Declined	Active	Declined outright
Daniel Andrews	Declined	Active	Declined outright
East Spring Primary School	Unprotected	No longer sysop
Europe of Sovereign Nations Group	Declined	Active	Declined outright
Gagan Thapa	Declined	Active	Declined outright
Jordan Love	Declined	Active	Declined outright
Julia Domna	Declined	No longer sysop	Declined outright
Lady Gaga	Unprotected	Active, but pinged	Protecting sysop pinged and unprotected
Livonia, Michigan	Declined	Active	Declined for not contacting protecting administrator
Amanda Jiroux	Unprotected	No longer sysop
Matt Kalinski	Declined	No longer sysop	Declined outright
Opinion polling for the next United Kingdom general election	Declined	Active	Declined outright
Pete Hegseth	Declined	Active	Declined outright
Noodle	Declined	Active	Declined outright
Reindeer	Reduced	Ex-sysop, but pinged
Rihanna	Declined	No longer sysop	Declined outright
Killing of Renee Good	Declined	Active	Declined outright
Super Aids	Declined	Active	Declined outright
Talk:Killing of Renee Good	Declined	Active	Declined outright
Teacher's Pet (2004 film)	Declined	No longer sysop	Declined outright
The Guardian	Declined	Active	Declined outright (removed by sysop)
United States dollar	Declined	Active	Declined outright
Vairankode Vela	Declined	Active	Declined outright
Valy Hedjasi	Reduced	No longer sysop

Close

Daniel Quinlan (talk) 22:25, 19 February 2026 (UTC)

The status of the protecting admin is not "N/A" simply because the request was declined (and goodness that yellow is hard to see). All of those requests were declined for a good reason that had nothing to do with whether the protecting admin was consulted. This is good – it shows that requests are being considered on their merits regardless of whether consultation took place, a perfect application of WP:NOTBURO. Toadspike [Talk] 10:03, 20 February 2026 (UTC)

Sorry about that, I replaced the yellow and filled out the column. I also removed a few requests where the page wasn't protected.

Most of the time when an active protecting administrator isn't asked first, there's a decline for a multitude of reasons: it's more efficient to just decline a dubious request, reasonable requests are generally routed through user talk pages as per the policy, etc. Anyhow, for the 29 cases where the protecting administrator was still an active sysop:

• 23 were declined
• 3 had the protecting administrator pinged, and were unprotected
• 2 were unprotected
• 1 had the protecting administrator pinged, and was declined

That's about 83% being declined, which seems consistent with will normally be declined. The policy doesn't require a specific procedure for declining requests, it just informs users about the likely result. If there's a more straightforward reason to cite, administrators are free to use it. This part of the policy isn't bureaucratic. It's meant to encourage contacting the protecting administrator first because it's more efficient, prevents admin shopping, helps avoid conflicting administrator decisions without discussion, and reduces RFPP workload. Daniel Quinlan (talk) 11:41, 20 February 2026 (UTC)

Regardless of whether a protecting admin is active or still has admin rights, it baffles me how anybody at all willingly reduces indefinite semi-protection or ECP; doing that is asking for trouble to resume. To be blunt, such reductions are never a risk worth taking when such trouble is what led to such protections in the first place. Don't be surprised when pages that go through "trials" of pending changes or being completely unprotected quickly see upticks in bad edits. In my opinion, it would be best to only allow reduction requests from full-protection emerging from content disputes, and semi-protection or ECP can be resumed if they were already indefinite beforehand. SNUGGUMS (talk / edits) 22:44, 20 February 2026 (UTC)

Some protections outlive the reason for their protection. As the blocking policy says, Indefinite does not mean "infinite" or "permanent"; it just means that no automatic expiration time (or duration) for the block has been set. The same should be true for protections. Daniel Quinlan (talk) 23:20, 20 February 2026 (UTC)

Not sure how comparable the blocking policy is, but I've never seen anything good come from reducing indefinite semi-protection or ECP. Lifting those comes off as reckless. When somebody decides to temporarily lift those as a trial, it becomes a magnet for disruption (sometimes including vandalism) to return, and there unsurprisingly have been many cases of such trials being short-lived due to lots of bad edits being made before protection gets restored. We could've avoided lots of needless trouble for articles by never reducing these protections once they're made indefinite. SNUGGUMS (talk / edits) 03:31, 21 February 2026 (UTC)

Was looking at the edit history for PeterSymond's user page and saw a protection level I never saw before: require CheckUser access. (see Special:PermaLink/320405065) Thoughts? - SimpleObjects-9ei (talk) 00:01, 3 March 2026 (UTC)

That wasn't a protection; it was an ordinary edit adding an empty line with a deceptive edit summary. Diff, Logs for that page, surrounding protection log entries. —Cryptic 00:59, 3 March 2026 (UTC)

I am likely sure about that, as before somewhere in the late 2000s protecting a page would show this text inside the edit summary:

[edit=<protection level, autoconfirmed or sysop>] [move=<protection level, autoconfirmed or sysop>]

However, somewhere in the early 2010s, it was changed to include this:

[edit=<protection level, autoconfirmed or sysop>] (<duration>) [move=<protection level, autoconfirmed or sysop>] (<duration>)

And as of today, this is what it looks like:

[Edit=<protection level; Require autoconfirmed or confirmed access, Require extended confirmed access, Require template editor access, or Require administrator access>] (<duration>) [Move=<protection level; Require autoconfirmed or confirmed access, Require extended confirmed access, Require template editor access, or Require administrator access>] (<duration>)

This is weird because at the time this page was protected, CheckUser protection wasn't mentioned in the protection policy page. I have actually burrowed through protection history before, but I wasn't expecting to see a protection level this weird. The reason of protection was reasonable (likely Grawp vandalism, but this was after the Willy on Wheels vandalism trend ended), but when protecting a page, you have to specify why you protected it. Example:

...23,456 bytes) . . Protected "Example": Your reason of protection. ([Edit=Require autoconfirmed or c...

Oh, and can't we forget the fact that this was before Twinkle became popular? PeterSymonds didn't use Twinkle to protect the page, and the [edit=autoconfirmed/sysop] summary is true (see the page information for Haggar Clothing, whose protection summary is the 2009-style one and is still labeled "Require administrator access (no expiry set)") Yet most admins use Twinkle to protect pages nowadays.

Also, to show I'm not cuckoo crazy, check the protection log for this page. See? It is protec- oh no. So maybe I was actually lying and CheckUser protection was just a nightmare I had in my head. However, I still hope you learned a valuable lesson. - SimpleObjects-9ei (talk) 01:48, 3 March 2026 (UTC)

A lesson for whom? When somebody makes an edit that alters the page text in any way - such as by adding a newline - the edit summary is free-form, it allows absolutely any text to be entered. Even something that looks like the contents of a log entry. You could use an edit summary like protected [[Wikipedia talk:Protection policy]] [Edit=Require SimpleObjects-9ei access] (expires 08:52, 3 June 2026) and it would be accepted by the MediaWiki software. But the page protection wouldn't be altered one bit. --Redrose64 🌹 (talk) 08:52, 3 March 2026 (UTC)

I don't think that a post-201X protection summary like:

...protected "Wikipedia talk:Protection policy": [Edit=Require SimpleObjects-9ei access] (expires 08:52, 3 June 2026) [M...

may as well be considered that. There are currently 5 levels of protection: pending changes protection (for uncommonly vandalized pages), semi-protection (the most common one; for vandalized pages by unregistered and new accounts), extended confirmed protection (for contentious topics and vandalized pages by (auto)confirmed accounts), template editor protection (for high-risk templates) and full protection (for edit warring/content disputes and vandalized pages from extended confirmed accounts).

You can as well put SimpleObjects-9ei protection level like if it was invented from nowhere, then log in to a temporary account (IP address prior to 4 November 2025) to see that the "Edit" button is not the "View source" button. This may be considered some sort of joke thing, however Wikipedia does not allow empty changes. The only way you can make the "(No difference)" message appear when switching revisions is by moving a page or protecting a page, not by typing an edit summary, editing nothing and pressing Publish changes.

So technically you can still edit pages even if the fake protection summary literally says "Require oversighter access". I was not around in 2009 so I couldn't check if the CheckUser protection evidence was true. - SimpleObjects-9ei (talk) 19:33, 3 March 2026 (UTC)

Please note that (a) the diff in question shows a newline being added - something that cannot happen when a loggable action occurs; and (b) I wrote an edit that alters the page text in any way - such as by adding a newline. It was, quite simply, a user-entered edit summary that was written to have the appearance of a log entry. Exactly like this. --Redrose64 🌹 (talk) 22:43, 3 March 2026 (UTC)

Ooh... So you mean a protection example like this? Okay, now I get it. However, the edit has a zero-byte difference, and it is truly impossible to get a zero-byte difference, huh? Because when admins protect the page using Twinkle, there is a literal zero-byte difference. Even still, before Twinkle existed, when protecting a page also a zero-byte difference because clearly the protection button is from the Tools dropdown button. Another cool example of a zero-byte difference is this, despite the fact the edit summary is suppressed. - SimpleObjects-9ei (talk) 23:15, 3 March 2026 (UTC)

However, the edit has a zero-byte difference - it's not a zero-byte difference, the [https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=history page history shows "(+1)". --Redrose64 🌹 (talk) 23:21, 3 March 2026 (UTC)

Zero byte edits used to be possible (I won't tell you how). I think it changed in the last few years. These types of edit summaries have been used a number of times for comedic effect. -- zzuuzz ^(talk) 23:32, 3 March 2026 (UTC)

BTW I think one of the earliest examples was this. Also that second example you provide was the result of a page move, per the log. -- zzuuzz ^(talk) 00:13, 4 March 2026 (UTC)

My goodness, I would have never known that since I am not extended confirmed and didn't sign the Wikimedia Foundation's confidentiality agreement for nonpublic information, which means I'm not an oversighter, but may want to be like one soon. Now, the second example I gave was several vandalism by BestToWaitSomeMore, which I didn't know was a page move since all log details have been suppressed.

Either thing or thing, it appears that the example you gave was an actual page move: despite the fact, this page was actually moved for real. I have actually burrowed through pagemove history before, such as (and please don't cancel me for saying it) massive use of a word during 2008, and in spaces because that's what the edit said: H A G G E R ?, Example on WHEELS!!! and a user trying to get extended confirmed rights by repeatedly typing 1 in their user talk page, and all to move the page Charlie Kirk.

Because this message is related to the CheckUser protection mystery, I have to not keep it off-topic. So maybe, the CheckUser evidence might be true. We will have to go back to 2009 if we want to see how CheckUser protection felt like. - SimpleObjects-9ei (talk) 01:09, 4 March 2026 (UTC)

User-right logs are not always on-wiki. The editor apparently was a CU in the past. . And I don't know if it is still the case, but my recollection is that there were indeed other types of protections. - jc37 13:16, 3 March 2026 (UTC)

As someone who has been active since there was only one protection level, I feel confident in saying that bureaucrat, checkuser, oversight, and steward protection levels have never existed. The closest you'll find was superprotect, which is mentioned overleaf. -- zzuuzz ^(talk) 01:19, 4 March 2026 (UTC)

I have to correct you for a moment, but steward isn't a user level in the English Wikipedia. Only Meta-Wiki has this feature. SimpleObjects-9ei (talk) 01:26, 4 March 2026 (UTC)

Enwiki stewards have existed (m:Special:Redirect/logid/18030), but I accept it's another example of things that don't exist. -- zzuuzz ^(talk) 01:37, 4 March 2026 (UTC)

The recent edit is a bit strong IMHO. First, the word "allowed" is not really suitable when talking about something which ultimately boils down to judgement. Editors are not allowed to abuse each other but a page should not be protected unless certain conditions apply. A minor point is that "be set to" is extraneous—the original wording was fine and less is more. The wording is tipping towards prohibiting protection unless a major attack is under way. That is not how things work at WP:RFPP where minor articles are routinely (and correctly) protected when only a small amount of disruption occurs, provided it is repeated. Good editors have to be supported and telling them to suck it up is not a good outcome. Protection is often needed simply to break some bored person's habit. Johnuniq (talk) 02:09, 5 March 2026 (UTC)

Agreed. It's effectively a policy change, but it's not well-formulated and it's unnecessarily wordy. Leading with not allowed is the least of the problems because the policy said that before. Worse is either currently in progress or currently ongoing and is occurring at a rate or frequency where page protection is clearly warranted. The currently in particular doesn't reflect how page protections are done or how durations are chosen. The previous text was better in every respect. Daniel Quinlan (talk) 17:04, 6 March 2026 (UTC)

Johnuniq, Daniel Quinlan - Thanks for discussing this, and I appreciate the input and the feedback! :-) In hindsight and after looking at it again, I completely understand your thoughts regarding the wording changes. The changes weren't meant at all to be any kind of "policy change" or anything that would restrict our ability to use judgment in order to gauge whether or not protection would be appropriate given... shenanigans. :-) My intent was to articulate how we make the determination as to whether or not to protect a page, and in a way that better describe the overall process? ...If that makes sense? An example being, either currently in progress or currently ongoing and is occurring at a rate or frequency where page protection is clearly warranted. The intent was to convey, "disruption is happening, lots of disruptive edits in a small time frame", like we see all the time where a page is getting hammered with 20+ disruptive edits over the span of an hour. Anyways, like I said - I completely understand your thoughts and how you interpreted the changes, and I thank you both for sharing them. ~Oshwah~^{(talk) (contribs)} 22:18, 9 March 2026 (UTC)

Oshwah, the phrasing of is occuring at a frequency that warrants protection does seem to be a bit circular. Would something like is occurring at a frequency significantly above typical address your concern without sounding like a policy change? Daniel Quinlan (talk) 01:17, 10 March 2026 (UTC)

Daniel Quinlan - That phrase looks good to me! :-) ~Oshwah~^{(talk) (contribs)} 01:29, 10 March 2026 (UTC)

I probably thought about this change much longer than warranted, but I ended up using mitigate persistent to replace the circular occurring at a frequency that warrants protection. Compared to my last suggestion, it's a bit less wordy, more to the point, and it includes the goal of mitigation. Daniel Quinlan (talk) 01:53, 16 March 2026 (UTC)

I think we ought to add a sentence to WP:ECP explaining the idea behind this, ie. that someone gains experience and proficiency in editing, which should discourage gaming. Idk which wording would be best though, and idk whether adding it to WP:XC would be better, depends which is linked to when a newbie tries to edit an ECPed page Kowal2701 (talk, contribs) 12:49, 12 March 2026 (UTC)

I don't think adding a sentence to state the obvious to either of those policies is going to discourage gaming. If there's any place to add a sentence, Template:Protected page text is more likely to be seen. Adding something along these lines might actually make gaming a more common response, though. Daniel Quinlan (talk) 02:07, 13 March 2026 (UTC)