Wikipedia:Pending changes/Straw poll

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

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 and any articles as requested. Improvements to the interface and policy continue.
• 4 – Keep, with expansion by bot to all biographies of living persons. Improvements to the interface and policy continue.

Straw poll

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

Close: option 1

1. Support 1 - System will be confusing to newcomers. Phearson (talk) 00:57, 23 August 2010 (UTC)
2. Support 1 - Keep the system open. Shenhemu (talk) 10:03, 24 August 2010 (UTC)
3. 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)
4. 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)
5. Support 1 Is this really worth keeping? ~~ Hi878 ^{(Come shout at me!)} 00:09, 22 August 2010 (UTC)
6. Support 1, discourages new editors from editing.Sumsum2010 · Talk · Contributions 00:22, 22 August 2010 (UTC)
7. 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)
8. 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)
9. 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)
10. Support 1 Slow with unclear and not followed standards.Cptnono (talk) 00:58, 22 August 2010 (UTC)
11. 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)
12. Support 1 Bejinhan talks 03:03, 22 August 2010 (UTC)
13. 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)
14. 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)
15. Support 1 it doesn't seem useful to me, doesn't stop socks, etc per Jeske Pilif12p :  Yo  03:17, 22 August 2010 (UTC)
16. 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)
17. 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)
18. 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)
19. Support 1. Unnecessary complication.Biophys (talk) 04:58, 22 August 2010 (UTC)
20. 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)
21. 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)
22. Support 1. No real benefit for the creation of tons of busy work. Courcelles 05:40, 22 August 2010 (UTC)
23. 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)
24. 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)

    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)

25. 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)
26. 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)
27. 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)
28. Support 1 Deters newcomers. Elitist. Richard75 (talk) 10:35, 22 August 2010 (UTC)
29. Support 1. Discourages new users from editing. Adds unnecessary extra work for others. Offliner (talk) 11:04, 22 August 2010 (UTC)
30. 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)
31. 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)
32. 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)
33. Support 1 Goes against everything WP is about. Access Denied ^talk _contribs editor review 15:11, 22 August 2010 (UTC)
34. Support 1 Wikipedia is improved by its open edit policy, not by adding layers of bureaucracy. I, Englishman^{Wouldst thou speak? • Handiwork} 15:33, 22 August 2010 (UTC)
35. 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. _EricLeb⁰¹ (Page | Talk) 15:38, 22 August 2010 (UTC)
36. 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)
37. 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)
38. Support 1 – Kerαunoςcopia^◁_galaxies 17:01, 22 August 2010 (UTC)
39. 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)
40. 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)
41. 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)
42. Support 1 ῤerspeκὖlὖm ^{in ænigmate ( talk )} 19:23, 22 August 2010 (UTC)
43. 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)
44. 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)
45. Support 1. Deters newcommers. Limited effectiveness against vandals. -FASTILY ^(TALK) 20:19, 22 August 2010 (UTC)
46. Support 1 per all above. All Hallow's Wraith (talk) 20:27, 22 August 2010 (UTC)
47. Support 1. Too complex, little real benefit. --Sable232 (talk) 21:01, 22 August 2010 (UTC)
48. 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)
49. 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)
50. Support 1. I don't understand it. And i don't think it does anything useful. Debresser (talk) 22:41, 22 August 2010 (UTC)
51. 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)
52. 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)
53. 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)
54. Support 1 Can't see it as a solution to the vandalism problem. Arteyu ? _{Blame it on me !} 23:01, 22 August 2010 (UTC)
55. 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)
56. Support 1 This is frustrating to sit and wait for someone else to approve it. Clamshell Deathtrap (talk) 00:16, 23 August 2010 (UTC)
57. 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)
58. Support 1 More went wrong than went right. Jsayre64 (talk) 00:33, 24 August 2010 (UTC)
59. Support 1 More trouble than it's worth, ineffective for most articles that needed semi-protection.—Kww(talk) 01:21, 23 August 2010 (UTC)
60. 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)
61. 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)
62. 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)
63. 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)
64. 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)
65. 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)
66. 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)
67. 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)
68. 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. OhanaUnited^{Talk page} 03:50, 23 August 2010 (UTC)
69. 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)
70. 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)
71. Support 1 per the reasons I discussed here. --William S. Saturn (talk) 05:18, 23 August 2010 (UTC)
72. Support 1: Complicates things unneccessarily with the interface and takes up more time.--Forty two^{the answer?} 06:57, 23 August 2010 (UTC)
73. 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)
74. Support 1 As per all of the above. Qwrk (talk) 07:43, 23 August 2010 (UTC)
75. 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)
76. Support 1 costs > benefits

