Wikipedia talk:PC2012/Adjwilley

Documentation of changes to policy

I have made a number of changes to the provisional policy, based on the outcome and closure of the RfC. I will document the changes here, providing rationalle for my changes. ~Adjwilley (talk) 01:15, 3 July 2012 (UTC)

Added a time period

One of the bigger concerns in the RFC was that the Pending Changes system would become severely backlogged, and some suggested that there should be an expiration time. Others were concerned that the system would create a hierarchy where a small minority (Admins and Reviewers) controlled the content of articles, while yet others feared that PC would contribute to a lack of openness, scaring away new users who didn't know whether or when their changes would be "accepted".

To address these concerns, I added a time-limit to the protected articles, after which time the edits would automatically "go live". I think that 24 hours would be a good time for most articles: it's long enough to give reviewers a look at the changes, and short enough not to scare away would-be editors. The time-limit, however, should be left as a free parameter to be chosen by the protecting admin, who might choose a shorter time period for a high-traffic, high-watched article, or a longer time period for a BLP that attracts persistant vandalism, but that few editors watch. The time limits can also be adjusted based on the length of the PC backlog.

In summary, when protecting an article with PC, an administrator will choose two times: the length of the protection period, and the time limit after which pending changes go live. ~Adjwilley (talk) 01:15, 3 July 2012 (UTC)

This is an interesting idea. However, it would require a change to the software and so far the developers haven't been very amenable. It is worth putting out there as an idea but I wouldn't have it in the draft policy at the moment. Yaris678 (talk) 17:33, 3 July 2012 (UTC)

I'm not all that familiar with the history of PC, but my impression was that the developers have been reluctant to invest time into improving PC because it was in limbo, and they didn't know if it would be a waste of their resources. I think if a consensus of editors told them "We want PC and we want it to work this way" then they would do it, and fast.

I have very little experience programming, but I don't imagine it would be very hard to have an expiration for pending changes. A simple hack solution would be to have a bot automatically accept any changes older than 24 hours. Taking that up a level would require programming changes, giving the admins an extra variable to set, (time limit=X) but a bot could still accept the changes if worse came to worse (if "current time"–"time of edit" ≥ X, then accept change.)

It would be helpful to get a developer to comment on this, giving us an idea of how difficult the change would be to make, but I would have no idea who to contact for that. ~Adjwilley (talk) 17:53, 3 July 2012 (UTC)

Yes. Doing by bot sounds like a good idea. I think it would make sense to do what we can for now with the system as it is and then get a bot up and running. If we get that far the devs my consider that we have consensus. Yaris678 (talk) 18:28, 3 July 2012 (UTC)

My understanding is that the closers of the previous RFC were in contact with the devs at various points, and that the devs will be making whatever changes we need ... as long as we only ask once. - Dank (push to talk) 21:25, 3 July 2012 (UTC)

That's the impression I got here as well. ~Adjwilley (talk) 21:47, 3 July 2012 (UTC)

Call it "go live" instead of "become visible"

This was a personal preference. I think describing the edits as "going live" is a better picture of what's happening than saying that they're becoming visible. (Are they invisible before?) ~Adjwilley (talk) 01:15, 3 July 2012 (UTC)

I agree that picking the right terminology can help. However, I think I prefer "visible" to "go live". Until approved, changes are invisible to the vast majority of Wikipedia's audience. There was a discussion of the ludicrously varied and occasionally unhelful terminology at Wikipedia talk:Pending changes/Closure#PC Terminology. Yaris678 (talk) 17:30, 3 July 2012 (UTC)

Move PC-2 down a level

I edited the Pending Changes table so that PC-2 came after Semi-protection, instead of before, in the order of increasing protection. My reasoning is thus: PC-1 makes it so everybody can edit an article, obviously placing it on a lower rung than Semi-protection, which makes it so that IP's and new-users can't edit. PC-2 makes it so that IP's and new users can edit again, however, it it also negatively affects the vast majority of registered users, which in my mind is a big deal. Semi-protection doesn't affect us, but PC-2 does, and should be used with extra caution. ~Adjwilley (talk) 01:15, 3 July 2012 (UTC)

Yep. Makes sense to me. Yaris678 (talk) 17:37, 3 July 2012 (UTC)

Add recommendations for when to protect articles

