Wikipedia:Pending changes/Closure

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

The scheduled two-month trial has ended. The community should now decide if the implementation is to be continued, and it should discuss possible adaptations, in terms of policy. Developers have indicated it would be too complex to turn off the feature, then turn it back on in case the decision is in favor of continuing the implementation, so they will wait for the community decision — unless it takes more than a month, in which case they will turn off the feature. In the meantime, it is possible to ask administrators to stop adding new pages under pending changes.

The trial was approved in this poll. A community consensus is required to continue the implementation. A discussion phase of roughly two weeks analysed the trial, and a decision phase with a classic support/oppose continuation poll of two weeks began on 22 August 2010 (00:00 UTC). It will end on 5 September 2010 (00:00 UTC). The organization of the closure is still under discussion.

For information, you may consult the feedback given during the trial. As of 20 August 2010, there were 1,409 articles under pending changes, and the average lag for pages with unreviewed edits pending was 4 minutes, 30 seconds — see Special:ValidationStatistics for updated statistics, and Wikipedia:Pending changes/Metrics for metrics on usage of pending changes. The Preliminary Analysis page has some cuts of data that may be useful for discussion. There are also Village Pump proposals relating to the discussion (FA Pending Revisions proposal).

Working Summary (unofficial)

This section should briefly list issues. Transfer ideas to this informal summary. Neutral phrasing appreciated. May get edited for clarity. Please keep discussion in other sections. It is not necessary for everyone to agree that every point is valid, just to get a consensus on which issues have been identified.

Pros (what worked)

• - Allowed IPs (anonymous users) to continue to edit
• - Allowed systematic page monitoring
• - Kept most vandalism from appearing
• - Pending Changes queue cleared quickly
• - Adds another option between 'open' and indefinite semi-protection
• - Some reviewers enjoyed looking at pages that they might otherwise have had no reason to look at.