Jebus989^★ 08:52, 23 August 2010 (UTC)

1. 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)
2. 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)
3. 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)
4. 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)
5. 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)
6. 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)
7. Support 1 would be very off-putting to new users 82UK (talk) 15:09, 23 August 2010 (UTC)
8. Support 1 - not practical. Adrian (talk) 15:11, 23 August 2010 (UTC)
9. 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)
10. 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)
11. 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)
12. 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)
13. 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-. Torque3000^Talk 18:41, 23 August 2010 (UTC)
14. Too complicated and cumbersome; the downsides outhweigh the benefits.  Sandstein  19:08, 23 August 2010 (UTC)
15. Found no advantages whatsoever using this system, certainly no better than semi-protection. BigDom 19:31, 23 August 2010 (UTC)
16. Support 1 - Unnecessarily complex. I am sure a better approach can be found. (RT) (talk) 20:26, 23 August 2010 (UTC)
17. Support 1 - Get rid of it. Groundsquirrel13 (talk) 21:04, 23 August 2010 (UTC)
18. Support 1 - Does not encourage new users. --Traveler100 (talk) 21:36, 23 August 2010 (UTC)
19. 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)
20. 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)
21. 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)
22. 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)
23. 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)
24. 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)
25. 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)
26. Support 1 Pending changes should be banished to Room 101. Jared Preston (talk) 09:25, 24 August 2010 (UTC)
27. 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)
28. Gurch (talk) 11:19, 24 August 2010 (UTC)
29. 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)
30. Support 1 Bureaucratic, unnecessary and elitist. Dalliance (talk) 11:50, 24 August 2010 (UTC)
31. Support 1 add more semi protection and the same affect will happen except the confusion! mabdul 13:16, 24 August 2010 (UTC)
32. Support 1 Complicated, obtuse, not really needed. Nave.notnilc (talk) 14:29, 24 August 2010 (UTC)
33. Support 1 confusing, unhelpful, unwieldy, and doesn't accomplish what it purports to accomplish. Exploding Boy (talk) 14:38, 24 August 2010 (UTC)
34. 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)
35. Support 1 Confusing, unnecessary, elitist, and ripe for abuse.Willcrys 84 (talk) 15:46, 24 August 2010 (UTC)
36. 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)
37. Support 1 It's complicated and I don't believe it helps.--Alistair Stevenson (talk) 18:31, 24 August 2010 (UTC)
38. Support 1 Since this can block even confirmed/autoconfirmed users' edits from appearing, I cannot support. Sakkura (talk) 19:26, 24 August 2010 (UTC)
39. 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)
40. 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)
41. Support 1 - A cumbersome, inefficient, and thoroughly useless system. Carrite (talk) 22:23, 24 August 2010 (UTC)
42. Support 1 Both confused and confusing SRESQ (talk) 23:01, 24 August 2010 (UTC)
43. 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)
44. Support 1 Confusing and does not reduce the workload of vandalism patrolling; semi-protection is a better alternative. RJC ^Talk_Contribs 00:18, 25 August 2010 (UTC)
45. Support 1 No clear benefit. - JeffJonez (talk) 00:44, 25 August 2010 (UTC)
46. 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)

    Also encourages subtle vandalism. Mr. R00t ^Talk 01:19, 25 August 2010 (UTC)

47. 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)

Keep: options 2, 3, or 4