I added an extra column to the protection table, giving suggestions for when various types of protection would be appropriate. I did this mainly for myself, and I will probably remove it later on. Otherwise, somebody who has much more experience than I do in page protection should have a look at it and correct details that I undoubtedly got wrong. ~Adjwilley (talk) 01:15, 3 July 2012 (UTC)

This is a great idea. One reason why people found PC so confucing during the trial was that info about it was so dispersed. With this extra column, the table tells people a lot of what they need to know. Having the draft policy above it helps too. Contrast this to during the trial where there were at least three pages to check: WP:Pending changes, WP:Protection policy and WP:Reviewing. Yaris678 (talk) 17:12, 3 July 2012 (UTC)

I'm a little ambivalent about the change you made that specifies that PC is "not appropriate for articles with a very high edit rate". On the one hand, I really like it because it would indeed be disrupting if a PC edit held up everybody else's edits for a day. At the same time, however, logged-in users would be seeing the "invisible" version of the article anyway.

Take Barack Obama, for instance: it has a very high edit rate, but I'd imagine that we'd want it to be PC-2 with semi-protection. It's currently got Semi, but still gets a lot of vandalism. PC would not be disruptive, because there are enough people watching the article that non-constructive edits will get reverted and constructive edits will get accepted very quickly. For that article, I would recommend PC-2/semi, with an expiration time of 1 hour. ~Adjwilley (talk) 18:33, 3 July 2012 (UTC)

Barack Obama would be a bad choice for either level of PC because it would quickly accumulate lots of unreviewed and unhelpful IP edits. PC2+SP could work though... and that is perfectly fine according to the table (assuming it is borderline for full protection). The table only recommends against pure PC for high edit rate articles. No such recommendation is given for PC2+SP. Yaris678 (talk) 08:53, 4 July 2012 (UTC)

During the trial period it was felt that PC caused too many problems on high traffic or bery long articles. The long article thing might be something the devs can fix, as I recall it really, really slowed down load times. The high traffic issue is probably something we should address in the policy. Beeblebrox (talk) 01:17, 10 July 2012 (UTC)

Thanks, I agree. I think it is addressed in my current policy... There is such a recommendation at Wikipedia:PC2012/Adjwilley#Pending changes table that Yaris added, and a recommendation in the policy above that articles with high edit rates be given a shorter auto-approve time (less than 24 hours). Do you think I should have more? ~Adjwilley (talk) 01:35, 10 July 2012 (UTC)

Add explanation of how edits are reviewed

While not entirely necessary, I added a paragraph on how edits are reviewed by reviewers. When I first read about pending changes I didn't understand how they worked until I had quizzed somebody who had seen them in action. I may have gotten some details wrong, so I ask that people correct me if I did. ~Adjwilley (talk) 01:37, 3 July 2012 (UTC)

Edit notice for anons/users affected by PC

I added a sentence to the effect that anonymous and new users editing a protected article should receive a simple but clear edit notice telling them how long it will be before their edit goes live. This could be in the form of an edit notice, or a pop-up after clicking "Submit", with a link to the edit history of the article. ~Adjwilley (talk) 03:04, 3 July 2012 (UTC)

Makes sense... but will also require the developers to do something. Yaris678 (talk) 17:34, 3 July 2012 (UTC)

Some other changes

I don't think these are mentioned above but I wanted to comment on them:

• Deeper colours in the table.
  • I don't like this. Less visually pleasing and harder to read.
• No asterisk for changes go live immediately.
  • This is now explained in brackets in one cell of the table, but it actually applies to many cells, which is why it was done the way it was. Bring back the asterisk.

Yaris678 (talk) 18:24, 3 July 2012 (UTC)

• I will lighten the colors back up, but I like the colors themselves a little better (red, green, yellow vs. brown) because it gives me a little better idea of what's happening.
• I took the asterisk out because as far as I could tell it only applied to the one cell. If an administrator or reviewer makes an edit to an article with pending changes, their version automatically becomes the "accepted" version. Any pending changes will be accepted, unless the reviewer's edit is to revert the changes. That is my understanding at least. ~Adjwilley (talk) 18:38, 3 July 2012 (UTC)
  • During the the trial, if I as a reviewer edit an article with changes pending they did not automatically get approved. However, you are half right. Since then there has been a modification so that a reviewer can tick a box to accept their change and all previous changes. If they don't tick the box they are shown the full diff when they save and it is implied that they should review it. See Wikipedia:Pending changes/Testing/1, which currently has two pending changes. One by an IP and one by a reviewer. I think this info could be displayed quite well on the table using asterisks. Yaris678 (talk) 08:44, 4 July 2012 (UTC)
  • Added info to the table with asterisks. Yaris678 (talk) 12:56, 4 July 2012 (UTC)

