This is an archive of past discussions about Wikipedia:Protection policy. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
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.
I propose we remove the Notification is to be posted in a subsection of AN for review, unless the topic is already authorized for 30/500 protection by the Arbitration Committee. requirement from ECP usage. The primary reason - it is not being done, and no one seems to care. There is a bot report that is transcluded to AN already (User:MusikBot/ECPMonitor/Report) and all of these protection actions are already clearly visible in the protection log. Any thoughts? — xaosfluxTalk19:05, 1 September 2016 (UTC)
Support - absolutely. The requirement is already discouraging even its appropriate use. If it's being automatically logged somewhere for statistical and tracking purposes, that should be more than enough. --Kudpung กุดผึ้ง (talk) 12:33, 2 September 2016 (UTC)
Comment I am not sure it can be amended by a vote here. The RFC to extend use of ECP specifically had options A, B, C to implement, of which C was the preferred choice which explicitly included the notification at AN. I dont think it can be amended by a local vote here, not without either notifying all the original participants who voted, or having an equally advertised RFC. Only in death does duty end (talk) 14:31, 2 September 2016 (UTC)
I've had people telling me I failed to notify when I used it, and getting annoyed I didn't, so what's clear to you may not be clear to others - David Gerard (talk) 19:32, 2 September 2016 (UTC)
The policy currently reads as prescriptive to me; and as far as bot reports go - a policy can not force anyone to make any edit - including the bot or its operator. I love the bot report and think that it should stay on AN. I'm also fine with changing this from part of the policy, to just an informative clause telling people reading about this policy that there is a bot report that is currently being maintained. — xaosfluxTalk21:00, 2 September 2016 (UTC)
Hmm, interesting. I didn't realize that people were getting annoyed. Yeah, I also would support adding an informative clause that explicitly confirms that the bot report is there to serve as the notification. If and when someone disagrees with an ECP application, they can create an individual AN section for it then. On a related matter, there were talks during WP:ECP2016 of doing some sort of mass message to all Wikipedia administrators clarifying the expectations for the use of ECP – would something like that be advisable to get everyone on the same page? Mz7 (talk) 23:21, 2 September 2016 (UTC)
I think we should send out a mass message sooner than later. I'm under the impression many admins aren't aware of ECP, some accidentally using it when they meant to use semi, and at least one that I talked to on IRC thought it was weaker than semi. We probably should wait till this discussion is closed, though, in the (hopefully) unlikely event we are forced to continue posting at AN — MusikAnimaltalk02:08, 3 September 2016 (UTC)
Support. Well, I didn't realize we were going to take that line so literally. You can count my vote as "option c, but without manual AN notification". NinjaRobotPirate (talk) 05:00, 4 September 2016 (UTC)
Support From the pre-RFC discussion that framed the question, I was the one that suggested that the manual notification be required. Subsequent discussion during the RFC brought about MusikAnimal's excellent idea of an automated bot script and figured that the wording at the close was clear enough that the bot notification was sufficient, so I definitely endorse the proposal to explicitly state that the bot notification is sufficient and that all admins be made aware. Blackmane (talk) 21:36, 14 September 2016 (UTC)
Support As I said in the RFC discussion, I think the bot notification is sufficient. Manual notification is redundant. Also, what Blackmane said. Katietalk21:58, 14 September 2016 (UTC)
Support clarifying this issue by specifically noting the bot satisfies this requirement. This was never a requirement in the first place. Consensus was that notification must be posted at AN, not that notification must be posted manually. Administrators would technically be on the hook if the bot malfunctioned, I suppose, but as far as I'm concerned the transclusion of the bot's table satisfies the existing requirement with no changes. ~ Rob13Talk17:22, 17 September 2016 (UTC)
Reluctant support: this is not what I envisaged when taking part in the RfC, but we might as well clean this up as a recognition of the facts on the ground. As long as the bot report remains in replace, I see no need at present for manual notification. BethNaught (talk) 17:46, 17 September 2016 (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.
Draft mass message to administrators
This is a very rough draft:
Hello, {{subst:BASEPAGENAME}}. This message is intended to notify administrators of important changes to the protection policy.
Extended confirmed protection (also known as "30/500 protection") is a new level of page protection that only allows edits from accounts at least 30 days old and with 500 edits. The automatically assigned "extended confirmed" user right was created for this purpose. The protection level was created following this community discussion with the primary intention of enforcing various arbitration remedies that prohibited editors under the "30 days/500 edits" threshold to edit certain topic areas.
In July and August 2016, a request for comment established consensus for community use of the new protection level. Administrators are authorized to apply extended confirmed protection to combat any form of disruption (e.g. vandalism, sock puppetry, edit warring, etc.) on any topic, subject to the following conditions:
Extended confirmed protection may only be used in cases where semi-protection has proven ineffective. It should not be used as a first resort.
Please review the protection policy carefully before using this new level of protection on pages. Thank you. This message was sent to the administrators' mass message list. To opt-out of future messages, please remove yourself from the list. ~~~~~
Comment: I think this is a bit premature. It assumes a consensus that hasn't been reached yet. I would prefer xaosflux to relaunch his original statement as a full blown RfC, because consensus can, and certainly does change. I'll repeat here for emphasis, that the bureaucracy surrounding this new protection level is so restrictive that I, and most likely other admins will prefer not to use it rather than be accused of abuse of it by those who take it upon themelves to watch over every single word and act our admins say and do. Kudpung กุดผึ้ง (talk) 07:06, 4 September 2016 (UTC).
I really don't care to write an entire RfC to discuss the 'mechanics' of bot-reporting vs editor reporting. This notice is not meant to go out until the issue above is addressed one way or the other. — xaosfluxTalk15:02, 5 September 2016 (UTC)
Made a few tweaks for readability, finalizing some text assuming the manual posting requirement will change as above, the timestamp will need to be a real one to mass message this out, added opt-out info. — xaosfluxTalk23:03, 15 September 2016 (UTC)
@Xaosflux: At this point, I would signal the green light for the mass message. There seems to be a consensus above that the bot report is sufficient as far as notification. Mz7 (talk) 22:52, 22 September 2016 (UTC)
Hello. You are invited to comment on this RfC regarding (1) the streamlining of the pending changes reviewing process and (2) the proposed protection of certain articles with Level 1 Pending Changes protection. Please do not comment here—your support or opposition to the proposals should be indicated in the relevant sections, and general discussion should be occur in the "General discussion" section at the bottom of the RfC page. Thank you. Biblio (talk) Reform project.21:14, 6 November 2016 (UTC)
There is. It, like all protection levels, can be found on a special page. A bot also notifies when ECP is used at AN. At one point in time this may have been useful. Now however, ECP is much more widely used and any list would be unruly and unnecessary to place on this particular page in my opinion. --Majora (talk) 00:37, 15 November 2016 (UTC)
The RfC discussion about level-2 Pending Changes is relisted. For those who did not participated yet, you may still have a chance to vote. Do it soon before closure. --George Ho (talk) 04:17, 15 December 2016 (UTC)
"Brief periods of full protection are used in rare cases when a large number of autoconfirmed accounts are used to make a sustained vandalism attack on an article." - Wait, what? I don't think this is up-to-date. The situation would call for Extended Confirmed protection to be considered, not full protection. May I update the wording in this section? Am I correct, or am I an idiot? or both? ~Oshwah~(talk)(contribs)06:01, 7 December 2016 (UTC)
As per WP:BOLD, which (cautiously) applies to policy pages as well, changing this to "large number of extendedconfirmed accounts are used to make a sustained vandalism attack" would be uncontroversial. You're correct that ECP would now be used before full protection for the described use case. ~ Rob13Talk06:04, 7 December 2016 (UTC)
I've reverted and tried a more mild change. The weakening of the language from essentially "Don't pre-emptively protect pages." to "It's discouraged." would need discussion, but I've changed the example to be accurate. ~ Rob13Talk06:34, 7 December 2016 (UTC)
BU Rob13 - It sounds like your primary reasons for reverting were the concerns over the use of the verb "discouraged" as well as the inclusion of the words "(and even controversial)" in the opening statement of my changes. I would like to update the section (with your changes in mind) to now state the following:
Applying page protection in a pre-emptive measure is contrary to the open nature of Wikipedia and is generally not allowed if applied for these reasons. However, brief periods of an appropriate and reasonable protection level are allowed in situations where blatant vandalism or disruption is occurring and at a level of frequency that requires its use in order to stop it. The duration of the protection should be set as short as possible, and the protection level should be set to the lowest restriction needed in order to stop the disruption.
The Arbitration Committee has resolved by motion that:
Remedy 2 (General Prohibition) is modified to read as follows:
All IP editors, accounts with fewer than 500 edits, and accounts with less than 30 days tenure are prohibited from editing any page that could be reasonably construed as being related to the Arab-Israeli conflict. This prohibition is preferably enforced by the use of extended confirmed protection, but where that is not feasible, it may also be enforced by reverts, page protections, blocks, the use of pending changes, and appropriate edit filters.
The sole exceptions to this prohibition are:
Editors who are not eligible to be extended-confirmed may use the Talk: namespace to post constructive comments and make edit requests related to articles within the topic area, provided they are not disruptive. Talk pages where disruption occurs may be managed by any of the above methods. This exception does not apply to other internal project discussions such as AfDs, WikiProjects, noticeboard discussions, etc.
Editors who are not eligible to be extended-confirmed may not create new articles, but administrators may exercise discretion when deciding how to enforce this remedy on article creations. Deletion of new articles by editors who do not meet the criteria is permitted but not required.
Pending-changes protection level 1 means edits by unregistered and new contributors are not visible to readers who are not logged in, until the edits are approved by a reviewer or administrator.
Pending-changes protection level 2 means edits by unregistered, new contributors, and autoconfirmed contributors are not visible to readers who are not administrator, until the edits are approved by a reviewer or administrator.
"Go live" means the changes become visible to readers who are not logged in to Wikipedia. In all cases throughout this table, changes are immediately visible to readers who are logged in.
and that notion of "going live" is explicitly invoked in the table's L2 entries. Clearly there's something wrong somewhere -- one place says unreviewed changes to L2 articles are visible to all logged-on readers, the other says they're visible only to admins.
There's also an internal contradiction in the phrase not visible to readers who are not administrator, until the edits are approved by a reviewer or administrator, since it implies that a reviewer who isn't an admin can't even see the changes -- how can a reviewer review what he's not allowed to see? EEng16:34, 7 January 2017 (UTC)
Thanks. I'm guessing the "not administrator" wording goes back to before there was such a thing as Pending Changes Reviewer. EEng05:42, 8 January 2017 (UTC)
It goes back to an addition from a not-very-experienced user.[3] I'm a bit bothered by the current wording as I think the default settings have changed, so logged-in users don't see the latest revision by default. All users can still see whether and which revisions are pending. -- zzuuzz(talk)05:49, 8 January 2017 (UTC)
Well, I've got a degree in computer science from a reasonably high-quality institution of higher education, and whenever I run into a page with one of these "pending"-type protections I have no idea what I'm looking at or which way is up, what with the Currently Accepted Version and blue tinting and whatnot. So if we could be sure this is all correct that'd be right grand. EEng06:02, 8 January 2017 (UTC)
@Xaosflux: The line at Wikipedia:High-risk templates "The most common reasons a template or module is considered high-risk are:... It is transcluded into a very large number of pages" brought me here :P I have ran into a couple templates which I feel were borderline usage/disruption and could benefit from higher protection (I didn't keep a list) but I resumed the search today because of {{Star Trek}} which has 11,00+ transclusions, I was going to list it at WP:RFPP but wasn't sure of the prerequisites. Lately the template has been getting more changes due to new stuff coming out, maybe dealing with edit requests would be better. - Mlpearc (open channel)19:58, 28 November 2016 (UTC)
Personally, I don't think {{Star Trek}} warrants currently increasing the projection level - 1000 pages is a bunch, but it's not that many - also this is a bottom-of-the-page nav template, and it is a "simple" template - easy to edit and revert. — xaosfluxTalk20:08, 28 November 2016 (UTC)
I agree--there should be a better understanding of what constitutes a high-use template. I have previously opined on the subject but would need to dig a bit to see where and what it was I said. --Izno (talk) 20:09, 28 November 2016 (UTC)
It's not as simple as a transclusion count. If a template has 50 tranclusions, but the transclusions are on pages like Hillary Clinton and Donald Trump which have been subject to vandalism via templates, that's high-risk. If a template has 1,000 transclusions on low-traffic stubs only, that's not high-risk (at least not to the level of requiring TE; semi would be fine). ~ Rob13Talk07:57, 30 November 2016 (UTC)
It also depends on the editing rate. Some templates are maintained almost exclusively by IP editors (sports templates for example). Then there's templates like {{bio-stub}} which don't need to be edited much. That template is currently fully (template-) protected with only 138 transclusions, but with a high turnover rate and the potential for BLP damage. I would say, however, that previous talk has suggested that any template with over 10,000 transclusions normally needs at least some protection. Anything over 50,000 transclusions will normally get a higher level of protection. Also any previous attempts to define a hard limit for protection have failed. -- zzuuzz(talk)09:34, 30 November 2016 (UTC)
50,000 is quite a bit higher than the standard I've seen used. I typically use the rule of thumb that anything over 10,000 should be template protected (unless, perhaps, none of the transclusions are in the mainspace or article talk pages). This is why there's been no easy consensus on what protection levels to apply, though. Everyone has different ideas of what high-risk means. As an aside, more complicated syntax also implies a higher level of protection should be used, since even good-faith editors can screw up a very complicated template. I would consider a complicated Lua module used on ~1,000 medium-traffic mainspace pages to be high-risk for this reason. ~ Rob13Talk10:53, 30 November 2016 (UTC)
An all too common scenario: A page that semi-protected suffers an edit war from confirmed users, then we have to fully or extended-confirmed protect for say, 2 days. The two days go by and now everyone can edit it, leading to significant disruption that led to it being semi'd in the first place. The issue is admins have to remember to restore the old semi, or users can re-request it at RFPP. How about we take out the busy work and let an admin bot do it? Can we envision a scenario where you wouldn't want this behaviour? To be clear, this is in regards to restoring older, lower-level protections, and to the expiry that they were originally set. So the same behaviour would apply if I fully protected a EC-protected a page, then full protection expired, and ECP would be restored as it was, etc. I believe this idea has been discussed before but I don't recall the outcome. Pinging recent RFPP admins @Samsara, Ad Orientem, Samwalton9, Ymblanter, Vanamonde93, Widr, CambridgeBayWeather, and Gfoley4:— MusikAnimaltalk07:47, 4 January 2017 (UTC)
If this is possible at the level of a bot or, even better, at the level of Mediawiki, this absolutely must be done.--Ymblanter (talk) 07:55, 4 January 2017 (UTC)
My exact same thoughts - should be a mediawiki feature, massive oversight that it doesn't work this way already imo. Given this opportunity, I would like to raise the issue of graceful degradation of protection. It's becoming increasingly common to use a period of PC1 following semi. While I don't consider that particular case mandatory (PC1 should be used on low traffic pages only, for good reason), I wonder if it makes sense for higher levels of protection - in particular, ECP being followed by a "grace period" of semi. Samsara08:23, 4 January 2017 (UTC)
Wow, wasn't even aware that this did not automatically take place. I'm in complete agreement: if this can be done by a bot, let's get it done by a bot. Regards, Vanamonde (talk) 09:38, 4 January 2017 (UTC)
Same here, this makes obvious sense and while it should probably be part of the software, if a bot is easier then I don't see a problem with that. Sam Walton (talk) 10:55, 4 January 2017 (UTC)
@Xaosflux: That's it! So I've actually talked to WMDE about it and it's sort of stalled right now, as they are trying iron out some details. For instance, what if a page was semi'd indefinitely, then an edit war took place so you add ECP protection for a week, then edit warring STILL happens so you fully protect for 3 days. What happens when full protection ends? Does it go back to whatever has the soonest expiry (ECP in this case)? Or does it always go back to semi? I'd personally would go with the former, so whatever the previous protection was, assuming it hasn't expired yet. Either way I'm very interested in pursuing a bot task, which would hold us off until a core solution has been implemented — MusikAnimaltalk18:31, 4 January 2017 (UTC)
MusikAnimal I'm not super excited about this being a protection-bot type of activity when it could be in core; 2 possible workflows would be:
Allow applying multiple protection types with related expiration - and AND them when checking if someone has edit permission.
Add a "When expires DO" workflow so you can specify what to do when a protection expires (default being do nothing)
If this was going to be somehow bot driven, how do you expect the bot to know when it should or shouldn't operate? — xaosfluxTalk18:56, 4 January 2017 (UTC)
My thing was wondering when a core solution would happen (tentatively Q1), and also I just really enjoy writing bot tasks :) There is no harm in waiting for a core solution. For us however it seems rather straightforward, per the above comments, that we just want it to fall back to the previous protection level, assuming it hadn't expired yet. Now that I think of it though, you'd have to somehow account for accidents. So if a page is indef semi'd, then I added indef ECP by accident, then I change it full protection for 2 days (what I wanted), it expires, now it goes back to ECP and not semi. So maybe a bot isn't the best idea :/ Daniel's comment on the phab task seems to line up with your thoughts. We should feel free to comment there, they said any input we have is very much appreciated — MusikAnimaltalk19:33, 4 January 2017 (UTC)
@MusikAnimal: What if you create the bot and just mass-message admins to inform them that in case of mistakes, they must first revert to the previous state - problem solved? Samsara05:08, 17 January 2017 (UTC)
@MusikAnimal: Or even better, when the bot changes a protection level, log it on a wikipage and use notifications to alert the protecting admins or admins, ie
* [[PAGE]] – Restored OLDPROTECTIONTYPE protection (expires DATESTAMP) after HIGHERPROTECTIONTYPE protection expired. {{ping|ADMIN1|ADMIN2}} please review and adjust if necessary. ~~~~
where ADMIN1 and ADMIN2 (if different) were the protecting admins for OLDPROTECTIONTYPE and HIGHERPROTECTIONTYPE. That way if the wrong protection type is restored, like ECP instead of Semi, the protecting admin will be notified and be able to fix it. And if there's no problem, then its just a little notification that can be dismissed. - Evad37[talk]03:04, 24 January 2017 (UTC)
Yeah I've thought about a ping system before for other bot tasks, and always ended up deciding against. It's a bit messy and hacky to say the least. For now, I think we should first find out if a core solution is on the horizon. I will speak with WMDE about it and if it sounds like things are questionable, I'll revisit the idea of a bot task — MusikAnimaltalk16:59, 24 January 2017 (UTC)
The 'extendedconfirmed' user access level is automatically granted to registered editors who make an edit after having 30 days tenure and at least 500 edits. This user access right allows editors to edit pages with extended confirmed protection. [...]
See Special:ListUsers/extendedconfirmed for a list of the 72569 extended confirmed users.
OK, for those of you who know Boolean logic, that means that the registered editors who are NOT granted the 'extendedconfirmed' user access level, are the ones who
(a) have less than 30 days tenure, OR (b) have made less than 500 edits.
(right? "OR", not "AND"...!).
For the TL;DR version (Warning!: might be "TMI" for the faint of heart!) [feel free to] "see also" De_Morgan's_laws.
"[...] any registered user with less than 30 days' tenure and fewer than 500 edits."
(see? "and", not "or"; ... while, IMHO, it should be"or"!).
IMHO, either these two pages are disagreeing with each other (that would not be my guess for "most likely") OR ... one of them is wrong.
I think the second one ("mentioned" above) is wrong.
I think the second one should say,
"[...] any registered user with less than 30 days' tenure OR fewer than 500 edits."
(Well, maybe without the bold font and the capital letters, for the word "OR"... I just did that in order to to highlight -- for your convenience! -- the one and only word, there, that (IMHO) might be the one to change.)
I would have just gone ahead [boldly] and made that edit (my UserID is shown on this [small part of, the big entire] list of 'extendedconfirmed' users); but ... I thought it might be better to check here, first. (right?)
Any comments?
PS: If there are no comments after a few days, then does that mean that I should go ahead with my proposed "edit"? (Any advice would be appreciated.)
Wonderful! Thanks to the first reply-er, who answered my question; and thanks to the second reply-er, who saved me some time by doing THIS edit ["for" me] ... and replied here. Now this matter is all
Anybody know where to get a tally of the types of each protection? Special:Protectedpages only gives an incremental list of titles, but no total count. I suspect, that if ECP has not yet overtaken full, then it soon will, and we should probably edit the lead accordingly. TimothyJosephWood17:55, 17 February 2017 (UTC)
I've never been keen on the pink padlock. Since 2015 the red padlock has been unused and I suggest to use this color for template protection. Any opinions please? — Martin (MSGJ · talk) 08:10, 13 November 2016 (UTC)
If you haven't gotten any opposes by now just change it. Be bold and all that. I doubt many people would even notice. --Majora (talk) 22:55, 6 December 2016 (UTC)
I don't agree. I think we should keep the padlock colours consistent over time. I think in particular that changing to a padlock formerly used to a different purpose could be confusing, especially for returning users, and since the red padlock disappeared relatively quietly. I suspect many people would look at it and think "why did all these template protected templates suddenly get permanently protected!?" Or maybe that's just me. BethNaught (talk) 23:10, 6 December 2016 (UTC)
How prevalent were the red locks to begin with? The only place I could ever remember seeing one was at WP:CASC (which is still there by the way). If they were only used in a few places I doubt anyone would really mind all that much. And if they do the locks are all link enabled (or at least should be). So what it means is only a click away. --Majora (talk) 23:19, 6 December 2016 (UTC)
@BethNaught and Majora: I've just just retrieved this from the archive because I forgot about it. Mt main rationale for changing is that we would never have chosen pink if red had been available. (I think the red padlock has been gone long enough that I don't think anyone will be thinking it means permanent protection.) — Martin (MSGJ · talk) 12:43, 21 February 2017 (UTC)
Thanks for the ping. I still don't agree, for the same reasons, and also because this doesn't solve an actual problem as far as I can see. We would never have chosen pink if red had been available—well, we did choose pink and that's how it's been for a long time. Also, {{citation needed}}. Moreover I think the red is unnecessarily scary and forbidding looking—even the full protection padlock isn't like that. BethNaught (talk) 13:23, 21 February 2017 (UTC)
Hi everyone! Thanks to everyone (MSGJ, Majora, BethNaught, and Evad37) for all the great work! I have a few opinions about this topic:
I agree with BethNaught that using the red lock could potentionally lead to confusion with the old usage of the red lock. However, I am not adverse to the color changing to something that has never been used before.
If a new color is being considered, I personally like this one:
And, unrelated to the main discussion (though related to an earlier comment in this discussion by MSGJ): MSGJ, I think that using a gold lock for cascade protection might confict with full protection, since WP:GOLDLOCK goes to full protection, but would equally apply to anything else with a gold lock. I think another color, which does not share a shortcut with anything, would be beter. For example, this one could be used:
Just for the new players, is there a reason why articles put under indefinite protection don't get the padlock added to them automatically? Is there anything wrong with going through and adding the templates onto articles with indefinite protection? Then same again with those under temporary?
Pretty much every one of El_C's. So there wouldn't be any harm in adding the template to pages that have been placed under a given level of protection? Just find it odd it's a fairly consistant thing. 203.6.77.2 (talk) 00:19, 17 March 2017 (UTC)
@El C: I think the IP is asking is there any reason why you're not adding the padlock icon to articles you're protecting. Also, IP, displaying the appropriate padlock icon automatically seems like a good idea to me. Anyone know why it isn't done? It would require a purge of the page when protection is added. --NeilNtalk to me17:03, 25 March 2017 (UTC)
When a revision is pending, it displays a mark [pending revisions], and on top of the page it has a blue box telling that something is pending. But nowhere it seems to link to policy/explanation what this actually means. Could we add a link to for example this policy section or elsewhere with a good explanation? It took me several searches to find this page... Thanks! effeietsanders16:17, 25 March 2017 (UTC) P.S. if this is the wrong place to ask, feel free to move/copy it.
Right now, a substantial amount of files are edit protected. With some exceptions, almost all of these seem to only merit upload+move protection as they are highly visible files in one way or another, and no edit protection.
I was thinking of performing a mass de-protection, with each file (save for those whose filepage should not be edited) being reduced to move+upload prot and I'd like to ask if there is any support/concern/opposition.
(There are some files which are cascade protected and can't be edited even when deprotected. There is a request in Phabricator to change cascade protection so that it only applies to filemoves and uploads, however, so the local edit protections could be lifted there as well)
I am going to put in an objection if (relatively large if) this request is doing what I think it is doing. I took a look in the category linked above, and I found images that would cause problematic amounts of disruption if they were to be vandalized. These files often have thousands or tens of thousands of transclusions, and are used in high risk templates. Therefore, I have to object to any kind of mass unprotection, and ask that any unprotections of images follow roughly the consensus for high risk templates, due to the risk of widespread vandalism occurring from a single edit. Tazerdadog (talk) 17:58, 12 March 2017 (UTC)
@Tazerdadog and Mlpearc: The idea I had is to lift edit protections while leaving upload and move protections in place, sorry if I was not clear about this. Changes to the filepage don't propagate to other articles so the filepage unlike the file itself is not a high risk page. Incidentally, File:Tango jpgordon.jpg appears to be @Jpgordon:'s personal file so I am not touching it. Jo-Jo Eumerus (talk, contributions) 19:13, 12 March 2017 (UTC)
1) Is there a way to break the attribution required by our license on any of these files? My guess is no, because the history is not alterable, but a single edit resulting in hundreds of thousand or millions of license violations is unacceptable even if reverted quickly (If such a breaking is possible, there is no need to elaborate on how (WP:BEANS)).
2) How many fully protected edit requests have been approved to tweak the documentation on a fully protected file in recent memory? If the answer is none, or only a handful, is this a solution looking for a problem?
3) Some of these files are fully protected in multiple ways (on the file page itself, and by putting them into a cascade-protected lockbox) so that a single admin oops is unlikely to expose the project to an attack. I'd like to see this redundant protection remain on files with hundreds of thousands to millions of transclusions. Changing the protection to move/upload from full doesn't affect this, but should be kept in mind. Tazerdadog (talk) 19:38, 12 March 2017 (UTC)
(edit conflict) I don't have a problem with reducing the protection on these pages directly. Just wanted to note that a lot of these images are probably cascade protected elsewhere anyways. Quite a few of them are listed in various places like WP:CASC. So reducing the protection on those pages directly won't actually do anything. --Majora (talk) 19:41, 12 March 2017 (UTC)
@Majora: There is a task somewhere in Phabricator that asks that cascade protection of files apply solely a move+upload protection; if it gets implemented the removal of edit protection would do something. @Tazerdadog: In order #1: The upload history is technically displayed on the filepage and can't be altered except by revision deletion, if that is the attribution you mean. #2: Such requests are sporadic, say one per month or less. That does not count any edits that weren't done because the user who wanted to edit did not find their way to the talk page. #3: I am only proposing to remove the per-file protection (with the caveat about that Phab task); adding or removing files to cascade protection is something that I don't plan to change. Jo-Jo Eumerus (talk, contributions) 19:47, 12 March 2017 (UTC)
Would that Phab task change them all at the coding level? By that I mean, would you then have to go and change the protection scheme on the various CASC pages (and just from a cursory overview there are a lot of them)? Or would it be a "if title is in namespace 6 only apply move+upload protection regardless of what the CASC page is set at"? --Majora (talk) 19:54, 12 March 2017 (UTC)
@Jo-Jo Eumerus: Ok, it sounds like this is unlikely to be a problem, although I'm not sure it is strictly necessary. I will encourage caution, as mistakes in this area can become bad quickly, but I do not see any major roadblocks for this change. Cheers, Tazerdadog (talk) 20:09, 12 March 2017 (UTC)
So it would work like option b (move+upload only regardless of CASC settings). That works with me. Like I said, I don't have a problem with the reduction of individual page settings. Just thought I would point out the CASC issue. Seeing as there is already a task to address that I don't have any problems. --Majora (talk) 20:18, 12 March 2017 (UTC)
I support the idea, but suggest the following:
Identify the X number (10? 100? 1000?) of most-transcluded files and deal with them separately after the rest are done.
Do 100 at first, 1,000 three days later, 10,000 three days later, and so forth.
Two days protection has been applied on that page so that non-admins can see its effects. I assume that it isn't a problem on a test page. As for the sensitive files, I'd imagine each on Wikipedia:Cascade-protected items#Cascade protected images would qualify. The list of files I am considering ain't large BTW: 1 and 2 are all the edit protected files we currently have, not all of which are candidates for unprotection. Jo-Jo Eumerus (talk, contributions) 16:08, 13 March 2017 (UTC)
I'm opposed to a mass de-protection: mindlessly reducing protection on a big group of pages is virtually always a bad idea. Of course, if you're talking about spending a large amount of time to review them individually, that's fine; you wouldn't have become an admin if people didn't think you had good judgement. In most cases, I agree that move+upload protection is sufficient, including with some protected-because-highly-visible images — many of those are non-clickable in most of their appearances (e.g. the images used in {{PD-self}}, {{cc-by-sa-3.0}}, etc.), and even if they are clickable, these high-use images generally won't get many clicks, i.e. people won't be bothered by vandalism to them, even in the unlikely event that it occurs. So in other words, I think you should probably unprotect most of these pages, but please consider each one individually. Nyttend (talk) 17:36, 14 March 2017 (UTC)
From reply above - this is only about 89 pages - so I'm fine with deferring to admin discretion on these - if it is used somewhere important keep the move+upload protection; and I wouldn't worry about if there is incidental cascade protection as well. — xaosfluxTalk17:41, 14 March 2017 (UTC)
Ah, you're right. I'm still opposed to mass-unprotecting them, but this small number means that it should be easier to review them individually. Nyttend (talk) 20:50, 14 March 2017 (UTC)
I'm generally supportive of this, provided that someone has verified that each file in question can be safely unprotected. -FASTILY02:00, 17 March 2017 (UTC)
Seems like after almost one week there is support for this proposal, with the condition that each file be reviewed before unprotecting so that we can be sure that it is in fact safe to unprotect. I may take action tomorrow unless people raise further issues. Jo-Jo Eumerus (talk, contributions) 09:51, 18 March 2017 (UTC)
Alrights, it's done. I've left the following pages with edit protection pending some feedback:
File:Apache Wickiup, Edward Curtis, 1903.jpg: Protected by @B: ostensibly to force folks to edit on Commons rather than locally. Simple semi protection would suffice, if any protection is needed, probably.
File:WPAbortion-logo.svg: Protected by @SarekOfVulcan: due to an upload and edit war, apparently. Not sure what kind, if any, of protection is needed now.
I don't remember anything with this image, especially since it's never gotten a bot edit. Surely the issue's resolved, so I've unprotected it. Nyttend (talk) 17:15, 20 March 2017 (UTC)
I checked the deleted revs of WPAbortion-logo, and it was changed to "Murder" a bunch of times before protection. I suspect it wouldn't take long for that to be repeated, and given the number of transclusions... --SarekOfVulcan (talk)19:15, 28 March 2017 (UTC)
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.
The "Protector" permission would give a user permissions to semi-protect, pending changes protect and extended confirmed protect pages indefinitely or temporarily. The users given this permission will help admins, patrolling WP:RPP. To become a "Protector", you will have to have a perfect understanding of the protection policy and have shown it through successfully requesting the protection of approximately 10 pages. To help admins, all of the actions (protect, unprotect) will be logged in something like Special:Protector log. I am happy to listen to constructive feedback, given by you. FriyMantalk09:01, 28 March 2017 (UTC)
Oppose: ECP is too much. Details have not been thought through, e.g.: how will a protector's abilities be allowed to interact with pre-existing protection. BethNaught (talk) 11:55, 28 March 2017 (UTC)
Oppose Per WP:PERENNIAL (unbundling of admin tools). Also, I worry about the number of eager Protectors trying to "help" with the backlog at WP:RFPP with their new buttons. There's a reason why some requests sit there for a while. --NeilNtalk to me13:35, 28 March 2017 (UTC)
Qualified oppose - ECP is waay too far, and eventually is definitely going to get used in a way that is going to cause a shit storm. However, I may support a severely restricted version of this: for example, the ability to semi-protect for either a single hour or something like 24 hours, with no option to re-protect after expiration. Very high volume pages (thousands of hits per hour...basically every single google doodle ever), are almost guaranteed to get high volume vandalism, and the time it takes between requesting semi at RFPP and getting a response might be the difference between dozens of vandalizing edits, and hundreds of readers seeing a vandalized version. So give folks the ability to very quickly deal with only abundantly clear cases and only for a very limited period of time. If the page needs re-protected for longer, or have protection upgraded, you'll have to go RFPP, but this should well give time for an admin to evaluate and respond. I probably wouldn't support a requirement of anything less than 50 successful requests but only with a success rate on the order of 90% or better, and with the expectation that an editor who protects a page is 100% expected to watchlist it and make a good faith effort to respond to legitimate semi-protected edit requests, and with the clear expectation that the editor is expected to err on the side of caution and undo their protection if it's legitimately challenged, and in those cases defer to RFPP, and with a strong understanding that this is only to be used to un-protect a page that that editor themselves has protected. TimothyJosephWood14:18, 28 March 2017 (UTC)
Actually, I would only support this if the restriction that you can only un-protect if you protected were actually built in to the user right. The risk posed by over-protecting is mitigated by the limited time frame, but the risk that a compromised account could mass-un-protect thousands of articles is quite real, and could cause too much damage to depend on the honor system. TimothyJosephWood14:35, 28 March 2017 (UTC)
Discussion
This, or a variation on this, has been discussed many times (Wikipedia:Perennial proposals#Hierarchical structures), and never found consensus. Any solution will need to be more nuanced or inventive than the above proposal. And FWIW, I would oppose this on 'successfully requesting the protection of approximately 10 pages' being much too low of a bar, and I don't think non-admins should be able to extended confirmed protect a page. Sam Walton (talk) 09:45, 28 March 2017 (UTC)
I would like to see arguments against a limited-time trial, per my belief that WP:CRYSTAL plays too great a role in these decisions. At the end of the trial period, there would be another RfC and the right would be removed unless there was a consensus to retain it. Cost of trial? Potential damage of trial? ―Mandruss☎11:29, 28 March 2017 (UTC)
There's a couple of issues with this (not to mention the whole perennial proposal side of things), but I'd like to focus on one in particular - if this were a permission it wouldn't be granted easily, and the editor would need demonstrable experience in protection policies, a general level of clue and an understanding of content creation. It's also pretty likely they'd have most of the other permissions "up for grabs". There wouldn't be that much of a jump between this level of trust and experience and that expected of a RfA candidate. Can't we just stop with the unbundling and focus on making RfA a bit better? -- There'sNoTime(to explain)11:35, 28 March 2017 (UTC)
Well, if you think about it, an ability to protect pages would not require merely as much trust, as it is needed to become admin. This right is nothing as dangerous and harmful in the wrong hands. Previous arguments about the requirements are right, maybe the amount of protection requests should be higher. I also agree, that this right should not give the ability to extended-confirmed protect. --Cheers, FriyMantalk11:59, 28 March 2017 (UTC)
I think everyone will agree that the stated proposal is much too broad. I could see myself supporting a proposal that had many more limits. Specifically:
The right would be given to trusted editors after a short discussion.
They could only semi-protect for 24 hours.
They may only semi-protect to stop ongoing obvious vandalism or blatant BLP violations (that is, addition of unsourced negative information). Socking, edit warring, disruptive editing, etc. are off limits.
Existing admin protection may not be overridden.
All such active protects would be listed on a central page.
The right could be taken away by a single admin, no prior discussion necessary.
I'm gonna go ahead and say User:FriyMan should probably withdraw this, and if they want to more carefully work through a proposal in userspace, I'm definitely willing to help. I think there is a place here for a potentially very useful addition, and I'm generally much more in favor of rights that grant users more abilities to help the project, rather than those that erect additional barriers to that. TimothyJosephWood22:15, 28 March 2017 (UTC)
Technical feasibility
The relevant user rights to configuring protection are "protect" and "stablesettings". From Special:ListGroupRights, the rights given by these are "Change protection levels and edit cascade-protected pages" (protect) and "Configure how the latest accepted revision is selected and displayed" (stablesettings). AFAICT it is not currently technically possible to allow a user to set protection, but not remove it. Nor is it possible to restrict which types of protections (as opposed to PC) a user may set. Therefore this proposal would require non-trivial development work to refactor the code for both these points. Otherwise this would have to be implemented as an adminbot with a requests page. BethNaught (talk) 11:55, 28 March 2017 (UTC)
To clarify, is it proposed to change the code to allow a privileged user to apply protection which they can't later remove? Certes (talk) 13:28, 28 March 2017 (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.
Articles and template access
Does this highest protection level before full exists exclusively for templates, as MSGJ argues? Do we, indeed, go straight to full protection once there's disruption from extended confirmed access accounts—or do we also have this middle road, between full and ce, to be used for the protection of articles, too? El_C18:03, 3 April 2017 (UTC)
Hmmm...I saw that you used that yesterday, and I asked myself the same question. Just by the wording I would say it is indeed only to be used for templates. Being pragmatic I thought you did well, so I'd say with IAR and stretching a bit in every direction, you have that leeway. But what I ask myself now: is there really a de facto difference between template- and full protection at all? Fwiiw, I was a big friend of pending changes level two, which would have filled the gap between full and the rest, and served well in this instance,but alas...it is not to be used. Lectonar (talk) 18:12, 3 April 2017 (UTC)
Well, if there's only 150 editors with that access, then it's not that practical to have at all, for anything. El_C18:17, 3 April 2017 (UTC)
@El C: No, it definitely is. You only want editors who know what they're doing mucking around with highly transcluded templates, especially complex ones. Asking admins to do changes is pretty futile as most of us don't understand the code involved. --NeilNtalk to me18:25, 3 April 2017 (UTC)
But applying it to articles, does in theory, give the 1,200 admins + 150 te editors more free reign to edit the given article freely; and with admins, that's a more sizeable body of editors. But, indeed, I'm surprised there's nothing above ce ec but below te. El_C18:22, 3 April 2017 (UTC)
But you are giving the advantage to editors not specifically cleared by the community to actually receive that advantage. --NeilNtalk to me18:37, 3 April 2017 (UTC)
I'm just looking for something that would permit established editors to use, but curtail disruptive ec accounts. El_C18:44, 3 April 2017 (UTC)
If extended confirmed accounts are being disruptive then either block them or as Neil says, yank the user right. — Martin (MSGJ · talk) 08:22, 4 April 2017 (UTC)
We have all these user-rights, but none are really reflected in the protection options. El_C18:46, 3 April 2017 (UTC)
Yeah, that did not occur to me. I don't think I've modified user-rights more than once or twice. El_C19:41, 3 April 2017 (UTC)
High-Conflict Subjects vs. Saboteurs
Wikipedia has major broad areas of poor-quality Wikipedia pages, particularly about high-conflict subjects - due to access & sabotage by vested interests and their surrogates.
Classic examples include any page about Russia, its politics, or about areas and issues in which it has been involved in conflict or sabotage, including Ukraine, Syria, etc. The Russian government appears (from the edits) to have a very active army of its own Wikipedia editors who track all activity on key Russia-related Wikipedia articles, and immediately undermine any other editors' edits that reflect unfavorably upon the Russian government or its clients, or their actions.
(On many such Russia-related Wikipedia articles, the honest editors, who try to undo vandalism, unsubstatiated claims and deliberate falsehoods, can't seem to keep up with the corrupting edits of the dishonest editors, who appear to be generating edits at an occupational pace, hence the appearance of an organized team of career Wikipedia saboteurs).
Likewise, saboteurs have repeatedly attacked various articles about the Rohingya people -- "the world's most persecuted people" (according to the The Economist and others) -- especialy where it is noted that the government of the Rohingya's home-nation Myanmar, is alleged (by the United NationsHigh Commissioner for Human Rights and by the U.S. State Department) to have committed, or aided and abetted, atrocities againt the Rohingya.
In such places -- and elsewhere in many of the fifty-some Wikipedia articles about the Rohingya and related issues -- the Myanmar government (or military), and their surrogates, have also apparently repeatedly attempted to alter (or delete) the record of their atrocities from the Wikipedia articles on the Rohingya -- while attempting to insert implausible and/or unsubstantiated claims against the Rohingya, or claims attributed to sources apparently affiliated with groups hostile to the Rohingya
(Fortunately, Wikipedia editors have kept up with most of the vandalism and corrupting edits, on most of the Rohingya-related pages, though not always. Additionally, some articles on the Rohingya issues seem to have been created by the saboteurs, to skew the discussion.)
On a more complex level, too, many issues have become so partisan that partisans on one side or another of the issue -- often from the public at large, indigenous to the nation or topic at issue -- seem to insert false statements, and otherwise tamper with the articles, out of bias, spite or deliberate cover-up... usually with little or no credible (nor even plausible) supporting references.
This has happened repeatedly with the Rohingya issue, it seems, but also with countless other issues, in Wikipedia articles, from Domestic violence in India, to governmental corruption prosecutions in Brazil, to American domestic politics.
On highly-charged, very controversial issues involving vast numbers of people -- or particularly targeted and vulnerable populations -- with fierce opposition to the truth from powerful entities, or from broad segments of society -- there ought to be some more effective and sober mechanism, in Wikipedia, to prevent the vandalism and corruption of Wikipedia articles, by these powerful and aggressive opponents of the truth.
And the current "Protection policy" is clearly inadequate to defend against the attacks.
In an era of professionally-produced "fake news" -- dissemenated by organized government-backed (or corporate-funded, or organization-funded, or billionaire-funded) groups of professional online saboteurs -- it is no longer sound policy for Wikipedia to leave articles on such sensitive, important and volatile issues, open to unregulated editing by unknown forces, many of whom are apparently professional saboteurs.
The credibility of Wikipedia, itself, is at stake.
@Penlite: You have suggested no specific policy changes here. If you're arguing for mandatory 30/500 protection for articles in this area then that needs to be approved by the wider community or Arbcom. --NeilNtalk to me12:11, 4 April 2017 (UTC)
@NeilN: I am too new to editing Wikipedia, too unfamiliar with its protocols and bureaucracy / social structure / culture, to be able to make knowledgeable specific recommendations. But I do have sufficient background in international affairs, political science, public affairs and journalism to recognize a pattern of interference with honest reporting and publication.
I'm just the guy who sees the fire -- not the fireman who knows how to put it out. But that's no reason to keep quiet. I've simply sounded an alarm. Those who dominate -- and, essentially, govern -- Wikipedia (such as administrators and long-time editors), are the ones who need to envision, develop and implement the solution.
I realize this is a devastating, fundamental issue, that goes to the core of what Wikipedia has been, from its origins, and what its participants and consumers have idealized in fantasy, and largely in reality.
But times change, circumstances change, and institutions that do not evolve with the times, eventually perish as a result.
Wikipedia is under rapidly escalating attack from professional saboteurs. Act, or don't: it's not really my decision, it's really yours.
Your assertion that the "credibility of Wikipedia, itself, is at stake" seems a bit alarmist, but I actually wouldn't be surprised if we wind up with egg on our faces a few years down the road. I have been vaguely aware of some disturbing patterns in Russia-related content over the past year or so. If anyone has the time and the patience, what really needs to happen is a systematic study to determine if there's a problem and, if so, what its scope is, whether it is indeed overwhelming the safeguards currently in place, and so on. But that should involve a centralized discussion somewhere else (perhaps at the village pump, not here. If you're right, the scope of the problem goes well beyond protection policy and will require a coordinated effort to solve. RivertorchFIREWATER15:58, 4 April 2017 (UTC)
"Your assertion that the "credibility of Wikipedia, itself, is at stake" seems a bit alarmist, but I actually wouldn't be surprised if we wind up with egg on our faces a few years down the road."
It's a bit late for that. The credibility of Wikipedia is not that high in most circles, and its crediblity has been the butt of countless sarcastic remarks, wisecracks and late-night comics' jokes.
While I think Wikipedia has merit (or I wouldn't bother with it), Wikipedia's credibility has been in danger for years, now. Recall the flap when ABC News publicly instructed their staff not to use it as a reference? That was years ago.
Wikipedia has "egg on its face" every time some visitor reads an obviously corrupted article. And the public is most likely to go to Wikipedia, in their most serious moods, to read articles on the most intensely important issues (also the most contentious issues, most subject to sabotage), making it more likely than not that they will see corrupted and vandalized articles.
And the ease with which the bad mixes with the good, in Wikipedia, gives the visitor no realistic way to sort the truth from the fiction, making Wikipedia articles largely pointless (or even detrimental) to read -- especially on the most important (and thus, most contentious) subjects.
While plenty of Wikipedia visitors are naive or ignorant enough to fail to notice the sabotage and falsehoods, many are not... and word spreads.
In my own circles, I've found it almost impossible to get most people to take Wikipedia seriously, and I no longer admit, out loud, to editing Wikipedia articles, for fear of damaging my own credibility by association.
And my experience is not unique.
The egg is already there, and getting rotten and smelly with age. Time to wipe it off.
"If anyone has the time and the patience, what really needs to happen is a systematic study to determine if there's a problem and, if so, what its scope is, whether it is indeed overwhelming the safeguards currently in place, and so on.
"But that should involve a centralized discussion somewhere else (perhaps at the village pump, not here.
"If you're right, the scope of the problem goes well beyond protection policy and will require a coordinated effort to solve."
I completely agree. I wish I had the freedom to spend the time to do the work, and had the full range of expertise in Wikipedia, journalism, forensics, cybersecurity, cybertechnology, and interactive user-interface design, to fully address the challenge. I salute those who do, and urge their engagement on this issue.
My experience is different than yours: I consider Wikipedia much more reliable than it once was, and I rarely receive a negative response after telling someone I edit here. When I referred to egg on the face, I meant specifically with regard to certain topics, particularly those relating to Russia. This is a real concern that deserves attention. In more general terms, we still have a long way to go but we are doing so much better than we were a few years ago. Vandalism will always be with us to some degree, but it's way less of a problem than it used to be. Certain other kinds of detrimental edits, especially subtle ones, are harder to detect, so they pose more of a challenge. When I used the word "alarmist", I was referring to sweeping statements of which you've now made more (e.g., "[t]he future of Wikipedia, itself, is at stake"). You have no idea how many times someone has said that over the past decade or so. The world's going to hell in a handbasket, but somehow we muster on. Wikipedia might soon "fade as a tawdry farce"? Give me a break. Maybe the concept of encyclopedia will become obsolete, but when it come to encyclopedias, right now we're very close to the only game in town. We have our problems, sure, but what's the alternative? There aren't exactly competitors waiting in the wings. In any event, this discussion is getting way outside the scope of this page, which is supposed to be about protection policy. If you're serious about sounding an alarm about certain articles or subjects, I suggest again the Village Pump. RivertorchFIREWATER13:52, 6 April 2017 (UTC)
"unregulated editing by unknown forces" is what wrote Wikipedia in the first place. I've seen extended-confirmed vandals, admins with paid agendas, and unregistered users fixing Rohingya articles. The relationship to the protection policy is not so straightforward. -- zzuuzz(talk)16:36, 4 April 2017 (UTC)
@Zzuuzz:Wikipedia is not now (was it ever?) the pure-and-honorable, egalitarian and noble venture that was envisioned at its outset. While most Wikipedians may be good, honorable people (and probably nearly all of the original Wikipedians were) -- time, growth, popularity and growing influence of Wikipedia have drawn the attention of less-honest and less-honorable people... and countless Wikipedia articles, growing in scale daily, are clearly showing the consequences.
As I noted above, times change, and institutions must change with the times to survive. Wikipedia was borne of that reality, and must live in accordance with it, now, or soon fade as a tawdry farce. Which will it be?
Is there a way to edit the request not to request edits?
"Wait! This page is not or discussing edits to protected pages, or for requesting protection or unprotection of a page." I humbly suggest "for" in place of the first "or." — Preceding unsigned comment added by P2Reflect (talk • contribs) 04:01, 10 April 2017 (UTC)
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.
Anyone can protect pages but can only protect to your existing user level? And you cannot unprotect or reduce protection levels if you are blocked or if you are below that protection level? UpsandDowns1234 (Talk to me) (My Contribs) 04:31, 17 April 2017 (UTC)
Hi, UpsandDowns1234! Thanks for the suggestion! A related suggestion was recently proposed, and was quickly closed due to high opposition. The proposed user right would have let users semi-, pending changes-, and extended confirmed protect. Also, to get the right, users would have needed to successfully request 10 page protections. It seemed to me that three of the main concerns with the other suggestion were:
It was a perennial proposal (which this one is too, as Majora stated here);
extended confirmed protection seemed too high (even for a granted right); and that
10 successful page protections seemed too low. (If 10 was too low, an automatic right would probably be too low as well.)
As for my thoughts on this: I am concerned that users could quickly bring themselves to auto-confirmed (or possibly even extended-confirmed) status and then harmfully protect large numbers of pages before being caught and blocked. Also, users could decide to protect pages from less-privileged users simply on the grounds of disagreement. For example, an autoconfirmed user edit-warring with some IP editors could decide to semi-protect the page just to keep the page the way that the autoconfirmed user wanted it.
I also have a few questions about things that seemed ambiguous to me:
Would you have to be autoconfirmed to pending changes-protect pages?
Users could not protect pages if they were blocked, right? (The proposition only said that users couldn't unprotect or reduce protection level on pages while blocked.)
At any rate, this is a very interesting idea, and although it probably won't go through, it's still interesting! (It never occured to me that users could automatically get a right like this.)
I'm confused as to what "the above statement" and "the same rules" are. For each one, are you referring to your own proposal, the one I mentioned, or something else?
I am referring to specifically my comment at the top. Also, a new level of protection "protection protection" can be used to only allow Administrators to protect pages should there be edit warring.UpsandDowns1234 (Talk to me) (My Contribs) 14:03, 17 April 2017 (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.
New level of protection?
There should be a new level of protection called link protection. It only allows the insertion of internal links and external links can be added by administrators only. UpsandDowns1234 (🗨) (My Contribs) 01:30, 19 April 2017 (UTC)
Why? What problem is this trying to solve that simple revision or any of the other protection levels won't solve? Also, mediawiki isn't set up like that. You might be able to do this with an edit filter but to waste server resources on this seems a little much. Trying to find a problem for this solution but not finding one. Perhaps you should post these ideas at the the idea lab instead of here. This page is more for discussion of edits to WP:Protection policy. Not for proposing completely new things. --Majora (talk) 01:35, 19 April 2017 (UTC)
But a bot and edit filter already take care of the worst spamlinks. And since spamlinks are typically added by unconfirmed editors, semi-protection would suffice for articles that get regularly hit. As an aside, I think I can count the number of articles I've protected solely because of spam on one hand (at the very most). --NeilNtalk to me02:47, 19 April 2017 (UTC)
Clarification needed?
Normally, I am on the side of avoiding instruction creep, but when I see an admin who appears to be missing the point of a policy, I have to wonder whether a slight wording change will avoid problems in the future. Note that I am not asking that the wording be changed, but rather trying to open a discussion about whether it should be changed.
The policy section is this:
"When protecting a page because of a content dispute, administrators normally protect the current version, except where the current version contains content that clearly violates content policies, such as vandalism, copyright violations, or defamation of living persons. Since protecting the most current version sometimes rewards edit warring by establishing a contentious revision, administrators may also revert to an old version of the page predating the edit war if such a clear point exists" --WP:PREFER
The conversation where I believe that an admin missed the point of the policy is here:[4][5][6]
In my opinion, the problem is the "administrators normally protect the current version" language. It seems to me that the policy should instead state or at least imply that administrators should use their discretion to decide whether to protect the last edit made or to restore a previous, stable version. --Guy Macon (talk) 14:30, 12 May 2017 (UTC)
How about "administrators may also revert to an old version of the page predating the edit war if such a clear point exists"? -- zzuuzz(talk)16:11, 12 May 2017 (UTC)
And perhaps we should include something that in that case the protecting admin is not to be considered involved (I think the protection of the current version is recommended exactly to avoid being accused of being involved). Often edit-warring isn't that clear cut to begin with. Lectonar (talk) 16:20, 12 May 2017 (UTC)
But it doesn't work. If an admin who is not previously involved in a content dispute but secretly favors version B over version A sees an edit war, all he has to do is wait until one of the edit warriors reverts to version B and instantly protect the page. We need to trust the administrators to recognize when they have strong feelings about the content of an article and let some other admin who doesn't have a bias (conscious or unconscious) deal with the edit warring behavior without using the tools to issue a supervote on article content. In my opinion, very close to 100% of admins do the right thing in such cases, and I don't see even a tiny hint to the contrary in the underlying case that I am studiously ignoring as I discuss policy wording. --Guy Macon (talk) 02:30, 14 May 2017 (UTC)
The current wording, as I noted in the prior discussion which Guy Macon actually cites above in his diff, already states this. As I told Guy Macon the first time, the current text already says " administrators may also revert to an old version of the page predating the edit war if such a clear point exists" I don't know why he believes that the current policy does not allow for admin discretion, since 1) it clearly states that it does and 2) in the very same post where I first replied to him, I plainly explained to him that it does. I'm not sure what else to do here, since both this page, and my explanation thereof, could not be any clearer regarding this. --Jayron3217:11, 12 May 2017 (UTC)
But you also told me "clearly states best practice is usually to protect the current version",[7] which is dead wrong. Neither protecting the current version or protecting a stable, status quo version is "best practice". Either is allowed, at the admin's discretion. The policy does not say anything about "best practice". I assume that the reason you wrote that particular wrong-headed opinion (and your snarky comment about my interpretation of the meaning of "status quo") was because of the word "normally". I assume that if that word led you astray it might lead other admins astray, and thus we are having this discussion about clarifying the policy. --Guy Macon (talk) 15:20, 13 May 2017 (UTC)
I think there might be a disagreement in what constitutes a "clear" version. In the discussion which gave rise to this thread, the definition of vandalism and/or edit-warring was contentious. Lectonar (talk) 17:22, 12 May 2017 (UTC)
The meaning of vandalism or edit warring is only confusing to people who are willfully obtuse and stand to gain by claiming to not know what those terms mean; usually to win an argument by claiming that their good-faithed opponent is vandalizing when in fact they merely hold a different point of view. Vandalism is pretty easy to understand, as is edit warring. --Jayron3218:03, 12 May 2017 (UTC)
Just for the record, I had nothing to do with the underlying dispute, and my only comments at Village pump (policy) were about what I believe to by an admin who, in good faith, came to a wrong conclusion about this policy (specifically, imagining that one of the two options for admins is "best practice"). --Guy Macon (talk) 15:20, 13 May 2017 (UTC)
Perhaps clarity would follow from resequencing the text, and making clear that if an editor / group of editors have an issue with the version protected, the option to request returning to a point before the dispute is available:
When protecting a page because of a content dispute, administrators have a duty to avoid protecting a version that contains policy-violating content, such as vandalism, copyright violations, defamation, or poor-quality coverage of living people. Subject to this proviso, administrators exercise their discretion (without becoming involved in the content dispute) in deciding whether to protect the most current version of an article, or to revert to an older, stable, or pre-edit-war version of the page before applying protection.
Editors convinced that the protected version contains policy-violating content, or that protection has rewarded edit warring or disruption by establishing a contentious revision, may identify a stable version prior to the edit war and request reversion to that version. Before making such a request, editors should consider advice about the wrong version and recognise that requests that are continuations of an edit war and may warrant blocks.how an independent editor might view the suggestion and recognise that continuing an edit war is grounds for being blocked.
I really like the basic concept. Perhaps we could work in something to the effect that such a request is best made by someone who wasn't part of the edit warring?
I have a problem with any policy linking to The Wrong Version, which is clearly labeled "This page contains material intended to be humorous. It should not be taken seriously or literally." --Guy Macon (talk) 15:20, 13 May 2017 (UTC)
Looks good to me. Jayron, would the above change in wording suffice to convince you that this policy does not "clearly state [that] best practice is usually to protect the current version"?[8] --Guy Macon (talk) 02:13, 14 May 2017 (UTC)
Support EdChem version. Reference to "the Wrong Version" has always stuck in my craw. It's insulting and wrongheaded and is actually bad advice, which is why it passed off as the joke it is. We are serious people here and don't benefit by being laughed at. The "I don't care whose truck it is; Jimmy was holding it when I came in the room, so Jimmy gets to keep it, now stop squabbling, I'm busy" approach to parenting is stupid and lazy. It might well be Bobby's truck, and that matters. So let's not have that approach here. It doesn't strike me as how a good organization would be run. Herostratus (talk) 02:58, 14 May 2017 (UTC)
It is clear that my suggestions above has some support, but implementing the above text in the existing text would be awkward. So, I offer a suggestion for a complete redraft of the section, with a side-by-side comparison with the current version:
Current Version
Proposed Version
On pages that are experiencing edit warring, temporary full protection can force the parties to discuss their edits on the talk page, where they can reach consensus. Isolated incidents of edit warring, and persistent edit warring by particular users, may be better addressed by blocking, so as not to prevent normal editing of the page by others.
Uninvolved administrators are authorised to use blocks to deal with isolated incidents of edit warring, as well as with persistent edit warring by particular users, thereby allowing normal page editing by others. Under this policy, administrators are granted discretion to temporarily impose full protection to end an ongoing edit war; in this situation, talk page discussion of all proposed edits must reach consensus for an edit to be implemented.
{{anchor|PREFER|prefer}}<!--former tags allow section referencing while accommodating section name changes. DO NOT REMOVE IT.-->
{{Policy shortcut|WP:PREFER}}
When protecting a page because of a content dispute, administrators normally protect the current version, except where the current version contains content that clearly violates content policies, such as vandalism, copyright violations, or defamation of living persons. Since protecting the most current version sometimes rewards edit warring by establishing a contentious revision, administrators may also revert to an old version of the page predating the edit war if such a clear point exists. Pages that are protected because of content disputes should not be edited except to make changes which are uncontroversial or for which there is clear consensus (see above).
When protecting a page because of a content dispute, administrators have a duty to avoid protecting a version that contains policy-violating content, such as vandalism, copyright violations, defamation, or poor-quality coverage of living people. Administrators remain uninvolved when exercising their discretion, subject to this proviso, to decide whether to apply protection to the most current version of an article, or to an older, stable, or pre-edit-war version.
Protected pages may not be edited except to make changes that are uncontroversial or for which there is clear consensus. Editors convinced that the protected version of an article contains policy-violating content, or that protection has rewarded edit warring or disruption by establishing a contentious revision, may identify a stable version prior to the edit war and request reversion to that version. Before making such a request, editors should consider how independent editors might view the suggestion and recognise that continuing an edit war is grounds for being blocked.
Administrators should not protect or unprotect a page to further their own positions in content disputes.
Administrators who have made substantive content changes to an article are considered involved and must not use their advanced permissions to further their own positions. When involved in a dispute, it is almost always wisest to respect the editing policies that bind all editors and call for input from an uninvolved administrator, rather than to invite controversy by acting unilaterally.
I recognise that I have made tweaks to the text proposed earlier, but I think they are not substantive. My proposed version integrates the material from the policy section not addressed earlier. EdChem (talk) 06:17, 14 May 2017 (UTC) PS: Inviting input from all those who have commented above: Guy Macon, zzuuzz, Lectonar, Blueboar, Jayron32, and Herostratus. EdChem (talk) 07:26, 14 May 2017 (UTC)
Support for the proposed version by EdChem. The soft "wrong" redirect is gone, and the matter of staying uninvolved while reverting is so much clearer now. Thank you for the work on that; my hat is off to you, Sir. Lectonar (talk) 07:02, 14 May 2017 (UTC)
Support , alt text for paragraph one suggested (but support the original as well @EdChem: what do you think? - reworded to make the lead focus of the paragraph to be about the protection policy not the blocking policy. — xaosfluxTalk15:16, 14 May 2017 (UTC)
Xaosflux, your change goes back to the sequence in the current text. I understand your preference to mention the protection policy up front, rather than the blocking policy. My thinking was that the intro is about edit warring and that page protection comes in where a single block is not likely to address the problem, where there is not a clear-cut right / wrong in the dispute. So, the logic to me is from problem (edit warring) to solution in simple cases (response = block) to the more complex cases where this policy comes in. The current version reads to me like the default response is protection with blocks as an alternative in some cases, but I think the default is to block and only go to protection where the collateral damage of cutting off all editing is justified by the type of disruption involved and where a discussion to reach a consensus is needed to resolve a dispute involving multiple editors and / or complex issues where policy might support either version or where the application of policy is unclear, etc. Perhaps an alternative form of words is needed to better reflect my intent? EdChem (talk) 17:21, 14 May 2017 (UTC)
I pulled it out of the top, will leave here if anyone else wants to comment:
Under this policy, administrators are granted discretion to temporarily impose full protection to end an ongoing edit war; in this situation, talk page discussion of all proposed edits must reach consensus for an edit to be implemented. The blocking policy authorizes uninvolved administrators to use blocks to deal with isolated incidents of edit warring and persistent edit warring by particular users - allowing normal page editing by others.
My thoughts were that when a content dispute involving many editors on one article is occurring that blocking every one of the editors is generally not the best course of action. Maybe a more specific call out that the edit warring policy information should be referred to first? — xaosfluxTalk18:38, 14 May 2017 (UTC)
I think that all options should be on the table, and that no policy should say that one is preferable over the others. True, many admins will protect the page rather than dealing with six or seven people edit warring simply because it is less work, but it is also perfectly OK for an admin to pick everyone who went past 3RR and give them a short block. Sometimes that's what is needed to convince editors that we are serious about our edit warring policy. But only sometimes. Again, we need to trust the admin to decide what will work best in each particular situation. -Guy Macon (talk) 22:28, 14 May 2017 (UTC)
Agree, however a multi-party content dispute may not hit "3RR" thresholds - but still leave the page unstable for readers. — xaosfluxTalk23:10, 14 May 2017 (UTC)
How about an alternative wording, such as:
Content disputes and edit warring may be addressed with blocks issued by uninvolved administrators while allowing normal page editing by other editors. This policy grants administrators the discretion to temporarily fully protect an article to ending an ongoing edit war. This alternative approach may be better suited to multi-party disputes and contentious content as talk page consensus becomes a requirement for requested edit to be implemented.
Maybe the emphasis is better this way, Xaosflux and Guy Macon? I've tried to imply when each approach is typically best, but without mandating admin action or inappropriately restricting discretion. EdChem (talk) 03:17, 15 May 2017 (UTC)
That direction feels better, think the phrasing needs a little bit of clean up, but I'm going to have to revisit due to WP:EUI right now. — xaosfluxTalk03:41, 15 May 2017 (UTC)
All three suggested versions look fine to me. Alas, it appears that no change to the wording will suffice to correct the original misinterpretation of policy that led me to start this discussion[9][10], so the best I can hope for here is clearer wording. --Guy Macon (talk) 04:39, 15 May 2017 (UTC)
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.
Hi! I noticed a side discussion going on here (which, admittedly, I turned into a full discussion), and I thought that it should have its own section for discussing the subject. (Added by Noah Kastin (talk) 11:31, 21 April 2017 (UTC))
Majora: I have changed the color of the padlock on WP:CASC to gold! — Martin (MSGJ · talk) 12:47, 21 February 2017 (UTC)
Noah Kastin said (not as a direct reply, but as part of a longer post, most of which had to do with the main discussion):
And, unrelated to the main discussion (though related to an earlier comment in this discussion by MSGJ): MSGJ, I think that using a gold lock for cascade protection might confict [sic] with full protection, since WP:GOLDLOCK goes to full protection, but would equally apply to anything else with a gold lock. I think another color, which does not share a shortcut with anything, would be beter [sic]. For example, this one could be used:
I do think that a color which does not conflict with a current shortcut should be used for cascading protection, but there are many colors of locks which fit these criteria. A full list of available locks can be found at Wikipedia:Protection policy/Padlocks#Available, but here is a list of 3D ones (in the same style as the other locks) which would not potentially usurp a shortcut:
This section is for voting on colors, preferably one of the ones listed above. If any of the padlocks which you want to vote for does not have a section below, please add a section for it with a picture of the lock. (Notice added by Noah Kastin (talk) 13:05, 21 April 2017 (UTC))
@Samwalton9: Thanks for the vote! I realized that it might have seemed like voters have to vote on one of the three colors I mentioned; as a large part of this was to see what other people want the padlock color to be, I would be happy for voters to pick any padlock, not just the ones I mentioned. Two edits I made (this edit and this edit) attempted to clear this up. Knowing this, you might want to change your vote. If you have any questions about this, please let me know. Thanks! Noah Kastin (talk) 13:24, 21 April 2017 (UTC)
@Samwalton9: Thanks for entering into this discussion! I appreciate any feedback.
I apologize for stating the point of this discussion confusingly. The point is not to change the template protection icon, which is what the Icon for template protection discussion was about. This discussion was created due to dissatisfaction with the current padlock for cascading protection, as the current padlock might conflict with an already existing shortcut (the current cascading padlock is bright gold, hence might conflict with full protection, which is dull gold, so they both could legitimately use WP:GOLDLOCK).
As for the template protection padlock, I don't think that there's anything wrong with it, but I don't mind if it changes, as long as it doesn't change to a retired padlock color. However, that's part of its own discussion (which this was originally a side discussion of), hence the confusion.
I hope that this has made matters clearer. If you have any questions, please let me know.
My color preferences have changed, which my new color votes reflect.
For reasons stated above, my main goal with this discussion is to get some color on my proposed list of 16 padlocks to replace the current color. Changing my votes like this should help get some color on the list to replace the current color, as there is now clear consensus (if two editors counts as consensus) to go ahead with one color.
Please let me know if this goes against Wikipedia policy or is otherwise problematic.
Right now, there seems to be a clear consensus that the lock icon should be changed to the Turquoise lock icon (the one pictured to the right). I'm going to put in a request at the Teahouse to ask how the lock color can be changed. If anyone has any suggestions on how to do this or any other comments (including color votes), feel free to let me know. Thanks! Noah Kastin (talk) (🖋) 04:01, 10 June 2017 (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.
Please change protection policy
OP checkuser blocked
The following discussion has been closed. Please do not modify it.
I want there to exist a new level of protection that I invented: "Register protection", which prevents unregistered users from editing pages with this level. It will use the padlock . Confirmation or autoconfirmation is not required to edit pages with this protection. All I need to do to edit pages with this protection is logging in or creating an account (the same required to create pages (not talk pages). Bemahewal (talk) 20:35, 9 July 2017 (UTC)
And also add bureaucrat protection (which makes full protection become "admin protection"), which allows only bureaucrats from editing the page. (padlock is ) Bemahewal (talk) 20:40, 9 July 2017 (UTC)
And bot protection () - which allows only bots and admins from editing.
And steward protection () - which allows only stewards from editing.
And founder protection (which will become full protection, padlock is ) - which allows only the founder of Wikipedia (User:Jimbo Wales) from editing.
(Note that like admin protection, bureaucrat, steward and founder protection will have cascading protection too). -- Bemahewal (talk) 20:52, 9 July 2017 (UTC)
Why do you think these would be beneficial changes? Why do you think these are necessary above and beyond the current protection mechanisms? --Izno (talk) 21:54, 9 July 2017 (UTC)
"Extended confirmed protection, also known as 30/500 protection, prevents edits from all IP editors and any registered user with less than 30 days' tenure or fewer than 500 edits. Pages with this level of protection can be edited only by editors with the extended confirmed user access level, granted automatically to editors with the requisite tenure and number of edits."
If they need "extended confirmed user access level", then they need 30 days and 500 edits.
Here is what I think it should say:
"Extended confirmed protection, also known as 30/500 protection, requires editors of the page to have been editors for 30 days and have 500+ edits. — Preceding unsigned comment added by 72.240.243.95 (talk) 02:57, 4 August 2017 (UTC)
Either "and" or "or" is fine in the sentence in question. To put it this way: it "prevents edits from [...] any registered user with [...] fewer than 500 edits". Inverting the statement, as you have in your proposed reword, would require the "and". --Izno (talk) 03:04, 4 August 2017 (UTC)
Now that the red padlock icon is free, I was thinking, perhaps the Office Actions padlock should be changed to red instead of black? Red seems like it would be a color that would indicate a more severe situation. What does anyone here think? ANDROS1337TALK15:55, 10 August 2017 (UTC)
Am I the only one who thinks all this fussing about colors is a waste of time? Why not just have a generic padlock with a word or abbreviation below or across it, like SEMI or FULL or PEND etc.? EEng01:42, 11 August 2017 (UTC)
@EEng: It seems to me that it would be a waste of time creating new lock icons with labels when there are existing icons to use, but I also think there's no need (not broken) to switch office colors. - FlightTime (open channel)01:56, 11 August 2017 (UTC)
Is there any reason Page Movers can't move pages under move protection? I understand that some pages like Facebook will highly likely never need to be moved, but for those being targetted by vandalism, it'd still be useful for us to be able to in the event a genuine reason / concensus is resolved in the meantime. — IVORKDiscuss23:16, 13 August 2017 (UTC)
I just requested a speedy deletion for Luigi Grosu (Actor & Singer) , which was an oddly familiar article. The creator is clearly trying to work around previously salted article titles, and has been doing so for a few years now. At what point is this considered disruptive, and what steps should be taken? --Ronz (talk) 02:05, 10 October 2017 (UTC)
Thanks. I pointed out to the admin that deleted the article that it was the ninth or so created by Jaymi Martin apparently to get around some of the salted articles. That was enough for a block and further article creation protections. --Ronz (talk) 22:24, 10 October 2017 (UTC)
What template to use for ECP articles?
For a semi-protected article, I put a {{pp-semi}} template on it. For an article full-protected due to a content dispute, I put a {{pp-dispute}} template on it.
I can't find a template to use for extended confirmed protection, although it seems the pp-semi template adapts to it somehow. ~Anachronist (talk) 23:43, 25 October 2017 (UTC)
Salting redirects
I went ahead and boldly added this to the salting policy. Its something that has become more common in AfDs where there is a concern that a redirect may simply be undone against consensus. I didn't see it listed on this page, and since it seems pretty non-controversial and is becoming more common, I thought it best to document. I'm of course open to any tweaks of wording, etc. or reversion if people think it shouldn't be there. TonyBallioni (talk) 16:49, 5 November 2017 (UTC)
Salting redirects
Tavix, I have a question about this revert of the content I added to put the practice of salting redirects here. I know it is not technically creation protection, but I don't really know where else it would go in the policy, and it is a common enough practice that it should be documented somewhere. I'd appreciate your thoughts on this. TonyBallioni (talk) 17:46, 5 January 2018 (UTC)
You're a bit confused on the jargon. A redirect cannot be "salted", WP:SALT only applies to creation protection. The action you are describing is full protection. On to the substance, I disagree that it should be added. If there is further disruption to the redirect after the AfD, protection can be added in accordance with the guidance already in place. However, what you are describing seems to me to be pre-emptive protection, which would be in violation of guidenece already in place, eg: Applying page protection in a pre-emptive measure is contrary to the open nature of Wikipedia. I would encourage you not to apply protection unless it's needed due to disruption, etc. --Tavix(talk)18:02, 5 January 2018 (UTC)
This is done at AfDs enough as it is that it needs to be documented. I've never done it myself (that I can think of), but I have supported it. Regardless of whether or not it is in here, it will continue to happen, so documenting that it exists is best. TonyBallioni (talk) 18:19, 5 January 2018 (UTC)
Just because something has been done doesn't mean it's the right thing to do. I can think of instances where fully protecting a redirect is beneficial to the project, but I can't think of any instances that would fall outside the current guidance. --Tavix(talk)18:22, 5 January 2018 (UTC)
Yes. It still should be documented as it is a practice that can be beneficial, and is done regularly enough at AfD that keeping it as IAR doesn't serve much point anymore. Nothing in the text I added contradicts the rest of the page, it just notes that with consensus at AfDs, a redirect may be salted/full protected just as a deleted article may through consensus in an AfD. TonyBallioni (talk) 01:32, 6 January 2018 (UTC)
Recreation of a variant on the salted title
This is continued from WP:COIN (permlink). Regardless of article content, is creation of XYZ when there is a salted XYZ Corporation to be considered to fall under the procedures for "contributors wishing to re-create a salted title with more appropriate content"? In other words is this behavior a) never covered by protection policy b) covered by protection policy depending on content, creator or some other variable or c) always a recreation of the salted article? ☆ Bri (talk) 21:43, 16 January 2018 (UTC)
Third Opinion
The request for a Third Opinion is being deleted, because there has not been significant discussion (or any discussion) here, only a comment. A Third Opinion can be offered after two editors disagree respectfully. Robert McClenon (talk) 02:46, 19 January 2018 (UTC)
However, when a title has been create-protected, creating a page with a variant spelling in order to bypass the create-protection is clearly an attempt to bypass the create-protection, and is likely to result in the variant also being salted. In American football, if you attempt an end run, and get hit by the linebacker, what did you expect? Robert McClenon (talk) 02:46, 19 January 2018 (UTC)
When to up pending changes protection to semi-protection?
I was surprised not to see a protected mark on the Rian Johnson article, since I've been peripherally aware of the "controversy" surrounding his movie over the past two months and figured the article was probably the target of massive IP vandalism. When I checked the page history I saw that it was under pending changes protection, but literally every edit I can see appears to be either vandalism by an IP or new account or someone reverting it. Since the changes are never publicly visible until they are accepted, I guess there is no content problem, but when every edit over a period of months is a revert it just looks like an edit war -- wouldn't semi-protecting be better?
Same is basically true for Game of Thrones except the "invisible edit war" there has been ongoing for years.
Posting this here rather than RFPP since I'm legitimately not sure if I'm missing something like how maintaining unconfirmed editors' "right" to edit those particular articles except in extreme circumstances is important.
FWIW, I'm not quite sure when PC offers benefits in general. I don't mean to raise the spectre of that discussion again, as I'm not opposed to PC for any ideological reasons, but all it has ever seemed to do for me or any page I'm familiar with is to increase the workload on dealing with vandalism because it is prone to technical glitches, doesn't actually seem to be that effective, and creates the possibility of hat collectors edit warring with good faith contributors (and this happens more often than we think). I know that I'm personally very unlikely to PC protect something if it falls short of semi-protection if only for the fact that it actually seems harder for a good faith user to contribute with it than with semi-protection, while making it easier for vandals to vandalize. I know before I got the bit, anytime I requested PC, most admins would just go ahead and flip the switch to semi. Not sure if this really answers the question, but I'm just bringing up some general thoughts that I've had and discussed with other admins recently. TonyBallioni (talk) 21:57, 13 February 2018 (UTC)
"I know before I got the bit, anytime I requested PC, most admins would just go ahead and flip the switch to semi." Not this admin. I like PC and find it very useful in certain situations. A BLP that gets constant updates (like a sports figure) but the occasional but steady BLP vio comes to mind. --NeilNtalk to me22:02, 13 February 2018 (UTC)
Seems like a technical nightmare that is more work than it's worth in those cases. I just personally can't seem to think of a case where it either doesn't create too much work (the edit history of the sport figure you described actually was one of my examples for when PC isn't worth the effort: you have too many good edits interwoven with bad ones during games, and it makes an absolute mess of the edit history and is a technical nightmare to deal with) or where semi-protection wouldn't be more effective. If it isn't really semi-protection worthy, I've always found it easier just to deal with it manually. TonyBallioni (talk) 22:10, 13 February 2018 (UTC)
British
Describing Stephen as 'English' does not do justice at all to the very high esteem in which he was held by the whole of the nation. He should be described as British to reflect this esteem from the various peoples of the UK. I will change this, but await comments first. Varnebank (talk) 19:44, 15 March 2018 (UTC)
Blacklisting would be better, but it might bring up other problems (i.e. there are legitimate titles that start with Test). TonyBallioni (talk) 02:19, 11 March 2018 (UTC)
True, a blacklist might stop some, but that which stops test pages might catch too many legitimate pages. I think maybe a bot or edit filter might catch the obvious ones. Still, I think the obvious titles should be salted. Jjjjjjdddddd (talk) 04:55, 11 March 2018 (UTC)
If you want technical details, I’m not your man, but the tl;dr is that salting prevents the creation of one specific title, while the blacklist uses regex to deny the creation of titles that meet specific conditions. Adding a title to the blacklist if done correctly prevents multiple iterations of the same concept (so Foo and Foo (bar) would both be prevented from creation). TonyBallioni (talk) 14:41, 11 March 2018 (UTC)
Thanks. If someone has an explanation of how the blacklist is anything more than a list of "regular expressions" that happen to be literal strings, I'd like to hear it. EEng19:59, 15 March 2018 (UTC)
It's not the only one that has random stuff. This one at least makes sense since I would guess in the edit protected edit notice this page is probably linked prominently. --Izno (talk) 02:32, 11 April 2018 (UTC)
errors on this page
there are syntactic or semantic errors currently on this page, for example : "Because pages in user space that end in ".js" and ".css" are only editable by the user the user space belongs to and administrators, this will protect your user page from further vandalism." The page needs to be repaired.
@Z75SG61Ilunqpdb: No, that's correct. Awkward phrasing, but it reads as "...only editable by (the user that userspace belongs to) and (administrators)..." I've made some slight changes, hopefully that's better. ~ Amory(u • t • c)01:06, 5 May 2018 (UTC)
"Should be rare"
Umm...WK...not withstanding that the edit is a bit premature since ACPERM hasn't yet been implemented, what exactly is the situation in which AC create protection accomplishes anything at all, and should therefore be "rare" rather than "nonexistent"? GMGtalk14:22, 25 April 2018 (UTC)
I thought about non-existent, but semi-creation protection could be useful for pages outside of mainspace, where non-confirmed users can still create pages. That's not a big use case, though. I honestly didn't realize that ACPERM hadn't been implemented yet, though; I thought it would be implemented within a day or two of the RfC closing. Mea culpa on that. Writ Keeper⚇♔14:27, 25 April 2018 (UTC)
Ah. Yes. That seems obvious now that you've pointed it out. Might be good to specify that when rarely used, it's only use is outside mainspace. I don't have the link to the phab ticket, but... there is a lively debate about implementation going on there, or at least there was as of this morning. GMGtalk14:31, 25 April 2018 (UTC)
Tl;dr a cs.wiki arb who is also a volunteer developer thought it was low priority and triaged it as such, and it ignited a shitstorm. TonyBallioni (talk) 14:35, 25 April 2018 (UTC)
Hoo boy, that sounds like fun. I was wondering why CSD still seemed pretty big. And we haven't added .* <autoconfirmed> to the title blacklist yet? Writ Keeper⚇♔14:39, 25 April 2018 (UTC)
Nothing, I would guess. It doesn't hurt anything that they're semiprotected, so I doubt it's worth anyone's time to go through and lift all the protections. I doubt there's any need to go through and increase protections on them either: they're no less protected after ACPERM than they were before. Just leave 'em, I'd say. Writ Keeper⚇♔15:29, 7 June 2018 (UTC)
I'm sorry I'm sending a message here, but I do not know where to request a place a defense on the value of Hapoel Be'er Sheva.
I would like you to help me to protect the value of Hapoel Be'er Sheva because there are unregistered users who do more damage to the value than they do. Thanks for the helpers Assaf Official (talk) 23:53, 9 June 2018 (UTC)
Semi-protection completely disables edits by new users (only possible via bulky proposal), while pending-change-protection does allow them to edit, just limited by a barrier of pending edits?. Maybe, some new users actually want to improve the page. --IChance2 (talk) 19:06, 6 June 2018 (UTC)
Because pending changes is all but useless, is a technical nightmare, creates more work, disturbs users on their watchlist, and frequently will completely mangle page histories. It’s more trouble than it’s worth: reverting live vandalism is easier and much less work in most cases. TonyBallioni (talk) 19:18, 6 June 2018 (UTC)
Cite error: There are <ref> tags on this page without content in them (see the help page).This page should be fully protected.
This talks about the protection policy itself. Why not fully protect when others might add unwanted edits etc.
Mohamed Naufan Ali Nifaz (talk) 11:53, 19 August 2018 (UTC)
Because this is Wikipedia, and we allow editors to collaboratively edit pretty much any page. Policies and guidelines are not exempt from this—see WP:PGCHANGE for more information. Mz7 (talk) 01:52, 4 September 2018 (UTC)
top padlock icon code
I was wondering if we could place the template top mini-icon code for each padlock section so editors can see what the correct code is for each padlock. Cheers. Govvy (talk) 12:39, 12 August 2018 (UTC)
Nowadays you can use {{pp}} for all protection levels, and the template will automatically detect the proper padlock color to display. Mz7 (talk) 01:54, 4 September 2018 (UTC)
There was a brief implementation on the English Wikipedia of the new padlock design for all protected pages from 02:30–04:40, 13 November 2018 (UTC). Does anyone know who was responsible for this? —Wei4Green | 唯绿远大 (talk) 04:57, 13 November 2018 (UTC)
Indeed. The current situation is that the files are create protected, and are upload/move protected on Commons, meaning that there's not much harm in going ahead again, although it may not be the done thing, as seen at the wording of {{Keep local high-risk}}. As an aside, I also propose that the following lock symbol gets added to the roster for interface protection: ∰Bellezzasolo✡Discuss11:01, 13 November 2018 (UTC)
@Bellezzasolo: "interface protection" isn't really a protection level (you can't configure it) so I don't think we need this just like we don't need a FP icon on every mediawiki message. — xaosfluxTalk20:14, 13 November 2018 (UTC)
Eh, I think it's worth using — we've got a specific template for requesting edits to interface pages, so while it won't get much use there's no harm in using it there. ~ Amory(u • t • c)23:22, 14 November 2018 (UTC)
In some article where a user don't have a permission to edit a page in "This page is currently protected so that only..." after clicking "View source", the page still showing the old padlock. Can someone fix this? Hddty. (talk) 12:55, 14 November 2018 (UTC)
These new minimalist icons for protected pages etc. are just downright ugly and gaudy, and to be a little bold they are irritating. The semi realistic locks were perfectly fine. Not everything online needs to needs to be so sleek and without detail. Talk about sucking the soul out of design.-Sıgehelmus (Tωlk)20:10, 13 November 2018 (UTC)
I see the change necessary to be able to differentiate the different types of locks present before having to hover over the image to see what it was. – The Grid (talk) 20:56, 13 November 2018 (UTC)
They could have just slapped on letters in Photoshop or Adobe Illustrator. I'm just sick of Omnipresent minimalist graphic design. They could have at least put some outline and shading.-Sıgehelmus (Tωlk)22:32, 13 November 2018 (UTC)
Also, the "GOLDLOCK" is now yellowish-brown, the "PINKLOCK" is reddish-purple, the "SILVERLOCK" is dark grey, the "SKYBLUELOCK" is Petty blue, the formerly-olive "GREENLOCK" is forest-green, the "PURPLELOCK" is lavender, the "WHITELOCK" is blue-grey, the "BLUELOCK" is over-saturated, and the "TURQUOISELOCK" is dark teal. The only correct lock is the OFFICE one. Kamafa Delgato(Lojbanist)Styrofoam is not made from kittens.00:22, 14 November 2018 (UTC)
We should move this subtopic "The new lock icons are ugly and unnecessary" to somewhere else. The topic here is about replacing the old designs with the new to the WP:Protection policy page, not about the designs themselves. —Wei4Green | 唯绿远大 (talk) 02:43, 14 November 2018 (UTC)
Mydogisfast I checked your usergroup and your are in the "autoconfirmed" group which means you should be able to edit semi-protected pages. If your still having issues please visit WP:PERM for immediate assistance. ♪♫Alucard16♫♪11:16, 23 November 2018 (UTC)
Hi. Currently, there is no section for protection that is automatically and permanently imposed on user .js and .css pages, nor sitewide pages. The full-protection section says that:
Some areas of Wikipedia are permanently protected by the MediaWiki software. The MediaWiki namespace, which defines parts of the site interface, is fully protected; it is impossible for administrators to remove this protection. User CSS and JavaScript pages, such as User:Example/monobook.css and User:Example/cologneblue.js, are automatically fully protected. Only accounts that are associated with these pages or interface administrators are able to edit them. This protection applies to any user subpage created with a ".css", ".js", or ".json" extension, whether an equivalent MediaWiki skin exists or not. Those administrators may modify these pages, for example, to remove a user script that has been used in an inappropriate way.
This is out of date. Only interface-administrators can edit User CSS and JavaScript pages, as well as sitewide pages. But, admins can still (I think?) edit user .json pages. Can this be updated? Since consensus is required for changes, I didn't edit this myself. --DannyS712 (talk) 01:47, 15 December 2018 (UTC)
@DannyS712: take a look at the update I added, this is really just a 'reference' section about the technical controls - not so much the "policy" so feel free to update it to include correct technical information. — xaosfluxTalk04:51, 15 December 2018 (UTC)
@Xaosflux: thanks! But, if the proposal to restrict the main page to IAdmins passes, I think we might need to define a new type of protection. I know its not my place (I've only been active for 3 months), but can I suggest "Interface protected"? --DannyS712 (talk) 04:55, 15 December 2018 (UTC)
@DannyS712: "interface protection" isn't really a "protection level" (in that you can't configure it - it is managed by the back end software) - Main page also has some other protection on it right now that you can't really see: it is delete-protected and move-protected in the software - it isn't that way because of the protection policy - it is just built in system protections. Perhaps a footnote may help. — xaosfluxTalk05:00, 15 December 2018 (UTC)
Hello 176.26... to request edits to an article, please place your requests on the talk page of the associated article. — xaosfluxTalk19:29, 22 January 2019 (UTC)
Extended confirmed protection
Modification of the text: near the end of the second paragraph, it should read: Extended confirmed protection may be used at administrator's discretion when creation protecting a page.[2]
Is extended confirmed protection needed on all Israel-Palestine related articles?
It seems understandable for some of the most vandalized ones, but surely a regular semi-protected status would be good for most of them? I should note, I can edit on extended confirmed protection articles. Alex of Canada (talk) 07:33, 14 February 2019 (UTC)
@Alex of Canada: This protection is based on a decision by the arbitration committee that says All IP editors, accounts with fewer than 500 edits, and accounts with less than 30 days tenure are prohibited from editing any page that could be reasonably construed as being related to the Arab-Israeli conflict. This isn't the proper location for reducing the protection imposed as a result (see WP:ARCA for amending past decisions) --DannyS712 (talk) 07:37, 14 February 2019 (UTC)
There are some types of pages that are protected by default, and some controlled by edit-filters, but none of the "choosing" of the protection is in the control of non-admins. — xaosfluxTalk20:48, 2 April 2019 (UTC)
Is this the same case for titles like, say, “Wiki on wh33ls” (which matches .*on wh33ls.*, that is not only blocked from moves but also from creation)? --NasssaNser (talk/edits) 02:58, 5 April 2019 (UTC)
Hi. I have a question about Wikipedia:Protection policy#Template protection. It says that Redirects should not be template-protected (although another type of protection may be appropriate). However, Category:Template-protected redirects currently has over 200 redirects that are template-protected. Potential solutions I see are: raise the protection of the redirects; lower the protection of the redirects; and change the protection policy to allow template-protected redirects. Just wanted to bring this discrepancy up. Thanks, --DannyS712 (talk) 23:26, 27 March 2019 (UTC)
It would seem logical, if the template is template protected, the redirects/shortcuts should be also. Messing with a redirect would also break many links. Just my opinion. - FlightTime (open channel)23:31, 27 March 2019 (UTC)
Why in any circumstance would template protection be superior to another type of protection for a redirect? The template editor permission is given to users that, for summary purposes, show proficiency editing templates. Why would that proficiency be relevant to editing a redirect? --Bsherr (talk) 20:13, 2 April 2019 (UTC)
All the non-test template-protected redirects are highly transcluded templates, which template editors are trusted to handle. I suppose we could raise the protection on them to full, but that seems pretty pointless. Galobtter (pingó mió) 20:23, 2 April 2019 (UTC)
For policy consistency, they should be raised to full or lowered. The template editor permission was not intended to be, and should be prevented from creeping into, a subadministrator permission. --Bsherr (talk) 20:35, 2 April 2019 (UTC)
Templates should be protected according to how many transclusions they have, regardless of whether they are redirects. If a redirect has enough transclusions to warrant template protection (but not enough for full protection), then it should be template protected. {{3x|p}}ery (talk) 21:14, 2 April 2019 (UTC)
@Pppery:Redirects should not be template-protected (although another type of protection may be appropriate).. See the "template protection" section. --DannyS712 (talk) 21:57, 4 April 2019 (UTC)
Sigh. I hate it when people unilaterally insert text into policy and later act like everyone else should follow it because it is policy. Galobtter (pingó mió) 19:34, 5 April 2019 (UTC)
@Galobtter: I think you must have misread me? I never argued that we should follow it because it is policy. That would be an obviously circular argument in this circumstance, and a disingenuous one since I inserted it. When I said policy consistency, I was referring to the policy basis behind the existence of the template editor permission. --Bsherr (talk) 19:57, 5 April 2019 (UTC)
It's a nuanced point, but the reason we have template editors is out of recognition that editing templates involves a higher level of complexity. That doesn't apply to redirects, so for redirects to high-risk templates, there is full protection, and no need to gradate. That being said, I understand there is a potential counterargument if a redirect template needs to be applied, or a double-redirect fixed. But I can't think of any other examples of when a template editor would need to edit a redirect to a high-risk template. --Bsherr (talk) 19:57, 5 April 2019 (UTC)
I don't think out of recognition that editing templates involves a higher level of complexity is the case. There are many complex templates that are not template protected - because they don't have enough transclusions. Template protection is not related to complexity (there are also many very simple templates that are protected) but risk of disruption/vandalism from letting anyone edit the template, and the right was created so that technically-competent people don't have to become admins just to edit highly used templates. Galobtter (pingó mió) 20:04, 5 April 2019 (UTC)
Also, applying RCATs and fixing double-redirects seems well-enough use for me - if you are moving a template you definitely need to fix double-redirects - and I don't buy that just because something only has to be rarely edited that we should be raising the protection level of it, despite the fact that template editors can obviously be trusted to edit the redirects. Galobtter (pingó mió) 20:11, 5 April 2019 (UTC)
So, yes, to the extent that we don't consider complexity in deciding whether a template is high-risk or not. However, that templates are often complex is the implicit reason that experience editing templates and modules is a prerequisite to being a template editor (This right is intended to allow experienced template and module coders to make changes without having to request that an administrator make the edits for them. —Wikipedia:User access levels#Template editor). If it were only about preventing vandalism, the right would be granted to anyone demonstrating trust. But since a redirect is not complex, why should one have to have template experience to edit it? If it is only about trust, extended-confirmed protection is a much better and less restrictive tool for that. --Bsherr (talk) 20:56, 5 April 2019 (UTC)
TFA
I see that a bot is preemptively protecting the TFA page.
This would appear to be at odds with the following statement under the vandalism section which will need updating.
"Applying page protection in a preemptive measure is contrary to the open nature of Wikipedia and is generally not allowed if applied for these reasons."
Neils51 (talk) 21:08, 4 April 2019 (UTC)
User:TFA Protector Bot only adds move protection to TFA, for one day, while leaving the original edit-protection as it was before. This is covered under Wikipedia:Protection_policy#Move_protection, specifically "Highly visible pages that have no reason to be moved". See also #Permanent_protection. The bot's been doing this for five years, and before that it was usually done manually. This protection is really minimal, and actually quite sensible since the main page articles tend to attract the types of people who would move a TFA, which has never to my knowledge been moved in any good way. Personally I think the policy has this covered with the additional sections and the words "generally not allowed .. as short as possible". -- zzuuzz(talk)21:01, 5 April 2019 (UTC)
Hi zzuuzz, thanks for responding. On the 4th April, 2019, it appeared that edit protection was applied as well, as per here [Robert Luongo ] with no notice as to why. Subsequently I see that the bot is performing move protection only so perhaps this was a one-off. Regards, Neils51 (talk) 02:49, 11 April 2019 (UTC)
"suggest edit" rather than "cannot edit"
The language on the page currently says that if an article is not protected, users cannot edit. This is correct, but I wish we could be more encouraging about users contributing suggestions on the talk page. Currently this page seems to not have guidance on how users can post suggestions to the talk page in case of page protection. I know the information is elsewhere. I think the answer is to put a request template on the talk page ({{edit semi-protected}}, {{edit extended-protected}} etc.) but I wonder if this is overly complicated for having a different request template for different types of protection.
I have not actually looked at this, policy, and past conversation, but I wanted to make a note of the issue. I do not have a strong opinion at this time. Blue Rasberry (talk)23:09, 25 February 2019 (UTC)
@Bluerasberry: regarding if an article is not protected, users cannot edit can you provide the exact text you are referring to? Generally, if an article is not protected anyone can edit it. — xaosfluxTalk23:36, 25 February 2019 (UTC)
As a new Wikipedia-accounter, I'd like to second this suggestion. I "jointed up" because I noticed a clear edit mistake in the https://wiki.riteme.site/wiki/Eugenics_in_the_United_States page, namely, "such as poverty and the lack of education" should be "such as avoiding poverty and the lack of education" (in the Sanger section). Not being familiar with how to submit edit suggestions for protected pages or how to find out how to do so, adding this comment here was the best thing I could figure out to do. Having a "suggest an edit" option on protected pages would allow me, and other people like me, to more easily and more effectively submit such improvement. I value Wikipedia and generally submit editorial improvements (I don't find it necessary to do so very often) provided it's sufficiently easy -- not the case in this case. Please make these suggested improvements, both my specific suggested edit in the Sanger section of the Eugenics_in_the_United_States page and adding a "suggest an edit" mechanism on protected pages. — Preceding unsigned comment added by MikeRudnick (talk • contribs) 14:43, 16 April 2019 (UTC)
Footnote 169
Very happy to see my piece with Michael Hunzeker cited in footnote 169 for the point on German peace overtures. However, the work cited of ours in the Wikipedia article on the First World War is a Monkey Cage article in the Washington Post. This article discusses our peer-reviewed essay with original research. Perhaps it would be better to cite that journal article rather than the Monkey Cage blog piece. If you agree, then the reference should thus be:
Lanoszka, Alexander, and Michael A. Hunzeker. "Rage of honor: Entente indignation and the lost chance for peace in the First World War." Security Studies 24, no. 4 (2015): 662-695.
My edit has been reverted. However, according to this prestigious dictionary, "tenure" is
"the period of time when somebody holds an important job, especially a political one; the act of holding an important job". So, the word "tenure" is appropriate when refers to "judges in courts", presidents, etc. But Wikipedia can be edited by anyone, even a 10 year old kid. So when we are talking about registered but still anonymous volunteers, and we don't know neither their age, nor qualifications, the word "tenure" sounds pretentious and even ridiculous. "Tenure as a Wikipedian" is like "tenure as a babysitter" - no offense meant - after all babysitting is maybe even more important than editing Wikipedia. So my proposal is to replace "tenure" with "period". Not because I regard the two words as synonymous - just the opposite. And this is why "tenure" should be replaced with "period". The phrase "30 days period" is as precise as "30 days tenure" but much more understandable, especially for non-native English speakers, e.g. scientists, which contribution is invaluable.
P.S. Ironically, when we go into details we see a completely different wording, that does not use neither "tenure", nor "period" ;-) Vikomtalk21:33, 20 April 2019 (UTC)
How about finding a better way to word that - this is a policy and should be plainly readable even to those with low English language aptitude. — xaosfluxTalk22:53, 20 April 2019 (UTC)
My revert is still true; "tenure" is not synonymous with "period" nor can its use there be seen as equivalent. Feel free to write out the full clause of interest and you will find that 'period' is not a word that can be used in that position: prevents editing by users without 30 days tenureperiod and 500 edits on the English Wikipedia is not a sentence that has any meaning to any English-speaking person, never mind non-English speakers.
The closest (but non-trivial) rewrite might be something like "prevents editing by users who have been registered less than 30 days or which have less than 500 edits on the English Wikipedia". --Izno (talk) 23:56, 20 April 2019 (UTC)
Oh my Goodness - you are absolutely right. Now I see that "30 days period" sounds bad. Actually I meant "a period of 30 days", but this phrase makes the problem even worse. Anyway, your last proposal sounds perfect :-) Vikomtalk01:24, 21 April 2019 (UTC)
@Xaosflux: Pretty good, but I have one reservation. Edits are made by the user, not the account. So how about: "(...) automatically when the account is at least 30 days old and the editor has made 500 edits (...)" ? Vikomtalk01:41, 21 April 2019 (UTC)
An editor with multiple accounts may reach 500 edits but still not be EC because they are spread between multiple accounts. --Izno (talk) 02:07, 21 April 2019 (UTC)
The account is at least 30 days old and has been used to perform at least 500 edits? This isn't about the 'editor' but the usage of the current account. — xaosfluxTalk03:07, 21 April 2019 (UTC)
My rule is very precise. Everything should be clear, unless you mean more than one editor using the same account. But we will never know it. Vikomtalk03:21, 21 April 2019 (UTC)
@Xaosflux: Oh, thanks, good catch. So let's make the description as good as possible. By the way: You converted my wording into a very concise one: "A registered editor becomes 'extendedconfirmed' automatically when their account is at least 30 days old and has been used to perform at least 500 edits (including deleted edits)" Excellent, but the Izno's version is also very good. Hard choice :-) Vikomtalk04:49, 22 April 2019 (UTC)
@Izno Oh really? Actions speak louder than words ;-) But, back to the point. I wrote: "your version is much more concise, hence much better", but I did not notice a problem. An editor with two accounts and 250 edits on each of them would be allowed to edit. On the other hand the Xaosflux's version, though very good, does not fit directly to the negative logic used in the "Overview of types of protection". So, how about: "Extended confirmed protection, also known as 30/500 protection, prevents editing by an user if their account has been registered less than 30 days or has been used to perform less than 500 edits on the English Wikipedia."? Notice that the phrase "including deleted edits" is essentially unnecessary here. Any 499 edits will be too less. However, if a user makes 500 or more edits, they will probably have doubts. Vikomtalk17:47, 24 April 2019 (UTC)
Green padlock missing on move-protected article pages
I have noticed that the green padlocks on move-protected article pages are absent. Prior to redesign of padlocks, a green padlock appears on move-protected pages, including articles. Should the green padlocks on move-protected article pages be restored? —Jencie Nasino (talk) 00:49, 6 August 2019 (UTC)
Language versions of Wikipedia that use extended confirmed protection
Is there a list of language versions of Wikipedia that use extended confirmed protection? As of August 2019, not all language versions of Wikipedia have extended confirmed protection. The Spanish Wikipedia, for example, has no extended confirmed protection; the French Wikipedia, on the other hand, has extended confirmed protection—it is known as semi-protection étendue (“extended semi-protection”) in French. By the way, is English Wikipedia the pioneer of extended confirmed protection? —Jencie Nasino (talk) 00:49, 6 August 2019 (UTC)
@Jencie Nasino: the types of editing restriction vary across projects, and even the ones that use 'extendedconfirmed' have different thresholds. From a technical perceptive, frwiki doesn't actually use 'extendedconfirmed' at all, they use 'editextendedsemiprotected' - which is a permission they bundle with "autopatrol". — xaosfluxTalk01:06, 6 August 2019 (UTC)
Extended Confirmed Move Protection
Is it possible to have extended confirmed move protection? If so, it might be in order to reword the move protection section. -- Dolotta (talk) 15:56, 14 August 2019 (UTC)
@Dolotta:yes. Most pages with an eprot edit protection also have eprot move protection. Move protection may also be configured distinctly with eprot as far as the configuration is concerned. — xaosfluxTalk17:34, 14 August 2019 (UTC)
month dependence
In a user talk page, discussion about seasonal dependence of vandalism gave me the idea that seasonal (maybe by month, or day of the year range) could be useful. I assume, but don't actually know, that it would not be hard to add to the protection system if it seemed useful. It would also be useful to know how seasonal some vandals actually are. Gah4 (talk) 08:02, 23 August 2019 (UTC)
Currently, we are missing requirements for admins to clearly indicate why ECP was applied in their rationale (some even have no rationale listed whatsoever and others' descriptions are vague or clearly lacking). Lastly, some admins are applying ECP as a FIRST resort when no other methods of mitigation or protection have been tried.
I propose the following additions to policy regarding ECP to stop this from happening or provide clear recourse if it fails... Buffs (talk) 18:01, 11 September 2019 (UTC)
ECP was authorized for use by the community where semi does not work on any page. Please take a minute to review the section of interest again. --Izno (talk) 18:07, 11 September 2019 (UTC)
I've read and re-read everything about a dozen times just to make sure I'm reading it properly. I guess I got hung up on some of the discussion at ArbCom. Like I said, it at least seemed implied. I've removed that line...striking it out made it difficult to read, so I blanked it. Buffs (talk) 19:38, 11 September 2019 (UTC)
Current phrasing of the second paragraph
Where semi-protection has proven to be ineffective, administrators may use extended confirmed protection to combat disruption (such as vandalism, abusive sockpuppetry, edit wars, etc.) on any topic. Extended confirmed protection should not be used as a preemptive measure against disruption that has not yet occurred, nor should it be used to privilege extended confirmed users over unregistered users in valid content disputes on articles not covered by Arbitration Committee 30/500 rulings. Extended confirmed protection may be applied by an administrator at their discretion when creation-protecting a page.
ECP Proposed Addendum 1
(Added to the end of paragraph 2)
Administrators are required to give clear rationale as to why a page is protected under ECP and must specify what kind of disruption has occurred which they are trying to prevent in the most recent summary. Links to applicable Arbitration rulings should be present in the summary (where applicable). ECPs applied prior to <date we add this> were not explicitly required to have this information and should be updated if found to be lacking.
I think this is unnecessary as a result of the clarification above that the community has provided for ECP. Evidence for why ECP was applied should be visible in the page history (notably, previous protections). I don't see a need to call out ECP here either. --Izno (talk) 21:37, 11 September 2019 (UTC)
I'm not sure that only one type of protection should be singled out for special treatment regarding rationales. If there is a need to provide a specific written rationale on, say, the accompanying talk page, then we should consider if it would be beneficial for all forms of protection. Since extended-confirmed protected pages are listed at the administrators' noticeboard, there is an opportunity to review these protective actions in that venue. isaacl (talk) 02:10, 12 September 2019 (UTC)
Per Wikipedia:Rough_guide_to_extended_confirmed_protection#Discussion_of_an_administrator's_decision_to_ECP, there's a box set up that automatically imports the most recent. I've seen that list have as high as 30% with no rationale listed. The fact that blanks exist show that they are not being reviewed. Further obfuscating that review process is a lack of ability to clearly see the rationale(s) at a glance. This is no different than providing a terrible edit summary (or worse, a misleading one). We cannot make admins review every page that comes through, but we can make it easier to review/function via their oversight role. Likewise, it should be easier for editors to evaluate why ECP has been enacted by reading the edit summary. Buffs (talk) 16:17, 12 September 2019 (UTC)
Examples of each from the past 45 days (not exhaustive)
Without specifying this requirement, it's clear that admins aren't going to do that consistently. More importantly, it's being applied where it shouldn't be applied, IMNSHO. Buffs (talk) 16:27, 12 September 2019 (UTC)
ECP Proposed Addendum 2
(Separate paragraph after current paragraph 2)
Every time ECP is applied, we are further restricting "The Encyclopedia that everyone can edit". Unfortunately, this protection is absolutely necessary in some instance, but should be minimized to what is absolutely necessary.
This is true of all kinds of protection. Sometimes it is necessary. If there's any thought or question as to protection, it should be length and not kind. I see no reason to call ECP out here. --Izno (talk) 21:35, 11 September 2019 (UTC)
"The Encyclopedia that everyone can edit" - yes, but this protection, like all others, is designed to defend the encyclopedia against some kinds of edits that 'anyone' can make. Kudpung กุดผึ้ง (talk) 01:10, 12 September 2019 (UTC)
Rephrase first sentences of paragraph 2; add items in bold, remove items struck out
Where semi-protection has proven to be ineffective,Administrators may use extended confirmed protection to combat disruption (such as vandalism, abusive sockpuppetry, edit wars, etc.) on any topic, but only where semi-protection has proven to be ineffective. Extended confirmed protection should notnever be used as a preemptive measure against disruption that has not yet occurred, nor should it be used to privilege extended confirmed users over unregistered users in valid content disputes on articles not covered by Arbitration Committee 30/500 rulings. As such, requests to protect user pages, templates, talk pages, and pages other than articles, no matter how prominent, should be denied unless persistent disruption exists and other methods of protection have failed.
In order to emphasize that semi-protection should be tried first, I prefer keeping the clause referring to semi-protection at the start at the sentence. I'm not a fan of redundancy; I think the more words there are, the more likely readers start skimming over the details lightly, thereby missing important info. Thus I disagree with the proposed last sentence. I'm not strongly opinionated about changing "not" to "never", as I think either way, extenuating circumstances will still be taken into account. isaacl (talk) 02:02, 12 September 2019 (UTC)
I'm ok with the order you mention of the first sentence, but we need to include the word "only". I couldn't figure out how to write that without it becoming awkward, so I put it at the end where it was easier. If you can think of a way, I'm all ears. Buffs (talk) 16:21, 12 September 2019 (UTC)
While I see the point of ECP, I think the edit-count limit is a bit out of step with the time requirement. Someone who reached both at the same time would have had to make 16 2/3 edits per day, whereas for semi-protection they'd have made 2.5 edits per day. That seems to very much prioritise activity and leaves loyal but occasional editors in the lurch - I don't think there'd be many people (as opposed to bots) who make the post-count criterion but not the time one.
I've been rather annoyed recently that despite having been here over twelve years and never having my good faith questioned I'm apparently not trusted to edit articles about politics anymore because I've only made a couple of hundred edits. I mean, I could make a few hundred edits to my user page and get around it, but that seems to be well into the area of "subverting the rules" and it shouldn't be something people are incentivised to do.
I think that either the time limit should be increased (if you really want to be sure they're good people, although I think in that case there are too many articles on ECP) or the edit-count limit should be decreased - they're just not proportionate and there's little point in even having the time requirement if it's so tiny compared to the edit-count one. Whether it's intended as such or not, it tends to come across as rather an affront to be told you can't edit something and this should be minimised when unnecessary. Magic9mushroom (talk) 07:37, 22 October 2019 (UTC)
These were arbitrarily selected and will not be changing without an amendment request there at WP:ARCA. If you think there are specific articles which should not be protected (some are required, again, per previous arbitration), you may request lower protection at WP:RFPP. My recommendation is just to get above 500 edits. ;) --Izno (talk) 21:25, 22 October 2019 (UTC)
When to use preemptive restrictions on new article titles
In a recent discussion, WP:SALT came up in the context of preemptively blocking a new article title - it instructs admins to use the Title Blacklist system for this rather than protection (making it clear that, unlike other forms of protection, preemptive salting is something we do), but provides no guidelines on when to do so or what that is for. One other thing that came up is that preemptively blocking alternative titles using protection is common, accepted practice. I don't think we need a huge amount on this, but perhaps there should be a sentence or two discussing what the Title Blacklist is for and giving guidelines for when preemptively blocking a new article title is appropriate? Additionally, should the instruction to use the title blacklist system be a requirement (ie. always use that, never use protection that way), or a suggestion? My assumption would be that it should be worded as a suggestion, since protection clearly is used that way, and since we have better systems to handle protection, eg. it's more obvious to users where they would go if they want to request that such a page be unprotected. The main advantage to the Title Blacklist system is regex's versatility and breadth, which is not always required. --Aquillion (talk) 07:30, 11 November 2019 (UTC)
Move the "Vandalism" subsection?
Hi all, I'm wondering if the vandalism subsection should be moved elsewhere on the page (perhaps a top-level section about "when to apply protection" before the list of protection types). It's a fairly general guideline since the points it makes apply to all types of protection, so I don't think it really fits under the full-protection section. Thoughts? creffett (talk) 00:44, 14 December 2019 (UTC)
indefinitely link
currently the indefinitely link just points to a disambiguation page so perhaps it should be removed or made to point to the Wiktionary definition here. any thoughts on the link? --Serprinss (talk) 03:05, 22 January 2020 (UTC)
If a page is a guideline, shouldn't it be protected as "pending" at least, by default?
Not sure if this is the right venue, please help triage, thank you!
So if an article is a Wikipedia guideline, shouldn't it be protected as "pending" at least, by default? Because a guideline reflects the current status of a consensus. Just like a MR or AfD's closure, a guideline shall be protected by default, shouldn't it? xinbenlvTalk, Remember to "ping" me04:14, 11 February 2020 (UTC)
@Xinbenlv: There's comparatively few vandalism attempts made to guideline pages, and quite a lot of BOLD edits that get made to try and clarify something (as a guideline is just a descriptive summary of the Community consensus). Obviously most of those edits are made by EC users, but I think it's viewed that the threat value is relatively low. The Community has declined pre-emptive protection in way higher risk cases - templates are functionally the only thing where it's exercised. Nosebagbear (talk) 14:22, 12 February 2020 (UTC)
Rhyme and reason for length of temporary semi-protection
On the article for Marvin Heemeyer, the protection log shows some odd variability in protection lengths. February 2018 for 4 days, December 2019 for a week, later December 2019 for two weeks, January 2020 for 2 days, later January 2020 for another 2 days, still later January 2020 for a month, February 2020 for a day, and most recently March 2020 for a day. The obvious uptick is due to the release of a documentary about the article subject (the notorious Killdozer rampage perpetrator) and IP editors subsequently trying to insert "hero" into the article. (To forestall questions: yes, it is vandalism, or at least significant disruption, to twist one man's spoiled-child temper-tantrum writ large into heroics.) My questions are:
Is there a reason for the protection lengths varying so widely? If there were significant breaks in the history of the disruption I could see "resetting" the protection lengths back down to 1 day but there are no such breaks here. I would expect that the protection lengths to get steadily longer in such a situation but I'm obviously missing something.
Do admins generally look at the log to decide on temporary protection lengths?
Could an edit filter work better for this specific problem?
Would indefinite semi-protection be appropriate to request the next time I send this to RfPP?
Is there a functional bot updating the protection icons for protected pages?
As seen here, it looks like there are instances in which protected pages are not having their icon updated so that readers/editors are aware of their protection status (in the example above, a log change in 2018 went unnoticed until a manual icon addition just recently). Is there a bot that did this at some point, and if so has it stopped working? Sdkb (talk) 21:04, 27 March 2020 (UTC)
Protected template that aren't "highly visible" anymore
In early 2018, an RfC decided that templates with at least around 200-250 transclusions should be permanently semi-protected. At around the same time, all templates with over 200 transclusions were permanently protected. The thing is, the number of transclusions is not a permanent feature of a template, and the numbers can go up or down. My concern is not so much about previously little used templates that are now above the threshold (I believe there are active admins dealing with that), as it is about formerly heavily used templates that have now fallen out of favour and whose transclusions will be below the mark. Is there any way to track them down and possibly unprotect them? Of course, the situation is somewhat complicated by the fact that it's not always clear from the log whether the protection was applied solely based on transclusion count, or whether there might have been other factors affecting visibility, such use on a very prominent article. – Uanfala (talk)17:13, 5 May 2020 (UTC)
Tony added the recent new topic sphere that can come under ECP preemptively, but did so in a way that adds to what I see as a bit of a crusty-organized section (for obvious reasons). Today, I nearly took a shot at reorganizing it so the section is a bit less PROSELINE and a bit more "hit me with what I need to know" (to wit, that's not the dates among other stuff) and then thought it might be better to inquire on the talk page because I found my organization-fu a bit lackluster today.
Would anyone be opposed to a list or other decrufting? Some of the material there applies to this policy as a whole (I understand why it's there), and the dates don't help actually identifying where/when/why I can use the protection level. --Izno (talk) 22:09, 4 June 2020 (UTC)
RFC: Changing protection icons
I have noticed some of the icons have icons instead of a letter. So, why not change the letters to icons too? –User45654116:20, 17 July 2020 (UTC)
The proposed new icons are (they may require tweaking):
@GeneralNotability: They are more descriptive than a letter and can be used on multiple language Wikimedia wikis. For example, the "WMF logo" on office protection makes people know that this page was "protected by the Wikimedia Foundation". –User45654116:39, 17 July 2020 (UTC)
No comment if this is needed in general, but if so for interface prot, may be better to go with some code looking symbols instead of the wikilink one, /* perhaps. — xaosfluxTalk16:42, 17 July 2020 (UTC)
This sort of thing comes up every 6-12 months - before you choose the colour to paint the bikeshed, first establish that the bikeshed needs painting. Or, is there a demonstrable issue with the current set - are people saying that they are finding them hard to understand? If not, we're in WP:IDONTLIKEIT territory, which is always a dead end. --Redrose64 🌹 (talk) 20:57, 17 July 2020 (UTC)
I like the new "Office protection" lock, I strongly dislike the new "Extended confirmed protection" lock because it's hostile to colorblind users (identical to "Semi protection" except for color), and I weakly dislike the other changes, just because they're "meh" in general. Also, a random suggestion: for "Interface protection", perhaps use the MediaWiki logo instead of an opening wikilink. Jackmcbarn (talk) 04:34, 10 August 2020 (UTC)
How about, for Extended confirmed, if the person has a little crown on his head or other badge of office? EEng04:46, 10 August 2020 (UTC)
I like only the office protected icon, since extended confirmed and autoconfirmed are the same to colorblinds, and full protection does not prohibit all editing. Also, I strongly dislike the interface and template protected icons, since this means that transclusions and links are protected. Anyway, I have thought up of adding a mediawiki icon to the interface protected, and have the creation protection changed to just a simple white paper. ThesenatorO5-2argue with me11:48, 15 August 2020 (UTC)
I like the new template and full protection icons. The office one makes sense too, however it might need little more padding inside the shackle. –Majavahtalk · edits20:38, 15 August 2020 (UTC)
I agree that the current system needs change to make it more accessible to readers, but I don't think the proposed changes go far enough. The four icons readers are most likely to encounter in mainspace are pending changes, semi, extended-confirmed, and full. However, the design of these has no solid hierarchy: it's impossible for a reading to tell without clicking through whether e.g. pending changes is lower or higher than extended-confirmed. This needs to be fixed by any potential redesign, and the proposal doesn't do so. {{u|Sdkb}}talk21:06, 7 September 2020 (UTC)
I like the office one in general (it could do with some tidying up perhaps, more distance off the bottom?). I explicitly dislike the change to extended-confirmed. Full and TE protections will take some adjustment at minimum, and overall I'm indifferent about both. Agree to changing your proposed IA one per xaos. Surprised you didn't change move protection, as that's always been one I never quite vibed with for some reason. Basically, Jack sums up my views. Full/TE could do with a change probably, but the proposed ones aren't quite there yet. ProcrastinatingReader (talk) 01:26, 8 September 2020 (UTC)
Support I like the designs better than the ones with just a letter. A letter is fine, but a {{ or [[ might be better. It's a minor change, but it should be a welcome one. Arsonxists (talk) 18:52, 14 September 2020 (UTC)
@ThesenatorO5-2: there is an entire discussion open just above this one on changing icons, why are you starting yet another RfC on only a subset of that one instead of just commenting there? — xaosfluxTalk20:08, 15 August 2020 (UTC)
If I saw this lock and had to guess which protection level it represented, I'd guess template protection. IMO, that makes it a poor choice for interface protection. (Perhaps angle brackets instead?) Jackmcbarn (talk) 23:18, 15 August 2020 (UTC)
I'm turning off the RfC so we can have a local discussion first. This isn't going to be a very clean outcome if we're still changing the proposal. --Bsherr (talk) 14:31, 18 August 2020 (UTC)
The issue is that these icons mostly are used at size 20px. Thus: . The white symbol on colored field is intended to provide legibility at that small size. The detail of this proposed icon is simply lost at that size, and the similarity of the colored field to the icon colors exacerbates the issue. --Bsherr (talk) 15:06, 18 August 2020 (UTC)
@Bsherr: ok thanks - this entire l2 section is going to where, I'm upmerging it in to the already open discussion above about icon redesigns. — xaosfluxTalk18:47, 18 August 2020 (UTC)
The image has an invalid license claim. Its file description page claims that it was not previously published, that its author is ThesenatorO5-2, and that the license is {{cc-zero}}. All of these are disprovable: the image is clearly a composite of three, including a blank padlock similar to e.g. File:Pending-protection-shackle-no-text.svg and an eye similar to e.g. File:FlaggedRevs-2-1.svg, but there is no acknowledgement of the sources of these two components nor of their authors. Far worse is the inclusion of the Wikipedia puzzle ball File:Wikipedia-logo-v2.svg, which is not just the property of the Wikimedia Foundation but is also licensed CC BY-SA 3.0, so the use of any other license for a composite image including this logo, without acknowledging the original author in any way, is a violation of the licensing terms.
"Move protected pages, or more technically, fully move-protected pages, cannot be moved to a new title except by an administrator." "Upload protected files, or more technically, fully upload-protected files, cannot be replaced with new versions except by an administrator." Are these phrases true? For example, Special:Log/protect includes "[Move=Require autoconfirmed or confirmed access]". --NGC 54 (talk | contribs) 14:34, 15 September 2020 (UTC)
As I have pointed out several times before (most recently at Module talk:Protection banner#Move-protected), there are five levels of protection for every protectable action. A page that is move- or upload-protected need not be fully protected for that action; they might be template- or EC-protected, but it is pointless setting either of these to semi-protected. --Redrose64 🌹 (talk) 18:33, 15 September 2020 (UTC)
Extended Confirmed Protection
So I checked this in August, and it said it had to be at least 100 edits. Then a little bit later, I came back and it said “at least 400 edits”. Now in the Extended Confirmed Section it states that we need at least 500 edits to become an Extended Confirmed User. I tried looking in the edit history but it didn’t show any edits from 400 - 500. Is it a suppressed edit or is it something else? EpicRice (talk) 05:25, 17 September 2020 (UTC)
The threshold has been 500 edits ever since the protection level was first implemented, hence the moniker 30/500. Where exactly did you see the figures of 100 and 400 mentioned? --Redrose64 🌹 (talk) 09:28, 17 September 2020 (UTC)
Stated: “Granted automatically to registered users with at least 30 days tenure and 100 edits.” and “Granted automatically to registered users with at least 30 days tenure and 400 edits.”EpicRice (talk) 02:38, 18 September 2020 (UTC)
@EpicRice: it has been 30/500 the entire time, if you can point to a specific revision that had the wrong text we can probably see what happened? If you see this, also look at the revision history and see if it was fixed after someone just vandalized the description. — xaosfluxTalk02:40, 18 September 2020 (UTC)
Done Mass Message sent. — xaosflux Talk 17:48, 23 September 2016 (UTC)
Resolved
―Mandruss ☎ 11:24, 28 March 2017 (UTC)
Fixed in the edit notice at Template:Editnotices/Page/Wikipedia talk:Protection policy. - Evad37 [talk] 04:45, 10 April 2017 (UTC)
Not done as a failed proposal ProgrammingGeek talktome 20:14, 17 April 2017 (UTC)
Hot pink
Yellow
Yellow 2
Mint
Turquoise
Violet
Red-silver
Skyblue-Hot pink
Red-yellow
Tiger (pink)
Tiger
Camouflage
Neon
Fur
Zebra
Zebra 2
Is there any reason Page Movers can't move pages under move protection? I understand that some pages like Facebook will highly likely never need to be moved, but for those being targetted by vandalism, it'd still be useful for us to be able to in the event a genuine reason / concensus is resolved in the meantime. — IVORK Discuss 23:16, 13 August 2017 (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. — IVORK Discuss 22:20, 10 April 2018 (UTC)
∰Bellezzasolo✡ Discuss 11:01, 13 November 2018 (UTC)
You are invited to join the discussion at Wikipedia:Village pump (idea lab)/Archive 28#Merging pending changes reviewer with other user groups. Mz7 (talk) 00:13, 18 December 2018 (UTC)
Ed talk! 17:04, 8 September 2020 (UTC)
ThesenatorO5-2argue with me 12:05, 15 August 2020 (UTC)
— Preceding unsigned comment added by ThesenatorO5-2 (talk • contribs) 01:27, 17 August 2020 (UTC)
. The white symbol on colored field is intended to provide legibility at that small size. The detail of this proposed icon is simply lost at that size, and the similarity of the colored field to the icon colors exacerbates the issue. --Bsherr (talk) 15:06, 18 August 2020 (UTC)