1. Support 2 The Thing // Talk // Contribs 23:13, 21 August 2010 (UTC)
2. 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)
3. Support 3 - if this option is successful, hopefully after improvements, we can then expand further. PhilKnight (talk) 23:28, 21 August 2010 (UTC)
4. 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)
5. Support 3 Gobonobo ^{T C} 23:34, 21 August 2010 (UTC)
6. Support 3--Wetman (talk) 23:35, 21 August 2010 (UTC)
7. Support 3 Doc James (talk · contribs · email) 23:37, 21 A ugust 2010 (UTC)
8. Support 2 —Soap— 23:38, 21 August 2010 (UTC)
9. Support 3 and definitely also shift it from high traffic to lower traffic articles. -84user (talk) 00:00, 22 August 2010 (UTC)
10. Support 3 My76Strat 00:03, 22 August 2010 (UTC)
11. Support 3 — {{Nihiltres|talk|edits|⚡}} 21:44, 24 August 2010 (UTC)
12. Support 3 Ғяіᴅaз'§Đоом | Spare your time? 00:31, 22 August 2010 (UTC)
13. 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)
14. 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)
15. Support 2 as a minimum - no objection to 3 or 4 being trialled, tool was useful. Off2riorob (talk) 00:34, 22 August 2010 (UTC)
16. 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)
17. Support 3 but where do these vote comment guidelines come from? --Mkativerata (talk) 00:39, 22 August 2010 (UTC)
18. Support 4 , but seriously consider usability. --Cyclopia^talk 01:12, 22 August 2010 (UTC)
19. 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)
20. Support 3 Pending changes has a lot of potential to help maintain the quality of Wikipedia. Tyrol5 [Talk] 01:19, 22 August 2010 (UTC)
21. 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)
22. 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)
23. 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. Mkdw^talk 02:08, 22 August 2010 (UTC)
24. Support 2 - and revisit again. --Threeafterthree (talk) 02:53, 22 August 2010 (UTC)
25. 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)
26. 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)
27. Support 3  ℳono  03:54, 22 August 2010 (UTC)
28. Support 3 with emphasis on improvements. DocOfSoc (talk) 04:06, 22 August 2010 (UTC)
29. Support 3 ErikHaugen (talk) 04:34, 22 August 2010 (UTC)

    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)

30. 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)
31. Support 2 (edit conflict) If you know how to use it, is useful. Tbhotch^{Talk C.} 04:58, 22 August 2010 (UTC)
32. 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)
33. Support 3--Cannibaloki 05:09, 22 August 2010 (UTC)
34. 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)
35. Support 3 From what I have seen, this is helping the project. --Ckatz^chat_spy 05:13, 22 August 2010 (UTC)
36. 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)

    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)