Moved reviewer paragraph to footnote

I moved the paragraph explaining what a reviewer was ("A reviewer is a user with a similar level of trust to a rollbacker...") to a footnote. It didn't have much to do with the policy, and seemed to be interrupting the flow. Most people know what a reviewer is, and if they don't they can click on the link or look at the footnote. ~Adjwilley (talk) 23:30, 3 July 2012 (UTC)

I have also added other footnotes, to keep the policy concise while still leaving more detail if it is wanted. ~Adjwilley (talk) 23:44, 3 July 2012 (UTC)

On second thought, I decided against footnotes, since most policy articles don't have them. ~Adjwilley (talk) 23:52, 3 July 2012 (UTC)

Admins should watch backlog

The following was added to the provisional policy:

Administrators should try to keep the number of pending-changes-protected pages to a level that is manageable by the active reviewers. As a rule of thumb, if edits are frequently waiting longer than an hour to be reviewed administrators should not apply PC protection to new pages and should instead look to reduce the number of pages under this type of protection.

~Adjwilley (talk) 17:34, 4 July 2012 (UTC)

Discussion

So some people think the devs will be persuadable... I would still prefer to come up with something that will survive if they are not persuadable. How about adding something to the "Implementation" section along the lines of "Administrators should try to keep the number of PC protected pages to a level that is manageable by the active reviewers. As a rule of thumb, if edits are frequently waiting longer than an hour to be reviewed administrators should not apply PC protection to new pages and should instead look to reduce the number of pages under this type of protection."... in fact... whether or not some automatic limit is in there, I think this provision makes sense.... if we end up with a lot of edits being auto approved it brings the whole thing into disrepute. Yaris678 (talk) 12:30, 4 July 2012 (UTC)

I have added the above text, about keeping it manageble, to the proposed policy. Yaris678 (talk) 12:34, 4 July 2012 (UTC)

The above text seems fine. I'm not certain that it would work in practice, but if it doesn't then worst case we'll have a bot do it at the 24 hour mark.

As a side note, I'm not sure how much you've kept up on the recent RfC that closed a few weeks ago. They did a 3 or 4 admin closure, in which they decided that Pending changes would come back on December 1, 2012, whether we like it or not. The consensus was for a provisional draft policy that had been written up, however there was a strong opposition to that policy, and the closers recommended that people modify the policy to see if they could come up with something better. Basically we get until November 1 to agree upon a policy, which gives the devs a month to make the changes required by the policy. If this policy gets community consensus over the current draft policy, the devs will do whatever it takes to implement it. ~Adjwilley (talk) 17:31, 4 July 2012 (UTC)

I don't actually think this will work in practice, but it's a nice idea, and we should probably have a vote on it anyway. I think that even if it doesn't work, the 24 hour time limit will be enough of a failsafe to ensure that the queue doesn't exceed a certain length. ~Adjwilley (talk) 20:36, 9 July 2012 (UTC)

I appreciate that this idea is intended to address the fear that PC will cause massive backlogs, but one hour is not really reasonable. I would suggest we start with 24 hours assuming this idea is approved, and iff backlogs occur this functionality should be able to be modified to a shorter time frame without having to go back and ask the devs every time. That way we retain the ability to be flexible and find out what works and what doesn't. Maybe, if the devs are feeling really creative, they can find a way for the tool to examine the queue itself and determine if there are sufficient backlogs to merit reducing the timeframe. Beeblebrox (talk) 01:12, 10 July 2012 (UTC).

I've just refactored the talk page a bit, because it seemed like two ideas were getting conflated. This section is meant to deal with the 1 hour recommended review rate for admins, while the section at the top of the page is meant for the 24 hour time period after which pending changes are automatically accepted. If you were talking about the automatic acceptance, I think that "time period" should be left as a free parameter to be chosen by the admin who protects the article, and I agree that the default should be 24 hours. If you're talking about the 1-hour time period here, I agree with you that it's not reasonable, but it's just a recommendation, and not something that the devs would have to deal with. ~Adjwilley (talk) 01:27, 10 July 2012 (UTC)

