Wikipedia

Wikipedia:Pending changes/Straw poll

< Wikipedia:Pending changes
(Redirected from Wikipedia:Pending changes/Vote comment)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

The results of the poll were 407 in favour of implementation in some form, and 217 opposed, with 44 other responses.

Introduction

edit

The two month trial of Pending Changes is over and community consensus is required for its continued use. The community should now decide if the implementation should be continued or not: the straw poll will last two weeks from August 22 – September 4 (UTC). An extensive discussion, including a summary of the major issues and recommendations, can be found and continued at Pending Changes/Closure. Meta-discussion about the poll itself should take place on the talk page.

Straw poll instructions

edit

There are two basic options: close or keep. Users who want to keep pending changes can additionally specify what format they would prefer a continued trial to take.

Close

  • 1 – Close, disable the feature entirely.

Keep

  • 2 – Keep as is. This option still allows for adding and removing individual articles but with no expansion beyond what was originally approved. Improvements to the interface and policy continue.
  • 3 – Keep with gradual limited expansion. From the present 1.4k to between 5k to 10k max, focusing on low traffic/BLPs (biographies of living persons) and any articles as requested. Improvements to the interface and policy continue.
  • 4 – Keep, with expansion by bot to all BLPs. Improvements to the interface and policy continue.

Straw poll

edit
  • Please add brief comments but refrain from discussion inside the poll.
  • Vote in the section titled with your choice.

Close: option 1

