Jump to content

Wikipedia:Pending changes/Straw poll

Add links
From Wikipedia, the free encyclopedia
< Wikipedia:Pending changes
This is an old revision of this page, as edited by Nave.notnilc (talk | contribs) at 14:29, 24 August 2010 (comment/vote). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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 BLP articles. 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)[reply]
  2. Support 1 - Keep the system open. Shenhemu (talk) 10:03, 24 August 2010 (UTC)[reply]
  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)[reply]
  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)[reply]
  5. Support 1 Is this really worth keeping? ~~ Hi878 (Come shout at me!) 00:09, 22 August 2010 (UTC)[reply]
  6. Support 1, discourages new editors from editing.Sumsum2010 · Talk · Contributions 00:22, 22 August 2010 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  10. Support 1 Slow with unclear and not followed standards.Cptnono (talk) 00:58, 22 August 2010 (UTC)[reply]
  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)[reply]
  12. Support 1 Bejinhan talks 03:03, 22 August 2010 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  19. Support 1. Unnecessary complication.Biophys (talk) 04:58, 22 August 2010 (UTC)[reply]
  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)[reply]
  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)[reply]
  22. Support 1. No real benefit for the creation of tons of busy work. Courcelles 05:40, 22 August 2010 (UTC)[reply]
  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)[reply]
  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)[reply]
    This is an interesting point, Casliber. So you're saying we should expand PC, on a trial basis, to all BLP's -- sort of like option 4 of this poll, except that after n number of months, PC will go away unless there is consensus for it to stay? That's a really reasonable thought and I'm sorry it's not getting discussed here. Andrew Gradman talk/WP:Hornbook 01:03, 23 August 2010 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  28. Support 1 Deters newcomers. Elitist. Richard75 (talk) 10:35, 22 August 2010 (UTC)[reply]
  29. Support 1. Discourages new users from editing. Adds unnecessary extra work for others. Offliner (talk) 11:04, 22 August 2010 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  33. Support 1 Goes against everything WP is about. Access Denied talk contribs editor review 15:11, 22 August 2010 (UTC)[reply]
  34. Support 1 Wikipedia is improved by its open edit policy, not by adding layers of bureaucracy. I, EnglishmanWouldst thou speak? • Handiwork 15:33, 22 August 2010 (UTC)[reply]
  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. EricLeb01 (Page | Talk) 15:38, 22 August 2010 (UTC)[reply]
  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)[reply]
  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)[reply]
  38. Support 1 – Kerαunoςcopia◁galaxies 17:01, 22 August 2010 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  42. Support 1 ῤerspeκὖlὖm in ænigmate ( talk ) 19:23, 22 August 2010 (UTC)[reply]
  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)[reply]
  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)[reply]
  45. Support 1. Deters newcommers. Limited effectiveness against vandals. -FASTILY (TALK) 20:19, 22 August 2010 (UTC)[reply]
  46. Support 1 per all above. All Hallow's Wraith (talk) 20:27, 22 August 2010 (UTC)[reply]
  47. Support 1. Too complex, little real benefit. --Sable232 (talk) 21:01, 22 August 2010 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  58. Support 1 More went wrong than went right. Jsayre64 (talk) 00:33, 24 August 2010 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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. OhanaUnitedTalk page 03:50, 23 August 2010 (UTC)[reply]
  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)[reply]
  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)[reply]
  71. Support 1 per the reasons I discussed here. --William S. Saturn (talk) 05:18, 23 August 2010 (UTC)[reply]
  72. Support 1: Complicates things unneccessarily with the interface and takes up more time.--Forty twothe answer? 06:57, 23 August 2010 (UTC)[reply]
  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)[reply]
  74. Support 1 As per all of the above. Qwrk (talk) 07:43, 23 August 2010 (UTC)[reply]
  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)[reply]
  76. Support 1 costs > benefits

Jebus989★ 08:52, 23 August 2010 (UTC)[reply]

  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  7. Support 1 would be very off-putting to new users 82UK (talk) 15:09, 23 August 2010 (UTC)[reply]
  8. Support 1 - not practical. Adrian (talk) 15:11, 23 August 2010 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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-. Torque3000Talk 18:41, 23 August 2010 (UTC)[reply]
  14. Too complicated and cumbersome; the downsides outhweigh the benefits.  Sandstein  19:08, 23 August 2010 (UTC)[reply]
  15. Found no advantages whatsoever using this system, certainly no better than semi-protection. BigDom 19:31, 23 August 2010 (UTC)[reply]
  16. Support 1 - Unnecessarily complex. I am sure a better approach can be found. (RT) (talk) 20:26, 23 August 2010 (UTC)[reply]
  17. Support 1 - Get rid of it. Groundsquirrel13 (talk) 21:04, 23 August 2010 (UTC)[reply]
  18. Support 1 - Does not encourage new users. --Traveler100 (talk) 21:36, 23 August 2010 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  26. Support 1 Pending changes should be banished to Room 101. Jared Preston (talk) 09:25, 24 August 2010 (UTC)[reply]
  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)[reply]
  28. Gurch (talk) 11:19, 24 August 2010 (UTC)[reply]
  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)[reply]
  30. Support 1 Bureaucratic, unnecessary and elitist. Dalliance (talk) 11:50, 24 August 2010 (UTC)[reply]
  31. Support 1 add more semi protection and the same affect will happen except the confusion! mabdul 13:16, 24 August 2010 (UTC)[reply]
  32. Support 1 Complicated, obtuse, not really needed. Nave.notnilc (talk) 14:29, 24 August 2010 (UTC)[reply]

