User:CMBJ/Pending changes straw poll

Wikipedia:Pending changes/Closure

Extended content

Data summary A graphical version of the data Position Pages Characters Words Support 10 36615 6393 Oppose 9 30362 5226 Other 7 23640 4175 Support Generally I like it as it calls attention to high-traffic or high-vandalism articles. If it were to show up on a large number of articles, though, it could become self-defeating. ←Baseball Bugs What's up, Doc? carrots→ 03:12, 23 August 2010 (UTC) I conditionally support it if, and only if, we limit it to articles that would otherwise be semied and we come down hard against reviewers trying to use it for censorship. If those conditions are met, this tool encourages new editors by letting them edit sensitive pages without showing vandalism to the public. —Arctic Gnome (talk • contribs) 21:05, 22 August 2010 (UTC) It actually encourages new and anonymous users by letting them edit articles that would otherwise be protected, so this works towards our mission. I do agree that censorship is a potential, but we just have to agree to have no tolerance for abuse of the reviewer power. —Arctic Gnome (talk • contribs) 21:05, 22 August 2010 (UTC) Support continuation as long as it should be re-iterated and made clear to reviewers that this is meant to fight vandalism and nonsense. I never understood this as a conflict/dispute-tool. Thus, I personally had no problem occasionally accepting edits on subjects I had no idea about, as long as it didn't say "wkfwgfcsfdn948fvhvj" or "motherfucker". I think the "accept"-button should be seen as the opposite of "revert vandalism"-button and be used as such. Choyoołʼįįhí:Seb az86556 > haneʼ 07:54, 22 August 2010 (UTC) Support assuming the system is modifed so that you can choose to accept or unaccept (instead of it being set to 'unaccept' automatically) and unaccepting autoreverts the edit. Seems kind of pointless having to revert the edit anyway, it'd be better if the system did that. HalfShadow 20:25, 21 August 2010 (UTC) Support since I have been a supporter all along, my opinion has never changed, and this looks like it may turn into a head count after all with the opposers being more likely to vote. —Soap—20:25, 21 August 2010 (UTC) Support while I feel that the feature was implemented too often in places where temporary / indefinite semi protections would have been far better, I generally like the system as a whole and it reduced vandalism while still maintaining the fundamental principal of a wiki. Mkdwtalk 23:29, 21 August 2010 (UTC) "Verified?" Where does it introduce this word? A reviewed edit is merely "accepted". This tool works very well for Telephone and others which get a steady though not heavy stream of IP graffiti and rarely a substantial improvement. Yes, it will confuse those who haven't logged on. It's worth the cost. Option 3, a modest expansion from the current thousand to a few thousand articles while continuing to tinker with the workings, is appropriate. Jim.henderson (talk) 18:14, 21 August 2010 (UTC) Support. In effect adds the options of quarter-protected and three-quarters protected to compliment semi and full protection. PhilKnight (talk) 18:29, 21 August 2010 (UTC) Any content you add or accept into an article you are responsible for, legally. You might get mitigation because you didn't actually present it for acceptance, but you are the one accepting it so you have a duty of care to yourself to review it well. Of course it rarely, almost never comes to such extreme situations.Off2riorob (talk) 19:44, 21 August 2010 (UTC) The author in the case of an accepted edit would be the unconfirmed user supported by the accepting reviewer. I haven't seen this you are referring to be an issue at articles I have worked that are pending protected. Off2riorob (talk) 20:08, 21 August 2010 (UTC) Pending changes doesn't clog the history with anything of the sort. If there's that much vandalism you should be using semi-protection instead. That much is obvious from this trial. What PC is good for is preventing vandalism showing in articles which aren't subject to heavy editing and which wouldn't normally be semi-protected, where the vandalism would otherwise be completely unattended - in Google and visible to visitors. -- zzuuzz (talk) 20:51, 21 August 2010 (UTC) If they're not protected at all then the vandalism stays visible in the article instead. That's what adds up. -- zzuuzz (talk) 21:02, 21 August 2010 (UTC) I am afraid I do not follow your reasoning. Patrolling recent changes also takes the manpower of experienced editors. Also, while vandals CAN register, they have to have a good activity before they will get the autoconfirmed flag. They can't just register and start vandalizing; we'll catch it immediately, PC or not. Further, what is the roadblock you speak of? Editors who previously could not edit some articles can now make good-faith edits that can be accepted by any member of the reviewing community; if the change is a good one, then it SAVES manpower on the talk page having to add it manually ourselves, and it's NOT an obstacle to the user who was able to add their bit to the article. CycloneGU (talk) 13:08, 21 August 2010 (UTC) Point taken. However, the current guideline I remember reading is you have to have 75 edits - typically mainspace edits - before being granted the userright (if am I mistaken, correct me please). So a vandal spending ten edits on their page will contribute nothing to the edits required to qualify as a reviewer. Maybe we do need stricter standards for the role, I'll be first to admit that. The pending changes itself, however, is not an obstacle to good editors; only to bad. CycloneGU (talk) 23:01, 21 August 2010 (UTC) Support. Does not replace semi protection but definitely has a place and should be kept.Doc James (talk · contribs · email) 01:19, 21 August 2010 (UTC) Support (conditionally) - It does have its place, and has helped in quite a bit of places. However, I observed one major problem: It got applied much, much too liberally in many places. Articles which really did not need it were given the PC flag, and users who were retired for months were given the flag automatically. This needs to be addressed if it will get reenabled. (X! · talk) · @195 · 03:40, 21 August 2010 (UTC) I think its liberal application was part of the test. Any page could have been requested for the trial period, and it was granted much of the time. Heck, Bible and Barack Obama (the latter which I reviewed an edit on once but was beaten to reverting it) both got added to the queue, but those were reversed (quickly) as they are heavy targets evidently. CycloneGU (talk) 13:08, 21 August 2010 (UTC) Support the feature. Only a few of my 5600 watched articles have the Pending feature, mainly because I unwatched the hot ones. Where pending changes arose, I was confused at first but after a couple tries could handle it. Wouldn't want it to be applied to the majority of articles or to the hottest articles that require firmer handling, but for most semi- protected articles it would be a good alternative. Jim.henderson (talk) 00:05, 21 August 2010 (UTC) Support Those of us not Reviewers are already doing this. I have 5123 pages on my watchlist as of today: once in a while (a month? three months?) I view the diff on my most recent edit and vet the intervening edits in a group. Vandalism you can't immediately see must be a dull game.--Wetman (talk) 21:10, 20 August 2010 (UTC) Support. Despite its complexities and oddities, it's a great intermediate before protection, and definitely an idea that should be continued. bibliomaniac15 22:05, 20 August 2010 (UTC) (Am I doing this right?) I liked it. I noticed speed issues with diffs loading, but that seems to have improved. I definitely prefer allowing IPs to continue to edit, so I prefer it to semi (and used PC1 instead of semi at WP:RFPP a lot). It seems less than ideal with high-traffic pages, and I had to change PC1 to semi several times, but for low-traffic pages it's great. I'd like to see pending changes kept. I'd also like to see us considering using PC1 by default on all WP:BLPs. TFOWR 14:26, 14 August 2010 (UTC) Definitely a success that should continue and be widened to more problem pages. I think there are some pages that should remain fully or semiprotected because either the frequency of vandalism makes pending changes impractical or with high profile templates the impact of vandalism is too great. I would like pending changes to be the norm at least for BLPs that have been offensively vandalised, and for approval to be tightened to "I've checked and it is a good edit" rather than the current "I've looked at it and it doesn't look like blatant vandalism".ϢereSpielChequers 14:44, 14 August 2010 (UTC) I like the pending changes feature myself simply because I have seen almost no vandalism on pages in the second month of its implementation, whereas I found many in the first month. Thus, I think it does serve the purpose of fighting vandalism. For this reason, I would typically suggest it be used site-wide only on extremely inactive pages (i.e. maybe five edits a day at most), but sitewide implementation is being considered taboo (understandably). I won't do the analysis of whether semi-protection or PC is better for various pages, but I can say that PC is doing the job of keeping vandalism from appearing, even if it's not reversed until an hour later (something that rarely happens in my experience). Also, if a page is getting too many edits to review, and a lot of vandalism, it can always be requested for SP for a one or two month period, or longer depending on the page. I've had to do this, it happens. CycloneGU (talk) 14:50, 14 August 2010 (UTC) I am in strong support of implementing this feature. It is an excellent alternative to the typical procedures at WP:RFPP and allows pages to be monitored in an effective manner. As an alternative to page protection, pending revisions do not defeat the purpose of a wiki, something everyone can edit. Pending revisions will keep vandalism from appearing to an anonymous reader; but will, at the same time, allow a non-registered user to edit in good faith to edit a page, something that is not possible when a page is under the standard form of protection. I've noticed that pending revisions have actually decreased the amount of vandalism seen here, seemingly discouraging vandals as they realize that their 'changes' will very rarely be seen by the public eye. Tyrol5 [Talk]15:00, 14 August 2010 (UTC) I'm all for keeping it - allowing people to edit is better than shutting them out, and some form of protection is sadly going to be with us regardless. There are some circumstances where its use is inappropriate, for technical reasons or conceptual ones, and there are some forms of maliciousness it doesn't protect against, but it's not meant to be a uniform panacea and in the circumstances where it's useful (pages with "normal" vandalism issues, but also potential good-faith passing edits) it works well. My suspicion is that once we stop having the somewhat forced atmosphere of a "trial" then the turnaround time for edits will increase slightly as it becomes routine work,but on the other hand this will lead to more edits being picked up from watchlists and so forth by editors involved in specific pages, meaning that we'll have more informed reviewing and less of the reported overenthusiastic "not crude vandalism" approvals. Swings and roundabouts. I don't see any problem with lifting the numerical cap on protection, but I think keeping it explicitly as a form of protection for the time being - and so a tool not to be applied to huge numbers of pages on a prophylactic basis - is wise; this effectively means it's unlikely to exceed 5-10k articles, the current protection level. We should come back again and discuss things like applying it to wide sets of articles seperately, a few months down the line, and decouple it from whether or not simply to keep the pending-changes tool around. Shimgray | talk | 15:22, 14 August 2010 (UTC) Keep in mind that not only is it an anti-vandalism tool, it can be used as an alternative to page protection in some cases (see my reasoning above). Tyrol5 [Talk] 16:13, 14 August 2010 (UTC) As an alternative to page protection, I think it would be useful mainly in the area of constant WP:BLP violations, rather than consistent vandalism (where an RFPP may be necessitated). Tyrol5 [Talk] 16:33, 14 August 2010 (UTC) And that's certainly a valid concern, which is why different levels of PC protection were proposed originally (see this). Tyrol5 [Talk] 18:49, 14 August 2010 (UTC) Just to respond to that point about vandalism getting quickly reverted. Yes the vast majority is, but we have no way of knowing when recent changes is unattended or swamped. Today I found an article that was vandalised 18 months ago, pending changes is a better system and will make that sort of thing rarer. ϢereSpielChequers19:40, 14 August 2010 (UTC) It's definitely a mistake to think that vandalism can always be reverted quickly. Among the articles I've applied pending changes to are: the president of a major international organisation called a penis for nearly a day, a school article containing outrageous libel for five months, another school prominently described simply as "full of slags" for ten days, the leader of the opposition in Israel with a vagina for a photo for six hours, and the White House Chief of Staff labelled dead for a while (a similar edit to the President's top advisor lasted 3 hours). It's stuff like that that slips through the net and does nobody any good. With pending changes we don't have to lock them up to all new users. -- zzuuzz (talk) 18:49, 16 August 2010 (UTC) I think generally it's worked quite well, though I think WereSpiel has the right of it around some of the issues that have come up. I think it's a pretty good system, though I think some of the guidance and policy advice around what should and shouldn't be approved needs tightening. GedUK 21:16, 14 August 2010 (UTC) I see what you are saying (I couldn't agree more), but keep in mind that this was only a preliminary trial. Tyrol5 [Talk] 04:06, 15 August 2010 (UTC) Could you (or others) provide some diffs of outright vandalism that was accepted? Ocaasi (talk) 04:10, 18 August 2010 (UTC) Support, but it needs to be used correctly. First, I think the list near the top of this page, of improvements that should be made, is a good one. My experience has been that it is kludgier and slower than semi-protection, and therefore, inferior to semi-protection on pages where semi is appropriate. On the other hand, we have plenty of pages where there are not that many watchers, where there are some good-quality IP edits, and where there is also IP vandalism, but not enough vandalism for semi-protection to be justified. Those are the pages where PC would be of value. For those pages, PC is a significant improvement over no protection at all. That's where it should be used, but it largely wasn't in this trial. On the other hand, for pages where semi-protection is reasonable, it should always be used in preference to PC. --Tryptofish (talk) 19:43, 18 August 2010 (UTC) Agree with both Tryptofish above and Malik Shabazz below: use semi-protection for frequently edited pages and Pending Changes (PC) for rarely edited pages and especially pages which are barely watched. I gave up reviewing after an initial bout of enthusiasm mainly because I was seeing the same high traffic pages all the time, and soon realised the editors more familiar with those pages could handle it better than I. Also I second the request to change this feedback into an RFC. -84user (talk) 20:26, 19 August 2010 (UTC) I support the continuation of pending changes. There was a lot of good-faith edits made by IPs during the trial, as well as keeping vandalism out of public view, which is a plus for readers. ~NSD(✉ • ✐) 20:36, 17 August 2010 (UTC) I support the continuation of flagged protection. To some extent the trial was too short, since there are clearly still a number of issues that need to be resolved like the speed, UI etc; and editors and admins alike are still just getting used to the system like how to review (when to accept etc) and when to request or grant/use flagged protection. In particularly we need a way to deal with seemingly good faith but poor edits, perhaps some sort of reject with comments option. Of course it's also something that vandals are getting used to, and we don't really know how they will respond (for example it's clearly possible one of the reasons we still get a lot of vandalism is because vandals are unfamiliar with PC so see they can edit an article and vandalise not really understanding few are going to see it if it isn't approved and while there's always likely to be a level of this, it may drop as people get more familiar with PC). I do think it's clear that it isn't always a good alternative to semi-protection and I think Jimbo Wales' comment a while back that we could open the main page up to editing is never going to happen. So all in all I wouldn't mind if the trial is continued, perhaps in an expand form. In particular, I would like to see more wide use of flagged protection in BLPs if not used on all unwatched BLPs then with a very low threshold for acceptance for BLPs (e.g. only one problematic edit which lasts for say at least 1 hour is enough to use flagged protection rather then requiring ongoing problems). As I've already said, I'm not suggesting semi-protection should be abandoned and this applies to BLPs as well. Some may considered widespread use of semi-protection on BLPs better then PC, but from my experience with discussions on this, it seems unlikely that will happen so if that's more likely with PC, why not? Note that I'm also not opposed to the implemention of PC on a non trial basis since IMHO we've seen enough to know it is a useful tool that isn't going to destroy wikipedia. Also if PC is going to be turned off in a month, either we have to make a decision before then or it should be continued until a decision is reached. It IMHO would be a silly waste of effort to turn off PC only to turn it on a few weeks later although at the same time it would be inappropriate for PC to continue just because supporters continue to hold up any failure to achieve consensus to either continue the trial or accept PC. (BTW, for all those comments on the German wikipedia and citizendium, the vast majority of users and contributors to the English wikipedia are almost definitely not familiar with either and therefore have no opinions on us following them. In fact I only actually see one comment on the German wikipedia and one on citizendium here anyway.) P.S. I should mention despite some initial interest I actually barely used PC myself including reviewing etc so I don't think I should be considered the 'converted' P.P.S. While the timing of the trial may not have been the best, it's IMHO offensive to suggest the developers somehow timed this specifically so it was the end of the school year in the US or whatever. Anyone following the protracted development that went into it would know clearly that was just an accident. Also in terms of why the trial was so short, AFAIK this was primarily because of detractors who were afraid that wikipedia wasn't going to survive the trial so a short trial was chosen to try an allay their concerns. Nil Einne (talk) 18:57, 17 August 2010 (UTC) ...>Thumbs up. :-) I have seen very few vandals on important articles since the PC trial has been in effect. Whatever it is doing, keep it up. And for those of you complaining about the workload of vandals, DEAL WITH IT! You realize vandals are the reason that this site is rarely used in schools anywmore, correct? If you keep the vandals off, Wikipedia has a better rep and is more trustworthy. Then, it might have a chance of regaining all the user schools it lost due to vandals. Being a vandal is, of course, a bad thing. However, doing nothing to stop it is just as bad. Don't be lazy, reviewers/admins. This seems to work to a degree, so CONTINUE TO USE IT! If any fixes can be made to it so it works more efficiently, install those measures too. Just do whatever it takes to earn this site's formerly clean reputation back, 'cause it will benefit EVERYONE. I have spoken. Wingdude88 out! --The Wing Dude, Musical Extraordinaire (talk) 04:43, 19 August 2010 (UTC) Keep the feature -- on two pages where I saw it used, Deepwater Horizon oil spill‎ and Stanley A. McChrystal‎, vandalism dropped to very low levels. The feature doesn't merely make vandalism invisible, it discourages repeat offenses per WP:DENY because the vandal doesn't even get his 5 minutes of hyuks before a revert. In other cases it allowed experienced editors to address markup mistakes before they were displayed. It's better than semi-protection because it's less work to review a change than to copy it from the talk page to the right spot in the article. I think that performance could/should be improved by caching the diff of a non-autoaccepted edit. Thundermaker (talk) 20:22, 18 August 2010 (UTC) As a reviewer, our time is not wasted to such efforts but rather well spent. My76Strat 02:56, 19 August 2010 (UTC) I support eventual implementation of Pending Changes, but I have a question: I understand some metrics were prepared for this trial. Is it possible for a summary of the results be published? It's a bit unwieldy to navigate to giant tables of full stats. Perhaps this will reveal some trends that we have not considered before. —Arsonal (talk + contribs)— 09:38, 19 August 2010 (UTC) That doesn't make any sense. It's not as if an accepted edit has to be treated differently than any other edit. It can be reverted as usual, and anyone 'monitoring the page' can see it and change it as needed. ♫ Melodia Chaconne ♫ (talk) 13:58, 19 August 2010 (UTC) Support on all BLP (with no exceptions), and on general topic articles with a long history of back and forth semi-protect/un-protect. DVdm (talk) 14:35, 19 August 2010 (UTC) Using it on highly visible, frequently-edited articles was a mistake and I think that put a lot of people (including me for a while) off the idea. However, using it on slightly quieter pages that have significant vandalism but some constructive edits from IPs/new editors seems to have worked quite well in many cases. I don't think it prevents vandalism, but it prevents it from being seen by the vast majority of readers. I think it's worked reasonably well on articles such as Pixie Lott and, to some extent, Deepwater Horizon oil spill, but about a dozen articles were so swamped with vandalism after the feature was introduced that PC was taken off within hours in favour of semi-protection. 15:43, 19 August 2010 (UTC) Support, especially on BLPs. The little notice that say that the edits will not go 'live' really helps - vandals know that their crap wont be accepted. If there isn't sufficient support for wider adoption, I would like this capability to still be available but constrained by policy to BLPs and other specific cases where indefinite full protection would otherwise be necessary. John Vandenberg (chat) 15:46, 19 August 2010 (UTC) Support. I don't think it always was used in the most effective way during the trial - it's at it's best for for lightly watched pages where vandalism will remain for long periods unreverted. For these pages, it is of great utility. I agree with the critics that on highly active pages it does little to stem vandalism. 138.162.0.44 (talk) 16:08, 19 August 2010 (UTC) Support. It still needs some technical work, in my opinion - viewing difs and reverting/accepting still lags in my browser, compared to other pages. There still needs to be a serious discussion onwhen to use it: lightly watched BLPs? probably. Heavily watched and edited articles? maybe, but only because it does seem to discourage vandals who like to have their few minutes of glory.First Light (talk) 16:35, 19 August 2010 (UTC) Support and at any rate extend the trial for another month or two to give time to review impact at the restart of school year when vandalism is really a problem. Motmit (talk) 17:20, 19 August 2010 (UTC) Conditional support - After my experiences using it, I could really only support it if it were symmetrical. That is, there need to be a reject feature that allows addition of a comment given the reason for the rejection. Requiring use of undo or rollback leads to ambiguity, because essentially the edit is approved, then reverted. Also, when there are multiple pending edits, they need to be able to be rejected invdividually, not rolled back as a group. If those features were implemented, it would have my full support. Yworo (talk) 18:49, 19 August 2010 (UTC) Support - My major issues were technical. The first one was that the "Deny" button (forget the name) was a bit confusing at first. I thought I clicked it if It was a bad change, but you use it to unaccept an already reviewed change. Also, review conflicts did happen, so maybe the first user to review gets a 1 minute lock on reviewing? Something like that would help. Some code work and I think it could work. Allmightyduck  What did I do wrong? 21:32, 19 August 2010 (UTC) 12:05 PM Support - while it didn't defer most of the vandalism it did work in getting rid of a fraction of the vandalism especially on high risk articles, I think it should definitely be used by default on BLPs since many editors have been subject to criticism over libelous or otherwise controversial edits on topics pertaining to this touchy area. Heads of government or state and other people of notability amongst the community should also have pending changes enabled by default since articles like George W. Bush (where vandalism peaked post-presidency) are always big targets. I think Pending Changes worked effectively. Fridae'§Doom | Spare your time? 23:05, 19 August 2010 (UTC) Supporting because it is helpful but closer to being neutral Even though it is to slow it still worked pretty well. And it is a great idea. I'd say just a few tweaks would make it work better.Mr. R00t Talk 23:33, 19 August 2010 (UTC) Support It has proved to be a useful alternative to semi-protection. There are some articles for which it is not useful, due to traffic. But in those cases administrators will become used to exercising the feature properly.--Mkativerata (talk) 00:16, 20 August 2010 (UTC) I quite like PC, but I do have to echo a few concerns above. the Accept/Unaccept buttons and comment box seemed quite pointless, I can't think of any times that the Unaccept button would be used, and the comment box should generally just be "looks good" or some such, since the edit summary should have already explained the change. The "Accepted Version" at the top of the page does imply that the page has been peer reviewed. Since the scope is currently to accept anything that isn't patent nonsense or vandalism, I think "No Pending Changes" would be more appropriate than "Accepted Version". On that note, I feel that there should be a very clear steer (based on some further discussion) as to whether we should be properly reviewing the edit or just checking for nonsense/vandalism per Scott Mac above. I see that some people are properly reviewing (myself included) and although it leads to a possible walled garden, the alternative is to basically push vandals into creating much more sneaky vandalism. -- WORMMЯOW 11:29, 20 August 2010 (UTC) Indifferent to weak support for BLPs only. My ideal I think is still semiprotection for all BLPs - this struck me as somewhat slow and cumbersome. I do wonder if more generous use of semiprotection would dissuade some potential new editors, so I'd be happy with using Pending Changes on all BLPs as default, but I think it used up more time than it saved elsewhere. I'd support a trial of all BLPs under PC for next few months. Casliber (talk · contribs) 14:19, 20 August 2010 (UTC) Support I think the community should accept this as an excellent tool to stave off page protection. I do think editors need to be bludgeoned with the idea that only vandalism and sockpuppetry should be rejected, and that acceptance of contentious non-vandalism is productive use of review rights. BigK HeX (talk) 14:24, 20 August 2010 (UTC) As earlier I read that this feature is an alternative to semi-protection of a page, and I have experienced most of this feature can be used as an alternative to semi-protection. Moreover This feature is more useful for unforced-involuntary-automatic-standardization of edit/addition of content. I like it!!!.--Ranjithsutari (talk) 17:35, 20 August 2010 (UTC) Feedback about slow and useless comment boxes/unaccept buttons is spot on, but other than that I think this is going pretty well. The instructions seem quite byzantine, but as a practical matter it's pretty simple and I almost never have to deal with multiple edits. One nit is that it says to discern the reason for the protection, but it is usually pretty hard to do this; ie, checking the discussion page usually doesn't help with this. So I would say to try to remove this from the directions. Just check for obvious vandalism. If sockpuppetry is the only problem, this is the wrong tool. ErikHaugen (talk) 17:40, 20 August 2010 (UTC) I think it's a very useful tool; the trial has shown it to be very good for some purposes (but not others). I would strongly support continued - and wider - use of pending changes. Of course, there should be discussion about exactly how it's used, what pages it should be used on, and how people should review. :-) bobrayner (talk) 11:39, 16 August 2010 (UTC) I'm all for it. It doesn't particularly work on the most vandalised pages where semi-protection is better, but pending changes is ideal for articles which aren't widely watched where libel and other vandalism can often sit for months and do real damage, and where new and unregistered users can still make improvements. As an alternative to indefinite semi-protection it makes a great addition to the admins' toolbox. -- zzuuzz (talk) 16:13, 16 August 2010 (UTC) I'd seen some vandalism spot up on PC articles. It is a great anti-vandalism tool. —I-20the highway 21:40, 16 August 2010 (UTC) I agree that the UI is seriously unintuitive and needs to be rethought from first principles. Nevertheless, I support the current limited practice of Level 1 protection as an alternative to semi-protection. It's easy for us editors to forget that passive readers of Wikipedia outnumber us more than 100-fold. This trial has protected those readers from the lies, obscenities and just plain bad writing that would plague prominent pages if they were unprotected, while allowing good-faith anonymous edits with minimal delay. This can only be good for both Wikipedia's reputation and the size of its editorship. – Smyth\talk 10:10, 17 August 2010 (UTC) Support - Would like to see it speeded up so does not take as long to see the difs. Codf1977 (talk) 15:59, 17 August 2010 (UTC) I would not oppose, but I would not support abandoning semi protection either. Whether or not the approval system is changed, I generally try to avoid approving any edits that don't appear good to me, rather than relying on whether it is blatant vandalism or not. Had a bit of trouble figuring out how to fix up a mistake I once made on this front, but I worked it out eventually. I also noticed speed issues with diffs loading, but that seems to have improved. Finally, I think it's a mistake to assume that vandalism is always reverted quickly. Ncmvocalist (talk) 18:02, 17 August 2010 (UTC) Support - I don't feel in any way that pending changes was unsuccessful. It fulfilled its goal in preventing inappropriate edits while still giving "Anyone" the opportunity to edit the article, unlike semi-protection. I generally found it easy to use and relatively simple, and although some small issues have been brought up, I don't think anything shows that PC failed. Initially I opposed the idea of this, but this trial makes me think that it isn't so bad in the least. SwarmTalk 06:37, 16 August 2010 (UTC) Support, Unequivocal, The trial went much better than pessimistically presumed by many. Many of the suggested improvements have been addressed and implemented during this trial. All projects endeavor to improve, therefore anticipating improvements is intuitive. No additional trial is necessary to show what has already been shown, which is that the "Pending changes" protection is effective, beneficial, and overall productive in total. Perhaps no article should be added unless there can be shown a specific request to do so, and requests to remove such protection should be emphatically considered. Under such guidelines, I can hardly see valid opposition. My76Strat 19:53, 18 August 2010 (UTC) Correct me if I am mistaken, but don't editors editing PC articles get to see their changes on their screen immediately? Ideally, the review is completed within a few minutes, and then everyone else sees it, too. This of course assumes beneficial edits, not vandalism. CycloneGU (talk) 13:28, 20 August 2010 (UTC) I thought it was pretty successful, while some vandalism undoubtably got through the cracks the situation was fairly obviously better than having no protection at all where it would all "get through". As one of the people who got iPad up to GA I thought it worked pretty well at allowing good IP editors to make contributions - even though there was a decent amount of vandalism to revert. Additionally quite a lot of "good faith" edits that were wrong (such as dodgy links/WP:CRYSTALBALL violations) were also caught at review which is good. I would say outright vandalism on iPad went down and I'd guess there were more borderline edits. However as its spent so little time unprotected its difficult to know. The major bad thing was the speed of doing the review, really that needs to be speeded up. -- Eraserhead1 <talk> 14:24, 15 August 2010 (UTC) The trial has been a success, insofar as nothing blew up, vandalism was caught, i.p.s made some edits, and a new feature was explored. However, given the large list of interface issues, speed issues, reviewing guideline confusion, and general hesitation to expand this feature without full community support, we should advance slowly. I recommend that we continue the trial for 6 months with no further expansion. I would personally prefer that we expand it to 5000-10000 pages, to see how this thing scales, but I think that given the numerous complaints, it is more than fair to try and make PC better before we make PC bigger. After 6 months, which will provide more data, school-year vandalism tests, and time for better documentation and bug-fixes, we can re-evaluate. By then, perhaps the community will be okay with an expanded trial, or a blp-focused expansion, or a patrolled revisions (review without pending) type of test. Ocaasi (talk) 06:07, 16 August 2010 (UTC) I'm strongly in favor of continuing this, but I think we need to rethink how it's used and where it fits into the existing RC patrol processes. Honestly, I'm thinking that while using this to mitigate the impact of semi-protected and full-protected articles is a very good thing, it's shortsighted to think it's the only use. Featured articles as well as very low traffic articles on specialist topics (where an RC patroller can't determine if an edit is appropriate simply at face value) would be good areas to discuss the value of pending changes protection. Triona (talk) 07:08, 17 August 2010 (UTC) The trial was largely useless. The original objective of flagged revisions was to protect many BLPs, not anything about "opening up editing" that it turned into to spin it to the press. We should continue to use it, but on a much more massive scale. All BLPs with less than 5 watchers would be a good place to start once the trial is over. Also, can we convert this to RFC format please?NW (Talk) 00:00, 16 August 2010 (UTC) I have a number of articles on my watchlist where for years, every few weeks or months, very problematic BLP material has been inserted by varying IPs. (e.g. Wisconsin Hoofers) It will take time to find out, but my hunch is that once the person(s) realizes that the edits are never, ever visible to the public, these attacks will drop off. For this kind of situation PC beats semi-protection, and avoids situations where the material stays in an article for days before somebody notices (as happened recently when I was on wikibreak). I agree comments about the slow loading and lack of clarity about how to revert/accept things. --Slp1 (talk) 20:21, 15 August 2010 (UTC) Oppose Oppose This only increases clutter on the history page and creates more burdens for those watching articles. I personally see at least as many "good" IP (or redlink) edits as "bad", and see no problem with the old simple system of WYSIWYG. As I noted elsewhere, I support the KISS principle, which works just fine in this case. Crum375 (talk) 22:24, 22 August 2010 (UTC) Oppose continuation: Non-existent, or at best totally inadequate, protections against censorship, instead of ensuring that it is used for nothing more than vandalism protection Inadequate guidelines/process for choosing editors as reviewers, in order to prevent picking people who will abuse tool Waste of time and resources, with no clear benefit -- yet another layer of bureaucracy that will suck away community time Increased complexity Discourages new and anonymous users from editing, while doing almost nothing to prevent vandals Directly contradicts Wikipedia's mission of being an open encyclopedia that anyone can edit --Jrtayloriv (talk) 17:28, 22 August 2010 (UTC) Though I have little personal experience with the Pending Changes process, not being a reviewer and not significantly looking at pages that it has effected in the trial, I do not think that it should be implemented further than the trial. It seems to me that, from the comments I have read, a main objection is that it does not help, as it either hinders edits too much or too little. The idea of which pages (high or low traffic) to use it on is also a question people have had about its future use. Again, I have no way of knowing any more than anyone else about it, but it seems that PC would not be useful, as seen in the two following points: If it were used on low-traffic pages, it would be likely that the people reviewing a page's edits would not really know much about the subject anyway, and so would not be able to make a good judgement as to whether the edit (barring very obvious vandalism) was reasonable or not. If it were used on high-traffic pages, incorrect edits would most likely be caught soon anyway, and be able to be corrected almost as easily, if not more easily. Thus, I oppose the Pending Changes process. Layona1 (Talk) 04:09, 22 August 2010 (UTC) Oppose. This seems to make the editing process too complicated for all involved, especially since users still have to revert vandalism regardless of the pending change status. Additionally, as others mentioned, this will potentially drive off good users if they don't see their edits show up. Better to lock them out entirely with an explanation and send them to the talk page than saying that their edits are awaiting approval. SchuminWeb (Talk) 23:42, 21 August 2010 (UTC) Until we get software features to remove blatant vandalism edits from a page's history, I'd have to regretfully oppose further implementation until we can get something like that developed. As Jeske said, an article's history of a highly-vandalized article (like with my experience with the RuneScape article – one of the very first PC-protected articles in the trial) just becomes clogged with vandalism edits, making it near impossible to conveniently and reliably track recent good previous versions of such an article. As I have also pointed to, I would like to see Pending Changes be implemented more as a pathway for a longterm semi-protected article to become unprotected and hence allow more people to edit. However, I don't think the rest of the community may be on the same wavelength as me, nor do I see much motivation for users to try and make any efforts to unprotect some longterm semi-protected articles. –MuZemike 00:40, 22 August 2010 (UTC) Oppose Increases the clutter of the history. Until we can filter vandalism out of the the history, this is a huge problem. I would prefer semiprotection. Also, it introduces the idea that we've "verified" the change when all we've done is verify that it is not nonsense. Nonsense is not what we are concerned about mainly because nonsense is obvious. It's things that appear true but aren't, or are true but violate other policies, that we are concerned about. Introducing more tracking of which edits are being truly reviewed and which ones are slipping through the cracks is important, but this doesn't do that. Plus, poor interface. II | (t - c) 17:57, 21 August 2010 (UTC) He's saying that accepting the edit gives the impression that it has been vetted and verified. Reread his comment. —Jeremy (v^_^v Carl Johnson) 19:28, 21 August 2010 (UTC) "Three-quarters" prot isn't likely to see use. "Quarter" prot is too ineffective to even be a "quarter" because it jams the history full of garbage and/or more serious material, such as BLP violations. —Jeremy (v^_^v Carl Johnson) 19:28, 21 August 2010 (UTC) That's not what I'm referring to. Even if the edit is reverted instead of accepted, the bum edit remains in the history (since we're obligated by the licenses to maintain a list of all authors), as will any other edit that a reviewer rejects. As a result, the history will be more difficult to browse through because of all the vandalism. —Jeremy (v^_^v Carl Johnson) 19:57, 21 August 2010 (UTC) Alright, then, you want Cliffsnotes: PENDING CHANGES CLOGS THE HISTORY WITH VANDALISM AND BLP VIOLATION EDITS. (I concede the authors point, but not the revision pollution one.) —Jeremy (v^_^v Carl Johnson) 20:21, 21 August 2010 (UTC) Actually, it does, since all edits remain in the history. Even if the article sees only one bum edit every few days, those edits add up. —Jeremy (v^_^v Carl Johnson) 20:58, 21 August 2010 (UTC) Believe me when I say, chummer, that the objects in the history can be just as much concern as on the actual page. —Jeremy (v^_^v Carl Johnson) 03:14, 22 August 2010 (UTC) I couldn't have put it better myself. CycloneGU (talk) 23:03, 21 August 2010 (UTC) Oppose. It takes manpower of experienced editors, and places additional roadblocks in the way of anonymous editors. I realize vandalism is a huge problem, but it isn't that hard for vandals to get autoconfirmed accounts. FluffyWhiteCat (talk) 04:14, 21 August 2010 (UTC) Speaking from experience, Cyclone, no they don't. I see autocon-busters all the time; they spend their first ten edits tweaking their talk page or wikiGnoming on an article before they start spreading havoc. —Jeremy (v^_^v Carl Johnson) 19:30, 21 August 2010 (UTC) Oppose. It is designed to allow IPs to edit semi-protected articles, but as IP's are generally unregistered, they may have no idea what it means, or whether or not they have done everything correctly. It's fine if you are regularly wiki-active, but for first time users it may be quite baffling. Furthermore, the entire thing just seems tedious. Vandalism is easily reverted without the feature and the review process must be as (if not more) time-consuming as patrolling recent changes. I, EnglishmanWouldst thou speak? • Handiwork 00:23, 21 August 2010 (UTC) Oppose Will the technical issues (slow, etc.) really be resolved? Will clearer reviewing guidelines be written soon? If they are, someone please show me two statistics: amount of vandalism compared to the same page using semiprot for the same amount of time, and the amount of time saved by reviewing edits rather than just rollbacking them. Let's get this straight: there is significant opposition to using this widely, so it is used on heavily viewed pages. Unreviewed edits must be reverted anyway. So, there's no time-saving involved. People will still vandalize the same articles, and think it's funny. Overall, pending changes is just not effective or appropriate at this time. —fetch·comms 23:43, 20 August 2010 (UTC) Speak for yourself and not others. —Jeremy (v^_^v Carl Johnson) 21:12, 20 August 2010 (UTC) Note my comments about rapid attacks and sockpuppets above. PendingChanges is useless against either. —Jeremy (v^_^v Carl Johnson) 20:18, 21 August 2010 (UTC) It only works well because nobody's sussed out a way to bypass it. As I stated below, Murphy's Law in regards to our antivandalism measures has never been proven fallacious. —Jeremy(v^_^v Carl Johnson) 20:18, 21 August 2010 (UTC) As a form of protection it's useless. PC just clogs the history with drek and will only increase the workload of admins, nonadmins, and Oversighters alike. The downsides are far too serious and outweigh the upsides. —Jeremy (v^_^v Carl Johnson) 20:18, 21 August 2010 (UTC) I'd drop the idea. Too much complexity (especially removing the feedback of seeing changes) chasing too little of a problem. Vandalism already gets quickly reverted. North8000 (talk) 15:46, 14 August 2010 (UTC) From the ones that I've seen, I'm having a hard time thinking of page protections situations where this would be applicable / useful One other note, right now you are polling the converted. Persons interested in this, and used to dealing with the complexities to the point where you can't understand that they are complexities. If you would liked a sampling of the rest, I'd cast the RFC net wider, and provide a simple 1 paragraph summary of what this change would mean. North8000 (talk) 16:23, 14 August 2010 (UTC) I think that aa lot of the problem folks on those are auto-confirmed accounts, and and nothing "higher". E.G. that's what I am. It's unclear whether or not their edits would need to go through the gauntlet. North8000 (talk) 18:31, 14 August 2010 (UTC) It wasn't as bad as I expected but I still do not like it. 1)There were certainly issues with how slow the pages were. 2) The principle is still terrible in my opinion. 3)There is confusion on if you are expected to accept poor edits that are not vandalism or not. 4)It is turning into sign of endorsement for editors and some will lose it since the community wishes to punish them. That is a a weird path to go down. There is an ANI about stripping a user of their access. It looks like the editor has made mistakes but he did not misuse the feature. Cptnono (talk) 19:17, 14 August 2010 (UTC) Oppose. In my views, the cons outweigh the pros. First, it complicates matters (especially with the mislabelled Accept/Unaccept buttons). Second, the speed is still a problem (yes, it's faster now but still noticeably slower than before). Third, non-obvious vandalism edits such as inserting wrong information are easily approved by people who're not familiar with the topic and so it slips through the cracks, only to be later on reverted by another volunteer. In a way, you're using 2 units of time to revert such kind of edit under the Pending Changes scheme when it could have been done in 1 unit of time under the Semi-Protection scheme. Some have also reported that if 2 reviewers are trying to disapprove an edit, the result is that the undo gets reverted and vandalism goes through. OhanaUnitedTalk page 04:18, 15 August 2010 (UTC) Not very useful My experience with pending changes was with dealing with an edit war with some IPs on the article Highschool of the Dead. Many IPs were adding certain genres despite not giving any reliable sources to back up their edits along with changing the air dates of the episodes despite that they contradict the source given for the air dates. I had requested special protection, but the article was placed under pending changes. To say the least, it did not stop the edit war at all. Eventually, we had to add a note about adding new genres in order to discourage editors from adding genres, which didn't help, and to keep "Reviewers" form automatically accepting the pending edits. All in all, it was a complete failure. —Farix (t | c) 22:39, 17 August 2010 (UTC) For example, I've already had to revert two attempts today to include a genre category by a particular IP which didn't provide a reliable source. Both edits by the IP were automatically accepted by a reviewer without even looking at the ongoing issue. I when ahead and unaccepted the last edit as it was clearly inapproriate. If editors are going to accept pending changes without doing some basic investigating over the validity of the change, then pending changes simply won't work. —Farix (t | c) 18:48, 18 August 2010 (UTC) I believe the problems far outweigh any benefit from it in its the current form. In the best case scenarios, for example, Microsoft, all it basically did was hide vandalism for an hour or two and maybe discourage vandalism in general. However, it may have discouraged good edits as well, we don't really know. It didn't meet its goal of preventing "certain kinds of vandalism or inappropriate changes" because stuff was simply "accepted" too quickly, nearly instant, and sometimes even outright vandalism got through. A lot of this was due to the unclear reviewer guidelines. It also likely led to make people to not look at accepted edits, thinking they were actually good when they often were not. It might work in its current form on other wikis with different cultures. I just don't see the reviewer part working out; as said en doesn't handle "bit bureaucracy" well. However, in its current form but without the reviewing part it might have some benefit on en. Ryan Norton 09:21, 18 August 2010 (UTC) What's the point in imposing more bureaucracy and the increase in workload? If registering an account is the biggest hurdle to be able to start editing, then I'd say we leave out edits from IP-only altogether. I know that's an issue that's been discussed over and over again [there's even an Oukaze on that, right?] but in my field of play IP-only editors are the ONLY vandals. Qwrk (talk) 16:32, 18 August 2010 (UTC) Oppose its use as a substitute for semi-protection on high-profile, frequently vandalized articles; support its use by default on all BLPs. On articles such as Malcolm X and Israel, the substitution of pending changes for semi-protection has required editors to revert large numbers of vandalism edits. Semi-protection saved a lot of work by preventing those edits altogether. — Malik Shabazz Talk/Stalk 20:10, 18 August 2010 (UTC) Personally, I like the second idea. The first is most certainly not worth it; the seocnd is the better, although I still don't think that pending changes should be kept at all... ~~ Hi878(Come shout at me!) 20:05, 18 August 2010 (UTC) As someone who regularly edits articles within various scientific and international areas of interest, I find the premise of purposely singling out low traffic articles objectionable. The idea that someone out there might be discouraged from anonymously contributing specialized knowledge to articles like MON 863, Cry3Bb1, Hailong Market, Haidian Christian Church, Solar cycle 24, Hexatriacontanoic acid, Aluminium acetotartrate, Camp Rustamiyah, Vimbayi Kajese, mu Opioid receptor, Yangonin, Flavokavain B,Dihydromethysticin, Salvadora persica, and FKBP1B disturbs me. Moreover, if reviewers are encouraged to evaluate content on any basis of quality, then we can say goodbye to many of our anonymous contributors that speak English as a second language, and consequently, many of our international articles that require the knowledge of a local. Similarly, if reviewers are encouraged to evaluate content on the basis of whether or not it is factual, then we are going to see gross POV-based decisions become commonplace. The fewer people that view an article, the easier it would be for a reviewer to veto or extinguish an unpopular viewpoint. — C M B J 07:54, 20 August 2010 (UTC) I think that for the most part, this has just been a hassle. Using it on high-traffic pages gives us more trouble than good, because of the high volume of edits that would need to be reviewed. However, using it on low-traffic pages where vandalism goes unnoticed for a long time would be preferable; pages that occasionally get some vandalism that isn't noticed for a while, which do not get semi-protection, seem as though they would be better. However, I still don't think that pending changes should be used at all. Even though there are good reasons for using it in certain spots, such as what I just mentioned, I just don't like the whole idea of it. It seems wrong. ~~ Hi878 (Come shout at me!) 20:10, 18 August 2010 (UTC) The problem is not the workload, but the southward effect that this would have on all IP contributions, beneficial and baneful. It's safe to say that Wikipedia's success has mainly been tied to instant gratification (i.e. edit an article, see your edit immediately). It is also for this reason that projects embracing the opposite have stagnated (i.e. Citizendium). If a beneficial IP finds that every edit he makes has to go through a bozo-filter before it shows up in the article, the likelihood of them editing is going to be decreased. Also, as has been pointed out FraggedRevisions can be a severe hindrance if the wrong people staff it - those who have preconceived notions, those who view it as "quality control", and those forced to take the tools and use them. Lastly, unlike most of the other antivandalism measures the Foundation has used FraggedRevs is the least effective due primarily to the press and the hype. A vandal will either attack nonrev'd articles or, worse, attain the userright and cause mayhem. —Jeremy (v^_^v Carl Johnson) 20:37, 19 August 2010 (UTC) For some vandals, wasting volunteer time gives them their jollies. —Jeremy (v^_^v Carl Johnson) 21:20, 18 August 2010 (UTC) Then you are the kind of person who gives the vandals I mentioned immediately above their jollies. —Jeremy (v^_^v Carl Johnson) 19:21, 20 August 2010 (UTC) Oppose the feature. Of the times I've seen it used, it fails to stop vandalism. -FASTILY (TALK) 04:32, 19 August 2010 (UTC) Oppose - I was open-minded about how the trial would go, but now I've seen pending changes in use, I think we're better off with the established system. The problem with pending changes is that in my opinion, a vandalism check is not sufficient grounds to give credence to an edit by deeming it "Accepted" by a "Wikipedia Reviewer". Even if not vandalism, an edit can be potentially misleading and harmful. Better to let those tending the article monitor edits as usual, than introduce potential to mislead both the general reader and the editor who made the change by deeming it "Accepted" even though someone who knows better may still challenge or revert it. PL290 (talk) 12:33, 19 August 2010 (UTC) I think his point is that having a notice saying "THIS IS THE *ACCEPTED* VERSION" along the top will tend to lead the casual reader to think that it's been peer-reviewed, or something like that, so their likely to give anything they read in it more credence, thus potentially increasing the damage done by sneaky inaccuracies.☻☻☻Sithman VIII !!☻☻☻ 15:05, 19 August 2010 (UTC) Those "other specific cases" were attempted and had to be rejected as test subjects because the vandalism overloaded the FR. —Jeremy (v^_^v Carl Johnson) 21:38, 19 August 2010 (UTC) Oppose wide use of this feature. In my observations, the PC feature works well ONLY for high-traffic articles that are watched by a significant number of users. Even there it does not always work out well - often it turns out that most edits by non-autoconfirmed users are either plain vandalism or additions of unverified info and thus have to be reverted; ordinary semi-protection works better in such cases. The biggest problem is that a wide use of the PC feature (e.g. adding it to all BLPs) would require too much extra work on the part of the regular users who are already overloaded and are decreasing in number. Basically it would create a new HUGE area of backlog, at the time when already existing backlogs all over the project are growing and threaten to become unmanageable. Something like that might have worked when the project was still in a rapid expansion phase, but it does not work now, when the project is in a slow and possibly accelerating decline phase in terms of the number of regular participants. A wider use of permanent or long-term semi-protection is a much more viable option under the circumstances. Nsk92(talk) 19:31, 19 August 2010 (UTC) Using it on particularly-liked or -disliked politicians would end up overloading the FR, as those articles are subject to heavy amounts of editing. You think Barack Obama and Bush weren't already tried? —Jeremy (v^_^v Carl Johnson) 19:36, 20 August 2010 (UTC) Murphy's Law indicates that they'll create sneakier vandalism or otherwise defeat antivandalism measures with or without FR. Thus far, it hasn't been proven wrong. —Jeremy (v^_^v Carl Johnson)19:49, 20 August 2010 (UTC) Oppose- I tried it and didn't particularly care for it. It was confusing, slow, and didn't seem to serve any kind of useful purpose. Reyk YO! 14:01, 20 August 2010 (UTC) Using FraggedRevs as quality control is a variation of soft censorship and highly inappropriate. I'm not the first one to have brought this up. —Jeremy (v^_^v Carl Johnson) 20:39, 20 August 2010 (UTC) What I gathered from the trial is that it adds another layer of complication that is burdensome and unnecessary. Regular page protection works just fine and can be used in all situations, whereas I found it hard to identify articles which would need specifically pending changes protection. PC doesn't really work on highly-edited articles because it just creates a ton of extra work that can only be done by a limited amount of users. And the revision history just looks like a mess, which doesn't help much with the revision pollution problem. I do like the fact that it allows highly-viewed articles to be sort of 'immune' from vandalism and it'd be nice if we could just permanently implement PC on just those limited amount of pages, or on all FAs, but that's not likely going to happen. -- œ™ 11:05, 16 August 2010 (UTC) Oppose, would require too much effort by people whose time is more useful elsewhere. Recent changes patrol is very similar to this but it has less, much simpler steps to get almost the same effect, vandalism removal. Also causes many unneeded battles between editors because of what should/ shouldn't be accepted.Sumsum2010 · Talk · Contributions 03:53, 19 August 2010 (UTC) I think it's a waste of time; The complex bureaucracy of the reviewing process is very intimidating, even to me. I can only imagine what it's like for a newbie. It also drives off many would-be contributers who think we're going the way of the german wikipedia. It is confusing, elitist, off-putting, and hasn't made any noticeable difference to the level of vandalism. Toss it, definitely.☻☻☻Sithman VIII !!☻☻☻ 18:57, 16 August 2010 (UTC) In general, it seemed to be more of a pain than it was worth. My particular problem was with articles that had previously been semi-protected because of sockpuppetry. Edits by socks were not detected by average reviewers, and I don't reasonably expect them to be: how many editors actually have the IP ranges for various sockpuppeteers in memorized? Semi-protection blocks those edits (or, at the very least, forces the sockpuppeteer to make a named account so that once he is detected, all of his edits can be reliably and conveniently reverted). Pending changes was just completely ineffective against that.—Kww(talk) 04:28, 17 August 2010 (UTC) I've got a fair number of thoughts, and they cover a broad spectrum, so I'm just going to jump right into "loose conglomeration of bullet points" mode and be done with it. Apologies for the loose prose. First and foremost, this trial hasn't captured and can't capture certain aspects of a real deployment. In particular, without the 2000 page limit, we are certain to see backlogs and blind acceptance (or blind reverting) of edits without checking the immediate prior history. Another point is that we haven't particularly tested what happens when vandals know how PC works. Remember, when vandalism is accepted, it becomes harder to get it off of the article, since not everyone can revert it anymore. The "unaccept" option and the option to leave a note when accepting are both fairly useless. If you want to revoke acceptance, then in practice you surely want to revert, and if you revert you ought to leave an edit summary. If you accept an edit, the reason had better be plain: "no problems here". Both of these should be removed. My major concern has always been that PC will be used to own articles or lock particular editors or opinions out of them. I was pleased to find that I didn't encounter this on any article I was watching. However, I have seen a great number of naive proposals to use Pending Changes as a quality control, or to revoke reviewer permission for reasons unrelated to reviewing or vandalism. Any such practices could become soft censorship over time, so any serious proposal to continue pending changes needs to stomp hard on these urges. I haven't seen any case being made for the usefulness of Pending Changes level 2, and it runs a much greater risk of enabling article ownership. Unless there is a very good reason out there that hasn't been articulated, I think Level 2 ought not to be approved. Of course, I also oppose deploying Level 1 protection, though that doesn't stop me from having the opinions above. Simply put, there is a case to be made for using Pending Changes on unwatched BLPs, though nobody is seriously pursuing that option. In all other cases, it offers only illusory advantages over semiprotection. Semiprotection prevents vandalism and constructive edits equally, and administrators understand this and avoid using it where it is not needed. Pending Changes does not prevent vandalism; it only makes it somewhat unlikely to be seen by the general readership. In exchange for that, it makes reverting (accepted) vandalism a much more arduous and failure-prone exercise for the very same general readership. More disjointed ramblings later if I happen to think of them. — Gavia immer (talk) 05:47, 17 August 2010 (UTC) While it may look like that is the case, the reality is far grimmer. FraggedRevs cannot handle mass attacks on an article (such as from 4chan threads) as the amount of edits made outstrips the capacity of reviewers to address them in a timely manner, and it is far too easily circumvented by autocon-buster sockpuppets who can outright bypass FraggedRevs altogether. In short, while it does reduce IP vandalism, it only does so if they aren't editing the article en masse (as those who attempted to use PC on, well, 4chan found out to their chagrin). —Jeremy (v^_^v Carl Johnson) 20:05, 21 August 2010 (UTC) Then your field of play is very narrow. I've seen countless registered vandals. Also, IP editing is a Foundation issue , not one en.wiki can take up. —Jeremy (v^_^v Carl Johnson) 19:02, 18 August 2010 (UTC) I'm aware this IP-only issue is very much one of the Basic Commandments of Wikipedia, and indeed my 'niche' is just the small specialisation on mountaineering and the higher ranges, and central Asia and Tibetan subjects. Having said that, I wanted to coin my 2 cents in this discussion because from what I experienced it's more of a hassle and a burden than a solution to an intrinsic problem we're facing. Qwrk (talk) 21:08, 18 August 2010 (UTC) Instant gratification doesn't work if it's based on a fundamental lie. Just because it shows up for them does not mean that it will stay in the article, and for IPs making obviously-beneficial edits with a few stylistic errors in them, this can be a major issue. When - not if - an IP's edit gets rejected because he (in the process of expanding an article) misspelled "benign" or a similar highschool or college word, then the façade of instant gratification vanishes and the IP gets jaded by the experience. —Jeremy (v^_^v Carl Johnson) 19:31, 20 August 2010 (UTC) In the pursuit of a vandalism-free encyclopedia where anyone can edit we cannot sacrifice article veracity. If anything, the comment above only serves as an argument against using FraggedRevs on articles about complex subjects. —Jeremy (v^_^v Carl Johnson) 19:43, 20 August 2010 (UTC) For what it was worth, I thought the trial actually did defer a small amount of vandalism. However, in this case, the "small" amount of vandalism isn't enough of a real difference. Maybe, if this process was automated (the process of protecting pages and flagging reviews), it may outweigh the cons (cons being slow pages, tedious processes, and extreme load on the servers). But for now, I will have to say that I Disagree. If only Wikipedia was powered from a crystal ball... A p3rson ‽ 01:00, 16 August 2010 (UTC) Slow, unclear guidelines, essentially meaningless in many cases. Basically, most of the vandalism gets reverted right away, and in many cases, semi-protecting it is necessary because of the level of vandalism. The articles for which pending changes would work well are few, and I would only support its use for BLPs (and not all of them by default), although I'm leaning toward opposing its continuation. —fetch·comms 01:12, 16 August 2010 (UTC) Oppose in all stripes. All it does is shunt the garbage off to the history (which can cause issues with severe BLP material), and I am extremely suspicious of the timing of the trial (it started, remember, as the school year ended). In addition, the responses of several of the supporters and/or detractors of this change seem to think we're trying to chase Citizendium's goals, which I find to be rather insulting not just to Wikipedia, but to the programmers. —Jeremy (v^_^v Carl Johnson) 03:55, 16 August 2010 (UTC) As an aside, I also vehemently oppose, should this end up being implemented, compulsory reviewer rights based off of account age or edits. Not only does this guarantee that someone who is unwilling or unworthy of using the userright is given it, but it will only make some of the issues brought up (such as accept/unaccept ambiguous edits that aren't blatant vandalism) worse. —Jeremy (v^_^v Carl Johnson) 21:25, 16 August 2010 (UTC) Oppose Even on the few pages where it worked, I don't think we gained nearly enough good edits to justify the hundreds of hours of time that went into this by admins and reviewers. (Those hours were made much longer by the sheer slowness of the system). The amount of volunteer time this will consume if widely deployed is incalculable. Shut it down, use semi-protection a tad more, but let's lose this system. Courcelles 04:21, 16 August 2010 (UTC) Other Comment I think, as an anti-vandalism feature, pending changes was not terribly useful. Vandalism still has to be reverted. I think hopes of using it as a generic "less than semiprotection but still protection" feature were less than fulfilled - it was confusing to reviewers, and possibly confusing to IP editors as well. By and large, by the time we long-term semiprotect an article, the article is decently mature and there's not that much left for IP authors to contribute. I still see hope for using PC in the specific context of articles subject to low levels of vandalism, but where vandalism or a persistent canard would have negative effects beyond the norm (particular categories of BLPs, conspiracy theories, etc). RayTalk 09:07, 21 August 2010 (UTC) Comment. Can someone point out to examples of specific pages where the PC feature has worked well? I must admit that I have yet to find one. Many of the people expressing support for the feature in the comments above say that it could work well for pages that are lightly/rarely edited. I think this is a rather untested assumption which is likely incorrect. With rarely edited pages that very few or no editors have watchlisted, edits by IP's or registered but not autoconfirmed users are likely to stay unreviewed for a long time - days, weeks or even months. They can also easily get staggered and nested which will make it even harder to eventually untangle them. I would think that the PC feature could only work reasonably well for a relatively small number of pages - where a sufficiently large number of editors are watching them but the editing traffic is not so high as to make dealing with reviewing new edits difficult. Even for this middle category it is not clear to me how useful the feature really is. One such article, Logan Lerman, was on my watchlist when the PC feature was activated there. Yet, as far as I can tell, almost all IP edits there had to be reverted since then. I think there is an additional psychological effect that is at play here. Most of non-vandalism IP edits, on any articles, consist of adding unverified information. Without the PC feature, when I see such an edit, I do not always revert it - often I sort of let it slide based on AGF. However, with the PC feature, we are required to accept an edit which looks like a higher degree of endorsement. I personally have found it difficult to endorse such edits - so for PC articles I usually revert them as unsourced, so that they don't clog the unreviewed portion of the history log. I suspect that many other reviewers do the same. Nsk92 (talk) 05:53, 21 August 2010 (UTC) I don't think I follow your points: "With rarely edited pages that very few or no editors have watchlisted, edits by IP's or registered but not autoconfirmed users are likely to stay unreviewed for a long time... They can also easily get staggered and nested which will make it even harder to eventually untangle them." Isn't that why PC would be useful, because it prevents unreviewed edits from just sitting there and getting tangled? "PC feature could only work reasonably well for a relatively small number of pages - where a sufficiently large number of editors are watching them but the editing traffic is not so high as to make dealing with reviewing new edits difficult." The balance only has to be in favor of edits/reviewers. Reviewing few high traffic pages or many low traffic pages should be about the same in terms of difficulty. "Most of non-vandalism IP edits, on any articles, consist of adding unverified information. Without the PC feature, when I see such an edit... I sort of let it slide based on AGF. However, with the PC feature, we are required to accept an edit which looks like a higher degree of endorsement." The badge of 'acceptance' has some weight, but unsourced BLP edits should be looked at with scrutiny to begin with, and I'm not sure assuming good faith is the driving motivation when working with BLP edits, in fact, it might be part of the problem. Ocaasi (talk) 09:05, 21 August 2010 (UTC) I don't see the situation where IP edits on a low traffic article sit unreviewed for weeks and months as beneficial. The IP editors would only get confused and frustrated by such a situation, and, after a bunch of unreviewed edits pile up, experienced editors will be discouraged from editing the article further and trying to untangle a pile of unreviewed edits. It is simpler to use regular semi-protection on a wider range of articles. This way people will not be confused and regular editors will not get saddled with a huge new area of backlog. Nsk92(talk) 14:22, 21 August 2010 (UTC) Whatever configuration people settle on, the assumption is it would only work if the reviewer backlog clears quickly. In that case, edits won't pile up. So I agree what you described is a bad situation, but don't think anyone is proposing it. Ocaasi (talk) 14:56, 21 August 2010 (UTC) A lot of this "debate" is being done on anecdotal experience. Here are some graphs. User A1 (talk) 23:47, 20 August 2010 (UTC) We need more graphs, and then need to work out which ones are useful. I started with these, and believe that the magnitudes are concerning. We are adding complexity to a lot of apparently low-traffic articles -- why? Its possible I have made a mistake (I am currently quite tired), but perhaps not.User A1 (talk) 23:55, 20 August 2010 (UTC) Also it appears that the local vandalism ratio is quite constant, except in the very end, suggesting that vandalistic edits are not actually more problematic than any other article, except in the last 200-300 articles in the plot; which is about 20% of what we have currently marked for pending change protection. This seems like we are overusing the tool User A1 (talk) The good: it allows more editors to contribute while keeping vandalism in check. Pending revisions should be accepted by the community. The not so good: editors bitching at other editors accepting not vandalism but maybe not correct edits. In other words, for following the WP:RVW policy as written. Further work needs to be done in establishing a consensus for what reviewing means. I see that as a separate discussion that whether to accept pending revisions. I assume that discussion would take place atWikipedia_talk:Reviewing. Gerardw (talk) 15:35, 14 August 2010 (UTC) I know this is aimed at comments another editor and I made on your talk page regarding infactual edits accepted. It was an attempt to be polite and I felt you replied to us very standoffishly by pointing at a policy with no further comments yourself. My complaint about the policy is something I'll address if pending changes DOES stay, and my comments were not meant to be "bitching" as you say, just constructive criticism. For my part, I apologize if you thought otherwise. I agree that "further work needs to be done in establishing a consensus for what reviewing means". CycloneGU (talk) 16:51, 14 August 2010 (UTC) I'd like to comment on the slowness since I was the one to report it: bugzilla:24124. In truth, pending changes did not made anything slower. Basically, pending changes are all about viewing diffs and archives versions of articles in order to review or revert them. Those pages are not cached so they take longer to load. As a result, users feel that it's slower because they are viewing more uncached pages than before. But the loading speed of each pages remains the same. Most of this problem is solved already. As Chad H. said: "When diffing to the current revision (which is the most common scenario) we can use the parser cache to save some rendering time. In my test page (58,699 bytes), I was able to cut execution time from over 1100ms down to less than 15ms." Revision #69414 reduces long loading times (10-20 seconds) when displaying a diff between the current version and an older version. If you feel the loading time is still slow do not hesitate to report it. If possible, use the Firebug add-on for Firefox like I did, to help identify accurately the source of the problem. Is the cause of the problem your browser, your bandwith or WMF's servers? Yours, Dodoïste (talk) 21:21, 14 August 2010 (UTC) Firebug++. But of note there are similar tools built into Safari and Google Chrome. -- Eraserhead1 <talk> 14:58, 15 August 2010 (UTC) Comment I'm not sure if I acted on a single edit. This was both because I was unsure if I should accept good faith poorly-phrased or borderline-dubious edits and because there seemed to be many reviewers checking pages. By the time I made up my mind on a post, another reviewer had acted and it would have to be relatively obvious reason for me to disapprove an approved edit. An above comment made a good point that the lack of constructive edit summaries muddies the RVV process. Additionally, the number of reviewers to pages in the trial skews the effectiveness of PCs, causing inactive reviewers like me and over-inflating the effectiveness. I can see PC working for BLPs and other places where vandalism may be harmful, but I certainly don't support widespread adoption and I question how effective it is an alternative to page semi-protection since vandals can still edit just to annoy the reviewers that have to then dismiss the edits. Finally, I will endorse Anomie's script which certainly helped point out pages needing review. —Ost (talk) 18:52, 18 August 2010 (UTC) Technically, this thing seems to have worked. However, effectively it has failed. The problem is that we are not clear what we want to do with it. If you use it to cover large numbers of articles (or small number of heavily edited ones) you'll lots of edits to review and the quality of the review will decrease. That's fine if you want to as a tool to decrease the visibility of simple vandalism. But it is worth the effort for that? IS simple vandalism such a big problem? Isn't it reverted pretty quickly anyway? Conclusion: small gain, lots of effort, perhaps many new editors discouraged. The other possible use is to target a small number of articles (or a large number that get fewer edits) and ask people to do quality reviews. Target it on the articles where bad edits might not get spotted, and there visibility for a short time is a real problem. That is use it ONLY for underwatched BLPs. Less edits to review, more care gets taken, less new editors are affected, and we help what we know to be a real problem. My point is that you can't simultaneously use this for 1 and 2. They are contradictory strategies. I'd strongly suggest #2 is more worthwhile. I proposed something similar before atWikipedia:Targeted Flagging - something like that might be worth people looking at again now.--Scott Mac 18:48, 18 August 2010 (UTC) Or on popular pages you just let the people with the page on watch to review the edits - they will still get reviewed pretty quickly. -- Eraserhead1 <talk> 18:59, 18 August 2010 (UTC) No, you can do one or the other. If it is used on popular pages, then you'll have lots of reviewers, and people won't distinguish between "popular" and "sensitive" pages. You can either use this as a mass took, for screening out obvious stuff, or you can use it for protecting sensitive (low traffic) pages where people are told NEVER to approve an edit without actually reading the article, and checking the sourcing. Try to have it both ways, you fail.--Scott Mac 19:20, 18 August 2010 (UTC) There were also a lot of reviewers making, frankly, stupid decisions on accepting vandalism. If this is continued, we should make the reviewer right more strict and less of a giveaway. Solid guidelines on what is OK to accept would also help. Still, I'm against it, as I noted way above. —fetch·comms 22:08, 17 August 2010 (UTC) A small aside on the subject of German Wikipedia: I am not sure what the intended criticism of German WP is in this case. German WP does insist that a comment be provided with every edit, but so do a few other projects, like Polish and Georgian. Regardless, a "comment" can be as simple as a single blank. Varlaam (talk) 02:20, 19 August 2010 (UTC) I'm not sure whether you were addressing me or speaking general. But for clarification, I have no views or for that matter little knowledge of how the German wikipedia works other then an understanding they have had something similar to pending changes for a while now and therefore are often an example, either of criticism or support for such a system. I was partially address this comment "It also drives off many would-be contributers who think we're going the way of the german wikipedia" and another one on citizendium. My point is that whatever you think of the German system or citizendium, I'm quite sure few people here on en.w really care that much about what they do and most people particularly non German speaking non regular contributors are almost definitely don't think we're trying to follow them or whatever. They may dislike what we're doing but they're not going to think, 'oh great, they're going the way of the German wikipedia/citizendium/whatever'. SO while they may be useful for comparison purposes, I'm quite sceptical of any claims that many people actually think we're following them. Nil Einne (talk) 14:33, 19 August 2010 (UTC) Reverting any vandalism is a waste of volunteer time, IMO. Sometiems I spend half my edits a day reverting vandalism, but that isn't going to change, with or without PC. - BilCat (talk) 03:42, 19 August 2010 (UTC) This is a discussion only and not a vote comment - Off2riorob (talk) 01:06, 20 August 2010 (UTC) Read the top, it asks for a consensus which is generally determined by people expressing their support or opposition to an idea or system. If it were a discussion, they would not ask for a consensus over the use of a policy. Mkdwtalk 23:38, 21 August 2010 (UTC) This edit-conflict nonsense has to stop soon!!! Together with the case-sensitivity of titles, there is no more uselessly frustrating and aggravating misuse of editors' time and patience.My reaction was "So?". I came back from a Wiki-break to find a message on my Talk Page that I'd been made a reviewer. I tried reviewing a few pieces, both from the general pool, and (later) when they were more focused on areas I'd edited, and, like the IP editor who doesn't see the results of his or her editing, I was confused, although not distressed, about what I had done, had not done, was supposed to have done, could have done and/or should not have done. It looked as if most of the things I tried to do, pass or review had already been done by someone else, although I did pass a couple of (what at least looked like) small, benign edits and stopped one or two minor vandalizations. Had the trial run longer, maybe I would have got the hang of it, but maybe I would have thought my time better spent elsewhere on Wikipedia (e.g. editing articles, fixing errors, formatting tables, researching details, answering Ref. Desk questions, learning more about how other parts of the system work). —— Shakescene (talk) 11:43, 20 August 2010 (UTC) What you said above begs the question: What about edit-warring on such articles? Is it a violation of CRASH policy to accept edits furthering an edit war, and would doing so make you as guilty of edit-warring as the actual edit-warriors? There's a rather major rub here, because both edit-warring and abetting the edit war would fall under disruption, I'd think. —Jeremy (v^_^v Carl Johnson) 20:43, 20 August 2010 (UTC) Reminder: this is not a vote. Merely a discussion. CycloneGU (talk) 14:40, 20 August 2010 (UTC) Actually no. If you read the top it asks for a consensus. For that to occur, this 'discussion' must show whether people support or oppose the system, and people are simply using the Wikipedia system 'support' / 'oppose' that is used from everything from WP:FAR to WP:RfA. Mkdwtalk 23:36, 21 August 2010 (UTC) I would also like to see a more detailed, specific guideline for reviewers. In my observations, too much sneaky vandalism is being accepted; it seems that reviewers are generally only looking out for obvious vandalism as if this was recent changes patrol. Zzyzx11 (talk) 06:46, 16 August 2010 (UTC) Comment While I don't support the PC feature mainly because of the 'cracks' in its system(users falsely accepting changes, technical issues, etc.), an amount of vandalism does slip through recent changes patrol. Pending changes might be able to keep that in check in a certain measure, but the outstanding issues has got to be resolved first. Bejinhan talks 05:37, 19 August 2010 (UTC) Some reviewers accepted false additions that were clearly false to anyone that had looked at the article. A lot of work was created for little content benefit from the unconfirmed users, at some articles all the contributions from unconfirmed users or the vast majority of it was false additions. When a reviewer is going around reviewing and accepting and adding false content because his edits as accepting are not visible in his edit history it is much more difficult to find and check his previous pending accepted edits. A reviewer could be going around accepting and inserting false content into articles all day long and it would be hard to spot him. Off2riorob (talk) 09:22, 16 August 2010 (UTC) 14:15, 16 August 2010 (UTC) Reviews are quite visible, e.g. 1 Gerardw (talk) 17:05, 16 August 2010 (UTC) Not as visible as edit history. You have to cross-ref the edit history and the review log to get the entire picture. OhanaUnitedTalk page 04:26, 17 August 2010 (UTC) IP-users often correct spelling in the more esoteric pages (e.g.) and are not all vandals or idiots (which is common). Has anyone ever done a thorough study though on it? --Squidonius (talk) 18:58, 18 August 2010 (UTC) I think its a process that has merit but one that needs more thought on implementation methods, what I found was that after the first couple of weeks I lost interest in being an active reviewer because either I didnt know the subject well enough to make an instant decision on the edit(except in the obvious "T 'n A" vandilism) or I conflicted with other editors anyway rather than as a tool for High profile articles I think it would probably work more effectivey with the lower profile articles where there's some delay between the edit and someone reviewing it off a watchlist. At this point in time I'm tending to ignore it altogether and reverting to just reviewing edit via my watchlist as I did before the trial started. Gnangarra 02:16, 20 August 2010 (UTC) Obviously if you are happier looking at your watchlist or whatever then do that, but I have a couple comments. First, you should not have to be a subject expert. The point here is to protect against obvious vandalism, not to make sure the article is totally correct. Sometimes I do make sure the article is correct because I want to, but that is a separate step and you don't have to do that before clicking "accept". I think it would be very harmful to implement a delay, because for legitimate editors we really don't want people to notice this. The point the PC-detractors make about this being an encyclopedia that anyone can edit is a really important one. I would say that if a delay proves to be necessary, we should just abandon PC instead. ErikHaugen(talk) 17:44, 20 August 2010 (UTC) That is a fair point. If the page is protected because of errors about complex subjects, then PC is probably the wrong tool for fighting that. In general, though, there is a balance between veracity and the ideal of anyone-can-edit; I think PC can be useful if the alternative is (semi-)protection, etc. ErikHaugen (talk) 20:33, 20 August 2010 (UTC) Note on this discussion: On reading through this page, I noticed that all the comments left are by autoconfirmed users. Not a single comment from an IP. Got to ask the question. Do they really care? I think most ips don't know this poll is happening. Many i.p.s are 'drive-by- editors, and though they may not care about this discussion, that doesn't mean they don't care about the ability to edit articles without having to go through an oversight procedure. It's up to us as regular editors to think about the effect of policy on users who might not be a part of the discussion. Ocaasi(talk) 11:52, 20 August 2010 (UTC) If the denial of approval criteria is only for blatant nonsense and obvious vandalism, I say keep it. If it's going to be expanded to include "bad edits" I think it's a terrible idea. Editors need the feedback provided by tags and reverts when they add unsourced or poorly sourced or poorly written or factually wrong good faith "bad" edits. 71.111.66.128 (talk) 05:33, 15 August 2010 (UTC) Woah, that was me. I thought I was logged in. Vampyrecat (talk) 05:35, 15 August 2010 (UTC) Comments Procedural issues The 'poll' forming here on the Closure page is not a representative sample of the community; most people here will be reviewers. Acceptance needs broader discussion in the community; I don't know if RfC is planned, or what. The above 'in favour' do not make it clear what they are in favour of; some people object to 'across the board', or specifying ideas of limits, but there are no specific implementation plans that have been put forward. As PC can mean over 9000 different things, we need ultra-clear proposals that we can support or oppose. Observations I'm concerned that it is only too tempting to see this as a quick solution to too many page problems; if a page is getting a bit of vandalism, it's tempting to just apply this, but we don't seem to know what impact that has on productive editors; we know that it has at least some impact, if only for the numbers of Wikipedians expressing their extreme disdain for the whole idea. A somewhat oxymoronic fact I found was, that it can work better when PCs are not reviewed so quickly. When there were many users vying to 'approve' a change as soon as it happened, there was a tendency for the editors to just briefly check if it was vandalism, and approve or reject it. That's fine, in as far as it goes - however, when things slowed down a bit, the reviewers tended to check the edits more thoroughly - for example, validating references or improving the format of the edit. I agree with CycloneGU above, that we need to clarify the expectation of reviewers - whether they just check for pure blatant vandalism, or if they should check further The terminology and interface is extremely confusing, 'unaccept' and the lack of a 'yes/no' type interface; this has been discussed elsewhere, so I won't elaborate here Speed concerns esp. on large articles If it is only used for vandalism, then not only is there the danger of things slipping through, but also people perceive that, because an edit has been 'accepted', it must be OK, therefore may not check it a second time Conclusions I feel that the way forward is with improvements to the system to address concerns raised, followed by a further trial. I find it hard to judge if I would support or oppose other suggestions, without very specific proposals. Chzz ► 05:21, 16 August 2010 (UTC) Note that the pending changes is still active. CycloneGU (talk) 05:26, 16 August 2010 (UTC) Also, this was listed at WP:Central discussion, so it should attract a wider audience. Ocaasi (talk) 15:43, 16 August 2010 (UTC) Some articles are better off with protection rather than review status. A good example is Emma Watson. As far as I can tell, almost all that happens is IPs make changes that get reverted by reviewers. The edit history is mind boggling. I'm sure there are other examples.--Bbb23 (talk) 18:58, 15 August 2010 (UTC)

