Eisspeedway

Wikipedia:Pending changes/Straw poll: Difference between revisions

Content deleted Content added
Off2riorob (talk | contribs)
Off2riorob (talk | contribs)
Line 90: Line 90:
#'''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. --[[User:Slp1|Slp1]] ([[User talk:Slp1|talk]]) 00:21, 22 August 2010 (UTC)
#'''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. --[[User:Slp1|Slp1]] ([[User talk:Slp1|talk]]) 00:21, 22 August 2010 (UTC)
#'''Support 3''', though I hope the suggested improvements will be made before expansion of PC material. —<font face="Garamond" size="3">[[User:Arsonal|Arsonal]] (''[[User talk:Arsonal#top|talk]]'' + ''[[Special:Contributions/Arsonal|contribs]]'')</font>— 00:17, 22 August 2010 (UTC)
#'''Support 3''', though I hope the suggested improvements will be made before expansion of PC material. —<font face="Garamond" size="3">[[User:Arsonal|Arsonal]] (''[[User talk:Arsonal#top|talk]]'' + ''[[Special:Contributions/Arsonal|contribs]]'')</font>— 00:17, 22 August 2010 (UTC)
#'''Support 2'''as a minimum - no objection to 3 or 4 being trialled, tool was useful. [[User:Off2riorob|Off2riorob]] ([[User talk:Off2riorob|talk]]) 00:34, 22 August 2010 (UTC)
#'''Support 2''' as a minimum - no objection to 3 or 4 being trialled, tool was useful. [[User:Off2riorob|Off2riorob]] ([[User talk:Off2riorob|talk]]) 00:34, 22 August 2010 (UTC)
#'''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. - [[User:BilCat|BilCat]] ([[User talk:BilCat|talk]]) 00:36, 22 August 2010 (UTC)
#'''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. - [[User:BilCat|BilCat]] ([[User talk:BilCat|talk]]) 00:36, 22 August 2010 (UTC)
#'''Support 3''' but where do these vote comment guidelines come from? --[[User:Mkativerata|Mkativerata]] ([[User talk:Mkativerata|talk]]) 00:39, 22 August 2010 (UTC)
#'''Support 3''' but where do these vote comment guidelines come from? --[[User:Mkativerata|Mkativerata]] ([[User talk:Mkativerata|talk]]) 00:39, 22 August 2010 (UTC)

Revision as of 23:55, 22 August 2010

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 starting August 22, 2010. An extensive discussion, including a summary of the major issues and recommendations, can be found and continued at Pending Changes/Closure. Discussion about the poll itself can be found on this page's talkpage.

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 - 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]
  2. 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]
  3. Support 1 Is this really worth keeping? ~~ Hi878 (Come shout at me!) 00:09, 22 August 2010 (UTC)[reply]
  4. Support 1, discourages new editors from editing.Sumsum2010 · Talk · Contributions 00:22, 22 August 2010 (UTC)[reply]
  5. 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]
  6. 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]
  7. 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]
  8. Support 1 Slow with unclear and not followed standards.Cptnono (talk) 00:58, 22 August 2010 (UTC)[reply]
  9. 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]
  10. Support 1 Bejinhan talks 03:03, 22 August 2010 (UTC)[reply]
  11. 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]
  12. 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]
  13. 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]
  14. 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]
  15. Support 1 Due to reasons given on the comments page. Layona1 (talk) 04:12, 22 August 2010 (UTC)[reply]
  16. 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]
  17. Support 1. Unnecessary complication.Biophys (talk) 04:58, 22 August 2010 (UTC)[reply]
  18. 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]
  19. 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]
  20. Support 1. No real benefit for the creation of tons of busy work. Courcelles 05:40, 22 August 2010 (UTC)[reply]
  21. 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]
  22. Support 1 or 4 - Myfeelings are like Courcelles above, so I am not oppoed 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]
  23. 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]
  24. 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. --GW09:03, 22 August 2010 (UTC)[reply]
  25. 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]
  26. Support 1 Deters newcomers. Elitist. Richard75 (talk) 10:35, 22 August 2010 (UTC)[reply]
  27. Support 1. Discourages new users from editing. Adds unnecessary extra work for others. Offliner (talk) 11:04, 22 August 2010 (UTC)[reply]
  28. 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]
  29. 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]
  30. 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]
  31. Support 1 Goes against everything WP is about. Access Denied talk contribs editor review 15:11, 22 August 2010 (UTC)[reply]
  32. 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]
  33. 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]
  34. 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]
  35. 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]
  36. Support 1Kerαunoςcopiagalaxies 17:01, 22 August 2010 (UTC)[reply]
  37. 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]
  38. 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]
  39. 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]
  40. Support 1 ῤerspeκὖlὖm in ænigmate ( talk ) 19:23, 22 August 2010 (UTC)[reply]
  41. 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]
  42. 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]
  43. Support 1. Deters newcommers. Limited effectiveness against vandals. -FASTILY (TALK) 20:19, 22 August 2010 (UTC)[reply]
  44. Support 1 per all above. All Hallow's Wraith (talk) 20:27, 22 August 2010 (UTC)[reply]
  45. Support 1. Too complex, little real benefit. --Sable232 (talk) 21:01, 22 August 2010 (UTC)[reply]
  46. 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]
  47. 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]
  48. 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]
  49. 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]
  50. 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]
  51. 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]
  52. 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]