Beeblebrox, I'm not sure but I think you might be getting slightly confused between the two different time periods being discussed. These are:

1. The time at which a page should automatically be approved. This would need to be implemented in software, either through MediaWiki or through a bot.
2. The time at which admins should try to keep most reviewing periods below. They would do this purely by modifying the number of articles under pending changes protection. It is only a rule of thumb and admins should try to keep this period from being exceeded frequently, so occasional long reviews are fine.

These things could be implemented independently. Neither requires the other.

However, if they are both implemented I think the second period should be significantly shorter than the first, to avoid having a lot of pages being auto approved.

Yaris678 (talk) 08:21, 10 July 2012 (UTC)

Page move

I now see there are a huge number of subpages of WP:Pending changes .... would it be okay to move your project page to WP:Pending changes/2012/Adjwilley? - Dank (push to talk) 14:29, 5 July 2012 (UTC)

Sure. Move it wherever you like. I'm not picky. ~Adjwilley (talk) 16:02, 5 July 2012 (UTC)

First mini-vote (automatically accept changes after some time)

This section is a draft for the first mini-vote and will change from time to time

One of the major concerns in the 2012 Pending changes RfC was that the Pending Changes queue would become severely backlogged, and it was suggested that there should be an expiration time, after which pending changes would be automatically accepted. Another concern was that Pending Changes would contribute to a lack of openness, scaring away new users who didn't know whether or when their changes would ever be "accepted". Based on these concerns, the following addition to the the provisional policy is proposed:

Edits to articles with pending changes protection will "go live" automatically after a specified time period or after they have been approved by a reviewer (whichever comes first). The time period is a parameter that will be chosen by the administrator who protects the article. The time might range from a few hours to several days, depending on the article, but a period of 24 hours is recommended. Shorter time periods may be used for articles that have a high edit rate and many watchers. Longer time periods may be used for articles with few watchers.

To address the concern of anonymous/new users not knowing when their changes will be accepted, users editing a protected article should receive a simple but clear edit notice telling them how long it will be before their edit goes live. The recommended period of 24 hours was chosen because it's long enough to give reviewers a chance to look at the changes, but short enough not to scare away would-be editors. In practice, the vast majority of edits should be accepted or reverted long before the 24 hour mark.

It is reasonably assumed that the developers will be willing and able to make the necessary changes to the software before the implementation of Pending Changes in December.

Discussion

• The statement ends with the assertion that most of the time edits will be reviewed before the time frame has expired. This is what has bugged me about his idea from the beginning. I appreciate this is a creative response to a legitimate concern expressed during some of the previous discussions, but the thing is we don't actually know that there will be unmanageable backlogs. I think I would like to see this strictly as an option, to be used only if it is demonstrably necessary, not as standard operating procedure. Everything gets backlogged occasionally, if we are only having intermittent problems with PC backlogs we probably shouldn't have a compulsory feature that could cause unacceptable edits to go live before review. But, if it is there and available to us we can implement it as soon as soon as serious backlogs become evident. Beeblebrox (talk) 03:28, 11 July 2012 (UTC)

Thanks. It actually says that the majority of edits should be reviewed before the time period expires. If they aren't, that means that something's wrong. Either we need more reviewers or fewer protected articles. The risk of letting inappropriate edits slip through should be a motivation to admins and reviewers to keep the backlogs small. That said, even if there is a backlog, I don't think very many unacceptable edits will slip through. ClueBot will catch the worst, and users will catch and revert the others, the same as they do now. (You don't need reviewer rights to revert edits, even on pending changes articles.) The main difference is that the vandalism won't get aired for the 5 minutes before Cluebot reverts it or the couple of hours before users running STiki revert it. I'm rambling now. Sorry. ~Adjwilley (talk) 23:03, 11 July 2012 (UTC)

• I have suggested elsewhere that we ramp up pending changes slowly to see where the backlog point is - and use that as a marker for the approx number of pages we can use the tool on beneficially - This would be a good informative experiment. Start with five hundred and keep adding a hundred until unmanageable backlogs appeared. - Personally I didn't see from the trial that the number of pages we used it on gave any backlog problems at all and I don't see we are going to implement it on more pages than the few thousand previously used for the foreseeable future anyways. I wouldn't have any objection to this though (it seems like a good idea - although reviewing shouldn't take and didn't take in the trial, more than 24 hours imo - and if implemented I would like to see the automatically accepted edits in a cat so that interested users could look through them at some point - I also don't think the number of watchers makes any difference to the time limit either - the Pending changes watchlist was a focus point in the trial so that page has the same number of watchers (a focus point for reviewers) so the actual article watchlist number isn't so important - Youreallycan 05:30, 11 July 2012 (UTC)