37. Support 4 —Where's '5'? Future is thataway→ Cheers, Jack Merridew 05:31, 22 August 2010 (UTC)
38. Support 3 or 4 --Diannaa ^(Talk) 05:36, 22 August 2010 (UTC)
39. 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)
40. 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)
41. Support 2, for ultimately being a net positive. -- œ^™ 06:46, 22 August 2010 (UTC)
42. 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)
43. Support 3 - This system is a net positive for the project and should be slowly expanded.--Sodabottle (talk) 07:13, 22 August 2010 (UTC)
44. 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)
45. 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)
46. Support 3 — Glenn L (talk) 07:26, 22 August 2010 (UTC)
47. Support 3 - useful alternative to either semi-protection or no protection in some cases. -- zzuuzz ^(talk) 07:30, 22 August 2010 (UTC)
48. Support 3 or 4 Dodoïste (talk) 07:47, 22 August 2010 (UTC)
49. Support 3. Revision/clarification of guidelines for reviewers might be in order, though. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 08:04, 22 August 2010 (UTC)
50. Support 3. Would consider support 4 once wrinkles are ironed out. TFOWR 08:06, 22 August 2010 (UTC)
51. Support 3 or 4 10k is a bit low. ϢereSpielChequers 08:10, 22 August 2010 (UTC)
52. 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)
53. Support 3 I like this idea but it needs expansion if it is going to stay. Iamcool234 08:28, 22 August 2010 (UTC)
54. Support 2 or 3 assuming the interface can continue to improve. -- Eraserhead1 <talk> 08:42, 22 August 2010 (UTC)
55. Support 4, 3, or 2 (in order of preference).   — Jeff G.  ツ 08:45, 22 August 2010 (UTC)
56. Support 4, and therefore (obviously) 3 and 2 as well. DVdm (talk) 08:50, 22 August 2010 (UTC)
57. Support 3 or 2(in order of preference). Still could use some work before 4-- WORMMЯOW  09:25, 22 August 2010 (UTC)
58. Support 3. I don't think it's needed for all BLPs. Svick (talk) 09:52, 22 August 2010 (UTC)
59. Support 3 Misarxist (talk) 09:54, 22 August 2010 (UTC)
60. Support 3. I think it needs to be improved before being expanded on to all BLPs.--EchetusXe 09:55, 22 August 2010 (UTC)
61. Support 3 Still needs some improvements. Theleftorium ^(talk) 10:00, 22 August 2010 (UTC)
62. 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)
63. Support 4 --Ziko (talk) 10:31, 22 August 2010 (UTC)
64. 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)
65. Support 3 Schapel (talk) 11:17, 22 August 2010 (UTC)
66. 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)
67. 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)
68. 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)
69. 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)
70. Support 3 Willking1979 (talk) 12:20, 22 August 2010 (UTC)
71. 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)
72. Support 3 Graham Colm (talk) 12:25, 22 August 2010 (UTC)
73. 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)
74. 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. --CastAStone/^/(talk) 12:48, 22 August 2010 (UTC)
75. Support 2 It worked with preventing BLP vandalism and some vandalism on other articles. ^GB86 13:21, 22 August 2010 (UTC)
76. 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)
77. Support 3 or 4. - Dank (push to talk) 13:25, 22 August 2010 (UTC)
78. 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)
79. Support 3 or 4. Salvio ^{Let's talk 'bout it!} 13:44, 22 August 2010 (UTC)
80. Support 3--intelati 13:51, 22 August 2010 (UTC)
81. Support 4 or 3, Spellcast (talk) 13:57, 22 August 2010 (UTC)
82. Support 4. --Funandtrvl (talk) 14:07, 22 August 2010 (UTC)
83. 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)
84. Support 4, 3, 2 in that order. NW (Talk) 14:19, 22 August 2010 (UTC)
85. Support 3. ~NSD (✉ • ✐) 14:27, 22 August 2010 (UTC)
86. Support 4. The Raptor ^{You rang?}/_{My mistakes; I mean, er, contributions} 14:28, 22 August 2010 (UTC)
87. 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)
88. 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)
89. Support 3 or 4 I'd prefer to see 3. Captain panda 15:34, 22 August 2010 (UTC)
90. Support 3 I think it should continue with expansion. --Nascar1996 ^{Contributions / Guestbook} 15:58, 22 August 2010 (UTC)
91. Support 3 Make sure reviewing process is a little improved code wise. Allmightyduck  What did I do wrong? 16:15, 22 August 2010 (UTC)
92. 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)]
93. Support 3 – My rationale is in Wikipedia:Pending changes/Closure. – Smyth\^talk 16:53, 22 August 2010 (UTC)
94. 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)
95. 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'sPonyo^shhh 16:58, 22 August 2010 (UTC)
96. (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)
97. Support 2, 3, and 4, favoring 3 the most. John Carter (talk) 17:16, 22 August 2010 (UTC)
98. 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)
99. Support 2, 3, and 4, favoring 3 the most. Oreo Priest ^talk 17:23, 22 August 2010 (UTC)
100. 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)
101. 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)
102. Support 4 or 3 1exec1 (talk) 17:52, 22 August 2010 (UTC)
103. 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)
104. Support 2 Proposal and technology need work. Particular concern is not discouraing new editors. Lfstevens (talk) 18:02, 22 August 2010 (UTC)
105. 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)
106. Support 3 – It isn't being used enough, and is working pretty well. —MC10 (T•C•GB•L) 18:51, 22 August 2010 (UTC)
107. Support 3 although 2 or 4 are fine as well. Wknight94 ^talk 18:56, 22 August 2010 (UTC)
108. 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)
109. 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)
110. Support 3 most, but also support 2 and 4. --JaGa^talk 20:14, 22 August 2010 (UTC)
111. 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)
112. 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)
113. 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)
114. 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. Swarm^Talk 20:52, 22 August 2010 (UTC)
115. Support 3 reduces vandalism and improves the readers' experience as well. --Elekhh (talk) 20:54, 22 August 2010 (UTC)
116. 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)
117. 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)
118. 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)
119. 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)
120. 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)
121. 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)
122. 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)
123. 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)
124. 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. §hep^Talk 22:53, 22 August 2010 (UTC)
125. Support 3 and 4 Mootros (talk) 22:55, 22 August 2010 (UTC)
126. 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)
127. Support 2 Wikiscient (talk) 23:32, 22 August 2010 (UTC)
128. 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)
129. Support 3 and 4. Ironholds (talk) 00:10, 23 August 2010 (UTC)
130. Support 3 gradual expansion will let the system evolve as needed. WuhWuzDat 00:20, 23 August 2010 (UTC)
131. 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)
132. 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)
133. Support 3. DrNegative (talk) 01:10, 23 August 2010 (UTC)
134. Support 3 - Agree with PhantomSteve, seems to work better with lower traffic articles. Mlpearc powwow 01:18, 23 August 2010 (UTC)
135. Support 4, or 2/3. Needs polishing, but otherwise a useful tool. vvv^t 02:08, 23 August 2010 (UTC)
136. 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)
137. Support 3 or 4 mgiganteus1 (talk) 02:13, 23 August 2010 (UTC)
138. Support 2 Openskye (talk) 02:14, 23 August 2010 (UTC)
139. Support 3 Needs work but otherwise a useful tool.--Steam Iron 02:26, 23 August 2010 (UTC)
140. 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. superluser_tc 2010 August 23, 02:29 (UTC)
141. Support 4 Maddie ^talk 02:41, 23 August 2010 (UTC)
142. 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)
143. 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)
144. 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)
145. 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)
146. Support 4 with 3 as a 2nd choice and 2 as a 3rd choice. Rlendog (talk) 03:44, 23 August 2010 (UTC)
147. 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. —Bruce1ee^talk 07:17, 23 August 2010 (UTC)
148. Support 2 --Saukkomies ^talk 07:38, 23 August 2010 (UTC)
149. Support 3 - per successful trial, but issues should be fixed before widespread use. AJRG (talk) 09:25, 23 August 2010 (UTC)
150. Support 3, and reconsider going for 4 in the long run. – sgeureka ^t•c 09:43, 23 August 2010 (UTC)
151. 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)
152. 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)
153. 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)
154. 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)
155. Support 3 would be my preference, with possible extension to 4 as noted above.--SarekOfVulcan (talk) 14:16, 23 August 2010 (UTC)
156. 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)
157. Support 4 . --CutOffTies (talk) 15:38, 23 August 2010 (UTC)
158. 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. Seaphoto^Talk 16:18, 23 August 2010 (UTC)
159. Support 3 Trial seems has been going alright. Expand number of articles and keep improving things. -fnlayson (talk) 16:23, 23 August 2010 (UTC)
160. Support 3 - and continue to improve and expand • Astynax ^talk 16:38, 23 August 2010 (UTC)
161. 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)
162. 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)
163. 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)
164. Support 3. The recent trial left many open questions. Needs further testing with an expanded scope. --Stepheng3 (talk) 17:41, 23 August 2010 (UTC)
165. 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)
166. 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)
167. Support any, most preferably 3. Very good system. Stifle (talk) 18:50, 23 August 2010 (UTC)
168. Support 3 – allen四names 19:00, 23 August 2010 (UTC)
169. Support 3; willing to accept 2 or 4. WhatamIdoing (talk) 19:55, 23 August 2010 (UTC)
170. 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)
171. 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)
172. Support 4; should be extended to all articles like in de.wp! →Alfie^±Talk 22:14, 23 August 2010 (UTC)
173. 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)
174. 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)
175. Support 2 or 3 and all FAs per Second Law of Thermodynamics. Haus^Talk 00:08, 24 August 2010 (UTC)
176. Support 3. We'll work it out over time. Barrylb (talk) 00:29, 24 August 2010 (UTC)
177. 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)
178. 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)
179. 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)
180. 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)
181. Support 2, but keep talking about 4. Someguy1221 (talk) 05:20, 24 August 2010 (UTC)
182. 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)
183. Support 3 and begin testing implementation of 4. First Light (talk) 06:06, 24 August 2010 (UTC)
184. Support keeping it - We can discuss the next step if the consensus is to keep it. ~~ GB fan ~~ 06:27, 24 August 2010 (UTC)
185. 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)
186. Support 4, --  LYKANTROP  ✉ 08:11, 24 August 2010 (UTC)
187. 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)
188. Support 3 or 4 A liberal alternative to protection, retaining Wikipedia's democratic philosophy whilst increasing integrity. The JPS^{talk to me} 09:00, 24 August 2010 (UTC)
189. Support 3. It seems to be doing a good job so far. Quantpole (talk) 10:59, 24 August 2010 (UTC)
190. Support 3 Kneale (talk) 11:19, 24 August 2010 (UTC)
191. Support 4, 3, 2, ordered in level of preference. Blurpeace 12:57, 24 August 2010 (UTC)
192. Support 3 - Skysmith (talk) 13:01, 24 August 2010 (UTC)
193. Support 3 or 4 - TexasAndroid (talk) 13:25, 24 August 2010 (UTC)
194. Support 3 - Only have small issues in regards to the articles it was trialed on. ZooPro 13:33, 24 August 2010 (UTC)
195. Support 3 or 4 ʘ alaney2k ʘ (talk) 13:47, 24 August 2010 (UTC)
196. Support 3 or 4 --The Taerkasten (talk) 14:03, 24 August 2010 (UTC)
197. 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)
198. Support 4 - Keeps the simplistic vandalism at bay. Tarc (talk) 14:38, 24 August 2010 (UTC)
199. 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)
200. Strong Support 4, support 2 and 3 – ukexpat (talk) 16:02, 24 August 2010 (UTC)
201. Support 2 or 4 Steven Walling 16:34, 24 August 2010 (UTC)
202. 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.
203. 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)
204. Support 3 A Quest For Knowledge (talk) 17:10, 24 August 2010 (UTC)
205. 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)
206. Support 3 PluniAlmoni (talk) 18:43, 24 August 2010 (UTC)
207. 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)
208. 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)
209. Support 3 Tim Vickers (talk) 19:39, 24 August 2010 (UTC)
210. Support 3 —Chris!_c/t 20:01, 24 August 2010 (UTC)
211. Support 4, 3, or 2 in decreasing order of preference. Plastikspork _―Œ^(talk) 20:21, 24 August 2010 (UTC)
212. 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)
213. Support 2. Needs more time. Powers ^T 21:11, 24 August 2010 (UTC)
214. Support 2. Strongly support. Shabidoo | Talk 21:20, 24 August 2010 (UTC)
215. Support 4, but not automatically for BLPs that are semi or fully protected. -- Jeandré, 2010-08-24t21:34z 21:34, 24 August 2010 (UTC)
216. Support 3. PaddyLeahy (talk) 21:40, 24 August 2010 (UTC)
217. Strongly support 3 —Mikemoral♪♫ 22:09, 24 August 2010 (UTC)
218. 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)
219. Support 3. Armbrust ^Talk _Contribs 22:31, 24 August 2010 (UTC)
220. 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)
221. Support 4 --Rocksanddirt (talk) 22:46, 24 August 2010 (UTC)
222. 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)
223. Support 2, 3 & 4, although 3 would be first pick. Lexicografía (talk) 23:00, 24 August 2010 (UTC)
224. Support 4 else 3 else 2. BLPs need more protection. --JWSchmidt (talk) 23:44, 24 August 2010 (UTC)
225. 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)
226. 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)
227. Support 2 and a better polling methodology. Recognizance (talk) 00:56, 25 August 2010 (UTC)
228. 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)
229. Support 4, then 3, then 2. We need to protect all BLPs. Mahanga (Talk) 01:50, 25 August 2010 (UTC)
230. 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)