Keep: option 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 Nil Einne (talk) 03:18, 22 August 2010 (UTC)[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]
  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.MAHEWAtalk 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 3Glenn 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 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]

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]
  1. 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]
  2. Oppose poll per Cybercobra's comment #39 under Keep, but if and only if certain issues are addressed. I feel very strongly that the feature should be monitored carefully for the problems related to discouraging anons. I also concur with those who think that the interface and guidelines need work. Particularly, the "don't accept", "stop reviewing", and "accepting of incorrect changes just because they aren't vandalism" issues need to be addressed. The latter is my strongest concern. Entire poll is poorly thought out at best as discussion page shows. Millahnna (mouse)talk 19:33, 22 August 2010 (UTC)[reply]
  3. Oppose this biased three-options-against-one poll. Biased towards the "yeas" and likely ending with votes being counted towards an option the voter had not supported. SpinningSpark 21:05, 22 August 2010 (UTC)[reply]
    I think the best way of doing polls with more than two options is multiple rounds in which the option with the fewest votes is dropped after each round, but that would require people to come back here a few times. Hopefully we can get a feel for the real consensus after this vote. —Arctic Gnome (talk • contribs) 21:10, 22 August 2010 (UTC)[reply]
    That's not the point. It should be either a straight choice of four options, or an initial keep/close vote that makes clear that "keep" means "keep regardless". The current hybrid risks fooling voters into thinking their expressed, exclusive choices are being honoured, when those votes will instead be bundled together with conflicting votes and used to bring about a result they didn't vote for. PL290 (talk) 21:25, 22 August 2010 (UTC)[reply]
    I dislike the format of this poll especially in its original "vote" incarnation. I don't think this should be used as a "3 vs 1" poll but it can legitimately be used as a "keep vs stop" poll (and that would be less chaotic than running pro/con votes on all four options simultaneously). There are a few people with a "one extreme or the other split" (option 1 or 4) but on the whole, this straw poll is addressing the basic question "Do we want to stop the trial or not?" After the poll has been run, if (as seems likely) the trial is to be continued, then there needs to be a new debate about in what format it is kept. It would be unfair just to use the 2/3/4 results of the "keep" !votes to determine what to do next! TheGrappler (talk) 21:33, 22 August 2010 (UTC)[reply]
    I disagree—see related discussion in numerous sections on the talk page. PL290 (talk) 21:38, 22 August 2010 (UTC)[reply]
    In my opinion, Spinningspark got it 100% right in this diff. That set of instructions would have ensured that, had general polling favored keeping the trial, nobody opposed to continuing the trial would have an input on the form it was kept as. That's potentially very significant, since those people supporting an end to the trial would clearly (judging from their comments) prefer the minimal possible continuation in such circumstances, and oppose a large scale roll-out. I would like a massive expansion of flagged revs, but I want those people who disagree with me to have their say too - not just for them to be told you've lost the vote on whether we continue, now we, the victors, will choose how to proceed. That would be ludicrous. TheGrappler (talk) 21:47, 22 August 2010 (UTC)[reply]
  4. Oppose the poll; poll was created with a bias that cannot be addressed short of redoing the whole thing. —Jeremy (v^_^v PC/VC is a show-trial!) 21:15, 22 August 2010 (UTC)[reply]
  5. Oppose the poll per Spinningspark and Jeremy plus related discussion in numerous sections on the talk page. PL290 (talk) 21:38, 22 August 2010 (UTC)[reply]
  6. Scrap this poll and notify all existing participants of the new forum. Far too many grave concerns have been raised by too many independent users.   — C M B J   21:45, 22 August 2010 (UTC)[reply]
  7. Scrap this poll The poll was constructed with an extremely clear steer that the outcome is either going to be scrapping or expanding. A significant proportion of people want the thing scrapped. The fact that they are a (large) does not mean they should be entirely ignored. --WFC-- 22:04, 22 August 2010 (UTC)[reply]
  8. Defective polling instrument - Since in essence there is only a boolean choice here (keep it on or off), it's inaccurate to present the choice as four distinct options where three have the same net effect. If this is the path to closure, there should be two or three separate polls: (1) keep PC we know today in force or not; (2) continue to pursue PC; (3) best way to improve PC (assuming #2 is "yes"). //Blaxthos ( t / c ) 22:05, 22 August 2010 (UTC)[reply]
    I don't like the poll in its current form, but there is some worth in seeing how the 2/3/4s are distributed among the "keep" voters (and indeed, what "second preferences" would be among those who'd rather end the trial now) because after this binary choice, other choices are far more open. Seeing the strength of feeling about expansion of flagged revs can help inform what kind of discussion we have next, but obviously it is not a replacement for the next discussion. For instance, if the consensus is to keep, and the vast majority of "keeps" are mostly strong in favor of option 4, then we need a subsequent discussion about mass roll-out to BLPs; if consensus is to keep, but there is a more equivocal mixture of 2s and 3s with lots of comments about how the system needs to improved before it's rolled out, then we probably need to be having a very different discussion afterwards. TheGrappler (talk) 22:22, 22 August 2010 (UTC)[reply]
No matter what option could be selected, it will require continued discussion and improvement. None of the options clarifies reviewer policy, or fixed the change/accept issue, or sets down page-use guidelines. All of those things need to be figured out no matter which option gets the most support. Still, if the 2:1 ratio of option 3 (keep with minimal expansion) : option 1 (close) remains, I don't see how we could justify ignoring that. To use the voting lingo, you only have a run-off if there's not a clear winner. But if overwhelming support is for option 3, then what is left to formally discuss besides how best to implement it? Ocaasi (talk) 23:38, 22 August 2010 (UTC)[reply]