Current status - Pending changes (level 1) was re-enabled on December 1st, 2012 by community consensus according to the 2012 RFC.
Logged in users – Logged in users (or users choosing to view pending changes) will see all edits as usual (unless the relevant setting has been changed in their preferences). All edits will still be added to the wiki and inappropriate edits must still be reverted or fixed as usual.
Logged out users – Until checked for obvious vandalism or superseded by appropriate editing, edits by new and unregistered users to "pending changes protected" pages will not be seen by users who are not logged in until approved. Edits by autoconfirmed users are approved automatically at level 1 when the prior revision is approved.
In the consensus formed for this trial, it had been decided that the policy for using flagged protection was the same as for using semi-protection; and for flagged protection without autoreview, that it was the same as for full-protection. However it hasn't been decided in which cases an admin should use semi-protection instead of flagged protection or vice-versa, or if we should use control groups and such.
Comments
Since the number of articles that can be switched to Pending Changes is limited, and since our pool of reviewers will be very small at the beginning, I've proposed that we only Pending-Change-protect pages in a controlled way.
I suggest turning it on for 50 articles every day for 30 days. I've started a queue to organize that (as a subpage for now) and filled it with 100 indef-semi-protected articles from a database report (preferring the longest protected ones, only discarding some like Stupid that seemed like bad ideas), as a start. Anyone may and should change that queue by adding, reordering, removing articles. Around 00:00 UTC some admin will remove the top 50 pages and Pending-Changes-protect them, every day.
I'm fairly certain that we need to it in this highly controlled way, to keep the backlog minimal. The number of articles converted can of course be adapted at any time. But thinking back to the recent introduction of RevDelete, I'm certain that we shouldn't just allow any admin to decide independently, since then we'd surely end up with hundreds of Pending-Change-protected pages on the first day, with a very immediate backlog. If an admin processes an RFPP request and find the article qualified for Pending-Changes-protection, he should semi-protect it normally, and insert the article into the queue for conversion. Opinions, objections, ideas? Amalthea12:11, 9 June 2010 (UTC)[reply]
I support the notion of controlling entry so that we don't swamp the initial pool of reviewers but I think if something is hot, it should be able to bump the things ahead of it. I also think maybe we could start at 20/day and ramp upwards gradually to 100/day or more by the end of the trial as the reviewer pool expands, instead of a constant 50/day. (still summing to 2000, mind) But in general, support. ++Lar: t/c13:32, 9 June 2010 (UTC)[reply]
Sounds good. Start with 20 a day, and adapt dynamically by looking at the backlog. And as far as I'm concerned the queue can be resorted at any time; I also wouldn't mind PC-protecting some pages on the spot as long as it's not done unilaterally, but brought up and confirmed on some central trial page, simply to maintain some control during the trial. Amalthea13:56, 9 June 2010 (UTC)[reply]
How much would this need to be enforced technically versus convention? It seems to me that if you all have a queue of articles to add, then we can rely primary on the throttle by convention, but have a weekly bump of the technical threshold to roughly match. For example, week 1: 150, week 2: 300, week 3: 450, etc. Alternatively, to keep things even simpler, we could just go with the originally planned 2000 article limit, and let you all enforce limits under that. I'd prefer that we not bump the software limit every day...it's not rocket science, but it is a config file, and each time we touch it is an opportunity for Murphy's Law to kick in.
For what its worth, I know there are plenty of people at WMF who think that we need a lot more than the very small numbers (since, for example, I floated something a lot like this proposal at WMF a month or so ago), so I wouldn't be surprised if there are also people in the broader community who think this plan is too conservative. From a technical perspective, we really won't know the performance implications of this until we get up above 1000 or so.
One other thing I should note: WMF was planning for 2000 to be the starting point, and opening up as performance permits, so don't assume that 2000 is the maximum for the end of the trial. -- RobLa (talk) 18:23, 9 June 2010 (UTC)[reply]
You're right, depending on the actual articles even 500 may only generate a handful edits per day that need reviewing. If we see that the review backlog is easily handled then we can and should immediately turn it on for more. For that reason alone it's probably best to handle it per convention, so that we don't have to hunt someone down to change the config. I don't know what kind of average review time we want to hold; I'd say less than 10 minutes would be very desirable. And good to know that 2000 isn't a hard limit! Thanks, Amalthea19:00, 9 June 2010 (UTC)[reply]
I think we indeed need a tightly controlled trial for the first month but we also need to see as close as possible how it will work in a non-trial situation, so in the second month of the trial we could give more leeway for admins to decide whether to apply SP or FP. By then we'll have to determine more precise guidelines on the respective usages. I don't think that in the duration of the trial 2000 articles could be (considerably) exceeded, except if we turn all SP in FP which doesn't seem like a good idea in any case. Cenarium (talk) 01:48, 10 June 2010 (UTC)[reply]
I think starting with a moderately large number - 500 or a thousand - is a good idea; there'll be a lot of desire to play with it when it goes live and restricting it to a small handful of pages is perhaps counterproductive in that regard. We're unlikely to run out of volunteers to work with it in the first couple of weeks, while we're all still experimenting :-)
Either way, perhaps it would be a good idea to set a rough timetable and some milestones before it goes live? Something like, say "Month 1 - increase protection page limit", "Month 2 - increase protection page limit and open up "other" namespaces", etc - with the thresholds being that we're approving (or "disapproving") edits within a reasonable average timeframe, and that the tech people are happy that it's not posing any major problems. This gives the advantage of a gradual rollout, whilst also meaning we can hold it back if we're finding problems. Shimgray | talk | 22:12, 9 June 2010 (UTC)[reply]
Actually, I rather like being counterproductive to "a lot of desire to play with it". Many many content editors are highly reserved with regards to this feature, to put it mildly. For obvious reasons, if you mainly produce quality content and only keep few, sometimes obscure articles on your watchlist, you won't find this feature useful, and will actually be put off by the thought that User:I_love_Huggle, who knows squat about your field of expertise, will review your edits before they are publicized. That is the sentiment I keep reading today, so I actually don't want any admin to "play" with it on his own whim (outside his own user space). It will only make things harder! Regarding milestones, I still don't quite know what to expect from the trial, so I have difficulties setting any up. Personally I'd open it up for all namespaces right away. I couldn't formulate any target number of articles at this point, except that as long as the review backlog is minimal, we should convert more. I have, by the way, not thought about Level 2 protection thus far. One article I think would qualify for it is Justin Bieber, which got a lot of autoconfirmed /b/ vandalism, and is regularly fully protected. Amalthea11:57, 11 June 2010 (UTC)[reply]
There's been a policy change w.r.t. TFA protection, they no longer have a special status and are subject to the protection policy as any other article. I propose we use pending changes on the TFA instead of semi-protection. Cenarium (talk) 01:48, 10 June 2010 (UTC)[reply]
TFA seems an excellent place to roll this out - it's both somewhere where pending changes will hopefully prove useful (high traffic, and many potential edits on already good content), and somewhere high-profile enough many people will have a chance to get a passing experience of seeing it in action. Shimgray | talk | 09:30, 10 June 2010 (UTC)[reply]
Agreed TFA would be a great option for this I think, a nice compromise. I have to agree that I think we can probably start with a good amount fairly quickly (a couple 100 even perhaps) for the sole fact that while we won't necessarily have a ton of non admin reviewers yet we WILL have a lot of people trying to figure out what the hell they are dealing with :). This is a feature that is much easier to understand by working with it. James (TC)02:29, 11 June 2010 (UTC)[reply]
Just a quick question for clarification. When Amalthea mentioned that if an admin believes an article "qualifies" for pending changes when looking at an article at RFPP, is that more or less a judgement call or is there a general rule of thumb for the articles? Icestorm815 • Talk02:54, 11 June 2010 (UTC)[reply]
I have no idea what good candidates are, at this point. Personally, I think the TFA is actually a bad candidate since it gets too many edits, which might make the review process difficult on the article. My guess would be that low-key, little-watched articles with a high vandalistic edit/productive edit ratio are the best candidates. Amalthea11:45, 11 June 2010 (UTC)[reply]
Break
If the test is very tightly controlled and carefully choreographed, then we would not know the flaws of the system, if there is any. Sole Soul (talk) 04:41, 11 June 2010 (UTC)[reply]
I'm not sure I agree with that. It might hide some stress testing flaws, and fewer test cases will make some bugs less noticeable, but most problems will be just as apparent. And as I keep saying, we can handle this dynamically: I'm happy to have the control loosened down the road – but in a controlled way! If we start out without restrictions and guidelines I'm expecting this to go very badly, with some admins adding it on hundreds of high-profile articles, not enough reviewers to quickly enough start reviewing, and other admins removing it on just as any articles since "this thing just doesn't work". I also can't say this often enough: I'm convinced that the key is to keep the review backlog minimal. Amalthea11:41, 11 June 2010 (UTC)[reply]
We are supposed to judge the new system based on a 2 months trial. Tightly controlling the trial to make the new system appears as working successfully, when a worst-case scenario could happen in reality, runs against that objection. Sole Soul (talk) 13:02, 11 June 2010 (UTC)[reply]
Yes, we need to progressively get closer to how it would look like in a non-trial situation. In the same time I agree we need to keep the backlog minimal, no more than a few minutes. We could have bot alerts if it exceeds, say, 8 minutes. It's also possible than we decide to run a second trial or provisional implementation after this one. Cenarium (talk) 02:02, 12 June 2010 (UTC)[reply]
Might be good for trial, but please be careful here; we absolutely don't want to put off new editors. Please just try a small number or something, first; the odds of new users editing those articles in near future are very very high. Yes, there is vandalsim - e.g. Peter Crouch was declared as 8 ft 7 instead of 6'7" earlier today - but we don't want to throw the baby out w/ the bathwater. Chzz ► 17:42, 13 June 2010 (UTC)[reply]
How about we add AN and ANI, plus their talk pages, to the queue. These pages get hit daily with vandalism and are protected quite often. I think having them on their queue would help admins alot so they wouldn't have to be watching every edit that came by, someone else (like a reviewer) could do it for them. - NeutralHomer • Talk • 01:04, 14 June 2010 (UTC)[reply]
Admins will always see the current version of the page, unless they have it configured to show only the flagged version. And I'm not sure why they would want to see only the flagged version. Anyone reading the administrator's noticeboards should be reading the current version of the page. If there's something that shouldn't be there, it will be closed or reverted. It's no big deal. Hiding the fact that there's vandalism will just make it more difficult to deal with. Reach Out to the Truth21:16, 14 June 2010 (UTC)[reply]
I'd rather keep them as unprotected as possible, as we do at times get legitimate comments from non-autoconfirmed users and IPs, not to mention it's a honeypot for those who like to shoot themselves in the foot :) –MuZemike21:18, 14 June 2010 (UTC)[reply]
There does not appear to be reasons for the request posted, are the reasons for the request posted elsewhere? As I understand it the tool has a specific use and there needs to be a visible related issue at the article to warrant its use , without a specific problem related to the designed use of the tool the trial will not have a value. Off2riorob (talk) 18:12, 14 June 2010 (UTC)[reply]
That as I see it is not a good reason to add this protection as regards a trial, if an article has been long time semi protected then unprotect it and if and when there is a clear issue that specifically will give a reason for this tool to benefit then apply for the tool this tool is not to replace long term semi protection, is it? Off2riorob (talk) 18:31, 14 June 2010 (UTC)[reply]
Is this tool a simple replacement for long term semi protected articles. no it is not, it is another tool to help protect articles. So replacing semi protection with this tool will not test this tool. I suggest removing the semi protection of the article and then when you have a reason that warrants the usage of this tool then state your reason and request permission. Off2riorob (talk) 18:34, 14 June 2010 (UTC)[reply]
Well, one of the uses of PCP1 is to open up "pages that have been semi-protected or fully protected (perhaps permanently) due to persistent vandalism and inappropriate content addition" (see current draft at WP:PCPP). You are quite right that the pages should be individually checked whether the initial indef protection was warranted and still is believed to be warranted, and I've added a note to that effect. From a quick view, there are certainly some where it isn't the case. Ultimate Guitar Archive used to get quite some vandalism back in 2008, but has hardly been edited for over a year. I kinda hoped that they would be reviewed, I didn't add the comment field for nothing and the 100+ I added initially were only meant to be a rough start. Amalthea18:48, 14 June 2010 (UTC)[reply]
I think we are on the same track, to test the tool correctly we should imo, remove the long term protection and wait for the specific type of reason that this protection is designed for which as I understand it is not to replace semi protection but for a subtle different type of disruption and actually quite focused and specific. For example Gordon brown is semi protected for ever, it just gets repeated and constant unconfirmed vandal type edits, changing this protection to the reviewer protection will simply mean work without any value, for this disruption semi protection is clearly much better.Off2riorob (talk) 18:55, 14 June 2010 (UTC)[reply]
Good point, that's of course true. Cenarium has made explicit note that "Pages which are subject to too high levels of vandalism can be put back to semi-protection". I think it just depends on the individual pages. I did skip a couple where from the title alone I had little hope for many constructive IP edits. But one aspect of the trial is to test the feasibility of the whole review process, and for that we need to put a sizable number of pages under the new protection levels, I believe more than we will get purely through WP:RFPP. I would recommend that we look at it for a few days, and if it turns out that the current page selection is a bad one we should just change it. What do others think? Amalthea20:09, 14 June 2010 (UTC)[reply]
I think we shouldn't allow admins to PC-protect at their discretion yet, because we need to start in a controlled way. First only selected articles (first week), then articles in selected categories at admin's discretion under the protection policy (second week), with a cap we raise each day, then extend to all articles, still with a cap. I don't see another way to proceed in the first phase than using already protected articles, changing from them SP to PCP, with same duration. They would likely have remained protected anyway, and it doesn't prevent from later reconsidering protection. In the first phase we should focus on testing the reviewing process. In the later phases we'll be able to test other aspects of the implementation. What we need to do now is making sure the selected articles are diversified. Cenarium (talk) 15:36, 15 June 2010 (UTC)[reply]
Well ok, we probably can also consider non-protected ones. Now we need to diversify articles, for the first day before it begins, there are mostly heavily vandalized articles. Cenarium (talk) 18:31, 15 June 2010 (UTC)[reply]
If it's of any interest, [1] has a list of all indefinitely semi-protected pages in chronological order starting at the longest semi-protected (mainspace only). As you can see, many off the first entries have been indefinitely semi-protected for good reasons :) As always, the community is welcome to review the semi-protections and request they be unprotected. –MuZemike20:04, 14 June 2010 (UTC)[reply]
Good point on the last comment. We need to be aware of restricting the trials so much that there is nothing left to test at all! - BilCat (talk) 21:42, 14 June 2010 (UTC)[reply]
Basically this is "Bible" plus the last part of some list (no other items begin with letters before 'R'). As good a methodology as any... RichFarmbrough, 19:57, 15 June 2010 (UTC).[reply]
Can any admin add this?
FT2 recently added to RfPP that that was the place to request pending-changes protection, [2] with the implication that any admin could add it based on an RfPP request. Is that the case, or do we come here to add the page to the queue for others to deal with? SlimVirgintalk|contribs17:13, 15 June 2010 (UTC)[reply]
What I proposed is this: in the first phase on the trial (first week), only articles listed here, in the second phase (second week) only listed articles or articles in listed categories, with a daily cap, and in the third phase, any article, with a daily cap. So we have a controlled progression. Cenarium (talk) 17:20, 15 June 2010 (UTC)[reply]
So we now have (well we did before) 98 articles and one category on the list. Dropping notes to the talk pages to try and gather soem response the the request on the Queue page. RichFarmbrough, 20:23, 15 June 2010 (UTC).[reply]
Without any substantive discussion anywhere, I've went ahead and switched out WoW: WotLK with Halo 3, which is similar in importance and article traffic. –MuZemike01:46, 16 June 2010 (UTC)[reply]
Hi all. I'm fully in support of pending changes being applied systematically to a set of articles so that its effectiveness can be quantified, however I'm not able to tell whether this is a community-approved list of articles that it will be applied to. Put another way, the top of this page say "For the first phase of the trial (week 1), only pages listed here can be protected under pending changes." - is there a technical measure in place that would stop any admin from applying pending changes to an article that is not on this list? Thanks. Mike Peel (talk) 22:37, 15 June 2010 (UTC)[reply]
As the above article is being used by the press as an example of an article which would be used for pending changes, is there a reason why it's not on the list?
Up to 2,000 articles, including a page about former US President George W Bush, will have their strict editing restrictions relaxed (BBC News
Jimmy Wales, Wikipedia's founder, said the new system would open up articles, such as the Wikipedia page of former US President George W Bush, that have, until now, been protected in order to prevent malicious edits.The Telegraph
The trial of the new system will cover a maximum of 2,000 pages, including such frequently vandalized ones as that about former President George W. Bush.Network World
So the fact that several press sources will use it as an example is neither here nor there? We'll have (for example) the BBC looking at it, and seeing that nothing has changed - we'll have editors popping up having read about George W. Bush being one example, and will see nothing is changed, they can't edit it? Hence my boldness... -- PhantomSteve/talk|contribs\ 00:28, 16 June 2010 (UTC)[reply]
I've got to go, but I'll say one last thing: normally I would seek consensus before beign bold like that, but I think it will look bad for Wikipedia/the WMF if all the press releases etc mention the GWB article, and it isn't included. The various press organisations will probably check the GWB article first, and will see it isn't pending-changes'd (they all have screen shots showing what the screen should look like) - and it will look unprofessional, and like Jimbo didn't know what he was talking about. Anyway, that's my 0.02 (well, probably about 0.04 or more!) - I'll leave it to you guys to decide one way or another. -- PhantomSteve/talk|contribs\ 00:35, 16 June 2010 (UTC)[reply]
Yeah, I don't understand why the pending protection was removed. The first time I actually heard of the trial was through the BBC News article with Bush's photo. The sharp adherence to the guideline, despite the compelling reasons to ignore it for this one article, is unbelievable. The Bush article will ultimately be pending-protected anyway. -- tariqabjotu00:45, 16 June 2010 (UTC)[reply]
I am not sure of the current status but wanted to weigh in with a personal request that this article - which is perhaps the archetype for the kind of article where we have long regretted that good faith edits from anonymous ip numbers were not possible - be included in the test sooner rather than later.--Jimbo Wales (talk) 00:47, 16 June 2010 (UTC)[reply]
Why have you regretted that, Jimbo? Fact is that almost all good-faith edits from autoconfirmed users have also been reverted from this article for a very long time. It's a good article, and most users don't have the chops to add well sourced, neutral, appropriate weight information to this article. Risker (talk) 01:04, 16 June 2010 (UTC)[reply]
I agree. Additionally, we need to have at least some higher traffic articles included if we're going to gain real experience with the feature. --Gmaxwell (talk) 00:52, 16 June 2010 (UTC)[reply]
Strongly oppose adding any of the articles that have been discussed in the media at least for the next week or so. Even as I write this, bugs are being discovered and worked out, and the reversal of the PC on this article when it was first applied resulted in a bug. These articles are going to be on every vandal's list of things to do for a bit. This is an encyclopedia, and the content takes precedence over public relations stunts. Risker (talk) 00:59, 16 June 2010 (UTC)[reply]
(ec) Re. Bush - I agree it would make a useful test case, but I disagree with adding it from Day 1. There are lots of odd bugs and things right now; can't we just wait a few days for things to settle down a bit? Maybe after a week? Chzz ► 01:00, 16 June 2010 (UTC)[reply]
And had it not been done and reversed we wouldn't have seen that problem. It's useful. I don't know what Risker's obsession is over vandalism is... the encyclopaedic mission is protected by the pending changes. If some excess vandalism shows up in the edit history... who cares? We currently have a ratio of >150 reviewers to reviewable articles. We can cope with a little extra vandalism in the edit history that does nothing to hurt readers. --Gmaxwell (talk) 01:13, 16 June 2010 (UTC)[reply]
Oh please, Gmaxwell. My obsession is with content and its accessibility. 99.998% of people who click on a wikipedia link are doing so to read it, not to edit it. We'll get a darn sight more bad press from "I tried to edit the George Bush article and got this huge error message" than we will from a notice that says "not available yet". Fact is, we've already had two buggy deployments of software already this month, and we as a community have learned that it's not wise to push things to the limit right away. This "damn the torpedoes, full speed ahead" attitude does not serve our readers, our editors, or our community well. Risker (talk) 01:43, 16 June 2010 (UTC)[reply]
I've yet to see any bugs reported which would negatively impact readers, if that wasn't abundantly clear from my words above. Care to point me to a bug report? If I believed that we knew of any I wouldn't be arguing that it was harmless for the readers. An timeout that comes up when you toggle the protection status isn't something that is going to hurt readers. --Gmaxwell (talk) 02:41, 16 June 2010 (UTC)[reply]
So, you think people will be interested in this particular article because it's in the press in connection with patrolled changes, and yet they will not perhaps click the new buttons?
A database query syntax error has occurred. This may indicate a bug in the software.
The last attempted database query was:
(SQL query hidden)
from within function "require/MediaWiki::performRequestForTitle/MediaWiki::performAction/Article::view/Article::showDiffPage/DifferenceEngine::showDiffPage/wfRunHooks/call_user_func_array/FlaggedRevsHooks::onDiffViewHeader/FlaggedArticleView::addToDiffView/Title::invalidateCache/wfGetAllCallers". Database returned error "1205: Lock wait timeout exceeded; try restarting transaction (10.0.6.46)".
Great, and I'm pleased these errors are being ironed out, through the trial. But that's part of the purpose of the trial . finding these things. Where is the rush? As the errors already reported were obviously unforseen, surely you accept that it is likely more will occur, especially in the very short term. I've seen 2 other problems with it myself, and heard reports of several more. Why rush? Chzz ► 04:21, 16 June 2010 (UTC)[reply]
If I thought that we should rush I'd be advocating mass converting most of the semis tonight. ;) We need to get more pages, including high traffic ones into the test to flush out the bugs and start building experience. It doesn't have to be today— but there should be constant motion forward. Adding ten articles per day is not going to get us there. Even after hours of operation we only have ~2 users who reviewed someone elses edits because there simply are no edits to review on the currently PCed articles. --Gmaxwell (talk) 04:36, 16 June 2010 (UTC)[reply]
Concerning discussion, the articles currently listed in the queue have been selected pretty much randomly. There is no particular reason for including them in the trial. Since Iceland, David Cameron, George W Bush, and homework were mentioned to and repeated by the BBC as topics where PCP can be used, and as long as there isn't a good reason to not use it on any of them, then by all means add them to the queue. Agreed with Risker that as long as there are known, unresolved, severe bugs it should be taken slowly, and those high-profile articles in particular should be held back. But let's include them in the trial as soon as possible. Amalthea08:16, 16 June 2010 (UTC)[reply]
See my post in the section below. The George W. Bush page is exceedingly large at 190,000+, and I believe is larger than any of the ones we have on trial already. The load time issue may well explain some of the errors that have occurred. While it's not something to which I'd given any thought before, it's something that will have to be addressed before bringing on such a very large, high-hit article. I have faith that the developers will find some fixes. Risker (talk) 09:09, 16 June 2010 (UTC)[reply]
BORING
So... unless quite a few more pages are transitioned the review queue is going to remain perpetually empty. This is reducing our ability to test the software and it's also skewing the statistics on how quickly pages are reviewed, since our reviewing capacity is enormously larger than the number of pending pages. I'd suggest that we instead double the number of pages transitioned from semi every day or two until we run out of good candidates, running into community/technical scaling issues (like long delays before changes go live), or hit the current software limit. --Gmaxwell (talk) 00:36, 16 June 2010 (UTC)[reply]
Greg, common sense says that you start off new software slowly, especially when you are already dealing with bugs. There is no harm in going slowly the first week while the technical issues get worked out. This extension is different than any that has been rolled out before, and we need for everyone to find their feet here. Risker (talk) 01:09, 16 June 2010 (UTC)[reply]
If the removal of GWB as discussed above is any indicator, you are right. Were supposed to have 2000 articles out of well over 3 million, and we can only come up with 100?? Ridiculous. - BilCat (talk) 00:49, 16 June 2010 (UTC) (Note that Jim Wales has now endorsed GWB's inclusion, which should end that dispute. - BilCat (talk) 00:50, 16 June 2010 (UTC))[reply]
I'd say wait about a week or so when we have around 70-80 (many of them highly-watched and trafficked) articles that are PC-protected to start seeing some big effects and discussion. –MuZemike00:55, 16 June 2010 (UTC)[reply]
That does make sence. Could we perhaps add a template to the pages mentioned in the media to note that they are to be included in the trial once some bugs have been worked out? - BilCat (talk) 01:04, 16 June 2010 (UTC)[reply]
You mean like the one I reported? Or the half a dozen that have been reported to me, that I'm telling people to mention in #wikimedia-tech? Risker (talk) 01:12, 16 June 2010 (UTC)[reply]
I'm sure there are plenty, but as far as I can tell it's a lie to claim that we're holding back because the software is excessively buggy. Especially when people can't even articulate what the bugs are and why they should defer deployment. You were aggressively pushing against deployment on Wikien-l earlier today... it makes your concern related to bugs seem rather disingenuous to me. :( --Gmaxwell (talk) 01:17, 16 June 2010 (UTC)[reply]
Balderdash, Greg; in fact, I actively supported deployment, and talked about the valuable learning opportunity that this trial gives us. There will be bugs, and errors, and people will make mistakes, and hopefully at the end of it we'll know whether or not this is the right tool for this project's purposes, or if maybe the Germans were right all along, or maybe there's something completely different that will work best here. I opposed including the George Bush article in the initial deployment and decried its use as an example. There are many other high profile, high hit-value, immediately recognisable titles even in the plan for the first days. I also did some mythbusting about what the trial is supposed to do, and pressed the community, the WMF and the developers to define what they would consider the trial to be a success, and what metrics we ought to be collecting to provide some measurable results. Risker (talk) 02:03, 16 June 2010 (UTC)[reply]
That is an excellent idea, BilCat. Let's hope one of our skilled template artists can come up with something, I'm sure at least one of them is watching this page. :-) Risker (talk) 01:09, 16 June 2010 (UTC)[reply]
It's not about begin exciting. Pending changes has been a pending change for a very long time (stable revisions is an exceedingly old idea), this is a 2 month trial - for week one, a hundred articles does not seem excessively cautious, I'm sure we will ramp up quickly. Also in the top candidate group (indef semis) there are about 500 pages, many of which either should not be protected, or there is "no reason to edit", or both. RichFarmbrough, 08:56, 16 June 2010 (UTC).[reply]
I hope you would agree that going an hour without even a single review of a non-reviewer edit isn't much of a test! Failing to get enough articles under the system to adequately tests it just delays problems until later and leaves us less time to work out the other details that crop up before the end of the trial. --Gmaxwell (talk) 18:28, 16 June 2010 (UTC)[reply]
Technical
For day 6, one of the article's there is Technical. But, the problem is, its a dab, not to mention that its not protected as well. So um, what should it really be? GamerPro64 (talk) 03:01, 16 June 2010 (UTC)[reply]
It's already indefinitely semi-protected, hence I believe the reason for its listing. It's also probably not as trafficked as some other articles, for instance. I'd keep it in there just because it may provide some sort of "quasi-control group" as opposed to just PC-protecting all high-importance, heavily-trafficked articles. –MuZemike06:46, 16 June 2010 (UTC)[reply]
How reliable is the list, though? It's not updated that frequently, and articles tend to differ on vandalism-frequency, depending on what is going on. –MuZemike06:49, 16 June 2010 (UTC)[reply]
Well, we still have a big pile of semi-protected articles to work through, which do need to be the priority as they're the prime targets for this feature. It might be worthwhile for someone to go down that list and see whether the "most vandalised" sobriquet is really true, though, and perhaps mark which ones are semi-protected. Strikes me this is one of those lists that only ever expands and nobody ever prunes. Risker (talk) 00:39, 18 June 2010 (UTC)[reply]
Added article
I read the notices at the top of the page but did not really see any explanation of how articles can be added to the list, so I went ahead and added "Andy Goldsworthy", which for some reason attracts high levels of vandalism. Let me know if there is some form of nomination process I should have gone through. — Cheers, Truth'sOutThere(speak the truth)06:23, 16 June 2010 (UTC)[reply]
Hmm, there doesn't seem to be terribly as much vandalism there, at least compared to the articles normally being used for the trial. Then again, none of the recent IPs have been productive at all. My question would be: would applying pending changes help any here, assuming semi-protection is out of the question due to infrequent vandalism? We don't want to scare away non-autoconfirmed users (i.e. no implied biting if we cannot help it), but OTOH no constructive editing has come from said non-autoconfirmed users. (Now you know what an admin goes through when determining whether semi- or full-protection on articles is necessary.) I'm on the fence; we can go either way with this. –MuZemike06:43, 16 June 2010 (UTC)[reply]
Self fulfilling prophecy
User:79.71.192.218 attempted to vandalise an article on the list (first edit for that IP), and when that failed ran off to another completely unrelated stub article and tried there. Seems like presence on the list drew the attack. RichFarmbrough, 09:00, 16 June 2010 (UTC).[reply]
It's good to know the the vandals are participating in the trial too. If they stayed away from the test articles, it would skew the results of the trial the other way! :) - BilCat (talk) 10:43, 16 June 2010 (UTC)[reply]
Load times and large articles
One of the things that has quickly become apparent is that the use of PC is significantly affecting the load times for pages under this level of protection; in particular, the review interface is coming up very slowly. This does appear to be proportional to the size of the article, and the longer the article, the greater the problems. The deployment team is aware of this, I understand, and is looking at it; however, in the interests of getting more articles up to test PC without having an adverse effect otherwise, perhaps we might want to juggle the queue a little bit to have shorter articles brought into the fold in the next couple of days while the team works on things. (Any comment by one or more of the developers would be helpful here, is this a good idea?) Risker (talk) 09:02, 16 June 2010 (UTC)[reply]
Does this have any effect on non-Pending changes articles? Wikipedia has seemed incredibly slow for me the last few days. --B (talk) 19:48, 18 June 2010 (UTC)[reply]
I don't know, but I noticed that rollbacks are taking 10 or 20 seconds now. Am I imagining it or did they use to be practically instant, no matter the article content? Amalthea20:27, 18 June 2010 (UTC)[reply]
I've noticed that too. It all seems inconsistent though. Sometimes I'll go to revert and open the user's talk page. Both actions will take longer than they should, but then when they both come up, they come up together. It's like there are transactions that are locking an edits table or something and once they get cleared everything goes though. --B (talk) 20:34, 18 June 2010 (UTC)[reply]
"Unaccept"
Why is the unaccept button grayed out when attempting to review current pending changes? I just reviewed an edit, did not want to accept it, but could not "unaccept" it (which on a separate issue, hurts my ears. We do not "unaccept" things and I think we should come up with a better word such as "reject", "deny", "repel", "veto", "disallow", "exclude", etc.) Anyway, is this a bug (possibly even on my end?)--Fuhghettaboutit (talk) 11:50, 16 June 2010 (UTC)[reply]
"Unaccept" means to remove the stable-flag from the most recent, accepted version, like here (ATM), i.e. you can only "unaccept" a previously "accepted" revision (Not sure if my terminology is quite right, sorry for that). If you find a pending change unacceptable, undo/revert it, and accept your reversion. Yep, we need tools to make this easier. :) Amalthea12:09, 16 June 2010 (UTC)[reply]
Yeah, I think we definitely need to get a "reject" button. I was confused by this issue as well, and wasn't sure if undoing/reverting the as-yet-unpublished edit was just a backdoor way of rejecting the edit. — CIS(talk | stalk) 12:13, 16 June 2010 (UTC)[reply]
Hmmm, I'm confused but I probably need to read the documentation more carefully. If we are rejecting an edit we act as if the edit was made and revert it? Anyway, the ability to "reject" is important because if we don't have that, then multiple people are going to be reviewing the same proposed vandal edit until it is obscured by later proposed edits, and non-vandal edits, but ones still inappropriate, will probably get accepted by someone eventually if people can't reject; 29 see the edit, do nothing because it's not appropriate but the 30th person will accept simply because it's not vandalism.--Fuhghettaboutit (talk) 12:29, 16 June 2010 (UTC)[reply]
I for one don't like the interface much either, and too find it confusing. Risker could give you some examples where it can hide good edits, or at least make things rather difficult. I would suggest that if you review pending revisions, just do it like you checked vandalized pages before. You now benefit from revisions marked as "accepted" in the page history so you have a point of reference against which you check. Once you're satisfied that the topmost revision is good, you "accept" it, i.e. publish it for readers. Amalthea14:52, 16 June 2010 (UTC)[reply]
You aren't "acting" like an edit was made then reverting it. The edit _was_ made. It's there, it's done. What PC controls is which edits are displayed by default to anons. You can choose to leave anons seeing an old version, or you can promote a newer version to be visible. If you want to remove an edit, you remove it like normal— by using the undo button, rollback, manually editing it out, or saving a prior version. I think the last minute change to the terminology makes this much more confusing than it needs to be. You may find this poster I made about the feature under the old name informative: [4].
The reason there can't generally be a "reject" button is that if there have been multiple intermediate edits, some good some bad, a rejection that actually undid the pending changes would cause good changes to be lost. Fortunately, the system is designed to reduce the urgency in reviewing... you can take the time to go carefully revert vandalism because the public isn't seeing a big penis-picture in the meantime. Cheers. --Gmaxwell (talk) 15:06, 16 June 2010 (UTC)[reply]
I understand from the technical perspective.
From the end-user persepective though, this is confusing, and encourages systemic bias, because it has a high expectation of the reviewer technical ability; I'm sure that it is possible to clarify it. The current choice for a new edit are just "Accept" there is no other option. If an "Reject" (and please, not 'unaccept') is not possible, then a short small note explaining the alternative action would clarify. "Reviewer: If this edit is not acceptable, undo it in the page history or something?
I'm not a fan of the greyed out buttons; it usually makes me think that I have just not (yet) filled something in somewhere - rather than the option not being available.
Gmaxwell, is it really not possible to have an undo link pointing to the specific diff? And there is a point...perhaps it should just be "Accept" or "Undo"? Chzz ► 17:00, 16 June 2010 (UTC)[reply]
It could be done if there is only a single revision which has been made since the last review, but the undo button could not be displayed if there are multiple revisions as the software couldn't tell which of the revisions you wish to undo... you can't even know for yourself which of them you'd like to undo without reviewing them individually. What do you think about the ease of use of a button which can only be there sometimes?
Even more useful than undo would be rollback— since if one edit by a user was vandalism it's pretty likely that the other contiguous edits by that user are also no good. Unfortunately EnWP seems to have a lot of bizarre politics about the rollback button (which I consider ironic because undo is more powerful in some ways, though not for this purpose)... If rollback were available then it could be offered in cases where the span of pending changes were all by the same author. It still wouldn't be available in cases of mixed authorship.
There is also a social-engineering aspect to consider. There is very little harm in letting a pending change sit for tens of seconds or even a few minutes before reaching its final state. So long as we have an excess of reviewers compared to revisions which need review (which we certainly have now) we should be encouraging people to error towards taking no action as that will result in the best decisions being made about the ultimate fate of an edit. (As more people will get a chance to look at it, allowing the person with the most confidence one way or another to pull the trigger).
As far as the note goes, I think that is a grand idea. We should add that, or something substantially similar, to the site message text. --Gmaxwell (talk) 17:49, 16 June 2010 (UTC)[reply]
Would it be sensible to add another column to indicate whether protection has or hasn't been applied (possibly with commentary)? The comments section is generally being used by the nominator to explain their rationale. That would also save people having to go through and check each one to see whether PC has been applied or not. GedUK12:43, 16 June 2010 (UTC)[reply]
Done It's embarassing I'm so lame at wikitables. I've done day 1. Presumably day 2 is today, or does that only kick in at 11pm UTC or thereabouts? GedUK14:02, 16 June 2010 (UTC)[reply]
How many articles for day two?
I for one never noticed any pending revisions in Special:OldReviewedPages today, so we're apparently very good in that regard. Personally, I'd react to that by converting decidedly more articles tonight, at least 30 (and wouldn't mind converting a batch during the day if nothing comes up). Or are there any technical issues that I'm unaware of which should make us tread that carefully? Amalthea16:51, 16 June 2010 (UTC)[reply]
The only technical issue that I've heard about so far is slow page loading, but I haven't noticed any comments from the developers as to whether there is an unexpected server load overall to this point, so I think, unless we get specific feedback from the technical folks, that it would be worthwhile to start accelerating the queue here. What about adding 10 new articles every 6 hours? That way if there's a problem, we haven't flooded the system and we can pause, but at the same time we can start progressing steadily. What do you think? I won't be around for about 12 hours, but can do an upload around that time. Risker (talk) 17:38, 16 June 2010 (UTC)[reply]
My guess is that the slow page loading during reviews is the same slow loading of many long, citation-heavy articles when you preview or purge them. 10 every 6 hours sounds good, too. Any objections to switching to a 6 hour cycle right away, at 18:00 UTC? Amalthea17:54, 16 June 2010 (UTC)[reply]
What about adding featured articles currently on the Main Page? These tend to attract a high level of vandalism (such as what is being experienced by "Robert Hues" at the moment). — Cheers, JackLee–talk–18:06, 16 June 2010 (UTC)[reply]
I wonder if you'd taste better with garlic and lemon butter or a wine based sauce? ... because I expect that if you propose that any louder you'll be burned alive. ;) I'm all for getting some more heavy use of the feature, but we should probably defer the most controversial uses possible until some later date. --Gmaxwell (talk) 18:31, 16 June 2010 (UTC)[reply]
When you figure it out, please let the rest of us know. ;) ... More seriously, I believe the idea of extending PC to pages which don't currently meet the criteria for semi-protection is opposed by many people. OTOH, no one appears to be flinging poison darts at you yet. --Gmaxwell (talk) 22:47, 16 June 2010 (UTC)[reply]
"Today's featured article may be semi-protected just like any other article. But since this article is subject to sudden spurts of vandalism during certain times of day, administrators should semi-protect it for brief periods in most instances."
With PC, it would be possible for admins to extend the protection for longer periods. I think we should at least consider Level one PC protection for FA's on an individual basis, just as we are considering other articles, for the duration of the trial, if we think they are likely to need semi-protection when they appear on the main page (with L1 prtection beginning on the day they appear until it's deemed unnecessary. As for the poison darts, they're being flung at supporters of Pending Changes anyway, so what are a few more? ;P - BilCat (talk) 07:11, 17 June 2010 (UTC)[reply]
I'm inclined to agree with Gmaxwell here. Very few TFAs qualify for semi-protection outside of their "day in the sun". If there is a TFA coming up in the scheduled TFA queue that is already semi-protected, that might be one that could be considered, but I wouldn't want to do that without having a pretty broad community discussion, and probably not until the trial has run for at least a month and people have a comfort level with the processes. Keep in mind that the day of the US election, when we had both presidential candidates on the main page (both of whose articles were normally semi-protected), even then we found a way to have the articles unprotected for portions of the day. Mind you, we did block at first sign of any untoward behaviour.... Risker (talk) 08:15, 17 June 2010 (UTC)[reply]
I'd like to see some opinions on how to deal with articles proposed for pending changes when they've got an OTRS ticket confirmation on them. OTRS can't always tell us why there's a ticket there, but I think they might be able to tell us if there is a connection between the OTRS ticket and the semi-protection. If there *is* such a connection, I'd suggest that we not include those articles in the trial itself. Should the community decide to keep the pending queue process going at the end of the trial, this is an issue that could be revisited, but I think there are probably sufficient articles available for the trial that we can probably skip these few. Thoughts? Risker (talk) 08:25, 17 June 2010 (UTC)[reply]
As far as I'm concerned, a ticket number should never be the only reason listed for a semi-protection. It may be useful to reference a specific ticket number in a list of reasons, but semi-protection should only happen on its own readily-apparent merits. With that in mind, I doubt it'd be an issue to include any such articles in the pending-changes trial. (Of course, specific examples of those semi-protected articles would be handy.) - Jredmond (talk) 16:03, 17 June 2010 (UTC)[reply]
We have enough that we probably could skip them. I don't understand why we should, since pending changes will have substantially the same effect as semi-protection on the page that is displayed to the public by default.--Chaser (talk) 23:44, 17 June 2010 (UTC)[reply]
You may well have a point. I'm inclined to ensure that OTRS has a heads-up about those specific articles, though, because they tend to be watched closely by the subjects (if they're BLPs), and any change may trigger a reaction from them. Both of the ones I'm aware of that are OTRS tickets and are currently in the queue are BLPs; not sure if the subject above has been advised in advance, but I understand the subject of the other has already been sent an email and advised that their article is going to be part of the trial. As it turns out, we're trialing more or less what the subject asked for in the first place. With that in mind, I'm happy to withdraw the "let's skip these ones" suggestion. Risker (talk) 00:04, 18 June 2010 (UTC)[reply]
Because there are so few pages in PC, so little activity on those pages, and so many reviewers. There hasn't been more than a couple become pending in an hour since the trial started, last hour there was one. --Gmaxwell (talk) 06:12, 18 June 2010 (UTC)[reply]
Article defacement
This defacement of a featured article needs to be sorted. The editor who originally added TS to the pending articles already added a template at the top; now the article is being defaced with this template. Tourette syndrome is vandalized when unprotected because of the nature of the content (coprolalia related), but there should be a way to implement this without a large, ugly template at the top of the article. SandyGeorgia (Talk) 02:29, 18 June 2010 (UTC)[reply]
When I accepted an edit to World War I, I had a "Wikimedia Foundation Error", a timeout, "Our servers are currently experiencing a technical problem. This is probably temporary ...details below."
I reported this in the #wikimedia-techconnect channel.
I'm told that it is related to the page size - that it takes approx. 17 seconds to render that page, that PC "often tries to parse things twice", and that the squid caching servers timeout at 30 seconds. Chzz ► 03:17, 18 June 2010 (UTC)[reply]
That part shouldn't matter as much. This is a problem with PR if it can't handle a page of this large, but not unreasonably so, size. Prodegotalk04:40, 18 June 2010 (UTC)[reply]
Chzz, did your acceptance of the revision get through and the timeout only occured afterwords (i.e. when the page was being rendered), or did it fail to flag the revision in the first place? Amalthea08:48, 18 June 2010 (UTC)[reply]
I see this error reasonably often on very large pages, or widely transcluded templates. The change is usually made, despite the warning. RichFarmbrough, 17:14, 23 June 2010 (UTC).[reply]
Wording for how to add a new entry.
After the page was split, the notice advising to Be Bold and add new entries was somewhat misleading. It implies that you still should edit this page unless you click on the Link which seems like it would just take you to the bottom of the page (where there is still a Heading)
I think it should simply ask for one to submit proposals to the Pool page.
Please don't directly add new articles here without going through the pool first. To suggest a new article for this queue, please follow the instructions at Wikipedia:Pending changes/Queue/Pool.
Propose it on the talk pages first. In general, I'm all for trying it out on a few suitable pages. A candidate I previously had in mind was Justin Bieber, but that article has calmed down somewhat. Amalthea09:44, 21 June 2010 (UTC)[reply]
Suggesting articles for queue
I don't know if this is appropriate to suggest, but homophobia and homosexuality are consistently used as POV fodder for one reason or another. This is compounded by the fact that neither article is particularly well-written. I don't know what would happen if either of these were accepted. I imagine some pretty inflammatory conversations about ownership and cabals and whatnot. However, after all, this is a trial, and I suppose were all interested in trying times. --Moni3 (talk) 17:34, 19 June 2010 (UTC)[reply]
I don't think POV warring is best managed with Pending Changes, which is supposed to block obvious bad faith edits (basically, vandalism). The line between POV pushing and bad faith can be hard to discern, and the reviewing editor may be put in a position where they feel they must block a change that really should be WP:BRD'ed, talked out, and then go to dispute resolution if necessary. Pending changes might drag reviewers into conflicts. / edg☺☭00:16, 20 June 2010 (UTC)[reply]
Lately, it's been a couple folks trying to insert that the term "homophobia" is pejorative. But ah, on to dispute resolution. Because that makes all kinds of sense. --Moni3 (talk) 01:26, 20 June 2010 (UTC)[reply]
World Cup players whose articles are semi-protected
I see Amalthea has run a list of the football players participating in the World Cup whose articles are semi-protected; looks like quite a batch. I'm thinking maybe they should be added en masse on Monday or Tuesday (while the tournament and most of the teams are still active), and pretty well make that the day's worth of additions. I know that's jumping the "category" queue a bit early, but we won't be seeing the full effects of the pending changes tool if we aren't using it at a time when there is likely to be a significant mix of both good and problem edits. These will be very good "test articles". Risker (talk) 17:04, 20 June 2010 (UTC)[reply]
The API link lists all pages in the category, you need to search it for Example text to find the semi-protected articles, and there are only four newly protected ones left. All others were already switched. Amalthea09:40, 21 June 2010 (UTC)[reply]
Selena Gomez
Selena Gomez was one of the articles put on PC trial.
As far as I can tell, the trial was working. Anonymous editors could now vanadalize the page, but no-one saw these changes without explicitly requesting to see them. And everything was getting reverted very quickly.
Apparently not understanding this new feature, a good intending anonymous user looked at the history file and saw dozens of recent reverts, so he/she requested page protection [5] which was granted by a helpful admin User:SlimVirgin patrolling the RfPP page.
Another user questioned why it was removed (and not entirely properly) and the Admin said he didn't quite understand all the details of the trial. [6]
So it looks like we have a process and education breakdown, which brings to my mind a couple of questions.
Should the PendingChanges have been reverted on that page?
Should the PageProtection bot be enhanced to note that a page being requested is already in Pending Changes state?
Should the instructions on the WP:RfPP page be highlighted to note to look for PendingChanges trial and potentially discuss it here first before removing it.
Could someone explain what the point is of maintaining pending-changes protection if vandalism, including possible BLP violations, is still getting through, and semi-protection is still required? SlimVirgintalk|contribs19:30, 21 June 2010 (UTC)[reply]
I for one am not so worried about BLP vandalism only seen by a few logged-in users. That being said, the high number of anon edits on the Selena Gomez were apparently all vandalistic or non-constructive, so I agreed with returning it to semi-protection. Amalthea08:21, 22 June 2010 (UTC)[reply]
I don't think the purpose of the trial should be to keep pending changes protection sacrosanct. Rather it should be to see what issues arise. This is one such issue. Thincat (talk) 18:41, 22 June 2010 (UTC)[reply]
Problem
Apparently, when you use Twinkle to rollback an edit after reviewing it, it doesn't mark it as accepted automatically, only if I rollback manually. Would there be any way to fix this? ~~ Hi878(Come yell at me!)02:13, 22 June 2010 (UTC)[reply]
Hmm. Probably, I need to find out how PC works here, and how it knows when to auto-accept a revision. Undo auto-accepts too, by the way. Amalthea08:35, 22 June 2010 (UTC)[reply]
I see several edits there that have been manually accepted. Those edits could not be made under semi-protection. Yes, there is lots of vandalism to revert, but that doesn't take too long. --Tango (talk) 20:45, 22 June 2010 (UTC)[reply]
The more high profile the article, the more likely it is to attract drive-by nonsense. I don't think that pending changes will alter this. All it will do is to increase the work for the regular editors. This is one reason why flagged revisions are controversial. Anyone who is serious can autoconfirm or place an edit request on the talk page.--♦IanMacM♦(talk to me)21:08, 22 June 2010 (UTC)[reply]
I'm not finding it terribly inconvenient, and I'm also seeing productive edits that probably wouldn't have otherwise been made. Edit requests can be pretty inconvenient too, so often such requests will simply not be made. Reach Out to the Truth21:16, 22 June 2010 (UTC)[reply]
That's just a general objection to the whole feature. We've discussed this at length and we agreed to a trial. Please wait until the trial is over before judging whether it has succeeded or not. --Tango (talk) 01:45, 23 June 2010 (UTC)[reply]
How to cancel review
Is there a way to cancel a review (if one doesnt want to accept or reject a PC (eg if it seems wrong or poor rather than vandalism)) ? Just using the browsers back button still shows the page as "under review" for a few seconds. ... Seems to sort itself out so I'll use the 'back' button for now. Rod57 (talk) 22:40, 22 June 2010 (UTC)[reply]
Is this queue still necessary? We have at the moment 841 pages under PCP. I think it is clear that the reviewers could manage 2000 pages as well. I would suggest that RFPP can from now on put any article under PCP right away, if they want, and that mass PC-protections should be proposed at WT:Reviewing from. Amalthea15:49, 23 June 2010 (UTC)[reply]
Earthquake just hit Central Canada this afternoon (felt it personally during a meeting). It would be nice to see how pending changes played out for a current and on-going events to gauge the ratio of good-faith and bad-faith edits so I was being bold and activated pending changes on that page without first listing it in the queue. OhanaUnitedTalk page18:54, 23 June 2010 (UTC)[reply]
This article is a high profile BLP that tends to attract a fair amount of bratty kids as well as fans of some other band he had a dispute with once who like to add BLP violating stuff about a backstage fight. PC1 would be fine for this since the vast majority of the vandalism and BLP violations are from anon IPs and SPAs with few or no other edits. <>Multi‑Xfer<> (talk) 06:05, 24 June 2010 (UTC)[reply]
Pending Changes/Review Confusion
Can someone help me? I am an accepted "reviewer" and yet when I try to review a "pending change" only the "accept" botton can be selected; the "unaccept" button is grayed out for me and cannot be selected? Why is this? (In trying to "fix" this problem, I accidentally "accepted" some changes to the Al Gore article that clearly should not have been accepted because they were incidents of vandalism!) Can someone explain to me why I am only able to select "accept" and not allowed to select "unaccept" when reviewing an article? Thanks! --Skb8721 (talk) 21:55, 24 June 2010 (UTC)[reply]
I had exactly the same confusion a while back. See the thread I started higher on this page. The long and short of it (as best I understand it) is that the unnaccept button, quite confusingly, is not for not accepting an edit, it is for undoing a prior acceptance. When you want to "reject" an edit, you can undo it, or revert it, or whatever you would normally do if there was no such thing as pending changes and someone had made the same edit to the article. However, they are apparently working on an actual "reject button".--Fuhghettaboutit (talk) 22:03, 24 June 2010 (UTC)[reply]
It's simple: At the time of your review, the revision had not been accepted. You can either leave it exactly that way, or you can accept it (by pressing the accept button). That's all there is for acceptance/nonacceptance (which controls whether it is displayed to every reader).
However, if the revision should not be accepted as is, as an editor you should probably edit the article so that a good version is the latest (and so acceptable). This can be done by reverting the edit, for instance, or by further editing to preserve the good parts of the edit while removing the bad parts. -R. S. Shaw (talk) 00:37, 25 June 2010 (UTC)[reply]
I found it confusing too to see a non-functional "unaccept" button. It would be much better to not display it at all when not relevant. --Elekhh (talk) 03:12, 25 June 2010 (UTC)[reply]
More articles need to be put into this trial
Right now, we have just over 900 articles enrolled in this trial; we need to make a very serious effort to increase this number to closer to 2000 to get a sense of how well our reviewers cope with a higher number of articles. I propose the following:
Encourage administrators to comb through the pool and the database reports on semi-protected articles to add another 500 articles. Particularly good targets are schools, places of residence (towns and cities), science-based articles; these are all more likely to receive "good" edits from unregistered or newly registered editors.
Add some BLPs that have been semi-protected in the recent past because of vandalism/BLP violations, even though they are not semi-protected currently.
In this respect, I've asked for a report listing articles in Category:Living people that have fewer than 10 "watchers" and have been semi-protected in the past six months. Since any list showing fewer than 30 "watchers" is considered "admin-only" information by the Toolserver admins, I will not be able to publish this list on-wiki; however, I will arrange for up to 200 of them to be included in the trial.
Aim to have at least 1800 articles in the trial by July 7.
Schools are often semi-ed because of the enthusiasm of their pupils. So far, there has been a consensus that pending changes is not ideal for articles that are likely to have IP timewasting. Articles need to have a good track record of sensible IP input before they are suitable for pending changes.--♦IanMacM♦(talk to me)06:25, 28 June 2010 (UTC)[reply]
In my experience school articles are often improved, albeit slowly, over the holiday season. It's the students at school who typically do the vandalism. Right now is the real low point of the year in terms of vandalism, as students are more inclined to want to forget about school. It probably makes them good candidates for either total unprotection or PC protection if currently semi-protected. -- zzuuzz(talk)06:44, 28 June 2010 (UTC)[reply]
I'd suggest looking through the history of Lar's liberal BLP protection movement for some BLP ideas. The protection logs of a few of the page's regular admins there are also worth following. There's a good number of BLPs that would have been indef-semi'd due to the constant and gross but low-level vandalism, if it weren't for the good proportion of good-faith edits. -- zzuuzz(talk)06:47, 28 June 2010 (UTC)[reply]
Articles involved with current events or recent deaths are another category of article where unregistered edits are likely to be constructive. I've been through some of these categories and applied PC-protection. — Martin (MSGJ · talk) 10:23, 28 June 2010 (UTC)[reply]
Well, one of the experiences we have already had is that many highly visible BLPs seem to be swamped with clearly inappropriate edits; in the case of this article, semi-protection was put in place because the inappropriate edits included BLP violations that affected third parties, and significantly POV edits. I'd probably not include it, but I wouldn't stand in the way of someone else doing so, provided we all understand that for this or any other BLP, if the vandalism/BLP violations outweigh any valuable information, it goes back to semi-protection, potentially within hours. Risker (talk) 16:35, 28 June 2010 (UTC)[reply]
Risker, I don't know who you asked for that list, but I'd recommend that in addition to random little-watched BLPs, also ask for the e.g. 200 BLPs with less than 10 watchers that got the most edits in the last 2 months (I leave the exact numbers to the person doing the database report). I'm not sure how many BLPs we have, but 200 random ones might very well get hardly any edits till the end of the trial, even if they were recently vandalized. In any case, we'll need to keep track of those pages that aren't currently semi-protected: There is a script that can convert all PCP-pages back to semi after the trial, but most of those that aren't currently protected might need to be unprotected after the trial. Amalthea17:52, 28 June 2010 (UTC)[reply]
Great idea, Amalthea; I know the list hasn't been run up yet, so there's room to modify the parameters. You're right, given the number of BLPs we have, we want to make sure they're ones likely to be edited for the purposes of the trial. Risker (talk) 17:57, 28 June 2010 (UTC)[reply]
I understand how you feel, MSGJ; however, it seems almost impossible to get responses to a lot of practical points on the other pages without it getting lost in general commmentary. Bluntly put, this page is actually working, but most of the others aren't. Risker (talk) 10:58, 28 June 2010 (UTC)[reply]
A frequent vandalism target (including once by myself back on April Fool's day 07:) it has been semi-proted since that particular padlock was created. It is a controversial BLP and, in short, a perfect candidate for this interesting little experiment.--R.D.H. (Ghost In The Machine) (talk) 11:35, 1 July 2010 (UTC)[reply]
See two sections up - vandalism targets are unlikely to be helped by pending changes, as all the vandalism will still need to be reviewed and reverted. — Martin (MSGJ · talk) 11:51, 1 July 2010 (UTC)[reply]
![[4]](http://myrandomnode.dyndns.org:8080/~gmaxwell/flagged_protection3.png){kind=link}