I agree with ramping up slowly, and that would be another good idea to run in a separate mini-vote. I also agree that a special page showing auto-accepted pending changes would be useful. For instance, if the changes were automatically accepted by a bot, these pages would all be in the bot's edit history. The idea with the watchers was that pending changes show up bright on peoples' watchlists, so a page with several watchers is bound to have a few interested reviewers watching it, who will accept/reject the edits long before they reach the end of the queue. And inappropriate edits will be reverted quickly by other users, and the reverts shouldn't have to wait a whole 24 hours (in the worst-case scenario) before being approved. Lastly, these pages with huge numbers of watchers will probably have a higher edit rate, and it would be disruptive to bog down the normal editing process for a few hours every time an IP makes an edit.

BTW: I just came up with a crazy idea while I was writing the paragraph above. What if the edits were approved/rejected by a bot at the time limit, and what if that bot were smart like ClueBot, who currently has like a 0.01% false positive rate for vandalism? Then the likelyhood of bad edits slipping through would be even lower. I'm just thinking out loud here, and that would probably take way to much work for the developers.

One last thought. The edit notice for anon/new users editing protected articles could read something like, "You are editing an article that has been protected because of persistent vandalism. Your edit will be reviewed within 24 hours, and will go live immediately after it is reviewed. To see whether your edit has been reviewed or not, please check the edit history.

Done rambling now. Thanks for the input. ~Adjwilley (talk) 23:03, 11 July 2012 (UTC)

I would like to see cluebot active on pages that are pending protected - searching through the pending changes and rejecting them as it usually does for content that is actually added to articles - treating the desired edit as it would an actual edit - Something regarding the edit notice - as pages are not guaranteed to be pending protected purely due to WP:vandalism , I would suggest having it say something more like , You are editing an article that has been WP:Pending protected, your desired edit will not be published until it has been reviewed and accepted. Thank you for your contribution to En.Wikipedia - Youreallycan 05:13, 12 July 2012 (UTC)

Good point about the reason. It would be nice if admins had a drop-down menu on their block (button? not sure how it works) where they could choose a reason: edit warring, vandalism, spam, etc. I think that ClueBot should absolutely be able to revert pending changes. As for the edit notice, I do want the IP/new user to know the absolute maximum time (24 hrs) before their edit is reviewed...otherwise they are left to wonder what the timeframe is...an hour, day, week, month? ~Adjwilley (talk) 15:08, 12 July 2012 (UTC)

• I agree with the concept, and am open-minded about the desired time limit, but could only contemplate this if there were some sort of ramp-up process. Delays of more than one hour (I'm open-minded on the timeframe) should be considered unacceptable: articles with such edits should go into a backlog category, and if that backlog is consistently above a predetermined limit, PC should no longer be added to new articles until the situation is under control. Perhaps a bot could be configured to enforce that (reverting new additions of PC and informing the admin that PC's use is currently restricted?).

  But automatically accepting edits should be the absolute last resort, considered only if all of the previous measures fail to curb the backlog. If we're stretched to the extent that edits are taking more than an hour to process, the problem is overuse of PC, and the true solution is dealing with that. Unrestricted use of PC when we're already at breaking point would render the whole system a useless, false sense of security. —WFC— 13:53, 12 July 2012 (UTC)

  • By the way, wouldn't this be a major technical change to PC? I thought the devs weren't working on it until we start using it? —WFC— 13:54, 12 July 2012 (UTC)