Keep: options 2, 3, or 4

  1. Support 2 The Thing // Talk // Contribs 23:13, 21 August 2010 (UTC)[reply]
  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)[reply]
  3. Support 3 - if this option is successful, hopefully after improvements, we can then expand further. PhilKnight (talk) 23:28, 21 August 2010 (UTC)[reply]
  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)[reply]
  5. Support 3 Gobonobo T C 23:34, 21 August 2010 (UTC)[reply]
  6. Support 3--Wetman (talk) 23:35, 21 August 2010 (UTC)[reply]
  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)[reply]
  9. Support 3 and definitely also shift it from high traffic to lower traffic articles. -84user (talk) 00:00, 22 August 2010 (UTC)[reply]
  10. Support 3 My76Strat 00:03, 22 August 2010 (UTC)[reply]
  11. Support 3 Ғяіᴅaз'§Đоом | Spare your time? 00:31, 22 August 2010 (UTC)[reply]
  12. Support 3 (at least) Definitely worth keeping. A great tool, though some extra time is needed to find out what exactly it is best for. In my mind, low traffic articles with BLP concerns (ie not just the BLP articles themselves) are likely the most likely to be a fruitful place for use. --Slp1 (talk) 00:21, 22 August 2010 (UTC)[reply]
  13. Support 3, though I hope the suggested improvements will be made before expansion of PC material. —Arsonal (talk + contribs)— 00:17, 22 August 2010 (UTC)[reply]
  14. Support 2 as a minimum - no objection to 3 or 4 being trialled, tool was useful. Off2riorob (talk) 00:34, 22 August 2010 (UTC)[reply]
  15. Support 3 - It works - not that confusing, became faster in time, does not seem to discourage new editors, and deterred vandalism on the pages I saw it used on, compared with vandal activity in the past foew months on those pages. Certainly needs some improvements, as discussed elsewhere. - BilCat (talk) 00:36, 22 August 2010 (UTC)[reply]
  16. Support 3 but where do these vote comment guidelines come from? --Mkativerata (talk) 00:39, 22 August 2010 (UTC)[reply]
  17. Support 4 , but seriously consider usability. --Cyclopiatalk 01:12, 22 August 2010 (UTC)[reply]
  18. Support 3 pending changes is a useful tool, but discretion is needed for where it's applied. Nick-D (talk) 01:13, 22 August 2010 (UTC)[reply]
  19. Support 3 Pending changes has a lot of potential to help maintain the quality of Wikipedia. Tyrol5 [Talk] 01:19, 22 August 2010 (UTC)[reply]
  20. Very, very weakly support 2 - As per my comment at the other page, this needs some serious reform before being enabled. However, I would not like to see it be closed, as that is a net negative. However, mass expansion is also a net negative. (There needs to be an Option 5: Other) (X! · talk)  · @122  ·  01:55, 22 August 2010 (UTC)[reply]
  21. Support 3 I admit that I only had, I believe, one page on my watch list that had been semi'd for a while turned into PC. Yes it got vandalized, but it wasn't really THAT much, and definitely slowed down a bit after some time. So long as the the number is left as an amount reasonable to manage -- that is, any semblance of "this'll just cause more more where other is needed blah blah blah so what if people are volunteers " then it's certainly the best way to go. Option 4 might be ok too, so long as that's not the ONLY use for it (that is, all BLP *plus* anything else deemed warranted). ♫ Melodia Chaconne ♫ (talk) 02:07, 22 August 2010 (UTC)[reply]
  22. Support 3. This system was perhaps being applied too liberally to areas that should have had a semi-protection, but its use as a tool for cases that should not be open, but still fundamentally follow the principals as a wiki, while still reducing vandalism under guardianship is favourable. Mkdwtalk 02:08, 22 August 2010 (UTC)[reply]
  23. Support 2 - and revisit again. --Threeafterthree (talk) 02:53, 22 August 2010 (UTC)[reply]
  24. Support 2 An effective tool on low traffic pages, though worthless on high traffic, keep PC-2 Ronk01 talk, Editor Review 02:57, 22 August 2010 (UTC)[reply]
  25. Support 4 followed by 3, followed by 2 Nil Einne (talk) 15:02, 23 August 2010 (UTC) (added additional supports since there is some suggestion on the talk page I need to spell it out)[reply]
  26. Support 3  ℳono  03:54, 22 August 2010 (UTC)[reply]
  27. Support 3 with emphasis on improvements. DocOfSoc (talk) 04:06, 22 August 2010 (UTC)[reply]
  28. Support 3 ErikHaugen (talk) 04:34, 22 August 2010 (UTC)[reply]
    Although I wish there was an option for focusing on replacing semiprot rather than "low traffic blp". ErikHaugen (talk) 16:49, 23 August 2010 (UTC)[reply]
  29. Support 3 Some good and valid points made by those who support option 1 - however, I believe this tool is still positively effective when used on low-traffic pages. ~SuperHamster Talk Contribs 04:57, 22 August 2010 (UTC)[reply]
  30. Support 2 (edit conflict) If you know how to use it, is useful. TbhotchTalk C. 04:58, 22 August 2010 (UTC)[reply]
  31. Support 3. From personal experience, I accept about 1/3 of the edits and reject 2/3 of the edits. Without pending changes, that 1/3 (still a significant amount) would be prevented by semi-protection. -- King of ♥ ♦ ♣ ♠ 05:01, 22 August 2010 (UTC)[reply]
  32. Support 3--Cannibaloki 05:09, 22 August 2010 (UTC)[reply]
  33. Support 3 After seeing how it works from an anonymous editor's view, and knowing how much 1.4k is, I support keeping the pending changes tool and expanding how much an anonymous editor can add onto an article. --K. Annoyomous (talk) 05:11, 22 August 2010 (UTC)[reply]
  34. Support 3 From what I have seen, this is helping the project. --Ckatzchatspy 05:13, 22 August 2010 (UTC)[reply]
  35. Support 3 - Though I don't like the attitude that seems to have developed which wants reviewers to decide if it's a "good" edit. That belongs in a talk page, not a reviewing hierarchy. I believe in the official guideline, which is to curb blatant vandalism. This protects the pages and allows edits to be viewable quickly.‡ MAHEWA ‡ • talk 05:14, 22 August 2010 (UTC)[reply]
    Support 2 - I want to see this work, but the fact of the matter is that there are too many issues with the current implementation to justify expansion just yet. --WFC-- 05:25, 22 August 2010 (UTC) Moving to scrap the poll. Please do not remove this. --WFC-- 22:05, 22 August 2010 (UTC)[reply]
  36. Support 4 —Where's '5'? Future is thataway→ Cheers, Jack Merridew 05:31, 22 August 2010 (UTC)[reply]
  37. Support 3 or 4 --Diannaa (Talk) 05:36, 22 August 2010 (UTC)[reply]
  38. Support 3 or 4 BLPs and low-traffic are the article types where this makes absolute sense (unless RecentUnwatchedChanges or similar gets implemented). --Cybercobra (talk) 06:20, 22 August 2010 (UTC)[reply]
  39. Support 2 or 3 - I think the idea is sound and needs to be continued. The how of it needs to be tweaked, but we need to get this confirmed to continue before we get too worried about the tweaks.  Afaber012  (talk)  06:40, 22 August 2010 (UTC)[reply]
  40. Support 2, for ultimately being a net positive. -- Ϫ 06:46, 22 August 2010 (UTC)[reply]
  41. Support 4 sorta I think rollout to all low traffic BLPs is an excellent use of the feature, especially with some of the discussed improvements, but high traffic articles (whatever the type) aren't a good fit. I also think we should leave this in control of humans unless we can agree on a unambiguous metric for "low traffic". Shell babelfish 06:49, 22 August 2010 (UTC)[reply]
  42. Support 3 - This system is a net positive for the project and should be slowly expanded.--Sodabottle (talk) 07:13, 22 August 2010 (UTC)[reply]
  43. Support 3 or 4 - This has been an astounding success. It should be rolled to BLP's on a large scale. Just, you know, please tweak the little flaws. Andrew Gradman talk/WP:Hornbook 07:17, 22 August 2010 (UTC)[reply]
  44. Support 3 keeping to low-traffic articles. My feeling is that it doesn't work well on high-traffic articles, and will put off new editors. -- PhantomSteve/talk|contribs\ 07:20, 22 August 2010 (UTC)[reply]
  45. Support 3 — Glenn L (talk) 07:26, 22 August 2010 (UTC)[reply]
  46. Support 3 - useful alternative to either semi-protection or no protection in some cases. -- zzuuzz (talk) 07:30, 22 August 2010 (UTC)[reply]
  47. Support 3 or 4 Dodoïste (talk) 07:47, 22 August 2010 (UTC)[reply]
  48. Support 3. Revision/clarification of guidelines for reviewers might be in order, though. Choyoołʼįįhí:Seb az86556 > haneʼ 08:04, 22 August 2010 (UTC)[reply]
  49. Support 3. Would consider support 4 once wrinkles are ironed out. TFOWR 08:06, 22 August 2010 (UTC)[reply]
  50. Support 3 or 4 10k is a bit low. ϢereSpielChequers 08:10, 22 August 2010 (UTC)[reply]
  51. Support 1 or 4 - we do a proper trial scaled up for what it was supposed to be for (BLPs), or we drop it, I am not a fan of sitting somewhere in the middle. I favour this slightly more than dropping altogether. Casliber (talk · contribs) 08:19, 22 August 2010 (UTC)[reply]
  52. Support 3 I like this idea but it needs expansion if it is going to stay. Iamcool234 08:28, 22 August 2010 (UTC)[reply]
  53. Support 2 or 3 assuming the interface can continue to improve. -- Eraserhead1 <talk> 08:42, 22 August 2010 (UTC)[reply]
  54. Support 4, 3, or 2 (in order of preference).   — Jeff G.  ツ 08:45, 22 August 2010 (UTC)[reply]
  55. Support 4, and therefore (obviously) 3 and 2 as well. DVdm (talk) 08:50, 22 August 2010 (UTC)[reply]
  56. Support 3 or 2(in order of preference). Still could use some work before 4-- WORMMЯOW  09:25, 22 August 2010 (UTC)[reply]
  57. Support 3. I don't think it's needed for all BLPs. Svick (talk) 09:52, 22 August 2010 (UTC)[reply]
  58. Support 3 Misarxist (talk) 09:54, 22 August 2010 (UTC)[reply]
  59. Support 3. I think it needs to be improved before being expanded on to all BLPs.--EchetusXe 09:55, 22 August 2010 (UTC)[reply]
  60. Support 3 Still needs some improvements. Theleftorium (talk) 10:00, 22 August 2010 (UTC)[reply]
  61. Support 2 or 3, when used in the right circumstances it's a very valid alternative to semi-protection. We simply need to strike the correct balance of using it where it's advantageous without overdoing it. ~ mazca talk 10:07, 22 August 2010 (UTC)[reply]
  62. Support 4 --Ziko (talk) 10:31, 22 August 2010 (UTC)[reply]
  63. Support 2, oppose 4 - pending changes is an extra tool in the fight against vandalism; as such I support it continual usage. I do however oppose any form of automatic protection: this is still supposed to be the encyclopedia that everyone can edit, and protection should only be applied when clearly needed. Rami R 10:46, 22 August 2010 (UTC)[reply]
  64. Support 3 Schapel (talk) 11:17, 22 August 2010 (UTC)[reply]
  65. Support 3: one of the best ideas on Wikipedia since sliced bread. How can you beat having a system in which, to readers, most vandalism is never seen? I like it, and see no real problems. |Finalius|T|S|C 12:04, 22 August 2010 (UTC)[reply]
  66. Support 3 - for whatever reason, it seems, (subjectively), to have reduced vandalism attempts on articles subject to the process.  Velella  Velella Talk   12:14, 22 August 2010 (UTC)[reply]
  67. Support 3 - maybe give editors with review permissions the right to protect pages with pending changes if they discover the need for it? Tomd2712 | Tell me something? 12:16, 22 August 2010 (UTC)[reply]
  68. Support 3. The trial succeeded in lowering visible BLP vandalism and the sky did not fall in. Sam Blacketer (talk) 12:18, 22 August 2010 (UTC)[reply]
  69. Support 3 Willking1979 (talk) 12:20, 22 August 2010 (UTC)[reply]
  70. Support 3 Needs work, but an asset that should continue to be deployed on our more "at-risk" articles of all stripes. Der Wohltemperierte Fuchs(talk) 12:23, 22 August 2010 (UTC)[reply]
  71. Support 3 Graham Colm (talk) 12:25, 22 August 2010 (UTC)[reply]
  72. Support Prefer 3/4, support 2 if alternative is cutting it off. Xymmax So let it be written So let it be done 12:33, 22 August 2010 (UTC)[reply]
  73. 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)[reply]
  74. Support 2 It worked with preventing BLP vandalism and some vandalism on other articles. GB86 13:21, 22 August 2010 (UTC)[reply]
  75. Support 3 - there's no real basis for an artificial cap at 2k, and we're unlikely to drastically exceed it in practice anyway, but having the flexibility is better than not. I am happy that there are few significant downsides to continuing the implementation of this system, and significant benefits to be gained. (If not 3, then by preference 2, then 4.) Shimgray | talk | 13:22, 22 August 2010 (UTC)[reply]
  76. Support 3 or 4. - Dank (push to talk) 13:25, 22 August 2010 (UTC)[reply]
  77. Support 3. But making improvements is important too—I might support 4 then. Not a substitute for semi-protection—it's a substitute for no protection on some pages. --Tryptofish (talk) 13:39, 22 August 2010 (UTC)[reply]
  78. Support 3 or 4. Salvio Let's talk 'bout it! 13:44, 22 August 2010 (UTC)[reply]
  79. Support 3--intelati 13:51, 22 August 2010 (UTC)[reply]
  80. Support 4 or 3, Spellcast (talk) 13:57, 22 August 2010 (UTC)[reply]
  81. Support 4. --Funandtrvl (talk) 14:07, 22 August 2010 (UTC)[reply]
  82. Weak support 3. I played no active part in the trial so don't know for sure, but from what I can tell this seems to have worked relatively well. Alzarian16 (talk) 14:08, 22 August 2010 (UTC)[reply]
  83. Support 4, 3, 2 in that order. NW (Talk) 14:19, 22 August 2010 (UTC)[reply]
  84. Support 3. ~NSD (✉ • ✐) 14:27, 22 August 2010 (UTC)[reply]
  85. Support 4. The Raptor You rang?/My mistakes; I mean, er, contributions 14:28, 22 August 2010 (UTC)[reply]
  86. Support 3 Idea is sensible since so many edits come from IPs which are constructive, and because some people don't like to create accounts, often these IPs end up not being able to positively edit a page which is semi-protected. This new system seems to get around this problem and I imagine also tends to prevent vandalised results coming through in search engines such as Google. It does need some improvement though - like what is the unaccept button all about? Jay-Sebastos (talk) 14:52, 22 August 2010 (UTC)[reply]
  87. Support 3 and 4, weak support 2. I think this would definitely be useful for all BLPs. - EdoDodo talk 15:10, 22 August 2010 (UTC)[reply]
  88. Support 3 or 4 I'd prefer to see 3. Captain panda 15:34, 22 August 2010 (UTC)[reply]
  89. Support 3 I think it should continue with expansion. --Nascar1996 Contributions / Guestbook 15:58, 22 August 2010 (UTC)[reply]
  90. Support 3 Make sure reviewing process is a little improved code wise. Allmightyduck  What did I do wrong? 16:15, 22 August 2010 (UTC)[reply]
  91. Support 3 or 4 TheGrappler (talk) 16:49, 22 August 2010 (UTC) [Clearly the current arrangement is imperfect; technical improvements are desirable, as would be stronger consensus on how much verification is required of edits before they are accepted - merely checking it's not vandalism is insufficient in my opinion - but neither of these improvements will be delivered by closing the trial down. In an awful sense, the more it gets used, and therefore the more annoying and apparent its problems become, the faster they'll get fixed! Yet its benefits are only likely to become really visible upon large scale implementation - once notable people start complaining less frequently that their biographies have been wrecked, or readers discover that they're less likely than before to stumble on complete dross. We'll hardly notice the fruits of that if it's only applied to a few pages, but larger scale roll-out should make a big difference. It doesn't seem to have cost a catastrophic amount of growth so far, and again we will likely only detect threatened editor drop-off if we expand; then we'd be in a better position (if necessary) to weigh up the benefits of improved accuracy versus reduced editorial resources. This has mostly been a technical trial, not a large-scale, long-term effect trial, and the "it puts new editors off" or "will cause a collapse in the encyclopedia" arguments lack quantitative evidence - as do the "stuff's got better" arguments here in the support section. Since the trial hasn't reached a state where it can give us empirical insight into the long-term effects on article quality and editor turnover, then it hasn't gone on long enough and has probably been used on too few articles to make a real difference. So scale the trial up, continue it, and if empirical evidence is negative 6 months later, we can shut it then. Declaring flagged revisions to be a success or failure at this point is extremely premature. TheGrappler (talk) 17:15, 22 August 2010 (UTC)][reply]
  92. Support 3 – My rationale is in Wikipedia:Pending changes/Closure. – Smyth\talk 16:53, 22 August 2010 (UTC)[reply]
  93. Support 3 or 4 - This is a good tool for dealing with our BLP problem on lightly trafficked articles, which is most of them.--Chaser (talk) 16:55, 22 August 2010 (UTC)[reply]
  94. Support 4 and 3 My strong preferance is for number 4, however I would support number 3 as well if there is not enough community concensus for pending changes to be applied to all BLPs. --Jezebel'sPonyoshhh 16:58, 22 August 2010 (UTC)[reply]
  95. (edit conflict)(edit conflict)Support 2, 3 or 4. But I would support 3 the most. —I-20the highway 17:08, 22 August 2010 (UTC)[reply]
  96. Support 2, 3, and 4, favoring 3 the most. John Carter (talk) 17:16, 22 August 2010 (UTC)[reply]
  97. Support 2 While pending changes is of some benefit, it should not be rolled out any further until the performance issues associated reviewing changes in large articles (like World War I, where I have found it almost impossible to accept or reject edits) are addressed.Nigel Ish (talk) 17:21, 22 August 2010 (UTC)[reply]
  98. Support 2, 3, and 4, favoring 3 the most. Oreo Priest talk 17:23, 22 August 2010 (UTC)[reply]
  99. Support 3 While Pending changes is a benefit to rollback to not have to be used as much. I think it should be moved out on more articles. This feature can help others edit pages like Full Protected pages and see their edits appear quicker than normal. Joe Gazz84 (user)•(talk)•(contribs) 17:29, 22 August 2010 (UTC)[reply]
  100. Support 2. I have two articles on my watchlist that get vandalized on a regular basis. Thank God for other editors who also watch them. Thomas R. Fasulo (talk) 17:31, 22 August 2010 (UTC)[reply]
  101. Support 4 or 3 1exec1 (talk) 17:52, 22 August 2010 (UTC)[reply]
  102. Support 3 The way it's set up now, a user has to do pretty much as much work as if the page were just semi-protected normally, or even not protected at all; the system needs to be set up so it auto-reverts 'unaccepted' edits and it needs to be set so you can unaccept edits. HalfShadow 17:56, 22 August 2010 (UTC)[reply]
  103. Support 2 Proposal and technology need work. Particular concern is not discouraing new editors. Lfstevens (talk) 18:02, 22 August 2010 (UTC)[reply]
  104. Support 2 Discouraging to anons, but much less so than its awful alternative, indefinite semiprotection. But for this reason, should be upon request and as alternative to semiprotection only. --Bsherr (talk) 18:48, 22 August 2010 (UTC)[reply]
  105. Support 3 – It isn't being used enough, and is working pretty well. —MC10 (T•C•GB•L) 18:51, 22 August 2010 (UTC)[reply]
  106. Support 3 although 2 or 4 are fine as well. Wknight94 talk 18:56, 22 August 2010 (UTC)[reply]
  107. Support 3 and 4. The tool, as it is, works. It doesn't work as well as it should, but that's because of holes in the documentation. HalfShadow several votes above has the right idea too. Level 1, however, should not be seen as exclusive to semi-protection; the heiarchy of protection would go free -> PC1 -> Semi -> PC2 -> Full. Sceptre (talk) 20:01, 22 August 2010 (UTC)[reply]
  108. Support 4. It better reflects what Wikipedia is meant to be about than semi-protection. There should be no artificially set limit on the number of pages which are included. There should be a list of reasons why an article should be placed under pending changes protection, with articles being assessed on a case by case basis. — Blue-Haired Lawyer t 20:10, 22 August 2010 (UTC)[reply]
  109. Support 3 most, but also support 2 and 4. --JaGatalk 20:14, 22 August 2010 (UTC)[reply]
  110. Support 3 and 4. It's a useful tool to have around, and is a much better fit to our philosophy than semi/full protection is (although there are cases where those protection levels are still needed). It is rare that there is a backlog of edits needing review. It's a considerable improvement to suffering from libel vandalism to BLPs - both for the article subjects, and also for us (the press love stories about vandalism on Wikipedia a bit too much...). Mike Peel (talk) 20:20, 22 August 2010 (UTC)[reply]
  111. Support 2 and 3 might work as well. The tool works, it just needs to be fixed up. Nolelover (talk) 20:28, 22 August 2010 (UTC)[reply]
  112. Support 2 or 3 I think the tool is very useful, but it could use a little revising, policy change, etc. Also, when reviewing edits, there should be a "Decline" or "Reject" button in addition to the "Accept" and "Unaccept" buttons to make it easier to undo unconstructive revisions. --- cymru lass (hit me up)⁄(background check) 20:41, 22 August 2010 (UTC)[reply]
  113. Support 3 We certainly can expand this to cover more articles and handle it effectively, but it should still be limited so it doesn't become difficult to deal with. SwarmTalk 20:52, 22 August 2010 (UTC)[reply]
  114. Support 3 reduces vandalism and improves the readers' experience as well. --Elekhh (talk) 20:54, 22 August 2010 (UTC)[reply]
  115. Support 3 - Has some merit, but ultimately will have limited usefulness. May need to be scrapped altogether, but it deserves more time. Cresix (talk) 21:12, 22 August 2010 (UTC)[reply]
  116. Support 3ish — Limit to those articles that would otherwise be semied. That way, we are getting the benefits without reducing the number of articles that anons can edit. —Arctic Gnome (talk • contribs) 21:14, 22 August 2010 (UTC)[reply]
  117. Support 3 and weak support 4 Pending changes should be expanded as an equal alternative to semi-protection or a trial period before unprotecting indefinitely protected articles. The bottleneck at 2000 seems arbitrary, especially considering the success PC has enjoyed. Intelligentsium 21:21, 22 August 2010 (UTC)[reply]
  118. Support 3. The trial seems to have for the most part shown that this can work well. Plus it's badly needed, and the status quo is simply not good enough. AGK 21:38, 22 August 2010 (UTC)[reply]
  119. Support 3. A review of the closure discussion revealed consistent support for making pending changes faster, fixing the accept/unaccept interface, clarifying policy regarding when to accept edits, and emphasizing use on lower-traffic/lower watched pages and BLPs rather than as a substitute for semi-protection, especially on high traffic pages which receive a lot of vandalism or are the target of sockpuppets or content disputes. This poll is only ground for an extension of the trial, not an expansion of the feature to the entire encyclopedia. The trial is designed to further refine and improve the feature and tailor its use to where it is not problematic and actually of benefit. It that turns out to be nowhere, so be it, but better not to toss a limited trial when things are still being figured out. Ocaasi (talk) 21:46, 22 August 2010 (UTC)[reply]
  120. Support 3 and 4. PC works quite well and is a much better alternative than semi/full protection. It simply better reflects what Wikipedia is all about. Laurinavicius (talk) 21:51, 22 August 2010 (UTC)[reply]
  121. Support 3 It opens up some articles back to edits by IP addresses. As a goal of encouraging new editors to come on board, I think this is a good compromise that will work well for certain articles. —Ute in DC (talk) 22:02, 22 August 2010 (UTC)[reply]
  122. Support 2 or 3, and use reviewing to supplement semi-protection. Articles that attract a lot of vandalism by IPs should be protected by the system, rather than reviewers. PKT(alk) 22:33, 22 August 2010 (UTC)[reply]
  123. Support 2 When some of the requests about making who did what easier to access and more transparent then I would support 3 or 4, but for now 2 seems good. §hepTalk 22:53, 22 August 2010 (UTC)[reply]
  124. Support 3 and 4 Mootros (talk) 22:55, 22 August 2010 (UTC)[reply]
  125. Support 3 and/or 4 Moving backwards towards anonymous, at-will defamation of living people is simply not an option. Jclemens (talk) 23:10, 22 August 2010 (UTC)[reply]
  126. Support 2 Wikiscient (talk) 23:32, 22 August 2010 (UTC)[reply]
  127. Support 3 System cannot be properly assessed until the number of articles is expanded. Best to do this gradually or in phases, to allow iterative improvement. Richardguk (talk) 23:41, 22 August 2010 (UTC)[reply]
  128. Support 3 and 4. Ironholds (talk) 00:10, 23 August 2010 (UTC)[reply]
  129. Support 3 gradual expansion will let the system evolve as needed. WuhWuzDat 00:20, 23 August 2010 (UTC)[reply]
  130. Support 3. Pending changes and semiprotection are different tools. Expand pending changes where it is helpful, but do not remove semiprotection where it is needed. Geometry guy 01:04, 23 August 2010 (UTC)[reply]
  131. Support 3 4 is a little to much and this helps with removing some of the sper/per requests. -- DQ (t) (e) 01:08, 23 August 2010 (UTC)[reply]
  132. Support 3. DrNegative (talk) 01:10, 23 August 2010 (UTC)[reply]
  133. Support 3 - Agree with PhantomSteve, seems to work better with lower traffic articles. Mlpearc powwow 01:18, 23 August 2010 (UTC)[reply]
  134. Support 4, or 2/3. Needs polishing, but otherwise a useful tool. vvvt 02:08, 23 August 2010 (UTC)[reply]
  135. Support 3- Gradual change in protection is good. It's for the best. --The Wing Dude, Musical Extraordinaire (talk) 02:10, 23 August 2010 (UTC)[reply]
  136. Support 3 or 4 mgiganteus1 (talk) 02:13, 23 August 2010 (UTC)[reply]
  137. Support 2 Openskye (talk) 02:14, 23 August 2010 (UTC)[reply]
  138. Support 3 Needs work but otherwise a useful tool.--Steam Iron 02:26, 23 August 2010 (UTC)[reply]
  139. Support 2 or 3 Well, I don't know if I really support it, but I think we need to spend more time evaluating it before we can come to any sort of conclusion. I'd like to see this expanded to major BLP articles (say, start class or better) if we keep it around, and to articles on medical or scientific subjects, or to articles where it is requested. Let's see how that works 6 months or so out, and then come to some sort of consensus. superlusertc 2010 August 23, 02:29 (UTC)
  140. Support 4 Maddie talk 02:41, 23 August 2010 (UTC)[reply]
  141. Support 4 I see enough random vandalism on BLP articles I watch that I think rollout to BLP articles is a good idea. I do agree that usability of the tool needs more work, especially for users who are also using Twinkle. -- WeijiBaikeBianji (talk) 02:52, 23 August 2010 (UTC)[reply]
  142. Support 3 We have to do something to avoid bad press generated by Seigenthaler type incidents, and this works better than semi-protection. Most bad edits come from anons anyway, so we might as well flag with them and review them so they never make it into articles.--Bkwillwm (talk) 03:17, 23 August 2010 (UTC)[reply]
  143. Support 3 Less hostile to anons than protection, and probably at least as effective at catching vandalism attempts provided admins and reviewers exercise their rights with due thought and care. 76.211.5.153 (talk) 03:36, 23 August 2010 (UTC)[reply]
  144. Support 3 - Provided there is improved policy and guidance for reviewers, and efforts are made to ensure that the vast majority of pages with pending changes are on the watchlists of active editors, I feel this implemementation would be a net positive for the project.  -- Lear's Fool 03:38, 23 August 2010 (UTC)[reply]
  145. Support 4 with 3 as a 2nd choice and 2 as a 3rd choice. Rlendog (talk) 03:44, 23 August 2010 (UTC)[reply]
  146. Support 3 provided that the performance issues are addressed, the accept/unaccept interface is fixed, and the policy about when to accept edits is clarified. —Bruce1eetalk 07:17, 23 August 2010 (UTC)[reply]
  147. Support 2 --Saukkomies talk 07:38, 23 August 2010 (UTC)[reply]
  148. Support 3 - per successful trial, but issues should be fixed before widespread use. AJRG (talk) 09:25, 23 August 2010 (UTC)[reply]
  149. Support 3, and reconsider going for 4 in the long run. – sgeureka t•c 09:43, 23 August 2010 (UTC)[reply]
  150. Support 4 (or a non-bot versiono of 4; i.e. at least option 3). True, some articles don't benefit by this, and it must be tweaked, but I generally found this useful and gives good possibilities to keep an eye on the content of articles. Noting that quite a number of BLP's should be deleted as unreferenced/not-notable, this gives a good view on where the problems lie. Preferably: have a look at all of them, clear out the rubbish, and either delete, or protect using Pending changes. Bot option: if the last editor is a reviewer, autoreview that version, otherwise autoreview the last revid that is by a reviewer, or leave it unreviewed; will give some work to review them at that time (but there are enough reviewers out there, and I think this is a good way of checking which BLP's certainly need to be looked at; the others will come in due time). --Dirk Beetstra T C 09:56, 23 August 2010 (UTC)[reply]
  151. Support 3 and would also Support 4, overall it is still a work in progress but a net plus. Codf1977 (talk) 10:16, 23 August 2010 (UTC)[reply]
  152. Support 2 This has a great potential, but currently needs improvement before we make it a site-wide nightmare. —Charles Edward (Talk | Contribs) 13:06, 23 August 2010 (UTC)[reply]
  153. Support 3, with possible extension to 4 in the fullness of time. Clearly there are some issues to be fixed, but they're quite well defined in the discussion and most can be addressed. I think we need to develop it and see it in use for a longer time. -- Boing! said Zebedee (talk) 13:44, 23 August 2010 (UTC)[reply]
  154. Support 3 would be my preference, with possible extension to 4 as noted above.--SarekOfVulcan (talk) 14:16, 23 August 2010 (UTC)[reply]
  155. Support 2, with the caveat that reviewing policy must be clarified for consistency (see my comment on WP:Pending changes/Closure#Arbitrary Break 3 for further explanation). If reviewing is fully automatic as I describe there, I might support 3 or 4. PleaseStand (talk) 14:30, 23 August 2010 (UTC)[reply]
  156. Support 4 . --CutOffTies (talk) 15:38, 23 August 2010 (UTC)[reply]
  157. Support 3 - I have faith that the interface and guidelines will be sorted out over time, and then heartily support it's extension to all BLP articles as well as others as needed. SeaphotoTalk 16:18, 23 August 2010 (UTC)[reply]
  158. Support 3 Trial seems has been going alright. Expand number of articles and keep improving things. -fnlayson (talk) 16:23, 23 August 2010 (UTC)[reply]
  159. Support 3 - and continue to improve and expand • Astynax talk 16:38, 23 August 2010 (UTC)[reply]
  160. Support 2 in the sense that this was the first version and should be iterated / improved but is not yet ready for primetime. Usability and probably guidelines should be improved, then a second "trial". Dhollm (talk) 16:44, 23 August 2010 (UTC)[reply]
  161. Support 3 - It's a great addition, I'd like to see this continue, improve and expand. 28bytes (talk) 17:03, 23 August 2010 (UTC)[reply]
  162. Support 2. I haven't had a problem with it, although clearer information about how to make sure vandal edits aren't accepted would be useful. Daniel Case (talk) 17:18, 23 August 2010 (UTC)[reply]
  163. Support 3. The recent trial left many open questions. Needs further testing with an expanded scope. --Stepheng3 (talk) 17:41, 23 August 2010 (UTC)[reply]
  164. Support 3. Low traffic pages and BLP pages are extremely vulnerable to vandalism, because of hthe way our patrol is organized. If real-time checking trough Huggle doesn't catch the vandalism, it is likely to stay unless someone manually intervenes by reading article's (And on low-traffic pages that can be a LONG time). However, this system may in no way be abused for content control. Denying revisions should only be done in clear cases such as vandalism, copyright violations and content that clearly violates BLP - reviewers who repeatedly show bad judgment should lose their privilege quickly, and clear cases of content control or bad faith should be met with blocks if required. Excirial (Contact me,Contribs) 18:20, 23 August 2010 (UTC)[reply]
  165. Support 3. While I don't love it, I believe it should be expanded to include all FAs plus what is already there. Us441(talk) (contribs) 18:24, 23 August 2010 (UTC)[reply]
  166. Support any, most preferably 3. Very good system. Stifle (talk) 18:50, 23 August 2010 (UTC)[reply]
  167. Support 3 – allen四names 19:00, 23 August 2010 (UTC)[reply]
  168. Support 3; willing to accept 2 or 4. WhatamIdoing (talk) 19:55, 23 August 2010 (UTC)[reply]
  169. Support 3. It's not perfect, but it's closer to the spirit of the project than what we have now. I'd like to see continuing development on streamlining the interface and better explaining it to new users. Chromancer (talk) 21:33, 23 August 2010 (UTC)[reply]
  170. Support 3, particularly low traffic BLPs and other vulnerable low traffic articles for clear vandalism, cvios and BLP vios.Fainites barleyscribs 21:35, 23 August 2010 (UTC)[reply]
  171. Support 4; should be extended to all articles like in de.wp! →Alfie±Talk 22:14, 23 August 2010 (UTC)[reply]
  172. Support 3; Better alternative to page protection - which I think puts off newcomers more. This lets newcomers actually do the edit, rather than just ask someone else to do it. IainUK talk 22:21, 23 August 2010 (UTC)[reply]
  173. support 2; tuning the appropriate set of pages to use it for: perhaps current-events and lower-traffic pages. NealMcB (talk) 23:24, 23 August 2010 (UTC)[reply]
  174. Support 2 or 3 and all FAs per Second Law of Thermodynamics. HausTalk 00:08, 24 August 2010 (UTC)[reply]
  175. Support 3. We'll work it out over time. Barrylb (talk) 00:29, 24 August 2010 (UTC)[reply]
  176. Support 4 - This is a fantastic tool. I'd be willing to accept 2 or 3 as well, but regardless of what we decide to do, this needs to be continued. Burpelson AFB (talk) 01:20, 24 August 2010 (UTC)[reply]
  177. Support 4 - If the trial proved anything, it was that anonymous editors can contribute useful content to Wikipedia. The current de-facto policy of Semi-Protect any medium traffic article is a much worse choice. Furthermore the simple fact was that with the unreviewed status page, bad edits were reverted MUCH quicker in the trial than they would have otherwise. -- KelleyCook (talk) 02:28, 24 August 2010 (UTC)[reply]
  178. Support 3. Two months was too short to work out the kinks. Low traffic BLPs are a good place to extend its use as they are not a place we need new editors mucking about.--agr (talk) 03:16, 24 August 2010 (UTC)[reply]
  179. Support 3, later 4 - This is a much better alternative to semi-protect - it's already been proven successful when implemented in all articles in German Wikipedia. We have to keep this, and eventually expand to all articles. --Interchange88 ☢ 04:41, 24 August 2010 (UTC)[reply]
  180. Support 2, but keep talking about 4. Someguy1221 (talk) 05:20, 24 August 2010 (UTC)[reply]
  181. Support 2 or 3 (with preference to 3). However, I don't like the idea of an arbitrary limit. There's no reason we can't just slowly expand as long as its managable. 4 is a bad idea though. Applying a quality control mechanism by bot is just ridiculous. A human still needs to verify that the current version of the article is acceptable before enabling it. Mr.Z-man 05:58, 24 August 2010 (UTC)[reply]
  182. Support 3 and begin testing implementation of 4. First Light (talk) 06:06, 24 August 2010 (UTC)[reply]
  183. Support keeping it - We can discuss the next step if the consensus is to keep it. ~~ GB fan ~~ 06:27, 24 August 2010 (UTC)[reply]
  184. Support 3 or 4 - it's imperfect, but low-volume and BLP articles need some protection, and semi-protect is overkill. Rwessel (talk) 07:31, 24 August 2010 (UTC)[reply]
  185. Support 4, --  LYKANTROP  ✉ 08:11, 24 August 2010 (UTC)[reply]
  186. Keep ... option five... expand scope rapidly. It appears that some folks really like this thing. To me, it's meaningless but they say it's worth something. So, for the sake of public peace, let them play with their toy - or else... East of Borschov 08:42, 24 August 2010 (UTC)[reply]
  187. Support 3 or 4 A liberal alternative to protection, retaining Wikipedia's democratic philosophy whilst increasing integrity. The JPStalk to me 09:00, 24 August 2010 (UTC)[reply]
  188. Support 3. It seems to be doing a good job so far. Quantpole (talk) 10:59, 24 August 2010 (UTC)[reply]
  189. Support 3 Kneale (talk) 11:19, 24 August 2010 (UTC)[reply]
  190. Support 4, 3, 2, ordered in level of preference. Blurpeace 12:57, 24 August 2010 (UTC)[reply]
  191. Support 3 - Skysmith (talk) 13:01, 24 August 2010 (UTC)[reply]
  192. Support 3 or 4 - TexasAndroid (talk) 13:25, 24 August 2010 (UTC)[reply]
  193. Support 3 - Only have small issues in regards to the articles it was trialed on. ZooPro 13:33, 24 August 2010 (UTC)[reply]
  194. Support 3 or 4 ʘ alaney2k ʘ (talk) 13:47, 24 August 2010 (UTC)[reply]
  195. Support 3 or 4 --The Taerkasten (talk) 14:03, 24 August 2010 (UTC)[reply]
  196. Support 3. As a reviewer, I think that the system works great when applied on a small amount of articles. —Waterfox (talk) 14:29, 24 August 2010 (UTC)[reply]

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)[reply]
    See Help:Pending changes -- Jrtayloriv (talk) 17:08, 22 August 2010 (UTC)[reply]
  2. Support 2 but on the condition that the lag be improved as a minimum, and that anything otherwise and I would support 1. :| TelCoNaSpVe :| 18:45, 22 August 2010 (UTC)[reply]
  3. I support 4, but in my opinion the bar for becoming a reviewer should be raised a little bit.  Dr. Loosmark  14:01, 24 August 2010 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Pending_changes/Straw_poll&oldid=380716348"