edit
  1. Support 1 - I have been an editor since 2002 and have started articles that have 10s of revisions after mine now. At first, I didn't know anything about accounts, but I had knowledge to share. I believe the danger will be that many valid article updates will never become a part of Wikipedia because they will be lost in a system where content must be approved to be seen. It promotes an attitude where Wikipedia editors can also edit would-be changes / contributions because of differences in style or opinion before the original article would have ever been seen. I think some of the uniqueness and power of Wikipedia comes from it's fluid nature of sharing knowledge -- by and for everyone. I resist the attitude of it becoming a club. Brandonforgod 3 September 2010
  2. Support 1 - System will be confusing to newcomers. Phearson (talk) 00:57, 23 August 2010 (UTC)[reply]
  3. Support 1 - Keep the system open. Shenhemu (talk) 10:03, 24 August 2010 (UTC)[reply]
  4. Support 1 - 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. SchuminWeb (Talk) 23:45, 21 August 2010 (UTC)[reply]
  5. Support 1 - It's confusing, elitist, bureaucratic, off-putting, and unclear. I'll be glad to see the back of it. ☻☻☻Sithman VIII !!☻☻☻ 23:48, 21 August 2010 (UTC)[reply]
  6. Support 1 Is this really worth keeping? ~~ Hi878 (Come shout at me!) 00:09, 22 August 2010 (UTC)[reply]
  7. Support 1, discourages new editors from editing.Sumsum2010 · Talk · Contributions 00:22, 22 August 2010 (UTC)[reply]
  8. Support 1- it just hasn't worked. It was confusing, slow, it discouraged new editors from editing and it hasn't really stopped vandalism. Reyk YO! 00:25, 22 August 2010 (UTC)[reply]
  9. Support 1 - 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). Diego Grez what's up? 00:38, 22 August 2010 (UTC)[reply]
  10. Support 1. The potted trial hasn't made a case for PC level 1, and it has made the case against Level 2 clear. — Gavia immer (talk) 00:54, 22 August 2010 (UTC)[reply]
  11. Support 1 Slow with unclear and not followed standards.Cptnono (talk) 00:58, 22 August 2010 (UTC)[reply]
  12. Support 1 - 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.   — C M B J   01:11, 22 August 2010 (UTC)[reply]
  13. Support 1 Bejinhan talks 03:03, 22 August 2010 (UTC)[reply]
  14. Support 1 Unfortunately I do not desire the 2-4 alternatives per my comment at Wikipedia:Pending_changes/Closure. Ryan Norton 03:05, 22 August 2010 (UTC)[reply]
  15. Support 1. 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. —Jeremy (v^_^v Carl Johnson) 03:12, 22 August 2010 (UTC)[reply]
  16. Support 1 it doesn't seem useful to me, doesn't stop socks, etc per Jeske Pilif12p :  Yo  03:17, 22 August 2010 (UTC)[reply]
  17. Support 1. 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. Riggr Mortis (talk) 03:57, 22 August 2010 (UTC)[reply]
  18. Support 1 Due to reasons given on the comments page. Layona1 (talk) 04:12, 22 August 2010 (UTC) 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.) Layona1 (talk) 00:15, 23 August 2010 (UTC)[reply]
  19. Support 1 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. —fetch·comms 00:05, 22 August 2010 (UTC)[reply]
  20. Support 1. Unnecessary complication.Biophys (talk) 04:58, 22 August 2010 (UTC)[reply]
  21. Support 1. A Wikipedian approving an edit of a non-Wikipedian before it becomes visible goes against the most fundamental values of this project. --Yair rand (talk) 05:02, 22 August 2010 (UTC)[reply]
  22. Support 1. 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. HumphreyW (talk) 05:38, 22 August 2010 (UTC)[reply]
  23. Support 1. No real benefit for the creation of tons of busy work. Courcelles 05:40, 22 August 2010 (UTC)[reply]
  24. Support 1 Slow speed and the issues raised by Jeske make it undesirable in its current incarnation. Jarkeld (talk) 08:05, 22 August 2010 (UTC)[reply]
  25. Support 1 or 4 - 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. Casliber (talk · contribs) 08:20, 22 August 2010 (UTC)[reply]
    This is an interesting point, Casliber. So you're saying we should expand PC, on a trial basis, to all BLP's -- sort of like option 4 of this poll, except that after n number of months, PC will go away unless there is consensus for it to stay? That's a really reasonable thought and I'm sorry it's not getting discussed here. Andrew Gradman talk/WP:Hornbook 01:03, 23 August 2010 (UTC)[reply]
  26. Support 1 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. PL290 (talk) 08:35, 22 August 2010 (UTC)[reply]
  27. Support 1 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. --GW… 09:03, 22 August 2010 (UTC)[reply]
  28. Support 1 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. User A1 (talk) 10:01, 22 August 2010 (UTC)[reply]
  29. Support 1 Deters newcomers. Elitist. Richard75 (talk) 10:35, 22 August 2010 (UTC)[reply]
  30. Support 1. Discourages new users from editing. Adds unnecessary extra work for others. Offliner (talk) 11:04, 22 August 2010 (UTC)[reply]
  31. Support 1 Another unfortunate initiative that drives wikipedia away from being edited by everyone into the realm of being edited by a "wiki elite". --Xeeron (talk) 11:09, 22 August 2010 (UTC)[reply]
  32. Support 1 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. Davewild (talk) 14:15, 22 August 2010 (UTC)[reply]
  33. Support 1' - 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. Yworo (talk) 14:38, 22 August 2010 (UTC)[reply]
  34. Support 1 Goes against everything WP is about. Access Denied talk contribs editor review 15:11, 22 August 2010 (UTC)[reply]
  35. Support 1 Wikipedia is improved by its open edit policy, not by adding layers of bureaucracy. I, EnglishmanWouldst thou speak? • Handiwork 15:33, 22 August 2010 (UTC)[reply]
  36. Support 1 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. EricLeb01 (Page | Talk) 15:38, 22 August 2010 (UTC)[reply]
  37. Support 1 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) --Errant Tmorton166(Talk) 16:23, 22 August 2010 (UTC)[reply]
  38. Support 1 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. Fleet Command (talk) 16:37, 22 August 2010 (UTC)[reply]
  39. Support 1 – Kerαunoςcopia◁galaxies 17:01, 22 August 2010 (UTC)[reply]
  40. Support 1 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:23, 22 August 2010 (UTC)[reply]
  41. Support 1 Confusing, ineffective, and mildly elitist (is there anyone who is not a reviewer, except me, of course).--Bbb23 (talk) 17:51, 22 August 2010 (UTC)[reply]
  42. Support 1 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. Regards SoWhy 19:09, 22 August 2010 (UTC)[reply]
  43. Support 1 ῤerspeκὖlὖm in ænigmate ( talk ) 19:23, 22 August 2010 (UTC)[reply]
  44. Support 1. 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. — ξxplicit 19:43, 22 August 2010 (UTC)[reply]
  45. Support 1. 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. SpinningSpark 20:07, 22 August 2010 (UTC)[reply]
  46. Support 1. Deters newcommers. Limited effectiveness against vandals. -FASTILY (TALK) 20:19, 22 August 2010 (UTC)[reply]
  47. Support 1 per all above. All Hallow's Wraith (talk) 20:27, 22 August 2010 (UTC)[reply]
  48. Support 1. Too complex, little real benefit. --Sable232 (talk) 21:01, 22 August 2010 (UTC)[reply]
  49. Support 1 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. ThemFromSpace 22:25, 22 August 2010 (UTC)[reply]
  50. Support 1. 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. Gzuufy (talk) 22:26, 22 August 2010 (UTC)[reply]
  51. Support 1. I don't understand it. And i don't think it does anything useful. Debresser (talk) 22:41, 22 August 2010 (UTC)[reply]
  52. Support 1. 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.--Yachtsman1 (talk) 22:44, 22 August 2010 (UTC)[reply]
  53. Support 1 Useless, a pain in the butt, and discourages new editors. Just more bureaucracy to add to the confusion. Jmlk17 22:49, 22 August 2010 (UTC)[reply]
  54. Support 1 In the event the poll is not restarted and this vote stands, I would prefer to scrap the whole beast. Millahnna (mouse)talk 22:54, 22 August 2010 (UTC)[reply]
  55. Support 1 Can't see it as a solution to the vandalism problem. Arteyu ? Blame it on me ! 23:01, 22 August 2010 (UTC)[reply]
  56. Support 1. Unnecessary, especially if the edit pages misleadingly say, "When you click Save, your changes will immediately become visible to everyone." Guoguo12--Talk--  00:02, 23 August 2010 (UTC)[reply]
  57. Support 1 This is frustrating to sit and wait for someone else to approve it. Clamshell Deathtrap (talk) 00:16, 23 August 2010 (UTC)[reply]
  58. Support 1 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. Humbersi (talk) 00:27, 23 August 2010 (UTC)[reply]
  59. Support 1 More went wrong than went right. Jsayre64 (talk) 00:33, 24 August 2010 (UTC)[reply]
  60. Support 1 More trouble than it's worth, ineffective for most articles that needed semi-protection.—Kww(talk) 01:21, 23 August 2010 (UTC)[reply]
  61. Support 1 Completely inefficient. Provides none of the advantages of protection in addition to a number of disadvantages that render it infeasible. Heavyweight Gamer (talk) 01:33, 23 August 2010 (UTC)[reply]
  62. Support 1 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). Makes new editors feel uncomfortable. Buchraeumer (talk) 02:20, 23 August 2010 (UTC)[reply]
  63. Support 1 Changes should appear instantly and consistently for all users. Anything else is no less than an insult to the purpose of Wikipedia. CompuHacker (talk) 03:06, 23 August 2010 (UTC)[reply]
  64. Support 1 Overly complex solution to a simple problem that already had a solution: page protection. Jason Quinn (talk) 03:21, 23 August 2010 (UTC)[reply]
  65. Support 1 The way this poll is being run is biased toward keep. That aside, I vote to remove the feature. — Eric Herboso 03:23, 23 August 2010 (UTC)[reply]
  66. Support 1 Utterly useless, and brings a flood of vandals. I've seen even blatant vandalism "accepted". Mokele (talk) 03:25, 23 August 2010 (UTC)[reply]
  67. Support 1 I like the idea, but I don't think the implementation is ready for prime time yet. Kaldari (talk) 03:26, 23 August 2010 (UTC)[reply]
  68. Support 1 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. VQuakr (talk) 03:46, 23 August 2010 (UTC)[reply]
  69. Support 1. 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. OhanaUnitedTalk page 03:50, 23 August 2010 (UTC)[reply]
  70. Support 1 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.oknazevad (talk) 03:50, 23 August 2010 (UTC)[reply]
  71. Support 1 It was fun to review articles but I don't think the very limited benefits outweigh the costs listed above. Vampyrecat (talk) 04:53, 23 August 2010 (UTC)[reply]
  72. Support 1 per the reasons I discussed here. --William S. Saturn (talk) 05:18, 23 August 2010 (UTC)[reply]
  73. Support 1: Complicates things unneccessarily with the interface and takes up more time.--Forty twothe answer? 06:57, 23 August 2010 (UTC)[reply]
  74. Support 1. The trial period has not found any classes of articles where the PC system was shown to have worked well. In particular, there is no evidence at all that the system would/could work well for low-traffic articles that are watched by only a few users. In fact, common sense suggests the opposite - in many cases unreviewed changes on such articles are likely to pile up for weeks and months, discouraging everyone (both IPs and regular editors) from editing these articles at all. Introducing PC for all BLPs is a particularly bad idea - that would create a huge new area of backlog for regular editors. Nsk92 (talk) 07:41, 23 August 2010 (UTC)[reply]
  75. Support 1 As per all of the above. Qwrk (talk) 07:43, 23 August 2010 (UTC)[reply]
  76. Support 1 I feel that the community has failed to make a good case for keeping this thing going, therefore I vote that pending changes should be terminated with extreme prejudice. TomStar81 (Talk) 07:58, 23 August 2010 (UTC)[reply]
  77. Support 1 costs > benefits Jebus989★ 08:52, 23 August 2010 (UTC)[reply]
  78. Support 1 I haven't seen this feature do any good in preventing false information or vandalism. Semi-protection works much better. Twentydragon (talk) 09:33, 23 August 2010 (UTC)[reply]
  79. Support 1. It's all been said, but as everyone is adding a rationale, here's mine. This thing adds an additional layer of complexity with no real benefit. All it is supposed to do is stop obvious vandalism from being displayed to unexperienced users. That's not necessary; vandalism gets undone quickly anyway. Worse, the "reviewed" label creates a false sense of reliability ("ah, this has been approved by someone experienced, so it must be ok"), so non-obvious vandalism, POV pushing or even just good-faith errors appear to get a rubber-stamp, damaging (what's left of) Wikipedia's credibility in the long run. Paradoxically, having an article adorned with "F*CK!!!!!" every once in a while may help keep the whole system running and useful. Jimmy Fleischer (talk) 11:13, 23 August 2010 (UTC)[reply]
  80. Support 1 Yet another layer of bureaucracy to solve a problem reasonably well handled by semi-protection. Goes against the view that the encyclopedia can be edited by anyone as even registered editors will be subject to the whims of a new class of administrator. Bad idea that has not been shown to help. CooperDB (talk) 11:23, 23 August 2010 (UTC)[reply]
  81. Support 1 Confusing UI, my involvement as a reviewer seemed to be redundant in each case I attempted. A completely new, simpler, less ambiguous implementation with less redundancy and better integration with the watchlist would attract me. Trev M  ~  11:47, 23 August 2010 (UTC)[reply]
  82. Support 1. A further point is that it puts a burden on the "reviewer". What if the reviewer gets hoodwinked into accepting an edit which absolutely ought not to be accepted? Who is responsible for that, the one who proposed the bad edit, or the one who reviewed it? I am unconvinced that there is an enormous amount of vandalism stopped by this either. An extra layer of complexity which slows down minor things like typo-corrections from new users is a turn-off. Sjakkalle (Check!) 12:06, 23 August 2010 (UTC)[reply]
  83. Support 1 too much effort to be worth the trouble on the small scale... lord forbid we do it site wide. Good intentions.. but just not practical Weaponbb7 (talk) 12:22, 23 August 2010 (UTC)[reply]
  84. Support 1 would be very off-putting to new users 82UK (talk) 15:09, 23 August 2010 (UTC)[reply]
  85. Support 1 - not practical. Adrian (talk) 15:11, 23 August 2010 (UTC)[reply]
  86. Support 1 - Will create Wikipedia Oligarchy and eventually kill Wikipedia spirit. It's better to disallow IP edits. No troll (talk) 15:32, 23 August 2010 (UTC)[reply]
  87. Support Either redesign - eliminating the awkward ambiguities and re-test; or scrap it. I think a new design and new test is in order...Modernist (talk) 15:58, 23 August 2010 (UTC)[reply]
  88. Support 1 - I find this feature (and this whole vote) incredibly elitist, WE are basically voting for something that will limit the ability of OTHERS to make genuine contributions on Wikipedia. Incidentally, most of these OTHERS can't even vote on this poll ! Sonid (talk) 16:01, 23 August 2010 (UTC)[reply]
  89. Support 1 - Other measures already discourage anons and newly registered editors. The last thing Wikipedia needs is yet more barriers to entry. This is called eating your seed corn. 68.167.224.215 (talk) 17:36, 23 August 2010 (UTC)[reply]
  90. Support 1 - A fine way of reducing vandalism, but is difficult for new comers. Needs to be more elegant. If worked on some more, it could lead to the creation of a good vandalism deterrent-. Torque3000Talk 18:41, 23 August 2010 (UTC)[reply]
  91. Too complicated and cumbersome; the downsides outhweigh the benefits.  Sandstein  19:08, 23 August 2010 (UTC)[reply]
  92. Found no advantages whatsoever using this system, certainly no better than semi-protection. BigDom 19:31, 23 August 2010 (UTC)[reply]
  93. Support 1 - Unnecessarily complex. I am sure a better approach can be found. (RT) (talk) 20:26, 23 August 2010 (UTC)[reply]
  94. Support 1 - Get rid of it. Groundsquirrel13 (talk) 21:04, 23 August 2010 (UTC)[reply]
  95. Support 1 - Does not encourage new users. --Traveler100 (talk) 21:36, 23 August 2010 (UTC)[reply]
  96. Support 1 - It's simply too confusing, for experienced users and new/unregistered users alike. I've seen a lot of feedback from users that indicates there is a lot of confusion about how it works. You can't expect someone to understand why their edits to a particular page have to be approved, or what "approved" really means. The interface and documentation can certainly be improved, sure, but the information provided on the edit page should should not overwhelm editors, and most people are simply never going to read any additional documentation. FlaggedRevs certainly has its uses, but I'm not convinced that it's right for the English Wikipedia. Reach Out to the Truth 22:44, 23 August 2010 (UTC)[reply]
  97. Support 1 - The problem is that this system is simply too complicated, especially for new users. The information shown when approving edits can be misleading, and people who don't understand the interface can easily inadvertently end up accepting vandalism into articles unintentionally. This should be removed from the English Wikipedia until the interface is significantly improved. Nomader (Talk) 00:42, 24 August 2010 (UTC)[reply]
  98. Support 1 - Goes against everything that makes Wikipedia so popular: the open model of an encyclopedia built on consensus. meshach (talk) 00:57, 24 August 2010 (UTC)[reply]
  99. Support 1 - Has done practically zilch to stem the flow of vandalism, it's confused people, and I have no doubt in my mind it has put people off editing. The biggest problem by far is that new editors will be put off by not having their work visible immediately, which is the whole point of Wikipedia in the first place. The encyclopedia anyone can edit is no use if what you do isn't seen. BarkingFish Talk to me | My contributions 02:27, 24 August 2010 (UTC)[reply]
  100. Support 1 - Frankly, I don't understand why we let people edit without accounts, because accounts obscure IP addresses and are therefore more anonymous than IP addresses, and registration takes seconds with no personal information required. I think if we restricted editing to accounts, we could cancel semi-protection entirely (as most vandalism comes from IP users), never need anything like pending changes, and let anybody (new accounts included) edit virtually any article within seconds. As it is though, if we're to keep IPs editing, I'd rather scrub pending changes and leave all edits on the same footing. I especially don't think that we should restrict new accounts from editing any article with immediate effect. - Bootstoots (talk) 04:58, 24 August 2010 (UTC)[reply]
  101. Support 1 Unless there is a feature on recent changes or on preferences which can hide pending revisions. Even though I'm not a reviewer, I still see the unnecessary highlighted yellow box with the bold pending changes text. It distracts some of those RC patrollers like me who want to review other edits as well. Minimac (talk) 06:55, 24 August 2010 (UTC)[reply]
    Edit: I've also discovered that you can't request pending changes protection using Twinkle. It's better to close pending changes down rather than ask the Twinkle creator to improve it so that these pending changes protection options can be available. Minimac (talk) 10:12, 25 August 2010 (UTC)[reply]
  102. Support 1 an additional software/application version of instruction creep that over-bureaucratises with a harsh WP:BITE and anti-IP aspect to boot. --S.G.(GH) ping! 07:11, 24 August 2010 (UTC)[reply]
  103. Support 1 Pending changes should be banished to Room 101. Jared Preston (talk) 09:25, 24 August 2010 (UTC)[reply]
  104. Support 1 it confused me as an alleged reviewer, so what chance does an editor stand? Fiddle Faddle (talk) 11:02, 24 August 2010 (UTC)[reply]
  105. Gurch (talk) 11:19, 24 August 2010 (UTC)[reply]
  106. Was neutral, just had something on my watchlist changed to pending changes because of 1 bit of vandalism that was reverted in less than a minute. I think applied carefully this could work, but I have serious doubts about the carefully part. I fear we'll get to the point the whole place is under pending changes and I think that would be bad for the encyclopedia anyone can edit. Hobit (talk) 11:47, 24 August 2010 (UTC)[reply]
  107. Support 1 Bureaucratic, unnecessary and elitist. Dalliance (talk) 11:50, 24 August 2010 (UTC)[reply]
  108. Support 1 add more semi protection and the same affect will happen except the confusion! mabdul 13:16, 24 August 2010 (UTC)[reply]
  109. Support 1 Complicated, obtuse, not really needed. Nave.notnilc (talk) 14:29, 24 August 2010 (UTC)[reply]
  110. Support 1 confusing, unhelpful, unwieldy, and doesn't accomplish what it purports to accomplish. Exploding Boy (talk) 14:38, 24 August 2010 (UTC)[reply]
  111. Support 1 my "no" vote should be interpreted as opposition to this poll on principle (see discussion). Revcasy (talk) 15:13, 24 August 2010 (UTC)[reply]
  112. Support 1 Confusing, unnecessary, elitist, and ripe for abuse.Willcrys 84 (talk) 15:46, 24 August 2010 (UTC)[reply]
  113. Support 1 Really don't know why we should have something like this when we have page protection. I know it lets anonymous and new users to continue to contribute to articles that have been subject to abuse and semi protected but why not just get them to create an account and wait out the 4 day period for auto confrmed users. It also prevents established users saying things they shouldn't on BLP articles but we have a team of eager volunteers to undo such edits. --tb240904 Talk Contribs 17:41, 24 August 2010 (UTC)[reply]
  114. Support 1 It's complicated and I don't believe it helps.--Alistair Stevenson (talk) 18:31, 24 August 2010 (UTC)[reply]
  115. Support 1 Since this can block even confirmed/autoconfirmed users' edits from appearing, I cannot support. Sakkura (talk) 19:26, 24 August 2010 (UTC)[reply]
  116. Support 1 There are basically two sorts of edits where this feature comes into play, simple vandalism and BLP violations. For vandalism it seems over complicated for the benefits, there are plenty of mechanisms for coping with this which work well. BLP violations are a more serious case, if there was a high frequency of these then it might be worth implementing. However I did not see a single such edit during the trial. Coupled with the problem of good anonymous editors not seeing the result of their work, I would say there is not sufficient justification for the feature.--Salix (talk): 19:53, 24 August 2010 (UTC)[reply]
  117. Support 1. Where's the comparitive analysis? Where's the actual results of the trial beyond simple data dumps? This was not supposed to be a simple test of whether it broke the pedia or not, it was supposed to be a scientfic collection and proper demonstration of real results and effects of PC. No results = no possibility of support. MickMacNee (talk) 21:42, 24 August 2010 (UTC)[reply]
  118. Support 1 - A cumbersome, inefficient, and thoroughly useless system. Carrite (talk) 22:23, 24 August 2010 (UTC)[reply]
  119. Support 1 Both confused and confusing SRESQ (talk) 23:01, 24 August 2010 (UTC)[reply]
  120. Support 1 Confusing and discouraging to beginners, and no evidence of effectiveness. We started this trial to see if it would work, and those who want to continue it have the burden of showing it did in fact have a significant positive benefit beyond what was achieved by our previous editing and protection procedures. DGG ( talk ) 23:34, 24 August 2010 (UTC)[reply]
  121. Support 1 Confusing and does not reduce the workload of vandalism patrolling; semi-protection is a better alternative. RJC TalkContribs 00:18, 25 August 2010 (UTC)[reply]
  122. Support 1 No clear benefit. - JeffJonez (talk) 00:44, 25 August 2010 (UTC)[reply]
  123. Support 1 This program does not work in it's present form. It is slow, has multiple editors jumping to do one thing causing more harm than good, and is pretty useless in present format. {{Editprotected}} works better, is faster, and just gives editors more work to do. Mr. R00t Talk 01:19, 25 August 2010 (UTC)[reply]
    Also encourages subtle vandalism. Mr. R00t Talk 01:19, 25 August 2010 (UTC)[reply]
  124. Support 1 Thought this was the encyclopedia that anybody could edit. It doesn't even reduce the amount of work required for anti-vandalism at all, unlike protection, which is used in only the most necessary cases. It's already difficult enough to start editing on here, with a billion policies, guidelines and conventions, as well as a cumbersome user interface, compounded by that disease that's called Vector. The last thing we ought to do is put in another layer of complexity for no visible advantage, other than further closing down our new user's possibility to edit. We seem to forget that not only we were the free encyclopedia, but also an open one, where anybody, without even registering, could fix an error. It's what made this project great. In any case, didn't seem there was any actual benefit from the trials, just another complicate layer of user interface and the same if not enlarged workload for the patrollers. Previous systems already in place might not be perfect, but this is much worse. Snowolf How can I help? 01:23, 25 August 2010 (UTC)[reply]
  125. Support 1 I have a problem with any restrictions on who can edit Wikipedia, as that alters what has made this the most successful encyclopedia in history. The already existent groups of anti-vandal editors will take care of the supposed need for a "pending changes" system.--Gniniv (talk) 06:06, 25 August 2010 (UTC)[reply]
  126. Support 1 too complicated and hard to understand for new users, and it moves us away from being an encylcopedia that anyone can edit.--Anon 08:58, 25 August 2010 (UTC)[reply]
  127. Support 1 Unnecessary and Confusing RahulChoudhary 13:37, 25 August 2010 (UTC)[reply]
  128. Support 1 Too complicated. --Kubanczyk (talk) 13:53, 25 August 2010 (UTC)[reply]
  129. Support 1 Creates more problems than it solves. C628 (talk) 14:19, 25 August 2010 (UTC)[reply]
  130. Support 1 Too difficult to use and understand, the old system seemed simpler and more robust. Shritwod (talk) 15:02, 25 August 2010 (UTC)[reply]
  131. Support 1Bruno talk 16:15, 25 August 2010 (UTC)[reply]
  132. Support 1 This isn't working. – iridescent 00:02, 26 August 2010 (UTC)[reply]
  133. Support 1 This gives the impression that all newbies and IPs can't be trusted to edit articles. Secret Saturdays (talk to me)what's new? 02:18, 26 August 2010 (UTC)[reply]
  134. Support 1 I remain philosophically opposed to this feature. ElKevbo (talk) 03:07, 26 August 2010 (UTC)[reply]
  135. Support 1. It's confusing; slow; adds little or no benefit (the vandalism was still visible to tens of thousands of logged-in readers); with rare exceptions was used on articles that needed semi-protection or none; and if it's extended it'll discourage new editors from joining the project. SlimVirgin talk|contribs 03:29, 26 August 2010 (UTC)[reply]
  136. Support 1 This idea starts a slippery slope towards having only registered users editing permission. NThomas (talk) 03:49, 26 August 2010 (UTC)[reply]
  137. Support 1 This was a bad idea. A good Idea would be to ban bots by using those verification codes found everywhere on the net. I would like wikipedia to run it's own bots for tiny stuff like correcting links, ect. But what I see today is that people use bots to help them in controlling the content of any such article. This sockpuppetry using bots to insta revert content and avoid the penalties in revert wars is just dumb. It seems to me that the worst vandals on wikipedia aren't the new ones. But those that have the means and the knowledge to control the content on wikipedia. GeneralChoomin 12:44, 26 August 2010 (UTC)
  138. Support 1 – Very confusing and looks bad. McLerristarr / Mclay1 15:09, 26 August 2010 (UTC)[reply]
  139. Support 1 - Goes completely against the spirit of Wikipedia as "The encyclopedia that anyone can edit". Tevildo (talk) 16:11, 26 August 2010 (UTC)[reply]
  140. Support 1 As most above. It deters users from editing and is confusing for inexperienced editors, and can only be understood upon reading about it in great detail, which most will not bother to do. 16:53, 26 August 2010 (UTC) —Preceding unsigned comment added by Wackywace (talk • contribs)
  141. Support 1 Ineffective, and slow loading times. Brambleclawx 20:57, 26 August 2010 (UTC)[reply]
  142. Support 1. This seemed like a great idea when first proposed but the implementation wasn't useful. Until some radical fixes are made (such as approval or rejection of individual piled up changes waiting for review, and improved page loading speed), I can't see how this is an improvement over semi-protection. ~Amatulić (talk) 21:21, 26 August 2010 (UTC)[reply]
  143. Support 1. We don't want to go down the road where an elite group of "reviewers" decides what an open encyclopedia should include. EdEColbertLet me know 22:02, 26 August 2010 (UTC)[reply]
  144. Support 1 in this structure, as the only way of preventing 4. If I could actually support 2, without being read as a generic keep, I would do so. This cemonstration of bad faith shows that the supporters of this cannot be trusted. Septentrionalis PMAnderson 01:06, 27 August 2010 (UTC)[reply]
  145. Support 1 Also voting 1 to prevent e.g. option 4. Weak poll. Argel1200 (talk) 01:34, 27 August 2010 (UTC)[reply]
  146. Support closure without reservation. This is discriminatory bureaucracy for little additional benefit. I readily revert suspected vandalism of articles on my watch list, but I don't want the burden of being a reviewer. I am forced to accept it because I would otherwise have to queue up with the IPs to get any editing done to BLPs. --Ohconfucius ¡digame! 04:31, 27 August 2010 (UTC)[reply]
  147. Support #1 This should be dropped. For the dozens of reasons listed above, with an extra note on: Too much complexity, hassles & problems chasing too little of a problem. Vandalism gets quickly reverted anyway. Discourages new editors, makes it even more complex for new editors, removes the important "User-Interface Design 101" need which is feedback - seeing the changes. North8000 (talk) 11:09, 27 August 2010 (UTC)[reply]
  148. Support 1 - semi-protection works better and more easily. Bearian (talk) 15:58, 27 August 2010 (UTC)[reply]
  149. Support 1 No real benefits for lots of complication, semi protect is best option. Mo ainm~Talk 16:10, 27 August 2010 (UTC)[reply]
  150. Support 1 Confusing, slow. Should be dropped. As said before, vandalism is quickly reverted. I see nothing wrong with semi-protection when needed. -- Alexf(talk) 17:22, 27 August 2010 (UTC)[reply]
  151. Support 1 Its main effects are to discourage new editors, inflate the edit counts of the privileged, and set up some editors as Better than the Rest. Antithetical to the spirit of the project and gets in the damned way. Yngvadottir (talk) 20:50, 27 August 2010 (UTC)[reply]
  152. Support 1 PC discourages new editors from editing, confusing, unnecessary. Artem Karimov (talk | edits) 21:25, 27 August 2010 (UTC)[reply]
  153. Support 1 PC detered new users from making changes and in instances of high trafficed/visiable/controversial pages, forced users to continually revert spam and flam wars that make legitamite and contrstructive edits nearly impossiable. Plus, it forced most editors to spend the majority of their time chasing down bad/spam information that editors were trying to add to those same pages. (For example: the Barack Obama main article) Brothejr (talk) 22:48, 27 August 2010 (UTC)[reply]
  154. Support 1 while I supported the trial, and continue to support some mechanism for dealing with BLPs, I was not convinced that pending changes has done anything substantial to reduce the potential damage done by vandals to BLPs. -Atmoz (talk) 23:22, 27 August 2010 (UTC)[reply]
  155. Support 1. Consumes even more manpower than spot-and-revert vandal-fighting, which is a level of reviewing manpower so high that we don't have. It doesn't solve the problem when troublemakers insert false but plausible-sounding information into Wikipedia either. --Deryck C. 03:05, 28 August 2010 (UTC)[reply]
  156. Support 1. from the point of view of a new user or one returning to wiki editing after a longer hiatus, the systems seems complex without sufficient payoff in improving quality. It definitely *seems* to add hierarchy and reduce openness. User:4POD 03:28, 28 August 2010 (UTC)[reply]
  157. Support 1 - sss333 (talk) 03:37, 28 August 2010 (UTC)[reply]
  158. Support 1. (i) It is Horribly slow at all stages (especially crucial when checking vandalism at WP:AIV) (ii) Attracts undue attention in the "recent changes" and watchlilsts to certain articles, which are selected not by community but by individual admins. (iii) Complicates the operation by setting an extra set of rules, promotes new WP species ("reviewers"). (iv) Induces potential wheel-warring among admins (semiprotect or pending? Those overlap somewhat in terms of deterring vandalism). Materialscientist (talk) 03:42, 28 August 2010 (UTC)[reply]
  159. Support 1 I'm not averse to another trial with better-defined criteria (and a cleanup of technical and user-interface bugs), but the current trial failed to show clear improvement in the areas targeted, and, IMO, failed quite clearly for the purposes of preventing vandalism, which is what it's used for in a lot of current articles. RayTalk 03:51, 28 August 2010 (UTC)[reply]
  160. Support 1 - No need for further complications, WP is complicated enough. let's keep it simple. --A user (talk) 10:15, 28 August 2010 (UTC)[reply]
  161. Support 1 - Two version of the truth aren't helpful OR welcoming to new users. Semi-protection is adequate to protect against anon/IP edits/vandalism, which seem to be 90% of the cases. Watchpup (talk) 11:35, 28 August 2010 (UTC)[reply]
  162. Support 1. It was a bad idea from the beginning. ru.Media (talk) 18:03, 28 August 2010 (UTC)[reply]
  163. Support 1 - I thought this was a bad idea from the beginning, and my opinion was not changed by the implementation of it. Parsecboy (talk) 18:48, 28 August 2010 (UTC)[reply]
  164. Support 1 - It appears as if some expert reviewed the articles "Reliability" but its not. This feature just confuses newbies to think that once an article is reviewed, all facts in it are accurate. I am still open for improvements, though. KonsulRomanumSPEAK to the Consulate 07:29, 29 August 2010 (UTC)[reply]
  165. Support 1, I hoped it would work well, but it didn't. Costs outweigh the benefits, and we've already got page protection to deal with pages that actually become a problem. I cannot even fathom locking up a series of articles just by classification. Seraphimblade Talk to me 07:31, 29 August 2010 (UTC)[reply]
  166. Support 1, it was still massively slow, and I was not impressed at all by how much vandalism it count on the articles I watch. --Gwern (contribs) 14:33 29 August 2010 (GMT)
  167. Support 1 – The special thing about Wikipedia is that everyone can edit it. RubySS (talk) 17:19, 29 August 2010 (UTC)[reply]
  168. Support 1 – Close. This discourages curious new editors from 'testing the water', in a more damaging way than semi-protection. Platypus333 (talk) 23:26, 29 August 2010 (UTC)[reply]
  169. Support 1 - Too bureaucratic for my tastes. Deep Purple Dreams (talk) 05:09, 30 August 2010 (UTC)[reply]
  170. Support 1 - Directly contradicts Wikipedia's mission of being an open encyclopedia that anyone can edit!
  171. Support 1 - Complicates things with no manifest gain. --M4gnum0n (talk) 08:14, 30 August 2010 (UTC)[reply]
  172. Support 1 - I would like to keep it as a tool that can be activated by the Edit Filter, as well as some user group harder to attain than autoconfirmed, to trigger mandatory further review by knowledgable reviewers. This will expand our toolbox without creating needless, confusing work. Applying a broad brush will just encourage users to find ways around it. --UncleDouggie (talk) 09:38, 30 August 2010 (UTC)[reply]
    The Edit Filter is far stronger than any iteration of PC and far more abusable; it makes no sense to merge the two. Also, what you're describing is "Three-quarters" protection, or PC2, which saw absolutely no use during the trial in the first place. —Jeremy (v^_^v PC/SP is a show-trial!) 19:34, 30 August 2010 (UTC)[reply]
    The Edit Filter has a fundamental flaw that can be fixed by integrating PC – thus the end result can be stronger than either alone. The filters only disallow in glaringly obvious cases. The current IP vandalism workflow seen frequently in the Edit Filter log is:
    1. Make obnoxious edit
    2. Reeceive disallow response from the Edit Filter
    3. Slightly tone down the edit
    4. Go to step 2 until just under the disallow threshold
    5. Receive warning from the Edit Filter
    6. Click Save
    7. Get reverted (hopefully)
    It would be much more valuable if step 5 was for the Edit Filter to just accept the edit as a PC. How would this be different from blindly applying PC to every article? Because many useful edits never trigger the Edit Filter at all and will not get subjected to PC overhead. --UncleDouggie (talk) 23:39, 30 August 2010 (UTC)[reply]
    Because the edit filter causes false positives all the time, something that would also end up affecting PC. (Also, most of the edit filters use regex, amongst other things, so there is no "disallow" threshold per se. The edit filter managers are competent enough to reduce their own ignorance, but they cannot create omniscience.) —Jeremy (v^_^v PC/SP is a show-trial!) 01:15, 31 August 2010 (UTC)[reply]
    This discussion is continued on my talk page. I'll post to the poll talk page if Jeremy and I are able to reach a consensus between us. --UncleDouggie (talk) 05:06, 31 August 2010 (UTC)[reply]
  173. Support 1 messy tool that offers little in the way of promised benifits.©Geni 11:50, 30 August 2010 (UTC)[reply]
  174. Support 1 LOL .. someone obviously came up with a new toy for Wikipedia, but it is hell boring, useless, and RESTRICTIVE of the freedom that is the whole point in the first place. Down with it! Maysara (talk) 13:18, 30 August 2010 (UTC)[reply]
  175. Support 1 This will deter IP contributors away from Wikipedia. EngineerFromVega (talk) 19:50, 30 August 2010 (UTC)[reply]
  176. Support 1 Unneccesary. Dlabtot (talk) 20:08, 30 August 2010 (UTC)[reply]
  177. Support 1 Bureaucracy is no substitute for trust. Sandman888 (talk) 21:40, 30 August 2010 (UTC)[reply]
  178. Support 1 in principle -- Wikipedia being so ridiculously easy to edit is very crucial to our identity, and we should preserve that as much as possible, accepting that vandalism is part of the package. Pending changes is a double-edged sword on that. In practice though, I defer to more active vandal fighters, if they strongly want option 2-3. --Alecmconroy (talk) 21:55, 30 August 2010 (UTC)[reply]
  179. Support 1 Excessive bureaucracy is not needed. SA ru (talk) 22:24, 30 August 2010 (UTC)[reply]
  180. Support 1 Purely discriminatory towards not only newcomers but also (auto)confirmed editors. Wikipedia does not need yet another class of editors privileged over ordinary editors. Kxx (talk | contribs) 02:39, 31 August 2010 (UTC)[reply]
  181. Support 1 Any articles with this protection enabled will take much longer to submit an edit. Nakon 05:22, 31 August 2010 (UTC)[reply]
  182. Support 1 Decision-making would be less transparent and less accountable. This would transfer control from the public to a select few, thus accentuating a culture of exclusion . Vote choices should have included an option for “changes and another vote.” —Peace01234 (talk) 05:36, 31 August 2010 (UTC)[reply]
  183. Support 1 No need for some selected 'editors'--Fox1942 (talk) 05:43, 31 August 2010 (UTC)[reply]
  184. Support 1 --Suomen Joutsen (talk) 06:38, 31 August 2010 (UTC)[reply]
  185. Support 1 Likely to confuse and effectively drive away Anonymous editors: would be simpler to just require log-ins. -- Doom (talk) 07:04, 31 August 2010 (UTC)[reply]
  186. Support 1. I saw a lot of complaints during the trial from editors who couldn't figure out how to make this work. WP is supposed to be easy to edit, but this adds a layer of complexity that is likely going to turn off new editors, and very possibly some of our experienced editors. I am adamantly opposed to any proposal to extend this automatically to all FAs and GAs, as flagged revisions makes no promises whatsoever to be quality control (and indeed, it can't be, as many reviewers won't have the specialized knowledge necessary to make those judgements). As others have alluded to, this could well create another class of privileged users, and is one more process that can be gamed during edit wars. Karanacs (talk) 16:57, 31 August 2010 (UTC)[reply]
  187. Support 1 There was no reason to begin the trial. FlaggedRevs are not necessary on Wikipedia. Radon210 18:19, 31 August 2010 (UTC)[reply]
  188. Support 1 Oppose all measures that contradict the founding principle that Wikipedia is an encyclopedia anyone can edit. TotientDragooned (talk) 18:30, 31 August 2010 (UTC)[reply]
  189. Support 1 painful to use. (What a terribly confused mess this page is, as well) Bob talk 08:20, 1 September 2010 (UTC)[reply]
  190. Support 1 unpractical for new users, creates false sense that "accepted" versions are "right", other, more pointed, remedies are better utilized Hekerui (talk) 09:22, 1 September 2010 (UTC)[reply]
  191. Support 1 more make-work; cumbersome and frustrating. Truthkeeper88 (talk) 14:20, 1 September 2010 (UTC)[reply]
  192. Support 1 - The Pending Changes system discourages new editors from editing, encourages certain users to essentially own articles, and is an affront to the basic principles of Wikipedia "the encyclopedia that anyone can edit". It's also elitist, overly bureaucratic, confusing to newcomers, and has had a negligible effect on preventing vandalism. --Kohoutek1138 (talk) 15:03, 1 September 2010 (UTC)[reply]
  193. Support 1 - As a newcomer, account-wise, but a frequent IP editor, I have tried my best to edit articles. This system clearly has alot of problems and violates the basic principles of Wikipedia. --Tespia (talk) 15:30, 1 September 2010 (UTC)[reply]
  194. Support 1 - The page protection system works well enough without the extra reviewing system. Fartherred (talk) 16:24, 1 September 2010 (UTC)[reply]
  195. Support 1 - While I understand the need to suppress the annoyance of vandalism, the risk of abuse of power is more severe. My first action on Wikipedia became an edit war with an Admin. ( It wasn't one of the main articles, so no one else took notice. ) Had he been able to block me by mere inaction, to condemn my efforts to limbo, I would have quickly become discouraged and left. Had this system been in place, Wikipedia would have lost me and countless other contributors who sought to improve the resource. ( He eventually conceded that he was wrong. After a comment about the need to find easier users, he has apparently left Wikipedia. ) BitterGrey (talk) 17:14, 1 September 2010 (UTC)[reply]
  196. Support 1 - This would discourage new users from using Wikipedia, since their contributions don't seem to "count" as much as others. I agree with users above that the founding principle of Wikipedia is that anyone can edit, and that this policy goes against that principle. Any mistakes or attacks on pages can be easily undone by other users, and there already is a system in place to protect against more vulnerable pages. I recently made a new account on a different languge Wikipedia, where they use this system for all edits - I really hesistate to make changes, even small ones, because I feel like my edits are somehow "automatically suspicious" and not worth as much as others.--Julie22193 (talk) 19:12, 1 September 2010 (UTC)[reply]
  197. Support 1 - Brings more and more vandalism to articles. Pure example of false promises. -68.217.117.65 (talk) 20:28, 1 September 2010 (UTC)[reply]
  198. Support 1 - It doesn't work, only creates a backlog of pending changes and discontented new users/experienced editors. Protecting articles is best. --John KB (talk) 06:16, 2 September 2010 (UTC)[reply]
  199. Support 1 per SlimVirgin and GeneralChoomin. Just another layer of un-needed bureaucracy. Semi-protection is good enough for articles with high-risk of vandalism, and I definitely see the potential for abuse if this new system continues and becomes more widely used. -Helvetica (talk) 11:04, 2 September 2010 (UTC)[reply]
  200. Support 1 - !vote changed, have been convinced it isn't helpful. —chaos5023 (talk) 12:14, 2 September 2010 (UTC)[reply]
  201. Support 1 wow. Was put off on first seeing it, but became much more against a change when I saw that the summary of problems linked atop this page makes a better case than I could. We have a review system that works fine already, it's called watchlists. JJB 12:46, 2 September 2010 (UTC)
  202. Support 1 A discriminatory system. Flies in the face of a true wiki. LevenBoy (talk) 12:53, 2 September 2010 (UTC)[reply]
  203. Support 1 I favour more openness and less barriers to entry. j-beda (talk) 14:22, 2 September 2010 (UTC)[reply]
  204. Support 1 I tried several times to use the new system and did not find it intuitive or easy to use. I did not understand the point of implementing it. It makes Wikipedia more complicated than necessary and I think its drawbacks outweigh the benefits. Blue Rasberry 17:09, 2 September 2010 (UTC)[reply]
  205. Support 1 Very weak at stopping vandalism - if implemented, the vandals are not going away, they will just do more subtle edits, and turn it into a MMORPG to see who can get an edit past the reviewer. I would much rather prefer semi-protection for all BLP, and the rest says as it is. The KISS system is always the best. Ronhjones  (Talk) 22:00, 2 September 2010 (UTC)[reply]
  206. Support 1 Feel the change works against the democratic spirit of Wikipedia, with little benefit. Metsasarv 23:25, 2 September 2010 (UTC)[reply]
  207. Support 1 Though I understand the concepts of the vandalism fighting side of it, the pages that have Pending Changes are usually popular enough to either be locked or watched by enough users that vandalism has a very slim chance of making it onto the article for very long. It really only adds another tool for editors to learn about and understand. WM2 02:07, 3 September 2010 (UTC)[reply]
  208. Support 1 Although pending changes does seem to have its upside in fighting vandalism, it also seems to be very confusing, especially for new users. Plus, the whole system essentially entitles the revierwers to write the encylopedia as they see fit. Bcperson89 (talk) 07:15, 3 September 2010 (UTC)[reply]
  209. Support 1 This is a way to let more people edit otherwise locked pages. This is almost a good idea, except that it makes the classes within Wikipedia more distinct. This will drive newcomers away who don't want to be treated like peons. Further, since it is less severe than locking a page, this will lead to it being applied to many more pages. This is a slippery slope that will ultimately lead to a miserable caste system that is bad for all.--Headlessplatter (talk) 15:28, 3 September 2010 (UTC)[reply]
  210. Support 1 This would allow too many people to change an article to "Pending" and place a confusing method on new users. I would not have liked it when I first started. This is an unwanted layer. There is a point where democracy becomes anarchy. There needs to be an established hierarchy within Wikipedia. There is already enough bad press and distrust about Wikipedia. I like the Reviewer status I do have and think this "Pending" is a bad iddea . Noles1984 (talk) 16:06, 3 September 2010 (UTC)[reply]
  211. Support 1 DIFFICULT 2 UNDERSTAND AND DISCOURAGES PARTICIPATION IN EDITING. Crunk Cup (talk) 18:55, 3 September 2010 (UTC)[reply]
  212. Support 1 having seen the results of the trial, I don't think the results of the effort expended on pending changes justify the effort. Most pages with pending changes enabled seem to have received lots of vandal edits which have had to be reverted, and the edits which weren't reverted are usually quite minor. I am strongly opposed to using the feature on a large number of articles, as with option 4, and I suspect that if we go for option 3 we will find the limit creeping skywards. Hut 8.5 19:33, 3 September 2010 (UTC)[reply]
  213. Support 1 It didn't have any effect on vandalism. People still vandalized the articles, only now we have to reject, instead of clicking rollback, each of the vandalism edits. It also prevents good anonymous edits from being in public view until someone decides to click approve. I had considered it, and think it would be fine if it was only applied to BLP's. This is not the case, a example, when Starcraft II was released it was locked pending changes. From what I read this tool was only going to be used on BLPs. If it were expanded farther than that then a permanent backlog would form. --Alpha Quadrant (talk) 20:15, 3 September 2010 (UTC)[reply]
  214. Support 1 Entirely redundant with semi-protection except that this system is more complicated. We can always encourage more editors to patrol Template:Editsemiprotected (edit | talk | history | links | watch | logs). --Selket Talk 22:44, 3 September 2010 (UTC)[reply]
  215. Support 1 Not user friendly, etc etc etc, see everyone else. Please remove this tool. --Riotrocket8676 You gotta problem with that? 00:45, 4 September 2010 (UTC)[reply]
  216. Support 1 - In my opinion, it will discourage new users and cause further dissolution within the community. Part of the traditional Wiki philosophy is to be bold I see the implementation of 'Pending changes' as a challenge to that philosophy. All systems are subject to a certain level of abuse. I am unconvinced this system will see less abuse than what is currently in place. Furthermore, it detracts importance from settling disputes via negotiation and consensus. Therefore, I must oppose the proposed change on both philosophical and practical grounds. --Xaliqen (talk) 02:35, 4 September 2010 (UTC)[reply]
  217. Support 1 - Had little effect in deterring vandalism on articles where it was enabled. Tarl.Neustaedter (talk) 21:25, 4 September 2010 (UTC)[reply]

Keep: options 2, 3, or 4

edit
  1. Support 4 Bbriggs1 (talk) 03:08, 29 August 2010 (UTC)[reply]
  2. Support 2 The Thing // Talk // Contribs 23:13, 21 August 2010 (UTC)[reply]
  3. Support 3 - 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. CycloneGU (talk) 23:19, 21 August 2010 (UTC)[reply]
  4. Support 3 - if this option is successful, hopefully after improvements, we can then expand further. PhilKnight (talk) 23:28, 21 August 2010 (UTC)[reply]
  5. Support 3 with an additional aim and special focus to curb sockpuppetry on pages known to be frequently targeted. BigK HeX (talk) 23:30, 21 August 2010 (UTC)[reply]
    Good luck in trying to solve WP membership's bigges problem! Ohconfucius ¡digame! 04:43, 27 August 2010 (UTC)[reply]
  6. Support 3 Gobonobo T C 23:34, 21 August 2010 (UTC)[reply]
  7. Support 3--Wetman (talk) 23:35, 21 August 2010 (UTC)[reply]
  8. Support 3 I support PC for a number of reasons. 1) Concerns are voiced both by academia and our readership regarding Wikipedia's reliability. Pending changes addresses some of these concerns. Thus there is a good chance that "pending changes" will not only increase our readership but the number of people who edit. No one wants to put in the work to create something good or excellent just to have it vandalized and left un-repaired. 2) Vandals like to see their work go "live". Pending changes stops this and will thus potentially decrease the entire volume of vandalism. 3) We will have a tool to allow the world to seamlessly contribute to a greater part of Wikipedia. Instead of semi protecting some pages ( and thus making it difficult for IPs to contribution ) we can use PC making Wikipedia more open per our founding priciple.Doc James (talk · contribs · email) 23:37, 21 A ugust 2010 (UTC)
  9. Support 2 —Soap— 23:38, 21 August 2010 (UTC)[reply]
  10. Support 3 and definitely also shift it from high traffic to lower traffic articles. -84user (talk) 00:00, 22 August 2010 (UTC)[reply]
  11. Support 3 My76Strat 00:03, 22 August 2010 (UTC)[reply]
  12. Support 3 — {{Nihiltres|talk|edits|⚡}} 21:44, 24 August 2010 (UTC)[reply]
  13. Support 3 Ғяіᴅaз'§Đоом | Spare your time? 00:31, 22 August 2010 (UTC)[reply]
  14. Support 3 (at least) 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. --Slp1 (talk) 00:21, 22 August 2010 (UTC)[reply]
  15. Support 3, though I hope the suggested improvements will be made before expansion of PC material. —Arsonal (talk + contribs)— 00:17, 22 August 2010 (UTC)[reply]
  16. Support 2 as a minimum - no objection to 3 or 4 being trialled, tool was useful. Off2riorob (talk) 00:34, 22 August 2010 (UTC)[reply]
  17. Support 3 - 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. - BilCat (talk) 00:36, 22 August 2010 (UTC)[reply]
  18. Support 3 but where do these vote comment guidelines come from? --Mkativerata (talk) 00:39, 22 August 2010 (UTC)[reply]
  19. Support 4 , but seriously consider usability. --Cyclopiatalk 01:12, 22 August 2010 (UTC)[reply]
  20. Support 3 pending changes is a useful tool, but discretion is needed for where it's applied. Nick-D (talk) 01:13, 22 August 2010 (UTC)[reply]
  21. Support 3 Pending changes has a lot of potential to help maintain the quality of Wikipedia. Tyrol5 [Talk] 01:19, 22 August 2010 (UTC)[reply]
  22. Very, very weakly support 2 - 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) (X! · talk) · @122 · 01:55, 22 August 2010 (UTC)[reply]
  23. Support 3 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). ♫ Melodia Chaconne ♫ (talk) 02:07, 22 August 2010 (UTC)[reply]
  24. Support 3. 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. Mkdwtalk 02:08, 22 August 2010 (UTC)[reply]
  25. Support 2 - and revisit again. --Threeafterthree (talk) 02:53, 22 August 2010 (UTC)[reply]
  26. Support 2 An effective tool on low traffic pages, though worthless on high traffic, keep PC-2 Ronk01 talk, Editor Review 02:57, 22 August 2010 (UTC)[reply]
  27. Support 4 followed by 3, followed by 2 Nil Einne (talk) 15:02, 23 August 2010 (UTC) (added additional supports since there is some suggestion on the talk page I need to spell it out)[reply]
  28. Support 3 ℳono 03:54, 22 August 2010 (UTC)[reply]
  29. Support 3 with emphasis on improvements. DocOfSoc (talk) 04:06, 22 August 2010 (UTC)[reply]
  30. Support 3 ErikHaugen (talk) 04:34, 22 August 2010 (UTC)[reply]
    Although I wish there was an option for focusing on replacing semiprot rather than "low traffic blp". ErikHaugen (talk) 16:49, 23 August 2010 (UTC)[reply]
  31. Support 3 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. ~SuperHamster Talk Contribs 04:57, 22 August 2010 (UTC)[reply]
  32. Support 2 (edit conflict) If you know how to use it, is useful. TbhotchTalk C. 04:58, 22 August 2010 (UTC)[reply]
  33. Support 3. 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. -- King of ♥ ♦ ♣ ♠ 05:01, 22 August 2010 (UTC)[reply]
  34. Support 3--Cannibaloki 05:09, 22 August 2010 (UTC)[reply]
  35. 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)[reply]
  36. Support 3 From what I have seen, this is helping the project. --Ckatzchatspy 05:13, 22 August 2010 (UTC)[reply]
  37. Support 3 - 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.‡ MAHEWA ‡ • talk 05:14, 22 August 2010 (UTC)[reply]
    Support 2 - 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. --WFC-- 05:25, 22 August 2010 (UTC) Moving to scrap the poll. Please do not remove this. --WFC-- 22:05, 22 August 2010 (UTC)[reply]
  38. Support 4 —Where's '5'? Future is thataway→ Cheers, Jack Merridew 05:31, 22 August 2010 (UTC)[reply]
  39. Support 3 or 4 --Diannaa (Talk) 05:36, 22 August 2010 (UTC)[reply]
  40. Support 3 or 4 BLPs and low-traffic are the article types where this makes absolute sense (unless RecentUnwatchedChanges or similar gets implemented). --Cybercobra (talk) 06:20, 22 August 2010 (UTC)[reply]
  41. Support 2 or 3 - 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. Afaber012 (talk) 06:40, 22 August 2010 (UTC)[reply]
  42. Support 2, for ultimately being a net positive. -- Ϫ 06:46, 22 August 2010 (UTC)[reply]
  43. Support 4 sorta 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". Shell babelfish 06:49, 22 August 2010 (UTC)[reply]
  44. Support 3 - This system is a net positive for the project and should be slowly expanded.--Sodabottle (talk) 07:13, 22 August 2010 (UTC)[reply]
  45. Support 3 or 4 - 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. Andrew Gradman talk/WP:Hornbook 07:17, 22 August 2010 (UTC)[reply]
  46. Support 3 keeping to low-traffic articles. My feeling is that it doesn't work well on high-traffic articles, and will put off new editors. -- PhantomSteve/talk|contribs\ 07:20, 22 August 2010 (UTC)[reply]
  47. Support 3 — Glenn L (talk) 07:26, 22 August 2010 (UTC)[reply]
  48. Support 3 - useful alternative to either semi-protection or no protection in some cases. -- zzuuzz (talk) 07:30, 22 August 2010 (UTC)[reply]
  49. Support 3 or 4 Dodoïste (talk) 07:47, 22 August 2010 (UTC)[reply]
  50. Support 3. Revision/clarification of guidelines for reviewers might be in order, though. Choyoołʼįįhí:Seb az86556 > haneʼ 08:04, 22 August 2010 (UTC)[reply]
  51. Support 3. Would consider support 4 once wrinkles are ironed out. TFOWR 08:06, 22 August 2010 (UTC)[reply]
  52. Support 3 or 4 10k is a bit low. ϢereSpielChequers 08:10, 22 August 2010 (UTC)[reply]
  53. Support 1 or 4 - 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. Casliber (talk · contribs) 08:19, 22 August 2010 (UTC)[reply]
  54. Support 3 I like this idea but it needs expansion if it is going to stay. Iamcool234 08:28, 22 August 2010 (UTC)[reply]
  55. Support 2 or 3 assuming the interface can continue to improve. -- Eraserhead1 <talk> 08:42, 22 August 2010 (UTC)[reply]
  56. Support 4, 3, or 2 (in order of preference). — Jeff G. ツ 08:45, 22 August 2010 (UTC)[reply]
  57. Support 4, and therefore (obviously) 3 and 2 as well. DVdm (talk) 08:50, 22 August 2010 (UTC)[reply]
  58. Support 3 or 2(in order of preference). Still could use some work before 4-- WORMMЯOW 09:25, 22 August 2010 (UTC)[reply]
  59. Support 3. I don't think it's needed for all BLPs. Svick (talk) 09:52, 22 August 2010 (UTC)[reply]
  60. Support 3 Misarxist (talk) 09:54, 22 August 2010 (UTC)[reply]
  61. Support 3. I think it needs to be improved before being expanded on to all BLPs.--EchetusXe 09:55, 22 August 2010 (UTC)[reply]
  62. Support 3 Still needs some improvements. Theleftorium (talk) 10:00, 22 August 2010 (UTC)[reply]
  63. Support 2 or 3, 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. ~ mazca talk 10:07, 22 August 2010 (UTC)[reply]
  64. Support 4 --Ziko (talk) 10:31, 22 August 2010 (UTC)[reply]
  65. Support 2, oppose 4 - 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. Rami R 10:46, 22 August 2010 (UTC)[reply]
  66. Support 3 Schapel (talk) 11:17, 22 August 2010 (UTC)[reply]
  67. Support 3: 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. |Finalius|T|S|C 12:04, 22 August 2010 (UTC)[reply]
  68. Support 3 - for whatever reason, it seems, (subjectively), to have reduced vandalism attempts on articles subject to the process. Velella Velella Talk 12:14, 22 August 2010 (UTC)[reply]
  69. Support 3 - maybe give editors with review permissions the right to protect pages with pending changes if they discover the need for it? Tomd2712 | Tell me something? 12:16, 22 August 2010 (UTC)[reply]
  70. Support 3. The trial succeeded in lowering visible BLP vandalism and the sky did not fall in. Sam Blacketer (talk) 12:18, 22 August 2010 (UTC)[reply]
  71. Support 3 Willking1979 (talk) 12:20, 22 August 2010 (UTC)[reply]
  72. Support 3 Needs work, but an asset that should continue to be deployed on our more "at-risk" articles of all stripes. Der Wohltemperierte Fuchs(talk) 12:23, 22 August 2010 (UTC)[reply]
  73. Support 3 Graham Colm (talk) 12:25, 22 August 2010 (UTC)[reply]
  74. 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)[reply]
  75. Support 2 or 3 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. --[[User:Cas<style>span.GerbrantEditRegexReplaceHit{font-weight:bold;background:lightsteelblue}span.GerbrantEditRegexReplaceHitOff{font-weight:bold;background:mistyrose}span.GerbrantEditRegexReplaceMaskFailed{font-weight:normal;color:red}</style>tAStone|CastAStone]]//(talk) 12:48, 22 August 2010 (UTC)[reply]
  76. Support 2 It worked with preventing BLP vandalism and some vandalism on other articles. GB86 13:21, 22 August 2010 (UTC)[reply]
  77. Support 3 - 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.) Shimgray | talk | 13:22, 22 August 2010 (UTC)[reply]
  78. Support 3 or 4. - Dank (push to talk) 13:25, 22 August 2010 (UTC)[reply]
    Supporting just 3 per talk on this subject at the NYC Wikiconference; see Ragesoss below. - Dank (push to talk) 19:06, 2 September 2010 (UTC)[reply]
  79. Support 3. 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. --Tryptofish (talk) 13:39, 22 August 2010 (UTC)[reply]
  80. Support 3 or 4. Salvio Let's talk 'bout it! 13:44, 22 August 2010 (UTC)[reply]
  81. Support 3--intelati 13:51, 22 August 2010 (UTC)[reply]
  82. Support 4 or 3, Spellcast (talk) 13:57, 22 August 2010 (UTC)[reply]
  83. Support 4. --Funandtrvl (talk) 14:07, 22 August 2010 (UTC)[reply]
  84. Weak support 3. 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. Alzarian16 (talk) 14:08, 22 August 2010 (UTC)[reply]
  85. Support 4, 3, 2 in that order. NW (Talk) 14:19, 22 August 2010 (UTC)[reply]
  86. Support 3. ~NSD (✉ • ✐) 14:27, 22 August 2010 (UTC)[reply]
  87. Support 4. The Raptor You rang?/My mistakes; I mean, er, contributions 14:28, 22 August 2010 (UTC)[reply]
  88. Support 3 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? Jay-Sebastos (talk) 14:52, 22 August 2010 (UTC)[reply]
  89. Support 3 and 4, weak support 2. I think this would definitely be useful for all BLPs. - EdoDodo talk 15:10, 22 August 2010 (UTC)[reply]
  90. Support 3 or 4 I'd prefer to see 3. Captain panda 15:34, 22 August 2010 (UTC)[reply]
  91. Support 3 I think it should continue with expansion. --Nascar1996 Contributions / Guestbook 15:58, 22 August 2010 (UTC)[reply]
  92. Support 3 Make sure reviewing process is a little improved code wise. Allmightyduck  What did I do wrong? 16:15, 22 August 2010 (UTC)[reply]
  93. 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)][reply]
  94. Support 3 – My rationale is in Wikipedia:Pending changes/Closure. – Smyth\talk 16:53, 22 August 2010 (UTC)[reply]
  95. Support 3 or 4 - This is a good tool for dealing with our BLP problem on lightly trafficked articles, which is most of them.--Chaser (talk) 16:55, 22 August 2010 (UTC)[reply]
  96. Support 4 and 3 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. --Jezebel'sPonyoshhh 16:58, 22 August 2010 (UTC)[reply]
  97. (edit conflict)(edit conflict)Support 2, 3 or 4. But I would support 3 the most. —I-20the highway 17:08, 22 August 2010 (UTC)[reply]
  98. Support 2, 3, and 4, favoring 3 the most. John Carter (talk) 17:16, 22 August 2010 (UTC)[reply]
  99. Support 2 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.Nigel Ish (talk) 17:21, 22 August 2010 (UTC)[reply]
  100. Support 2, 3, and 4, favoring 3 the most. Oreo Priest talk 17:23, 22 August 2010 (UTC)[reply]
  101. Support 3 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. Joe Gazz84 (user)•(talk)•(contribs) 17:29, 22 August 2010 (UTC)[reply]
  102. Support 2. I have two articles on my watchlist that get vandalized on a regular basis. Thank God for other editors who also watch them. Thomas R. Fasulo (talk) 17:31, 22 August 2010 (UTC)[reply]
  103. Support 4 or 3 1exec1 (talk) 17:52, 22 August 2010 (UTC)[reply]
  104. Support 3 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. HalfShadow 17:56, 22 August 2010 (UTC)[reply]
  105. Support 2 Proposal and technology need work. Particular concern is not discouraing new editors. Lfstevens (talk) 18:02, 22 August 2010 (UTC)[reply]
  106. Support 2 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. --Bsherr (talk) 18:48, 22 August 2010 (UTC)[reply]
  107. Support 3 – It isn't being used enough, and is working pretty well. —MC10 (T•C•GB•L) 18:51, 22 August 2010 (UTC)[reply]
  108. Support 3 although 2 or 4 are fine as well. Wknight94 talk 18:56, 22 August 2010 (UTC)[reply]
  109. Support 3 and 4. 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. Sceptre (talk) 20:01, 22 August 2010 (UTC)[reply]
  110. Support 4. 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. — Blue-Haired Lawyer t 20:10, 22 August 2010 (UTC)[reply]
  111. Support 3 most, but also support 2 and 4. --JaGatalk 20:14, 22 August 2010 (UTC)[reply]
  112. Support 3 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...). Mike Peel (talk) 20:20, 22 August 2010 (UTC)[reply]
  113. Support 2 and 3 might work as well. The tool works, it just needs to be fixed up. Nolelover (talk) 20:28, 22 August 2010 (UTC)[reply]
  114. Support 2 or 3 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. --- cymru lass (hit me up)⁄(background check) 20:41, 22 August 2010 (UTC)[reply]
  115. Support 3 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. SwarmTalk 20:52, 22 August 2010 (UTC)[reply]
  116. Support 3 reduces vandalism and improves the readers' experience as well. --Elekhh (talk) 20:54, 22 August 2010 (UTC)[reply]
  117. Support 3 - Has some merit, but ultimately will have limited usefulness. May need to be scrapped altogether, but it deserves more time. Cresix (talk) 21:12, 22 August 2010 (UTC)[reply]
  118. Support 3ish — 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. —Arctic Gnome (talk • contribs) 21:14, 22 August 2010 (UTC)[reply]
  119. Support 3 and weak support 4 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. Intelligentsium 21:21, 22 August 2010 (UTC)[reply]
  120. Support 3. 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. AGK 21:38, 22 August 2010 (UTC)[reply]
  121. Support 3. 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. Ocaasi (talk) 21:46, 22 August 2010 (UTC)[reply]
  122. Support 3 and 4. PC works quite well and is a much better alternative than semi/full protection. It simply better reflects what Wikipedia is all about. Laurinavicius (talk) 21:51, 22 August 2010 (UTC)[reply]
  123. Support 3 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. —Ute in DC (talk) 22:02, 22 August 2010 (UTC)[reply]
  124. Support 2 or 3, 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. PKT(alk) 22:33, 22 August 2010 (UTC)[reply]
  125. Support 2 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. §hepTalk 22:53, 22 August 2010 (UTC)[reply]
  126. Support 3 and 4 Mootros (talk) 22:55, 22 August 2010 (UTC)[reply]
  127. Support 3 and/or 4 Moving backwards towards anonymous, at-will defamation of living people is simply not an option. Jclemens (talk) 23:10, 22 August 2010 (UTC)[reply]
  128. Support 2 Wikiscient (talk) 23:32, 22 August 2010 (UTC)[reply]
  129. Support 3 System cannot be properly assessed until the number of articles is expanded. Best to do this gradually or in phases, to allow iterative improvement. Richardguk (talk) 23:41, 22 August 2010 (UTC)[reply]
  130. Support 3 and 4. Ironholds (talk) 00:10, 23 August 2010 (UTC)[reply]
  131. Support 3 gradual expansion will let the system evolve as needed. WuhWuzDat 00:20, 23 August 2010 (UTC)[reply]
  132. Support 3. Pending changes and semiprotection are different tools. Expand pending changes where it is helpful, but do not remove semiprotection where it is needed. Geometry guy 01:04, 23 August 2010 (UTC)[reply]
  133. Support 3 4 is a little to much and this helps with removing some of the sper/per requests. -- DQ (t) (e) 01:08, 23 August 2010 (UTC)[reply]
  134. Support 3. DrNegative (talk) 01:10, 23 August 2010 (UTC)[reply]
  135. Support 3 - Agree with PhantomSteve, seems to work better with lower traffic articles. Mlpearc powwow 01:18, 23 August 2010 (UTC)[reply]
  136. Support 4, or 2/3. Needs polishing, but otherwise a useful tool. vvvt 02:08, 23 August 2010 (UTC)[reply]
  137. Support 3- Gradual change in protection is good. It's for the best. --The Wing Dude, Musical Extraordinaire (talk) 02:10, 23 August 2010 (UTC)[reply]
  138. Support 3 or 4 mgiganteus1 (talk) 02:13, 23 August 2010 (UTC)[reply]
  139. Support 2 Openskye (talk) 02:14, 23 August 2010 (UTC)[reply]
  140. Support 3 Needs work but otherwise a useful tool.--Steam Iron 02:26, 23 August 2010 (UTC)[reply]
  141. Support 2 or 3 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. superlusertc 2010 August 23, 02:29 (UTC)
  142. Support 4 Maddie talk 02:41, 23 August 2010 (UTC)[reply]
  143. Support 4 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. -- WeijiBaikeBianji (talk) 02:52, 23 August 2010 (UTC)[reply]
  144. Support 3 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.--Bkwillwm (talk) 03:17, 23 August 2010 (UTC)[reply]
  145. Support 3 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. 76.211.5.153 (talk) 03:36, 23 August 2010 (UTC)[reply]
  146. Support 3 - 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. -- Lear's Fool 03:38, 23 August 2010 (UTC)[reply]
  147. Support 4 with 3 as a 2nd choice and 2 as a 3rd choice. Rlendog (talk) 03:44, 23 August 2010 (UTC)[reply]
  148. Support 3 provided that the performance issues are addressed, the accept/unaccept interface is fixed, and the policy about when to accept edits is clarified. —Bruce1eetalk 07:17, 23 August 2010 (UTC)[reply]
  149. Support 2 --Saukkomies talk 07:38, 23 August 2010 (UTC)[reply]
  150. Support 3 - per successful trial, but issues should be fixed before widespread use. AJRG (talk) 09:25, 23 August 2010 (UTC)[reply]
  151. Support 3, and reconsider going for 4 in the long run. – sgeureka t•c 09:43, 23 August 2010 (UTC)[reply]
  152. Support 4 (or a non-bot versiono of 4; i.e. at least option 3). True, some articles don't benefit by this, and it must be tweaked, but I generally found this useful and gives good possibilities to keep an eye on the content of articles. Noting that quite a number of BLP's should be deleted as unreferenced/not-notable, this gives a good view on where the problems lie. Preferably: have a look at all of them, clear out the rubbish, and either delete, or protect using Pending changes. Bot option: if the last editor is a reviewer, autoreview that version, otherwise autoreview the last revid that is by a reviewer, or leave it unreviewed; will give some work to review them at that time (but there are enough reviewers out there, and I think this is a good way of checking which BLP's certainly need to be looked at; the others will come in due time). --Dirk Beetstra T C 09:56, 23 August 2010 (UTC)[reply]
  153. Support 3 and would also Support 4, overall it is still a work in progress but a net plus. Codf1977 (talk) 10:16, 23 August 2010 (UTC)[reply]
  154. Support 2 This has a great potential, but currently needs improvement before we make it a site-wide nightmare. —Charles Edward (Talk | Contribs) 13:06, 23 August 2010 (UTC)[reply]
  155. Support 3, with possible extension to 4 in the fullness of time. Clearly there are some issues to be fixed, but they're quite well defined in the discussion and most can be addressed. I think we need to develop it and see it in use for a longer time. -- Boing! said Zebedee (talk) 13:44, 23 August 2010 (UTC)[reply]
  156. Support 3 would be my preference, with possible extension to 4 as noted above.--SarekOfVulcan (talk) 14:16, 23 August 2010 (UTC)[reply]
  157. Support 2, with the caveat that reviewing policy must be clarified for consistency (see my comment on WP:Pending changes/Closure#Arbitrary Break 3 for further explanation). If reviewing is fully automatic as I describe there, I might support 3 or 4. PleaseStand (talk) 14:30, 23 August 2010 (UTC)[reply]
  158. Support 4 . --CutOffTies (talk) 15:38, 23 August 2010 (UTC)[reply]
  159. Support 3 - I have faith that the interface and guidelines will be sorted out over time, and then heartily support it's extension to all BLP articles as well as others as needed. SeaphotoTalk 16:18, 23 August 2010 (UTC)[reply]
  160. Support 3 Trial seems has been going alright. Expand number of articles and keep improving things. -fnlayson (talk) 16:23, 23 August 2010 (UTC)[reply]
  161. Support 3 - and continue to improve and expand • Astynax talk 16:38, 23 August 2010 (UTC)[reply]
  162. Support 2 in the sense that this was the first version and should be iterated / improved but is not yet ready for primetime. Usability and probably guidelines should be improved, then a second "trial". Dhollm (talk) 16:44, 23 August 2010 (UTC)[reply]
  163. Support 3 - It's a great addition, I'd like to see this continue, improve and expand. 28bytes (talk) 17:03, 23 August 2010 (UTC)[reply]
  164. Support 2. I haven't had a problem with it, although clearer information about how to make sure vandal edits aren't accepted would be useful. Daniel Case (talk) 17:18, 23 August 2010 (UTC)[reply]
  165. Support 3. The recent trial left many open questions. Needs further testing with an expanded scope. --Stepheng3 (talk) 17:41, 23 August 2010 (UTC)[reply]
  166. Support 3. Low traffic pages and BLP pages are extremely vulnerable to vandalism, because of hthe way our patrol is organized. If real-time checking trough Huggle doesn't catch the vandalism, it is likely to stay unless someone manually intervenes by reading article's (And on low-traffic pages that can be a LONG time). However, this system may in no way be abused for content control. Denying revisions should only be done in clear cases such as vandalism, copyright violations and content that clearly violates BLP - reviewers who repeatedly show bad judgment should lose their privilege quickly, and clear cases of content control or bad faith should be met with blocks if required. Excirial (Contact me,Contribs) 18:20, 23 August 2010 (UTC)[reply]
  167. Support 3. While I don't love it, I believe it should be expanded to include all FAs plus what is already there. Us441(talk) (contribs) 18:24, 23 August 2010 (UTC)[reply]
  168. Support any, most preferably 3. Very good system. Stifle (talk) 18:50, 23 August 2010 (UTC)[reply]
  169. Support 3 – allen四names 19:00, 23 August 2010 (UTC)[reply]
  170. Support 3; willing to accept 2 or 4. WhatamIdoing (talk) 19:55, 23 August 2010 (UTC)[reply]
  171. Support 3. It's not perfect, but it's closer to the spirit of the project than what we have now. I'd like to see continuing development on streamlining the interface and better explaining it to new users. Chromancer (talk) 21:33, 23 August 2010 (UTC)[reply]
  172. Support 3, particularly low traffic BLPs and other vulnerable low traffic articles for clear vandalism, cvios and BLP vios.Fainites barleyscribs 21:35, 23 August 2010 (UTC)[reply]
  173. Support 4; should be extended to all articles like in de.wp! →Alfie±Talk 22:14, 23 August 2010 (UTC)[reply]
  174. Support 3; Better alternative to page protection - which I think puts off newcomers more. This lets newcomers actually do the edit, rather than just ask someone else to do it. IainUK talk 22:21, 23 August 2010 (UTC)[reply]
  175. support 2; tuning the appropriate set of pages to use it for: perhaps current-events and lower-traffic pages. NealMcB (talk) 23:24, 23 August 2010 (UTC)[reply]
  176. Support 2 or 3 and all FAs per Second Law of Thermodynamics. HausTalk 00:08, 24 August 2010 (UTC)[reply]
  177. Support 3. We'll work it out over time. Barrylb (talk) 00:29, 24 August 2010 (UTC)[reply]
  178. Support 4 - This is a fantastic tool. I'd be willing to accept 2 or 3 as well, but regardless of what we decide to do, this needs to be continued. Burpelson AFB (talk) 01:20, 24 August 2010 (UTC)[reply]
  179. Support 4 - If the trial proved anything, it was that anonymous editors can contribute useful content to Wikipedia. The current de-facto policy of Semi-Protect any medium traffic article is a much worse choice. Furthermore the simple fact was that with the unreviewed status page, bad edits were reverted MUCH quicker in the trial than they would have otherwise. -- KelleyCook (talk) 02:28, 24 August 2010 (UTC)[reply]
  180. Support 3. Two months was too short to work out the kinks. Low traffic BLPs are a good place to extend its use as they are not a place we need new editors mucking about.--agr (talk) 03:16, 24 August 2010 (UTC)[reply]
  181. Support 3, later 4 - This is a much better alternative to semi-protect - it's already been proven successful when implemented in all articles in German Wikipedia. We have to keep this, and eventually expand to all articles. --Interchange88 ☢ 04:41, 24 August 2010 (UTC)[reply]
  182. Support 2, but keep talking about 4. Someguy1221 (talk) 05:20, 24 August 2010 (UTC)[reply]
  183. Support 2 or 3 (with preference to 3). However, I don't like the idea of an arbitrary limit. There's no reason we can't just slowly expand as long as its managable. 4 is a bad idea though. Applying a quality control mechanism by bot is just ridiculous. A human still needs to verify that the current version of the article is acceptable before enabling it. Mr.Z-man 05:58, 24 August 2010 (UTC)[reply]
  184. Support 3 and begin testing implementation of 4. First Light (talk) 06:06, 24 August 2010 (UTC)[reply]
  185. Support keeping it - We can discuss the next step if the consensus is to keep it. ~~ GB fan ~~ 06:27, 24 August 2010 (UTC)[reply]
  186. Support 3 or 4 - it's imperfect, but low-volume and BLP articles need some protection, and semi-protect is overkill. Rwessel (talk) 07:31, 24 August 2010 (UTC)[reply]
  187. Support 4, -- LYKANTROP ✉ 08:11, 24 August 2010 (UTC)[reply]
  188. Keep ... option five... expand scope rapidly. It appears that some folks really like this thing. To me, it's meaningless but they say it's worth something. So, for the sake of public peace, let them play with their toy - or else... East of Borschov 08:42, 24 August 2010 (UTC)[reply]
  189. Support 3 or 4 A liberal alternative to protection, retaining Wikipedia's democratic philosophy whilst increasing integrity. The JPStalk to me 09:00, 24 August 2010 (UTC)[reply]
  190. Support 3. It seems to be doing a good job so far. Quantpole (talk) 10:59, 24 August 2010 (UTC)[reply]
  191. Support 3 Kneale (talk) 11:19, 24 August 2010 (UTC)[reply]
  192. Support 4, 3, 2, ordered in level of preference. Blurpeace 12:57, 24 August 2010 (UTC)[reply]
  193. Support 3 - Skysmith (talk) 13:01, 24 August 2010 (UTC)[reply]
  194. Support 3 or 4 - TexasAndroid (talk) 13:25, 24 August 2010 (UTC)[reply]
  195. Support 3 - Only have small issues in regards to the articles it was trialed on. ZooPro 13:33, 24 August 2010 (UTC)[reply]
  196. Support 3 or 4 ʘ alaney2k ʘ (talk) 13:47, 24 August 2010 (UTC)[reply]
  197. Support 3 or 4 --The Taerkasten (talk) 14:03, 24 August 2010 (UTC)[reply]
  198. Support 3. As a reviewer, I think that the system works great when applied on a small amount of articles. —Waterfox (talk) 14:29, 24 August 2010 (UTC)[reply]
  199. Support 4 - Keeps the simplistic vandalism at bay. Tarc (talk) 14:38, 24 August 2010 (UTC)[reply]
  200. Support 2 or 3 with a case by case focus on low-traffic articles. I strongly oppose 4: this should not become a de facto lockup of any entire category. Arxiloxos (talk) 15:53, 24 August 2010 (UTC)[reply]
  201. Strong Support 4, support 2 and 3 – ukexpat (talk) 16:02, 24 August 2010 (UTC)[reply]
  202. Support 2 or 4 Steven Walling 16:34, 24 August 2010 (UTC)[reply]
  203. Support 2 or 3: the feature does not seem (either in description or implementation) to have major problems, and appears somewhat beneficial. While potentially confusing, such a complaint could apply to any new feature.
  204. Support 3, preferably 4 Wikipedia has needed this for too long, and so far the trial has been mostly beneficial. elektrikSHOOS 17:03, 24 August 2010 (UTC)[reply]
  205. Support 3 A Quest For Knowledge (talk) 17:10, 24 August 2010 (UTC)[reply]
  206. Support 4 The process is still clunky, and it will take a long time, but the goal of implementing the most cautious approach to derogatory information about living people must remain our guidestar. Such information is simply different from other kinds. Our rules must implement our ideals. The law of various jurisdictions is of secondary importance, in my view. Law sets a floor. If we descend below that, we put the entire project at risk. But law only answers our easiest questions. If it's illegal it should not go up. If it gets up, it must be ruthlessly hunted out and excised.But there's plenty of derogatory information --- even verifiable, reliably sourced derogatory information --- that has no business appearing in our encyclopedia. Declaring and enforcing standards of taste, civility, decency, and humane treatment of our brothers and sisters is not censorship. It's editorial judgment. That our editorial bar should be set higher than those of tabloids and trash TV is no shame. Quite the opposite, it's to our credit. David in DC (talk) 18:06, 24 August 2010 (UTC)[reply]
  207. Support 3 PluniAlmoni (talk) 18:43, 24 August 2010 (UTC)[reply]
  208. Support 3 - I'm really sure how well it works, but it doesn't seem to be hurting much. - Peregrine Fisher (talk) 19:12, 24 August 2010 (UTC)[reply]
  209. Support 3 - I have some sympathy with those who support proposal 1, but I think that pending changes can be useful for certain low-traffic articles, particularly low-traffic BLPs. Rje (talk) 19:39, 24 August 2010 (UTC)[reply]
  210. Support 3 Tim Vickers (talk) 19:39, 24 August 2010 (UTC)[reply]
  211. Support 3 —Chris!c/t 20:01, 24 August 2010 (UTC)[reply]
  212. Support 4, 3, or 2 in decreasing order of preference. Plastikspork ―Œ(talk) 20:21, 24 August 2010 (UTC)[reply]
  213. Support 4 FlaggedRevisions is an extremely useful tool. On German Wikipedia we've had it for >2years and it prevents things like vandalism showing up in 21 articles for 3h. See this page for more information. FlaggedRevs for all BLPs is the minimum in my opinion --Church of emacs (Talk) 21:10, 24 August 2010 (UTC)[reply]
  214. Support 2. Needs more time. Powers T 21:11, 24 August 2010 (UTC)[reply]
  215. Support 2. Strongly support. Shabidoo | Talk 21:20, 24 August 2010 (UTC)[reply]
  216. Support 4, but not automatically for BLPs that are semi or fully protected. -- Jeandré, 2010-08-24t21:34z 21:34, 24 August 2010 (UTC)[reply]
  217. Support 3. PaddyLeahy (talk) 21:40, 24 August 2010 (UTC)[reply]
  218. Strongly support 3 —Mikemoral♪♫ 22:09, 24 August 2010 (UTC)[reply]
  219. Support 4 plus 3, or 4, or 3 in that order Current sample size is too small, I saw very few PC edits on recent IP changes, so I think 2 will provide no more useful information. I expect that extending to all (or many more) BLP would be excellent. Mirokado (talk) 22:19, 24 August 2010 (UTC)[reply]
  220. Support 3. Armbrust Talk Contribs 22:31, 24 August 2010 (UTC)[reply]
  221. Support 4 else 2 else 3 Some protection should be applied to all BLPs and I think PC is the way to go, GDonato (talk) 22:35, 24 August 2010 (UTC)[reply]
  222. Support 4 --Rocksanddirt (talk) 22:46, 24 August 2010 (UTC)[reply]
  223. Support 4 We should do the best we can to protect BLPs. The admins and community can remain open even with protection mechanisms in place if the people remain open. That's what I recommend. Crionell (talk) 22:52, 24 August 2010 (UTC)[reply]
  224. Support 2, 3 & 4, although 3 would be first pick. Lexicografía (talk) 23:00, 24 August 2010 (UTC)[reply]
  225. Support 4 else 3 else 2. BLPs need more protection. --JWSchmidt (talk) 23:44, 24 August 2010 (UTC)[reply]
  226. Support 3 must be against vandalism and clearly wrong edits, anything not matching one of those 2 things should be accepted regardless of how bold it is. Featured articles are not particularly good candidates for pending changes protection Nicolas1981 (talk) 00:39, 25 August 2010 (UTC)[reply]
  227. Support 4 will reduce vandalism fighting in the long run, since edits need only be checked once, all BLPs and FA articles would benefit from it.- Wolfkeeper 00:50, 25 August 2010 (UTC)[reply]
  228. Support 2 and a better polling methodology. Recognizance (talk) 00:56, 25 August 2010 (UTC)[reply]
  229. Support 3, needed tool but gradual expansion allows article editors to get used to it while encouraging bugs to get seen & fixed before the change expands to system-wide. FactStraight (talk) 01:24, 25 August 2010 (UTC)[reply]
  230. Support 4, then 3, then 2. We need to protect all BLPs. Mahanga (Talk) 01:50, 25 August 2010 (UTC)[reply]
  231. Support 3, then 2, then 1, I do not support 4, or any option which implies automatic expansion to all articles. The expansion I support is the granting of pending changes protection upon request. Regards-Town,WP (talk) 02:38, 25 August 2010 (UTC)[reply]
  232. Support 3 -epicAdam(talk) 06:05, 25 August 2010 (UTC)[reply]
  233. Support 4 - Alison ❤ 06:07, 25 August 2010 (UTC)[reply]
  234. Support 3 Donar Reiskoffer (talk) 06:49, 25 August 2010 (UTC)[reply]
  235. Support 3 Themeparkgc Talk 08:09, 25 August 2010 (UTC)[reply]
  236. Support 2, for beginning. Maybe something more later. --Tone 08:11, 25 August 2010 (UTC)[reply]
  237. Support 3 JACOPLANE • 2010-08-25 08:44
  238. Support 4 we need to cover the BLP issue well - otherwise we'll have continuing problems. Buckshot06 (talk) 09:59, 25 August 2010 (UTC)[reply]
  239. Support 2, 3 & 4 . I'm undecided between the three, but I support the essential concept. --Harumphy (talk) 10:00, 25 August 2010 (UTC)[reply]
  240. Support 2. I think pending changes works better if it's enabled on a article-by-article basis, similar to how semi-protection is used – and keep in mind that pending changes was meant to replace semi-protection in BLPs. It's not needed on all BLPs, at least not immediately, just like semi-protection isn't needed for vast majority of BLPs. Just put it on most likely vandalised/heavily edited articles and we're set. --wwwwolf (barks/growls) 10:03, 25 August 2010 (UTC)[reply]
  241. Support 3. Sole Soul (talk) 10:43, 25 August 2010 (UTC)[reply]
  242. Support 3. Marokwitz (talk) 11:53, 25 August 2010 (UTC)[reply]
  243. Support 4.--Charles (talk) 12:57, 25 August 2010 (UTC)[reply]
  244. Support 4 Andrew Lenahan - Starblind 14:27, 25 August 2010 (UTC)[reply]
  245. Support 3 would be against all BLPs but a great option for the low-traffic ones. J04n(talk page) 15:18, 25 August 2010 (UTC)[reply]
  246. Support 3 - Schrandit (talk) 19:05, 25 August 2010 (UTC)[reply]
  247. Support 4 -- Mjquinn_id (talk) 19:37, 25 August 2010 (UTC)[reply]
  248. Support 3 Strobilomyces (talk) 19:42, 25 August 2010 (UTC)[reply]
  249. Support 3 - should not replace semi-p. but work in places where semi-p. doesn't. Also, to alleviate errors made in accepted version, make becoming a reviewer more difficult, reward reviewers with some way to count what they're doing, make some type of "X-strikes you're out" for reviewers who mess up big time, not punishable, but with all of the supposed errors, the right should make those who have it cautious - Theornamentalist (talk) 19:45, 25 August 2010 (UTC)[reply]
  250. Support 4 --Cúchullain t/c 19:55, 25 August 2010 (UTC)[reply]
  251. Support 4, 3, 2, ordered in level of preference. — TRANSPORTERMAN (TALK) 20:00, 25 August 2010 (UTC)[reply]
  252. Support 2 or 3, but not 4. I think 4 would be ridiculous, but 2 and 3 are manageable.--Aervanath (talk) 20:04, 25 August 2010 (UTC)[reply]
  253. Support 3 Seems to be working well as is, with room for expansion, but option 4 might be overwhelming.Anaxial (talk) 20:30, 25 August 2010 (UTC)[reply]
  254. Support 4 and then some, with continued improvements to policy and usability. Kevin Forsyth (talk) 20:59, 25 August 2010 (UTC)[reply]
  255. Support 3 or, if not, 4 - but we need to simplify and streamline the process. ~ QwerpQwertus Talk ツ 21:29, 25 August 2010 (UTC)[reply]
  256. Support 3 or 4. The sky isn't going to fall! Walkerma (talk) 21:55, 25 August 2010 (UTC)[reply]
  257. Support 3, and then 4 later - System requires major improvements (and the developers appear to be aware of what they are), but the concept is proven. Once all of the kinks have been worked out, then BLP's should be auto-PC-protected. SnottyWong talk 21:58, 25 August 2010 (UTC)[reply]
  258. Support; in order of preference, 4, 3 and 2. There are tweaks to be done to policy and process both, but none are show stoppers and we'll work the details out. — Coren (talk) 22:08, 25 August 2010 (UTC)[reply]
  259. Support 3 - Open to option 4 when we're ready for that. Sχeptomaniacχαιρετε 22:17, 25 August 2010 (UTC)[reply]
  260. Support 3 . Good system . Scheaffer Sirls (talk) 00:48, 26 August 2010 (UTC)[reply]
  261. Support 4 — MrDolomite • Talk 15:57, 25 August 2010 (UTC)[reply]
  262. Support 4 Strongly, would support 3. Frankly, I've been one to support semi-protection of all BLP-related articles as a way to limit false information and/or vandalism. This seems like a viable option as well. Either way, in the time I've had to participate in this system, I've found it to be quite an improvement to Wikipedia. I should also mention that I, in no way, shape or form, view or support this as a replacement for semi-page protection applied to (BLP) articles. ⒺⓋⒾⓁⒼⓄⒽⒶⓃ② talk 01:14, 26 August 2010 (UTC)[reply]
  263. Support 3 for now. --CarTick 01:56, 26 August 2010 (UTC)[reply]
  264. Support 3. As a writer of BLPs of political figures, of whom three were covered in the trial, I saw several cases where vandalisms and obvious bad edits were prevented from ever appearing to the general public. And that's the goal. I also saw one or two cases where bad edits got approved, and I took them out when I saw them on my watchlist. So it's not perfect, but it was an improvement from before. I didn't notice any speed degradation or other problems like the people against it have talked about. Wasted Time R (talk) 03:32, 26 August 2010 (UTC)[reply]
  265. Support 3 or 4 I'm not sure why the non-BLP aspects of 3 aren't included in 4. If I've misunderstood something, I hope whoever's counting can make heads or tails of this response. -Rrius (talk) 03:42, 26 August 2010 (UTC)[reply]
  266. Support 2 or 3. Flatterworld (talk) 06:35, 26 August 2010 (UTC)[reply]
  267. Support 3 -- RP459 Talk/Contributions 09:57, 26 August 2010 (UTC)[reply]
  268. Support 4 but first apply it on articles about given names & surnames, to discourage vandalism/vanity edits. - Fayenatic (talk) 12:24, 26 August 2010 (UTC)[reply]
  269. Support 3 with a review of the maximum should we get close to it. waggers (talk) 12:37, 26 August 2010 (UTC)[reply]
  270. Support 3 and 4, but only with substantially stricter screening of those granted reviewer privileges. The reviewing process is only as good as those allowed to participate in it. If those with records of multiple blocks, bans, disruptiveness and other misuse of Wikipedia are casually granted reviewer status on request, as I have seen happen (though fortunately such bad examples are probably few in number), we are, at cross-purposes, actually facilitating vandalism. Hertz1888 (talk) 13:33, 26 August 2010 (UTC)[reply]
  271. Support 4 Catfish Jim and the soapdish (talk) 13:38, 26 August 2010 (UTC)[reply]
  272. Support 3, but with a very slow rate of increase and only after a review on how to make the system more efficient, intuitive, and transparent. LinkTiger (talk) 13:41, 26 August 2010 (UTC)[reply]
  273. Support 4 --LilHelpa (talk) 13:43, 26 August 2010 (UTC)[reply]
  274. Support 3 -- This could be grown to help with vandalism, but still needs a lot of work. However, as is, it still can be used, so I support 3. A p3rson ‽ 15:56, 26 August 2010 (UTC)[reply]
  275. Support 3 -- Generally instruments to hinder vandalism must improve, but also we need better documentatiion, guidance and help how and when one can invoke these measures. Bleddynefans (talk) 16:27, 26 August 2010 (UTC)[reply]
  276. Support 4 at least for another test period. The interface needs improving. Active Banana ( bananaphone 17:13, 26 August 2010 (UTC)[reply]
  277. Support 4 - invaluable for BLPs. — e. ripley\talk 20:42, 26 August 2010 (UTC)[reply]
  278. Support 3, 2, 4 in that order – I like what we did here, so I'm okay with allowing it to continue and affect a larger number of articles. However, I'm a little unsure about expanding it to all BLPs at the moment. — The Earwig (talk) 20:51, 26 August 2010 (UTC)[reply]
  279. Support 3. Schutz (talk) 21:00, 26 August 2010 (UTC)[reply]
  280. Support 3, 2 or 4 would also be acceptable (in order). The interface and implementation need improvement, but the fundamental idea is sound. I agree that it should be used only where needed, to avoid semi pp.Jesstalk|edits 21:47, 26 August 2010 (UTC)[reply]
  281. Support 4 WikiCopterRadioChecklistFormerly AirplanePro 22:54, 26 August 2010 (UTC)[reply]
  282. Support 3. Şłџğģő 23:02, 26 August 2010 (UTC)[reply]
  283. Support 3 -- Winston365 (talk) 23:23, 26 August 2010 (UTC)[reply]
  284. Support 3 Jim.henderson (talk) 23:39, 26 August 2010 (UTC)[reply]
  285. Support 2 minimosher (talk) 23:52, 26 August 2010 (UTC)[reply]
  286. Support 4 apraetor (talk) 05:02, 27 August 2010 (UTC)[reply]
  287. Support 3. Daniel (talk) 06:27, 27 August 2010 (UTC)[reply]
  288. Support 3-4. Not sure about automatically rolling it out to article by bot, but neither do I want an arbitrary numerical limit to the amount of articles that can be protected - apply it wherever it's needed. BEVE (talk) 07:57, 27 August 2010 (UTC)[reply]
  289. Support 4-3-2 in that order. Goodness, I wish Wikipedians realized the disservice that vandalism does to Wiki's reputation. Let alone the financial damages that could occur (I realize they legally shouldn't, but lawyers). And it makes it better encyclopedia. Magog the Ogre (talk) 08:10, 27 August 2010 (UTC)[reply]
  290. Support 4. I don't edit many BLPs but they do get vandalised a lot and it is imperative for legal reasons these are accurate. So I don't really want to call out BLPs especially but I think the deserve the protection. As for the others, I have found I get about one or two a week asking for approval from my watchlist, which is hardly a burden: only one I have refused approval on. (And several times I have gone to approve it to find someone else already has). So I think it is working pretty well, despite my initial worries. I'm not even an admin so I don't think it unnecessarily closes it off to others. On Hungarian Wikipédia my missus User:Monkap had an article waiting nine months for approval, I think it is still waiting (), but that doesn't happen on English WP as far as I can see, they get approved pretty quickly. Si Trew (talk) 07:59, 27 August 2010 (UTC)[reply]
  291. Support 2. I was dubious, but in practice this seems to help on certain articles without imposing much burden on productive editing or even newbie contributions -- surprisingly, not low traffic BLPs so much as high traffic contentious articles. - Wikidemon (talk) 08:16, 27 August 2010 (UTC)[reply]
  292. Support 3 I am happy to see expansion of this trial to other pages that would benefit from this type of protection. It's just another tool in the toolbox; sometimes it's the best tool to use, sometimes it isn't. I would oppose automatic extension of this trial to 'all' BLPs, or some other large set of articles, without individual assessment. bobrayner (talk) 09:30, 27 August 2010 (UTC)[reply]
  293. Support 4, 3, 2; in that order. Pinethicket (talk) 11:11, 27 August 2010 (UTC)[reply]
  294. Support 2: Given limited resources, only problematic articles, BLP or not, whatever their traffic, should be listed. But don't make it too hard to put on the list. CarolMooreDC (talk) 14:08, 27 August 2010 (UTC)[reply]
  295. Support 2 or 3. PC might be preferable to semi-protection, and that's not because it's harder on vandalism, but because it's softer on good-faith IP edits. (It seems that many who supported 1 miss this point.) Still, for me 4 takes the whole thing way too far - I'd prefer 1 over 4. GregorB (talk) 14:27, 27 August 2010 (UTC)[reply]
  296. Support 2 or 3 --Teukros (talk) 15:15, 27 August 2010 (UTC)[reply]
  297. Support 3 Randomblue (talk) 16:18, 29 August 2010 (UTC)[reply]
  298. 3 or 4 Martinp23 19:53, 27 August 2010 (UTC)[reply]
  299. Support 3: I've attempted to do some reviewing. It's actually hard work sometimes. An astonishing amount of edits I reviewed was not immediately clear to be vandalism or legitimate. Even after some mild research I found trouble evaluating them, especially since only "clear" vandalism should be reverted. On some occasions I gave up on reviewing the article and left it to the next in line. However and this is important, over the years I've witnessed several low traffic articles being vandalized and going unnoticed for months. This is even worse when the vandalism is subtle, because any reader (even an aware one) might mistake the vandalism for genuine information. For BLP this is of even greater importance. Having the articles reviewed greatly increases the probability that changes that are actually vandalism will be spotted soon after they are made. --Atavi (talk) 20:32, 27 August 2010 (UTC)[reply]
  300. Support 3 This is basically an automated version of semi-protect, sometimes a necessary feature. Thundermaker (talk) 22:01, 27 August 2010 (UTC)[reply]
  301. Support 4 I personally think that with some minor improvements, this can be used on all articles on wikipedia. ChaosMasterChat 00:13, 28 August 2010 (UTC)[reply]
  302. Support 3 Helps improve overall quality of WP --hulmem (talk) 01:39, 28 August 2010 (UTC)[reply]
  303. Support 3 Trial has proved the tool worthy of inclusion and helped keep vandalism and bad edits out of the general publics scrutiny. More attention to detail of the material under review (less treating it like a simple anti-vandalism tool) will lead to a greater efficiency. Locking the review once one person has clicked it, for say 10 mins, would mean less wasted time and avoid those quickfire reviews. Chaosdruid (talk) 02:25, 28 August 2010 (UTC)[reply]
  304. Support 3 Per good points made by Atavi five votes above. Northumbrian (talk) 05:00, 28 August 2010 (UTC)[reply]
  305. Support 2 system has now begun to work. Red Flag on the Right Side 06:38, 28 August 2010 (UTC)[reply]
  306. Support 3 ajdlinux | utc 09:15, 28 August 2010 (UTC)[reply]
  307. Support 3, I felt the trial worked well, improvements can be implemented, eventually expand to option 4. Contrary to suggestions by some in the oppose camp, IPs are not cut out, it is just that their contributions are checked. Jezhotwells (talk) 11:03, 28 August 2010 (UTC)[reply]
  308. Support 2, 3, 4. We'd shift gradually to 4. This is an important way forward. Dr Bug (Vladimir V. Medeyko) 16:39, 28 August 2010 (UTC)[reply]
  309. Support 2, 3, 4 Though there are many issues, of varying significance, the system seemed to accomplish its goals. ~ Josh "Duff Man" (talk) 17:13, 28 August 2010 (UTC)[reply]
  310. Support 2 There is a lot of vandalism, tedious to fix.--GwydionM (talk) 17:45, 28 August 2010 (UTC)[reply]
  311. Support 3. 3 best of presented alternatives, but should keep going in some form. -R. S. Shaw (talk) 18:57, 28 August 2010 (UTC)[reply]
  312. Support 3:Pending Changes works best at preventing vandalism on BLP's, as you don't want vandalism to be publicly displayed on such articles. I believe it also reduces vandalism on other types of article. - In my opinion, any article that receives frequent vandalism should get Pending Changes instead of Protection, as this still allows IP editors to make useful contributions. IP editors contribute greatly to Wikipedia - normal Protection puts these people off and so we miss out on edits which could have helped the encyclopaedia. - People do not get the "thrill" of vandalism when an article has Pending Changes as the general public can't view their vandalism. - Pending Changes does not "criminalise" IP editors as they can still make useful contributions - I see no real reason to support this argument. - However, I do not see the need to roll out Pending Changes on all BLP's, as they are not all subjected to vandalism - this would be unnecessary. This is why I've opted for Support 3. Beeshoney (talk) 19:46, 28 August 2010 (UTC)[reply]
  313. Support 4 All Biography of Living people articles need it. We don't know which BLP articles are vulnerable to vandalism until it happens and the results of un-addressed vandalism in this category are extremely harmful to Wikipedia's reputation. Lumos3 (talk) 20:19, 28 August 2010 (UTC)[reply]
  314. Support 3. ANYTHING to reduce deliberate vandalism plus mindless obscenities and vitriol (as added to my talk page by one upset "editor" whose edit I'd reverted) Viva-Verdi (talk) 21:07, 28 August 2010 (UTC)[reply]
  315. Support 2, 3, 4 Anything and everything is desirable to reduce the nonsense that is added to/subtracted from articles and destroys the good work of the many dedicated editors who spend their good time trying to help WP readers advance their knowledge. Hmains (talk) 02:37, 29 August 2010 (UTC)[reply]
  316. Support 2+3+4 I wish there were an option to vote for that explicitly expanded this beyond biographies as other types of articles are prone to disruption too. Sitewide mainspace application as needed. And, whoot whoot 316 vote :D delirious & lost ☯ ~hugs~ 03:06, 29 August 2010 (UTC)[reply]
  317. Support 2, 3, 4 --Dr Jorgen (talk) 03:40, 29 August 2010 (UTC)[reply]
  318. Support 2,3,4 I do not know much about the differences, but any tool which prevents someone vandalizing and editing page again and again, as I just noticed on the page I am watching is helpful. I wonder, if there is any software that could block automatically such person, especially in BLP pages. Spt51 (talk) 03:50, 29 August 2010 (UTC)[reply]
  319. Support 2,3,4 As per Spt51 above. AkankshaG (talk) 06:52, 29 August 2010 (UTC)[reply]
  320. Support 3: Since I became a reviewer on June 29, my use of the right has been quite conservative. In truth, I have only made 12 decisions (five approvals and seven reverts). My reason for using the privilege so infrequently is that I did not want to unwittingly approve something that I did not positively know to be constructive; this was especially the case on BLPs of people I had never heard of. When these unfamiliar situations arose, I decided to just let another Reviewer make the decision. That stated, I think that the whole "pending changes" concept is still worth keeping on Wikipedia, and I'm still thankful for having been admitted as a Reviewer. --Sgt. R.K. Blue (talk) 07:50, 29 August 2010 (UTC)[reply]
  321. Support 3 with drastic improvements. IP contributors should know why their edits don't appear immediately, should have the option to see the page with all pending changes included before editing it, and the reviewers should focus on vandalism only. We don't want Wikipedia to become censored. There should be sanctions against those who use their reviewers' position as a means of censoring or for "covert edit-warring". With these improvements, and many other, I'm sure, the PC will make Wikipedia yet a better encyclopedia. JaneStillman (talk) 09:00, 29 August 2010 (UTC)[reply]
  322. Support 3 or even 4, while hoping for UI improvements. Very useful option for troublesome articles. Much better than semi-protection: good edits from IPs get through while the vandals and haters quickly give up. CWC 09:32, 29 August 2010 (UTC)[reply]
  323. Support 4 (followed by 3 and 2) --Chris 11:14, 29 August 2010 (UTC)[reply]
  324. Support 3 I initially was very opposed to Flagged Revs. However this implementation as a page protection method changed my opinion drastically. It has certainly helped, keeping vandals at bay. There are times when PC is appropriate and there are times when Semi-prot and full-prot are appropriate. This compliments the existing structure nicely. There are lots of policy things to work out, and the interface sucks (and is slow); but overall this is a good thing for the Wikipedia community. Acps110 (talk • contribs) 11:39, 29 August 2010 (UTC)[reply]
  325. Support 4. Lara 13:22, 29 August 2010 (UTC)[reply]
  326. Support 3. I voted against pending revisions in the previous poll, but this current trial has changed my mind. As long as it is only considered a last option, it can be a very useful tool in the fight against vandalism. --Saddhiyama (talk) 14:21, 29 August 2010 (UTC)[reply]
  327. Support 3. Green Cardamom (talk) 15:14, 29 August 2010 (UTC)[reply]
  328. Support 3, 4, 2 in that order. Helps more than it hinders. --GRuban (talk) 16:11, 29 August 2010 (UTC)[reply]
  329. Support 3. --John (talk) 19:32, 29 August 2010 (UTC)[reply]
  330. support 3 I'm also OK with having 1 or 4 being implemented as well but I prefer 3. --White Shadows Your guess is as good as mine 20:16, 29 August 2010 (UTC)[reply]
  331. Support 4 -- Maddox (talk) 21:24, 29 August 2010 (UTC)[reply]
  332. support 3 I'm always on board with methods to make Wikipedia less of a joke, e.g. The Steven Colbert effect
  333. support 4 This method is one of the few attempts to actually actively protect content, rather than being reactionary and block vandals. Strong support. Please expand program, so proven editors (reviewers?) may place pages under protection. In addition, mature (TBD) articles should automatically fall under protection, based on to be determined criteria. Kbrose (talk) 00:40, 30 August 2010 (UTC)[reply]
  334. Support 3 — It is saving a lot of needless work on reverting vandalism as vandals give up after realizing that their handwork comes to naught (as far as they can see). — S Masters (talk) 03:25, 30 August 2010 (UTC)[reply]
  335. Support 3 (or 4, or 2, in decreasing preference order) --j⚛e deckertalk 04:36, 30 August 2010 (UTC)[reply]
  336. Support 4 - More work needs to be done but we are moving in the right direction. Triona (talk) 07:06, 30 August 2010 (UTC)[reply]
  337. Support 4, 3, 2 - In that order. Strom (talk) 08:58, 30 August 2010 (UTC)[reply]
  338. Strong Support 2, 3, 4 - This is a good system to prevent vandalism (It will make the WP:RCP job much easier as the general public cannot see vandalism right away, and in most cases; not at all. Also: this will act as strong persuasion against vandalism as most vandals do what they do to get attention, this system will deny them the attention they would normally get from vandalizing wikipedia. Barts1a (talk) 09:11, 30 August 2010 (UTC)[reply]
  339. Support 3, then 2, but not 4 — I've noticed a difference in levels of vandalism, small at the moment but hopefully as understanding of the system grows amongst the public and IPs, the difference will become even more apparent. I oppose 4 because I think that would be unnecessary on many articles and there would not be enough reviewers to go around. Half Price (talk) 10:25, 30 August 2010 (UTC)[reply]
  340. Support 4 - But I agree, the poll design is poor. --Chris.urs-o (talk) 11:19, 30 August 2010 (UTC)[reply]
  341. Support 2. Modest and conservative approach which can always be expanded later. I'd like to see this in place for some time (12 months?) before expanding the scope. Don't trust no bots neither after I saw that Robocop movie. --Quartermaster (talk) 13:31, 30 August 2010 (UTC)[reply]
  342. Support 3 Gradual expansion would be best. Ks0stm (T•C•G) 14:38, 30 August 2010 (UTC)[reply]
  343. Support 2 Cannonbolt2 (talk) 15:52, 30 August 2010 (UTC)[reply]
  344. Support 3 or 4 In my estimation the trial period is an unqualified success. Seems to me that some of the specific aspects may need to be tweaked as we learn more, somewhat slow response time of the servers could use improvement, and Level 2 protection may not really be needed much in the end. But I trust this sort of stuff will get worked through with time and attention. ... Kenosis (talk) 17:12, 30 August 2010 (UTC)[reply]
  345. Support 3 or 4 It seems to have been reasonably effective in the limited places where it was applied. I favor the extension of this to all articles following the model of German Wikipedia, starting with Featured and Good Articles. SteveMcCluskey (talk) 19:00, 30 August 2010 (UTC)[reply]
  346. Support 2, maybe 3 but No way on 4. Pichpich (talk) 20:17, 30 August 2010 (UTC)[reply]
  347. Support 3 - reluctant support. Better then semi-protection. Regards, SunCreator (talk) 22:34, 30 August 2010 (UTC)[reply]
  348. Support 3Benjabean1 (talk) 04:25, 31 August 2010 (UTC)[reply]
  349. Support 4Alan.ca (talk) 04:56, 31 August 2010 (UTC)[reply]
  350. Support 3 I think that this was easy to use and a very helpful tool in the prevention of problems articles receive. I would have no problem with #4 either. I would love to see this expand to all articles esp. BLP's. I found this also help stop socking with IP's once it was realized it had to be accepted. --CrohnieGalTalk 10:08, 31 August 2010 (UTC)[reply]
  351. support 4--Kmhkmh (talk) 10:21, 31 August 2010 (UTC)[reply]
  352. support 4, from my experience in other projects--Yaroslav Blanter (talk) 11:14, 31 August 2010 (UTC)[reply]
  353. support 4--Bwwm (talk) 12:16, 31 August 2010 (UTC)[reply]
  354. Support 3, maybe 4. I imagine it's good at keeping out BLP issues, but I have to note it's rubbish at keeping out copyright problems. Reviewers are evidently not considering that dimension of things. --Moonriddengirl (talk) 12:25, 31 August 2010 (UTC)[reply]
  355. Support 3 Not the best system, but vandalisim has gone down. Not a fan of the voting system either, however better to input a vote, then none.
  356. Support 3 or 4 (or, failing that, 2). Protection is completely anti-wiki and we should be aiming to replace it completely with pending changes. Moreover, as Wikipedia matures, improving its accuracy is becoming more important than improving its breadth, so it's appropriate that most users should receive more accurate versions even at slight expense to editing incentive. —Aryeh Gregor (talk • contribs) 18:59, 31 August 2010 (UTC)[reply]
  357. Support 4 And expansion as soon as possible to ALL articles. -- Kim van der Linde at venus 19:16, 31 August 2010 (UTC)[reply]
  358. Support 3 Not worth getting shot of now. Serious work needs doing to make it far simpler for new users to grasp. But it has its uses, and I've used it and know its benefits. Orphan Wiki 19:31, 31 August 2010 (UTC)[reply]
  359. Support 4 And expansion as soon as possible to ALL articles. Raymond (talk) 20:30, 31 August 2010 (UTC)[reply]
  360. Support 2 Seems like a natural evolution of the project. ˉˉanetode╦╩ 20:36, 31 August 2010 (UTC)[reply]
  361. Support 3 Can't come quickly enough for BLP's. Eventually should be rolled out to other articles. --HighKing (talk) 21:47, 31 August 2010 (UTC)[reply]
  362. Support 3 There are some problems, but I'd rather err on the side of caution when it comes to BLPs. AniMate 06:47, 1 September 2010 (UTC)[reply]
  363. Support 3 No system is perfect but this seems like an improvement nonetheless. Splateagle (talk) 10:36, 1 September 2010 (UTC)[reply]
  364. Support 3 or 4 - Hoo man (talk) 14:09, 1 September 2010 (UTC)[reply]
  365. Support 3 Really, I'd say 3.5 if there was an option to expand it to cover tens of thousands more articles without trenching upon those pages that are well watched but rarely vandalized. bd2412 T 14:10, 1 September 2010 (UTC)[reply]
  366. Support 2 or 3 would be my second choice. And then 1, then 4. Useight (talk) 15:26, 1 September 2010 (UTC)[reply]
  367. Support 3 - Vipinhari || talk 16:01, 1 September 2010 (UTC)[reply]
  368. Support 3 Continue, with expansion. This is an overall useful tool, though there is room for improvement.--JayJasper (talk) 16:44, 1 September 2010 (UTC)[reply]
  369. Support 3 and/or 4 - This is an amazing new feature of Wikipedia that we cannot let go to waste. With a few improvements and some clarification of policy, this could become really useful. — Parent5446 ☯ (msg email) 19:37, 1 September 2010 (UTC)[reply]
  370. Support 2 If used correctly, it could be another useful tool. This actually allows for more open-editing than semi-protection, and I welcome any such gradience in anti-vandalism measures. Of course, it should be used sparingly (we still want MOST articles to be free) and with some formal guidelines in mind.-Tesseract2 (talk) 19:50, 1 September 2010 (UTC)[reply]
  371. Support 2, 3 or 4 I consider this to be a useful tool. Some people seem to forget that this is not an anti-vandal tool, it is an anti-vandal-visibility tool. It is not supposed to replace full or semi protection at all. —TheDJ (talk • contribs) 20:13, 1 September 2010 (UTC)[reply]
  372. Support 2, 3 or 4 Its really nice tool to have, we should keep this. KuwarOnline Talk 20:24, 1 September 2010 (UTC)[reply]
  373. Support 3--Spike Wilbury (talk) 21:33, 1 September 2010 (UTC)[reply]
  374. Support 3 - Shadowjams (talk) 23:39, 1 September 2010 (UTC)[reply]
  375. Support 3 or 4 - I will admit that I'm not up on all of the technical aspects, but I think the pending changes does help a lot in keeping junk off our pages and, IMO, is less restrictive than semi/full page protection. PrincessofLlyr royal court 23:46, 1 September 2010 (UTC)[reply]
  376. Strong Keep: Support options 2, 3, or 4 as all solve some basic problems facing Wikipedia. - Ret.Prof (talk) 00:45, 2 September 2010 (UTC)[reply]
  377. Support 4; protect BLPs. We then need to consider expansion to other entities subject to the same defamation risk which are not individual "living people" -- i.e. groups, companies, bands, etc. Antandrus (talk) 03:32, 2 September 2010 (UTC)[reply]
  378. Support 3 or 4 Proven on german wikipedia. Roeme (talk) 07:05, 2 September 2010 (UTC)[reply]
  379. Support 3 - Though further improvements are still to be made, and pending changes will never fully replace "traditional" page protection, it has shown plenty of potential, and vandalism and other disruption is best fought by a full tool kit. Allowing pending changes on request seems sensible, and while I am not strictly against a blanket roll out to all BLPs, making one step at a time may be wise. CT Cooper · talk 09:53, 2 September 2010 (UTC)[reply]
  380. Support 3. Axl ¤ [Talk] 09:55, 2 September 2010 (UTC)[reply]
  381. Support any. Prefer 4 over 3 over 2, as 4 is where we eventually need to be. ++Lar: t/c 10:33, 2 September 2010 (UTC)[reply]
  382. Support 3 Well I relaay liked Pending Changes, though e interface could be souped up... I noticed that, while reviewing stuff, there almost never was anything to review. This shows that we have a capacity for more articles to be added to the reviewing category, though a drastic change like 4 shouldn't be implemented, at least now... ManishEarthTalk • Stalk 13:18, 2 September 2010 (UTC)[reply]
  383. Support anything besides 1 I've seen it on Wikibooks, where, even though there's not much vandalism herediatarialy, the stuff that still pops up is neutralized by PC. Buggie111 (talk) 13:25, 2 September 2010 (UTC)[reply]
  384. Support 3. Howie Fung's analysis makes it pretty clear that Pending Changes is quite helpful in some situations.--ragesoss (talk) 14:21, 2 September 2010 (UTC)[reply]
  385. Support 3, although I still find the current implementation of how it works on the user interface very clunky and confusing for newcomers so improvements to the design must continue. I don't like the idea of a bot rolling out blanket protection though, too many ways it could be abused if it simply tries to detect categories. Best to have human eyes on it. ---Taelus (Talk) 15:57, 2 September 2010 (UTC)[reply]
  386. Support 3 --Locos epraix ~ Beastepraix 19:11, 2 September 2010 (UTC)[reply]
  387. Support 3 or 4 - It's not perfect but it's a worthwhile tool. It may be useful beyond BLPs in limited circumstances. It shouldn't be overused either, due to the extra work required by reviewers.   Will Beback  talk  20:42, 2 September 2010 (UTC)[reply]
  388. Support 3 But only if humans carefully select which articles are included, and the results are monitored. This concept can both reduce vandalism, but also encourage the new IP user to make worthwhile edits and, I would hope, become a registered and active editor. Sue Gardner's talk in NYC last weekend convinced me that careful selection and monitoring is needed to get the results that she and others hope for. Without sufficient volume, editors who volunteer for reviewing will become bored and not look for reviewing to be done. WP:BB. --DThomsen8 (talk) 21:42, 2 September 2010 (UTC)[reply]
  389. Support broadly any; pending changes helps us control a number of ongoing problems in a way that is less harsh on the users, newbies or not. I see this reducing the use of protection and blocks and (of course) improving our credibility along the way. I suspect most OTRS volunteers feel much the same way. 80.176.82.42 (talk) 16:37, 3 September 2010 (UTC)[reply]
  390. Support 4 With the understanding that this may be expanded and that certain articles are still going to require semi-protection because of the controversial nature of the subject. Rapier (talk) 17:48, 3 September 2010 (UTC)[reply]
  391. Support 4. I would support 5 if it was possible. Dugnad (talk) 18:06, 3 September 2010 (UTC)[reply]
  392. Support 3 Ravensfire (talk) 19:02, 3 September 2010 (UTC)[reply]
  393. Support any in such sequence: 4 better than 3 better than 2.--Mbz1 (talk) 19:50, 3 September 2010 (UTC)[reply]
  394. Support 3.--Literaturegeek | T@1k? 20:01, 3 September 2010 (UTC)[reply]
  395. Support 3 -- I like the general idea. I have been underwhelmed by the initial implementation of Pending Changes. It has had very little impact on the articles and areas that I work on most, and overall I don't think has had the positive impact that was hoped for. However, I think that continuing it and expanding it (coupled with continually improving it, which is the Wikipedia way with things) is more likely to lead toward a more ideal outcome than the alternatives of (1) scrapping it -- which means talking for at least another year about what to do instead or (2) keeping the existing inadequate arrangement. I don't think that expanding it to all BLPs is a good idea at this time, because that seems like too big an expansion for a system that's still pretty "clunky" and also because I personally think that might discourage use outside of BLPs (where there also is a large need -- and where some of the future "lessons learned" are likely to be different in kind than in BLPs). --Orlady (talk) 20:36, 3 September 2010 (UTC)[reply]
  396. Support 4--I think that all BLPs need to have either semi-protection or pending changes. I guess this makes me some type of BLP extremist; guilty as charged. I think it's better to leave out possibly true but poorly-sourced information than to include it, because we are dealing with real people, with real-life consequences. This is not the Wikipedia of 2002, with a few hundred articles and a few thousand readers; we now have 3 million articles and are one of the most visited websites globally; we need to act responsibly. Horologium (talk) 01:00, 4 September 2010 (UTC)[reply]
  397. Support 4 -- I think these steps that encourage valuable contributions but discourage most vandalism are very needed so that wikipedia can get the respect that it deserves. --Fshoutofdawater (talk) 00:34, 4 September 2010 (UTC)[reply]
  398. Support 2 Seems to have helped a bit, oppose expansion to all BLP's.Acather96 (talk) 09:56, 4 September 2010 (UTC)[reply]
  399. Support 2 There needs to be some way to prevent editing wars I think this is the best option. David Straub (talk) 10:18, 4 September 2010 (UTC)[reply]
  400. Support 4, 3, 2 in that order. Wammes Waggel (talk) 13:45, 4 September 2010 (UTC)[reply]
  401. Support 2. Keep it as it is.The current pending changes feature is okay. Will be a bit faster if more experienced editors join the reviewers team. I'd not expect any problem with that. Gryllida 14:14, 4 September 2010 (UTC)[reply]
  402. Support 2, 3 Tabercil (talk) 15:57, 4 September 2010 (UTC)[reply]
  403. Support 3, 4 the Pending changes process is an improvement; work should continue on incrementally improving it. N2e (talk) 16:16, 4 September 2010 (UTC)[reply]
  404. Support 2, 3, 4 or N for that matter. At some point in the future, Wikipedia will have to become more stable. This process must continue and be expanded. There is valuable content that needs protection. History2007 (talk) 19:50, 4 September 2010 (UTC)[reply]
  405. Support 3 or 2. I wasn't going to comment on this poll as I've had very little interaction with pending changes myself, so I thought I should leave it to those who have actually experienced it to comment. However, I just removed some blatant vandalism from a BLP which had gone unnoticed for over four months. That's just not good enough, and that brought me here. We need Pending Changes, or something like it; the current system may be flawed, but keeping it and improving it is a better option than abandoning it altogether. I would eventually support option 4, but let's get the system working a bit better first. Robofish (talk) 21:08, 4 September 2010 (UTC)[reply]
  406. Support 3 or 2. We do need, however, a more clearly defined process for handling edits that are clearly nonconstructive, but may not fall squarely into one of the nonacceptance criteria. Hullaballoo Wolfowitz (talk) 22:31, 4 September 2010 (UTC)[reply]
  407. Support 2. Keep as is. --Celtics 2008 (talk) 23:08, 4 September 2010 (UTC)[reply]
    Support 3. Will get better. -- Scray (talk) 03:19, 5 September 2010 (UTC)[reply]
    Support 4,3,2, in that order. עוד מישהו Od Mishehu 04:45, 7 September 2010 (UTC)[reply]

Other responses

edit
  1. Confused. I still don't understand how this works, so I can't tell whether it's doing what it's supposed to. If it could be made radically clearer and more transparent, then it's worth continuing the experiment. But for all I know, it's better to close it. —— Shakescene (talk) 08:17, 22 August 2010 (UTC)[reply]
    See Help:Pending changes -- Jrtayloriv (talk) 17:08, 22 August 2010 (UTC)[reply]
  2. Support 2 but on the condition that the lag be improved as a minimum, and that anything otherwise and I would support 1. :| TelCoNaSpVe :| 18:45, 22 August 2010 (UTC)[reply]
  3. I support 4, but in my opinion the bar for becoming a reviewer should be raised a little bit.  Dr. Loosmark  14:01, 24 August 2010 (UTC)[reply]
  4. Support 2, but probably not in its current form. Clear rules are needed on what should be accepted and when it is best used, perhaps for vandalism and harmful libel. This may require a broader test for a longer time to weed out the early rush when reviewers are more actively engaged earlier in the trial. I can see this being useful for pages with legal concerns like BLPs—especially little watched ones where harmful information may remain undetected—but I'm not yet convinced that it should be a default for BLPs. The process also seems to increase the workload for monitoring normal vandalism. Additionally, I agree with previous comments that "Approved" seems to imply that the article has achieved some validity, while approved edits mean something different for each editor that approves. If concerns cannot be addressed, I'd lean toward option #1 because it's a simpler scheme, easier for readers to understand, and more likely to attract to new editors. —Ost (talk) 18:19, 24 August 2010 (UTC)[reply]
    Note: the following was removed by User:Smyth at 14:06 UTC on 24 August 2010, and restored as of the timestamp of this edit. --WFC-- 02:34, 25 August 2010 (UTC)[reply]
    Yes, I would agree that "approved" is a bad term. I suggest "checked": that's not perfect but better. Si Trew (talk) 08:15, 27 August 2010 (UTC)[reply]
  5. Oppose poll per Cybercobra's comment #39 under Keep, but if and only if certain issues are addressed. I feel very strongly that the feature should be monitored carefully for the problems related to discouraging anons. I also concur with those who think that the interface and guidelines need work. Particularly, the "don't accept", "stop reviewing", and "accepting of incorrect changes just because they aren't vandalism" issues need to be addressed. The latter is my strongest concern. Entire poll is poorly thought out at best as discussion page shows. Millahnna (mouse)talk 19:33, 22 August 2010 (UTC)[reply]
  6. Oppose this biased three-options-against-one poll. Biased towards the "yeas" and likely ending with votes being counted towards an option the voter had not supported. SpinningSpark 21:05, 22 August 2010 (UTC)[reply]
    I think the best way of doing polls with more than two options is multiple rounds in which the option with the fewest votes is dropped after each round, but that would require people to come back here a few times. Hopefully we can get a feel for the real consensus after this vote. —Arctic Gnome (talk • contribs) 21:10, 22 August 2010 (UTC)[reply]
    That's not the point. It should be either a straight choice of four options, or an initial keep/close vote that makes clear that "keep" means "keep regardless". The current hybrid risks fooling voters into thinking their expressed, exclusive choices are being honoured, when those votes will instead be bundled together with conflicting votes and used to bring about a result they didn't vote for. PL290 (talk) 21:25, 22 August 2010 (UTC)[reply]
    I dislike the format of this poll especially in its original "vote" incarnation. I don't think this should be used as a "3 vs 1" poll but it can legitimately be used as a "keep vs stop" poll (and that would be less chaotic than running pro/con votes on all four options simultaneously). There are a few people with a "one extreme or the other split" (option 1 or 4) but on the whole, this straw poll is addressing the basic question "Do we want to stop the trial or not?" After the poll has been run, if (as seems likely) the trial is to be continued, then there needs to be a new debate about in what format it is kept. It would be unfair just to use the 2/3/4 results of the "keep" !votes to determine what to do next! TheGrappler (talk) 21:33, 22 August 2010 (UTC)[reply]
    I disagree—see related discussion in numerous sections on the talk page. PL290 (talk) 21:38, 22 August 2010 (UTC)[reply]
    In my opinion, Spinningspark got it 100% right in this diff. That set of instructions would have ensured that, had general polling favored keeping the trial, nobody opposed to continuing the trial would have an input on the form it was kept as. That's potentially very significant, since those people supporting an end to the trial would clearly (judging from their comments) prefer the minimal possible continuation in such circumstances, and oppose a large scale roll-out. I would like a massive expansion of flagged revs, but I want those people who disagree with me to have their say too - not just for them to be told you've lost the vote on whether we continue, now we, the victors, will choose how to proceed. That would be ludicrous. TheGrappler (talk) 21:47, 22 August 2010 (UTC)[reply]
  7. Oppose the poll; poll was created with a bias that cannot be addressed short of redoing the whole thing. —Jeremy (v^_^v PC/VC is a show-trial!) 21:15, 22 August 2010 (UTC)[reply]
  8. Oppose the poll per Spinningspark and Jeremy plus related discussion in numerous sections on the talk page. PL290 (talk) 21:38, 22 August 2010 (UTC)[reply]
  9. Scrap this poll and notify all existing participants of the new forum. Far too many grave concerns have been raised by too many independent users.   — C M B J   21:45, 22 August 2010 (UTC)[reply]
  10. Scrap this poll The poll was constructed with an extremely clear steer that the outcome is either going to be scrapping or expanding. A significant proportion of people want the thing scrapped. The fact that they are a (large) does not mean they should be entirely ignored. --WFC-- 22:04, 22 August 2010 (UTC)[reply]
  11. Defective polling instrument - Since in essence there is only a boolean choice here (keep it on or off), it's inaccurate to present the choice as four distinct options where three have the same net effect. If this is the path to closure, there should be two or three separate polls: (1) keep PC we know today in force or not; (2) continue to pursue PC; (3) best way to improve PC (assuming #2 is "yes"). //Blaxthos ( t / c ) 22:05, 22 August 2010 (UTC)[reply]
    I don't like the poll in its current form, but there is some worth in seeing how the 2/3/4s are distributed among the "keep" voters (and indeed, what "second preferences" would be among those who'd rather end the trial now) because after this binary choice, other choices are far more open. Seeing the strength of feeling about expansion of flagged revs can help inform what kind of discussion we have next, but obviously it is not a replacement for the next discussion. For instance, if the consensus is to keep, and the vast majority of "keeps" are mostly strong in favor of option 4, then we need a subsequent discussion about mass roll-out to BLPs; if consensus is to keep, but there is a more equivocal mixture of 2s and 3s with lots of comments about how the system needs to improved before it's rolled out, then we probably need to be having a very different discussion afterwards. TheGrappler (talk) 22:22, 22 August 2010 (UTC)[reply]
    No matter what option could be selected, it will require continued discussion and improvement. None of the options clarifies reviewer policy, or fixed the change/accept issue, or sets down page-use guidelines. All of those things need to be figured out no matter which option gets the most support. Still, if the 2:1 ratio of option 3 (keep with minimal expansion) : option 1 (close) remains, I don't see how we could justify ignoring that. To use the voting lingo, you only have a run-off if there's not a clear winner. But if overwhelming support is for option 3, then what is left to formally discuss besides how best to implement it? Ocaasi (talk) 23:38, 22 August 2010 (UTC)[reply]
    It is not clear whether or not option 3 would have overwhelming support in a run-off discussion. Thirty percent of the participants in this poll have essentially been deprived of their opportunity to weigh in on how to move forward if consensus is in favor of continuing the trial.   — C M B J   02:52, 23 August 2010 (UTC)[reply]
    Yeah, I've done that math, and it is worth considering. I don't quite accept the premise that the oppose voters have been deprived of anything, since they have full opportunity to pick any of the keep options. Also, consider that in a run-off, 2's and 4's may shift towards 3 in anticipation of what you just described. Last, don't forget that the difference between 2 and 3 is at max 8k low-traffic articles. That's not insignificant, but it is also not likely to be more problematic than what's already going on. It might even be necessary to test the scalability of the feature. That's not a comment on the voting procedure, just the possible outcome. Ocaasi (talk) 03:08, 23 August 2010 (UTC)[reply]
    "I don't quite accept the premise that the oppose voters have been deprived of anything, since they have full opportunity to pick any of the keep options." Huh? I truly don't understand the logic behind that at all. Those completely opposed to keeping PC are not deprived of anything because they can always vote to keep PC? WTF? The perception is, rightly or wrongly, that those voting opposed (of whom I was not originally one of) will have no say in how the implementation is carried out (as implied by options 2-4) because they are voting against (which has no such implications). If there is a follow up poll planned discussing that very issue then it has not been made clear. And based on how abruptly the poll went up after conversation tapered off, I see plenty of reason why many may have jumped to the conclusion that this poll had more finality in that regard than many seem to feel that it had. Millahnna (mouse)talk 03:32, 23 August 2010 (UTC)[reply]
    I agree the poll wasn't implemented as carefully as it could have been, but I'm not convinced the current structure is fundamentally flawed. You get to vote on: close, keep as is, keep with limited expansion, or keep with expansion to BLPs. Those are four options; you get to select the one you prefer. All options assume improvement can and must continue. Waiting for improvement before continuing is not technically possible because the developers can't just turn the feature on and off. It is reasonable to not just lump together all keeps vs. all opposes, since some keeps are only for one type, but most support for option 2, 3, or 4 is not exclusive of a general keep sentiment. I think it's reasonable not to expand until improvements happen. That is already somewhat expressed in the "gradual" expansion, and could be specified further. Re: keeping out close votes, consider this logic. If I vote for a Republican candidate, should I also get to select which Democrat I prefer if the Republican loses? Ocaasi (talk) 09:08, 23 August 2010 (UTC)[reply]
    The Democrat-Republican analogy has no relevance here. We don't make decisions based on votes (see WP:VOTE and WP:DEMOCRACY), we make them based on a consensus building model used throughout all areas of the project. It is absurd to even suggest excluding more than a hundred users from participating in such an important decision.   — C M B J   03:11, 25 August 2010 (UTC)[reply]
  12. Oppose the poll. This should be redone as two separate polls. I voted for option 1, but I would also like to express an opinion on options 2-4. Right now, the only way to do this is to vote for both and thus cancel out my initial vote. Kaldari (talk) 03:29, 23 August 2010 (UTC)[reply]
  13. Oppose the poll as biased. Should offer only two options, as we do in any RFC: either remove it or improve it. Don't just call for expansion or keeping it wholesale if there are other options. Shooterwalker (talk) 03:50, 23 August 2010 (UTC)[reply]
  14. Oppose poll This poll is terribly designed. "Keep-as-is" and "keep with changes" are separate things and shouldn't be lumped together. The current poll, or more accurately, the way it would be tallied, is almost assured to produce a "keep" result.oknazevad (talk) 03:50, 23 August 2010 (UTC)[reply]
    Agreed. This poll is seriously flawed as it stands, and it almost appears like there was an attempt, conscious or not, to stack it a certain way. SchuminWeb (Talk) 05:00, 23 August 2010 (UTC)[reply]
    What is with these opinions? This logic is flawed. At the end of the day, the poll's trying to determine how many people want to keep it, and how many want to get rid of it. Keep is a very broad stance, so asking the "keeps" to what extent they want it kept is completely reasonable. However, those who want it to cover all BLPs and those who want it expanded no more than it already is both want it kept - and that's what's important. SwarmTalk 05:35, 23 August 2010 (UTC)[reply]
    The poll is indeed terribly flawed. I want to keep it, but in a heavily modified form not represented by options 2, 3 or 4. My only course of action is to support option 1, which will be taken as saying it should go away forever. I really don't want to see it expanded in its current form. --UncleDouggie (talk) 09:32, 30 August 2010 (UTC)[reply]
  15. Oppose this poll I have gone for option 1 but only really because of the poor format of this poll that does not allow my real opinion to be presented. Davewild (talk) 07:10, 23 August 2010 (UTC)[reply]
  16. Oppose the poll although I have already voted for close. But I am not opposing because of perceived bias. I am opposed because the premise is wrong. The poll is asking the wrong question. Rather than ask about how much to expand the PC, it should be asking: 1) whether to keep PC the way it is, 2) change PC to improve the implementation workings, or 3) completely close it. Voting on how much expansion we desire distorts the results because the question is wrong. If the PC implementation were improved then my current vote of "close" could be different simply because if it works better then I would have less resistance to it being kept. HumphreyW (talk) 07:13, 23 August 2010 (UTC)[reply]
  17. Comment: Yes, the poll is not very functional. We should start the poll over, and vote simply yes vs. no. If yes prevails, then we vote on the other options to narrow it down. And obviously if no prevails we scrap the system. I strongly suggest a restart. |Finalius|T|S|C 12:59, 23 August 2010 (UTC)[reply]
  18. Oppose the poll per reasons stated by Kaldari. If the "Scrap it entirely" option lost, those voting on it should have the opportunity to vote on the next steps to be taken. Should be done as two polls. Keep/Scrap Entirely and (assuming Keep won), Large Expansion/Change Implementation/Limited Expansion. --Resplendent (talk) 14:15, 23 August 2010 (UTC)[reply]
  19. I don't see a strong reason to restart the poll, but once finished we should _then_ discuss 2 vs. 3 vs. 4. It may well be that some people prefer 1 but would pick 3 or 4 over 2. Hobit (talk) 16:05, 23 August 2010 (UTC)[reply]
    I agree, I think almost everyone voting 1 would change to option 2, rather than see option 3 or 4 implemented. Lets not take this poll as a final decision. If the decision is to keep, then lets vote again as to what extent it will be kept. We are asking two questions, but only allowing for one answer as I see it. —Charles Edward (Talk | Contribs) 17:46, 23 August 2010 (UTC)[reply]
    Speak for yourself and stop assuming. —Jeremy (v^_^v PC/SP is a show-trial!) 00:09, 24 August 2010 (UTC)[reply]
  20. Re-orgonize votes options 2,3,4 should be separates into thier own sections. If they are not separated the vote will be setup so that all versions of keep will be mashed together into one big keep, unfairly outnumbering don't keep.Sumsum2010 · Talk · Contributions 20:59, 23 August 2010 (UTC)[reply]
    Does that mean that I get three !votes, since I'll accept any "yes" option? Or is the goal to divide-and-conquer the "yes" crowd, so that a mere one-third of respondents (=editors voting no) can prevent two-thirds of respondents from getting what they prefer (=editors voting yes)? (Well, it's how the California leg works...) WhatamIdoing (talk) 21:27, 23 August 2010 (UTC)[reply]
    I see your point. This should be done as "close" or "keep" then if keep wins THEN have 4 options one of which being "any of the three".Sumsum2010 · Talk · Contributions 21:33, 23 August 2010 (UTC)[reply]
    I don't really see the problem here to be honest - You can either vote "Keep" or "Close", with the keep side having the ability to add some nuances to their vote. If we boiled the entire vote down to "Keep" or "Don't keep" we would technically pit option 1 against option 2, while discussion option 3 and 4 once we were certain we had consensus to keep. Think about it; Option 3 and 4 actually call for an extension of pending changes - gives only two options, would it be likely that people voting 3 and 4 would switch their vote to option 1? Excirial (Contact me,Contribs) 22:07, 23 August 2010 (UTC)[reply]
    If you're voting to expand it then you obviously want to keep it, albeit with caveats. —Jeremy (v^_^v PC/SP is a show-trial!) 00:07, 24 August 2010 (UTC)[reply]
  21. Restart the poll with a preferential voting system (see talk). Sceptre (talk) 22:38, 23 August 2010 (UTC)[reply]
  22. WTF??? (Okay, I admit it's not the most creative way to start a response, but it captures my feelings here on many levels.) First, I'm coming to this straw poll/discussion/whatever as an uninvolved outsider; I don't have a strong opinion on this matter. If this actually improves Wikipedia, I not only can live with this, I may even come to support it. Second, reading the relevant pages here -- Wikipedia:Pending changes/Metrics & Wikipedia:Pending changes/Closure -- I have no clue how to vote here. Nowhere does anyone state if this has improved any specific articles, made no difference on any articles, or hurt any articles, which is what I would like to know. Thirdly, there is no clear rationale for the four options: are we deciding whether "Pending changes" is a clear success (which I guess justifies option 4). or we need more information, requiring either a longer period of time or a wider sample to sample (justifying options 2 or 3), or it is destructive (justifying option 1). And if I'm baffled, how are the rest of Wikipedia's membership supposed to react to the result here? Jimmy Wales has been pushing this for years, claiming that "Pending changes" will be the final solution to all of the BLP problems -- so approving this will appear like the fix is in. Then if this straw poll fails, there will be a number of people who will believe "the inmates now run the asylum". And lastly, this whole matter still looks like a case of a solution looking for a problem to solve: since at no time has anyone explained just what this is supposed to do & provided a metric to see just how well it does it. -- llywrch (talk) 04:46, 24 August 2010 (UTC)[reply]
  23. Close poll, then have a community discussion on how to implement this - per my comments on the discussion page. This is a farce of a 'poll', and should be halted now. Jusdafax 06:43, 24 August 2010 (UTC)[reply]
  24. Dazed and confused I can see that this is a really important issue and I am FOR anything (anything!) which will stop or substantially reduce vandalism of pages. (I am sick and tired of finding pages disrupted by the vandalism/POV of unregistered users). But I cant really follow all of this stuff at all. I'm not even sure that I'm entering this comment in the right place... Wembwandt (talk) 10:58, 25 August 2010 (UTC)[reply]
  25. Keep the poll
    1. Instructions have been consistent for the majority of participants.
    2. All keep options include at least keep as is. Options 2 and 3 add additional support, but are keep-inclusive.
    3. Votes to only support one option are few
    4. Oppose voters had/have the option to vote 'keep as is (with improvements)'. Since that is the minimal keep scenario, anything less is naturally a close vote. Voting 'close', and then wanting to express support for a version of 'keep' allows two contradictory positions, essentially two votes on the same poll.
    5. Proposals for a conditional oppose or conditional supports are not currently possible, as the feature will be turned off in 1 month, and technical developments are in the works. It is assumed that improvements will continue, particularly to the interface. Their exact date is not known but is a high priority. The option 3 limited expansion is minimal and would likely be rolled out over time, as improvements happened, reducing the need for a conditional expansion option.
    6. The whole feature is still under evaluation and development. A keep vote does not mean keep this way forever. Even support for keeping the feature is conditional on its improvement.
    7. Consensus still needs to be determined. A vote is not binding, though it is important.
    8. Discussion is not finished. There is a massive list of problems and recommendations at Wikipedia:Pending_changes/Closure which need it. Ocaasi (talk) 07:33, 24 August 2010 (UTC)[reply]
    #1 is objectionable because the instructions were not consistent during the first 24 hours, and even if they had been, they still arguably misguided a fair parcentage of participants. #4 is extremely objectionable, because it imposes a double standard that would undermine an unthinkable number of contributors.   — C M B J   04:35, 25 August 2010 (UTC)[reply]
  26. This page is way too long. Pending changes is a good idea in principle however some guidance would be helpful for reviewers. Also pages like Great Wall of China seem to attract very little ligament ip editing and a lot of random un productive edits. Traditional semi-protection may be better in these cases. Phatom87 (talk • contribs) 16:04, 25 August 2010 (UTC)[reply]
  27. Confused, aside from the chaotic nature of the poll itself, no evidence or metrics have been provided for PC's performance, so how can anyone make an informed decision? OrangeDog (τ • ε) 18:00, 26 August 2010 (UTC)[reply]
    This is a very valid point. I think there should have been some sort of data to count during the trial (i.e., number of reverted "accepted" edits, number of unaccepted edits, average load, average edits per protected page, etc.) This would probably have made the trial a little more worthwhile, and helps eliminate bias from voters who did not become a Reviewer. EricLeb01 (Page | Talk) 19:33, 26 August 2010 (UTC)[reply]
  28. Scrap Poll and reorganize. I support 2 moderately; I very strongly oppose 4. The run has not been a disaster, although several of the PC articles have had to be semi-protected, suggesting that PC is useful, but not a panacea. On the other hand, imposing it by bot, like semi-protecting by bot, would be a disaster. I have no way to express this opinion effectively. This edit does show that Off2riorob has preconceived notions, which the abominable structure of this poll favors; and this post shows he thinks this is a majority vote. Septentrionalis PMAnderson 01:02, 27 August 2010 (UTC)[reply]
  29. Scrap this "stacked deck" poll. Only one "drop it" option, and three "keep it" options, with the the "keep it" ones added together. ? ! ? ! This is mathematical deck-stacking 101 North8000 (talk) 11:13, 27 August 2010 (UTC)[reply]
    Option 3 and 4 are exactly the same as option 2, except that they wish for an even larger implementation of pending changes. Say that we would only provide option option 1 and 2 - anyone who would vote option 3 or 4 would choose option 2 in this case. This is not a "stacked poll" where different options are offered to influence the outcome - The various options offer the ability to add nuances to the vote. If the majority of the votes would state option 1 and 2, we could determine that the community at least doesn't want expansion of pending changes - if the majority would be 3 and 4 we could determine that the community doesn't only want to keep pending changes, but equally wishes to expand its employment. Besides, this is not a majority vote in any sense - it is merely a poll to determine what the community thinks about pending changes. Excirial (Contact me,Contribs) 14:22, 27 August 2010 (UTC)[reply]
    • On the "keep/drop" question, 3 of the 4 choices are "keep" and somebody is going to end up adding those together. That's deck stacking 101, even if unintended. I wasn't implying avoiding polling the nuances within "keep". What's needed is what others are pervasively saying here....... a separate 2 choice question on keep vs. drop. North8000 (talk) 14:52, 29 August 2010 (UTC)[reply]
    • The majority is not the community; it may be just over half the community, and it may be a strongly energized minority of the community as a whole. That's why we don't run by majority vote.
    Also, it is not clear what those who chose Option 1 would do in a better-phrased poll; some people want 1 or 4. but no compromise. Septentrionalis PMAnderson 14:35, 27 August 2010 (UTC)[reply]
  30. A few points:-
    • A high percentage of edits that should have been rejected were allowed simply because the review is treated as if it has to be done immediately. This results in reviews which were being looked at in detail by an editor, before being allowed or rejected, being passed by another quick fire reviewer who just looked at it and then allowed it (it did not include spam or swearing etc. so was allowed) without paying any attention to the content and the editor who was looking in detail then finds that someone else has allowed it while they were still examining the edits/sources. This led to more work for the involved editors who then had to clean up the mess. In many cases the reviewers knew nothing about the topics, did not do any research on the edits and did not fully understand the impact that their "allow" decisions were leading to.
    • There was no way to disallow the edits under review - the only option was to allow, then undo. There should have been an option to ignore or disallow
    • High proportion of editors were given the reviewers rights who treated the reviews as if they were only looking for vandalism and seem to have been too quick off the mark to allow as long as the edits did not contain spam or swearing.
    • Once a review was underway the process should have locked out other reviewers for a period of say 30 mins to prevent a detailed study being voided by a quickfire reviewer as well as stopping multiple editors from working on it only to find that the review was already passed making their work pointless Chaosdruid (talk) 02:20, 28 August 2010 (UTC)[reply]
    These comments might be better placed at WP:Pending_changes/Closure. Ocaasi (talk) 10:27, 28 August 2010 (UTC)[reply]
    • the only option was to allow, then undo – Not true, it is possible to click "undo" directly, then the offending revision will never be displayed to the public.
      Not a very good defense. Chaosdruid has clearly reviewed; he has misunderstood the system; therefore it's not an optimal reviewer interface. Septentrionalis PMAnderson 23:41, 28 August 2010 (UTC)[reply]
      Agreed. – Smyth\talk 09:22, 29 August 2010 (UTC)[reply]
    • treated the reviews as if they were only looking for vandalism – Blame the reviewing guidelines, not the reviewers. This is exactly what the current guidelines encourage reviewers to do.
    • lock out other reviewers for a period of say 30 mins to prevent a detailed study being voided – You haven't thought this through. The only meaningful way to achieve this would be to lock the entire article against edits, which is surely unacceptable. And what if the first person to obtain the lock made the wrong decision, but very slowly? Then you would be locked out of making the right one.
    • review was already passed making their work pointless – It's not pointless: if someone accepts an edit while you're thinking about a complete or partial reversion of it, your reversion can still go ahead. – Smyth\talk 10:55, 28 August 2010 (UTC)[reply]
  31. Option 5, who cares whether it's a BLP? Every article is important - Apply to every article that receives persistent vandalism, including the top 100 most vandalized articles. - ʄɭoʏɗiaɲ τ ¢ 4:03 pm, 25 August 2010, last Wednesday (3 days ago) (UTC−4)
    The trial has proven that this is not tenable simply *because* they receive massive amounts of vandalism. It clogs the edit filter. —Jeremy (v^_^v PC/SP is a show-trial!) 20:07, 28 August 2010 (UTC)[reply]
  32. Discard poll results and start over. Including the phrase "improvements to the interface and policy continue" causes a severe bias towards keeping, encouraging those who oppose all three keep options to vote keep in the hope of some undefined future improvement. If the "improvements continue" label is retained, close should be labeled with "close, replace with a new, improved policy." Guy Macon 16:16, 28 August 2010 (UTC)[reply]
    That would be fair, except many of the close voters do have existential problems with the feature. They wouldn't want it even if it was cleaner or faster. The other reason is that the developers emphasized not toggling the feature on and off. That made 'close but improve' an untenable option. Please see this discussion on talk for more clarification. There might have been/be 'some' window to improve the policy while turning it off, but developer preferences seemed to be to avoid that effort if possible. Since a minimal 'keep as is option' is still available, the difference between 'close and improve' and 'keep as is and improve'—given that current use is only on 1.4k articles and though not perfect hasn't been particularly disruptive—is fairly minor. Ocaasi (talk) 18:44, 28 August 2010 (UTC)[reply]
  33. Keep the poll, continue the poll, but take seriously the methodological concerns that have been raised, when interpreting the results. Instead of just counting a "vote", which of course it is not. Obviously. --Tryptofish (talk) 20:47, 28 August 2010 (UTC)[reply]
  34. Functionality to focus on vandalism control. The straw poll has not resulted in a clear consensus, indicating that the PC trial tried to take too big a bite (the increment in functionality was too large). My suggestion is to automatically accept the change after NN minutes (NN = some number like 30 minutes), which discourages instant gratification of vandals, and make this functionality an optional feature in the toolbox of existing vandalism control processes. Obankston (talk) 20:59, 28 August 2010 (UTC)[reply]
  35. Scrap the poll and start over.The poll was poorly engineered and confuses the issue. Restart the poll as diametric: close vs. keep. Then, if 'keep' is the determined outcome, have further discussion/poll to determine degree of implementation.Hyzerflip (talk) 23:31, 28 August 2010 (UTC)[reply]
  36. Support only 2, otherwise 1 — Initially, I had supported PC over semi, but now after dealing with this in the wild, I've come to three realizations: first, PC on low-traffic, low-interest, or highly-specialized articles seems to lead to larger backlogs in PC patrolling due to the unexpectedly large amount of trivial stuff that I've seen clogged in the PC queue for hours due to something unexpectedly difficult when it comes to verifying the given edits; second (and contrary to my initial thoughts), PC should be used with as much restraint as—maybe even greater retraint than—semiprotection due to the increased demand for reviewers as the number of PC articles increases, which leads to a diminishing marginal returns situation; third, (and this is speculation, but justified, imo) over-use of the tool (i.e., to a point where the public isn't surprised to see PC) might lead to significant decreases in edits—both the good and bad—due to the increased learned helplessness inherent to a review/reject process and decreased immediate-results-style feedback on positive edits. Option 4 should be completely out of the question in my opinion, as it would be a dangerous, unexpectedly disastrous road to start down. Anyway, this is just my experience so far. Cheers =) --slakr\ talk / 10:50, 30 August 2010 (UTC)[reply]
  37. Oppose this poll as per Kaldari. Luka666 (talk) 22:37, 1 September 2010 (UTC)[reply]
  38. Oppose the poll per oknazevad. ialsoagree (talk) 23:54, 1 September 2010 (UTC)[reply]
    I feel the need to state that I don't think polling in general is bad for wikipedia. But it should be there to facilitate discussion. This poll clearly does not do that. I think that fact is emphasized by the lumping together of otherwise different ideas. I personally would lean toward the "keep" side, but think there are improvements that must be made for the feature to be worth keeping. That leaves me with the dilemma of either supporting the feature no matter what, or voting to end it. ialsoagree (talk) 17:52, 3 September 2010 (UTC)[reply]
  39. Oppose this and any future poll, however reorganized. Polls are evil; they are the wrong way to make decisions on Wikipedia. —Angr (talk) 14:32, 2 September 2010 (UTC)[reply]
  40. Oppose the poll per Kaldari. MurfleMan (talk) 23:18, 2 September 2010 (UTC)[reply]
  41. Oppose the poll and the entire concept of a poll. For Wikipedia purposes, polls really are evil -- Mattinbgn (talk) 00:57, 3 September 2010 (UTC)[reply]
  42. Oppose this poll because it is too complicated to collect opinions reliably. But I don't necessarily oppose all polls on Wikipedia: they aren't automatisally evil. - Pointillist (talk) 01:16, 4 September 2010 (UTC)[reply]
  43. Oppose poll format This poll is designed with bias. The "keep" point of view has three options. The "don't keep" point of view only has one. This will almost guarantee the "keep" point of view winning the poll. Jason Quinn (talk) 02:18, 4 September 2010 (UTC)[reply]
  44. Poll is defective 1) Consensus is not a vote, and the !votes here demonstrate a lack of consensus. 2) The options are presented in a biased manner. 3) Options have not been fully explored, and we are still learning how to use pending changes in a way that is effective. 4) We need to learn more from the other large scale pending changes trial - I've seen very little from the German project, and their experiences are relevant to our trial. Triona (talk) 20:27, 4 September 2010 (UTC)[reply]
    1 – Close, disable the feature entirely. Wikipedia is already becoming more and more for "Wikipedians" and the new pending change is too confusing to new users. Brandorr (talk) 03:14, 5 September 2010 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Pending_changes/Straw_poll&oldid=1251437489"