• Support the general idea of "go live automatically"; oppose an adjustable timeframe as unnecessarily complex and confusing for editors, reviewers, and admins. And 24 hours seems like way too short an interval. Rivertorch (talk) 06:15, 13 July 2012 (UTC)
  • @As per User:Rivertorch's support for his position of -"go live automatically"- please explain or link to discussion of this desired position - thanks -— Preceding unsigned comment added by Youreallycan (talk • contribs) 06:56, 13 July 2012 (UTC)
    • I'm not quite sure whether you're asking me. If so, I'm not sure how to explain. I think it would unworkable to have edits pending indefinitely, and the alternative to automatic acceptance—automatic rejection—would be deeply problematic. Rivertorch (talk) 08:41, 13 July 2012 (UTC)
      • Ah thanks. automatic rejection would be a totally unacceptable/ fail position imo also. I could support an accept automatically if not reviewed in 24 hours position - but like Yaris, as a last resort and if edits are taking longer than that to review then that would be a reflection of another problem (to many articles under the protection/to few editors willing to/working as reviewers ) that would require dealing with in another/better way than auto accepting. - Just to note - In the trrial with the few thousand articles pending protected it did not happen to my knowledge that edits remained not reviewed for anywhere close to 24 hours. Youreallycan 15:52, 13 July 2012 (UTC)
        • Thanks for all the comments. I tend to agree that this is more of a last-resort-type idea, and I certainly believe that it should be applied in parallel to other changes: ramping up and watching backlog included. When I present this for the "mini-vote" (whenever that happens) I'll see if I can make a note to the effect that this is not a standalone fix, and shouldn't be necessary if the other policies work as desired. ~Adjwilley (talk) 17:28, 13 July 2012 (UTC)
• I think I mostly agree with WFC on this one. I think it is better that the policy should say that the number of pages under PC protection should be manageable by the reviewers. Autoaccepting could work as a last resort but I would rather we weren't in the position where it was necessary. As stated above, I like the following wording: "Administrators should try to keep the number of pending-changes-protected pages to a level that is manageable by the active reviewers. As a rule of thumb, if edits are frequently waiting longer than an hour to be reviewed administrators should not apply PC protection to new pages and should instead look to reduce the number of pages under this type of protection." If we add in a "ramp it up slowly" clause then we should be sorted. Yaris678 (talk) 13:37, 13 July 2012 (UTC)

We had over three thousand articles on pending protections previously and there were little to no backlogs - (I think I have a link to the articles that were on pending that were replaced to indef semi protection when the protection was removed) one users opinion of ramp it up slowly and another's are totally different - if we add a thousand at a time we will find the point were there is an issue - Youreallycan 22:07, 17 July 2012 (UTC)

When I mentioned a "ramp-up process", I was referring to the action we take if PC starts to get backlogged. Talking purely about article numbers is also a trap I'd prefer to avoid. 100,000 BLPs which average an edit a month may not cause a problem. 1,000 contentious, topical, high-traffic articles may reduce the whole system to a crawl. —WFC— 22:22, 18 July 2012 (UTC)

1,000 contentious, topical, high-traffic articles - no one will be adding pendingot such a bunch of articles - that is clear from prior trial experiance. - PC - Should not get unduly backlogged (it did not get over twenty four hours in the trial) The protection could be applied till wait times become excessive - we can easily find the point - personally I don't see any need to specify anything about this - its enough to state in the guideline - Waiting times for reviews should not become unduly excessive - times have been discussed a bit - but twenty four to thirty six hours would not be excessive limits imo - and if those limits are easily obtained then we could easily reduce then as and when possible - simple and flexible guidelines are the best for a developing tool - Youreallycan 23:22, 18 July 2012 (UTC)

Second "mini-RFC" (changes to WP:Pending changes/Protection level table)

I have made several changes to the Protection level table that was used in the 2012 RfC and is currently being used at WP:Pending changes.

Current and Proposed versions of the Table