Other responses

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)

   See Help:Pending changes -- Jrtayloriv (talk) 17:08, 22 August 2010 (UTC)

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)
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)
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)

1. 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)

1. 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)
2. 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)

   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)

   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)

   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)

   I disagree—see related discussion in numerous sections on the talk page. PL290 (talk) 21:38, 22 August 2010 (UTC)

   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)

3. 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)
4. 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)
5. 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)
6. 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)
7. 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)

   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)

   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)

   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)

   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)

   "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)

   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)

8. 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)
9. 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)
10. 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)

    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)

    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. Swarm^Talk 05:35, 23 August 2010 (UTC)

11. 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)
12. 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)
13. 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)
14. 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)
15. 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)

    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)

    Speak for yourself and stop assuming. —Jeremy ^{(v^_^v PC/SP is a show-trial!)} 00:09, 24 August 2010 (UTC)

16. 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)

    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)

    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)

    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)

    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)

17. Restart the poll with a preferential voting system (see talk). Sceptre ^(talk) 22:38, 23 August 2010 (UTC)
18. 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)
19. 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)
20. 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)

21. Keep the poll, on the basis of the following compromise: It goes without saying that if forced to choose between options 2, 3 and 4, those people the vast majority of those people who hate pending changes would all vote for 2, the most limited deployment of the feature. So when (as is probably going to happen) we have to choose between 2, 3 and 4, it should be done by first including votes for 1 in the total for 2. As 2 is the status quo, it will be selected by default unless its total level of support is significantly exceeded by 3+4 (the meaning of "significantly" being at the discretion of the developers). – Smyth\^talk 12:28, 24 August 2010 (UTC)

    At the time of your comment, there are roughly 30 option 2's (although some include 2 or 3, or 2, 3, or 4). With a little over 100 closes, and 190 total keeps, that would leave 130 support 2 vs. 160 support 3 or 4. I think that is the maximum way to phrase the situation in support of option 2. Other rationales make the case more strongly for option 3, for example, the fact that anyone who prefers the status quo over a close can currently just vote for it. Ocaasi (talk) 12:51, 24 August 2010 (UTC)