Wikipedia:Pending changes/Straw poll

Extended content

Data summary A graphical version of the data Position Characters Words Option 1 12720 2108 Option 2, 3, and 4 17661 3064 Notes The content of the straw poll has been refactored to remove headlines and signatures. Participants in the "other responses" section are intentionally omitted, as most of them fall outside the scope of the poll itself. Example 1: Support 1 Deters newcomers. Elitist. Richard75 (talk) 10:35, 22 August 2010 (UTC) Example 2: Support 3 Gobonobo T C 23:34, 21 August 2010 (UTC) Example 3: Support 4, 3, or 2 (in order of preference).   — Jeff G.  ツ 08:45, 22 August 2010 (UTC) Example 4: Support 2 - and revisit again. --Threeafterthree (talk) 02:53, 22 August 2010 (UTC) Example 5: Support 3 or 4 TheGrappler (talk) 16:49, 22 August 2010 (UTC) [Clearly the current arrangement is imperfect; technical improvements are desirable, as would be stronger consensus on how much verification is required of edits before they are accepted - merely checking it's not vandalism is insufficient in my opinion - but neither of these improvements will be delivered by closing the trial down. In an awful sense, the more it gets used, and therefore the more annoying and apparent its problems become, the faster they'll get fixed! Yet its benefits are only likely to become really visible upon large scale implementation - once notable people start complaining less frequently that their biographies have been wrecked, or readers discover that they're less likely than before to stumble on complete dross. We'll hardly notice the fruits of that if it's only applied to a few pages, but larger scale roll-out should make a big difference. It doesn't seem to have cost a catastrophic amount of growth so far, and again we will likely only detect threatened editor drop-off if we expand; then we'd be in a better position (if necessary) to weigh up the benefits of improved accuracy versus reduced editorial resources. This has mostly been a technical trial, not a large-scale, long-term effect trial, and the "it puts new editors off" or "will cause a collapse in the encyclopedia" arguments lack quantitative evidence - as do the "stuff's got better" arguments here in the support section. Since the trial hasn't reached a state where it can give us empirical insight into the long-term effects on article quality and editor turnover, then it hasn't gone on long enough and has probably been used on too few articles to make a real difference. So scale the trial up, continue it, and if empirical evidence is negative 6 months later, we can shut it then. Declaring flagged revisions to be a success or failure at this point is extremely premature. TheGrappler (talk) 17:15, 22 August 2010 (UTC)] Example 6: Support 3 After seeing how it works from an anonymous editor's view, and knowing how much 1.4k is, I support keeping the pending changes tool and expanding how much an anonymous editor can add onto an article. --K. Annoyomous (talk) 05:11, 22 August 2010 (UTC) Option 1 System will be confusing to newcomers. The process practically turns non-auto-accepted users into criminals, making one really have to think hard about accepting them, vs. rolling back. Good idea in theory, but in practice, I'll take a pass on this one. It's confusing, elitist, bureaucratic, off-putting, and unclear. I'll be glad to see the back of it. Is this really worth keeping? discourages new editors from editing. it just hasn't worked. It was confusing, slow, it discouraged new editors from editing and it hasn't really stopped vandalism. Flagged Revs on Wikipedia is pretty useless. I would support its use on good and featured articles (because of the fact they're supposed to be peer-reviewed). The potted trial hasn't made a case for PC level 1, and it has made the case against Level 2 clear. Slow with unclear and not followed standards. Pending changes, in at least one of its currently envisioned forms, is an affront to several of the founding principles of this project. Moreover, even from a pragmatic standpoint, it is difficult to justify such a superfluous allocation of resources at this time. Unfortunately I do not desire the 2-4 alternatives per my comment at Wikipedia:Pending_changes/Closure. Revision pollution... utter ineffectiveness against cabalism, sockpuppets, or out-of-the-blue en masse attacks... severe potential for controlling content... impossible to institute in such a way that it won't drive off the users it's intended to aid... The list goes on and on and on. it doesn't seem useful to me, doesn't stop socks, etc per Jeske Concerned about the implicit hierarchy created by this (content ownership), and similarly, the inevitable widening of scope of edit rejections, de facto, regardless of what policy says; and it's somewhat confusing conceptually; and the user interface/tools are definitely confusing/lacking. This change only raises the bar for contributing and invests more power, as if there weren't enough, in the core contributors. Due to reasons given on the comments page. My second choice might be 4, but why just BLP pages? If it is so wide-ranging, my previous comments on the comments page would hold - if people would be reviewing things they knew little about(forgive me if I am wrong about what rewiewers would be able to know is right or wrong concerning a page's content), in order to avoid vandalism, then you almost might as well do entirely all pages, perhaps, or at least all low-traffic ones? (If you disregard the immense amount of work it would create.) Weak and ineffective at stopping vandalism; the slow speed and technical issues only hinder the rate of reverts. Also, poor reviewing guidelines and blind reviews only let vandalism pass through easily. Unnecessary complication. A Wikipedian approving an edit of a non-Wikipedian before it becomes visible goes against the most fundamental values of this project. Creates extra work for good edits and allows more vandalism to be inserted for articles that should be semi-protected instead. Plus: hiding edits, either good or bad, creates confusion. No real benefit for the creation of tons of busy work. Slow speed and the issues raised by Jeske make it undesirable in its current incarnation. Myfeelings are like Courcelles above, so I am not opposed to closing, but we do a proper trial scaled up for what it was supposed to be for (BLPs), or we drop it, I am not a fan of sitting somewhere in the middle. Such a review process (if indeed practicable in an "anyone can edit" environment) would need far more than a vandalism check. Even if not obvious vandalism, an edit can be potentially misleading and harmful. (Besides, the page may already have other problems.) Yet we would deem it "Accepted" by a "Wikipedia Reviewer"? Methinks not. Anyone can edit: reader beware. Provides too little benefit to justify having to put up with its bugs and the extra work it causes. The only way this could ever be useful is if it were only used in cases where page protection would otherwise be used. Since this is not an option, I am voting to close. I would also like to state my opposition to the way that this poll is being conducted; since all !votes for options 2-4 will be counted together, it will provide a bias in favour of those results. If, for example, someone !votes for option 2, but they dislike options 3 and 4, then their !vote for option 2 would count towards all three when the "keep" and "close" votes are compared, and therefore it could help to cause implementation of the proposal to which they are opposed. I thought we didn't vote. Anyway, this has added a lot of complexity for little gain. Remember everytime you add complexity you have to explain it to would be regular editors. Secondly, the very mission of a reviewer cannot even be agreed upon, some think it is a quick process (diff ooks ok), others think it involves actually reviewing the article for correctness. Finally no-one has presented any evidence of the quality of superiority over regular rollback. Badly thought through, badly executed. Deters newcomers. Elitist. Discourages new users from editing. Adds unnecessary extra work for others. Another unfortunate initiative that drives wikipedia away from being edited by everyone into the realm of being edited by a "wiki elite". Would support a reasonable proposal but this poll is not it - I see only 3 or 4 people commenting on how this poll was created and lots of opposition on this talk page to the bad format. Given that I am not going to give a blank cheque for any "improvements" (which could be anything) I must oppose. If a reasonable discussion took place to produce a balanced proposal I could probably be persuaded to support. Note my attempt to produce an alternative has been removed. Since I don't see any real commitment to improving the interface by adding an orthogonal reject option and allowing pending changes to be approved/rejected individually, I cannot support continuing the use of pending changes. Come back with a new trial once these improvements have been made. Goes against everything WP is about. Wikipedia is improved by its open edit policy, not by adding layers of bureaucracy. Encourage a better or more frequent usage of semi-protection, but flagged revisions should not be used in its current state. It's much too complicated and will create an enormous backlog (which in turn could slow down the approval of good contributions, therefore making it counter-productive). Entering <<Editprotected>> in the talk page was a good system and worked just fine. It's a very nice idea BUT not working. The major issue is that people are approving factually incorrect edits which are then given more "weight" by being approved. I am concerned that this has a small benefit in allowing IP's to edit but a massive disadvantage in making factual inaccuracies more of a risk. I'd support it if the guidelines were much more explicit as to how to approve (i.e. basic fact checking of material) Discourages new users from editing and does not discourage vandals from vandalizing. In the end, the work load of me and other watchers remains same as before. In the end, it is an unjust segregation that is not based on competencies. It just solidifies the belief that Wikipedia is not an encyclopedia that everyone can edit. Non-existent, or at best totally inadequate, protections against censorship, instead of ensuring that it is used for nothing more than vandalism protection; Inadequate guidelines/process for choosing editors as reviewers, in order to prevent picking people who will abuse tool; Waste of time and resources, with no clear benefit -- yet another layer of bureaucracy that will suck away community time; Increased complexity; Discourages new and anonymous users from editing, while doing almost nothing to prevent vandals; Directly contradicts Wikipedia's mission of being an open encyclopedia that anyone can edit. Confusing, ineffective, and mildly elitist (is there anyone who is not a reviewer, except me, of course). Complicated, slows page loads, deters newcomers - you name it. All while not really adding anything of benefit to the project. All energy that went into countless discussions about this could have been used much more productively in working on articles and improving the project. The current protection policy reflects an acceptable compromise between "anyone can edit" and "we need to protect certain pages". The trial has shown that it was not really any improvement and made those pages harder to edit and use. The only way I would support the continued use of flagged protections would be as an alternative to a complete, de-wiki-style implementation of flagged revisions, i.e. as the lesser of two evils. I was in opposition of flagged revisions when that was proposed a while ago, and I'm in opposition of pending changes as well. Isn't the Wikipedia about making edits that appear right when they're made, and not waiting around until a superior reviews them? Semi-protection does a better job, and it completely stops the vandalism by IPs and newly registered users, instead of just holding it out of the view of the readers. I find no positive aspect in clogging up my or anyone else's watchlist with this crap, nor is it any help to the community if vandalism occurs regardless of whether a page is not protected or stuck with pending changes. Too complicated, the page registered editors are looking at is not the same as viewed by readers. Plus, IP editors are pretty effectively cut out of the community. Deters newcommers. Limited effectiveness against vandals. per all above. Too complex, little real benefit. Too bureaucratic, against our mission of an open editing environment. I haven't seen any evidence that it's helping in any way except to fight petty vandalism. Much of the above ... This represents a return to corporate publishings' habits of censorship prior to the personal computer revolution. This return of old ways has shiny, fancy new microprocessors and software as templates to pretend it's a new way. I don't understand it. And i don't think it does anything useful. I participated in this project, but I cannot say I support it. It flies squarely in the face of open editing. Bit too exclusive for my tastes, and I think it has the capacity to quash often interesting viewpoints and edits from IP editors. Useless, a pain in the butt, and discourages new editors. Just more bureaucracy to add to the confusion. In the event the poll is not restarted and this vote stands, I would prefer to scrap the whole beast. Can't see it as a solution to the vandalism problem. Unnecessary, especially if the edit pages misleadingly say, "When you click Save, your changes will immediately become visible to everyone." This is frustrating to sit and wait for someone else to approve it. The system should be rebuilt on a different model. This proposal adds an undue burden on editors and presents as many problems as it fixes. Should only be considered for semi protected articles, and perhaps it could be brought in automatically for articles that get spikes of traffic/spam/vandal slashdotting. More went wrong than went right. More trouble than it's worth, ineffective for most articles that needed semi-protection. Completely inefficient. Provides none of the advantages of protection in addition to a number of disadvantages that render it infeasible. Gives impression to readers that "accepted" status is an approved/peer reviewed version of the article and makes top of article page even more unaesthetic and confusing (especially on small screens). Gives an uncomfortable feeling to new editors. Changes should appear instantly and consistently for all users. Anything else is no less than an insult to the purpose of Wikipedia. Overly complex solution to a simple problem that already had a solution: page protection. The way this poll is being run is biased toward keep. That aside, I vote to remove the feature. Utterly useless, and brings a flood of vandals. I've seen even blatant vandalism "accepted". I like the idea, but I don't think the implementation is ready for prime time yet. Great in theory, but overall it does more harm than good. Simplicity is just too important to lose, especially for stuff likely to be encountered by newbies. Creates new "review conflict", sometimes require an extra pair of eyes who knows the topic to check whether the approved edit was indeed valid or vandalism masking as a legitimate edit. A poor quality system that does blatant harm to the founding principles, is utterly unfriendly to new, good faith users because of a few bad actors, and makes following pages via watchlist a pain for experienced users. Option 2, 3, and 4 Per my comments at Wikipedia:Pending changes/Closure, I am in support of the option. However, it does need some clearer guidelines for reviewers and the interface needs a little tweaking. I wouldn't mind seeing this expand to more articles as well, but full sitewide implementation is not necessary at this time. I guess that makes it a 3 for me. if this option is successful, hopefully after improvements, we can then expand further. with an additional aim and special focus to curb sockpuppetry on pages known to be frequently targeted. and definitely also shift it from high traffic to lower traffic articles. Definitely worth keeping. A great tool, though some extra time is needed to find out what exactly it is best for. In my mind, low traffic articles with BLP concerns (ie not just the BLP articles themselves) are likely the most likely to be a fruitful place for use. though I hope the suggested improvements will be made before expansion of PC material. as a minimum - no objection to 3 or 4 being trialled, tool was useful. It works - not that confusing, became faster in time, does not seem to discourage new editors, and deterred vandalism on the pages I saw it used on, compared with vandal activity in the past foew months on those pages. Certainly needs some improvements, as discussed elsewhere. but where do these vote comment guidelines come from? but seriously consider usability pending changes is a useful tool, but discretion is needed for where it's applied. Pending changes has a lot of potential to help maintain the quality of Wikipedia. As per my comment at the other page, this needs some serious reform before being enabled. However, I would not like to see it be closed, as that is a net negative. However, mass expansion is also a net negative. (There needs to be an Option 5: Other) I admit that I only had, I believe, one page on my watch list that had been semi'd for a while turned into PC. Yes it got vandalized, but it wasn't really THAT much, and definitely slowed down a bit after some time. So long as the the number is left as an amount reasonable to manage -- that is, any semblance of "this'll just cause more more where other is needed blah blah blah so what if people are volunteers " then it's certainly the best way to go. Option 4 might be ok too, so long as that's not the ONLY use for it (that is, all BLP *plus* anything else deemed warranted). This system was perhaps being applied too liberally to areas that should have had a semi-protection, but its use as a tool for cases that should not be open, but still fundamentally follow the principals as a wiki, while still reducing vandalism under guardianship is favourable. and revisit again An effective tool on low traffic pages, though worthless on high traffic, keep PC-2 with emphasis on improvements. Some good and valid points made by those who support option 1 - however, I believe this tool is still positively effective when used on low-traffic pages. If you know how to use it, is useful. From personal experience, I accept about 1/3 of the edits and reject 2/3 of the edits. Without pending changes, that 1/3 (still a significant amount) would be prevented by semi-protection. After seeing how it works from an anonymous editor's view, and knowing how much 1.4k is, I support keeping the pending changes tool and expanding how much an anonymous editor can add onto an article. From what I have seen, this is helping the project. Though I don't like the attitude that seems to have developed which wants reviewers to decide if it's a "good" edit. That belongs in a talk page, not a reviewing hierarchy. I believe in the official guideline, which is to curb blatant vandalism. This protects the pages and allows edits to be viewable quickly. I want to see this work, but the fact of the matter is that there are too many issues with the current implementation to justify expansion just yet. Where's '5'? Future is thataway→ BLPs and low-traffic are the article types where this makes absolute sense (unless RecentUnwatchedChanges or similar gets implemented). I think the idea is sound and needs to be continued. The how of it needs to be tweaked, but we need to get this confirmed to continue before we get too worried about the tweaks. for ultimately being a net positive. I think rollout to all low traffic BLPs is an excellent use of the feature, especially with some of the discussed improvements, but high traffic articles (whatever the type) aren't a good fit. I also think we should leave this in control of humans unless we can agree on a unambiguous metric for "low traffic". This system is a net positive for the project and should be slowly expanded. This has been an astounding success. It should be rolled to BLP's on a large scale. Just, you know, please tweak the little flaws. keeping to low-traffic articles. My feeling is that it doesn't work well on high-traffic articles, and will put off new editors. useful alternative to either semi-protection or no protection in some cases. Revision/clarification of guidelines for reviewers might be in order, though Would consider support 4 once wrinkles are ironed out. 10k is a bit low we do a proper trial scaled up for what it was supposed to be for (BLPs), or we drop it, I am not a fan of sitting somewhere in the middle. I favour this slightly more than dropping altogether. I like this idea but it needs expansion if it is going to stay. assuming the interface can continue to improve. Still could use some work before 4 I don't think it's needed for all BLPs. I think it needs to be improved before being expanded on to all BLPs. Still needs some improvements. when used in the right circumstances it's a very valid alternative to semi-protection. We simply need to strike the correct balance of using it where it's advantageous without overdoing it. pending changes is an extra tool in the fight against vandalism; as such I support it continual usage. I do however oppose any form of automatic protection: this is still supposed to be the encyclopedia that everyone can edit, and protection should only be applied when clearly needed. one of the best ideas on Wikipedia since sliced bread. How can you beat having a system in which, to readers, most vandalism is never seen? I like it, and see no real problems. for whatever reason, it seems, (subjectively), to have reduced vandalism attempts on articles subject to the process. maybe give editors with review permissions the right to protect pages with pending changes if they discover the need for it? The trial succeeded in lowering visible BLP vandalism and the sky did not fall in. Needs work, but an asset that should continue to be deployed on our more "at-risk" articles of all stripes. Prefer 3/4, support 2 if alternative is cutting it off. but prefer 2. This is useful in vandalism reduction, and 99% of pages will be free of it. Preferable to semi-protection in most cases. It worked with preventing BLP vandalism and some vandalism on other articles. there's no real basis for an artificial cap at 2k, and we're unlikely to drastically exceed it in practice anyway, but having the flexibility is better than not. I am happy that there are few significant downsides to continuing the implementation of this system, and significant benefits to be gained. (If not 3, then by preference 2, then 4.) But making improvements is important too—I might support 4 then. Not a substitute for semi-protection—it's a substitute for no protection on some pages. I played no active part in the trial so don't know for sure, but from what I can tell this seems to have worked relatively well Idea is sensible since so many edits come from IPs which are constructive, and because some people don't like to create accounts, often these IPs end up not being able to positively edit a page which is semi-protected. This new system seems to get around this problem and I imagine also tends to prevent vandalised results coming through in search engines such as Google. It does need some improvement though - like what is the unaccept button all about? I think this would definitely be useful for all BLPs. I'd prefer to see 3. I think it should continue with expansion. Make sure reviewing process is a little improved code wise. [Clearly the current arrangement is imperfect; technical improvements are desirable, as would be stronger consensus on how much verification is required of edits before they are accepted - merely checking it's not vandalism is insufficient in my opinion - but neither of these improvements will be delivered by closing the trial down. In an awful sense, the more it gets used, and therefore the more annoying and apparent its problems become, the faster they'll get fixed! Yet its benefits are only likely to become really visible upon large scale implementation - once notable people start complaining less frequently that their biographies have been wrecked, or readers discover that they're less likely than before to stumble on complete dross. We'll hardly notice the fruits of that if it's only applied to a few pages, but larger scale roll-out should make a big difference. It doesn't seem to have cost a catastrophic amount of growth so far, and again we will likely only detect threatened editor drop-off if we expand; then we'd be in a better position (if necessary) to weigh up the benefits of improved accuracy versus reduced editorial resources. This has mostly been a technical trial, not a large-scale, long-term effect trial, and the "it puts new editors off" or "will cause a collapse in the encyclopedia" arguments lack quantitative evidence - as do the "stuff's got better" arguments here in the support section. Since the trial hasn't reached a state where it can give us empirical insight into the long-term effects on article quality and editor turnover, then it hasn't gone on long enough and has probably been used on too few articles to make a real difference. So scale the trial up, continue it, and if empirical evidence is negative 6 months later, we can shut it then. Declaring flagged revisions to be a success or failure at this point is extremely premature. My rationale is in Wikipedia:Pending changes/Closure. This is a good tool for dealing with our BLP problem on lightly trafficked articles, which is most of them. My strong preferance is for number 4, however I would support number 3 as well if there is not enough community concensus for pending changes to be applied to all BLPs. But I would support 3 the most. favoring 3 the most. While pending changes is of some benefit, it should not be rolled out any further until the performance issues associated reviewing changes in large articles (like World War I, where I have found it almost impossible to accept or reject edits) are addressed. favoring 3 the most. While Pending changes is a benefit to rollback to not have to be used as much. I think it should be moved out on more articles. This feature can help others edit pages like Full Protected pages and see their edits appear quicker than normal. I have two articles on my watchlist that get vandalized on a regular basis. Thank God for other editors who also watch them. The way it's set up now, a user has to do pretty much as much work as if the page were just semi-protected normally, or even not protected at all; the system needs to be set up so it auto-reverts 'unaccepted' edits and it needs to be set so you can unaccept edits. Proposal and technology need work. Particular concern is not discouraing new editors. Discouraging to anons, but much less so than its awful alternative, indefinite semiprotection. But for this reason, should be upon request and as alternative to semiprotection only. It isn't being used enough, and is working pretty well. although 2 or 4 are fine as well. The tool, as it is, works. It doesn't work as well as it should, but that's because of holes in the documentation. HalfShadow several votes above has the right idea too. Level 1, however, should not be seen as exclusive to semi-protection; the heiarchy of protection would go free -> PC1 -> Semi -> PC2 -> Full. It better reflects what Wikipedia is meant to be about than semi-protection. There should be no artificially set limit on the number of pages which are included. There should be a list of reasons why an article should be placed under pending changes protection, with articles being assessed on a case by case basis. but also support 2 and 4. It's a useful tool to have around, and is a much better fit to our philosophy than semi/full protection is (although there are cases where those protection levels are still needed). It is rare that there is a backlog of edits needing review. It's a considerable improvement to suffering from libel vandalism to BLPs - both for the article subjects, and also for us (the press love stories about vandalism on Wikipedia a bit too much...). 3 might work as well. The tool works, it just needs to be fixed up. I think the tool is very useful, but it could use a little revising, policy change, etc. Also, when reviewing edits, there should be a "Decline" or "Reject" button in addition to the "Accept" and "Unaccept" buttons to make it easier to undo unconstructive revisions. We certainly can expand this to cover more articles and handle it effectively, but it should still be limited so it doesn't become difficult to deal with. reduces vandalism and improves the readers' experience as well. Has some merit, but ultimately will have limited usefulness. May need to be scrapped altogether, but it deserves more time. Limit to those articles that would otherwise be semied. That way, we are getting the benefits without reducing the number of articles that anons can edit. Pending changes should be expanded as an equal alternative to semi-protection or a trial period before unprotecting indefinitely protected articles. The bottleneck at 2000 seems arbitrary, especially considering the success PC has enjoyed. The trial seems to have for the most part shown that this can work well. Plus it's badly needed, and the status quo is simply not good enough. A review of the closure discussion revealed consistent support for making pending changes faster, fixing the accept/unaccept interface, clarifying policy regarding when to accept edits, and emphasizing use on lower-traffic/lower watched pages and BLPs rather than as a substitute for semi-protection, especially on high traffic pages which receive a lot of vandalism or are the target of sockpuppets or content disputes. This poll is only ground for an extension of the trial, not an expansion of the feature to the entire encyclopedia. The trial is designed to further refine and improve the feature and tailor its use to where it is not problematic and actually of benefit. It that turns out to be nowhere, so be it, but better not to toss a limited trial when things are still being figured out. PC works quite well and is a much better alternative than semi/full protection. It simply better reflects what Wikipedia is all about. It opens up some articles back to edits by IP addresses. As a goal of encouraging new editors to come on board, I think this is a good compromise that will work well for certain articles. and use reviewing to supplement semi-protection. Articles that attract a lot of vandalism by IPs should be protected by the system, rather than reviewers. When some of the requests about making who did what easier to access and more transparent then I would support 3 or 4, but for now 2 seems good. Moving backwards towards anonymous, at-will defamation of living people is simply not an option. System cannot be properly assessed until the number of articles is expanded. Best to do this gradually or in phases, to allow iterative improvement. gradual expansion will let the system evolve as needed. Pending changes and semiprotection are different tools. Expand pending changes where it is helpful, but do not remove semiprotection where it is needed. 4 is a little to much and this helps with removing some of the sper/per requests Agree with PhantomSteve, seems to work better with lower traffic articles. Needs polishing, but otherwise a useful tool. Gradual change in protection is good. It's for the best. Needs work but otherwise a useful tool. Well, I don't know if I really support it, but I think we need to spend more time evaluating it before we can come to any sort of conclusion. I'd like to see this expanded to major BLP articles (say, start class or better) if we keep it around, and to articles on medical or scientific subjects, or to articles where it is requested. Let's see how that works 6 months or so out, and then come to some sort of consensus. I see enough random vandalism on BLP articles I watch that I think rollout to BLP articles is a good idea. I do agree that usability of the tool needs more work, especially for users who are also using Twinkle. We have to do something to avoid bad press generated by Seigenthaler type incidents, and this works better than semi-protection. Most bad edits come from anons anyway, so we might as well flag with them and review them so they never make it into articles. Less hostile to anons than protection, and probably at least as effective at catching vandalism attempts provided admins and reviewers exercise their rights with due thought and care. Provided there is improved policy and guidance for reviewers, and efforts are made to ensure that the vast majority of pages with pending changes are on the watchlists of active editors, I feel this implemementation would be a net positive for the project. with 3 as a 2nd choice and 2 as a 3rd choice.

Wikipedia:Pending changes/Straw poll (as of closure)

Data summary

A comparison based on the final results. Of the 482 contributors who provided discernible input, 56.6% supported options 2+3+4 and 43.3% supported option 1.

Position	Number of users that provided discernible input	Percent
Option 1	209/482	43.3%
Options 2+3+4	273/482	56.6%

Users who voted for option 1 without providing input

Stats: 8/217 (3.68%)

1. Support 1 Bejinhan talks 03:03, 22 August 2010 (UTC)
2. Support 1 – Kerαunoςcopia◁galaxies 17:01, 22 August 2010 (UTC)
3. Support 1 ῤerspeκὖlὖm in ænigmate ( talk ) 19:23, 22 August 2010 (UTC)
4. Support 1 per all above. All Hallow's Wraith (talk) 20:27, 22 August 2010 (UTC)
5. Support 1 As per all of the above. Qwrk (talk) 07:43, 23 August 2010 (UTC)
6. Support 1Bruno talk 16:15, 25 August 2010 (UTC)
7. Support 1 - sss333 (talk) 03:37, 28 August 2010 (UTC)
8. Support 1 --Suomen Joutsen (talk) 06:38, 31 August 2010 (UTC)

Users who voted for option 2, 3, and 4 without providing input

Stats: 134/407 (32.92%)

1. Support 2 The Thing // Talk // Contribs 23:13, 21 August 2010 (UTC)
2. Support 3 Gobonobo T C 23:34, 21 August 2010 (UTC)
3. Support 3--Wetman (talk) 23:35, 21 August 2010 (UTC)
4. Support 3 Doc James (talk · contribs · email) 23:37, 21 A ugust 2010 (UTC)
5. Support 2 —Soap— 23:38, 21 August 2010 (UTC)
6. Support 3 My76Strat 00:03, 22 August 2010 (UTC)
7. Support 3 Ғяіᴅaз'§Đоом | Spare your time? 00:31, 22 August 2010 (UTC)
8. Support 2 - and revisit again. --Threeafterthree (talk) 02:53, 22 August 2010 (UTC)
9. Support 4 Nil Einne (talk) 03:18, 22 August 2010 (UTC)
10. Support 3 ℳono 03:54, 22 August 2010 (UTC)
11. Support 3 ErikHaugen (talk) 04:34, 22 August 2010 (UTC)
12. Support 3--Cannibaloki 05:09, 22 August 2010 (UTC)
13. Support 4 —Where's '5'? Future is thataway→ Cheers, Jack Merridew 05:31, 22 August 2010 (UTC)
14. Support 3 or 4 --Diannaa (Talk) 05:36, 22 August 2010 (UTC)
15. Support 3 — Glenn L (talk) 07:26, 22 August 2010 (UTC)
16. Support 3 or 4 Dodoïste (talk) 07:47, 22 August 2010 (UTC)
17. Support 3. Would consider support 4 once wrinkles are ironed out. TFOWR 08:06, 22 August 2010 (UTC)
18. Support 4, 3, or 2 (in order of preference). — Jeff G. ツ 08:45, 22 August 2010 (UTC)
19. Support 4, and therefore (obviously) 3 and 2 as well. DVdm (talk) 08:50, 22 August 2010 (UTC)
20. Support 3 or 2(in order of preference). Still could use some work before 4-- WORMMЯOW 09:25, 22 August 2010 (UTC)
21. Support 3 Misarxist (talk) 09:54, 22 August 2010 (UTC)
22. Support 4 --Ziko (talk) 10:31, 22 August 2010 (UTC)
23. Support 3 Schapel (talk) 11:17, 22 August 2010 (UTC)
24. Support 3 Willking1979 (talk) 12:20, 22 August 2010 (UTC)
25. Support 3 Graham Colm (talk) 12:25, 22 August 2010 (UTC)
26. Support Prefer 3/4, support 2 if alternative is cutting it off. Xymmax So let it be written So let it be done 12:33, 22 August 2010 *(UTC)
27. Support 3 or 4. - Dank (push to talk) 13:25, 22 August 2010 (UTC)
28. Support 3 or 4. Salvio Let's talk 'bout it! 13:44, 22 August 2010 (UTC)
29. Support 3--intelati 13:51, 22 August 2010 (UTC)
30. Support 4 or 3, Spellcast (talk) 13:57, 22 August 2010 (UTC)
31. Support 4. --Funandtrvl (talk) 14:07, 22 August 2010 (UTC)
32. Support 4, 3, 2 in that order. NW (Talk) 14:19, 22 August 2010 (UTC)
33. Support 3. ~NSD (✉ • ✐) 14:27, 22 August 2010 (UTC)
34. Support 4. The Raptor You rang?/My mistakes; I mean, er, contributions 14:28, 22 August 2010 (UTC)
35. Support 3 or 4 I'd prefer to see 3. Captain panda 15:34, 22 August 2010 (UTC)
36. Support 2, 3 or 4. But I would support 3 the most. —I-20the highway 17:08, 22 August 2010 (UTC)
37. Support 2, 3, and 4, favoring 3 the most. John Carter (talk) 17:16, 22 August 2010 (UTC)
38. Support 2, 3, and 4, favoring 3 the most. Oreo Priest talk 17:23, 22 August 2010 (UTC)
39. Support 4 1exec1 (talk) 17:52, 22 August 2010 (UTC)
40. Support 3 although 2 or 4 are fine as well. Wknight94 talk 18:56, 22 August 2010 (UTC)
41. Support 3 most, but also support 2 and 4. --JaGatalk 20:14, 22 August 2010 (UTC)
42. Support 3 and 4 Mootros (talk) 22:55, 22 August 2010 (UTC)
43. Support 2 Wikiscient (talk) 23:32, 22 August 2010 (UTC)
44. Support 3 and 4. Ironholds (talk) 00:10, 23 August 2010 (UTC)
45. Support 3. DrNegative (talk) 01:10, 23 August 2010 (UTC)
46. Support 3 or 4 mgiganteus1 (talk) 02:13, 23 August 2010 (UTC)
47. Support 2 Openskye (talk) 02:14, 23 August 2010 (UTC)
48. Support 4 Maddie talk 02:41, 23 August 2010 (UTC)
49. Support 4 with 3 as a 2nd choice and 2 as a 3rd choice. Rlendog (talk) 03:44, 23 August 2010 (UTC)
50. Support 2 --Saukkomies talk 07:38, 23 August 2010 (UTC)
51. Support 3, and reconsider going for 4 in the long run. – sgeureka t•c 09:43, 23 August 2010 (UTC)
52. Support 4 . --CutOffTies (talk) 15:38, 23 August 2010 (UTC)
53. Support 3 – allen四names 19:00, 23 August 2010 (UTC)
54. Support 3; willing to accept 2 or 4. WhatamIdoing (talk) 19:55, 23 August 2010 (UTC)
55. Support 2, but keep talking about 4. Someguy1221 (talk) 05:20, 24 August 2010 (UTC)
56. Support 3 and begin testing implementation of 4. First Light (talk) 06:06, 24 August 2010 (UTC)
57. Support 3 Kneale (talk) 11:19, 24 August 2010 (UTC)
58. Support 4, 3, 2, ordered in level of preference. Blurpeace 12:57, 24 August 2010 (UTC)
59. Support 3 - Skysmith (talk) 13:01, 24 August 2010 (UTC)
60. Support 3 or 4 - TexasAndroid (talk) 13:25, 24 August 2010 (UTC)
61. Support 3 or 4 ʘ alaney2k ʘ (talk) 13:47, 24 August 2010 (UTC)
62. Support 3 or 4 --The Taerkasten (talk) 14:03, 24 August 2010 (UTC)
63. Strong Support 4, support 2 and 3 – ukexpat (talk) 16:02, 24 August 2010 (UTC)
64. Support 2 or 4 Steven Walling 16:34, 24 August 2010 (UTC)
65. Support 3 PluniAlmoni (talk) 18:43, 24 August 2010 (UTC)
66. Support 3 Tim Vickers (talk) 19:39, 24 August 2010 (UTC)
67. Support 3 —Chris!c/t 20:01, 24 August 2010 (UTC)
68. Support 4, 3, or 2 in decreasing order of preference. Plastikspork ―Œ(talk) 20:21, 24 August 2010 (UTC)
69. Support 2. Strongly support. Shabidoo | Talk 21:20, 24 August 2010 (UTC)
70. Support 3. PaddyLeahy (talk) 21:40, 24 August 2010 (UTC)
71. Strongly support 3 —Mikemoral♪♫ 22:09, 24 August 2010 (UTC)
72. Support 3. Armbrust Talk Contribs 22:31, 24 August 2010 (UTC)
73. Support 4 --Rocksanddirt (talk) 22:46, 24 August 2010 (UTC)
74. Support 2, 3 & 4, although 3 would be first pick. Lexicografía (talk) 23:00, 24 August 2010 (UTC)
75. Support 3 -epicAdam(talk) 06:05, 25 August 2010 (UTC)
76. Support 4 - Alison ❤ 06:07, 25 August 2010 (UTC)
77. Support 3 Donar Reiskoffer (talk) 06:49, 25 August 2010 (UTC)
78. Support 3 Themeparkgc Talk 08:09, 25 August 2010 (UTC)
79. Support 3 JACOPLANE • 2010-08-25 08:44
80. Support 3. Sole Soul (talk) 10:43, 25 August 2010 (UTC)
81. Support 3. Marokwitz (talk) 11:53, 25 August 2010 (UTC)
82. Support 4.--Charles (talk) 12:57, 25 August 2010 (UTC)
83. Support 4 Andrew Lenahan - Starblind 14:27, 25 August 2010 (UTC)
84. Support 3 - Schrandit (talk) 19:05, 25 August 2010 (UTC)
85. Support 4 -- Mjquinn_id (talk) 19:37, 25 August 2010 (UTC)
86. Support 3 Strobilomyces (talk) 19:42, 25 August 2010 (UTC)
87. Support 4 --Cúchullain t/c 19:55, 25 August 2010 (UTC)
88. Support 4, 3, 2, ordered in level of preference. — TRANSPORTERMAN (TALK) 20:00, 25 August 2010 (UTC)
89. Support 4 — MrDolomite • Talk 15:57, 25 August 2010 (UTC)
90. Support 2 or 3. Flatterworld (talk) 06:35, 26 August 2010 (UTC)
91. Support 3 -- RP459 Talk/Contributions 09:57, 26 August 2010 (UTC)
92. Support 4 Catfish Jim and the soapdish (talk) 13:38, 26 August 2010 (UTC)
93. Support 4 --LilHelpa (talk) 13:43, 26 August 2010 (UTC)
94. Support 3. Schutz (talk) 21:00, 26 August 2010 (UTC)
95. Support 4 WikiCopterRadioChecklistFormerly AirplanePro 22:54, 26 August 2010 (UTC)
96. Support 3. Şłџğģő 23:02, 26 August 2010 (UTC)
97. Support 3 -- Winston365 (talk) 23:23, 26 August 2010 (UTC)
98. Support 3 Jim.henderson (talk) 23:39, 26 August 2010 (UTC)
99. Support 2 minimosher (talk) 23:52, 26 August 2010 (UTC)
100. Support 4 apraetor (talk) 05:02, 27 August 2010 (UTC)
101. Support 3. Daniel (talk) 06:27, 27 August 2010 (UTC)
102. Support 4, 3, 2; in that order. Pinethicket (talk) 11:11, 27 August 2010 (UTC)
103. Support 2 or 3 --Teukros (talk) 15:15, 27 August 2010 (UTC)
104. Support 3 Randomblue (talk) 16:18, 29 August 2010 (UTC)
105. 3 or 4 Martinp23 19:53, 27 August 2010 (UTC)
106. Support 3 ajdlinux | utc 09:15, 28 August 2010 (UTC)
107. Support 2, 3, 4 --Dr Jorgen (talk) 03:40, 29 August 2010 (UTC)
108. Support 4 (followed by 3 and 2) --Chris 11:14, 29 August 2010 (UTC)
109. Support 4. Lara 13:22, 29 August 2010 (UTC)
110. Support 3. Green Cardamom (talk) 15:14, 29 August 2010 (UTC)
111. Support 3. --John (talk) 19:32, 29 August 2010 (UTC)
112. Support 4 -- Maddox (talk) 21:24, 29 August 2010 (UTC)
113. Support 3 (or 4, or 2, in decreasing preference order) --j⚛e deckertalk 04:36, 30 August 2010 (UTC)
114. Support 4, 3, 2 - In that order. Strom (talk) 08:58, 30 August 2010 (UTC)
115. Support 2 Cannonbolt2 (talk) 15:52, 30 August 2010 (UTC)
116. Support 2, maybe 3 but No way on 4. Pichpich (talk) 20:17, 30 August 2010 (UTC)
117. Support 3Benjabean1 (talk) 04:25, 31 August 2010 (UTC)
118. Support 4Alan.ca (talk) 04:56, 31 August 2010 (UTC)
119. support 4--Kmhkmh (talk) 10:21, 31 August 2010 (UTC)
120. support 4--Bwwm (talk) 12:16, 31 August 2010 (UTC)
121. Support 3 or 4 - Hoo man (talk) 14:09, 1 September 2010 (UTC)
122. Support 3 - Vipinhari || talk 16:01, 1 September 2010 (UTC)
123. Support 3--Spike Wilbury (talk) 21:33, 1 September 2010 (UTC)
124. Support 3 - Shadowjams (talk) 23:39, 1 September 2010 (UTC)
125. Support 3. Axl ¤ [Talk] 09:55, 2 September 2010 (UTC)
126. Support 3 --Locos epraix ~ Beastepraix 19:11, 2 September 2010 (UTC)
127. Support 4. I would support 5 if it was possible. Dugnad (talk) 18:06, 3 September 2010 (UTC)
128. Support 3 Ravensfire (talk) 19:02, 3 September 2010 (UTC)
129. Support any in such sequence: 4 better than 3 better than 2.--Mbz1 (talk) 19:50, 3 September 2010 (UTC)
130. Support 3.--Literaturegeek | T@1k? 20:01, 3 September 2010 (UTC)
131. Support 4, 3, 2 in that order. Wammes Waggel (talk) 13:45, 4 September 2010 (UTC)
132. Support 2, 3 Tabercil (talk) 15:57, 4 September 2010 (UTC)
133. Support 2. Keep as is. --Celtics 2008 (talk) 23:08, 4 September 2010 (UTC)
134. Support 4,3,2, in that order. עוד מישהו Od Mishehu 04:45, 7 September 2010 (UTC)