Current version Interaction of Wikipedia user groups and page protection levels   Unregistered or newly registered Confirmed or autoconfirmed Extended confirmed Template editor Admin Interface admin Appropriate for (See also: Wikipedia:Protection policy) No protection Normal editing The vast majority of pages. This is the default protection level. Pending changes All users can edit Edits by unregistered or new editors (and any subsequent edits by anyone) are hidden from readers who are not logged in, until reviewed by a pending changes reviewer or admin. Logged-in editors see all edits, whether accepted or not. Infrequently edited pages with high levels of vandalism, BLP violations, edit-warring, or other disruption from unregistered and new users. Semi Cannot edit Normal editing Pages that have been persistently vandalized by anonymous and registered users. Some highly visible templates and modules. Extended confirmed Cannot edit Normal editing* Specific topic areas authorized by ArbCom, pages where semi-protection has failed, or high-risk templates where template protection would be too restrictive. Template Cannot edit Normal editing High-risk or very-frequently used templates and modules. Some high-risk pages outside of template space. Full Cannot edit Normal editing Pages with persistent disruption from extended confirmed accounts. Critical templates and modules. Interface Cannot edit Normal editing Scripts, stylesheets, and similar objects central to operation of the site or that are in other editors' user spaces. * In order to edit through extended confirmed protection, a template editor must also be extended confirmed, but in practice this is almost always the case. Other modes of protection: Create protection Move protection Upload protection Office protection Cascade protection Proposed version Wikipedia users, page protections, and page edits   Unregistered, New Autoconfirmed, Confirmed Reviewer Administrator Appropriate for No protection can edit; changes go live immediately (no acceptance required) The vast majority of articles Pending-changes level 1 protection can edit; changes will go live after a specified time period or after being accepted by a reviewer; can edit; changes go live immediately (if no previous pending changes remain to be accepted) can edit; changes go live immediately*; can accept pending changes Articles that are borderline for semi-protection. Not recommended for articles with a very high edit rate Semi-protection cannot edit can edit; changes go live immediately; no acceptance required Articles experiencing high levels of vandalism or edit warring from unregistered and new users Pending-changes level 2 protection can edit; changes will go live after a specified time period or after being accepted by a reviewer; can edit; changes go live immediately*; can accept pending changes Articles that experience high levels of vandalism or edit warring from (auto)confirmed accounts such as some controversial BLP articles. Not recommended for articles with a very high edit rate Pending-changes level 2 with Semi-protection cannot edit can edit; changes will go live after a specified time period or after being accepted by a reviewer; can edit; changes go live immediately*; can accept pending changes Articles that experience high levels of vandalism from (auto)confirmed accounts such that they are borderline for full protection. Full protection cannot edit can edit; changes go live immediately Articles experiencing persistent vandalism or edit warring from (auto)confirmed accounts and for important templates *When editing articles with un-reviewed pending changes, Administrators and Reviewers are prompted to review the pending changes before saving their edit.

Summary of changes

• I moved Pending Changes level 2 (PC2) down a level so that it comes after Semi-protection, instead of before, in the order of increasing protection. Semi-protection doesn't affect registered users, but PC-2 does, and should be used with extra caution.
• I changed some of the terminology, often calling it "go live" instead of "become visible" to describe what happens when pending changes are reviewed.
• I added an extra column to the protection table, giving recommendations for when various types of protection would be appropriate. The actual contents of this column are up for debate, but I feel its presence is very beneficial for giving people a quick idea of how PC will be applied.
• I updated the color scheme from red-brownish-green to red-yellow-green.
• I added the "time period" that had been discussed previously. No need to comment on it again here, as it is a completely separate issue.

Discussion

Please comment on the various proposed changes. Some of these changes are very minor, and I don't expect them to ever be brought before the big RfC. And technically, some of these can be implemented without even making any changes to the provisional policy, so they wouldn't need to go before the RfC anyway. For instance, if people here like the color changes, I can just change that in the original table. Also, there's no policy saying that PC2 has to come before Semi. It just happened to fall that way in the table. So if there turns out to be a good consensus here that it's a good idea to move PC-2 down below semi, I think we could simply make the change without further ado. The terminology change is a little bigger, as is the extra column, so let's play those by ear for now. The "time period" is definitely going to have to go before the big RfC before it's implemented, so obviously it would be a bad idea to change that in the original table. ~Adjwilley (talk) 21:40, 18 July 2012 (UTC)

• I support having level 2 PC come after semi in the table. As for the nomenclature, I think visible is a more accessible term then go live. I think going live may confuse those less in tune with technology or those who are not native English speakers, so I don't support that change. No comment on the colors. The additional column for the description seems fine to me. Monty₈₄₅ 22:15, 18 July 2012 (UTC)
• I agree that discussion on the principle of a time limit belongs elsewhere. But if for arguments' sake we do introduce it, I think it is self-defeating to mention it in the table. It would be an at-a-glance declaration of weakness: an invitiation to heavily vandalise if you will. I would be in favour of bringing back the asterisk (or <ref>A footnote</ref>) to cover side detail such as that. I like the column you have introduced, although its content would obviously depend on the policy itself. —WFC— 22:34, 18 July 2012 (UTC)

Thanks, so are you saying stick the part about the time limit in a footnote for this discussion, or for the coming RfCs, or permanently, assuming the time limit is adopted? Note, there is already an asterisk in the table, describing what happens when a reviewer edits an article with pending changes. ~Adjwilley (talk) 22:45, 18 July 2012 (UTC)