Cons (what didn't work)

User interface / Usability

• - Speed issues with loading diffs
• - Confusing accept/unaccept scheme
• - Complicated to review multiple edits. Some good intermediate edits could be missed if followed by vandalism.
• - Causes "review conflict"
• - Review summary not visible in edit history; you have to cross-ref the edit history and the review log to get the full picture
• - Some people are unhappy about the way pending changes are highlighted on the watch list
• - Complicates editors' seeing and correcting errors they made if the errors were not caught during preview
• - Relative to semi-protection, "clutters" edit history with vandalism/reverted edits

Vandalism / Workload

• - Some users accepted false additions that would have been obvious to someone familiar with the article or who looked at it
• - Some pages continue to suffer large amounts of IP/unconfirmed-user vandalism and so might be better to have semi-protection
• - Pages with a high frequency of edits have multiple problems
  • - Creates a high workload for reviewers. Some reviewers may be put off by seeing the same page appearing repeatedly at Special:OldReviewedPages.
  • - These pages often accumulate pending changes from multiple users, which leads to further problems
    • - More complex for reviewers to review
    • - Helpful, auto-confirmed (non-reviewer) editors are being denied instant gratification and possibly being confused, which would not be the case with semi protection.
    • - IP editors will be editing a version of the page that they may not have seen.
    • - It can appear that the reviewer is taking sides in an edit war. Even if the reviewer accepts multiple versions, only the last accepted version will get its time being visible to non-logged-in users.
  • - Sometimes these pages attract multiple different vandals and hence putting off one vandal, by denying instant gratification, may be less successful than on low-edit-frequency pages.
• - Failed to achieve a desirable effect in at least one instance
• - Counterproductive on pages protected due to sockpuppetry
• - Can be exploited as a sophisticated form of vandalism; potentially creates an extra incentive for subtle vandalism, i.e. Vandals may feel a sense of achievement if they get their vandalism accepted. Provides an extra system for disruptive people to game
• - The ratio of manpower : effect is inefficient when compared to semi-protection; in some cases, the amount of time necessary to manage vandalism increased rather than decreased
• - Vandalism removed by IPs will still be visible until someone accepts the change
• - Increases chances that subtle vandalism won't be detected if people see the "accepted" status as a sign that things are OK
• - Because PC stops IPs from seeing vandalism, they won't be helping out with reverting or fixing that vandalism; relegates vandalism fixing tasks and patrolling in PC articles to autoconfirmed users only, increasing their workload and preventing others' ability to assist

Community

• - May be perceived as a burdensome and bureaucratic process in general
• - May increase the perception of a hierarchy amongst Wikipedians
• - May inadvertently result in article ownership and/or soft-censorship of conflicting POVs
• - Can put off new users in a way that neither "no protection" nor "semi protection" can. i.e. IP goes to an article and makes a constructive change, clicks save, but doesn't see his or her edit in the article. Figures, "doesn't work", or "too complicated to figure out", and never edits again
• - Disrupts the Bold-Revert-Discuss cycle
• - Some editors inadvertently unaccepted good edits on subjects with which they were not familiar, causing battles
• - Unclear or controversial guidelines for reviewers led to conflicts
• - Fewer users see a change in an article before it is reverted. Some users who would have seen a good change, and questioned its removal, won't even know about it to go to bat for keeping it in.
• - An IP may want to edit constructively, but is addicted to instant gratification, so doesn't bother editing at all.
• - Inconvenient for users to check each others reviewing behaviour (Most users are unaware of Special:AdvancedReviewLog or that it can be filtered by user; even if you know this, it is several clicks away)
• - May conflict with one or more of Wikipedia's founding principles
• - Proposed policy level implantation does not offer Wikiprojects, working groups, or other editor-based article improvement units the option of interpreting and applying such protection for their articles if they so wish.

Feature Requests (what might make it better)

User interface / Usability

• - A "stop reviewing" button that marks the pending change as no longer "under review". Alternatively this button could be called "put back in queue" or "defer". The desired effect can currently be achieved by accepting and then unaccepting an edit, but that's a hard one to explain and a single button would be much better.
• - A shorter timeout on the "under review", and/or use of Javascript to determine automatically when the review is no longer actively examining the article
• - Different logo for PC/Reviewers
• - Unapprove button should be hidden when inactive, not greyed out.
• - Clearly labeled "Reject" button tied to the rollback or undo action on the review form using the reason entered as the summary
• - More common names for PC specialpages, and a quick link to PC specialpages, in addition to notification of PCs on your watchlist
• - Better links to documentation on PC related specialpages
• - Incorporate the PC protection rationale (protection log message) into the review screen as instruction to the reviewer.
• - Make it faster
• - An "accept" button/link on the watchlist or page history without loading the full diffs - using popups for example
• - Make page protection log more visible (reviewing depends on protection reason, but it's hidden by default) Is this the same as "Incorporate the PC protection rationale (protection log message) into the review screen as instruction to the reviewer."?
• - Add short reviewer instructions to the review page
• - Easier access to preview/edit from the review page, for on-the-fly edits to pending changes
• - Don't make reviewers who try to directly edit an article they're reviewing have to accept their own edits
• - Ability to leave short notes/questions for other reviewers on the review page itself
  • Ability for reviewers to add a comment without making a review decision - this could allow concerns to be left for other reviewers.
  • Ability to request expert advice on a review decision.(should add the page to a report)
• - If another user preempts a page under review, make notification to the reviewer more obvious
• - An assisted tool for handling large pending changes queues (something along the lines of Huggle or Igloo)—before we have a large pending changes queue—to prevent a self-defeating backlog
• - If we end up with a lot more pages under pending changes protection, Special:OldReviewedPages should allow some kind of filtering or ranking so that reviewers can focus their effort. e.g.
  • - Separate out those pages that are on a lot of watchlists. It may be better for reviewers to concentrate on pages that they know about and pages on few watchlists.
  • - Rank pages for each reviewer according to considerations such as direct association (whether it is on that users watchlist, how many edits the user has made to the page) and direct association with pages that have links in and out of the page under consideration. By default, a reviewers Special:OldReviewedPages could order the pages according to the rank for that reviewer relative to the average rank for all users
• - Changes of terminology could make this feature much more understandable and usable.
  • "Review" sends the message to vandals (and other editors) that "accepted" means wikipedia has allowed invalid changes. Suggested "Review for obvious vandalism" (or whatever policy is agreed upon) to specify the precise depth and limitations of this type of review.
  • Suggested term "Visible" rather than "Accepted"
• Ability to supply a missing edit summary, or annotate an unclear/misleading one. (potentially this needs to apply to all articles, but PC would be a good start)

Policy

• - Need to better define when to use semi-protection instead of pending changes (leading to changes to Wikipedia:Protection policy)
• - Further work to establish consensus on what reviewing means. Ideas for changing Wikipedia:Reviewing pending changes include:
  • - Encourage people to stop reviewing if they are unsure.
  • - A more clearly defined process for handling edits that are clearly nonconstructive, but may not fall squarely into one of the nonacceptance criteria.
• - Need to respond swiftly to reviewers who use PC to censor views they disagree with.
• - More prominent description of how to review other reviewers
• - PC protection should be used mainly/exclusively on pages with a low frequency of edits
• - Works best on certain types of article. e.g. For articles in Category:Surnames and Category:Given names, a lot of the IP edits are vandalism but some are not and so the pages gain information that they would not with semi protection.

Expansion or contraction (beyond policy and pure numbers of articles)

• - A possible "PC3", with which all edits must be reviewed by an administrator prior to appearing in the "stable version" for possible trial as an alternative to full protection
• - Possibly remove the option of PC2. It increases the power of reviewers to censor other Wikipedians.
• - Ability to "defer" edit(s) on an article that is not under Pending Changes protection
  • - Most likely using a modified Wikipedia:Edit filter
  • - Possibly tie in with RC patrol, particularly when assisted with RC patrol tools such as Twinkle, Igloo, and Huggle - allowing for implementation of a "2nd opinion" feature completely within Mediwiki
  • - However it is done, indicate why the change is flagged for review on the review screen

Open questions (what was unclear)

Evaluation

• - Did vandalism attempts go down on PC pages?
• - Did the timing of the trial--during the June to August period when there is a drop in vandalism levels--skew results?
• - What percentage of IP/unconfirmed edits were "good edits"?

Implementation

• - Is PC better for high or low traffic pages?
• - Are reviewers checking "good edits" or just preventing "vandalism"?

• Check for obvious deficiencies?
• Check for vandalism only?
• Enforce reliable sources?
  • All of the time?
  • When a change looks questionable?

• - Is PC for protection (use on problem pages only) or prophylaxis (use on many pages)?
• - Will reviewing rights be taken away as sanction for bad behavior?
• - On what grounds should an editor be denied "reviewer" status?

• Disregard for reviewer guidelines?
• Disregard for WP:COI
• Editors with a recent history of vandalism, blocks, or other sanctions that would indicate poor judgment?
• Editors who have previously (recently?) had reviewer status taken away for poor judgment?

• - Should "reviewer" status be auto-confirmed, e.g. based on X number of edits or X amount of time?

• Should be relatively easy to get, but not auto-confirmed - a defense against "sleeper" accounts is required to prevent vandals from getting the reviewer permission, especially if we let up on RC patrol on "reviewed" articles.

Expansion

• - Would the pending changes queue have a backlog if PC was expanded to many more pages?
• - Should PC be expanded to BLPs, low-traffic pages, or other articles?
• - Does the similarity of PC to Citizendium's approved content model indicate similar intentions or consequences?
• - What would the 5,000 or so reviewers be doing otherwise, if they weren't reviewing articles?

Notes

Preliminary discussion

Note that pending changes is still active. It will be shut off in 1 month unless there is consensus to continue

• (Am I doing this right?) I liked it. I noticed speed issues with diffs loading, but that seems to have improved. I definitely prefer allowing IPs to continue to edit, so I prefer it to semi (and used PC1 instead of semi at WP:RFPP a lot). It seems less than ideal with high-traffic pages, and I had to change PC1 to semi several times, but for low-traffic pages it's great. I'd like to see pending changes kept. I'd also like to see us considering using PC1 by default on all WP:BLPs. TFOWR 14:26, 14 August 2010 (UTC)
• Definitely a success that should continue and be widened to more problem pages. I think there are some pages that should remain fully or semiprotected because either the frequency of vandalism makes pending changes impractical or with high profile templates the impact of vandalism is too great. I would like pending changes to be the norm at least for BLPs that have been offensively vandalised, and for approval to be tightened to "I've checked and it is a good edit" rather than the current "I've looked at it and it doesn't look like blatant vandalism". ϢereSpielChequers 14:44, 14 August 2010 (UTC)
• I like the pending changes feature myself simply because I have seen almost no vandalism on pages in the second month of its implementation, whereas I found many in the first month. Thus, I think it does serve the purpose of fighting vandalism. For this reason, I would typically suggest it be used site-wide only on extremely inactive pages (i.e. maybe five edits a day at most), but sitewide implementation is being considered taboo (understandably). I won't do the analysis of whether semi-protection or PC is better for various pages, but I can say that PC is doing the job of keeping vandalism from appearing, even if it's not reversed until an hour later (something that rarely happens in my experience). Also, if a page is getting too many edits to review, and a lot of vandalism, it can always be requested for SP for a one or two month period, or longer depending on the page. I've had to do this, it happens. CycloneGU (talk) 14:50, 14 August 2010 (UTC)
• I am in strong support of implementing this feature. It is an excellent alternative to the typical procedures at WP:RFPP and allows pages to be monitored in an effective manner. As an alternative to page protection, pending revisions do not defeat the purpose of a wiki, something everyone can edit. Pending revisions will keep vandalism from appearing to an anonymous reader; but will, at the same time, allow a non-registered user to edit in good faith to edit a page, something that is not possible when a page is under the standard form of protection. I've noticed that pending revisions have actually decreased the amount of vandalism seen here, seemingly discouraging vandals as they realize that their 'changes' will very rarely be seen by the public eye. Tyrol5 [Talk] 15:00, 14 August 2010 (UTC)

• Note my comments about rapid attacks and sockpuppets above. PendingChanges is useless against either. —Jeremy ^{(v^_^v Carl Johnson)} 20:18, 21 August 2010 (UTC)

• I'm all for keeping it - allowing people to edit is better than shutting them out, and some form of protection is sadly going to be with us regardless. There are some circumstances where its use is inappropriate, for technical reasons or conceptual ones, and there are some forms of maliciousness it doesn't protect against, but it's not meant to be a uniform panacea and in the circumstances where it's useful (pages with "normal" vandalism issues, but also potential good-faith passing edits) it works well. My suspicion is that once we stop having the somewhat forced atmosphere of a "trial" then the turnaround time for edits will increase slightly as it becomes routine work,but on the other hand this will lead to more edits being picked up from watchlists and so forth by editors involved in specific pages, meaning that we'll have more informed reviewing and less of the reported overenthusiastic "not crude vandalism" approvals. Swings and roundabouts.

• It only works well because nobody's sussed out a way to bypass it. As I stated below, Murphy's Law in regards to our antivandalism measures has never been proven fallacious. —Jeremy ^{(v^_^v Carl Johnson)} 20:18, 21 August 2010 (UTC)

• I don't see any problem with lifting the numerical cap on protection, but I think keeping it explicitly as a form of protection for the time being - and so a tool not to be applied to huge numbers of pages on a prophylactic basis - is wise; this effectively means it's unlikely to exceed 5-10k articles, the current protection level. We should come back again and discuss things like applying it to wide sets of articles seperately, a few months down the line, and decouple it from whether or not simply to keep the pending-changes tool around. Shimgray | talk | 15:22, 14 August 2010 (UTC)

• As a form of protection it's useless. PC just clogs the history with drek and will only increase the workload of admins, nonadmins, and Oversighters alike. The downsides are far too serious and outweigh the upsides. —Jeremy ^{(v^_^v Carl Johnson)} 20:18, 21 August 2010 (UTC)

• The good: it allows more editors to contribute while keeping vandalism in check. Pending revisions should be accepted by the community.

The not so good: editors bitching at other editors accepting not vandalism but maybe not correct edits. In other words, for following the WP:RVW policy as written. Further work needs to be done in establishing a consensus for what reviewing means. I see that as a separate discussion that whether to accept pending revisions. I assume that discussion would take place at Wikipedia_talk:Reviewing pending changes. Gerardw (talk) 15:35, 14 August 2010 (UTC)

I know this is aimed at comments another editor and I made on your talk page regarding infactual edits accepted. It was an attempt to be polite and I felt you replied to us very standoffishly by pointing at a policy with no further comments yourself. My complaint about the policy is something I'll address if pending changes DOES stay, and my comments were not meant to be "bitching" as you say, just constructive criticism. For my part, I apologize if you thought otherwise. I agree that "further work needs to be done in establishing a consensus for what reviewing means". CycloneGU (talk) 16:51, 14 August 2010 (UTC)

• I'd drop the idea. Too much complexity (especially removing the feedback of seeing changes) chasing too little of a problem. Vandalism already gets quickly reverted. North8000 (talk) 15:46, 14 August 2010 (UTC)

Keep in mind that not only is it an anti-vandalism tool, it can be used as an alternative to page protection in some cases (see my reasoning above). Tyrol5 [Talk] 16:13, 14 August 2010 (UTC)

From the ones that I've seen, I'm having a hard time thinking of page protections situations where this would be applicable / useful

One other note, right now you are polling the converted. Persons interested in this, and used to dealing with the complexities to the point where you can't understand that they are complexities. If you would liked a sampling of the rest, I'd cast the RFC net wider, and provide a simple 1 paragraph summary of what this change would mean. North8000 (talk) 16:23, 14 August 2010 (UTC)

As an alternative to page protection, I think it would be useful mainly in the area of constant WP:BLP violations, rather than consistent vandalism (where an RFPP may be necessitated). Tyrol5 [Talk] 16:33, 14 August 2010 (UTC)

I think that aa lot of the problem folks on those are auto-confirmed accounts, and and nothing "higher". E.G. that's what I am. It's unclear whether or not their edits would need to go through the gauntlet. North8000 (talk) 18:31, 14 August 2010 (UTC)

And that's certainly a valid concern, which is why different levels of PC protection were proposed originally (see this). Tyrol5 [Talk] 18:49, 14 August 2010 (UTC)

Just to respond to that point about vandalism getting quickly reverted. Yes the vast majority is, but we have no way of knowing when recent changes is unattended or swamped. Today I found an article that was vandalised 18 months ago, pending changes is a better system and will make that sort of thing rarer. ϢereSpielChequers 19:40, 14 August 2010 (UTC)

It's definitely a mistake to think that vandalism can always be reverted quickly. Among the articles I've applied pending changes to are: the president of a major international organisation called a penis for nearly a day, a school article containing outrageous libel for five months, another school prominently described simply as "full of slags" for ten days, the leader of the opposition in Israel with a vagina for a photo for six hours, and the White House Chief of Staff labelled dead for a while (a similar edit to the President's top advisor lasted 3 hours). It's stuff like that that slips through the net and does nobody any good. With pending changes we don't have to lock them up to all new users. -- zzuuzz ^(talk) 18:49, 16 August 2010 (UTC)

• It wasn't as bad as I expected but I still do not like it. 1)There were certainly issues with how slow the pages were. 2) The principle is still terrible in my opinion. 3)There is confusion on if you are expected to accept poor edits that are not vandalism or not. 4)It is turning into sign of endorsement for editors and some will lose it since the community wishes to punish them. That is a a weird path to go down. There is an ANI about stripping a user of their access. It looks like the editor has made mistakes but he did not misuse the feature. Cptnono (talk) 19:17, 14 August 2010 (UTC)

  I'd like to comment on the slowness since I was the one to report it: bugzilla:24124. In truth, pending changes did not made anything slower. Basically, pending changes are all about viewing diffs and archives versions of articles in order to review or revert them. Those pages are not cached so they take longer to load. As a result, users feel that it's slower because they are viewing more uncached pages than before. But the loading speed of each pages remains the same.

  Most of this problem is solved already. As Chad H. said: "When diffing to the current revision (which is the most common scenario) we can use the parser cache to save some rendering time. In my test page (58,699 bytes), I was able to cut execution time from over 1100ms down to less than 15ms." Revision #69414 reduces long loading times (10-20 seconds) when displaying a diff between the current version and an older version.

  If you feel the loading time is still slow do not hesitate to report it. If possible, use the Firebug add-on for Firefox like I did, to help identify accurately the source of the problem. Is the cause of the problem your browser, your bandwith or WMF's servers? Yours, Dodoïste (talk) 21:21, 14 August 2010 (UTC)

  Firebug++. But of note there are similar tools built into Safari and Google Chrome. -- Eraserhead1 <talk> 14:58, 15 August 2010 (UTC)

• I think generally it's worked quite well, though I think WereSpiel has the right of it around some of the issues that have come up. I think it's a pretty good system, though I think some of the guidance and policy advice around what should and shouldn't be approved needs tightening. GedUK  21:16, 14 August 2010 (UTC)

I see what you are saying (I couldn't agree more), but keep in mind that this was only a preliminary trial. Tyrol5 [Talk] 04:06, 15 August 2010 (UTC)

• Oppose. In my views, the cons outweigh the pros. First, it complicates matters (especially with the mislabelled Accept/Unaccept buttons). Second, the speed is still a problem (yes, it's faster now but still noticeably slower than before). Third, non-obvious vandalism edits such as inserting wrong information are easily approved by people who're not familiar with the topic and so it slips through the cracks, only to be later on reverted by another volunteer. In a way, you're using 2 units of time to revert such kind of edit under the Pending Changes scheme when it could have been done in 1 unit of time under the Semi-Protection scheme. Some have also reported that if 2 reviewers are trying to disapprove an edit, the result is that the undo gets reverted and vandalism goes through. OhanaUnited^{Talk page} 04:18, 15 August 2010 (UTC)
• If the denial of approval criteria is only for blatant nonsense and obvious vandalism, I say keep it. If it's going to be expanded to include "bad edits" I think it's a terrible idea. Editors need the feedback provided by tags and reverts when they add unsourced or poorly sourced or poorly written or factually wrong good faith "bad" edits. 71.111.66.128 (talk) 05:33, 15 August 2010 (UTC) Woah, that was me. I thought I was logged in. Vampyrecat (talk) 05:35, 15 August 2010 (UTC)
• I thought it was pretty successful, while some vandalism undoubtably got through the cracks the situation was fairly obviously better than having no protection at all where it would all "get through". As one of the people who got iPad up to GA I thought it worked pretty well at allowing good IP editors to make contributions - even though there was a decent amount of vandalism to revert. Additionally quite a lot of "good faith" edits that were wrong (such as dodgy links/WP:CRYSTALBALL violations) were also caught at review which is good.
• I would say outright vandalism on iPad went down and I'd guess there were more borderline edits. However as its spent so little time unprotected its difficult to know. The major bad thing was the speed of doing the review, really that needs to be speeded up. -- Eraserhead1 <talk> 14:24, 15 August 2010 (UTC)
• Some articles are better off with protection rather than review status. A good example is Emma Watson. As far as I can tell, almost all that happens is IPs make changes that get reverted by reviewers. The edit history is mind boggling. I'm sure there are other examples.--Bbb23 (talk) 18:58, 15 August 2010 (UTC)
• I have a number of articles on my watchlist where for years, every few weeks or months, very problematic BLP material has been inserted by varying IPs. (e.g. Wisconsin Hoofers) It will take time to find out, but my hunch is that once the person(s) realizes that the edits are never, ever visible to the public, these attacks will drop off. For this kind of situation PC beats semi-protection, and avoids situations where the material stays in an article for days before somebody notices (as happened recently when I was on wikibreak). I agree comments about the slow loading and lack of clarity about how to revert/accept things. --Slp1 (talk) 20:21, 15 August 2010 (UTC)
• The trial was largely useless. The original objective of flagged revisions was to protect many BLPs, not anything about "opening up editing" that it turned into to spin it to the press. We should continue to use it, but on a much more massive scale. All BLPs with less than 5 watchers would be a good place to start once the trial is over. Also, can we convert this to RFC format please? NW (Talk) 00:00, 16 August 2010 (UTC)

• For what it was worth, I thought the trial actually did defer a small amount of vandalism. However, in this case, the "small" amount of vandalism isn't enough of a real difference. Maybe, if this process was automated (the process of protecting pages and flagging reviews), it may outweigh the cons (cons being slow pages, tedious processes, and extreme load on the servers). But for now, I will have to say that I  Disagree. _{If only Wikipedia was powered from a crystal ball...} A p3rson ‽ 01:00, 16 August 2010 (UTC)

• Slow, unclear guidelines, essentially meaningless in many cases. Basically, most of the vandalism gets reverted right away, and in many cases, semi-protecting it is necessary because of the level of vandalism. The articles for which pending changes would work well are few, and I would only support its use for BLPs (and not all of them by default), although I'm leaning toward opposing its continuation. —fetch·comms 01:12, 16 August 2010 (UTC)
• Oppose in all stripes. All it does is shunt the garbage off to the history (which can cause issues with severe BLP material), and I am extremely suspicious of the timing of the trial (it started, remember, as the school year ended). In addition, the responses of several of the supporters and/or detractors of this change seem to think we're trying to chase Citizendium's goals, which I find to be rather insulting not just to Wikipedia, but to the programmers. —Jeremy ^{(v^_^v Carl Johnson)} 03:55, 16 August 2010 (UTC)

• As an aside, I also vehemently oppose, should this end up being implemented, compulsory reviewer rights based off of account age or edits. Not only does this guarantee that someone who is unwilling or unworthy of using the userright is given it, but it will only make some of the issues brought up (such as accept/unaccept ambiguous edits that aren't blatant vandalism) worse. —Jeremy ^{(v^_^v Carl Johnson)} 21:25, 16 August 2010 (UTC)

• Oppose Even on the few pages where it worked, I don't think we gained nearly enough good edits to justify the hundreds of hours of time that went into this by admins and reviewers. (Those hours were made much longer by the sheer slowness of the system). The amount of volunteer time this will consume if widely deployed is incalculable. Shut it down, use semi-protection a tad more, but let's lose this system. Courcelles 04:21, 16 August 2010 (UTC)
• I'm strongly in favor of continuing this, but I think we need to rethink how it's used and where it fits into the existing RC patrol processes. Honestly, I'm thinking that while using this to mitigate the impact of semi-protected and full-protected articles is a very good thing, it's shortsighted to think it's the only use. Featured articles as well as very low traffic articles on specialist topics (where an RC patroller can't determine if an edit is appropriate simply at face value) would be good areas to discuss the value of pending changes protection. Triona (talk) 07:08, 17 August 2010 (UTC)
• Comments

Procedural issues

• The 'poll' forming here on the Closure page is not a representative sample of the community; most people here will be reviewers. Acceptance needs broader discussion in the community; I don't know if RfC is planned, or what.
• The above 'in favour' do not make it clear what they are in favour of; some people object to 'across the board', or specifying ideas of limits, but there are no specific implementation plans that have been put forward. As PC can mean over 9000 different things, we need ultra-clear proposals that we can support or oppose.

Observations

• I'm concerned that it is only too tempting to see this as a quick solution to too many page problems; if a page is getting a bit of vandalism, it's tempting to just apply this, but we don't seem to know what impact that has on productive editors; we know that it has at least some impact, if only for the numbers of Wikipedians expressing their extreme disdain for the whole idea.
• A somewhat oxymoronic fact I found was, that it can work better when PCs are not reviewed so quickly. When there were many users vying to 'approve' a change as soon as it happened, there was a tendency for the editors to just briefly check if it was vandalism, and approve or reject it. That's fine, in as far as it goes - however, when things slowed down a bit, the reviewers tended to check the edits more thoroughly - for example, validating references or improving the format of the edit.
• I agree with CycloneGU above, that we need to clarify the expectation of reviewers - whether they just check for pure blatant vandalism, or if they should check further
• The terminology and interface is extremely confusing, 'unaccept' and the lack of a 'yes/no' type interface; this has been discussed elsewhere, so I won't elaborate here
• Speed concerns esp. on large articles
• If it is only used for vandalism, then not only is there the danger of things slipping through, but also people perceive that, because an edit has been 'accepted', it must be OK, therefore may not check it a second time

Conclusions

• I feel that the way forward is with improvements to the system to address concerns raised, followed by a further trial. I find it hard to judge if I would support or oppose other suggestions, without very specific proposals. Chzz  ►  05:21, 16 August 2010 (UTC)

Note that the pending changes is still active. CycloneGU (talk) 05:26, 16 August 2010 (UTC)

Also, this was listed at WP:Central discussion, so it should attract a wider audience. Ocaasi (talk) 15:43, 16 August 2010 (UTC)

• The trial has been a success, insofar as nothing blew up, vandalism was caught, i.p.s made some edits, and a new feature was explored. However, given the large list of interface issues, speed issues, reviewing guideline confusion, and general hesitation to expand this feature without full community support, we should advance slowly. I recommend that we continue the trial for 6 months with no further expansion. I would personally prefer that we expand it to 5000-10000 pages, to see how this thing scales, but I think that given the numerous complaints, it is more than fair to try and make PC better before we make PC bigger. After 6 months, which will provide more data, school-year vandalism tests, and time for better documentation and bug-fixes, we can re-evaluate. By then, perhaps the community will be okay with an expanded trial, or a blp-focused expansion, or a patrolled revisions (review without pending) type of test. Ocaasi (talk) 06:07, 16 August 2010 (UTC)
• Support - I don't feel in any way that pending changes was unsuccessful. It fulfilled its goal in preventing inappropriate edits while still giving "Anyone" the opportunity to edit the article, unlike semi-protection. I generally found it easy to use and relatively simple, and although some small issues have been brought up, I don't think anything shows that PC failed. Initially I opposed the idea of this, but this trial makes me think that it isn't so bad in the least. Swarm^Talk 06:37, 16 August 2010 (UTC)
• Support, Unequivocal, The trial went much better than pessimistically presumed by many. Many of the suggested improvements have been addressed and implemented during this trial. All projects endeavor to improve, therefore anticipating improvements is intuitive. No additional trial is necessary to show what has already been shown, which is that the "Pending changes" protection is effective, beneficial, and overall productive in total. Perhaps no article should be added unless there can be shown a specific request to do so, and requests to remove such protection should be emphatically considered. Under such guidelines, I can hardly see valid opposition. My76Strat 19:53, 18 August 2010 (UTC)

• While it may look like that is the case, the reality is far grimmer. FraggedRevs cannot handle mass attacks on an article (such as from 4chan threads) as the amount of edits made outstrips the capacity of reviewers to address them in a timely manner, and it is far too easily circumvented by autocon-buster sockpuppets who can outright bypass FraggedRevs altogether. In short, while it does reduce IP vandalism, it only does so if they aren't editing the article en masse (as those who attempted to use PC on, well, 4chan found out to their chagrin). —Jeremy ^{(v^_^v Carl Johnson)} 20:05, 21 August 2010 (UTC)

• Oppose, would require too much effort by people whose time is more useful elsewhere. Recent changes patrol is very similar to this but it has less, much simpler steps to get almost the same effect, vandalism removal. Also causes many unneeded battles between editors because of what should/ shouldn't be accepted.Sumsum2010 · Talk · Contributions 03:53, 19 August 2010 (UTC)

• Comment While I don't support the PC feature mainly because of the 'cracks' in its system(users falsely accepting changes, technical issues, etc.), an amount of vandalism does slip through recent changes patrol. Pending changes might be able to keep that in check in a certain measure, but the outstanding issues has got to be resolved first. Bejinhan talks 05:37, 19 August 2010 (UTC)

Arbitrary Break

• I would also like to see a more detailed, specific guideline for reviewers. In my observations, too much sneaky vandalism is being accepted; it seems that reviewers are generally only looking out for obvious vandalism as if this was recent changes patrol. Zzyzx11 (talk) 06:46, 16 August 2010 (UTC)

• What I gathered from the trial is that it adds another layer of complication that is burdensome and unnecessary. Regular page protection works just fine and can be used in all situations, whereas I found it hard to identify articles which would need specifically pending changes protection. PC doesn't really work on highly-edited articles because it just creates a ton of extra work that can only be done by a limited amount of users. And the revision history just looks like a mess, which doesn't help much with the revision pollution problem. I do like the fact that it allows highly-viewed articles to be sort of 'immune' from vandalism and it'd be nice if we could just permanently implement PC on just those limited amount of pages, or on all FAs, but that's not likely going to happen. -- œ^™ 11:05, 16 August 2010 (UTC)
• I think it's a very useful tool; the trial has shown it to be very good for some purposes (but not others). I would strongly support continued - and wider - use of pending changes. Of course, there should be discussion about exactly how it's used, what pages it should be used on, and how people should review. :-) bobrayner (talk) 11:39, 16 August 2010 (UTC)

• Some reviewers accepted false additions that were clearly false to anyone that had looked at the article. A lot of work was created for little content benefit from the unconfirmed users, at some articles all the contributions from unconfirmed users or the vast majority of it was false additions. When a reviewer is going around reviewing and accepting and adding false content because his edits as accepting are not visible in his edit history it is much more difficult to find and check his previous pending accepted edits. A reviewer could be going around accepting and inserting false content into articles all day long and it would be hard to spot him. Off2riorob (talk) 09:22, 16 August 2010 (UTC) 14:15, 16 August 2010 (UTC)

Reviews are quite visible, e.g. [[1]] Gerardw (talk) 17:05, 16 August 2010 (UTC)

Not as visible as edit history. You have to cross-ref the edit history and the review log to get the entire picture. OhanaUnited^{Talk page} 04:26, 17 August 2010 (UTC)

• I'm all for it. It doesn't particularly work on the most vandalised pages where semi-protection is better, but pending changes is ideal for articles which aren't widely watched where libel and other vandalism can often sit for months and do real damage, and where new and unregistered users can still make improvements. As an alternative to indefinite semi-protection it makes a great addition to the admins' toolbox. -- zzuuzz ^(talk) 16:13, 16 August 2010 (UTC)

• I think it's a waste of time; The complex bureaucracy of the reviewing process is very intimidating, even to me. I can only imagine what it's like for a newbie. It also drives off many would-be contributers who think we're going the way of the german wikipedia. It is confusing, elitist, off-putting, and hasn't made any noticeable difference to the level of vandalism. Toss it, definitely. ☻☻☻Sithman VIII !!☻☻☻ 18:57, 16 August 2010 (UTC)
• I'd seen some vandalism spot up on PC articles. It is a great anti-vandalism tool. —I-20the highway 21:40, 16 August 2010 (UTC)

• In general, it seemed to be more of a pain than it was worth. My particular problem was with articles that had previously been semi-protected because of sockpuppetry. Edits by socks were not detected by average reviewers, and I don't reasonably expect them to be: how many editors actually have the IP ranges for various sockpuppeteers in memorized? Semi-protection blocks those edits (or, at the very least, forces the sockpuppeteer to make a named account so that once he is detected, all of his edits can be reliably and conveniently reverted). Pending changes was just completely ineffective against that.—Kww(talk) 04:28, 17 August 2010 (UTC)

• I've got a fair number of thoughts, and they cover a broad spectrum, so I'm just going to jump right into "loose conglomeration of bullet points" mode and be done with it. Apologies for the loose prose.

1. First and foremost, this trial hasn't captured and can't capture certain aspects of a real deployment. In particular, without the 2000 page limit, we are certain to see backlogs and blind acceptance (or blind reverting) of edits without checking the immediate prior history. Another point is that we haven't particularly tested what happens when vandals know how PC works. Remember, when vandalism is accepted, it becomes harder to get it off of the article, since not everyone can revert it anymore.
2. The "unaccept" option and the option to leave a note when accepting are both fairly useless. If you want to revoke acceptance, then in practice you surely want to revert, and if you revert you ought to leave an edit summary. If you accept an edit, the reason had better be plain: "no problems here". Both of these should be removed.
3. My major concern has always been that PC will be used to own articles or lock particular editors or opinions out of them. I was pleased to find that I didn't encounter this on any article I was watching. However, I have seen a great number of naive proposals to use Pending Changes as a quality control, or to revoke reviewer permission for reasons unrelated to reviewing or vandalism. Any such practices could become soft censorship over time, so any serious proposal to continue pending changes needs to stomp hard on these urges.
4. I haven't seen any case being made for the usefulness of Pending Changes level 2, and it runs a much greater risk of enabling article ownership. Unless there is a very good reason out there that hasn't been articulated, I think Level 2 ought not to be approved.
5. Of course, I also oppose deploying Level 1 protection, though that doesn't stop me from having the opinions above. Simply put, there is a case to be made for using Pending Changes on unwatched BLPs, though nobody is seriously pursuing that option. In all other cases, it offers only illusory advantages over semiprotection. Semiprotection prevents vandalism and constructive edits equally, and administrators understand this and avoid using it where it is not needed. Pending Changes does not prevent vandalism; it only makes it somewhat unlikely to be seen by the general readership. In exchange for that, it makes reverting (accepted) vandalism a much more arduous and failure-prone exercise for the very same general readership.

More disjointed ramblings later if I happen to think of them. — Gavia immer (talk) 05:47, 17 August 2010 (UTC)

• I agree that the UI is seriously unintuitive and needs to be rethought from first principles. Nevertheless, I support the current limited practice of Level 1 protection as an alternative to semi-protection. It's easy for us editors to forget that passive readers of Wikipedia outnumber us more than 100-fold. This trial has protected those readers from the lies, obscenities and just plain bad writing that would plague prominent pages if they were unprotected, while allowing good-faith anonymous edits with minimal delay. This can only be good for both Wikipedia's reputation and the size of its editorship. – Smyth\^talk 10:10, 17 August 2010 (UTC)
• Support - Would like to see it speeded up so does not take as long to see the difs. Codf1977 (talk) 15:59, 17 August 2010 (UTC)
• I would not oppose, but I would not support abandoning semi protection either. Whether or not the approval system is changed, I generally try to avoid approving any edits that don't appear good to me, rather than relying on whether it is blatant vandalism or not. Had a bit of trouble figuring out how to fix up a mistake I once made on this front, but I worked it out eventually. I also noticed speed issues with diffs loading, but that seems to have improved. Finally, I think it's a mistake to assume that vandalism is always reverted quickly. Ncmvocalist (talk) 18:02, 17 August 2010 (UTC)
• I support the continuation of flagged protection.

• To some extent the trial was too short, since there are clearly still a number of issues that need to be resolved like the speed, UI etc; and editors and admins alike are still just getting used to the system like how to review (when to accept etc) and when to request or grant/use flagged protection. In particularly we need a way to deal with seemingly good faith but poor edits, perhaps some sort of reject with comments option.
• Of course it's also something that vandals are getting used to, and we don't really know how they will respond (for example it's clearly possible one of the reasons we still get a lot of vandalism is because vandals are unfamiliar with PC so see they can edit an article and vandalise not really understanding few are going to see it if it isn't approved and while there's always likely to be a level of this, it may drop as people get more familiar with PC).
• I do think it's clear that it isn't always a good alternative to semi-protection and I think Jimbo Wales' comment a while back that we could open the main page up to editing is never going to happen.
• So all in all I wouldn't mind if the trial is continued, perhaps in an expand form. In particular, I would like to see more wide use of flagged protection in BLPs if not used on all unwatched BLPs then with a very low threshold for acceptance for BLPs (e.g. only one problematic edit which lasts for say at least 1 hour is enough to use flagged protection rather then requiring ongoing problems). As I've already said, I'm not suggesting semi-protection should be abandoned and this applies to BLPs as well. Some may considered widespread use of semi-protection on BLPs better then PC, but from my experience with discussions on this, it seems unlikely that will happen so if that's more likely with PC, why not?
• Note that I'm also not opposed to the implemention of PC on a non trial basis since IMHO we've seen enough to know it is a useful tool that isn't going to destroy wikipedia.
• Also if PC is going to be turned off in a month, either we have to make a decision before then or it should be continued until a decision is reached. It IMHO would be a silly waste of effort to turn off PC only to turn it on a few weeks later although at the same time it would be inappropriate for PC to continue just because supporters continue to hold up any failure to achieve consensus to either continue the trial or accept PC.
• (BTW, for all those comments on the German wikipedia and citizendium, the vast majority of users and contributors to the English wikipedia are almost definitely not familiar with either and therefore have no opinions on us following them. In fact I only actually see one comment on the German wikipedia and one on citizendium here anyway.)
• P.S. I should mention despite some initial interest I actually barely used PC myself including reviewing etc so I don't think I should be considered the 'converted'
• P.P.S. While the timing of the trial may not have been the best, it's IMHO offensive to suggest the developers somehow timed this specifically so it was the end of the school year in the US or whatever. Anyone following the protracted development that went into it would know clearly that was just an accident. Also in terms of why the trial was so short, AFAIK this was primarily because of detractors who were afraid that wikipedia wasn't going to survive the trial so a short trial was chosen to try an allay their concerns.

Nil Einne (talk) 18:57, 17 August 2010 (UTC)

A small aside on the subject of German Wikipedia:

I am not sure what the intended criticism of German WP is in this case.

German WP does insist that a comment be provided with every edit, but so do a few other projects, like Polish and Georgian. Regardless, a "comment" can be as simple as a single blank.

Varlaam (talk) 02:20, 19 August 2010 (UTC)

I'm not sure whether you were addressing me or speaking general. But for clarification, I have no views or for that matter little knowledge of how the German wikipedia works other then an understanding they have had something similar to pending changes for a while now and therefore are often an example, either of criticism or support for such a system. I was partially address this comment "It also drives off many would-be contributers who think we're going the way of the german wikipedia" and another one on citizendium. My point is that whatever you think of the German system or citizendium, I'm quite sure few people here on en.w really care that much about what they do and most people particularly non German speaking non regular contributors are almost definitely don't think we're trying to follow them or whatever. They may dislike what we're doing but they're not going to think, 'oh great, they're going the way of the German wikipedia/citizendium/whatever'. SO while they may be useful for comparison purposes, I'm quite sceptical of any claims that many people actually think we're following them. Nil Einne (talk) 14:33, 19 August 2010 (UTC)

• I support the continuation of pending changes. There was a lot of good-faith edits made by IPs during the trial, as well as keeping vandalism out of public view, which is a plus for readers. ~NSD (✉ • ✐) 20:36, 17 August 2010 (UTC)

• There were also a lot of reviewers making, frankly, stupid decisions on accepting vandalism. If this is continued, we should make the reviewer right more strict and less of a giveaway. Solid guidelines on what is OK to accept would also help. Still, I'm against it, as I noted way above. —fetch·comms 22:08, 17 August 2010 (UTC)

• Not very useful My experience with pending changes was with dealing with an edit war with some IPs on the article Highschool of the Dead. Many IPs were adding certain genres despite not giving any reliable sources to back up their edits along with changing the air dates of the episodes despite that they contradict the source given for the air dates. I had requested special protection, but the article was placed under pending changes. To say the least, it did not stop the edit war at all. Eventually, we had to add a note about adding new genres in order to discourage editors from adding genres, which didn't help, and to keep "Reviewers" form automatically accepting the pending edits. All in all, it was a complete failure. —Farix (t | c) 22:39, 17 August 2010 (UTC)
  • For example, I've already had to revert two attempts today to include a genre category by a particular IP which didn't provide a reliable source. Both edits by the IP were automatically accepted by a reviewer without even looking at the ongoing issue. I when ahead and unaccepted the last edit as it was clearly inapproriate. If editors are going to accept pending changes without doing some basic investigating over the validity of the change, then pending changes simply won't work. —Farix (t | c) 18:48, 18 August 2010 (UTC)
• I believe the problems far outweigh any benefit from it in its the current form.
  1. In the best case scenarios, for example, Microsoft, all it basically did was hide vandalism for an hour or two and maybe discourage vandalism in general. However, it may have discouraged good edits as well, we don't really know. (Update 8/30: It's back on semi now... wish there was a middle ground between semi and none that existed for articles like that, but I guess PC just isn't it)
  2. It didn't meet its goal of preventing "certain kinds of vandalism or inappropriate changes" because stuff was simply "accepted" too quickly, nearly instant, and sometimes even outright vandalism got through. A lot of this was due to the unclear reviewer guidelines. It also likely led to make people to not look at accepted edits, thinking they were actually good when they often were not.
  3. It might work in its current form on other wikis with different cultures. I just don't see the reviewer part working out; as said en doesn't handle "bit bureaucracy" well. However, in its current form but without the reviewing part it might have some benefit on en.

Ryan Norton 09:21, 18 August 2010 (UTC)

Could you (or others) provide some diffs of outright vandalism that was accepted? Ocaasi (talk) 04:10, 18 August 2010 (UTC)

• What's the point in imposing more bureaucracy and the increase in workload? If registering an account is the biggest hurdle to be able to start editing, then I'd say we leave out edits from IP-only altogether. I know that's an issue that's been discussed over and over again [there's even an Oukaze on that, right?] but in my field of play IP-only editors are the ONLY vandals. Qwrk (talk) 16:32, 18 August 2010 (UTC)

IP-users often correct spelling in the more esoteric pages (e.g.) and are not all vandals or idiots (which is common). Has anyone ever done a thorough study though on it? --Squidonius (talk) 18:58, 18 August 2010 (UTC)

Then your field of play is very narrow. I've seen countless registered vandals. Also, IP editing is a Foundation issue, not one en.wiki can take up. —Jeremy ^{(v^_^v Carl Johnson)} 19:02, 18 August 2010 (UTC)

I'm aware this IP-only issue is very much one of the Basic Commandments of Wikipedia, and indeed my 'niche' is just the small specialisation on mountaineering and the higher ranges, and central Asia and Tibetan subjects. Having said that, I wanted to coin my 2 cents in this discussion because from what I experienced it's more of a hassle and a burden than a solution to an intrinsic problem we're facing. Qwrk (talk) 21:08, 18 August 2010 (UTC)

• Comment I'm not sure if I acted on a single edit. This was both because I was unsure if I should accept good faith poorly-phrased or borderline-dubious edits and because there seemed to be many reviewers checking pages. By the time I made up my mind on a post, another reviewer had acted and it would have to be relatively obvious reason for me to disapprove an approved edit. An above comment made a good point that the lack of constructive edit summaries muddies the RVV process. Additionally, the number of reviewers to pages in the trial skews the effectiveness of PCs, causing inactive reviewers like me and over-inflating the effectiveness. I can see PC working for BLPs and other places where vandalism may be harmful, but I certainly don't support widespread adoption and I question how effective it is an alternative to page semi-protection since vandals can still edit just to annoy the reviewers that have to then dismiss the edits. Finally, I will endorse Anomie's script which certainly helped point out pages needing review. —Ost (talk) 18:52, 18 August 2010 (UTC)
• Support, but it needs to be used correctly. First, I think the list near the top of this page, of improvements that should be made, is a good one. My experience has been that it is kludgier and slower than semi-protection, and therefore, inferior to semi-protection on pages where semi is appropriate. On the other hand, we have plenty of pages where there are not that many watchers, where there are some good-quality IP edits, and where there is also IP vandalism, but not enough vandalism for semi-protection to be justified. Those are the pages where PC would be of value. For those pages, PC is a significant improvement over no protection at all. That's where it should be used, but it largely wasn't in this trial. On the other hand, for pages where semi-protection is reasonable, it should always be used in preference to PC. --Tryptofish (talk) 19:43, 18 August 2010 (UTC)
  • Agree with both Tryptofish above and Malik Shabazz below: use semi-protection for frequently edited pages and Pending Changes (PC) for rarely edited pages and especially pages which are barely watched. I gave up reviewing after an initial bout of enthusiasm mainly because I was seeing the same high traffic pages all the time, and soon realised the editors more familiar with those pages could handle it better than I. Also I second the request to change this feedback into an RFC. -84user (talk) 20:26, 19 August 2010 (UTC)
• Oppose its use as a substitute for semi-protection on high-profile, frequently vandalized articles; support its use by default on all BLPs. On articles such as Malcolm X and Israel, the substitution of pending changes for semi-protection has required editors to revert large numbers of vandalism edits. Semi-protection saved a lot of work by preventing those edits altogether. — Malik Shabazz ^Talk/_Stalk 20:10, 18 August 2010 (UTC)
• I think that for the most part, this has just been a hassle. Using it on high-traffic pages gives us more trouble than good, because of the high volume of edits that would need to be reviewed. However, using it on low-traffic pages where vandalism goes unnoticed for a long time would be preferable; pages that occasionally get some vandalism that isn't noticed for a while, which do not get semi-protection, seem as though they would be better. However, I still don't think that pending changes should be used at all. Even though there are good reasons for using it in certain spots, such as what I just mentioned, I just don't like the whole idea of it. It seems wrong. ~~ Hi878 ^{(Come shout at me!)} 20:10, 18 August 2010 (UTC)
• Technically, this thing seems to have worked. However, effectively it has failed. The problem is that we are not clear what we want to do with it.

1. If you use it to cover large numbers of articles (or small number of heavily edited ones) you'll lots of edits to review and the quality of the review will decrease. That's fine if you want to as a tool to decrease the visibility of simple vandalism. But it is worth the effort for that? IS simple vandalism such a big problem? Isn't it reverted pretty quickly anyway? Conclusion: small gain, lots of effort, perhaps many new editors discouraged.
2. The other possible use is to target a small number of articles (or a large number that get fewer edits) and ask people to do quality reviews. Target it on the articles where bad edits might not get spotted, and there visibility for a short time is a real problem. That is use it ONLY for underwatched BLPs. Less edits to review, more care gets taken, less new editors are affected, and we help what we know to be a real problem.

My point is that you can't simultaneously use this for 1 and 2. They are contradictory strategies. I'd strongly suggest #2 is more worthwhile. I proposed something similar before at Wikipedia:Targeted Flagging - something like that might be worth people looking at again now.--Scott Mac 18:48, 18 August 2010 (UTC)

Or on popular pages you just let the people with the page on watch to review the edits - they will still get reviewed pretty quickly. -- Eraserhead1 <talk> 18:59, 18 August 2010 (UTC)

No, you can do one or the other. If it is used on popular pages, then you'll have lots of reviewers, and people won't distinguish between "popular" and "sensitive" pages. You can either use this as a mass took, for screening out obvious stuff, or you can use it for protecting sensitive (low traffic) pages where people are told NEVER to approve an edit without actually reading the article, and checking the sourcing. Try to have it both ways, you fail.--Scott Mac 19:20, 18 August 2010 (UTC)

As someone who regularly edits articles within various scientific and international areas of interest, I find the premise of purposely singling out low traffic articles objectionable. The idea that someone out there might be discouraged from anonymously contributing specialized knowledge to articles like MON 863, Cry3Bb1, Hailong Market, Haidian Christian Church, Solar cycle 24, Hexatriacontanoic acid, Aluminium acetotartrate, Camp Rustamiyah, Vimbayi Kajese, mu Opioid receptor, Yangonin, Flavokavain B, Dihydromethysticin, Salvadora persica, and FKBP1B disturbs me. Moreover, if reviewers are encouraged to evaluate content on any basis of quality, then we can say goodbye to many of our anonymous contributors that speak English as a second language, and consequently, many of our international articles that require the knowledge of a local. Similarly, if reviewers are encouraged to evaluate content on the basis of whether or not it is factual, then we are going to see gross POV-based decisions become commonplace. The fewer people that view an article, the easier it would be for a reviewer to veto or extinguish an unpopular viewpoint.   — C M B J   07:54, 20 August 2010 (UTC)

Personally, I like the second idea. The first is most certainly not worth it; the seocnd is the better, although I still don't think that pending changes should be kept at all... ~~ Hi878 ^{(Come shout at me!)} 20:05, 18 August 2010 (UTC)

• • ^...>Thumbs up. :-) I have seen very few vandals on important articles since the PC trial has been in effect. Whatever it is doing, keep it up. And for those of you complaining about the workload of vandals, DEAL WITH IT! You realize vandals are the reason that this site is rarely used in schools anywmore, correct? If you keep the vandals off, Wikipedia has a better rep and is more trustworthy. Then, it might have a chance of regaining all the user schools it lost due to vandals. Being a vandal is, of course, a bad thing. However, doing nothing to stop it is just as bad. Don't be lazy, reviewers/admins. This seems to work to a degree, so CONTINUE TO USE IT! If any fixes can be made to it so it works more efficiently, install those measures too. Just do whatever it takes to earn this site's formerly clean reputation back, 'cause it will benefit EVERYONE. I have spoken. Wingdude88 out! --The Wing Dude, Musical Extraordinaire (talk) 04:43, 19 August 2010 (UTC)

• The problem is not the workload, but the southward effect that this would have on all IP contributions, beneficial and baneful. It's safe to say that Wikipedia's success has mainly been tied to instant gratification (i.e. edit an article, see your edit immediately). It is also for this reason that projects embracing the opposite have stagnated (i.e. Citizendium). If a beneficial IP finds that every edit he makes has to go through a bozo-filter before it shows up in the article, the likelihood of them editing is going to be decreased. Also, as has been pointed out FraggedRevisions can be a severe hindrance if the wrong people staff it - those who have preconceived notions, those who view it as "quality control", and those forced to take the tools and use them. Lastly, unlike most of the other antivandalism measures the Foundation has used FraggedRevs is the least effective due primarily to the press and the hype. A vandal will either attack nonrev'd articles or, worse, attain the userright and cause mayhem. —Jeremy ^{(v^_^v Carl Johnson)} 20:37, 19 August 2010 (UTC)

• Correct me if I am mistaken, but don't editors editing PC articles get to see their changes on their screen immediately? Ideally, the review is completed within a few minutes, and then everyone else sees it, too. This of course assumes beneficial edits, not vandalism. CycloneGU (talk) 13:28, 20 August 2010 (UTC)

• Instant gratification doesn't work if it's based on a fundamental lie. Just because it shows up for them does not mean that it will stay in the article, and for IPs making obviously-beneficial edits with a few stylistic errors in them, this can be a major issue. When - not if - an IP's edit gets rejected because he (in the process of expanding an article) misspelled "benign" or a similar highschool or college word, then the façade of instant gratification vanishes and the IP gets jaded by the experience. —Jeremy ^{(v^_^v Carl Johnson)} 19:31, 20 August 2010 (UTC)

Arbitrary Break 2

• Keep the feature -- on two pages where I saw it used, Deepwater Horizon oil spill‎ and Stanley A. McChrystal‎, vandalism dropped to very low levels. The feature doesn't merely make vandalism invisible, it discourages repeat offenses per WP:DENY because the vandal doesn't even get his 5 minutes of hyuks before a revert. In other cases it allowed experienced editors to address markup mistakes before they were displayed. It's better than semi-protection because it's less work to review a change than to copy it from the talk page to the right spot in the article. I think that performance could/should be improved by caching the diff of a non-autoaccepted edit. Thundermaker (talk) 20:22, 18 August 2010 (UTC)

For some vandals, wasting volunteer time gives them their jollies. —Jeremy ^{(v^_^v Carl Johnson)} 21:20, 18 August 2010 (UTC)

As a reviewer, our time is not wasted to such efforts but rather well spent. My76Strat 02:56, 19 August 2010 (UTC)

Then you are the kind of person who gives the vandals I mentioned immediately above their jollies. —Jeremy ^{(v^_^v Carl Johnson)} 19:21, 20 August 2010 (UTC)

Reverting any vandalism is a waste of volunteer time, IMO. Sometiems I spend half my edits a day reverting vandalism, but that isn't going to change, with or without PC. - BilCat (talk) 03:42, 19 August 2010 (UTC)

• Oppose the feature. Of the times I've seen it used, it fails to stop vandalism. -FASTILY ^(TALK) 04:32, 19 August 2010 (UTC)
• I support eventual implementation of Pending Changes, but I have a question: I understand some metrics were prepared for this trial. Is it possible for a summary of the results be published? It's a bit unwieldy to navigate to giant tables of full stats. Perhaps this will reveal some trends that we have not considered before. —Arsonal (talk + contribs)— 09:38, 19 August 2010 (UTC)
• Oppose - I was open-minded about how the trial would go, but now I've seen pending changes in use, I think we're better off with the established system. The problem with pending changes is that in my opinion, a vandalism check is not sufficient grounds to give credence to an edit by deeming it "Accepted" by a "Wikipedia Reviewer". Even if not vandalism, an edit can be potentially misleading and harmful. Better to let those tending the article monitor edits as usual, than introduce potential to mislead both the general reader and the editor who made the change by deeming it "Accepted" even though someone who knows better may still challenge or revert it. PL290 (talk) 12:33, 19 August 2010 (UTC)

That doesn't make any sense. It's not as if an accepted edit has to be treated differently than any other edit. It can be reverted as usual, and anyone 'monitoring the page' can see it and change it as needed. ♫ Melodia Chaconne ♫ (talk) 13:58, 19 August 2010 (UTC)

I think his point is that having a notice saying "THIS IS THE *ACCEPTED* VERSION" along the top will tend to lead the casual reader to think that it's been peer-reviewed, or something like that, so their likely to give anything they read in it more credence, thus potentially increasing the damage done by sneaky inaccuracies.☻☻☻Sithman VIII !!☻☻☻ 15:05, 19 August 2010 (UTC)

• Support on all BLP (with no exceptions), and on general topic articles with a long history of back and forth semi-protect/un-protect. DVdm (talk) 14:35, 19 August 2010 (UTC)
• Using it on highly visible, frequently-edited articles was a mistake and I think that put a lot of people (including me for a while) off the idea. However, using it on slightly quieter pages that have significant vandalism but some constructive edits from IPs/new editors seems to have worked quite well in many cases. I don't think it prevents vandalism, but it prevents it from being seen by the vast majority of readers. I think it's worked reasonably well on articles such as Pixie Lott and, to some extent, Deepwater Horizon oil spill, but about a dozen articles were so swamped with vandalism after the feature was introduced that PC was taken off within hours in favour of semi-protection. 15:43, 19 August 2010 (UTC)
• Support, especially on BLPs. The little notice that say that the edits will not go 'live' really helps - vandals know that their crap wont be accepted. If there isn't sufficient support for wider adoption, I would like this capability to still be available but constrained by policy to BLPs and other specific cases where indefinite full protection would otherwise be necessary. John Vandenberg ^(chat) 15:46, 19 August 2010 (UTC)

• Those "other specific cases" were attempted and had to be rejected as test subjects because the vandalism overloaded the FR. —Jeremy ^{(v^_^v Carl Johnson)} 21:38, 19 August 2010 (UTC)

• Support. I don't think it always was used in the most effective way during the trial - it's at it's best for for lightly watched pages where vandalism will remain for long periods unreverted. For these pages, it is of great utility. I agree with the critics that on highly active pages it does little to stem vandalism. 138.162.0.44 (talk) 16:08, 19 August 2010 (UTC)
• Support. It still needs some technical work, in my opinion - viewing difs and reverting/accepting still lags in my browser, compared to other pages. There still needs to be a serious discussion on when to use it: lightly watched BLPs? probably. Heavily watched and edited articles? maybe, but only because it does seem to discourage vandals who like to have their few minutes of glory. First Light (talk) 16:35, 19 August 2010 (UTC)
• Support and at any rate extend the trial for another month or two to give time to review impact at the restart of school year when vandalism is really a problem. Motmit (talk) 17:20, 19 August 2010 (UTC)
• Conditional support - After my experiences using it, I could really only support it if it were symmetrical. That is, there need to be a reject feature that allows addition of a comment given the reason for the rejection. Requiring use of undo or rollback leads to ambiguity, because essentially the edit is approved, then reverted. Also, when there are multiple pending edits, they need to be able to be rejected invdividually, not rolled back as a group. If those features were implemented, it would have my full support. Yworo (talk) 18:49, 19 August 2010 (UTC)
• Oppose wide use of this feature. In my observations, the PC feature works well ONLY for high-traffic articles that are watched by a significant number of users. Even there it does not always work out well - often it turns out that most edits by non-autoconfirmed users are either plain vandalism or additions of unverified info and thus have to be reverted; ordinary semi-protection works better in such cases. The biggest problem is that a wide use of the PC feature (e.g. adding it to all BLPs) would require too much extra work on the part of the regular users who are already overloaded and are decreasing in number. Basically it would create a new HUGE area of backlog, at the time when already existing backlogs all over the project are growing and threaten to become unmanageable. Something like that might have worked when the project was still in a rapid expansion phase, but it does not work now, when the project is in a slow and possibly accelerating decline phase in terms of the number of regular participants. A wider use of permanent or long-term semi-protection is a much more viable option under the circumstances. Nsk92 (talk) 19:31, 19 August 2010 (UTC)
• Support - My major issues were technical. The first one was that the "Deny" button (forget the name) was a bit confusing at first. I thought I clicked it if It was a bad change, but you use it to unaccept an already reviewed change. Also, review conflicts did happen, so maybe the first user to review gets a 1 minute lock on reviewing? Something like that would help. Some code work and I think it could work. Allmightyduck  What did I do wrong? 21:32, 19 August 2010 (UTC) 12:05 PM
• Support - while it didn't defer most of the vandalism it did work in getting rid of a fraction of the vandalism especially on high risk articles, I think it should definitely be used by default on BLPs since many editors have been subject to criticism over libelous or otherwise controversial edits on topics pertaining to this touchy area. Heads of government or state and other people of notability amongst the community should also have pending changes enabled by default since articles like George W. Bush (where vandalism peaked post-presidency) are always big targets. I think Pending Changes worked effectively. Fridae'§Doom | Spare your time? 23:05, 19 August 2010 (UTC)

• Using it on particularly-liked or -disliked politicians would end up overloading the FR, as those articles are subject to heavy amounts of editing. You think Barack Obama and Bush weren't already tried? —Jeremy ^{(v^_^v Carl Johnson)} 19:36, 20 August 2010 (UTC)

• Supporting because it is helpful but closer to being neutral Even though it is to slow it still worked pretty well. And it is a great idea. I'd say just a few tweaks would make it work better. Mr. R00t ^Talk 23:33, 19 August 2010 (UTC)
• Support It has proved to be a useful alternative to semi-protection. There are some articles for which it is not useful, due to traffic. But in those cases administrators will become used to exercising the feature properly.--Mkativerata (talk) 00:16, 20 August 2010 (UTC)
• This is a discussion only and not a vote comment - Off2riorob (talk) 01:06, 20 August 2010 (UTC)
  • Read the top, it asks for a consensus which is generally determined by people expressing their support or opposition to an idea or system. If it were a discussion, they would not ask for a consensus over the use of a policy. Mkdw^talk 23:38, 21 August 2010 (UTC)
• I think its a process that has merit but one that needs more thought on implementation methods, what I found was that after the first couple of weeks I lost interest in being an active reviewer because either I didnt know the subject well enough to make an instant decision on the edit(except in the obvious "T 'n A" vandilism) or I conflicted with other editors anyway rather than as a tool for High profile articles I think it would probably work more effectivey with the lower profile articles where there's some delay between the edit and someone reviewing it off a watchlist. At this point in time I'm tending to ignore it altogether and reverting to just reviewing edit via my watchlist as I did before the trial started. Gnangarra 02:16, 20 August 2010 (UTC)
  • Obviously if you are happier looking at your watchlist or whatever then do that, but I have a couple comments. First, you should not have to be a subject expert. The point here is to protect against obvious vandalism, not to make sure the article is totally correct. Sometimes I do make sure the article is correct because I want to, but that is a separate step and you don't have to do that before clicking "accept". I think it would be very harmful to implement a delay, because for legitimate editors we really don't want people to notice this. The point the PC-detractors make about this being an encyclopedia that anyone can edit is a really important one. I would say that if a delay proves to be necessary, we should just abandon PC instead. ErikHaugen (talk) 17:44, 20 August 2010 (UTC)

• In the pursuit of a vandalism-free encyclopedia where anyone can edit we cannot sacrifice article veracity. If anything, the comment above only serves as an argument against using FraggedRevs on articles about complex subjects. —Jeremy ^{(v^_^v Carl Johnson)} 19:43, 20 August 2010 (UTC)

That is a fair point. If the page is protected because of errors about complex subjects, then PC is probably the wrong tool for fighting that. In general, though, there is a balance between veracity and the ideal of anyone-can-edit; I think PC can be useful if the alternative is (semi-)protection, etc. ErikHaugen (talk) 20:33, 20 August 2010 (UTC)

• I quite like PC, but I do have to echo a few concerns above. the Accept/Unaccept buttons and comment box seemed quite pointless, I can't think of any times that the Unaccept button would be used, and the comment box should generally just be "looks good" or some such, since the edit summary should have already explained the change. The "Accepted Version" at the top of the page does imply that the page has been peer reviewed. Since the scope is currently to accept anything that isn't patent nonsense or vandalism, I think "No Pending Changes" would be more appropriate than "Accepted Version". On that note, I feel that there should be a very clear steer (based on some further discussion) as to whether we should be properly reviewing the edit or just checking for nonsense/vandalism per Scott Mac above. I see that some people are properly reviewing (myself included) and although it leads to a possible walled garden, the alternative is to basically push vandals into creating much more sneaky vandalism. -- WORMMЯOW  11:29, 20 August 2010 (UTC)

• Murphy's Law indicates that they'll create sneakier vandalism or otherwise defeat antivandalism measures with or without FR. Thus far, it hasn't been proven wrong. —Jeremy ^{(v^_^v Carl Johnson)} 19:49, 20 August 2010 (UTC)

• This edit-conflict nonsense has to stop soon!!! Together with the case-sensitivity of titles, there is no more uselessly frustrating and aggravating misuse of editors' time and patience. My reaction was "So?". I came back from a Wiki-break to find a message on my Talk Page that I'd been made a reviewer. I tried reviewing a few pieces, both from the general pool, and (later) when they were more focused on areas I'd edited, and, like the IP editor who doesn't see the results of his or her editing, I was confused, although not distressed, about what I had done, had not done, was supposed to have done, could have done and/or should not have done. It looked as if most of the things I tried to do, pass or review had already been done by someone else, although I did pass a couple of (what at least looked like) small, benign edits and stopped one or two minor vandalizations. Had the trial run longer, maybe I would have got the hang of it, but maybe I would have thought my time better spent elsewhere on Wikipedia (e.g. editing articles, fixing errors, formatting tables, researching details, answering Ref. Desk questions, learning more about how other parts of the system work). —— Shakescene (talk) 11:43, 20 August 2010 (UTC)
• Note on this discussion: On reading through this page, I noticed that all the comments left are by autoconfirmed users. Not a single comment from an IP. Got to ask the question. Do they really care?

I think most ips don't know this poll is happening. Many i.p.s are 'drive-by- editors, and though they may not care about this discussion, that doesn't mean they don't care about the ability to edit articles without having to go through an oversight procedure. It's up to us as regular editors to think about the effect of policy on users who might not be a part of the discussion. Ocaasi (talk) 11:52, 20 August 2010 (UTC)

• Oppose- I tried it and didn't particularly care for it. It was confusing, slow, and didn't seem to serve any kind of useful purpose. Reyk _YO! 14:01, 20 August 2010 (UTC)
• Indifferent to weak support for BLPs only. My ideal I think is still semiprotection for all BLPs - this struck me as somewhat slow and cumbersome. I do wonder if more generous use of semiprotection would dissuade some potential new editors, so I'd be happy with using Pending Changes on all BLPs as default, but I think it used up more time than it saved elsewhere. I'd support a trial of all BLPs under PC for next few months. Casliber (talk · contribs) 14:19, 20 August 2010 (UTC)
• Support I think the community should accept this as an excellent tool to stave off page protection. I do think editors need to be bludgeoned with the idea that only vandalism and sockpuppetry should be rejected, and that acceptance of contentious non-vandalism is productive use of review rights. BigK HeX (talk) 14:24, 20 August 2010 (UTC)

• What you said above begs the question: What about edit-warring on such articles? Is it a violation of CRASH policy to accept edits furthering an edit war, and would doing so make you as guilty of edit-warring as the actual edit-warriors? There's a rather major rub here, because both edit-warring and abetting the edit war would fall under disruption, I'd think. —Jeremy ^{(v^_^v Carl Johnson)} 20:43, 20 August 2010 (UTC)

• Reminder: this is not a vote. Merely a discussion. CycloneGU (talk) 14:40, 20 August 2010 (UTC)
  • Actually no. If you read the top it asks for a consensus. For that to occur, this 'discussion' must show whether people support or oppose the system, and people are simply using the Wikipedia system 'support' / 'oppose' that is used from everything from WP:FAR to WP:RfA. Mkdw^talk 23:36, 21 August 2010 (UTC)
• As earlier I read that this feature is an alternative to semi-protection of a page, and I have experienced most of this feature can be used as an alternative to semi-protection. Moreover This feature is more useful for unforced-involuntary-automatic-standardization of edit/addition of content. I like it!!!.--Ranjithsutari (talk) 17:35, 20 August 2010 (UTC)

• Using FraggedRevs as quality control is a variation of soft censorship and highly inappropriate. I'm not the first one to have brought this up. —Jeremy ^{(v^_^v Carl Johnson)} 20:39, 20 August 2010 (UTC)

• Feedback about slow and useless comment boxes/unaccept buttons is spot on, but other than that I think this is going pretty well. The instructions seem quite byzantine, but as a practical matter it's pretty simple and I almost never have to deal with multiple edits. One nit is that it says to discern the reason for the protection, but it is usually pretty hard to do this; ie, checking the discussion page usually doesn't help with this. So I would say to try to remove this from the directions. Just check for obvious vandalism. If sockpuppetry is the only problem, this is the wrong tool. ErikHaugen (talk) 17:40, 20 August 2010 (UTC)
• Support Those of us not Reviewers are already doing this. I have 5123 pages on my watchlist as of today: once in a while (a month? three months?) I view the diff on my most recent edit and vet the intervening edits in a group. Vandalism you can't immediately see must be a dull game.--Wetman (talk) 21:10, 20 August 2010 (UTC)

• Speak for yourself and not others. —Jeremy ^{(v^_^v Carl Johnson)} 21:12, 20 August 2010 (UTC)

• Support. Despite its complexities and oddities, it's a great intermediate before protection, and definitely an idea that should be continued. bibliomaniac15 22:05, 20 August 2010 (UTC)
• Oppose Will the technical issues (slow, etc.) really be resolved? Will clearer reviewing guidelines be written soon? If they are, someone please show me two statistics: amount of vandalism compared to the same page using semiprot for the same amount of time, and the amount of time saved by reviewing edits rather than just rollbacking them. Let's get this straight: there is significant opposition to using this widely, so it is used on heavily viewed pages. Unreviewed edits must be reverted anyway. So, there's no time-saving involved. People will still vandalize the same articles, and think it's funny. Overall, pending changes is just not effective or appropriate at this time. —fetch·comms 23:43, 20 August 2010 (UTC)
• Graphs

  

  Logarithmic approval rates.

  

  Linear approval rates

  A lot of this "debate" is being done on anecdotal experience. Here are some graphs. User A1 (talk) 23:47, 20 August 2010 (UTC)

We need more graphs, and then need to work out which ones are useful. I started with these, and believe that the magnitudes are concerning. We are adding complexity to a lot of apparently low-traffic articles -- why? Its possible I have made a mistake (I am currently quite tired), but perhaps not. User A1 (talk) 23:55, 20 August 2010 (UTC)

Also it appears that the local vandalism ratio is quite constant, except in the very end, suggesting that vandalistic edits are not actually more problematic than any other article, except in the last 200-300 articles in the plot; which is about 20% of what we have currently marked for pending change protection. This seems like we are overusing the tool User A1 (talk)

• Support the feature. Only a few of my 5600 watched articles have the Pending feature, mainly because I unwatched the hot ones. Where pending changes arose, I was confused at first but after a couple tries could handle it. Wouldn't want it to be applied to the majority of articles or to the hottest articles that require firmer handling, but for most semi- protected articles it would be a good alternative. Jim.henderson (talk) 00:05, 21 August 2010 (UTC)
• Oppose. It is designed to allow IPs to edit semi-protected articles, but as IP's are generally unregistered, they may have no idea what it means, or whether or not they have done everything correctly. It's fine if you are regularly wiki-active, but for first time users it may be quite baffling. Furthermore, the entire thing just seems tedious. Vandalism is easily reverted without the feature and the review process must be as (if not more) time-consuming as patrolling recent changes. I, Englishman^{Wouldst thou speak? • Handiwork} 00:23, 21 August 2010 (UTC)
• Support. Does not replace semi protection but definitely has a place and should be kept.Doc James (talk · contribs · email) 01:19, 21 August 2010 (UTC)
• Support (conditionally) - It does have its place, and has helped in quite a bit of places. However, I observed one major problem: It got applied much, much too liberally in many places. Articles which really did not need it were given the PC flag, and users who were retired for months were given the flag automatically. This needs to be addressed if it will get reenabled. (X! · talk)  · @195  ·  03:40, 21 August 2010 (UTC)

• I think its liberal application was part of the test. Any page could have been requested for the trial period, and it was granted much of the time. Heck, Bible and Barack Obama (the latter which I reviewed an edit on once but was beaten to reverting it) both got added to the queue, but those were reversed (quickly) as they are heavy targets evidently. CycloneGU (talk) 13:08, 21 August 2010 (UTC)

• Oppose. It takes manpower of experienced editors, and places additional roadblocks in the way of anonymous editors. I realize vandalism is a huge problem, but it isn't that hard for vandals to get autoconfirmed accounts. FluffyWhiteCat (talk) 04:14, 21 August 2010 (UTC)

• I am afraid I do not follow your reasoning. Patrolling recent changes also takes the manpower of experienced editors. Also, while vandals CAN register, they have to have a good activity before they will get the autoconfirmed flag. They can't just register and start vandalizing; we'll catch it immediately, PC or not. Further, what is the roadblock you speak of? Editors who previously could not edit some articles can now make good-faith edits that can be accepted by any member of the reviewing community; if the change is a good one, then it SAVES manpower on the talk page having to add it manually ourselves, and it's NOT an obstacle to the user who was able to add their bit to the article. CycloneGU (talk) 13:08, 21 August 2010 (UTC)

• Speaking from experience, Cyclone, no they don't. I see autocon-busters all the time; they spend their first ten edits tweaking their talk page or wikiGnoming on an article before they start spreading havoc. —Jeremy ^{(v^_^v Carl Johnson)} 19:30, 21 August 2010 (UTC)

• Point taken. However, the current guideline I remember reading is you have to have 75 edits - typically mainspace edits - before being granted the userright (if am I mistaken, correct me please). So a vandal spending ten edits on their page will contribute nothing to the edits required to qualify as a reviewer. Maybe we do need stricter standards for the role, I'll be first to admit that. The pending changes itself, however, is not an obstacle to good editors; only to bad. CycloneGU (talk) 23:01, 21 August 2010 (UTC)

• You said nothing about the reviewer userright - "Also, while vandals CAN register, they have to have a good activity before they will get the autoconfirmed flag." In any case, autocon-busters still render PC:L1 useless because they can bypass PC altogether, making it no better than semi-protection with regards to defeating determined sockpuppeteers (whom commonly create autocon-busters). —Jeremy ^{(v^_^v PC/SP is a show-trial!)} 22:09, 28 August 2010 (UTC)

• Comment. Can someone point out to examples of specific pages where the PC feature has worked well? I must admit that I have yet to find one. Many of the people expressing support for the feature in the comments above say that it could work well for pages that are lightly/rarely edited. I think this is a rather untested assumption which is likely incorrect. With rarely edited pages that very few or no editors have watchlisted, edits by IP's or registered but not autoconfirmed users are likely to stay unreviewed for a long time - days, weeks or even months. They can also easily get staggered and nested which will make it even harder to eventually untangle them. I would think that the PC feature could only work reasonably well for a relatively small number of pages - where a sufficiently large number of editors are watching them but the editing traffic is not so high as to make dealing with reviewing new edits difficult. Even for this middle category it is not clear to me how useful the feature really is. One such article, Logan Lerman, was on my watchlist when the PC feature was activated there. Yet, as far as I can tell, almost all IP edits there had to be reverted since then. I think there is an additional psychological effect that is at play here. Most of non-vandalism IP edits, on any articles, consist of adding unverified information. Without the PC feature, when I see such an edit, I do not always revert it - often I sort of let it slide based on AGF. However, with the PC feature, we are required to accept an edit which looks like a higher degree of endorsement. I personally have found it difficult to endorse such edits - so for PC articles I usually revert them as unsourced, so that they don't clog the unreviewed portion of the history log. I suspect that many other reviewers do the same. Nsk92 (talk) 05:53, 21 August 2010 (UTC)

I don't think I follow your points:

• "With rarely edited pages that very few or no editors have watchlisted, edits by IP's or registered but not autoconfirmed users are likely to stay unreviewed for a long time... They can also easily get staggered and nested which will make it even harder to eventually untangle them." Isn't that why PC would be useful, because it prevents unreviewed edits from just sitting there and getting tangled?
• "PC feature could only work reasonably well for a relatively small number of pages - where a sufficiently large number of editors are watching them but the editing traffic is not so high as to make dealing with reviewing new edits difficult." The balance only has to be in favor of edits/reviewers. Reviewing few high traffic pages or many low traffic pages should be about the same in terms of difficulty.
• "Most of non-vandalism IP edits, on any articles, consist of adding unverified information. Without the PC feature, when I see such an edit... I sort of let it slide based on AGF. However, with the PC feature, we are required to accept an edit which looks like a higher degree of endorsement." The badge of 'acceptance' has some weight, but unsourced BLP edits should be looked at with scrutiny to begin with, and I'm not sure assuming good faith is the driving motivation when working with BLP edits, in fact, it might be part of the problem. Ocaasi (talk) 09:05, 21 August 2010 (UTC)

• I don't see the situation where IP edits on a low traffic article sit unreviewed for weeks and months as beneficial. The IP editors would only get confused and frustrated by such a situation, and, after a bunch of unreviewed edits pile up, experienced editors will be discouraged from editing the article further and trying to untangle a pile of unreviewed edits. It is simpler to use regular semi-protection on a wider range of articles. This way people will not be confused and regular editors will not get saddled with a huge new area of backlog. Nsk92 (talk) 14:22, 21 August 2010 (UTC)

• Whatever configuration people settle on, the assumption is it would only work if the reviewer backlog clears quickly. In that case, edits won't pile up. So I agree what you described is a bad situation, but don't think anyone is proposing it. Ocaasi (talk) 14:56, 21 August 2010 (UTC)

Arbitrary Break 3

• Comment I think, as an anti-vandalism feature, pending changes was not terribly useful. Vandalism still has to be reverted. I think hopes of using it as a generic "less than semiprotection but still protection" feature were less than fulfilled - it was confusing to reviewers, and possibly confusing to IP editors as well. By and large, by the time we long-term semiprotect an article, the article is decently mature and there's not that much left for IP authors to contribute. I still see hope for using PC in the specific context of articles subject to low levels of vandalism, but where vandalism or a persistent canard would have negative effects beyond the norm (particular categories of BLPs, conspiracy theories, etc). Ray^Talk 09:07, 21 August 2010 (UTC)
• Oppose Increases the clutter of the history. Until we can filter vandalism out of the the history, this is a huge problem. I would prefer semiprotection. Also, it introduces the idea that we've "verified" the change when all we've done is verify that it is not nonsense. Nonsense is not what we are concerned about mainly because nonsense is obvious. It's things that appear true but aren't, or are true but violate other policies, that we are concerned about. Introducing more tracking of which edits are being truly reviewed and which ones are slipping through the cracks is important, but this doesn't do that. Plus, poor interface. II | (t - c) 17:57, 21 August 2010 (UTC)

"Verified?" Where does it introduce this word? A reviewed edit is merely "accepted". This tool works very well for Telephone and others which get a steady though not heavy stream of IP graffiti and rarely a substantial improvement. Yes, it will confuse those who haven't logged on. It's worth the cost. Option 3, a modest expansion from the current thousand to a few thousand articles while continuing to tinker with the workings, is appropriate. Jim.henderson (talk) 18:14, 21 August 2010 (UTC)

He's saying that accepting the edit gives the impression that it has been vetted and verified. Reread his comment. —Jeremy ^{(v^_^v Carl Johnson)} 19:28, 21 August 2010 (UTC)

• Support. In effect adds the options of quarter-protected and three-quarters protected to compliment semi and full protection. PhilKnight (talk) 18:29, 21 August 2010 (UTC)

• "Three-quarters" prot isn't likely to see use. "Quarter" prot is too ineffective to even be a "quarter" because it jams the history full of garbage and/or more serious material, such as BLP violations. —Jeremy ^{(v^_^v Carl Johnson)} 19:28, 21 August 2010 (UTC)

• Any content you add or accept into an article you are responsible for, legally. You might get mitigation because you didn't actually present it for acceptance, but you are the one accepting it so you have a duty of care to yourself to review it well. Of course it rarely, almost never comes to such extreme situations.Off2riorob (talk) 19:44, 21 August 2010 (UTC)

• That's not what I'm referring to. Even if the edit is reverted instead of accepted, the bum edit remains in the history (since we're obligated by the licenses to maintain a list of all authors), as will any other edit that a reviewer rejects. As a result, the history will be more difficult to browse through because of all the vandalism. —Jeremy ^{(v^_^v Carl Johnson)} 19:57, 21 August 2010 (UTC)

The author in the case of an accepted edit would be the unconfirmed user supported by the accepting reviewer. I haven't seen this you are referring to be an issue at articles I have worked that are pending protected. Off2riorob (talk) 20:08, 21 August 2010 (UTC)

Alright, then, you want Cliffsnotes: PENDING CHANGES CLOGS THE HISTORY WITH VANDALISM AND BLP VIOLATION EDITS. (I concede the authors point, but not the revision pollution one.) —Jeremy ^{(v^_^v Carl Johnson)} 20:21, 21 August 2010 (UTC)

Pending changes doesn't clog the history with anything of the sort. If there's that much vandalism you should be using semi-protection instead. That much is obvious from this trial. What PC is good for is preventing vandalism showing in articles which aren't subject to heavy editing and which wouldn't normally be semi-protected, where the vandalism would otherwise be completely unattended - in Google and visible to visitors. -- zzuuzz ^(talk) 20:51, 21 August 2010 (UTC)

Actually, it does, since all edits remain in the history. Even if the article sees only one bum edit every few days, those edits add up. —Jeremy ^{(v^_^v Carl Johnson)} 20:58, 21 August 2010 (UTC)

If they're not protected at all then the vandalism stays visible in the article instead. That's what adds up. -- zzuuzz ^(talk) 21:02, 21 August 2010 (UTC)

I couldn't have put it better myself. CycloneGU (talk) 23:03, 21 August 2010 (UTC)

Believe me when I say, chummer, that the objects in the history can be just as much concern as on the actual page. —Jeremy ^{(v^_^v Carl Johnson)} 03:14, 22 August 2010 (UTC)

• Support assuming the system is modifed so that you can choose to accept or unaccept (instead of it being set to 'unaccept' automatically) and unaccepting autoreverts the edit. Seems kind of pointless having to revert the edit anyway, it'd be better if the system did that. HalfShadow 20:25, 21 August 2010 (UTC)
• Support since I have been a supporter all along, my opinion has never changed, and this looks like it may turn into a head count after all with the opposers being more likely to vote. —Soap— 20:25, 21 August 2010 (UTC)
• Support while I feel that the feature was implemented too often in places where temporary / indefinite semi protections would have been far better, I generally like the system as a whole and it reduced vandalism while still maintaining the fundamental principal of a wiki. Mkdw^talk 23:29, 21 August 2010 (UTC)
• Oppose. This seems to make the editing process too complicated for all involved, especially since users still have to revert vandalism regardless of the pending change status. Additionally, as others mentioned, this will potentially drive off good users if they don't see their edits show up. Better to lock them out entirely with an explanation and send them to the talk page than saying that their edits are awaiting approval. SchuminWeb (Talk) 23:42, 21 August 2010 (UTC)
• Until we get software features to remove blatant vandalism edits from a page's history, I'd have to regretfully oppose further implementation until we can get something like that developed. As Jeske said, an article's history of a highly-vandalized article (like with my experience with the RuneScape article – one of the very first PC-protected articles in the trial) just becomes clogged with vandalism edits, making it near impossible to conveniently and reliably track recent good previous versions of such an article.

As I have also pointed to, I would like to see Pending Changes be implemented more as a pathway for a longterm semi-protected article to become unprotected and hence allow more people to edit. However, I don't think the rest of the community may be on the same wavelength as me, nor do I see much motivation for users to try and make any efforts to unprotect some longterm semi-protected articles. –MuZemike 00:40, 22 August 2010 (UTC)

• Though I have little personal experience with the Pending Changes process, not being a reviewer and not significantly looking at pages that it has effected in the trial, I do not think that it should be implemented further than the trial. It seems to me that, from the comments I have read, a main objection is that it does not help, as it either hinders edits too much or too little. The idea of which pages (high or low traffic) to use it on is also a question people have had about its future use. Again, I have no way of knowing any more than anyone else about it, but it seems that PC would not be useful, as seen in the two following points:

• If it were used on low-traffic pages, it would be likely that the people reviewing a page's edits would not really know much about the subject anyway, and so would not be able to make a good judgement as to whether the edit (barring very obvious vandalism) was reasonable or not.
• If it were used on high-traffic pages, incorrect edits would most likely be caught soon anyway, and be able to be corrected almost as easily, if not more easily.

Thus, I oppose the Pending Changes process. Layona1 (Talk) 04:09, 22 August 2010 (UTC)

• Support continuation as long as it should be re-iterated and made clear to reviewers that this is meant to fight vandalism and nonsense. I never understood this as a conflict/dispute-tool. Thus, I personally had no problem occasionally accepting edits on subjects I had no idea about, as long as it didn't say "wkfwgfcsfdn948fvhvj" or "motherfucker". I think the "accept"-button should be seen as the opposite of "revert vandalism"-button and be used as such. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 07:54, 22 August 2010 (UTC)
• Oppose continuation:

• Non-existent, or at best totally inadequate, protections against censorship, instead of ensuring that it is used for nothing more than vandalism protection
• Inadequate guidelines/process for choosing editors as reviewers, in order to prevent picking people who will abuse tool
• Waste of time and resources, with no clear benefit -- yet another layer of bureaucracy that will suck away community time
• Increased complexity
• Discourages new and anonymous users from editing, while doing almost nothing to prevent vandals
• Directly contradicts Wikipedia's mission of being an open encyclopedia that anyone can edit

--Jrtayloriv (talk) 17:28, 22 August 2010 (UTC)

• It actually encourages new and anonymous users by letting them edit articles that would otherwise be protected, so this works towards our mission. I do agree that censorship is a potential, but we just have to agree to have no tolerance for abuse of the reviewer power. —Arctic Gnome (talk • contribs) 21:05, 22 August 2010 (UTC)

• No, chummer, just like DRM it screws the beneficial and empowers the baneful. You need to think less "beneficial" anons and more "all" anons - even the trolls, even the drive-by vandals, even the wethers of Grawp, even the IP sockpuppets. Thinking like yours is the very same logical fallacy FraggedRevs of any implementation runs on, and it's so severe as to be insurmountable. —Jeremy ^{(v^_^v PC/SP is a show-trial!)} 18:42, 9 September 2010 (UTC)

• I conditionally support it if, and only if, we limit it to articles that would otherwise be semied and we come down hard against reviewers trying to use it for censorship. If those conditions are met, this tool encourages new editors by letting them edit sensitive pages without showing vandalism to the public. —Arctic Gnome (talk • contribs) 21:05, 22 August 2010 (UTC)
• Oppose This only increases clutter on the history page and creates more burdens for those watching articles. I personally see at least as many "good" IP (or redlink) edits as "bad", and see no problem with the old simple system of WYSIWYG. As I noted elsewhere, I support the KISS principle, which works just fine in this case. Crum375 (talk) 22:24, 22 August 2010 (UTC)
• Generally I like it as it calls attention to high-traffic or high-vandalism articles. If it were to show up on a large number of articles, though, it could become self-defeating. ←Baseball Bugs ^{What's up, Doc?} carrots→ 03:12, 23 August 2010 (UTC)
• Support in Principle It needs to be simplified a bit more and applied to a limited range of articles GainLine ♠ _♥ 12:01, 23 August 2010 (UTC)
• Simplify and keep system. I cannot ethically "approve" a revision I have no way of verifying the accuracy of, such as changes to sports-related articles. In particular, sports scores and statistics proved to be troublesome when I reviewed revisions for the Pending Changes trial (they vary widely among different Web sources). This causes rather inconsistent reviewing, with some approving a change because it is not obviously wrong and others undoing it because there is no source for the information. Perhaps a simple delayed publication scheme emphasizing "innocent until proven guilty" would work, implemented by bot approving all revisions, say, five minutes afterward if there are no subsequent changes, and discouraging reviewers from manually accepting or unaccepting revisions unless strictly necessary. This would also free up time for other work on Wikipedia. PleaseStand ^(talk) 14:22, 23 August 2010 (UTC)

• I actually found an Australia television show under Pending Changes as well and quetioned its inclusion. I agree that your sports scores example is another good example. My policy has been that if it's not sourced, it's not valid and should be reversed. If a source is provided, check the source; if it agrees, approve it. Sometimes I did my own research, too, and actually found the information; I can think of once this occurred and I approved the edit, then applied the source. Just my stance, though. CycloneGU (talk) 17:58, 23 August 2010 (UTC)

Unfortunately, that's the problem; everyone is acting based on their own stance instead of clear guidelines for approving. —Ost (talk) 17:39, 24 August 2010 (UTC)

In particular, the people who are using it to reject all unsourced edits are using it to apply an imagined policy. We do not normally reject unsourced edits unless they are challenged,or are unsourced negative BLP information, and a decision to change this to include all unsourced edits would require a very wide consensus indeed--even if only on BLPs, as most edits are entirely non-controversial. My understanding was that it would be used only to prevent clear vandalism or unsourced negative BLP edits. DGG ( talk ) 23:32, 24 August 2010 (UTC)

On that note, I did accept an edit that looked all right once and moments later had a talk page posting pointing out that the edit WASN'T all right. It was a mistake on my part, it seems, but what I accepted was not clear vandalism or negative BLP to me upon reading it. CycloneGU (talk) 00:30, 25 August 2010 (UTC)

• Oppose: I think a good summary of this whole trial is that it was a unsuccessful foray into well-meaning regulation of editor activity. Wikipedia will not long remain the "Free Encyclopedae" if more cumbersome regulations and policies are added to the system. Gniniv (talk) 11:06, 25 August 2010 (UTC)

Hmm, not a bad summary.. but maybe it would be more helpful if someone could conclude by summarizing both sides of the debate?? -- œ^™ 11:42, 25 August 2010 (UTC)

Larry Sanger has done that for us. —Jeremy ^{(v^_^v PC/SP is a show-trial!)} 21:03, 26 August 2010 (UTC)

• Get some statistics to show whether it is more effective that our prior methods. As I interpret the graphs shown above, there were many rejected edits on some but not all articles, but no indication of how many would have escaped our normal detection methods, which includes a rather sophisticated system of WP:edit filters. Nor is there any indication of what may have been missed that our prior methods would have caught. There's no way of making a reasonable decision on the basic of everyone's individual varying impressions, which for those who worked on these articles must in each case must have been based on a very small sample. DGG ( talk ) 13:18, 25 August 2010 (UTC)

Statistics seem largely irrelevant on such a small sample, the wheels did not drop off so perhaps it is just a simple question of, shall we now test it on what it was designed for, applying to all BLP articles. Off2riorob (talk) 14:33, 25 August 2010 (UTC)

I don't think there's support for a major expansion until at least the interface and policy issues are worked out. The 10k expansion seemed useful towards the end of better stats, even if it's still relatively small. Ocaasi (talk) 15:18, 25 August 2010 (UTC)

The more I think about it and see the discussion the more I start to support a full trial of all BLP articles. The trial was basically to see if the wheels dropped of and they didn't as so we should logically take the next step. Off2riorob (talk) 15:30, 25 August 2010 (UTC)

• Keep for use on certain categories of pages. It was useful on articles about given names and surnames. On these pages, a majority of edits are probably vandalism/vanity edits, but new users can make useful additions, so PC is better semi-protection. As a member of WP:WikiProject Anthroponymy I would support the use of PC on all such pages. Perhaps the same goes for BLPs. - Fayenatic (talk) 12:14, 26 August 2010 (UTC)

• Oppose Debatable whether it solved any real problems but clearly caused e.g. dealing with edit wars to be even more troublesome. Also agree about subtle vandalism slipping through. Argel1200 (talk) 01:27, 27 August 2010 (UTC)

• Support in principle. Haven't read all of these posts so am not totally clear WHO REVIEWS, but could the program detect some addition to an article with a specific WikiProject tag, which could then alert those members (or a volunteer member) of the project to review the content????????? Viva-Verdi (talk) 20:59, 28 August 2010 (UTC)

  Trust me when I say that such a bot would be annoying at best and disruptive at worst. Not everybody who has a vested interest in a particular article belongs to its associated WikiProject, and not everybody in the associated WikiProject has a vested interest in that particular article. —Jeremy ^{(v^_^v PC/SP is a show-trial!)} 22:03, 28 August 2010 (UTC)

  Gotta agree with Jeremy on that one. If I'm part of the "XYZ WikiProject" and an edit gets added five times daily by anon. users within the project, I don't want five talk page posts saying, "An edit has been made to this page within your WikiProject! Please consider reviewing the edit to determine its acceptance! Signed, XYZBot" Kinda annoying. CycloneGU (talk) 05:16, 29 August 2010 (UTC)

  A better but approach to targeting interested reviewers is the suggestion in #Feature Requests (what might make it better) that Special:OldReviewedPages should separate out those pages that are on the watchlists of a lot of reviewers. If it is on your watch list you will see it highlighted there and can deal with it. If it is not on your watchlist then it will still appear on Special:OldReviewedPages but it will be in a section at the bottom and you may decide that it is better to leave it to someone more familiar with the article.

  That said, the suggestion by Viva-Verdi does make me wonder if there is a way to involve wikiProjects. If there were a lot of pages with changes pending, as you would expect if the feature was expanded, it might make sense to enable the filtering of Special:OldReviewedPages. Perhaps make it put at the top of the list pages associated with wikiProjects of which you are a member. I wouldn't have thought that would be that easy, given the less-than systematic way that page and especially user association with wikiProject is recorded. But it may be doable with a bit of thought and it would be a useful improvement.

  Yaris678 (talk) 16:16, 3 September 2010 (UTC)

• Support with clarification and simplification. Accept should probably be renamed screened (or equivalent) to indicate the review is just a vandalism scan and the reviewer is not sanctifying the edit. Unaccept should be removed -- if the edit's no good, just revert it. Gerardw (talk) 19:38, 31 August 2010 (UTC)
• Support Increases the legitimacy of Wikipedia in the eye of our readers and thus will hopefully increase the number of people who decide to edit. If people are going to put in the effort to write good content for Wikipedia they will want to know that there is at least some protection of it.Doc James (talk · contribs · email) 04:29, 2 September 2010 (UTC)

  PC can actually backfire in that manner because not every reviewer is an expert on the subject matter. If a reviewer approves an edit that is later empirically shown false, Wikipedia will lose far more credibility than it would pre-PC. This is not rocket science. So long as people are able to edit Wikipedia, the goal of having an accurate or academically-legitimate encyclopedia is impossible. Pending Changes exacerbates that issue. —Jeremy ^{(v^_^v PC/SP is a show-trial!)} 04:51, 2 September 2010 (UTC)

• Conditional Oppose: Pending Changes is a great idea, but we should let non-account users create articles if PC was implemented. It's just that having both would be overkill to vandal screening.199.126.224.245 (talk) 03:29, 10 September 2010 (UTC)

Continue but scale back

While the straw poll outcome was a majority in favor of continuing pending changes, a significant minority (~33%) want to end the trial. As a compromise, I propose the following:

1. Roll back the current trial by removing pending changes protection from the pages that have it now, to be completed within 30 days.
2. After pending changes protection has been removed from all articles on which it is currently used, continue the trial in 3 month increments at a smaller scale to allow the developers time to make improvements, adjusting the scale of the trial at each increment, based on consensus. (100 articles to start with?)
3. Strictly limit the time a page is under pending changed protection to 1 week increments so that we can gain better experience with where the feature works and does not work, and allow the feature to be tried in other ways.
4. Ask the opposers to elaborate on what doesn't work, so that we may make improvements.

Discuss? Triona (talk) 06:48, 7 September 2010 (UTC)

The discussion has been had. I sincerely doubt you will get any points that are not listed in the "working summary" section above, which pretty much says it all. There are some issues that improvements (technical changes) can address (feature request section), but there are questions that no amount of technical trickery is going to help you with (mostly the community and workload section). These are all well thrashed out above. Statistical analyses might answer some of the open questions above, but who will do it, and how will we know that they have answered the questions correctly? These things can take months to analyse in any meaningful manner. My personal opinion is that implementing this will generate a significant number of disgruntled editors, not implementing it propagates the status quo. User A1 (talk) 15:18, 7 September 2010 (UTC)

The first step is to honor the original trial agreement, which limited the trial to two months. That's over. That trial needs to stop. Once that's done, it's time to figure out what to do next. If PC proponents won't honor the original agreement, what faith can be placed in subsequent agreements?—Kww(talk) 15:20, 7 September 2010 (UTC)

I wish we could come to a consensus on this. I see two obvious things: 1, a lot of issues were raised (see above); 2, a lot of people want to remove PC. So, why not keep it enabled but end its use until the issues have been fixed, and then just start a new trial with a better technical system? Even if 1/3 oppose might be seen by some as not enough to be "no consensus", why keep a trial going on indefinitely with no apparent purpose, as the issues haven't all been addressed yet? —fetch·comms 00:02, 8 September 2010 (UTC)

I'm in support of PC but I'm more in support of the consensus operation of WP. Given the lack of clear consensus, the trial should end now. I'm starting to see backlogs on the PC editing list. Gerardw (talk) 02:39, 8 September 2010 (UTC)

I'm still confused how 2/3 support to go ahead with it is not consensus to move ahead when 3/5 was enough to turn it on originally. NW (Talk) 22:04, 7 September 2010 (UTC)

259-61 is 3/5 now? --Yair rand (talk) 22:20, 7 September 2010 (UTC)

I was talking about the original poll to turn it on, the one that Jimbo (not uncontroversially) closed. NW (Talk) 22:43, 7 September 2010 (UTC)

Notwithstanding Jimbo's close, the WMF didn't act on that previous proposal because it was not supported by at least 66% of editors, unlike the present trial which achieved 80%. Erik Moller had stated that for a FlaggedRevs implementation, 2/3 of editors in support were required [2]. Cenarium (talk) 23:48, 7 September 2010 (UTC)

• I agree with Kww that this needs to stop while we discuss what to do next. I voted above but not in the straw poll. I don't think something like this should be decided through a straw poll as that doesn't get into the right kind of discussion and analysis - it's like a government trying to implement a nuts and bolts policy through a majority, which as we in the US know from California (and as Socrates discovered) is not very efficient. The major problem I have is that, as mentioned above many times, it is not clear what purpose this serves. People say this should only be used for obvious vandalism and nonsense, yet why should we worry about obvious vandalism and nonsense in articles? Obvious vandalism and nonsense is obvious. It's not damaging. If someone adds some obvious vandalism to an article and someone reads it, they are just going to shrug or laugh. Damaging are fictitious references and other types of sophisticated vandalism. If we were going through a program to systematically allow editors to check off which edits have been verified, this might be useful. But as it is, it's just a misleading band-aid which doesn't solve any problems. II | (t - c) 06:37, 8 September 2010 (UTC)

Obvious vandalism decreases the opinion our readers hold of Wikipedia and thus potentially decreases people desire to join in editing.Doc James (talk · contribs · email) 23:33, 8 September 2010 (UTC)

So does subtle vandalism that is later proven false and becomes difficult to remove because someone gave it a green light, false promises, a very deeply entrenched troll community, and an already-prevalent mood that the unwashed anon peasants are diluting the glorious registered-editor master race's say. —Jeremy ^{(v^_^v PC/SP is a show-trial!)} 18:38, 9 September 2010 (UTC)

Do you realise that when you say "this needs to stop while we discuss what to do next" that it then no longer matters what you discuss and what the outcome of the discussion is? If it stops then it is not so likely to come back even if it is wanted. I rather like flagged revisions. I don't like calling it pending changes. Just typing that makes me feel dirty. Maybe it has something to do with my little corner of Wikipedia but i never came across any horrible issues with the feature. I read the poll. My thoughts on consensus are a poorly kept secret. In short it is 'good luck getting people to agree - we are not Cybermen'. To the person coming to an article to learn things are not always obvious. If it were obvious to them they would not necessarily be there reading the article or you would see a hell of a lot more anonymous correcting of obvious nonsense and errors that were snuck in for shits and giggles. I did that for about 7 years. With flagged revisions enabled i wouldn't have been able to correct the obvious errors i found however there would likely have been a lot less of them to be found. I voted in the keep section for the wildly crazy idea to actually not set some random restriction on the use of flagged revisions, forcing it there and disallowing it here but to use it as warranted on any given article be it about a person, an event, a place, a whatever. Technically that was not even an option in the voting, hence my calling it a wildly crazy idea. People read more than biographies. Every article makes mention of someone if it is at least a proper stub because someone had to write the reference used. Obvious nonsense gets added to any article not deleted. Proscribing an artificial limit to the scope of use or quantity of pages it is applied to is just setting up failure. Not every biography needs flagged revisions enabled; to claim so is just a whee bit exaggerated. To deny flagged revisions where it would be beneficial simply because an article is not a biography is likewise lacking some common sense. Scale back use? Maybe. Practical, common sense use? Yes, please!. delirious & lost ☯ ^~hugs~ 06:23, 9 September 2010 (UTC)

To be perfectly honest 66% of the vote is a pretty resounding vote of support. If such a large percentage voted for one party in a US election or one coalition elsewhere it would be a very resounding victory. Obama won by 53% to 46% or something. -- Eraserhead1 <talk> 06:59, 9 September 2010 (UTC)

• I agree that the trial should be ended now. If it mollifies the supporters of PC, then we can go ahead and make a commitment to have further trials. I think the straw poll, with all of its flaws, can be read as consensus to at least continue trials and improvement of PC. However, the first step is to honor the original agreement to a two month trial. Remove all pages currently under PC, but keep PC enabled, and then we all come back to the table and make a decision about how to proceed with future trials. Revcasy (talk) 15:18, 9 September 2010 (UTC)

Announcement of result

Announcement about Pending Changes --Jimbo Wales (talk) 19:33, 10 September 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.