Wikipedia talk:Flagged revisions/Trial

Related discussions

• Wikipedia talk:Flagged revisions and its archives contain the full history of FlaggedRevisions development on en.wiki
• Wikipedia talk:Flagged revisions/Trial/Archive 1 contains previous discussion on this specific proposal

RfC on implementation

The proposal on the attached project page represents the culmination of a very lengthy discussion and development process for implementing FlaggedRevisions on en.wiki. A clear consensus is required to present to the developers to have the extension installed. Ultimately that consensus will need to take the form of a straw poll, however we are not yet at that stage. This RfC initially seeks external input on the proposal, the opinions, comments and suggestions of editors not already involved with the development process. As such, please (for now) avoid simple expressions of "support" and "oppose" and instead present arguments and comments specifically connected to this proposal. Happy‑melon 17:56, 14 December 2008 (UTC)

---

I think this kind of trial is a good idea, since without it, we'll never have the evidence for an informed discussion of the implementation of the extension and its effect on Wikipedia. That said, I think that the current proposal does not say enough about how limited the trial will be. I may well have read it incorrectly, but it seems as if surveyors will be able to mark pages flagged indiscriminately suring the trial. Is this the intention, or is there meant to be some limitation in scope? Fritzpoll (talk) 11:36, 15 December 2008 (UTC)

Technically they can mark any page in the main space or portal space. However their actions, of course, will be limited by the relevant policies by the mandate that the community will give them. One of the proposed trials is to enable Flagged Revisions over featured articles and portals (see here). This proposal is just a technical framework: specific trials should be discussed separately. Ruslik (talk) 12:20, 15 December 2008 (UTC)

Sounds fine then - I can't see anything wrong with the proposal as it stands. Fritzpoll (talk) 12:39, 15 December 2008 (UTC)

Fritzpoll, you haven't done any newpage patrol at all. You have no idea what sort of backlog this sort of thing creates. Even if we just limit it to cursory skims of newpages, we wind up with, literally, weeks of backlog, and almost no one helping. DS (talk) 04:18, 20 December 2008 (UTC)

I can assure you that I have done newpage patrol. Just not in the past 2-3000 or so entries in my logs thanks to a couple of lengthy runs at Huggle and spells of blocking/unblocking. Unless you viewed the entire log you wouldn't know this, which is fair - of course, it means there was no basis to your assertion either, which is not as fair :) I am fully aware of the never ending backlogs in this place, but there are ways around it, the most obvious of which is not to implement it over every single article, just over some of our more vulnerable ones. Best wishes, Fritzpoll (talk) 08:32, 20 December 2008 (UTC)

Ah, my apologies - I misread your log. My overall point stands, though: in the year since the implementation of the newpage patrol flag, which is analogous to the revision patrol flag, thousands and thousands of articles have gone unpatrolled. DS (talk) 14:44, 20 December 2008 (UTC)

An expiration system, automatically showing revisions that are old enough to IPs, at least for non-blps, would eliminate the harm caused by backlogs and wouldn't decrease significantly the efficiency of flaggedrevs. Cenarium (Talk) 15:37, 20 December 2008 (UTC)

I'm looking at the broader scope here and a "trial" will likely lead to a full implementation that I don't believe we would be able to handle. Some of the smaller wikis have huge backlogs of revisions waiting to be sighted. I'd very much like for this to be able to work but I don't feel it will, thus I oppose any implementation of Flagged revisions at this time, whether it be limited implementation as this proposal suggests or otherwise. - Rjd0060 (talk) 15:45, 15 December 2008 (UTC)

That is indeed a perennial objection to the concept of FlaggedRevisions, but it is based on assumptions: while those assumptions are sensible, and may apply to en.wiki, you simply cannot say so with certainty until we have tried. The "don't give an inch or they'll take a mile" stance is not really applicable here because taking the second inch (having the implementation extended across the whole wiki) is no easier than taking the first (having FlaggedRevs installed at all). Both require developer intervention and so cannot occur without consensus. So I don't think you're being fair to say that "a trial will likely lead to a full implementation" as if that were a unequivocally bad thing. The trial will lead to an implementation only if we conclude that that is the right thing to do. If, as you believe, we are unable to maintain FlaggedRevs on en.wiki, then it will be impossible for us to attain consensus for its deployment. Having had a trial period only puts us in a better position to make that choice, it does not encourage one or other outcome. Happy‑melon 15:51, 15 December 2008 (UTC)

In my opinion, it would be a bad thing actually, and for the reasons I already specified. I've seen enough evidence to reasonably conclude that we would have unmanagable backlogs and don't like the idea of gambling with it. Of course this is only an assumption, just as your optimism is an assumption (and everybody who has an opinion one way or another is assuming). Have you researched/been following the other wikis that have implemented it as I have? - Rjd0060 (talk) 15:55, 15 December 2008 (UTC)

I certainly have, and I agree that it is a serious concern, such that I would probably have opposed most of the wider implementations that have been proposed previously without evidence to the contrary. I maintain that we cannot be certain either way without such evidence. But the point at which we need to make the ultimate decision "do we think we can handle a full FlaggedRevisions deployment?" is not being made with this proposal; with this system it will be delayed until we have gathered enough evidence to say whether it is viable. When that day comes, we'll be in a much better position than we are now to answer that question correctly. Without this trial implementation, however, we will continue to be entirely in the dark as to the true answer, and so any other implementation would be a complete leap of faith. If, as you believe, any full implementation will be a failure, we will be able to see that from the trials. So if you are correct, those trials will strengthen your position, not weaken it. There is no "gamble" as you claim, because this implementation is not at 'risk' of turning into a full deployment. You are right about one thing: everybody who has an opinion is assuming things. Why don't we take the opportunity to replace those assumptions with facts? Happy‑melon 16:08, 15 December 2008 (UTC)

It is perfectly reasonable to look at other wikis who have implemented this to see what issues they have faced. I've done so and made my opinion here and nothing at this point is really going to change my opinion unless they say that the 10,000++ revision backlog was a software glitch. I'm comfortable with the amount of "research" I've done on this and comfortable with the conclusions I've drawn. But, there are other people here :-). - Rjd0060 (talk) 16:13, 15 December 2008 (UTC)

That's certainly an opinion you're entitled to, and I agree that there is some evidence to support it. If it is true, then these trials will only provide more such evidence, and convince more people that FlaggedRevisions is unworkable. So why do you oppose them? :D Happy‑melon 16:25, 15 December 2008 (UTC)

In order to limit or avoid backlogs, I've proposed to automatically 'sight' (more technically, expire) edits after a certain period (for example, 6 hours), with various ways to adapt the system, so that backlogs shouldn't be a problem.
Cenarium (Talk) 19:03, 15 December 2008 (UTC)

To me the backlog thing is not a big deal. I'd like to see flagged revs for the simple reason that it allows you to keep track of what the latest stable version of the page was. An example of where this was an issue is the recent vandalism to the Spike Video Game Awards yesterday there were over 200 vandal edits to the page, and it became very easy to loose track of what the good version was. Even if we used flagged revs for nothing but that it'd be useful. We can't really be recognized as a creditable source until there is an easy way for users to go back to a reviewed version of a page, ideally a reviewed version that has been thoroughly checked above what would be considered sighted. The only practical way to do this is with something like flagged revs. —Nn123645 (talk) 05:15, 16 December 2008 (UTC)

FlaggedRevs is fairly technical, but is the proposal to basically digg individual edits? I take it FlaggedRevs is already being tested on en.labs.wikimedia.org. So only a bureacrat can make/unmake someone a 'surveyor'? And a 'surveyor' can turn on FlaggedRevisions for a page? All admins and rollbackers automatically become 'reviewers'? Admins can make/unmake people 'reviewers'? And a 'reviewer' looks at a page and labels it 'sighted' or 'unsighted'? A logged out user will see only the most recent 'sighted' version? A logged in user will see the most recent version? What button do I push to send an edit down the memory hole? Joking aside, is Special:OldReviewedpages going to get extremely large? I suppose that's one thing the trial is meant to find out. Are there ideas floating around about the potential length of the trial and how many articles on en.wiki would be involved? Would the first trial just be about 'sighted'/'unsighted' revisions? Or are there ideas for a range of ratings? --Pixelface (talk) 18:22, 15 December 2008 (UTC)

The proposed trial will be only about 'sighted'/'unsighted' revisions. Any expansion of the rating scale will require developer intervention. However I am open to consider a more complicated scale if the community deems it necessary. The potential length of the trial? I can only express my personal opinion here: 6-12 months. The first trials will involve only a few thousands articles, so Special:OldReviewedpages is unlikely to grow extremely large. Ruslik (talk) 20:26, 15 December 2008 (UTC)

You have the right general idea, certainly. As you point out, many of your questions are best answered by a few well-planned trials! Happy‑melon 21:03, 15 December 2008 (UTC)

If an editor makes an edit to an article, and the editor is a 'reviewer', can they mark their own edit 'sighted' or does it have to be a different editor who marks it 'sighted'? --Pixelface (talk) 01:46, 16 December 2008 (UTC)

In the proposed implementation the edits of reviewers are marked sighted automatically. Of course, this function can be disabled if there strong objections against it. Ruslik (talk) 06:16, 16 December 2008 (UTC)

Since immediately implementing flagged revisions on every single article is most likely going to lead to backlogs, I'd support a trial on featured article (which are the articles most in need of retaining quality) and heavily vandalised articles (perhaps as an alternative to semi-protection). The growth of the English Wikipedia has already caused cleanup and referencing backlogs, so sighting backlogs are very likely to occur if we don't work to prevent it. - Mgm|^(talk) 18:47, 15 December 2008 (UTC)

New Trial idea: A trial for featured articles will not show the full extent of the backlog. We have a few thousand featured articles at the moment. If Flagged Revisions goes live, there will be a great interest in it for perhaps the first few months, which will likely be the duration of the trial. But the problem is, as we increase Flagged Revisions to encompass greater and greater amounts of articles (perhaps first to A-class, then to GA(, interest in going through the backlog will likely die off.

What I would support would be a removal of the semi-protection system and an addition of this to all currently semi'd articles. That would allow IPs to make constructive edits, something that requires the use of an obscure template, {{edit-semiprotected}}, right now. If we do this instead, we will have increased our net beneficial edits and we will still have the trial you all seem to want. - NuclearWarfare ^{contact me}_{My work} 20:40, 15 December 2008 (UTC)

• Argh where did the bold words come from? However, you are aware that the proposal you're actually discussing is just the technical configuration, not any particular trial? Implementing your proposal would require exactly the same implementation as is proposed here. We removed the specific details of the trials for precisely that reason: no matter how we trial, we still need the technical ability to trial. Why don't you move this suggestion to Wikipedia talk:Flagged revisions/Trial/Proposed_trials? Happy‑melon 20:48, 15 December 2008 (UTC)

  • Well, it seemed like that's what all of you were discussing. My apologies for not reading fully into each comment. And yes, I would support a decision to trial, as per my last post.
  • I'm confused now. The objective of this discussion is to figure out whether or not to start a trial of some form? - NuclearWarfare ^{contact me}_{My work} 01:51, 16 December 2008 (UTC)

    You are right the objective is whether to start a trial of some form. However for this to happen we need to agree on a configuration of Flagged revisions that is necessary for trials to start. This configuration should be of limited nature, but simultaneously flexible enough to enable fine tuning during trial period. Ruslik (talk) 07:58, 16 December 2008 (UTC)

• As of right now, Category:Featured articles has 2,336 articles and Category:Semi-protected has 2,058 pages (1,873 articles I think). There are 5,601 GAs according to GimmeBot (although I count 5,610 currently) and 1,152 featured lists (although I count 1,148). FAs/FLs/GAs is 9,089, and plus semi-protected articles (ignoring any overlap) is 10,962. I think 123 FAs are semi-protected, I think 5 FLs are semi-protected, and I think 155 GAs are semi-protected. So I think there are about 10,679 articles currently on en.wiki that are FA or GA or FL or semi-protected. --Pixelface (talk) 03:15, 16 December 2008 (UTC)
• I don't have the energy to dig through all the archives on this, but I believe that with the sighted revisions model a "backlog" isn't really a concern -- if there are no sighted versions, the gentle reader simple sees the latest version, as it is now. So nothing changes, except that we could ensure quality on articles that need it, perhaps focusing on particularly needy articles: FAs, BLPs, semi-protected articles. Given that, I support this trial plan (but then, I support turning flaggedrevs on for good). (Which is to say: I support this proposal. I got lost with all the different trial proposals. -- phoebe / (talk to me) 07:39, 16 December 2008 (UTC)
  • Yeah and if this is just about what unlogged-in readers see, I suppose a 'reviewer' would not need to 'sight' each new edit, they could just 'sight' the newest revision they find without a ton of vandalism on it. --Pixelface (talk) 19:44, 16 December 2008 (UTC)

I'm just brainstorming here. On Wikipedia there are currently edit wars (reverts to articles), and "wheel wars" (admins undoing each other's actions, sometimes on articles) and I think with FlaggedRevs there's a possibilty of "sight wars" — one 'reviewer' marking their preferred version of an article as 'sighted' and another 'reviewer' marking it 'unsighted'.

• So what do we do when a "sight war" happens?
• Can each revision only be 'sighted' or 'unsighted' one time?
• Can the value be changed many many times?
• Does the newest 'sighted' revision always take precedence over an older 'sighted' revision?
• Or could the value be cumulative, and the number of 'reviewers' that mark a revision as 'sighted' would matter?
• If admins give people the ability to be a 'reviewer', when should that ability be taken away?
• Also, if a 'surveyor' enables Flagged Revisions on an article, and an IP edits the article, yet does not see their change immediately on the page, are the talk pages going to be full of IPs saying "Why doesn't the article show the change I made?"
• Does there need to be note on 'surveyed' articles saying "Only the most recent sighted version is visible."?

And I don't know if the words 'sighted' and 'unsighted' are the best words; they might confuse people.

• How does one decide whether to mark a revision 'sighted' or 'unsighted'?
• And I guess reader ratings (shown with Special:RatingHistory) will not be in the first trial?
• Can Special:OldReviewedpages show the aricles with the most edits to them since the last 'sighted' version?

Just some things to think about. --Pixelface (talk) 20:53, 16 December 2008 (UTC)

Thanks for your comments. Some of your questions have easy answers, others are more thought-provoking. An edit can only be sighted once: once marked as sighted, that specific edit cannot be 'unsighted'. The only way to reverse the effect of the edit is, as usual, to revert the edit (and mark the reversion as sighted). So I don't think we have to worry about "sight wars" as you call them, as they will just be normal edit wars. There is an issue, however, in that edit wars can now become unbalanced if one editor is a reviewer and the other isn't. I would think that edit warring in this situation would be dealt with severely, possibly resulting in loss of reviewer rights. Newest sighted revisions always take priority, just like more recent edits at the moment. Only one reviewer can sight an edit, it cannot be 'multiply sighted'. When to give and revoke reviewer status is a key question to answer in the trial period, as is when to sight a revision. Check out http://en.labs.wikimedia.org/wiki/Tablature for an example of a page that is currently displaying behavior similar to what the trial pages will show; you can check out what warnings and messages will be displayed for yourself. Happy‑melon 21:10, 16 December 2008 (UTC)

Thanks a lot for your answers. I looked at the Tablature page, and it was quite helpful. Looking at the history, I see a "Visual comparison" button and a "Wikitext comparison" button. Does that come with the FlaggedRevs extension? I also see "sighted" and "validated" next to edit summaries. What's the difference? Is 'validated' used to mark a "quality" version and 'sighted' to mark a "stable" version? --Pixelface (talk) 22:48, 16 December 2008 (UTC)

Well, this is not quite right. Sighted page can be unsighted (depreciated), see an example here. However any revision that does not contain vandalism, libel or copy-right violation must be sighted. If one reviewer overlooked something, the revision may be unsighted by another. Though Flagged revisions should not be used to resolve content disputes. Ruslik (talk) 04:57, 17 December 2008 (UTC)

The VisualDiff system is an experimental parser stage, not part of FlaggedRevs; although hopefully it will be coming soon to live wikis. You're quite right about 'sighted' vs 'validated'; the en.labs implementation uses three 'grades' of sighting, not two - sighted overrides unsighted, and validated overrides sighted, if the page is so configured. This initial implementation here does not use "qurality" revisions; it's something to think about at a later stage. Thanks for the info on 'unsighting', Ruslik, I wasn't aware that that was the case. However, I maintain that 'unsighting' an edit should not be condoned; if there is a legitimate reason why the edit should not be visible, then the correct response is to remove that problem and sight the clean version. I hope it's not a problem we're going to encounter; of course, you never know till you try. Happy‑melon 13:12, 17 December 2008 (UTC)

What happens if a vandal becomes a 'reviewer' and all their edits are automatically marked 'sighted'? What should happen to the person who made the vandal a 'reviewer'? What happens if a well-meaning 'reviewer' marks several revisions 'sighted' but did not catch the vandalism on the page and their 'reviewer' abilities are questioned? I really think a plan (when to sight, when to unsight, when and who gives reviewer status, when and who revokes reviewer status) needs to be in place before the trial starts. --Pixelface (talk) 21:10, 18 December 2008 (UTC)

I couldn't agree more, these are things that the 'crats will want to see clear guidelines for before allowing a trial to proceed. However, they are entirely distinct from the technical issues considered by this proposal and so, I hope, the fact that we haven't yet decided on such things as these should not prevent this stage of the process from going forward. Most importantly, these are things that might well change as we become more familiar with FlaggedRevs and what we can and can't expect from it, so it would be highly inappropriate to prescribe them rigidly at this time. In response to your general question, I'd say the situation is very much analogous to incorrect asignation of rollback, as the two permissions are on a similar level of sensitivity. Happy‑melon 21:55, 18 December 2008 (UTC)

• The answer seems to be that we should give this a go; in a temporary, monitored, and clean fashion. If we never try it we won't know if it doesn't work here. Never trying seems to be keeping us in the dark for a function that could end up being useful. §hep • ¡Talk to me! 21:29, 17 December 2008 (UTC)

• We have so many backlogs that people don't deal with as it is. Look at Newpage patrol, I know few users that do that. This looks like it would do more harm than good in general to the project. Wizardman 04:17, 20 December 2008 (UTC)

  However, using an expiration system to show old enough revisions to IPs, at least for non-blps, would solve this problem, and still prevent the quasi-totality of vandalism and other disruption from being seen. Cenarium (Talk) 15:37, 20 December 2008 (UTC)

• I strongly oppose any possible implementation of this feature in any way. This takes away much of the purpose of the site, which is to allow anyone to contribute. I can already imagine the huge backlogs. If implemented, I could look up an article about a building that caught on fire five days ago and burnt down. I would see nothing about the fire, and the article would say the building is still standing. It could take quite a while for someone to get around to "flagging" that revision. Plus, more and more tasks to do. More and more backlogs. I do not like it. _David^WS _(contribs) 03:02, 22 December 2008 (UTC)

  Your opinion on FlaggedRevs generally is, of course, one you're entitled to, and it is not that uncommon amongst en.wiki users. However it is currently based on nothing more than, as you yourself put it, your imagination. Can you prove that five-day backlogs would be commonplace? We can, with this trial. If you are in fact correct and FlaggedRevs is unworkable on en.wiki, these trials will point that out very clearly. Then you will have actual evidence to support your position. In that situation, having had a trial will make it harder, not easier, for FlaggedRevs to be deployed more widely on en.wiki. Happy‑melon 11:50, 22 December 2008 (UTC)

• Can you prove that there are any benefits of flagged revisions? No trial before people have been allowed to state their opinions please. (i.e. not after this RFC) --Apoc2400 (talk) 15:33, 27 December 2008 (UTC)

• Can the benefits of FlaggedRevs be proven? Yes, by conducting one or more small, controlled trials and seeing tangible benefits. Can you prove that the "huge backlogs" and "[loss] of the purpose of the site" will come to pass? Yes, by conducting the same trials and seeing the tangible downsides. Opinions are great and the whole point of this discussion (and the megabytes that have preceeded it) is to obtain as many of them as possible. Evidence for those opinions is even more valuable. I couldn't agree with you more: "no trial before people have been allowed ot state their opinions". If you take even the quickest skim through the archives linked to at the top of this page, you will see that we have just about every opinion on the spectrum. My contention is that we should have "no deployment without trials", for exactly the same reasons. Once again, this proposal, if the consequences of a full deployment of FlaggedRevs are as dire as you claim, this proposal will strengthen your position. Why then are you opposed to it? Happy‑melon 15:48, 27 December 2008 (UTC)

• I have not claimed very much at all. At the top of this page you ask people to not register simple supports or opposes. Therefore you should not use this page to say that you have consensus for anything, even a trial. To get back to the general question, I doubt a small trial of a few articles and many people watching will give us any information about the backlogs if flagged revs is applied to millions of articles. --Apoc2400 (talk) 16:12, 27 December 2008 (UTC)

• If you have not claimed very much, I'm confident that I have claimed even less. Where do I or anyone else claim that there is "consensus for anything, even a trial"? This is a discussion phase, where everyone is encouraged to put forward their comments and arguments that may influence the development of the proposal. You are quite right to say that this process does not produce a clear consensus, that will require a straw poll, which we are now planning. At this time, you have the opportunity to present your opinions, which will be welcomed, and the reasoning behind them, which will be contested; that is the nature of constructive discussion. You and everyone else who contributes to the eventual poll will be encouraged to read through this discussion and use it to form and inform their own opinions. I simply do not agree that your concerns, valid though they are, are actually in opposition to this proposal. This is not a discussion on "should we enable FlaggedRevs on "millions of articles""; it is not even a discussion on "should we enable FlaggedRevs on any articles". It is proposed merely to give ourselves the technical ability to enable FlaggedRevisions on a small set of articles in a controlled fashion and for a limited time without further developer intervention. Everything else, including the situations that concern you, are expressly excluded from the proposal. Happy‑melon 16:25, 27 December 2008 (UTC)

• Do the experiment, then we will have some data that will show what the costs and benefits of this feature are. Tim Vickers (talk) 22:09, 23 December 2008 (UTC)
  • I think a trial run of this feature would be nice. It looks like a good benefit to the project. – Alex43223 ^{T | C | E} 08:37, 30 December 2008 (UTC)

New userrights group

A trial run limited on certain articles sounds interesting. I hope some people have some more-or-less scientific ideas how to run such a trial.

I don't quite understand why we need a new userright group for this. Essentially, if we want to have a trial run, we need to figure out a way to select a good sample of pages where flagged revisions should be tried, and keep that sample for a period of time. The actual switching of the "flagged revision" flag on a page does not seem to need "surveyor" oversight, and would be more efficiently done by a bot.

In other words, I welcome having people who think about pages that should be included and monitor those (and scientifically evaluate the results later), but don't see why they should add or remove the flagging flag while the trial runs. Not having to add an extra usergroup has the advantage that we won't have to argue who gets that userright and why. Kusma (talk) 15:48, 15 December 2008 (UTC)

You misunderstand the purpose of the flag. Yes, the setting and unsetting of pages could be most efficiently done by a bot, and indeed it probably will. In order for the bot to be able to make those changes, it will need the 'surveyor' user right! Surveyors are different only in that they have the technical ability to make the changes; which pages they change and for how long will be governed by the community and relevant policy. The situation is entirely analogous to bureaucrats: crats have the technical ability to change any user into an administrator, but the users who receive that treatment are selected by the community at RfA. Bureaucrats are chosen not for their ability to judge who should be made admins (because they don't do that), but because they are trusted to use that technical ability on behalf of the community. In the same way surveyors wield the technical ability to implement FlaggedRevisions on behalf of the community, they would not themselves be responsible for selecting the pages. Happy‑melon 15:56, 15 December 2008 (UTC)

I have no objection if the group contains only specialized bots (or if the flagging is done by a MediaWiki pseudobot, which I guess would be more of a hack, but a possible implementation). I just want that the oversight of the process is by the community, not by a group of people wearing a certain hat. Kusma (talk) 16:08, 15 December 2008 (UTC)

That's absolutely the case; the community will decide what to do to which pages, and the surveyors will execute those wishes. Having the flagging done by a maintenance script (the 'pseudobot' you describe) would introduce a very long delay between decisions being reached and the actions actually being implemented, which includes correcting errors and ommissions. Having a trusted on-wiki user to make these changes is definitely the simplest solution. Happy‑melon 16:23, 15 December 2008 (UTC)

I object to any new ability being automatically given to, or exercised by administrators. Part of the project page, foresees, administrators doing this function almost exclusively and having an untoward ability to prevent any reviewer they choose, by simply revoking their reviewer privileged. I see wheel-wars in this. We already have edit-warring, now we'll be able to allow admins to go-to-war over which editor should be a reviewer. This is not a good thing. Surveyor and reviewer should be settable only by bureaucrats or higher to prevent this. They typically do not war between themselves, and understand much more clearly than admins how to be fair to the community-at-large, not imposing a view by force. Wjhonson (talk) 04:45, 16 December 2008 (UTC)

For the full implementation of flagged revisions we need at least about 10,000 reviewers. Do you think that ~ 10 active bureaucrats can handle this? In addition, sysops can give and remove rollback now. I am not aware of sysops mass removing rollback to prevent rollbacking their edits. Such behavior would be an abuse of power. Ruslik (talk) 06:24, 16 December 2008 (UTC)

I agree with Ruslik. The distribution of 'editor' flags will be conducted in exactly the same format, and probably in the same place, as rollback, IPBE, and the various other rights that admins already have the ability and authority to assign. There is no evidence of the systematic abuse of this existing process that you seem to be afraid of, so I can't see any reason not to extend it to this process as well. Happy‑melon 13:55, 16 December 2008 (UTC)

(outdent) I think 'surveyor' is unnecessary, technical control of pages is already in the purview of +sysops, and if there is a page issue a sysop should be able to fix it without using extraordinary means (that may be possible using existing tools like moves/deletes). — xaosflux

^Talk 12:03, 18 December 2008 (UTC)

Sorry, but I do not understand what you mean. Do you want to abolish surveyor usergroup and give all FR tools to sysops? However this will mean full implementation of Flagged Revisions, not just a trial, because once you give the tools to all 1600+ sysops there will be no simple way to stop the experiment. Ruslik (talk) 13:48, 18 December 2008 (UTC)

Yes there would be, remove the Flagged revisions extension.... — xaosflux ^Talk 12:04, 19 December 2008 (UTC)

Removing an extension is not simple, it will require consensus before filling bugzilla request. Since the consensus is difficult to achieve the FR extension will stay, and the trial will become a full implementation without any consensus for this. The consensus should be required to continue trials not to stop them. Ruslik (talk) 12:37, 19 December 2008 (UTC)

As for reviewers, this is a simple enough permissions that letting sysop +/- it for others should be a non-issue, we have ways to deal with wheel warriors. — xaosflux ^Talk 12:03, 18 December 2008 (UTC)

As for using a bot, I'm confused; is the trial scope so large it can't be managed? As for full implementation wouldn't this be name-space wide? — xaosflux ^Talk 12:03, 18 December 2008 (UTC)

Visibility of the test

How visible will this test be? Specifically, will a sighted page contain any notice of the change? Will we be using any sort of site notice to announce the test? While I can accept the terms of the test (as frustrating as it is that sighted versions will be visible by default, which I personally think is a bad idea), I do think that we need to make it obvious to readers and people who aren't "regulars" what's going on. I don't particularly want to be getting confused messages about "why aren't my edits showing up?" without good cause. {{Nihiltres|talk|log}} 19:16, 15 December 2008 (UTC)

You can see how FlaggedRevisions looks at http://en.labs.wikimedia.org - I've set the page Tablature to display in much the same way as trial pages here would. You can see when you edit it that there is a warning above the edit box that edits will not be visible immediately; we can make this as large and obvious as we feel is necessary. As usual, most of the interface can be customised through modifying system messages to be as overt or subtle as desired. Happy‑melon 21:00, 15 December 2008 (UTC)

Deciding on individual trials

So, the current plan is to ask first on whether a trial (or multiple trials) at all should place, and then to get consensus on the specifics of the trials? I'm not really a fan of abstract discussions on Wikipedia, but I can certainly live with it. However, then the question becomes how do we decide on the specifics of the trials? It says 'consensus', which is rather vague. Wouldn't it be better to be more explicit about this, especially given how explicit the rest of the proposal is? -- Jitse Niesen (talk) 22:18, 15 December 2008 (UTC)

I prefer to think of it as breaking the problem down into manageable chunks rather than being abstract, but I take your point. It is in fact being deliberately vague in an atempt to separate the specifics of the trials from the implementation required to conduct them. I think that, given that we're handing the power to initiate trials (by creating surveyors) to bureaucrats, who are after all appointed based on their ability to gauge consensus, that we don't need to worry about a trial starting without consensus. Do you have any suggestions for a more explicit phrasing that is not overly bureaucratic? Happy‑melon 22:38, 15 December 2008 (UTC)

I was thinking about the level of consensus required. There is a difference between the rough consensus used at WP:AfD and the stronger consensus required at WP:RfA. But I'm happy to leave it to the discretion of the bureaucrats.

I think it is important that it's very difficult for the proposed implementation to evolve sneakily from a trial to a full deployment. Should this be made more explicit, for instance by modifying the second sentence so that it reads "The proposed configuration does not scale well to a full deployment, ensuring that it is only used for limited trials." Or is this perhaps patronizing by stating the obvious?

Incidentally, I went through the Q&A of the candidates for the recent Arbitration Committee elections. By my count, and there are a couple of borderline cases, there are two against flagged revisions (Lifebaka and Wizardman), ten with no or unclear opinion (Carcharoth, Hemlock Martinis, Lankiveil, Risker, and six who didn't answer the questions), and sixteen in favour. Of the top seven candidates, six are in favour and one doesn't know. -- Jitse Niesen (talk) 16:20, 16 December 2008 (UTC)

It's not "difficult" for this to extend to a full deployment so much as technically impossible :D. I to am willing to trust the bureaucrats to evaluate a 'sufficiently strong' consensus. Interesting point on the ArbCom candidates. Happy‑melon 17:49, 16 December 2008 (UTC)

Each area of proposal should get a seperate consensus. i. e. Get one for FAs, or A class, or GAs, or BLPs, or whatever, then address the next if it seems worthwhile. Don't say "Flagged Revs at all?" then "Okay, on what?" - that's too confusing. WilyD 17:38, 16 December 2008 (UTC)

Why is that confusing? Happy‑melon 17:49, 16 December 2008 (UTC)

You're likely to get a mandate to implement flagged revisions, but not in any particular class of articles, or not representing consensus. In the nominal case where GAs, FAs and BLPs are each supported by 1/3 of people for first implementation, you might think they're all equal. If the 2nd choice of the GA and BLP supports are both FA, for instance, then they're not equal. In practive the outcome is likely to be substantially messier. "Should we have flagged revs on FAs?" "Should we have flagged revs on GAs?" and so forth yield much clearer answers. WilyD 19:15, 16 December 2008 (UTC)

I disagree. You seem to think that, if this proposal is accepted, then we are duty-bound to implement FlaggedRevs somewhere and in exactly one place, and hence we will be confused over where exactly. That's not the case; if this proposal goes through and then we can't get a consensus to trial anywhere in particular, then so be it, we don't have any trials and hence no FlaggedRevs. If this proposal goes through and then we see clear consensus for trials on FAs and BLPs, then we trial in both areas. This proposal is not "should we have FlaggedRevs?" but "should we give ourselves the technical ability to have FlaggedRevs"; it's just a stepping-stone. But it's a stepping stone that will be needed by any implementation of FlaggedRevs,(IMO) makes intuitive sense to agree on it separately. Happy‑melon 13:17, 17 December 2008 (UTC)

I'm not suggesting that. Zero, or two, or whatever still could result in the fashion of "Where?" I'm talking about. But maybe you're right, that "Ability to implement when wanted?" is the first step. WilyD 15:24, 17 December 2008 (UTC)

While I agree we should have a seperate !vote for each type of article (FA, GA, BLP, Protected, etc...) I don't see any reason not to figure out whether people want any sort of trial first, and then hammer out the details. --Falcorian ^(talk) 18:38, 16 December 2008 (UTC)

It seems to me that if you're going to go ahead with this, that you should at least be planning on randomized trials, where you pick a class of articles and divide it into (trialed) and (not-trialed) so that there is some hope that we can compare like-for-like in seeing how much better (or worse) Flagged articles fare over non-flagged articles. Lot 49a^talk 05:45, 4 January 2009 (UTC)

Wikipedia:Protecting BLP articles feeler survey

FYI, based on a conversation on Jimmy Wales's talk page:

• Wikipedia:Protecting BLP articles feeler survey

Your feedback is appreciated. rootology (C)(T) 22:40, 19 December 2008 (UTC)

Report from the German Wikipedia

I'm mildly in favor of implementing flagged revisions here on the English Wikipedia, but before we do so, I'd love to hear a report from the German Wikipedia. As you all know, they've had flagged revisions for many months now, and we can definitely benefit from their experience. While our wiki is culturally different from theirs, a good amount of their experiences with the system should transfer over. Anyone know of a good way to get in contact with the German Wikipedia and hopefully get a report on their progress with flagged revisions — in English — to help us make our decision on whether we should implement it? --Cyde Weys 01:35, 28 December 2008 (UTC)

Just wait for a German Wikipedian to come by :)

P. Birken (who has been deeply involved in this project all along) published a report on wikide-l two weeks ago - in German, though. I'll try to translate it this afternoon, and I'm alerting him of this discussion. --dapete 11:36, 28 December 2008 (UTC)

Translation at User:Dapete/Report on Flagged Revisions, December 14, 2008. Enjoy (or not). --dapete 12:50, 28 December 2008 (UTC)

Thanks for the report, and for the quick translation! Flagged revisions looks promising for use here on the English Wikipedia. As far as I can tell, they didn't hit any major issues. The main minor issue seems to be a lag time between when an edit is made and when it is approved. Luckily, they've already come up with several mechanisms to address that that we could leverage here. Also, I don't doubt the tenacity of our counter-vandalism users one bit. They already provide 24/7 coverage through tools such as Huggle. Flagging non-vandalized edits on top of that wouldn't be a very big deal, I would guess. What do the rest of you guys take from this report? --Cyde Weys 19:32, 28 December 2008 (UTC)

I noticed the report says "Now there is a campaign to ensure that the [median] waiting time doesn't exceed 21 days, so this has been stable since November 19..." Who wants to wait three weeks for their edits to become visible? It also says there are only 3,000 to 4,000 manual sightings per day, which doesn't sound like a lot when there are 851,000 articles on German Wikipedia. This will be a disaster. Richard75 (talk) 15:54, 3 January 2009 (UTC)

maximum waiting time, not median waiting time. --Chin tin tin (talk) 23:08, 5 January 2009 (UTC)

Actually, P. Birken's report is lying when saying "there is currently a discussion to more clearly specify the criteria for sighted revisions" "a regular Wikipedia author has looked at it and the revision is free from obvious vandalism."

The discussion is not about "free from obvious vandalism" but about lots of additional criterias that should be met when flagging an article. Some of them (from de:Wikipedia Diskussion:Gesichtete Versionen#Endgültige Fassung der Sichtungskriterien, translation welcome):

The article must be sourced, it must fulfill German Wikipedia's rules for links, for notability criteria, for biographies of living persions and some more rules, copyvios should be checked, weblinks and picture links should be checked, in case of new articles additionally the rules from the Wikipedia manual of style should be fulfilled, article should have links and categories – then it is allowed to flag the revision.

And if it's not flagged, the the older version is still displayed. Actually, I don't like this German verboten approach.

--Cyfal (talk) 23:14, 3 January 2009 (UTC)

Information from another german further down the page. Lot 49a^talk 16:17, 7 January 2009 (UTC)

There seems to be some misinformation about the German trial. They had trials for almost a year and a vote last fall,whether to implement it for good or not. Though not all German authors liked the feature there was a clear yes-vote. But note the German system has 2 step revision process (and only the first step was tested an voted on). Basically you have the flags "reviewed" (gesichtet) and "confirmed" (überprüft). Reviewed only means lightweight quality control (i.e. some other "trustworthy" or "established" author has read the article and has found no obvious errors or falsehoods), which blocks vandalism, obvious falsehoods/pov/proganda and alike. Confirmed means a thorough review of the article by an expert in field. Personally i like the general idea of flagged revisions (it's a bit like in software development) aside from blocking spam/vanadalism/extreme, they also allow a better organisation of quality control (for instance you can avoid that people accidentally proofread the same article under assumption nobody checked it yet). Please note that flagged revision in this form do not violate they anyone can edit principle and all edits remain visible to readers. It only means that the reader will receive the additional information, whether the content has been reviewed or not. Overall i would recommend a test.--Kmhkmh (talk) 16:24, 9 January 2009 (UTC)

Straw poll on implementation

Template:RFCpolicy We have now had plenty of time to discuss and refine this proposal to the point where the majority of its bugs have been ironed out. It is now time, I believe, to proceed to demonstrate a consensus for or against its implementation by means of a straw poll. The question to be considered is effectively:

“ Should the proposed configuration of FlaggedRevisions be enabled on the English Wikipedia? ”

Support for this proposal effectively implies support for one or more small-scale trials of FlaggedRevisions on en.wiki articles, although it does not necessarily imply support for a 'full deployment' either now or in the future. I would like to request that contributors read at least the discussion higher on this page as well as the details of the proposal before commenting. If you want to know more about how the system will look and feel on real articles, please investigate the live demonstration on en.labs. As usual, this is a straw poll, not a straight vote: discussion and debate is always welcome and encouraged. If you participate, please watchlist this page and be prepared to participate in any subsequent discussion. Usual no biting/kicking/sockpuppeting/bitching/scratching rules apply :D. Happy‑melon 17:40, 2 January 2009 (UTC)

Support

0-100

1. Support — Sure, let's see what happens. No harm in a trial. ► RATEL ◄ 21:07, 3 January 2009 (UTC)
2. Per all my various posts and throughts on the Wikipedia:Protecting BLP articles feeler survey that I began. rootology (C)(T) 17:48, 2 January 2009 (UTC)
3. I participated in creation of this trial proposal. So I support. Ruslik (talk) 17:57, 2 January 2009 (UTC)
4. Something that's been long overdue, although I think that the surveyor function should be bundled with the admin tools. bibliomaniac15 18:08, 2 January 2009 (UTC)
5. Support this seems a reasonable configuration (probably agreeing with Bibliomaniac above however), however I would much prefer that the first proposed trial be a small random selection of BLPs (all beginning with Q or Z for instance) firstly because I think (ref. Wikipedia:Protecting BLP articles feeler survey) BLPs is where the strongest support for flagged revisions can be found, and secondly because they will be a fair sample of wikipedia's articles (small, long, little edited, widely edited, etc.) rather than the existing two proposed samples which would not be representative of wikipedia's wider articles. Davewild (talk) 18:16, 2 January 2009 (UTC)

   That definitely sounds like a good possible trial. Why don't you write that up on the /Proposed trials page? Happy‑melon 18:19, 2 January 2009 (UTC)

   I have added it to the proposed trial page. We can change the letter as needed if people think it should be larger or smaller group. Davewild (talk) 22:54, 2 January 2009 (UTC)

6. Support. --Barberio (talk) 18:17, 2 January 2009 (UTC)
7. Support Xclamation point 18:19, 2 January 2009 (UTC)
8. Support. This has been a long time coming, and will add a little bit of professionalism to articles. Ec5618 13:18, 3 January 2009 (UTC)
9. Support --Jimbo Wales (talk) 18:29, 2 January 2009 (UTC)
10. Avruch ^T 18:30, 2 January 2009 (UTC)
11. I believe flagged revisions are potentially a great improvement but there are unknowns like whether or not a substantial backlog will develop. So we need a trial. -- Jitse Niesen (talk) 18:34, 2 January 2009 (UTC)
12. Support - This is worth trying. I think it will be helpful in dealing with problems on BLP articles. Also would support a trial for featured articles. --Aude (talk) 18:35, 2 January 2009 (UTC)
13. I think this feature is needed to improve the reliability of Wikipedia articles. A trial would be a good way of demonstrating its effectiveness. Wronkiew (talk) 18:35, 2 January 2009 (UTC)
14. Support A trial will give us some hard evidence as to how the system works, and will allow us to make a better judgment as to whether to implement it across more articles. --Falcorian ^(talk) 18:38, 2 January 2009 (UTC)
15. Support a trial, certainly. Martin 18:40, 2 January 2009 (UTC)
16. I'm all for experimenting with new ideas, let's see how it works out. RichardΩ612 Ɣ ɸ 18:44, 2 January 2009 (UTC)
17. support --Malcolmxl5 (talk) 18:46, 2 January 2009 (UTC)
18. Support, we've discussed this to death. Let's get some experience with it.-gadfium 18:49, 2 January 2009 (UTC)
19. Support Flagged revisions would be a great improvement. JoJan (talk) 19:03, 2 January 2009 (UTC)
20. Support. Absolutely - nothing to lose, everything to gain, especially regarding BLPs. Black Kite 19:19, 2 January 2009 (UTC)
21. Support. Extremely strong support in fact. It's definitely worth a trial, and there's a lot of support at the BLP feeler survey. - Taxman ^Talk 19:23, 2 January 2009 (UTC)
22. Strong support: The only reason people ever criticise us is that we're not reliable - the sooner we implement FlaggedRevs, the sooner we remove any criticism of Wikipedia. Dendodge Talk^Contribs 19:26, 2 January 2009 (UTC)

    Flagging should make us less reliable, and makes us more like Citizendium. Both are bad. Septentrionalis PMAnderson 19:36, 2 January 2009 (UTC)

    How would it make us less reliable? Things have to be checked before going live, meaning factual inaccuracies don't make it into articles. Dendodge Talk^Contribs 00:50, 3 January 2009 (UTC)

    Because flagged articles will tend to lose fixes offered by people without sighting privileges, and therefore accumulate crud which the flaggers have missed. Most of our substance, after all, derives from anon edits. The idea that flaggers will actively check the accuracy of edits is a fantasy; the advocates of this test repudiate it here. Septentrionalis PMAnderson 21:58, 3 January 2009 (UTC)

    It's better than semiprotection. This will only be selective, and should provide a happy compromise between 'anyone can edit' and semi protection - thereby allowing some people to edit articles they could not previously edit. Dendodge Talk^Contribs 19:44, 4 January 2009 (UTC)

23. shoy (reactions) 19:35, 2 January 2009 (UTC)
24. Support Give it a try. It's better to evaluate in practice rather than keep discussing in theory. MrMurph101 (talk) 19:49, 2 January 2009 (UTC)
25. Support -- Ed (Edgar181) 19:56, 2 January 2009 (UTC)
26. Support. This has been long discussed and a successful experiment will be invaluable, no matter what the conclusion is. Dcoetzee 19:59, 2 January 2009 (UTC)
27. Reluctant Support - I oppose Flagged Revisions in principle with all the force I can muster, but I suppose that there is no practical way to make a reasoned decision than to see them in action. J.delanoy^gabs_adds 20:06, 2 January 2009 (UTC)
28. Support. Opposing something based on guesses about the results, especially guesses that contradict what information we do have, is not helpful. Mr.Z-man 20:08, 2 January 2009 (UTC)
29. Support - Something needs to be done to repair Wikipedia's reputation. - Trevor MacInnis (Contribs) 20:13, 2 January 2009 (UTC)
30. Support implementing this at small scales and going from there seems the best way to catch any tech or philosophical problems that could arise from it. --MASEM
31. Support - No way a trial about this can be bad. I've been following this for over a year now and have seen all the pros and cons put forward multiple times. All said and done, I cannot see any harm in a test run and hope this finally goes forward rather than the circles it's been in for ages. Almost all issues with this are already issues in the first place as the way things stand now, so it can only really help, not hurt. ♫ Melodia Chaconne ♫ (talk) 20:21, 2 January 2009 (UTC)
32. Support - how can I, as a scientist, judge something without an empirical test? The data of others is fine, but I'll always understand my own data better ... WilyD 20:21, 2 January 2009 (UTC)
33. Support with Reservations, born of both my apprehensions over how such a program would actually interact with everything from the various sub-cultures on a day-to-day basis to the greater architecture of the system over time (and my own opinions and proposals), and my conviction that evidence is better than the absence of evidence. Ngorongoro (talk) 20:52, 2 January 2009 (UTC)
34. Support It's certainly worth experimenting with. There is no harm in a trial, and benefits to be gained either way. --.:Alex:. 20:58, 2 January 2009 (UTC)

    Support - Something needs to be done to repair Wikipedia's reputation. - 20:12, 2 January 2009 (UTC) —Preceding unsigned comment added by 24.83.204.61 (talk)

35. Support: There are a couple of pages on my watchlist that could really benefit from this. --Carnildo (talk) 21:15, 2 January 2009 (UTC)
36. Support. Seems like a well-designed framework for testing out FlaggedRevs.--ragesoss (talk) 21:36, 2 January 2009 (UTC)
37. Support - Fritzpoll (talk) 21:40, 2 January 2009 (UTC)
38. Support There's not going to be anything negative from trying. Stop being picky eaters and eat the damn vegetables! §hep • ¡Talk to me! 22:01, 2 January 2009 (UTC)
39. Support, this is a very sensible first step. We can change who are reviewers, and other configuration items, after we have made the first step. Some are worried there is a scaling problem: I seriously doubt that the community as a whole will be overwhelmed, as implementing this will mean that some tasks no longer need to be done with as much urgency (e.g. reverting vandals; NPP). My opinion is that this extension will be a net time saver, but of course the first few weeks are going to be extra busy as we learn the subtleties of the feature, and the addon tools like Twinkle may take a few weeks to be ready to help us process this queue quickly. John Vandenberg ^(chat) 22:22, 2 January 2009 (UTC)
40. Tactical Strong Support, because I think this is the stupidest idea I have ever heard of, and I would like to see it fail as soon as possible so we can archive it as a really bad idea, and be done with it forever. Jerry delusional ¤ kangaroo 22:57, 2 January 2009 (UTC)

    I agree. Why not demonstrate what a ridiculous idea this is, so we can avoid it actually happen. Jonathan321 (talk) 04:33, 4 January 2009 (UTC)

41. Worth a try If it goes down in flames at least we'll know to look for other options. Dance With The Devil (talk) 23:42, 2 January 2009 (UTC)
42. Support I think I explained my reasoning before, so I don't repeat here. -- Taku (talk) 00:30, 3 January 2009 (UTC)
43. Qualified Support As scalability is a major issue, I would prefer a full real test on a defined subset of vwey actively edited articles rather that the proposed trial which might not reach levels where real results will be seen. Data from a potentially very limited test might not be valid if the use of flagging were extended to large numbers of articles. The earlier real data is gathered, the better. I also have some concernes with "reviewers" as a new level of authority rather than extending sighting to all editors with sufficient experience (who, presumably, are quite unlikely to be the vandals we seek to prevent). Collect (talk) 00:56, 3 January 2009 (UTC)
44. Support - All previous efforts on controlling vandalism and unwanted edits have been frustrating to participate in, when so many people look through the same revision again and again, without any control on what's already been done. A patrolling system without visual indicators to raise the attention and interest of editors can't get sufficient participation either, when there is no cue and no visible effect. Flagged revisions has all of this, and I believe enough users will participate when it's available, like they have with Wikipedia generally. --Para (talk) 01:12, 3 January 2009 (UTC)
45. Support --Jake Wartenberg^Talk 01:28, 3 January 2009 (UTC)
46. Strong support, for a number of reasons.
    • Firstly, I'd like to point out the necessity of a trial—so much of the English Wikipedia community's understanding of this feature has been shaped either by rumour, gut feeling, or opinion, not by hard, proven facts. A trial—multiple trials, even—is necessary if we are ever to reach the point where we can all engage in an intellectual, reasoned debate over the flagged revisions extension.
    • Secondly, reliability is paramount to an encyclopedia project—whether or not said encyclopedia is produced via strong collaboration. Reliability gives knowledge value, not openness. This feature actually does not harm openness itself, it merely gives experienced users an opportunity to engage in constructive checking and review of edits made by others. This two-person approach is important from both a practical and a scholarly approach.
    • Thirdly, Wikipedia currently suffers seriously from malicious edits that can seriously damage the lives and reputations of real people—most notably, libellous alterations. We have a moral duty to our readers, and to the subjects of our articles on biographies of living persons, to ensure that libel and other forms of disasteful, horrible material do not appear publicly.

    Please support this feature! – Thomas H. Larsen 03:12, 3 January 2009 (UTC)

47. Strong Support. I've been here for four years and never, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever did I think this day might actually come. RyanGerbil10(Four more years!) 04:54, 3 January 2009 (UTC)
48. Support Esp for BLP. --mav (talk) 06:00, 3 January 2009 (UTC)
49. Strong Support - way overdue. Let's just do this please - even in a limited way, but let's get started. Note that this is a trial and not some sort of permanent implementation. Let's see what the trial results in, and re-evaluate. To the opposers - supporting this is not the end, it's just a step along the path, so let's just use it to obtain real data here - Alison ^❤ 06:19, 3 January 2009 (UTC)
50. Support - should have been done in 2007. I've had some wild and wrongful things written about me on Wikipedia. It will be helpful to see exactly which characters flag through the libelous garbage. Which will hopefully beget a sense of responsibility, and thus less garbage. -- He called me with jack high (talk) 06:49, 3 January 2009 (UTC)

    Is the expectation here that reviewers will have some form of legal experience? Would you take action against a reviewer if under the Flagged Revision system he/she becomes somehow particularly 'responsible' for the passing of material you deem "libelous garbage" but they mistakenly or willingly don't see it the same way. MickMacNee (talk) 07:28, 3 January 2009 (UTC)

51. Broadly Support, although I'd like to see the permissions handed out a bit more liberally. As many people say, the trick is to get something up and running, and then we can look at how it's performing, and what changes we might like to make. I support flagged revisions in general, and I therefore support getting anything sensible and small-scale up and running, lest we remain stuck in a permanent quagmire of deciding what colour we would like our wheels to be. — Werdna • talk 07:01, 3 January 2009 (UTC)
52. Support the proposed setup. I generally support FlaggedRevs, but still have questions about the feasibility of the backlog and other problems. This setup will allow us to explore these issues instead of standing still as we have been doing for too long.--Danaman5 (talk) 08:33, 3 January 2009 (UTC)
53. Qualified Support; the proposed trial on letter-limited BLP articles seems very clever. The qualification is that there be a strong presumption that after the trial FR not be implemented, unless the trial is a superbe success ~ a success agreed to by a super-majority of users. Probably this is what sdsds meant by Sunset Provisions below. Cheers, Lindsay^Hi 08:48, 3 January 2009 (UTC)
54. Support I believe that this can only be an improvement, but we absolutely need a trial to confirm whether that's true or not. Bring it on!Anaxial (talk) 09:28, 3 January 2009 (UTC)
55. Support We won't know if this is good or bad if we don't try. I'm rather optimistic that a trial doesn't spell total doom either way. – sgeureka ^t•c 11:34, 3 January 2009 (UTC)
56. Support - good configuration for small-scale trials. --B. Wolterding (talk) 12:36, 3 January 2009 (UTC)
57. Support, let's try it for a set amount of time, it will allow us to judge if it is ready for prime time. --Steven Fruitsmaak (Reply) 13:12, 3 January 2009 (UTC)
58. Support; article protection, particularly semi-protection, is woefully overused. Anything at all to take the edge off of that is a welcome change. I'll take a little delayed gratification rather than not being able to edit an article at all any day. HiDrNick! 13:17, 3 January 2009 (UTC)
59. Dubious support, I'm not personally convinced that flagged revisions is a great idea, but I'm open to it being tested - and BLPs seems a good place to do so. My largest concern is that, after a brief period of novelty value, a huge backlog of revisions to be sighted will develop; so if any kind of long-term backlog develops during a smaller-scale test I'd encourage people to consider how badly a site-wide implementation is going to go. ~ mazca ^t|c 13:18, 3 January 2009 (UTC)
60. Support, but only on a very small subset by now (maybe on what is currently known as "semi-protected articles"). I tried the demo and am happy with it, I just have a problem with the comment field of the sighting dialog: Am I required to write a comment just to say "I have read this article and found no blatant nonsense in it" ? Nicolas1981 (talk) 13:20, 3 January 2009 (UTC)

    Sighting is equivalent of stating that there is no vandalism in the article. Comments are optional. Ruslik (talk) 13:24, 3 January 2009 (UTC)

61. Replacing semi-protection with flagging seems like an obvious improvement. Including BLPs seems reasonable too. But why guess? Needs to be tested, sooner the better. Angus McLellan (Talk) 13:50, 3 January 2009 (UTC)
62. Support trial. I have strong reservations about this idea, but let's see how it works in practice. There should be a wide selection of articles inlcuded in this trial, otherwise the results won't be meaningful. The trial should include at least two of the following: FA article, BLP article, science article, controversial politics article. In each category there should be one high traffic and one low traffic article (traffic with respect to edits/day, not views). Xasodfuih (talk) 13:53, 3 January 2009 (UTC)
63. Support per my comments on the BLP feeler survey. ~~ [ジャム]^[t - c] 14:03, 3 January 2009 (UTC)
64. Support trial, because it should be abundantly clear that this issue isn't going to disppear without a trial, and because we had a 2 to 1 margin in favor during the last poll on implementing for BLPs (Wikipedia:Protecting BLP articles feeler survey) ... but only for BLPs. There's more to say, but I'll wait til we have some trial data to discuss. - Dan Dank55 (send/receive) 14:07, 3 January 2009 (UTC)
65. Support Makes watchlisting easier. — Edokter • Talk • 14:19, 3 January 2009 (UTC)
66. Support: worth a trial, then we can decide whether to implement it or not. bahamut0013^words_deeds 14:24, 3 January 2009 (UTC)
67. Yes do it If it doesn't work turn it off. Spartaz ^Humbug! 14:26, 3 January 2009 (UTC)
68. Strong support. If it doesn't work, we can turn it off. Massive benefits if it works, no long-term drawbacks if it does not. Ironholds (talk) 14:35, 3 January 2009 (UTC)
69. Strong Support -- It is an excellent limited trial. This protracted pro and con debate about flagged revisions could continue ad infinitum, but is yet only based on theory. A real world test will finally provide some concrete evidence to decide on the practicality of flagged revisions for the English Wikipedia. It is time to move forward and get some answers. — CactusWriter | ^needles 14:40, 3 January 2009 (UTC)
70. Support Ealdgyth - Talk 14:46, 3 January 2009 (UTC)
71. As soon as possible, especially on BLPs. -- Jeandré, 2009-01-03t14:50z
72. Strong support: It's about time! - BillCJ (talk) 14:59, 3 January 2009 (UTC)
73. Support - it's a good idea, which has been in use over at de:wikipedia for a while now. A trial run should expose some of the issues and benefits of such a system. – Toon^(talk) 15:05, 3 January 2009 (UTC)
74. Timid support - this is trial basis only, and appears to have potential. I'm quite worried however that it will greatly confuse many editors (especially new ones - "where's my edit?"), and the advancement of pages will slow down considerably. At very least, we should and must place a note on top of the edit page, if not the regular page itself. Magog the Ogre (talk) 15:20, 3 January 2009 (UTC)
75. Support I haven't had the time to check through the tiny minutiae, but the limited proposal seems sound, and is a way for our quality to increase without locking out anonymous edits entirely. Der Wohltemperierte Fuchs ^(talk) 15:22, 3 January 2009 (UTC)
76. Support Given that so much of my watchlist is filled with random vandalistic edits and/or reversions, I look forward to seeing if flagged revisions can help. --moof (talk) 15:25, 3 January 2009 (UTC)
77. Support Good experiences in de-WP. --Leyo 15:27, 3 January 2009 (UTC)
78. Support with skepticism – There are potential problems with a full-scale implementation that a small-scale test will not make apparent. The test must include high and low traffic pages. The test should include some newly created pages. I am concerned with the effect on little-watched pages where reliable editors make quality changes, and are then unable to make those changes appear to the public. Any wide implementation should include a usergroup whose edits are trusted and auto-sighted - to not have that would mean pointless extra work sighting the edits of trustworthy editors. Of course, un-trusted editors means known vandals and newbies, and we don't want to discourage newbies by making their edits not show up. Vandalism is a drawback to the nature of a wiki; this proposal addresses that by taking some of the positive wiki nature out of the wiki. — Swpb^{τ • c} 15:43, 3 January 2009 (UTC)
79. Support, Tom Harrison ^Talk 15:56, 3 January 2009 (UTC)
80. Support trial - It goes slightly against Wikipedia's slogan -"anyone can edit" as only 'reviewers' will be able to change the content displayed on the page instantly, but still worth a try. I think 'reviewer' flag should be given to all autoconfirmed users. --Unpopular Opinion (talk) 15:59, 3 January 2009 (UTC)
81. Support — Past due, really. This is great. Cheers, Jack Merridew 16:03, 3 January 2009 (UTC)
82. Support. The time has come to make a proper usable trustworthy encyclopedia available to the user. The only way to do this now is to present guaranteed reviewed content to them. I might propose to limit it to FAs and possibly GAs though - that is, stuff where the main content has consensus and been worked over a lot. Articles in development (i.e., everything else) may benefit less. Unusual? Quite ^TalkQu 16:28, 3 January 2009 (UTC)
83. Support. I like the idea, as i think it would really help the stability aspect. --♬♩ Hurricanehink (talk) 16:33, 3 January 2009 (UTC)
84. Very Strong Support per Unpopular Opinion. Willking1979 (talk) 16:35, 3 January 2009 (UTC)
85. Support – Potentially a very useful enhancement to the wiki, merits a full trial. Rjwilmsi 16:42, 3 January 2009 (UTC)
86. Support per my comment further down the page. Just make sure the specifics of implementation are reasonable. Estemi (talk) 16:51, 3 January 2009 (UTC)

    By "reasonable", I mean that only well-developed articles (eg B quality or higher) should have flagged revisions and "stable" pages. Obviously, requiring gainsaying/approval for ALL changes on Wikipedia would be a huge mistake and cripple the growth of early-stage articles. Flagged revisions should be in place on high-traffic pages. Estemi (talk) 17:02, 3 January 2009 (UTC)

87. Support for reasons already stated by many others above me. CIreland (talk) 17:07, 3 January 2009 (UTC)
88. Strong, happy, enthusiastic support. It's a test, not an implementation, and empirical testing is the way to find out whether it is good or bad, whether the fears of the opponents will prove true or not. No rational person should fear finding out the truth. I'd gladly support a test of SP too. --Tryptofish (talk) 17:20, 3 January 2009 (UTC)
89. Support - for the reliability of WP. --Harald Khan Ճ 17:27, 3 January 2009 (UTC)
90. Support - let's see if it works. Tim Vickers (talk) 18:01, 3 January 2009 (UTC)
91. Support. I would need to see this in action in order to form any opinion about it. dissolve^talk 18:03, 3 January 2009 (UTC)
92. Support - nothing to lose, everything to gain. See if it works. Ale_Jrb^talk 18:21, 3 January 2009 (UTC)
93. Support SU Linguist (talk) 18:41, 3 January 2009 (UTC)
94. Support Not perfect, but a move in the right direction. faithless (^speak) 18:41, 3 January 2009 (UTC)
95. Support - full protection is harmful. If there are enough reviewers to not let a backlog form, I'd happily trade the immediacy of edits becoming live (not much more than ego-boosting anyway) for the ability to really have every page editable by anyone. --Waldir ^talk 19:21, 3 January 2009 (UTC)
96. Conditional support Soon as someone writes a Huggle-like recent edits patrol program. —/Mendaliv/^2¢/_Δ's/ 19:30, 3 January 2009 (UTC)
97. Support -- Commdor {Talk} 19:50, 3 January 2009 (UTC)
98. Strong support per all above. —Preceding unsigned comment added by Quantumobserver (talk • contribs) 20:02, 3 January 2009 (UTC)
99. Support - As others have said: this is a test. Regardless of whether you oppose or support it, let's find out if it works. Burnedthru 20:06, 3 January 2009 (UTC)
100. Support To be blunt - screw wiki-philosophy - I want some damn data. Lets go get some results on FlaggedRevs and then have our ridiculous arguments afterwards.--Tznkai (talk)
     • This proposal lacks the conditions - specifically the control group - that would get us data. Septentrionalis PMAnderson 20:14, 3 January 2009 (UTC)
     • I can't agree, Sept. The data would not be as controlled as one might wish, but it will still give us information.sinneed (talk) 20:57, 3 January 2009 (UTC)

101-200

1. Support Brad 20:22, 3 January 2009 (UTC)
2. Strong support - While I am unsure that this model is workable, I am confident we will learn important lessons that cannot be learned through discussion only.
   :On reviewing comments within the test and playing with this version a bit more...I am more confident that the test is good, and I think we will miss a great opportunity if we don't try this in the real world. It seems to me to be a great way to reduce admin workload and general frustration when an article is under attack by vandals or the subject of an edit war: a way to let people continue to edit, perhaps even sort out their squabble without the rest of the world being subjected to their behaviour. Much less disruptive than page protection.— Preceding unsigned comment added by Sinneed (talk • contribs)
3. Support --McSly (talk) 20:31, 3 January 2009 (UTC)
4. Support trial. I am skeptical about flagged revisions. In particular, if introduced, I think they should essentially only be used to deal with vandalism, on a simple sighted/unsighted basis, with no further elaboration, and that sighting should (if technically possible) expire after a short time period. However, the only way to see whether concerns are genuine obstructions or not is to try the thing out. Geometry guy 21:14, 3 January 2009 (UTC)
5. Support - I think it is worth a small scale test at the very least, usually not everything is comes out as expected with discussion, and a trial is not going to destroy Wikipedia. I am not too concerned with the specificness of the proposal, if the trial results are skewed I am sure there will be plenty of people around to point it out and discredit it. Camaron | Chris (talk) 21:18, 3 January 2009 (UTC)
6. Support - it's worth a go, to see whether it works or not for us. Mike Peel (talk)
7. Support - Xxanthippe (talk) 21:56, 3 January 2009 (UTC).
8. Support No harm in seeing what happens. If it turns out to be terrible, it can always be deactivated. -ruby.red.roses 22:33, 3 January 2009 (UTC)
9. Support. Suggest striking all votes (on either side) by people who obviously don't understand what flagged revisions actually are. Phil Sandifer (talk) 22:39, 3 January 2009 (UTC)

   Determining who has an obvious misunderstanding requires some judgment. It's better to talk and explain the situation to them—hopefully it will lead them to a more informed opinion. Ozob (talk) 23:50, 3 January 2009 (UTC)

10. Strong Support a trial is the best way to see if the claims (by both sides of the debate) have merit and get an idea if the benefits outweigh the costs or vice versa. Eluchil404 (talk) 22:42, 3 January 2009 (UTC)
11. Support. Let's give it a try and not dismiss it out of hand. – ukexpat (talk) 22:50, 3 January 2009 (UTC)
12. Reluctant support. Let's see how it works. What worked for Wikipedia until now may not necessarily be the best thing in the future. On the other hand, flagged revisions may prevent us from implenting something even better. GregorB (talk) 23:18, 3 January 2009 (UTC)
13. Guarded support. I see others here, who, like myself, are not certain about the wisdom of out-and-out adopting flagged revisions for BLPs, much less as a whole. But since in the discussions above I have indicated my support for the idea of applying them to BLPs until they reach a certain length or quality level as a way of reducing the potential liability risk from an overlooked BLP turned into a platform for a defamatory attack, I would support a trial run that would probably make up a lot of minds (However, if we want to see about the efficacy of FRs as a deterrent to vandalism, let's apply it not to BLPs but to articles about secondary schools, and see if we then see a corresponding decrease in the amount of anon-IP blocks in the period afterwards). Daniel Case (talk) 23:45, 3 January 2009 (UTC)
14. Support; It is only a trial after all... --Deenoe 23:45, 3 January 2009 (UTC)
15. Support. Not an ideal trial, but a necessary first step to broader revision flagging. —Simetrical (talk • contribs) 23:47, 3 January 2009 (UTC)
16. Support We need to start investigating other methods of protecting BLPs from libel besides the ineffective semiprotection. Foxy Loxy ^Pounce! 23:48, 3 January 2009 (UTC)
17. Support; this is a good first step. — Coren ^(talk) 23:53, 3 January 2009 (UTC)
18. Support. This could significantly improve Wikipedia. In my experience, the vast majority of IP edits are not constructive, and I think that removing the possibility of 'instant gratification' for vandals would dramatically reduce the appeal of vandalism. All IP edits and edits made by registered users with less than around 100 mainspace contributions should be flagged. I am not persuaded by the argument that this will deter sincere contributions because the people who really want to improve Wikipedia will either create an account so that their contributions are not flagged (after they pass the threshold) or simply accept that their IP edits will be delayed. – SJL 23:55, 3 January 2009 (UTC)
19. Support — it's worth a try, after years of talking. - Mark 00:42, 4 January 2009 (UTC)
20. Support. I'm not entirely confident they'll work, but I think it's worth giving them a limited trial. Judging from the goings-on at perpetually contentious processes such as RfA, the community is rapidly losing its ability to achieve consensus on any substantive change in policy. I think it's important to encourage limited experiments like this so that we can evaluate alternative policies on the basis of actual data, or we will wind up drowning in our own accumulated dogma. Choess (talk) 00:52, 4 January 2009 (UTC)
21. Support, though the mess of new user groups created should probably be simplified before any full-scale implementation. I have always thought, why not let any visitors (including IPs) sight page revisions, and then revisions that have reached a certain threshold can be considered free of vandalism.--Michael White^T·C 01:01, 4 January 2009 (UTC)
22. --Chris 01:14, 4 January 2009 (UTC)
23. Support - I will support the idea but I don't think this will last long. A testrun on enwiki is what we need :) ...--Cometstyles 01:40, 4 January 2009 (UTC)
24. Support - Due to curiosity; although I dislike the general idea it might be useful with protected and semi-protected pages that are normally off limits.--_ZXCVBNM 02:03, 4 January 2009 (UTC)
25. Support. We need to trial this to really see whether it works and improves things. --Bduke (Discussion) 02:05, 4 January 2009 (UTC)
26. Very Strong Support I like the idea a lot. I always belived in testing, and it will help cut down on vandlism. The vandlism would have to be approved first, like that's gonna happen. I like it. Also, new content can be verifed. Bab (talk) 02:08, 4 January 2009 (UTC)
27. Support. Something along these lines has been needed for several years; vandalism is still rampant on English Wikipedia. If Wikipedia is ever to become a respected encyclopedia, it cannot allow vandalism to continue unchecked. It's my hope that the chosen flaggers will be an intelligent group of individuals who will bring some measure of reliability to the project. Firsfron of Ronchester 02:12, 4 January 2009 (UTC)
28. Support. This seems to be a good plan. I notice that the test page seems to default to showing the draft when not logged in. Otherwise it behaves as expected. Phatom87 ^{(talk • contribs)} 02:44, 4 January 2009 (UTC)
29. Strong support. This will help to increase the credibility of Wikipedia. TerriersFan (talk) 02:56, 4 January 2009 (UTC)
30. Strongest conceivably possible support. To address those below: a quality control process does not destroy the "anyone can contribute" model. Open source software uses something very similar, where anyone can contribute a patch, but submissions from those who are not well-known to the community have their submissions vetted by someone who's trusted and knows the project well. After enough good submissions, such a person becomes known to the community and becomes one of those trusted members. An analogue to a widely used and generally successful system in open content deserves at least a trial here. Seraphimblade ^{Talk to me} 03:04, 4 January 2009 (UTC)
31. Support - It's overdue. Snappy (talk) 03:17, 4 January 2009 (UTC)
32. Support - Happy to see how a trial goes Camw (talk) 03:28, 4 January 2009 (UTC)
33. Support Barrylb (talk) 04:03, 4 January 2009 (UTC)
34. Very Strong Support - To alleviate the concerns of those who oppose the idea, the trial should start on a small scale and expand from that if it proves to be successful. Flagged revisions has the ability to save editors an awful lot of time by not having to fix up rampant vandalism. -- Alan Liefting (talk) - 04:23, 4 January 2009 (UTC)
35. Support I'm not convinced any harm will come of a trial whereas not doing one seems guaranteed to engender issues - and I have issues with issues. -- Banjeboi 04:46, 4 January 2009 (UTC)
36. Support. Everything is speculation until we try it and while a small-scale trial will not address concerns regarding scaling, some insights can be gleaned with a trial than with none at all. --seav (talk) 04:58, 4 January 2009 (UTC)
37. Strong Support. I think this system would go a long way toward improving Wikipedia's credibility. It certainly sounds like a useful idea on paper. It might prove unmanageable, but the only way to know is to actually try. --ThaddeusB (talk) 05:39, 4 January 2009 (UTC)
38. Support. Limited trials of this feature seem like a good idea. I am worried about its potential for harm to the project, but I am also worried (and have been for some time) that the current Wikipedia model may not be stable in the long term (decades, not years). A feature like this could be sufficient to stabilize it, preventing vandalism from degrading articles that do not have sufficient attention from editors.--Srleffler (talk) 06:18, 4 January 2009 (UTC)
39. Support It's only a trial. Matthewedwards (talk • contribs • email) 06:45, 4 January 2009 (UTC)
40. Support, no harm in a trial. If it turns out to be impractical, it can always be rolled back. Lankiveil ^{(speak to me)} 07:06, 4 January 2009 (UTC).
41. Support It's been a long time in coming. Enigma msg 07:39, 4 January 2009 (UTC)
42. Support apart from all theoretical concerns, it already does work well elsewhere (de-wiki, pl-wiki...) Pundit|utter 07:59, 4 January 2009 (UTC)
43. Support - Support a trial to see how this will work on a practical level. Cirt (talk) 08:25, 4 January 2009 (UTC)
44. Support: Flagged Reviews is an essential tool within the wiki environment. We don't just need to write and revise articles, we also need a fully-reliable way to rate them and present reviewed material to our readers. Implementation of ER is about the maturing of the wiki process. Dovi (talk) 08:37, 4 January 2009 (UTC)
45. Support - providing that there would be an easily-accessible automatically-generated list of which pages had the system enabled... for example, Special:FlaggedPages or something. ╟─TreasuryTag►contribs─╢ 08:38, 4 January 2009 (UTC)

    We'll get Special:ReviewedPages. Happy‑melon 10:41, 4 January 2009 (UTC)

46. Support - FlaggedRevs would allow semi-protected pages to be unprotected, which would make Wikipedia more open, not less—greenrd (talk) 09:59, 4 January 2009 (UTC)
47. Support - agree with Dovi just above. If we don't do this we are going to have to stop IPs from editing or, I think, there will be a slippery slide downhill. dougweller (talk) 10:44, 4 January 2009 (UTC)
48. Support - it's working well on de and pl. Enwiki Exceptionalism doesn't exist. // roux   11:01, 4 January 2009 (UTC)
49. Support -- and BLP is not the only category which could benefit! I believe unregistered users should generally be under more pressure to register. Macdonald-ross (talk) 11:23, 4 January 2009 (UTC)
50. Support Woody (talk) 11:43, 4 January 2009 (UTC)
51. Support Flagged reviews are necessary to make them more reliable and reduce vandalism.Pharaoh of the Wizards (talk) 11:52, 4 January 2009 (UTC)
52. Support For the reasons stated above. Jon513 (talk) 11:59, 4 January 2009 (UTC)
53. Strong Support I use de.Wiki a lot and have seen how their system works. It will prevent the juvenile vandalism which is such an embarrassment to Wikipedia. Mikeo1938 (talk) 12:40, 4 January 2009 (UTC) Forgot to mention that the monitor (surveyor?) need not be a full-blown administrator ... just someone with an interest and a feeling of responsibility towards certain pages. Mikeo1938 (talk) 12:44, 4 January 2009 (UTC)
54. Support with Reservations I concur that all administrators should default to the 'surveyer' capacity, but would also encourage the 'reader' position to be automatically granted to all current and future registered members (if implemented past a trial scenario, obviously). There is, of course, also the Pandora's box aspect of this proposal, wherein one day all articles will use this system. hornoir (talk) 12:56, 4 January 2009 (UTC)
55. Strongly Support A wonderful asset for all BLP articles .Alexnia (talk) 13:10, 4 January 2009 (UTC)
56. Support First, it's a trial so no harm. Second, for those fearing the end of Wikipedia and its spirit- Wikipedia is already stagnating as it is. This new feature may actually contribute to user retention, something nobody seems to be willing to address or even realize as a major problem. Too many good contributors have been leaving simply because they ran out of patience for continuously fixing the articles within their scope of action. Not to mention that flagging could prove extremely effective against vandalism. Húsönd 13:39, 4 January 2009 (UTC)
57. Support for now, with the hopes that this will never be implemented on a whole namespace. It could be usefull as an alternative to page protection however. — Twinzor ^{Say hi!} 14:01, 4 January 2009 (UTC)
58. Support. Hemmingsen 14:14, 4 January 2009 (UTC)
59. Support Robin klein (talk) 15:29, 4 January 2009 (UTC)
60. Support w/Reservations: I'll support a trial, in the hope that Flagged Revisions are used as an alternative to page protection only when needed (when implemented), not automatically, and that they not extend beyond BLP. Additionally, I would tend to feel that by default, all registered users with some threshold of edits should have monitor/surveyor status, not just administrators. That will hopefully speed up activity, and give editors a extra good reason to register and edit more. Jo7hs2 (talk) 16:04, 4 January 2009 (UTC)
61. Support: Absolutely, a trial in a small scale is a fantastic way to approach this and I'll be excited to see how it pans out. The opposition seems concerned with changing the way things just are, but this type of attitude will not lead to progress and doesn't hold up when the proposal is for a relatively mild trial basis. Nja247 (talk • contribs) 16:42, 4 January 2009 (UTC)
62. Support a trial run on carefully-selected articles. If this is actually implemented, then I would only support it on BLP articles. ~AH1^(TCU) 16:51, 4 January 2009 (UTC)
63. Support idea, oppose this poll Trying flaggedrevs on a subset of articles is a good idea, but this poll would have been better conducted if it actually specified one particular trial to run. GDonato (talk) 17:34, 4 January 2009 (UTC)
64. Generally support a trial of some sort, although it seems weird to me that the immediate outcome of this RfC would seem to me to be...yet another RfC to determine which, if any, trials to run.--Aervanath lives in the Orphanage 17:49, 4 January 2009 (UTC)
65. Support This will require refinement in both the tools and the "culture" of WP, but seems like an appropriate and proportionate response to the challenges of maintaining the quality of content here. --Scray (talk) 18:15, 4 January 2009 (UTC)
66. Support While I'm not entirely sold on the concept of FlaggedRevs, I think a trial will be the best way to see how this will work in practice. A few of the issues brought up by the detractors (i.e. the potential for a huge backlog) may or may not actually happen, and with a trial, we can see if they will or not. TheCatalyst31 ^{Reaction•Creation} 18:23, 4 January 2009 (UTC)
67. Support Captain panda 19:19, 4 January 2009 (UTC)
68. Support this trial. Let's give this a try already. I think the results will be very positive. Mahanga^Talk 20:21, 4 January 2009 (UTC)
69. Support as I see nothing wrong with testing something to see how well it really works. ···日本穣^{? · Talk to Nihonjoe} 20:35, 4 January 2009 (UTC)
70. Meh - Can't hurt to give it a go. -- Cheeseman Muncher (talk) 20:36, 4 January 2009 (UTC)
71. Support - Why not? — D. Wo. 20:37, 4 January 2009 (UTC)
72. Support - Too much user time is spent reverting vandalism to articles whose content should be stable, and such vandalism has serious adverse impacts on Wikipedia's credibility. Just today, I reverted a seriously erroneous change to Behavior modification that had gone unnoticed for several weeks. I often see egregious vandalism to U.S. Census data included in articles about U.S. geographic locations. "Flagged revisions" could reduce the adverse impact of this kind of vandalism. --Orlady (talk) 21:18, 4 January 2009 (UTC)
73. ayematthew @ 21:19, 4 January 2009 (UTC)
74. Support--Peter Andersen (talk) 21:20, 4 January 2009 (UTC)
75. Weak Support it's a test in it's infancy stage. Slysplace ^{talk ♫} 23:13, 4 January 2009 (UTC)
76. one of the three planks which should be implemented yesterday - yes please :-) Privatemusings (talk) 23:16, 4 January 2009 (UTC)
77. I don't necessarily support FlaggedRevs, but I do support a small, restricted trial. That way we will actually have evidence of how it will affect en Wikipedia, rather that relying on conjecture. My only suggestion would be to grant 'surveyor' to all administrators by default. seresin ( ¡? )  23:18, 4 January 2009 (UTC)
78. Support Nesseccary to the long term success of wikipedia. Nn123645 (talk) 23:31, 4 January 2009 (UTC)
79. Support - Worth a shot. لennavecia 23:32, 4 January 2009 (UTC)
80. Support a limited trial. Until we try this in practice it isn't really possible to conclude how it will work here so I feel we should give it a go at least. Adambro (talk) 23:33, 4 January 2009 (UTC)
81. Weak Support - I'm not entirely convinced of the practicality of the proposa. I have particular doubts about whether the community as a whole will keep up with reviewing a lot of more esoteric pages. That said, I'd be quite happy to be proven wrong, and we won't know until we try it in the fairly limited way that's proposed. - Chrism would like to hear from you 23:50, 4 January 2009 (UTC)
82. Support - We are learning as we go with this project. This would be one more tool in our tool kit to better understand how to proceed with the Wikipedia project. The more we know the better... E_dog95' ^{Hi '} 00:03, 5 January 2009 (UTC)
83. Support, although the initial trial should be limited to maybe the top 300 articles (by vistits), or to FA articles. OSX (talk • contributions) 00:09, 5 January 2009 (UTC)
84. Support - let's see how it goes. -FrankTobia (talk) 00:42, 5 January 2009 (UTC)
85. Support - but only for BLP's and Semi/Full Protected articles. » \ / (⁂ | ※) 02:52, 5 January 2009 (UTC)
86. Support - It's time to move Wikipedia toward being a more reliable, stable source of information, not one that can be defaced by any passing stranger. -- BlastOButter42 ^See Hear _Speak 03:24, 5 January 2009 (UTC)
87. support - absolutely some trials, and likely the full implementation. --Rocksanddirt (talk) 04:56, 5 January 2009 (UTC)
88. Strong Support; I believe this can serve to improve the perception of Wikipedia and reduce random Vandalism. I would like to see "project" members able to "approve" or "publish" the versions. -- Mjquin_id (talk) 05:10, 5 January 2009 (UTC)
89. Support - Let's give it a try and see if we like it --Megaboz (talk) 05:40, 5 January 2009 (UTC)
90. Support - I agree that this systems seems like it might be better at preventing vandalism than some existing methods. I think that those on both sides of this issue should remember that we are debating a trial and not a full scale roll out, and we should look very carefully at the results of this trial before we consider expanding this system. Optimusnauta (talk) 05:45, 5 January 2009 (UTC)
91. Support - Involve projects. I also hope that the new user rights will not become as 'bereaucratic' as adminship has become. Will be a major incentive to editors adding content and will decrease burn out and frustration among 'good' editors. Great to have a trial before scaling. prashanthns (talk) 06:26, 5 January 2009 (UTC)
92. Support - let's give it a try Mayalld (talk) 07:42, 5 January 2009 (UTC)
93. Support - Flagged revision will help handle a lot of issues, so the sooner we have it implemented the better. I fully support a trial on articles that benefit from it as long as the size of the trial can be handled by the amount of editors involved. - Mgm|^(talk) 09:10, 5 January 2009 (UTC)
94. Support – well worth a trial. If done right, it could work like Mjquin_id says above. /skagedal^talk 09:33, 5 January 2009 (UTC)
95. Support' - Classical geographer (talk) 10:22, 5 January 2009 (UTC)
96. Support Must be done. MBisanz ^talk 13:09, 5 January 2009 (UTC)
97. Support -- lucasbfr ^{ho ho ho} 13:12, 5 January 2009 (UTC)
98. Support - A trial will help answer questions the community has. Awadewit (talk) 14:33, 5 January 2009 (UTC)
99. Support - Let's do it, already! --Cerebellum (talk) 14:41, 5 January 2009 (UTC)
100. Support - Other wikis get it to work, why can't we? The Placebo Effect (talk) ^{How's my editing? Please contribute to my editor review.} 15:15, 5 January 2009 (UTC)

201-300

1. Support - This will clear misconceptions about the process and has already been demonstrated to have a reasonable degree of success on the German Wikipedia. SBC-YPR (talk) 15:32, 5 January 2009 (UTC)
2. Support - Implement it for now on BLPs, and this will give us the ability to assess it better. עוד מישהו Od Mishehu 16:20, 5 January 2009 (UTC)
3. Support This idea was proposed more than 4 years ago. User:Larry Sanger called it "Sifter". One of the developers wrote a software patch for it, and even got up a test wiki just to showcase it. I never understood why it fizzled. This is only a test. If it has bad results, no harm done, and we will learn something from it. If it works, great! --Uncle Ed (talk) 16:28, 5 January 2009 (UTC)
4. Support It's high time we stopped hypothesizing and had a go at it. --Zvika (talk) 17:45, 5 January 2009 (UTC)
5. Support Absolutely no harm in a trial, and we'll see where this goes. Change can be good. Artichoker^[talk] 17:55, 5 January 2009 (UTC)
6. Support Why not? A trial does no harm. -- Mufka ^{(u) (t) (c)} 18:00, 5 January 2009 (UTC)
7. Support FlaggedRevs and specifically setting up for the planned trials. Splitting the decision between principle and specific details of trials is a good idea, and I note that the quality of the specific proposed trials has improved a lot since this poll started, mainly due to edits by users who (unfortunately) are still opposing this motion. Now we have some feedback on the German experiment and it seems to be scaling OK (>92% of pages currently have their most recent page sighted), and is doing its basic job of shutting out most vandalism. If it was the disaster some are claiming it would have been switched off by now; furthermore, we could configure it better than their current set-up. PaddyLeahy (talk) 18:24, 5 January 2009 (UTC)

   Well, shutting out most vandalism is done by the RC patrol, you don't need flagged revisions for this. As we have produced (though hard to measure) several MB of discussion already I'd be interested in your suggestions for "configuring it better than their current set-up". Once in a while new ideas do show up but only rarely by now. --X-Weinzar (talk) 15:29, 7 January 2009 (UTC)

   I sometimes think RC patrollers oppose FlaggedRevs because it will spoil their game or something, although of course they could just as usefully patrol the special pages listing unflagged revisions. Needless to say at present RC patrollers can't get rid of the vandalism before it has been displayed to readers for a finite time. As for improvements over the de version lots have been discussed, my favorites include (1) actually turning off semi-protection where no longer needed (2) extending the "sighter" permission to a larger fraction of the community, on an automatic basis, and (3) only applying flagged revs to articles which really need it (I would include BLPs, FAs, and currently semi-protected and protected pages). PaddyLeahy (talk) 11:03, 8 January 2009 (UTC)

8. Support Looks like a great idea. I'm all for it. Cdhaptomos talk–contribs 18:47, 5 January 2009 (UTC)
9. Support - on a trial basis, why not? Jauerback^dude?/_dude. 18:59, 5 January 2009 (UTC)
10. Support as a trial. I think much good can come from this. Martijn Hoekstra (talk) 19:05, 5 January 2009 (UTC)
11. Support. --Kbdank71 20:08, 5 January 2009 (UTC)
12. Support: We absolutely do need new tools. A trial is a good idea. Sunray (talk) 20:26, 5 January 2009 (UTC)
13. Support: If it causes the world to abruptly end, we can always just reboot and try again, leaving out progress this time. Kevin Baas^talk 20:42, 5 January 2009 (UTC)
14. Support: Looks good. Let's try this! --wwwwolf (barks/growls) 21:04, 5 January 2009 (UTC)
15. Strong Support: I'm mainly active in the German Wikipedia, where I am also a sysop. FlaggedRevs really improved our quality and I think this can be done here as well --Church of emacs (Talk) 21:16, 5 January 2009 (UTC)

    Could you please explain why you think the quality has really been improved? Please consider how much time could be spent working on articles instead of flagging articles. --X-Weinzar (talk) 15:38, 7 January 2009 (UTC)

    The reliability of the quality has greatly improved, as much more vandalism is being detected with FlaggedRevs (which means coordinated control of _all_ edits by non-established users) than without. I've started a (quite large) list with cases of vandalism that have only been detected because of FlaggedRevs. This is an even greater problem on enwiki, as much vandalism is missed in regular CVU. Oh, and articles are flagged mostly by users who do cleanup anyway, so don't worry: there will be enough people still working on writing new articles. --Church of emacs (Talk) 01:21, 10 January 2009 (UTC)

16. Support Rgoodermote  23:01, 5 January 2009 (UTC)
17. Support. Sooner the better. Kaiwhakahaere (talk) 23:18, 5 January 2009 (UTC)
18. Support. It's important that we try this. Basing decisions on guesses is ridiculous, let's get some evidence to work with. -- Earle Martin [^t/_c] 23:20, 5 January 2009 (UTC)
19. Support I am most curious to try this out. That doesn't mean I approve, just life's not worth living without the odd risk. Alientraveller (talk) 00:29, 6 January 2009 (UTC)
20. Support. Neither side of the whole flagged revisions debate will gain any real ground until we get some data. I can't think of a better test methodology than what's proposed here. -- Ken g6 (talk) 00:31, 6 January 2009 (UTC)
21. Support per some arguments above familytree101 (talk) 00:40, 6 January 2009 (UTC)
22. Support Trial needed to refine arguments for or against LeeVJ (talk) 01:57, 6 January 2009 (UTC)
23. Support. This is just a proposal to allow the configuration that will make trials technically possible. Any initial trials will most likely be quite limited in scope, and those trials will be key to determining whether flagged revisions is a good idea or not. Many of the arguments I've seen both for and against flagged revisions are based on what theoretically should happen. However, theoretically speaking, based on what most people assumed before Wikipedia started, Wikipedia could never work. For a project that works only in practice, more empirical evidence of flagged revisions' effect is definitely a good thing. Pyrospirit (talk · contribs) 02:09, 6 January 2009 (UTC)
24. Support. Go for it. Alaney2k (talk) 02:15, 6 January 2009 (UTC)
25. Support it has been a very very long time since this extension was developed... At last can we use it? Prodego ^talk 03:03, 6 January 2009 (UTC)
26. Support - Tried the prototype and it seems reasonable. LouScheffer (talk) 04:09, 6 January 2009 (UTC)
27. Support I don't think we have enough editors to double-do everything, and so this is only support for a trial. -SusanLesch (talk) 05:23, 6 January 2009 (UTC)
28. Support - We have to try this out! I love this idea, because it will help us a great deal with the WP:1.0 project, but of course it needs to be done the right way. Walkerma (talk) 05:43, 6 January 2009 (UTC)
29. Support for featured articles. =Nichalp «Talk»= 06:55, 6 January 2009 (UTC)
30. Support. Those who can't even endorse a trial program such as this go through should be swiftly banned from the project. It isn't helpful. JBsupreme (talk) 06:58, 6 January 2009 (UTC)
    • Best. Vote. Ever. "I vote X, and anybody who votes Y should be banned". Sherurcij ^{(speaker for the dead)} 07:17, 6 January 2009 (UTC)
    • Comment: I am a supporter but many of the opposition have provided constructive criticism about the methodology and have been civil in expressing reasonable disagreement about whether the trial is ready to be undertaken. Please be civil in return and respect their opinions. This kind of attitude will only polarize discussion and make the supporters seem unreasonable. Dcoetzee 07:21, 6 January 2009 (UTC)
    • Dude. Chill out. Go look at some pictures of cats. Ozob (talk) 07:25, 6 January 2009 (UTC)
31. Support. If the results of any trials are not to our liking, we can always return to the status quo. But FR may be a real improvement, unlike patrolled pages. Fram (talk) 09:59, 6 January 2009 (UTC)
32. Support, just to enable a trial, the specifics of which I expect will be the subject of further debate. Personally, I'd currently support a single trial on Living People articles. Also I'd prefer users to become reviewers automatically though so that there is less bureaucracy and management overhead.. eug (talk) 10:04, 6 January 2009 (UTC)
33. Support, my experiences with FlaggedRevisions are so far good. --Eivind (t) 10:36, 6 January 2009 (UTC)
34. Support no amount of speculation can beat an experiment. —Ruud 15:04, 6 January 2009 (UTC)
35. Support maybe at first as an alternative to protection, and on featured articles. —Snigbrook 15:44, 6 January 2009 (UTC)
36. Strong Support it is only through trial that its effectiveness can be deturmined. Grika Ⓣ 15:47, 6 January 2009 (UTC)
37. Alpha, Beta and Pilot Testing at first then if sucessful: Implement: plus some way needs to be found to hide defamatory edits too. --Marianian (talk) 15:51, 6 January 2009 (UTC)
38. Support - a trial is a trial is a trial. The community in German wikipedia is very different from the English one in many aspects. After the trial new ideas may emerge. `- 7 bubyon>t 16:24, 6 January 2009 (UTC)
39. Support Subject to expressed limitations. Phil_burnstein (talk) 17:22, 6 January 2009 (UTC)
40. Support -- Xenus (talk) 18:41, 6 January 2009 (UTC)
41. Support: I oppose flagged revisions because I think they're a bad idea. But a trial should show people how good they really are, better or worse. CRGreathouse (t | c) 18:52, 6 January 2009 (UTC)
42. Qualified support. Good alternative to page protection, provided its use is limited to articles where consensus determines that it's clearly and immediately needed - which should be very, very few. Give it a shot. Nothing wrong with a trial. Graymornings_(talk) 18:56, 6 January 2009 (UTC)
43. Suppert. At dewiki it works successfully. --Obersachse (talk) 19:12, 6 January 2009 (UTC)

    Could you please explain what you mean by "successfully"? --X-Weinzar (talk) 15:38, 7 January 2009 (UTC)

    Isn't it succesfull, when about 90% of all articles are proofed? It means, they are vandal-free, have sources, interwikis nd categories. I think, that is very successful. --Obersachse (talk) 13:23, 8 January 2009 (UTC)

44. Support. We should've done this ages ago. Increased accountability and oversight can only be a good thing.--Hemlock Martinis (talk) 19:21, 6 January 2009 (UTC)
45. Strong Support. Pretty please. The future of the human race depends on this. Kaldari (talk) 20:17, 6 January 2009 (UTC)
46. Support. This is absolutely needed to maintain the quality of articles as they are constantly edited and improved. Letsgoridebikes (talk) 20:34, 6 January 2009 (UTC)

    The system of "anyone can edit (almost) anything and see his/her changes immediately" has worked great so far. Why change it now? --X-Weinzar (talk) 15:38, 7 January 2009 (UTC)

47. Support (and I did strongly oppose) on the condition that no reader article grading (think YouTube) is introduced. At all. J Milburn (talk) 20:46, 6 January 2009 (UTC)
48. Support Happy to support trial, although eventually would probably only support for small subset of articles. Suicidalhamster (talk) 22:15, 6 January 2009 (UTC)
49. Support - wikipedia is now large enough that this feature can be supported. That said I think this will have less of an impact then most people think. --T-rex 23:24, 6 January 2009 (UTC)

    Support changing position to oppose as currently implemented in the demo link - see my entry under opposed - but I do still agree with the rest of my original post that follows: - Testing is the only real way to come up with a rational decision as to will it work or not, or will it help or hurt. With limited testing having the least posible negative impact should things not workout as advertised. Dbiel ^(Talk) 02:46, 7 January 2009 (UTC)

50. Support - WP would benefit from incorperating aspects of content management systems. Its worth trying, cautiously, to determine if it can be done well.--Thesoxlost (talk) 03:45, 7 January 2009 (UTC)
51. Support as it works perfectly on de.wiki — Jan Hofmann (talk) 04:13, 7 January 2009 (UTC)

    Works perfectly? 1 in 5 editors in de.wp left the project because of this. OhanaUnited^{Talk page} 04:39, 7 January 2009 (UTC)

    Works perfectly? Right, editors have to wait up to 20 days to see their changes approved or refused. I wouldn't exactly say it's a mess but I suggest you explain what led you to the conlusion that it works perfectly. On the other hand I'd love to have a source for "1 out of 5 have left". You can't just throw in such a number Without a source or at least some explanation. While there have been heavy debates (and still are going on) whether it is a success or not I doubt that 1 out of 5 (!!) have left the project. --X-Weinzar (talk) 09:31, 7 January 2009 (UTC)

    I was under the assumption that once you have become an autoconfirmed editor [I don't know de.wiki's requirements] your edits appear instantly. — Jan Hofmann (talk) 10:48, 7 January 2009 (UTC)

    Oh okay, it does work from the technical point of view, that's what you mean I guess. However, the question to be addressed is whether it's useful overall. And I'm not talking about my contributions but about how anonymous editors will be discouraged from editing. --X-Weinzar (talk) 14:32, 7 January 2009 (UTC)

52. Support. I believe that anonymous (not logged in) editing should be disabled, so implementing a bit of an article review process is definitely a good idea, especially if it is only a trial. —Gordon P. Hemsley→✉ 08:00, 7 January 2009 (UTC)
53. Support Absolutely we need a trial. I know that most IP edits are of value, but there are some articles where that is not the case. ϢereSpielChequers 10:21, 7 January 2009 (UTC)

    That's what semi-protection is there for. IPs can place their suggestions on the talk page. --X-Weinzar (talk) 14:36, 7 January 2009 (UTC)

54. Strong Support This is why it was created, no harm at all in a trial. Timmccloud (talk) 15:00, 7 January 2009 (UTC)
55. Support - While WP is "the encyclopedia anyone can edit", it is clearly a double-edged sword. I think if we discouraged the "any anon IP can insert whatever into articles and see it immediately" aspect of WP, I think we could reduce the amount of oversighting requests, BLP problems, and even edit warring, because the "holding pen" before approving edits would moot the purpose of fighting on the articles directly. It will be far more useful for some articles than for others, but it should at least be tried. MSJapan (talk) 17:52, 7 January 2009 (UTC)
56. Support Definitely worth a trial, and has the potential to improve overall quality. JavaTenor (talk) 18:35, 7 January 2009 (UTC)
57. Support Eusebeus (talk) 19:47, 7 January 2009 (UTC)
58. Support For all that we may learn from giving it a limited try. Mfield (talk) 21:56, 7 January 2009 (UTC)
59. Get on with it. Sarcasticidealist (talk) 23:28, 7 January 2009 (UTC)
60. Support, this should have been done ages ago. -- Visviva (talk) 02:15, 8 January 2009 (UTC)
61. Strong support. Andre (talk) 02:40, 8 January 2009 (UTC)
62. Support A trial won't hurt. --Russavia ^Dialogue 06:59, 8 January 2009 (UTC)
63. krimpet✽ 07:35, 8 January 2009 (UTC)
64. Absolutely. The oppose reasons are completely unconvincing. A test would be very useful. Tombomp (talk/contribs) 10:51, 8 January 2009 (UTC)
65. Support - we've been discussing this for years. Let's run a trial, then the debate can finally move forward; we'll have some actual evidence as to whether flagged revisions are desirable and, if so, how best to implement them more widely. Warofdreams talk 11:11, 8 January 2009 (UTC)
66. Support a trial. Mosheroni (talk) 13:18, 8 January 2009 (UTC)
67. Secret ^account 13:58, 8 January 2009 (UTC)
68. Support a restricted trial, certainly. I'm rather sceptical but I would quite like a trial on BLPs. --Cameron* 15:10, 8 January 2009 (UTC)
69. Support a trial. Vandalism should be dealt with by reverting the bad edits, and blocking or banning the vandals, not by protecting pages (except possibly in extreme cases). I believe that page protection is used far too much today. I expect that Flagged Revisions will make it easier to deal with vandalism, and will reduce the incentive to use page protection. A trial, or several trials, will enable us to figure out whether Flagged Revisions are useful. —AlanBarrett (talk) 17:48, 8 January 2009 (UTC)

    Protection is not only applied for vandalism. And only in extreme cases of vandalism are pages protected. MickMacNee (talk) 18:37, 8 January 2009 (UTC)

70. Support with Conditions - Before this trial commences, I would like to see the following in place:

    • Start and end dates.
    • Planned target articles, definitions of what the selection criteria is, what the process will be for adding/removing articles from trial scope
    • Plan on how the user experience will be managed during the trial (article notices etc)
    • Defined success/failure criteria
    • Defined emergency escape criteria
    • Risk assesment - server/infrastructure, admin/maintenance, backlogs, user/editor experience
    • Defined user/editor processes the feature will create
    • Defined changes to existing user/editor/admin processes

    You may wish to respond to these points on my talk page. Many thanks, Gazimoff 17:55, 8 January 2009 (UTC)

71. Support alanyst ^/talk/ 18:46, 8 January 2009 (UTC)
72. Support - From my experience in RC patrolling, there is a dire need for such a mechanism in sensitive articles (such as BLPs). Gail (talk) 20:59, 8 January 2009 (UTC)
73. support - give it a go, see what happens William M. Connolley (talk) 23:42, 8 January 2009 (UTC)
74. Support - Zginder 2009-01-09T03:57Z (UTC)
75. Support - I'm frequently seeing libel that goes for hours or days or longer without being reverted. This is not an acceptable situation. This is the type of thing that just needs to be implemented by fiat by the foundation rather than to continue to allow "wiki purists" to stifle progress. --B (talk) 05:09, 9 January 2009 (UTC)

    reply It is not "wiki puritism" making me oppose. This proposal means the "anyone can edit" line is, effectively, no longer true. This proposal takes what makes Wiki so attractive and turns it ugly. I would assume, with respect, that your examples of month long unchecked libel is not accurate. doktorb _words^deeds 05:15, 9 January 2009 (UTC)

    You are assuming that libel only comes from IPs. You are assuming that assessing libel is only ever simple and black and white issue. You are assuming that libeled subjects do not have access to registered accounts and will find it any more "acceptable" that they can only be libeled for 4 days or more in front of thousands of registered users, or that they would be any less likely to seek redress. If the issue is truly libel, and this is not just a poster child for closing up the project, then we should take full measures that actually address the problem, and not merely take half measures that sweep it under the carpet. How many users for instance regularly take on the task of copyeditting BLP articles tagged as unreferenced? Is it "acceptable" to have an unreferenced BLP article at all? Only as long as it is not visible to the outside? MickMacNee (talk) 16:02, 9 January 2009 (UTC)

76. Support - Some opposers object because they say it violates anyone can edit but f.r. won't stop anyone from editing just that what becomes live to the world will be delayed until reviewed. I think this is especially needed for biographies due to the possible harm that could be caused. It's a simple trial and it would give those of us curious about it a much better gauge of its effectiveness, pros/cons. RedWolf (talk) 06:57, 9 January 2009 (UTC)
77. Support, I have some issues with the cosmetics of how FR is presented, but from a technical point of view it seems potentially helpful. Far better than simply protecting or semi-protecting a page. —Locke Cole • t • c 09:10, 9 January 2009 (UTC)
78. Support - We are the biggest online encyclopedia in the world, and must have certain standards to what content is added accordingly (especially very sensitive articles). Vandalism rates dropping will allow more editors to focus on furthering the cause. This hopefully will increase the credibility Wikipedia has in the community. Full support. If there are problems with the F.R's, we will see them, catch them, and respond to them.
79. Support. So far so good with my experiences on de-wp. The risk of a good-faith edit failing to show up for a week or so is more than compensated for by the virtually complete elimination of visible vandalism. I frequently encounter vandalism here that has gone unreverted for months on end, typically because it was quickly followed by a good-faith edit made by someone who hadn't noticed the vandalism, and all that shows up on people's watchlists is the most recent edit. If FR work here the way they do at de-wp, that won't happen, because all revisions have to be checked before the page can go live. And the "anyone can edit" principle is not impaired even remotely; I really fail to understand that argument. —Angr 14:41, 9 January 2009 (UTC)

    From my perspective, most of the people who simply 'cannot see a problem' with FR (rather than those would want a trial to assess it) are entrenched experienced Wikipedia users who see everything in terms of how it affects their watchlist or their user experience (see above, there are plenty of examples of this), and take their existence as a registered user as representative of Wikipedia contributors as a whole, without any appreciation that instantaneous (not delayed or subject to approval) IP editing is (was?) a fundemental feature of Wikipedia. I have no problem delaying/interfering/confusing that feature if it can be shown that the obvious benefits of it (drawing in new users, the ease of use, the perception as an open unbeaurocratic project, the instant correction of non-vandalism factual errors by IPs etc etc) are not wiped out by FR for the benefits to registered users lives. And frankly, I am uncomfortable with a delay of hours, if we are honestly saying it is more like weeks based on an already implemented practical example, I would certainly never have bothered signing up to Wikipedia. MickMacNee (talk) 15:42, 9 January 2009 (UTC)

    Imho it should not be about registered vs unregistred users, but about readers and the product. If FR prove overall beneficial to the quality/content of WP and its readers you them otherwise don't. However the only way to find out is a test run.--Kmhkmh (talk) 16:41, 9 January 2009 (UTC)

    Mick, I do appreciate that instantly appearing IP editing is a traditional feature of Wikipedia, but full protection and semiprotection - both of which have long been fully implemented - interfere with that feature to a much greater extent than flagged revisions do. And whether the revision goes live in minutes or weeks depends on how highly watched the article in question is. Pages that are on a lot of people's watchlists will have their changes flagged very quickly; pages that are on few people's watchlists may have to wait somewhat longer. I suspect that things will move faster here than they do on de-wp simply because there are so many more active logged-in users here than there. —Angr 16:48, 9 January 2009 (UTC)

    This is making several assumptions about the benefits of FR based on conflicting implementations. If it is only applied to protected articles, you are not preventing vandalism very much as a percentage of all articles. And protection is not done simply for vandalism, so it will not be able to be wholly removed just because FR is applied. If it is applied to all articles, you are inconveniencing by a massive factor IPs more than protection does right now, and that is before we even get into the sublte difference in interaction with new users between the active process of requesting an edit to a protected article, and the try it and see aspect of FR. And just because we have more users, does not mean that we don't have hundreds of thousands of articles wih less than 5 people watching them. These reviews will definitely require putting in a pool of unreviewed pages. MickMacNee (talk) 17:07, 9 January 2009 (UTC)

    Well, for the test version of FR, we'll have to see whether they're only applied to (semi)protected pages or how the test works, but of course a full-fledged version of FR would apply to all pages, and would hopefully (and probably) reduce the total number of pages that would have to be semiprotected. (No one ever said FR would completely obviate (semi)protection.) But flagged revisions don't inconvenience IPs at all, and don't inconvenience registered regulars any more than RC and watchlist patrolling already do. The "pool of unreviewed pages" can stay where it's always been, at Special:RecentChanges. —Angr 20:44, 9 January 2009 (UTC)

    I don't think we have the same definition of inconvenience, for IP users or registered users (not all registered users will be Reviewers). In fact, users who never feel the collective burden that drives people to patrol, but gain Reviewer status anyway, will positively benefit, at the expense of IPs and non-Reviewers, even though all are supposedly still equal stakeholders when it comes to building content. MickMacNee (talk) 01:44, 10 January 2009 (UTC)

80. Support - having worked with them on the German wikipedia my overall experience is positive so far.--Kmhkmh (talk) 18:35, 9 January 2009 (UTC)
81. Strong support - there's a reason why so many people distrust Wikipedia's verifiability, and why so many people will not allow Wikipedia to grow any further as a trustworthy encyclopedia. Seeing the phrase 'the encyclopedia anyone can edit' automatically puts some people off, whilst drawing others in (for the right reasons or the wrong) -- I think the idea of flagged revisions is perfect for helping iron out those things that bring down our reputation. ≈ The Haunted Angel 16:59, 9 January 2009 (UTC)

    That depends on whether the FR process will come anywhere near to ensuring an article meets the principle of verifiability. If the review process starts to resemble the GA/FA review process, where these things are properly checked, then why pretend FR is anything other than an upfront enforced QA system, disbarring any well meaning edits made by newcomers who are not experienced in policy. If the FR process is simply meant to be a seconds long check for blatant vandalism, then obviously anyone who then thinks Wikipedia is more verifiable because FR exists is going to to be sadly dissappointed if they do even the most cursory of investiagations. If the goals is to highlight to readers potentially untrustworthy edits, rather than implement FR, we may as well code the interface to add {citation-needed} or {verify me} to the end of any text added to an article by an IP user. MickMacNee (talk) 17:26, 9 January 2009 (UTC)

    I guess we won't know unless we have a trial where verifiability is included in the parameters. If we don't, we'll see no improvement in the respect on other trials and be able to move on with our lives without FR. But you gotta trial it first :) Fritzpoll (talk) 17:36, 9 January 2009 (UTC)

82. Strong Support Like The Haunted Angel mentioned, this will transition Wikipedia from an encyclopedia that anyone can edit, to one where anyone can propose edits which is really what is required by the academic community. Furthermore, one can hope that this feature will remove the need for article protection, which really is censorship. -- KelleyCook (talk) 18:34, 9 January 2009 (UTC)
83. Support The great is the enemy of the good. This is a reasonable step for BLPs, and worthy of a trial on a subset of those. If the problems predicted below materialize, we can drop it. However, the potential benefits are significant, and worthy of the attempt. Xymmax ^{So let it be written} _{So let it be done} 20:38, 9 January 2009 (UTC)
84. Support: BLP is an issue we need to address, not before time. This tool can reduce the drive-by problem there significantly. That argument is within the traditional way here, of stepwise coping with real issues that can threaten the project. Charles Matthews (talk) 21:38, 9 January 2009 (UTC)
85. Support - provided that the trial conditions are properly set this seems a good way forward. The problems foreseen by the opposers may or may not manifest themselves but that is the reason for a trial. Better we trial and see if there are net benefits than not trial and never know. Smile a While (talk) 22:20, 9 January 2009 (UTC)
86. Weak Support As a replacement to semi-protection.--Res2216firestar 22:28, 9 January 2009 (UTC)
87. Weak Support As a replacement to semi-protection --GeometryGirl (talk) 22:42, 9 January 2009 (UTC)
88. Support It would be good to try this. It may have very good effects in the long run. --Bwwm (talk) 01:11, 10 January 2009 (UTC)
89. Support Anything that will control the chaos on BLP's would help. A 'known good' page link will be a useful tool. Mytwocents (talk) 02:24, 10 January 2009 (UTC)
90. Support. It is time to start learning things rather than theorizing about how Flagged revisions will work. Mangojuice^talk 06:10, 10 January 2009 (UTC)
91. Strong Support - missed vandalism (RC) like [1] must not happen, but does often enough (there are more and better (respectively 'worse') examples, I just cannot find them in my logs right now, but you all know anyway wow: it turned out that the article actually is a real prime example, absolute negative); finding vandalism by coincidence is not acceptable! --Melancholie (talk) 07:30, 10 January 2009 (UTC)

    Vandalism on such an insignificant article isn't of importance. If we did FlagRev on all articles, there would not be enough manpower to validate the onslaught of edits; most of which are fine. - RoyBoy 16:55, 10 January 2009 (UTC)

92. Support --Jan eissfeldt (talk) 09:27, 10 January 2009 (UTC)
93. Support 211.30.119.55 (talk) 11:14, 10 January 2009 (UTC)
94. Strong Support - due to positive experience in the German Wikipedia. Raymond (talk) 12:22, 10 January 2009 (UTC)
95. Tentative support as a great idea on paper, but with the minor caveat that due to the inertia that often seems to develop with these things, a 'trial' that goes badly may be more difficult to undo and cause more damage than we might anticipate. EyeSerene^talk 13:33, 10 January 2009 (UTC)
96. Support with the addition to automatically publish some articles after a certain time if no one have cleared the flag. --Jimmy Bergmark (talk) 14:39, 10 January 2009 (UTC)
97. Support I am curious to see how well this will work, and how it won't work. Quality Control needs to be taken seriously, and fast reverting cannot also always be counted on, even for heavily trafficked articles. - RoyBoy 16:49, 10 January 2009 (UTC)

Oppose

0-100

1. — Aitias // discussion 18:04, 2 January 2009 (UTC)
2. to conduct one or more trials is to vague Mion (talk) 18:13, 2 January 2009 (UTC)

   Each trial will require a separate consensus; we can support or oppose each on separately. This proposal is just to give us the technical ability to conduct any trials at all. Happy‑melon 18:20, 2 January 2009 (UTC)

   If the first trial request fails support by the community there is no reason to implement the configuration ? Mion (talk) 18:28, 2 January 2009 (UTC)

   There is if the second request succeeds. If every request fails then the implementation remains completely unusable, so does no damage. We can implement the technical changes without committing ourselves to actually doing any trials, but we can't do any trials without the technical changes, so it makes eminent sense to do the changes first before getting into the details of specific trials. Happy‑melon 18:49, 2 January 2009 (UTC)

   IF the second request for a trail succeeds, its early enough for this vote, you save the energy of doing the unusable implementation ?Mion (talk) 18:58, 2 January 2009 (UTC)

   I don't see your point. If the first, or second, or third, or fourth, or nth trial gains consensus, we will need this implementation. So we would need to have this discussion and straw poll in any of those instances. If none of the trial proposals gain consensus, there is no harm whatsoever done by having this extension inactive in the background. 99% of the "energy" required to implement this proposal has already been expended, the effort required to finish it off is trivial. It would actually be more effort to not proceed with this proposal than to continue. Happy‑melon 19:04, 2 January 2009 (UTC)

   I trust this is not a declaration of intent to poll until you get your way; but the implementation is unnecessary, and undesirable, until there is consensus on how to implement it.Septentrionalis PMAnderson 19:10, 2 January 2009 (UTC)

   Certainly not; "my way", like everyone else's personal preference for FlaggedRevs, is one distinct set of policies that I suspect is going to be one of the more popular trial choices. If it fails to gain consensus, "I" have nothing to gain from proposing a myriad of variations. But the reason the general FlaggedRevs discussion has run round in circles for the past six months is because every man and his dog has "his way" and dearly wanted wikipedia to implement it as our one-and-only shot at FlaggedRevisions, thereby splitting the "general support for some implementation of FlaggedRevs" camp into dozens of parts. With this proposal, we can ask everyone to cough up their ideas again, have a think about which ones might be the best, even try the top few to see how they work. Then we can make an informed decision about which one, if any, is best for wikipedia, and how (if) to deploy it. I have seen no reasoning whatsoever to suggest that having this implementation without a consensus to use would be in any way "undesirable". Happy‑melon 22:36, 2 January 2009 (UTC)

3. Very Strongly oppose. The fundamental problem with flagging is a problem of scale, as explained here; this "test" avoids the real questions (although it would be fascinating, and unsurprising, if flagging proved to be ineffective even at the small scale.) In addition, the creation of a new flag for sub-admin status is another step of bureaucracy and ego, which we have always consistently opposed. See also #bots? and #neither test please, below. Septentrionalis PMAnderson 19:08, 2 January 2009 (UTC)

   I agree that this proposal does not consider many of the questions that we need answers for before deciding on a final implementation of FlaggedRevs. It's not supposed to. It's supposed to provide evidence to inform us when we make those decisions. It would indeed be fascinating to see that flagging proved ineffective in the trials. I think we should be given the opportunity to see for ourselves. In regards your other reason, I point you in the direction of rollback, IPBE, account-creator... we don't seem to have opposed the creation of additional user groups very "consistently" so far. Happy‑melon 23:29, 2 January 2009 (UTC)

   Then it's not ready. This poll is about two things confounded: whether to have a test at all (which I would support) and whether to use this structure, which I absolutely oppose. Most of the support !votes are on the first question only; they should be separated. Septentrionalis PMAnderson 18:27, 3 January 2009 (UTC)

   Interesting; I agree with your assessment that this proposal covers only the two areas you mention. When you say "this structure", what exactly do you refer to? Do you oppose because the 'structure' contains things that you actively disagree with, of just because you believe it is not sufficiently complete? Happy‑melon 21:16, 3 January 2009 (UTC)

   I actively disagree with any proposal to make sighted status another handout at will, a sub-admin status; it should be acquired automatically. Beyond that, this proposal should have added to it the conditions suggested by us opposers, which would increase the information generated and decrease its potential for actual harm. Septentrionalis PMAnderson 21:24, 3 January 2009 (UTC)

   • I also oppose any system which means that logged in editors do not see what our readers see. WYSIWYG. Septentrionalis PMAnderson 19:13, 6 January 2009 (UTC)

   For the record, the median sighting time at the German Wikipedia is one week three weeks (still unacceptable), and it is taking some effort to keep it that low. Until this drastically changes, I take all assurances that FR is "working" there with several grains of salt. Septentrionalis PMAnderson 20:16, 3 January 2009 (UTC)

4. Oppose - for two reasons, at least. First, in this proposal 'bots are given more capability than registered users. That represents an underlying flaw in the thinking of those who propose this "solution." Second, the terminology invented by this proposal, specifically but not limited to "sighted" and "unsighted", has no commonly understood meaning in American English that maps well to the underlying implementation. (sdsds - talk) 19:07, 2 January 2009 (UTC)

   I prefer to think of it in terms of how we populate the 'reviewer' user group. In an ideal world, we could independently review every user for editor status, and approve them individually. Unfortunately, we also have to get a substantial number of reviewers immediately or any FlaggedRevs implementation will inevitably fail. So we consider "which groups of editors can we promote en masse to reviewer status?" Essentially, where have we already judged a group of editors to be at least trustworthy enough to be reviewers? Admins are obvious candidates; we trust them with much more than mere sighting. Rollbackers ditto. As for bots, consider what we're really giving them. Bots are just scripts that repeatedly do actions that have community consensus, actions that would be too numerous for humans to do manually. As such, every action performed by a bot must meet the low standard to be considered 'sighted', as they must also meet the much higher standard of having community support. However, it would not be appropriate for bots to go around sighting edits made by other editors, which is why if you look closely bots are given the autoreview permission but not the review permission. So when a bot makes an edit on top of a sighted revision, that edit is automatically sighted - if we didn't do this then someone would have to run around behind all of our maintenance bots sighting their edits manually, which completely defeats the purpose of having a bot in the first place. But when a bot makes an edit on top of an unsighted revision, that set of edits is not sighted, as is quite appropriate since the underlying edit needs human review. Bots are already given access to permissions that are not available to registered users; why is giving them a few more somehow taboo? I'm not going to comment on your second point, although if you want to 'translate' the terms into ones that make more sense to you and other American editors, we'd be delighted to see such translations. Happy‑melon 19:22, 2 January 2009 (UTC)

   So only admins and bots can actually change the visible form of test articles? I regret not being able to make my opposition stronger. Septentrionalis PMAnderson 19:39, 2 January 2009 (UTC)

   I got that as saying admins, rollbackers, bots (autorev), and then most likely ACC. The other users could get approved individually if they wanted to be reviewers. §hep • ¡Talk to me! 22:05, 2 January 2009 (UTC)

   Admins, rollbackers, bots in certain situations, and anyone else who asks for and receives the 'reviewer' user right. This proposal makes no statements about who may be elegible for the latter category; that's for us to decide, and decide very clearly, at a later date. I will eat my hat if the consensus on that is not "give 'reviewer' to anyone who asks for it unless there is an obvious reason not to". Happy‑melon 22:40, 2 January 2009 (UTC)

   Then write it into the proposal. If Happy melon is right, it will draw no objections. Septentrionalis PMAnderson 18:27, 3 January 2009 (UTC)

5. Oppose. First, the proposal would enable a specific configuration of flagged revisions, but the proposal admits that it would not scale to wide deployment. Why even test a system like this? We should turn FRs on only to trial either a fully working system or a simplified version of that system. We should not trial FRs with a configuration that does not reflect how they would be used in practice. If there is no consensus for what a working system might look like, then there is no consensus for how to trial FRs! So the present proposal is premature.

   I realize that part of the reason for the proposal is to find a good configuration through experience. But that experience will be wasted if the trial configuration is not similar to the configuration we want to use on a wider scale. The experience we get with the wrong configuration could lead us to make the wrong decision: Either to use FRs when we should not, or to not use FRs when we should.

   Second, the proposal provides for no way to test whether this configuration is any good. Even if the proposal reflects current consensus for an FR implementation, it could be that the implementation will fail in practice. The only way to determine this is through testing, but the proposal does not provide any tests. Without any tests, how will we know whether the configuration works? The tests need to state which articles FR will be applied to, for how long, and how the tests will be ended when they are over. Without that, the proposal is incomplete.

   The present proposal says that it is designed to let us conduct multiple tests of FRs. Two possible tests are at Wikipedia:Flagged revisions/Trial/Proposed trials. But turning on FRs and testing them are a package deal. Without tests, we cannot tell if the FR implementation is the right one; and if we are testing FRs, then we are trying to tell if our FR implementation is the right one. Leaving tests out ensures that we cannot tell whether FRs work or not.

   As a consequence of all of this, I oppose the proposal as it is written. Ozob (talk) 21:49, 2 January 2009 (UTC)

   I'd argue that even if the proposal is technically very different from the final wide-scale implementation, as long as the user interface is similar it's still valuable as a mock-up for an experiment. A version of the final system would be ideal, but I think it's better to test something to motivate and direct future changes, so that we can begin iterating. Dcoetzee 22:10, 2 January 2009 (UTC)

6. Per This post. But it looks like I'm in the minority. If we do go with a trial, a gradual implementation should be rolled out (few thousand articles a week, tops.)NuclearWarfare ^{contact me}_{My work} 22:47, 2 January 2009 (UTC)

   Strike per Jerry (currently #38 in supports). Tis nothing but a tactical move. I'm sorry, but I wouldn't be terribly sad if this failed.

7. Oppose: For the reasons I explained here. - Rjd0060 (talk) 22:48, 2 January 2009 (UTC)
8. Oppose. Vague scope of the test (who picks the articles to be censored), vague review procedure (FAC level? NPP level?) etc. NVO (talk) 01:02, 3 January 2009 (UTC)

   The proposal is deliberately vague deliberately does not consider such points, becuase we're not trying to decide on any particular details such as those at this point. Each trial will require a separate consensus on precisely the details you note. All we're doing here is saying "if we get that consensus, we want to have the technical ability to implement it". Happy‑melon 11:04, 3 January 2009 (UTC)

   Why do you want a vote on a vague proposal????? What is that supposed to accomplish????? Ozob (talk) 20:54, 3 January 2009 (UTC)

   I'll strike that; you're correct that vagueness would be extremely unhelpful. Rather, I'll say that the proposal "deliberately does not consider" some areas. The reason for this is, in all honesty, to break this hugely complicated process down into bite-size chunks that we can actually chew on. Right now we have "part 1" in its final stage: this poll. "Part 2" is still in a discussion stage; although it was not anticipated, I'm absolutely delighted that the high publicity of this poll is bringing in a very wide range of participants to that discussion, which I think is likely to come up with a much more balanced set of trials, not least because we have people involved who are looking for negative data as well as positive. I think that's a very healthy thing, but it's not something that would have happened if we had 'completed' that discussion as well and then rolled the two proposals into one before coming to the wider community. Yes, we'd only have had to have one community-wide poll, but reduced wider participation is not, IMO, a good thing. You've said somewhere else that you understand the impossibility of changing the subject of a poll while it's in progress; if you accept the necessity for a final poll to demonstrate consensus, then you understand the inevitable contradiction: every new person to such a wide discussion brings in new ideas many of which you'd dearly like to include, but at some point the metaphorical foot has to come down and you have to say "no, we need to consider one static version". In my opinion, being able to say "Ok, we've made these parts static and we want you to !vote on them, but we'd also very much like your contributions to the other parts which are still fluid while you're here..." is the best of both worlds. Do you disagree? Happy‑melon 10:58, 4 January 2009 (UTC)

   OK, good, that correction reads much better. I agree that it's good to break things in to small chunks. But I guess I don't see the overall picture. You and several other users brought forward this proposal with some larger plan in mind, and that plan still isn't entirely clear to me or, it seems, to a lot of other people. That plan may not be entirely clear to you, either, because you may not have worked it out yet. But without that sort of plan, how do we know where we'll go from here? How will we decide what tests to run? When will the tests happen? Where will their success or failure be discussed? Who will judge whether to continue running tests or to stop? And so on. Not knowing these things leads people to absurd fears about cabals. I'm sure you can detect a hint of paranoia in more than a couple of the "oppose" comments.

   Of course, I fall pretty heavily on the planning-in-advance side. (You can see evidence of this at the extremely long list Wikipedia:Flagged_revisions/Trial/Proposed_trials#Possible metrics to measure success of trials. I'm sure I'll think of more things to add, too...) I'm naturally inclined to doubt proposals that don't spell everything out, and unfortunately this proposal is one of those. Ozob (talk) 00:34, 5 January 2009 (UTC)

   If the trial calls for censoring access to one single article, no mater how stable, then the choice of this article must be clear and public. It's not. NVO (talk) 19:45, 3 January 2009 (UTC)

   Indeed, becuase it hasn't been decided yet. There's no point in pouring hundreds of hours of time and energy into fighting our way to a consensus on that decision if there's no technical ability to implement it once we finally decide. I can promise you that that later proposal will be just as clear and public as this one. Happy‑melon 20:51, 3 January 2009 (UTC)

9. Oppose Wikipedia has always worked on a basis of trust, we have always said that being an admin is nothing special and most importantly its an encyclopaedia that anyone can edit. Flagged revisions says you can edit but your edit cant be seen we dont trust you. It places importance on having tools creating an importance that shouldnt be there. The worse thing is flagged revisions makes the presumption that all edits are malicious and increases the power of POV pushers/Cabals to control article content. In all of this people appear to be loosing sight of the characteristics that made Wikipedia what it is. Gnangarra 01:29, 3 January 2009 (UTC)

   I agree with Gnangarra, when you treat people as equals then you get respect and dedication. The proposal represents old style thinking where 'experts' determine what is wrong and right. New style thinking says let the reader of the article decide what level of accuracy they want by selectable option. If such a capability were available then the present proposal would be unnecessary.--Wildplum69 (talk) 08:03, 4 January 2009 (UTC)

   Protected and semi-protected articles are already putting up barriers to people editing. With Flagged Revisions we could make it easier for people to edit problematic pages, without necessarily having to protect or semi-protect them. That could increase participation, not decrease it.—greenrd (talk) 10:04, 4 January 2009 (UTC)

10. Opppose I cannot support any move to technically implement Flagged Revisions for a series of trials until there are actual concrete proposals for how the specific trials will be undertaken, specifically, the articles to be included, the duration, the method of reviewer approval, and the specific data to be collected to show success/failure. The current set of four suggested trials all use the same duration and method of reviewer approval, so I could not support any of them as I don't agree with either a 2 month duration or an admin approval process. Additionaly, the proposed questions to be answered by the trials miss out a fundemental point, will Flagged Revisions increase the level of perceived beaurocracy to the point where potential contributors/contributions are lost? It is all very well tinkering at the edges by measuring backlogs or the changes in the amount of 'reader exposed' vandalism, but if you don't propose to measure the effect on one of the fundemental basic advantages of Wikipedia, then what's the point of the trials? I consider myself an experienced editor now, obviously with an account, but that all started from the gradual introduction to the site's ways from making sporadic IP edits. The up front complexity of Flagged Revisions looks to me at least to have massive potential to deter those intial good faith IP contributions which can then lead to better things. I want absolute assurance that these trials will be able to provide proof they will be a net benefit to the project in that respect. MickMacNee (talk) 01:47, 3 January 2009 (UTC)

    Expanding on my theme of what this proposal needs to commit to measuring, before it even gets to a stage of fine tuning trial details, here are some questions I think need adding to the proposal page Procedural implementation section:

    What effect, if any, does the Flagged Revisions nature of delayed visibility for edits made by constructive unregistered users have on their overall contribution history, and on the total and ratio of conversion of unregistered into registered users?

    What effect, if any, does the use of sighting to filter out basic errors have on the perceptions of the factual accuracy of unsourced or unreviewed but sighted articles?

    What effect, if any, does the selective protection of a sub-set of article types such as BLP's or disputed pages have on the wider perception of Wikipedia as an information source on all topics?

    What effect, if any, does the presence of Flagged Revisions have on the nature, volume and response time at the help desks and other advice/request forums?

    MickMacNee (talk) 07:47, 3 January 2009 (UTC)

11. Strongly Opppose. Unnecessarily complicated for no real good. 63.3.15.129 (talk) 02:14, 3 January 2009 (UTC)
12. Oppose Pace Black Kite, there is a good bit to lose—I don't imagine that I need set out that argument once more here—and very little to gain; I am utterly unpersuaded that the net effect on the project of the implementation of flagged revisions should be positive, and I cannot imagine that any trial experience should lead me to think otherwise, my opposition's resting on my firm rejection of flagged revisions as inconsistent with my understanding of how our enterprise (at least as regards the formulation of online content) ought to work. Joe 04:45, 3 January 2009 (UTC)

    If you are so confident that a trial would not provide any evidence in favour of implementing FlaggedRevisions more widely, shouldn't you be supporting it? If all it does is show that FlaggedRevs is a Bad Idea^TM, it would strengthen your position, not weaken it. Happy‑melon 11:07, 3 January 2009 (UTC)

    What is there to lose in a trial of the system? Black Kite 14:25, 3 January 2009 (UTC)

    If the trials are not framed and measured objectively, quite a lot. MickMacNee (talk) 15:42, 3 January 2009 (UTC)

    I found it amusing to read "objectively" and then merely "quite a lot" in the same sentence. --Waldir ^talk 19:43, 3 January 2009 (UTC)

    It won't be so amusing if bad data leads us to a bad decision. Ozob (talk) 20:46, 3 January 2009 (UTC)

13. Oppose per WP:NOT#BUREAUCRACY. This may appear to be worth a try, but it increases the "hierarchy of participation" to WP and decreases its ease of universal use at the same time as increasing Admin workload. Furthermore, I do not agree with that this will be the by any means the most effective way of protecting our BLPs, most of which are see no more than a couple of 'tweak edits' a year and many of which remain unsourced for long periods and are so either a high-risk category or no risk at all, depending how you look at it. Tagging doesn't deal with that problem. Having said that, I'm tempted to go tactical with NuclearWarfare, though. Ohconfucius (talk) 06:31, 3 January 2009 (UTC)

    I would definitely encourage you to do so. I'm not yet convinced that this is "the solution" for BLPs myself. However, I want to see for myself rather than make blind guesses based on vague extracts from a foreign language wiki with a radically different culture. I really hope that this will actually decrease the strength of the apparent hierarchy, not increase it. WP:DEAL to the contrary, there are as you say significant jumps in perceived 'status', particularly between admins and non-admins. By creating an intermediate level, I think we can smooth out some of those gaps. There's nothing wrong with there being a hierarchy of respect and trust, as long as the hierarchy of technical tools is the same shape and size. Currently it's not, I agree that that is a problem; I think that this may be one step on the road to correcting that. Happy‑melon 11:15, 3 January 2009 (UTC)

14. Exceptionally Strong Oppose - We launched this on Wikinews, and it nearly lead to all out bloodshed, mutiny and resignations. I personally have been editing here for over 4 years, and quite frankly, I don't need someone else reviewing my damn work to make sure its correct before other people see it. If this gets implemented here, I WILL RESIGN. I've been doing this long enough to do the work without having a bloody overseer! Thor Malmjursson (talk) 07:44, 3 January 2009 (UTC)

    May I ask you to provide evidence of bloodshed on Wikinews? In addition, you are a rollbacker now, and therefore you will automatically become a reviewer if FR are enabled. Then you will be able to sight others edits yourself, and moreover all your edits to sighted revisions will be sighted automatically. So I do not see any problem here. Ruslik (talk) 09:03, 3 January 2009 (UTC)

    I didn't say it CAUSED bloodshed, I said it NEARLY caused bloodshed. And since I am not allowed by the rules of IRC to publish any logs from discussion on there, I cannot provide evidence of this situation. Rest assured however, that the discussion on WN's IRC channel almost lead to 3 of us, 2 who are accredited reporters (myself and one other) walking out on the project. The main reason was that initially, not everyone was going to be given editor status (reviewer). I only relented when this was reversed. I am however, still completely and fundamentally opposed to FR being implemented in ANY form, trial or otherwise. Since with Flagged Revs, you are not allowed to sight your own work, this potentially means everything I create as a new article having to be sighted by someone else. I am not accepting that in any way. I don't care if I get God Mode from this. If it happens, I'll shut the door on my way out :) Thor Malmjursson (talk) 09:14, 3 January 2009 (UTC)

    The reason why edits of a reviewer to an article (whose last revision is not sighted) are not automatically sighted is that the unsighted revision may contain vandalism. In my opinion, the best solution is: if you are going to edit an article whose last revision is not sighted, you should simply check and sight this article yourself before making your edits! Then you can edit it, and all your edits will be sighted automatically. Again I do not see any problem. Ruslik (talk) 09:32, 3 January 2009 (UTC)

    And again, you miss the point. My biggest beef is simple. If I create any New article, I cannot, by the terms of FR, sight it myself. It HAS to be done by someone else. I have been here long enough to know how to create an article and what kind of content to put in it without having to have someone else check up to make sure I did it right before it gets published. Now do you understand why I am pissed with this idea? Thor Malmjursson (talk) 09:40, 3 January 2009 (UTC)

    That s the problem this is being done because an edit may contain vandalism, what percentage of all mainspace edits are actually vandalism? Gnangarra 09:36, 3 January 2009 (UTC)

    Ok, I understand you now. However currently there is no rules about the use of sight function on Wikipedia. They will be created in the future (if FR are enabled). So I am not against allowing creators of the articles (if they reviewers) to sight their own articles just after creation. The risk is low, because reviewers are trusted members of the community. Ruslik (talk) 09:48, 3 January 2009 (UTC)

    In addition the proposed setup does not mean that the flagged revisions will be enabled over all articles including new ones. FR will be enabled just over a subset of highly visible articles. New articles will not need to be sighted unless FR are enabled over them manually. Ruslik (talk) 09:58, 3 January 2009 (UTC)

    Withdrawn from conversation - Please see my talk and user pages. They both say the same thing. I've quit WP. :) Thor Malmjursson (talk) 21:39, 3 January 2009 (UTC)

    No, the proposal says nothing about which pages will be flagged and which pages won't be. Some of the proposed trials are specifically intended to catch some non-highly visible articles. Ozob (talk) 20:59, 3 January 2009 (UTC)

    In fact the "rules of FR" don't require anything like this. There is nothing to technically prevent reviewers sighting their own work, be it new pages or edits to existing articles. On en.wiki I suspect that would be encouraged. The "rules" you rail against are the policies set up by en.wikinews, policies that I very much doubt will ever be enacted here. If such policies are ever enacted here, you'd be quite within your rights to walk out (I would probably join you). But don't assume that all FlaggedRevs implementations are equal; that's one thing we've learnt the hard way. Happy‑melon 11:03, 3 January 2009 (UTC)

    English Wikinews or another one? I don't remember any near-bloodshed. --Steven Fruitsmaak (Reply) 13:15, 3 January 2009 (UTC)

    Indeed, if this user is talking about English Wikinews, they are out of their tree. The implementation of Flagged Revisions led to nothing more than a short lived heated discussion (as per normal, with any new policy). In addition, Flagged Revisions has lead to a significant increase in the quality of Wikinews articles, even though we have a very small group of dedicated editors (between 10 and 15 at any given time). So if you're going to use Wikinews as an example, at least go through the trouble to get it right:P. That said, there are valid reasons to oppose Flagged Revisions; Wikinews is a special case because of 1)Our small userbase, and 2)Our very very short article turnover time (news cannot be old, so complete articles that might take months on Wikipedia have to be put out in mere hours on Wikinews.) In my opinion these conditions do not exist on Wikipedia, rendering Flagged Revisions of limited value here. Gopher65_talk 17:02, 5 January 2009 (UTC)

15. Oppose Needlessly complex and a deterrent to new editor contributions that should not be accepted, especially given the preexisting tools available. That said, I think it somewhat inappropriate that this was even opened up for discussion prior to closure of the widely publicized strawpoll, and that notice of this discussion was so deeply buried in that conversation. Limiting visibility in this manner undoubtedly skews the results of this straw-poll in favor of the editors who were initially promoting the concept. MrZaius^talk 13:14, 3 January 2009 (UTC)
16. Oppose Completely unnecessary and needlessly complex. It makes a farce of "Anybody can edit" by creating groups of editors who by definition are the only ones who can edit freely without restrictions. We can just abolish WP:AGF for anon editors completely then, seeing that this proposal will assume they are making bad edits that need to be reviewed. So this creates much more work, new structures and more drama...and for what? I saw it on de-wiki, where I got that "sighter"-status - anyone can get it with a few edits and a bit of history, so we are just inviting vandals to become "reviewers" and then they can wreak havoc, seeing that most people will think reviewed versions are without problems. We got options to protect the content already which are not having such problems. Regards SoWhy 13:37, 3 January 2009 (UTC)

    So you are proposing instead of making farce of "Anybody can edit" simply to abolish "Anybody can edit" principle and protect all sensitive articles? Ruslik (talk) 13:45, 3 January 2009 (UTC)

    I think what he was getting at was that the current and usually temporary protections with clearly established editing procedures are already well understood and functional and don't require the creation of a new user class, needlessly complicating the already complex guidelines and editor-hierarchy of the wiki. That said, the automatic status mentioned in the parent post doesn't seem like a valid point to complain about, as it sounds an awful lot like the status required to edit a semiprotected article. MrZaius^talk 15:47, 3 January 2009 (UTC)

    That is a simplistic comparison to say the least. By definition, SP'd articles are being watched by many people, more than enough to see and respond to {edit requests}. Blanket sighting of all articles, including the back-waters and niche topics which nobody is frequently watching, is a totally different prospect. MickMacNee (talk) 16:02, 3 January 2009 (UTC)

    Also, I am German, so I know the German implementation and it's problems. De-wiki has a backlog of 11,000 articles and they are using bots to do the job and anyone with 300 edits, 60 days and no blocks gets the flag automatically there. A trial might work for a few selected articles but once this were to be implemented for all articles, I dread to think how long the backlog will be. New-page patrolling has a huge backlog, as many already pointed out, but that backlog does not prevent huge groups of editors from making changes to live articles. Once all the impression of "shiny new feature" is gone, people will not do the massive work this proposal will undoubtedly create. SoWhy 20:07, 3 January 2009 (UTC)

    So it might work for smaller sets of articles, and might not work for larger sets? That's definitely something I want hard data on. And if that is the case, then what's stopping us from only using FlaggedRevs on such smaller sets. Nowhere is it written in stone that FlaggedRevs has to be enabled over all articles or not at all; this trial configuration is proof of that. Happy‑melon 21:06, 3 January 2009 (UTC)

    No, the point is that it creates a huge workload that will not be cared for. It might work for a week, a month, but someday people will be bored by their shiny new toy and then even limited sets will not be cared for. We got dozens of areas with huge backlogs already - no need to create another system that will create backlogs. And the lesson from the example I cited is that when such backlogs occur on a wiki where practically most regular accounts are allowed to flag and there are bots to flag as well, we can guarantee that this will happen here as well - on a much larger scale. SoWhy 23:59, 3 January 2009 (UTC)

    Your comparison to the German Wiki makes No Effort to assess what they are doing wrong. Articles such as Evolution have very fast turn around, and the current protections saves them time (and stress) as less vandalism goes live. However, the current situation does allow easy circumnavigation of Protections. Furthermore, I feel Wiki-veterans basically forget that any Protection of an article is far more disruptive to a Wiki than a flagged version system used in its place. Again, for a small set of articles, that are heavily trafficked, vandalized and consequently watched by active patrollers & admins. A backlog simply will not form given those realities. When a backlog does occur on articles that have become under supervised over time, then a bot automatically nominates it to be unflagged. - RoyBoy 05:40, 8 January 2009 (UTC)

    Protection works fine as is: in moderation. While it's as unwiki as we get and FlaggedRevs would be preferable to protection, the argument was made on the a different basis—a counter-argument based on use of FlaggedRevs to replace protection is fallacious. {{Nihiltres|talk|log}} 07:29, 8 January 2009 (UTC)

    Protection cannot be replaced by flaggedrevs, to think so is a logical fallacy. Protection is (or should be) used seldom just because it is anti-wiki. As one of the admins handling RFPP I deal with protection requests all the time and I know how people think otherwise, but that does not make it any more correct. But protection does not single out a certain group of editors as "better" - it is plain simple "Sorry, we cannot handle the vandalism at the moment but usually you should be able to edit this article without anyone judging your edits for worthyness". FlaggedRevs are "Sorry, we assume your edits are vandalism, so our we-don't-want-to-call-them-elite-editors™ will check if your contributions are okay - come back in 2-3 weeks to see if they were accepted". If one compares those two concepts, I think the latter is much more anti-wiki as it effectively does not get rid of editing rights but of WP:AGF. Also, RoyBoy's argument is incorrect - if we need bots to flag such articles, then we have a backlog and we have more work (more serverload by multiple bots, some people have to write and maintain them etc.) And if those articles are watched by active patrollers and admins, they can revert those vandalism edits anyway. So there is no reason for flaggedrevs in these cases and in no others. Regards SoWhy 17:36, 8 January 2009 (UTC)

    While you are citing valid concerns, the 2-3 week turnaround guesstimate completely ignores what I said about implementing FlaggedRevs on heavily edited articles. Turnaround would be closer to 2-3 hours, not weeks. If it were weeks, then indeed I would be opposed to the idea as well. Also you fail to carry forward your point, logically speaking, we use Protection on articles where WP:AGF for new editors has proven ill-advised. Hence, the drastic measure in the first place. - RoyBoy 06:10, 10 January 2009 (UTC)

    Additionally, if FlaggedRevs was indeed used only in specific cases of heavy vandalism (which are currently protected), the number of articles involved would be laughably small. I repeat, the en.wiki has more regular editors than any other; watching plenty of articles, making backlogs a minority issue. Bot overhead is simply not a valid objection. - RoyBoy 06:17, 10 January 2009 (UTC)

17. Oppose I just don't like it. The result of a trial is very likely get misrepresented or taken to show something it doesn't. Maybe if we had a specific trial proposal to consider I would change my mind. --Apoc2400 (talk) 13:47, 3 January 2009 (UTC)
18. Oppose "Anyone can edit" ? Anyone can, as long as your edit gets subsequent approval. This will double the workload of editors. GreyWyvern (talk) 14:49, 3 January 2009 (UTC)

    Why are you so sure? Currently all new changes and newly created articles are patrolled. Patrollers mark edits as patrolled or revert them. Flagged revisions will simply replace patrolling. You can think about FR as patrolling "on steroids". This analogy can help you to understand what FR really mean. Ruslik (talk) 15:29, 3 January 2009 (UTC)

    The advantage of replacing patrolling with sighting is a philosopical issue, as well as a technical issue. If nobody patrols a good contribution, then no harm is done by default. If nobody sights a good contribution, harm is done by default. If nobody patrols a bad edit, harm could be done, if nobody sights a bad edit, no harm is done by default. It is very much AGF vs. ABF. MickMacNee (talk) 15:39, 3 January 2009 (UTC)

    Insightful comment :) however, I'd say that in the case of a good contribution not being sighted, "harm is done by default" should perhaps be replaced by "no good is done by default", which is different. --Waldir ^talk 19:55, 3 January 2009 (UTC)

    I tried to represent this visually. Check out File:Patrolling vs sighting.png --Waldir ^talk 20:39, 3 January 2009 (UTC)

19. Oppose: We won't even require people to register an account (which still makes it the encyclopedia anyone can edit), no reason to do this, which actually restricts things much more than requiring account registration, which takes all of 8 seconds.--IvoShandor (talk) 15:09, 3 January 2009 (UTC)
20. Oppose: There are some articles I've worked on that haven't had another editor - muchless an administrator - pass by them in three or four years -- I can't imagine the frustration of someone trying to update information in them and having to wait indefinitely to see if their changes are even accepted, before being bold and adding further changes. I also see a "refusal to flag" becoming a new form of edit war between our less-than-noble administrators - all in all, it's a poorly-conceived plan. Sherurcij ^{(speaker for the dead)} 15:39, 3 January 2009 (UTC)

    How about our rollbackers and the 5,000 or so editors who will ask for and receive the 'reviewer' flag? If you can't find anyone in 10,000 sighters who is willing to flag a revision, it must be very controversial indeed. I jest, but the point is that the designers of this extension have given a lot of thought to problems exactly like the ones you mention: there are several new special pages to collect articles such as you describe so that new edits are sighted in a reasonable time. Happy‑melon 21:14, 3 January 2009 (UTC)

    Having seen FR implemented at en.WN where I'm an accredited reporter/reviewer/etc - no, "new edits" are not "sighted in a reasonable time" -- and there's a much higher admin/text ratio on WN...exponentially so. We have approximately 300 texts editable at any given time...and nearly as many reviewers...and it can still take six hours to remove incorrect information from a front-page "news" story. Flagged revisions simply don't work, German Wikipedia seems to suggest the same. Sherurcij ^{(speaker for the dead)} 07:22, 6 January 2009 (UTC)

21. VERY Strongly oppose I agree with SoWhy and GreyWyvern above - This would make a complete farce of the "Anyone can edit" principle which is at the core of Wikipedia, and introduce the possibility that completely valid and accurate edits may be blocked simply because the person responsible for approving the edit is unaware of the information (for example, the information is in a printed publication or TV broadcast only available in one country, and the person responsible for reviewing the edit is in a different country and has no access to this source), or because it differs from their own personal opinion. The only way this could be avoided is if all edits are reviewed by multiple persons located in different parts of the world, and passed if they receive a majority vote from the reviewers - and we know that will never happen. And who is going to appoint the reviewers? What will the criteria for becoming a reviewer be? How can we be sure they are truly impartial and have sufficient knowledge of the subject to be able to accurately assess the validity of each edit? Wikipedia already has far too many self-appointed "experts" who delete any edits they feel do not match their own personal views - Can you imagine the chaos this could bring if they had the validity of being one of the official subject reviewers??? For this reason, I believe this is a VERY bad idea, which will drive away a significant number of existing editors, and also scare away potential new ones. I myself would have to think long and hard about my continued participation here if such a scheme was introduced, and would very probably leave for pastures new. Emma white20 (talk) 15:41, 3 January 2009 (UTC)

    You seem to misunderstand the proposal. Reviewers are not supposed to check the validity of edits. They are only supposed to look for obvious vandalism, libel and copyright violations. Therefore any revision that does not contain the above mentioned statements must be sighted. Ruslik (talk) 16:47, 3 January 2009 (UTC)

    Not "must" but "should". There is no obligation on any reviewer to sight anything. Nobody can be punished for not sighting a page, whatever its contents. MickMacNee (talk) 17:00, 3 January 2009 (UTC)

    And I thank you. This has persuaded me; the only constraint on the obvious possibility of abuse here is that reviewers should not do it. So they should not; as editors should not revert war, and admins should not employ their tools in content disputes. Has that stopped them? No. So here. Flagged revisions should never be tolerated; it should be stopped now and here. Septentrionalis PMAnderson 22:43, 4 January 2009 (UTC)

22. Oppose: This is a really bad idea. It will deter new editors, since the intial appeal of contributing to the encyclopedia "anyone can edit" is being able to see your changes online immediately. Would anyone bother if their edit amounted to no more than a saved preview? I doubt it. Richard75 (talk) 15:42, 3 January 2009 (UTC)
23. Strongest possible oppose although I'm in the minority here. As Richard above, this will deter people from the idea this is an encyclopaedia which anyone can edit. Not only that, but it's one we should be able to edit when we want and without having every edit checked by 'higher-up' users. This idea promotes the idea that we value our members over IPs, which I don't believe in at all. IPs contribute highly to this encyclopaedia despite others vandalising it. Therefore, I cannot support a trial of this system. —Cyclonenim (talk · contribs · email) 15:52, 3 January 2009 (UTC)
24. Oppose for pretty much all the reasons above. We don't need this kind of German bureaucracy.The Magnificent Clean-keeper (talk) 15:57, 3 January 2009 (UTC)
25. Absolutely, positively, hell no. Flagged revisions are a bad idea on so many levels, and against the open wiki spirit. So oppose. SchuminWeb (Talk) 15:58, 3 January 2009 (UTC)

    Comment. Wikipedia is part of the larger free culture landscape, akin to GNU/Linux in promoting open standards, free knowledge, and widespread participation in our cultural future. Now let me ask you this. In Linux kernel development, does every contribution of code automatically upload and install to every Linux user's computer? Because that's how I see Wikipedia in its current state.

    Revision control and versioning are not limiters of freedom or creativity. They merely seperate workshop from distribution center, providing the end-user with a polished product while leaving the workshop -- saw-dust filled and chaotic -- in another room. In the workshop, the "wiki spirit" can pulse stronger than ever, because contributors need not feel afraid when "being bold" and making ambitious changes to an article. The implementation of versioning with "stable" and "unstable" branches does not undermine openness or the wiki spirit. It just moves the inevitable mistakes and mishaps in the development process out of the realm where they can do real damage. Estemi (talk) 16:48, 3 January 2009 (UTC)

    A good analogy. But we have to be clear about what we are defining as "damage". Linux certainly takes no responsibility for defective code if they release it, but they did not decide to have a QA system instead of automatic uploading. The perception of damage can take many forms on Wikipedia, where the automatic availability of open content is a prime mission. Is a sighted article free of obvious vandalism but still unreferenced or subtlely POV any more damaging? Is a libelous statement about a BLP any more damaging than straight lies and misinformation about, say, a product? Wikipedia is now seen as a timely source of unfolding information (whether we want it to be or not), is the discouraging of that type of contribution more or less damaging? I can't count the number of times I have ended up expanding articles based on a single unreferenced but timely line added by an IP. Will that source of inspiration to the "workshop" from unregistered users dry up with the up front comlexity or time delayed updating of Flagged Revisions? And I am not entirely sure even that restricting the viewing of libelous content to registered users only makes any difference from a legal damage point of view (I have requested information at the main page here). I am all for a trial of Flagged Revisions if it is to try and measure it merits against these basic issues, I am not for it if it is merely here to make the lives of the "workers" easier. MickMacNee (talk) 17:27, 3 January 2009 (UTC)

    I disagree that the analogy is a good one. Computer software is very fragile. Changing a single line of code in a tiny way can turn a working program into a pile of scrap. (What happens if you change an increment to a decrement, or start searching an array from the first element instead of the zeroth?) An encyclopedia is not so fragile. We humans are used to dealing with incomplete or sketchy information. We do it all the time when we communicate: All the words that everyone's ever written are an attempt to communicate our thoughts and feelings, but you can see misunderstandings and clarifications everywhere. A tiny mistake in an encyclopedia makes it less useful, but it does not make it useless.

    So it becomes a matter of balancing: We need to determine what level of error we're willing to tolerate as a price for the content our editors contribute. We could take the Citizendium or Veropedia routes, which are both much more extreme than FRs; we could return to the old days when IPs were allowed to create new pages; or we can try to balance them. I feel like FRs will discourage good editing by IPs. Consequently they may never get accounts and may never become regular editors. I edited as an IP for a long time before getting an account. I'd never have an account here otherwise.

    However, none of that is relevant to my own objections to the current proposal. The only way to get good data is to do a well-planned, carefully considered test. Happy-melon called his own proposal "deliberately vague", and I find that intolerable. Ozob (talk) 21:18, 3 January 2009 (UTC)

    Please don't call it "my" proposal just because I happen to be the most active on this thread, although I can see how such a misunderstanding would arise. This is the combined work of half a dozen editors, with contributions from a dozen more. That said, I agree that proceeding from here to think "ok now we have everything we need to do a trial" would be a farcical disaster. It's probably best to consider this proposal "part 1 of 3". Happy‑melon 10:34, 4 January 2009 (UTC)

    I also like your analogy Estemi. The wiki spirit will remain and we will spend less time cleaning up vandalism. -- Alan Liefting (talk) - 04:45, 4 January 2009 (UTC)

26. Strong Oppose: I really don't see the advantage to the idea of flagged revisions. I agree with the above commenters; this will make a farce of the slogan "the encyclopedia that anyone can edit." By restricting free editing to only an elite group it is unfairly subjugating everyone else, creating more work for that elite group and reducing the ease with which all other editors can edit the encyclopedia. Why should rollbackers, administrators, and bots get to say that they don't trust editors who are established users and not vandals, or IP users who are making good edits? It doesn't make sense to me, and as far as I can tell protecting pages and undoing vandalism seems to be working well enough without most edits being reviewed by this elite group in the manner enumerated in this proposal. I don't like it, because it's a terrible idea that will discourage new editors from contributing to Wikipedia and furthermore the whole concept goes against Wikipedia's principles. A Stop at Willoughby (talk) 16:19, 3 January 2009 (UTC)
27. Strong Oppose per those above me. Is this the end of wikipedia? Wizardman 16:26, 3 January 2009 (UTC)
28. Oppose. Timeline: Proposal to implement Flagged Revisions. Two weeks later: Proposal to rename project to "Citizendium". Bleeech. --Cryptic C62 · Talk 16:46, 3 January 2009 (UTC)
29. Oppose - Wikipedia should be all-live, all the time. Flagged revisions are against the main point here. —La Pianista ^(T•C) 16:56, 3 January 2009 (UTC)
30. Oppose - against the wiki spirit of "anyone can edit" and will eventually create a massive backlog, like NPP has already. Sceptre ^(talk) 16:59, 3 January 2009 (UTC)

    Why are you so sure that this quite a limited proposal will create (or worsen) backlogs? Ruslik (talk) 17:35, 3 January 2009 (UTC)

    The backlog on the German Wikipedia is three weeks. Ozob (talk) 21:23, 3 January 2009 (UTC)

31. Oppose, strongly. Come on, we're the encyclopedia that anyone can edit. –Juliancolton ^{Tropical Cyclone} 17:27, 3 January 2009 (UTC)
32. Oppose. FlaggedRevs undermine the most basic principle of Wikipedia's success, which is that random people decide to click "edit" for the first time & get the instant satisfaction of seeing their contribution to knowledge displayed and disseminated to the entire world. Wareh (talk) 17:43, 3 January 2009 (UTC)
33. Oppose While I truly appreciate and respect the work that has gone into this proposal and the technology underlying it, particularly the patience shown in continually explaining things and answering questions and concerns, I believe this idea is fundamentally at odds with one of our core principles that allows anyone to edit articles. I am not in principle opposed to experimentation of this technology but I see no possible outcome that would convince me to support a full implementation and thus a trial would be largely a waste of valuable time and energy. --ElKevbo (talk) 17:50, 3 January 2009 (UTC)
34. Oppose Too antiwiki, it goes against our slogan: "The free encyclopedia that everyone can edit". If we use this system, I'm sure that the work made on anti-vandalism tools will be in vain. —_macy^{es: bot} 18:12, 3 January 2009 (UTC)
35. Oppose We already have backlogs with a similar feature for new pages this will just make these much much worse Alexfusco⁵ 18:16, 3 January 2009 (UTC)
36. Absolutely, positively NO. Since this feature is not compatible with any of the stated goals or purposes of wikipedia, and would create yet another way for a select group of people to force themselves on other editors and viewers, anything that works towards any possible implementation of this is unacceptable. Bushytails (talk) 18:34, 3 January 2009 (UTC)
37. Oppose but without prejudice. In previous discussion, someone from German Wikipedia had come here and told us how this feature leads to ownership-like attitudes. They just trash the revision if they don't like it. OhanaUnited^{Talk page} 18:43, 3 January 2009 (UTC)
38. Strong oppose. for the reasons I have repeated several times (see Wikipedia talk:Flagged revisions). Admiral Norton ^(talk) 18:58, 3 January 2009 (UTC)
39. Oppose. I'd rather not become anti-Wiki. DiverseMentality 19:31, 3 January 2009 (UTC)
40. Oppose - I don't see how there's going to be enough people running around flagging revisions to keep all of the hundreds of thousands of less popular pages from going stale. For those pages, this is the same effect as banning ip editing, as no flagged user will ever come by and permit their changes. --PresN 20:05, 3 January 2009 (UTC)
41. Strong oppose. WP:NOTBUREAUCRACY, Semi-protecting certain (groups of) articles would be a lot better. —Preceding unsigned comment added by Alexanderpas (talk • contribs) 20:20, 3 January 2009 (UTC)
42. oppose As with all flagging proposals to much risk of articles getting locked as flaggers forget about them or lack the rescources to keep up.Geni 20:38, 3 January 2009 (UTC)
43. Strong Oppose - Once I thought about it, I almost vomited. This has got to be... .the most... useless, horrible idea we've come up with yet. I think this is a bad idea. Having the concept of review an article just to get the changes visible... just horrible. Imagine waiting weeks just for a typo change to be visible. This would cause backlog explosion, as well. We have over 2,000,000 articles, think of the backlog explosion. We simply don't have enough manpower and resources to deal with this... and that is why I must oppose this concept, trial, idea, in any shape or form... VX!^~~~ 20:52, 3 January 2009 (UTC)
44. Strong Oppose (i) could discourage editing by the more nervous, (ii) requires a lot of meta-work (ie not actually writing articles) when there is so much of that already and backlogs on many many lists and (iii) Most articles that anyone would be willing to review are already watched by interested editors and many many more are patrolled and thus there is already a perfectly good peer-review process in place. Please let's not make things more complicated. Babakathy (talk) 21:00, 3 January 2009 (UTC)
45. Strong oppose - Imagine the backlogs, at Newpages there is a huge backlog, and that is a heck of a lot smaller size than the whole of the wiki, it'll take about a year to get an edit approved. Plus there will simply never be enough manpower to keep up with it. This will take away the whole point of editing wikipedia, having immediate reliable information. Sunderland06 (talk) 21:03, 3 January 2009 (UTC)
46. Oppose. "You can edit this page right now [and view it published]" should continue to be a basic principle of this encyclopedia, no matter if you are an admin or an IP. --Anna Lincoln (talk) 21:05, 3 January 2009 (UTC)
47. Strong Oppose I think that there are far too many problems with flagged versions. (backlog, having a wikipedia approved version, the version you edit is different to that on the screen etc.) Martin451 (talk) 21:14, 3 January 2009 (UTC)
48. Strong Oppose Welcome to Wikipedia, the free encyclopedia that anyone can edit. Or so they say. BigDunc^Talk 21:28, 3 January 2009 (UTC)
49. Oppose because I don't want Wikipedia to lose its special quality that convinced me to become a member. Welcome to Wikipedia, the free encyclopedia that anyone can edit John Sloan (view / chat) 22:01, 3 January 2009 (UTC)
50. Oh dear god. Very Strong Oppose Oh dear god, think of the MASSIVE backlog that would ensue. The people that review the edits would never get any sleep! It's total blasphemy to think of implementing such a thing. I oppose this move very strongly. Until It Sleeps 22:09, 3 January 2009 (UTC)
51. Strong Oppose I strongly oppose any action which would turn editing Wikipedia in to a system whereby changes must be approved before they appear, rather than reviewed after they are added. The fun and effectiveness of immediate editing is what has made Wikipedia a successful encyclopedia to date. Flagged revisions is a flawed technical addition that fails to retain the appearance and spirit of open editing that Wikipedia relies upon to attract new volunteers. Open editing means "you can edit this page right now", not "you can edit this page and wait for your change to be approved". Jimbo himself once said that "you can edit this page right now must be a guiding check on everything that we do." Semi-protecting a tiny minority of pages, which is an up-front and honest way of saying "we can't handle the vandalism, please be patient", is far more preferable to a system that says "you can edit this page, but it won't really show up until we approve it". Flagged revisions will solve neither vandalism nor the problem of articles being taken seriously as a source (academically speaking). What's more, this adds a huge new workload. The current backlog on the German Wikipedia for sighting revisions is three weeks. That is an intolerable new burden for very little gain. If we are to add a new special userrights group, a new form of bureaucracy, then it must be for an absolutely vital reason. Flagged revisions is not vital. It's a shiny new toy that mucks with the founding pillars of this project. If anyone thinks that this is going to be received like some think (as an opening, rather than a closing, of the wiki) just look at The New York Times coverage of Flagged revisions: "the online encyclopedia anyone can edit would add a layer of hierarchy and eliminate some of the spontaneity." I for one will not stand for added hierarchy and the death of spontaneity. I hope you won't either. Steven Walling (talk) 22:24, 3 January 2009 (UTC)
52. Strong strong strong strong strong oppose Per the above reasons and because I like simplicity. Mww113 (talk) 22:38, 3 January 2009 (UTC)
53. Strong oppose - I have the sinking suspicion this will kill efforts at assuming good faith, and that this is being implemented because we think we've lost the will to assume. Xavexgoem (talk) 22:44, 3 January 2009 (UTC)
54. Extremely Strong Oppose. This would be extremely anti-wiki, and it would be a violation of WP:AGF. Also it would discourage people from editing, and it would ultimately kill the project. Also, what would we do about users who create pages? I might consider leaving if flagged revs are implemented. Jonathan321 (talk) 23:01, 3 January 2009 (UTC)
55. Oppose per MickMacNee, if there are to be any trials. —Mirlen^Talk 23:11, 3 January 2009 (UTC)
56. Oppose - Too many issues I don't like the prospect of at this time. VegaDark (talk) 23:23, 3 January 2009 (UTC)
57. Seems like a lot of extra work and does this not go against the real time nature of the wiki and the slogan that "anyone can edit"? –thedemonhog talk • edits 23:24, 3 January 2009 (UTC)
58. Oppose (strong): It made the German Wikipedia a toy for a minority of users who watch over other people's contributions. No trial needed for this ugly thing. --Cyfal (talk) 23:29, 3 January 2009 (UTC)
59. Oppose: I just can't see it working, and if it did there would be a small numbers of contributors leading to more elitism and bureaucracy. Most likely, it would just make a newpage style backlog. Enough with the user flags... If adminship is no big deal, all these flags need not exist. Ian¹³/t 23:32, 3 January 2009 (UTC)
60. Strongly oppose - if it takes away the ability to immediately implement changes, it destroys the point of Wikipedia. All Hallow's Wraith (talk) 23:55, 3 January 2009 (UTC)
61. Strong oppose - Completely against the ethos, extra workload all over the place when people could be doing more valuable things, largely a net negative. — neuro^(talk) 00:11, 4 January 2009 (UTC)
62. No thanks. PeterSymonds (talk) 01:26, 4 January 2009 (UTC)
63. "If it ain't broke, don't fix it." ✼ American Eagle (talk) 01:42, 4 January 2009 (UTC)
64. STRONG oppose This would go completly against the spirit of Wikipedia. Wikipedia may not be a Democracy but it isn't Communism either. People outside the ruling party should be able to make their edits just as fairly as people from within the system. Themfromspace (talk) 02:24, 4 January 2009 (UTC)
65. Oppose - I only supported the idea before when it was in regards to BLP. However, there is no limiting measure to it now. Thus, I feel as if this will be used in areas that will only cause a harm instead of the original benefit that it was originally proposed to bring. Ottava Rima (talk) 02:32, 4 January 2009 (UTC)
66. Oppose - Keeping to the Unix philosophy, simplicity is best. We have articles, we lock them (to various degrees) if they're prone to vandalism. It shouldn't get much deeper than that. --♥pashtun ismailiyya 04:08, 4 January 2009 (UTC)
67. Oppose - This adds too much complicated structure to the existing "editing-way-of-life." I have serious doubts that Flagging will accomplish anything except confusion, especially among new users. Acps110 (talk) 05:16, 4 January 2009 (UTC)
68. Weak Oppose- I've played around with the labs implementation. If you're a reviewer (which we'll presumably need A LOT of) this is nearly invisible, your changes are auto-approved. If you are a new editor, it just adds a new layer of bureaucracy and confusionto an already dizzying array of rules, conventions and ways of doing things. The encyclopedia that anyone can edit (pending review by insiders) doesn't have the same inspirational ring. I feel like I don't even know what problem this is solving anymore. Why are we making it harder for new editors to join the project? Lot 49a^talk 05:38, 4 January 2009 (UTC)

    Also time median 1 week, some as long as 21 days? guys, that's insane! Lot 49a^talk 05:51, 4 January 2009 (UTC)

    This is misunderstanding. From the same German report the median time articles edited by non-sighters wait is unfortunately currently not recorded, but if of course lower - most edits are checked be RC patrol, watchlists or wikiprojects/portals within minutes to hours'. So the majority of edits are sighted within minutes or hours, not days. 1 week and 21 days only refer to the average waiting time of edits that are in the list of unsighted pages (only minority of edits end up in it). Ruslik (talk) 08:49, 4 January 2009 (UTC)

    OK now I'm totally confused. What causes an article to end up on this list with a median wait time of 1 week / as long as 21 days? They say the backlog is 12,000 articles. That seems like a substantial backlog. You are suggesting that most articles are approved quickly but then for those that aren't the median wait time is 1 week? Lot 49a^talk 20:35, 6 January 2009 (UTC)

69. Oppose- let's not make Wikipedia even more bureauocratic, unfriendly and bewildering. Reyk _YO! 05:48, 4 January 2009 (UTC)
70. Oppose per my discussion on one of the archives -- penubag  (talk) 07:44, 4 January 2009 (UTC)
71. Oppose Questions about the delays and workload in the approval process would not be answered by a small scale test. Would signicantly impact the type of collaborative editing that went into articles such as 2008 Mumbai attacks. Edgepedia (talk) 08:04, 4 January 2009 (UTC)

    Further thought - today, if I type "XYZ is a thief" into a BLP it is likely to be reverted and I'll get a warning. However, if I type "When 19, XYZ stole a wallet from a friend and then spent three months in prison".<ref> XYZ Autobiography, published last year</ref> it is likely to be left. If we have sighting over a large number of articles, the first (if obvious vandlism) will not be accepted, but the second (probably) will. I don't think this gains us anything, apart from a false sense of security. Edgepedia (talk) 11:05, 6 January 2009 (UTC)

72. Oppose as violating the fundamental spirit of Wikipedia. --Cybercobra (talk) 09:24, 4 January 2009 (UTC)
73. Oppose as complicated, confusing, and frustrating. Far easier to ask IPs to register. -- Evertype·✆ 10:20, 4 January 2009 (UTC)
74. Oppose as it will break the wiki model by creating hierarchy among users. I would much rather see a system that allows "Veracity" scores to be assigned to each statement within an article. The user would then have the option of turning on a mode, which allows the veracity of each word/sentence/section/whatever within an article to be visualised. Perhaps colour or shade each word (or whatever) to indicate its veracity? In this way the reader can be continually informed of the veracity of what they read and judge whether to trust it. Some system (eg. mouse hover) needs to be provided whereby a reader can determine how the score for what they are reading has been derived (similar to an expert system traceback) and sources indicated. Veracity scores could be derived automatically, manually or in a hybrid manner. If each statement was linked to a citation a score could be automatically calculated based on a trustworthiness score for the source (based on some sort of "web of trust" type system between journals?). Alternatively editors could manually fact check and sway the veracity. More corroboration from more people increases veracity. Authors should not be able to influence the veracity score of what they have written. Maybe a hybrid whereby auto scoring is also influenced by humans? Whatever scoring system is used it is important that high veracity requires multiple verifications and it would be ideal if some "web of expertise/trust" style system could be used to objectively rate who are the true experts and assign their word a greater weight when calculating veracity within their field of expertise. Being provably a true expert in the field should be the only criteria by which one persons word should be given more weight than another. Even there, the expert should only have an advantage in scoring, not authoring. Being a member of some wikipedia admin class, having lots of edits, having a high profile, or whatever, should not be a criteria. Granted such a scheme is more difficult to implement than simple flagging, but I think it would be doable. No doubt the method used to derive veracity scores needs a lot more thought to be useable and to reflect more closely what most people judge to be the criteria for reliability. John Dalton (talk) 10:44, 4 January 2009 (UTC)
75. Storng Oppose I'm generally against restricting Wikipedia anymore. Guy0307 (talk) 10:59, 4 January 2009 (UTC)

    Strongly Oppose No thanks, I've heard from admins that they'll be retiring if this is implemented, do we really need more admin resignations? The Helpful One 11:18, 4 January 2009 (UTC)

    Comment I agree with you, Thehelpfulone. We definitely do not need anymore admins retiring for sure. I'm serious, that would make the problems associated with this substantially increase in magnitude due to less people here to help out the wiki, possibly causing a snowballing increase in problems. UntilItSleeps PublicPC 20:45, 5 January 2009 (UTC)

    I'm going to go Neutral now because I realise that a) This is just a vote to get the software installed and b) We need it installed to show how horrible it will be! The Helpful One 17:12, 9 January 2009 (UTC)

    Strong Weak oppose- I hate everything about this. More discouragement to new users, more bureucracy, more rules, more technical bullshit I'm not going to understand a word of, and the very thought of getting closer to voting to rate articles (ala YouTube) makes me sick. J Milburn (talk) 11:46, 4 January 2009 (UTC)

76. Oppose - As far as I can see flagged revisions has an awful lot of problems associated with it for very little gain. The obvious vandalism, etc that will be spotted by sighting would be exactly the sort of changes that would be picked up quickly and reverted in the normal sceme of things - and there will be a lot less people to spot and revert the changes - only "trusted" reviewers rather than everybody passing. It will not help to fix anything more subtle or insidious, and by adding long delays, will actually mean that harmful edits are more likely to get through. I also see big problems about edit conflicts with some people working on the live version and others working on the sighted version.Nigel Ish (talk) 11:54, 4 January 2009 (UTC)
77. Strong oppose. Given the small number of editors who will be able to review articles, and the amount of content and volumes on Wikipedia, the implementation of this is unworkable, and can only possibly result in the articles which are displayed to the public becoming seriously out of date due to the backlog of articles to be flagged. All this to eliminate a small amount of obvious vandalism, which would probably be reverted fairly quickly anyway. This system is likely to be far less effective at preventing vandalism than the current system of simply reverting it, as the reviewers will be overstretched, and will not have time to conduct a detailed review of every article. Also, look at the damage that compulsory reviewing, albeit in a more stringent manner, did to Wikinews. --GW… 12:06, 4 January 2009 (UTC)
78. Strong oppose - "the free encyclopedia that anyone can edit", etc. etc. Ferronier (talk) 13:23, 4 January 2009 (UTC)
79. Oppose - the system is already used in the German-language wikipedia, and it just complicates things unnecessarily, is impractical and will keep newcomers from editing, thus limiting the degree by which new good editors emerge.Madcynic (talk) 13:45, 4 January 2009 (UTC)
80. Strong Oppose I understand the way of the world, asking for a trial means that something is given a permanent confirmation once the trial is done (if the trial works right - which it probably will). This is not isolated to Wikipedia but it's human nature. I opposed to the idea because I think it will take too much time away from the people we need to be working on articles, for I think it will scale poorly. I see BLP problems for only 2% of articles - 1% are the most important articles like George W. Bush and 1% are articles where someone has a chip on their shoulder against this person like Wayne Taylor. These articles need to be semi or fully protected. How come we now can't WP:AGF that anons might be doing some good? I hate how it discourages new editors - their edits won't appear online until someone approves them. If this passes, should I as an administrator now have to assess all the editors that I know on here to determine if they should be approved to sight articles? How unfair is that to me to pick some and fail others? If this passes, we need to remove the line "the free encyclopedia that anyone can edit." off the main page because I don't believe that it would be true any more. Royalbroil 14:27, 4 January 2009 (UTC)
81. Will create a massive backlog out of thin air for no good reason -- Gurch (talk) 14:44, 4 January 2009 (UTC)
82. Oppose. The scale of the proposed test is unnecessarily large, and the duration unnecessarily long. A much smaller group of articles could constitute a valid random sample without the risk of adding confusion, complexity, and contention across such a wide swath of article space. I remain skeptical about the idea of flagged revisions in the abstract, but if the proposal were for, say, stubs starting with 'Y', with all flagging turned off in 14 days, I'd support the test. Rivertorch (talk) 15:40, 4 January 2009 (UTC)
83. Very Strongly Oppose. This idea is just added bureaucracy to a process of editing that works well already, and with all the suggestions for how the 'reviewer' permissions would work, along with all of the exceptions and additions, seems overly-complicated for new users, and just a power-trip for those granted additional permissions and responsibilities. The idea goes against the principles of the encyclopedia, and would, even as a trial, be harmful to its progress. - RD ^(Talk) 15:48, 4 January 2009 (UTC)
84. Oppose per many of the reasons given above. The objections expressed by Gnangarra at no.9 reflect mine completely. sassf (talk) 16:39, 4 January 2009 (UTC)
85. Strong oppose – complete bureaucracy that will damage editor's free will to edit. Whilst the sentiment of the support is all well and good, we must accept that this will not be used in the interests of the article, instead creating divides out of thin air. We already have a report in the Signpost about the number of editors shrinking over the past few months, here is a perfect example why. Caulde 16:53, 4 January 2009 (UTC)
86. opppose. It's a Bad Idea. The Germans have tried it, and it's crap. Just more red tape, more self-styled "reviewers", yet another article grading system. Another bureaucracy will grow around it, just like GA, which was a good idea as originally intended, but which is a horrible thing as implemented today. This is just another power trip for our apparatchik population, and will not help improving Wikipedia. Today, you get your semi-trusted but timely and priceless info from 2.6 million untrusted Wikipedia articles, tomorrow you'll get it from 2.6 million untrusted and unreviewed Wikipedia articles? Where's the progress in that. We already have FA, for god's sake, that's the only mark of quality we need. Anything else is offered on a "take it or leave it" basis, with readers expected to use their brains when absorbing information. I encourage my students to use Wikipedia precisely because it is untrusted, and will thus teach them to use your sources responsibly. Another layer of bureaucracy will not help the reader, but it will harm the community and the project. --dab (&#55304;&#56435;) 19:15, 4 January 2009 (UTC)
87. Strong oppose as, whilst this extension may be useful on a heavily-moderated subscription (i.e. paid-for) service, it appears to be contrary to the spirit of wikipedia. --GrahamSmith (TALK) 19:34, 4 January 2009 (UTC)
88. Oppose While the principle is a good idea for BLPs, I'm not sure if this is a good idea Wikipedia-wide. Plus, Dbachmann brings up a good point--the German Wikipedia is only a third the size of this one, and it didn't work there. If this had been proposed solely for BLPs, it would be easier for me to support. Blueboy96 19:56, 4 January 2009 (UTC)
89. Oppose. Anyone can edit is the goose that laid the golden egg that is Wikipedia. I accept this is just about trials, which is more akin to an colonoscopy for the poor goose than just killing it, but why try something that is su utterly a) against the Wikipedia ethos and b) so wretchedly complicated? Sabine's Sunbird talk 22:00, 4 January 2009 (UTC)
90. Oppose - This will just scare away any new editor. It just doesn't fly for me. Ronhjones (talk) 22:16, 4 January 2009 (UTC)
91. Oppose - Goes against the very nature and character of Wikipedia. Trust, trust, trust! And keep it simple. Iterator12n ^Talk 23:00, 4 January 2009 (UTC)
92. Oppose. Keep it free to edit. Malinaccier (talk) 23:15, 4 January 2009 (UTC)
93. Oppose - anyone can edit. keep it simple. And who gets hurt by edits that get reverted (and quite quickly more often than not!)? xschm (talk) 01:41, 5 January 2009 (UTC)

    Who gets hurt? Well, Taner Akçam, for one. -- Frothy Sloth (talk) 03:37, 5 January 2009 (UTC)

    That piece of vandalism was done by a named account, now blocked. Most variants of these proposals would have permitted him to become a reviewer without much trouble; the rest have too few reviewers to be workable. Septentrionalis PMAnderson 17:14, 5 January 2009 (UTC)

    I would change my !vote to support if it was explicitly stated that this proposal would be the one. As it stands it is too vague to support in a general sense. xschm (talk) 23:49, 6 January 2009 (UTC)

94. Oppose - Wikipedia works best when editors work together in a collaborative process to achieve consensus. This proposal does not seem to be imbued with that spirit. Dlabtot (talk) 01:52, 5 January 2009 (UTC)
95. Oppose: Boo, boring, part of the appeal/draw of Wikipedia is seeing your first edit just "pop up"! Enough of us cover the vandalism, and doing this thing wont change wikipedia's "it's full of nonsense" reputation (as obviously those who think that never use it), but it will alienate all the first time editors. Ryan4314 (talk) 02:05, 5 January 2009 (UTC)
96. Oppose. The proposed trial does not appear to address the main problem of flagged revisions, viz the backlogs and delays in edits appearing resulting from implementing it over more than a very limited number of articles. Espresso Addict (talk) 02:26, 5 January 2009 (UTC)
97. Oppose Goes against Wikipedia spirit. Tim Q. Wells (talk) 02:51, 5 January 2009 (UTC)
98. Absolutely not. Anti-Wiki. Ed Wood's Wig (talk) 02:51, 5 January 2009 (UTC)
99. Strongly Oppose The idea of flagged revisions is just... bad, and this really goes against what Wikipedia is. —Preceding unsigned comment added by Rockstone35 (talk • contribs) 02:01, 9 January 2009 (UTC)
100. Oppose Will not do anything useful but make it impossible to have an open Wikipedia. --Patrick (talk) 03:32, 5 January 2009 (UTC)

101 - 200

1. Oppose. Not proven to be effective at increasing the quality of Wikipedia. A trial would undoubtedly lead to a widespread deployment, no matter what the results are. --- RockMFR 04:19, 5 January 2009 (UTC)
2. Oppose It discourages new editors from being bold. --Pgp688 (talk) 04:35, 5 January 2009 (UTC)
3. Oppose per Ozob. I will support this only when there is a specific consensus on the scope of the proposal, and a specific set of outcomes under which the test is judged to have been a success or a failure. Some proper references regarding the relevant experimental methodologies (preferably published in sources that would pass muster for inclusion in a Wikipedia article) should also be given in the proposal. siℓℓy rabbit (talk) 05:33, 5 January 2009 (UTC)
4. Oppose what we have proposed here is far too vague. Given the huge number of applications of flagged revisions which have been suggested, we need a specific proposal detailing exactly what this feature is to be used for and who gets what rights, and I agree that a trial may well lead to an implementation even if it is a complete disaster. Hut 8.5 07:46, 5 January 2009 (UTC)

   I did create an example of a specific type of implementation that could be done with flagged revisions, you might want to take a look at this proposal. Y. Ichiro (talk)

5. Weak Oppose Strong oppose: While I think a quasi-stable version of Wikipedia would be great, this system just sucks (pardon my french). In theory, its a great way to catch hidden vandalism, but in reality, most articles aren't going to get the thorough check they need before being flagged. Too much bureaucracy, more work for a small group of core editors who have better things to do, etc etc, yadda yadda, all been said above. I say we just suck it up and wait out the 500 years until all articles are featured :-D -RunningOnBrains 09:13, 5 January 2009 (UTC)
6. Not for another ten years. Not joking. We're not yet strong enough as a pedia to pull this off (as per everybody else's comments). Maybe in ten years we will be able to ignore anons. Maybe. Matt Yeager ♫ (Talk?) 10:29, 5 January 2009 (UTC)
7. Oppose, if the question is to enable Wikipedia:Flagged revisions/Trial, right now I would have to say no because it appears incomplete, with too many unanswered questions. Better would be a straw poll on the specifics of the proposed configuration (or other proposals), and perhaps a straw poll on the details of a guideline for Flagged Revisions. --Pixelface (talk) 10:59, 5 January 2009 (UTC)
8. Oppose To suggest that people have to have every change validated by someone else smacks of big brother-ism and is very much contrary to the basic concept that anyone can contribute. Perhaps it would be better to say that in order to edit, an account is required. That would tend to stop, or at least slow, many of those who vandalise only to be disruptive, while still allowing those who wish to contribute positively to do so. Edit - whoops, forgot to sign... Andy Johnston (talk) 12:45, 5 January 2009 (UTC)—Preceding unsigned comment added by Andy Johnston (talk • contribs) 12:41, 5 January 2009 (UTC)
9. Oppose - utterly incompatible with the ideals of Wikipedia. There is already too much fragmentation of the community, and this proposal will only increase that. It will discourage new editors, and dispirit many established ones too. DuncanHill (talk) 13:50, 5 January 2009 (UTC)
10. Oppose (for now) - I've now tried the lab version. I *think* I now understand the usage (though a clear purpose, including an example for instance, would still be welcome as I wrote below)... but the wording and the implementation needs a lot more thought. Firstly, the word "sighted" is horrible (I would suggest "reviewed"). Then I could review pages that had already been reviewed... is that right? Then, I couldn't review intermediate pages (that is, I couldn't mark as "sighted" an older version, which had yet to be "vandalised" by me). Then, I could add a comment while unticking "sighted", but that comment seemed to vanish into the ether. None of this behaviour was in any way intuitive to me. Generally, as someone who sees a lot of IP vandal edits, I would welcome something that stops those edits getting into the article, but I can't quite see how it works in this case - if an IP adds some valid text to a previously vandalised article, that version cannot be marked as "sighted"/"reviewed" because it contains vandalism, and so therefore that text would probably never be seen (how many editors, or "reviewers" would seriously work out which edits to keep before marking the article "sighted". I think this test implementation needs more work and more thinking about use cases before going "live". Stephenb (Talk) 14:13, 5 January 2009 (UTC)

    Although I'm on the other side of the vote, I think you make a very good point with respect to "reviewed" being much better than "sighted". Thank you for that. --Tryptofish (talk) 20:05, 6 January 2009 (UTC)

11. Oppose - Didn't scale on German Wikipedia, still thousands of pages completely unflagged. Didn't prevent vandalism, either. Frustrates junior editors --Pgallert (talk) 15:17, 5 January 2009 (UTC)
12. Oppose, until we have some agreement as to what articles should be flagged. The two proposals I have seen so far are either unwieldy (flag everything), or present a serious issue with responsibility shifting which I detailed here, and mentioned here. The latter problem is one with some potentially serious legal consequences for good-faith volunteer flaggers, and I have not seen any response to that concern from those supporting flagged versions. The issues surrounding that need to be cleared up before we implement a mechanism like this. Sjakkalle (Check!) 15:51, 5 January 2009 (UTC)
13. Oppose Adopting flagged revisions on any scale is a bigger restriction to Wikipedia than requiring all editors to register, which we don't do. The results of any trial will not be representative of the full-scale adoption most of its proponents seem to support. I'm also concerned that this mechanism amounts to an additional claim of reliability, something I would like the project to avoid. Wikipedia aspires to be an encyclopedia, but it must also remain a wiki, and it's potentially dangerous to pretend otherwise. Ntsimp (talk) 16:10, 5 January 2009 (UTC)
14. Oppose per Cybercobra etc –Sarregouset (talk) 16:23, 5 January 2009 (UTC)
15. Oppose - It would be much simpler to ban un-signed-in edits from IP addresses. MRM (talk) 17:39, 5 January 2009 (UTC)
16. Oppose, my experience on German wiki was horrible with this system. JACOPLANE • 2009-01-5 18:00
17. Oppose - The system of everyone-can-edit with all its flaws is still preferable to this. --Saddhiyama (talk) 19:21, 5 January 2009 (UTC)
18. Oppose - As if we didn't have enough classes of users already. Bikasuishin (talk) 19:38, 5 January 2009 (UTC)
19. Oppose I don't trust the promise that a trial brings with it no intertia. Also, I oppose for the various reasons I have stated in the numerous past "polls, straw polls, testing the waters, etc." in which I have participated. Protonk (talk) 19:50, 5 January 2009 (UTC)
20. Oppose - Per User:Pmanderson's rationale in oppose #2 (or #3, I forget). Chrislk02 ^{Chris Kreider} 20:13, 5 January 2009 (UTC)
21. Oppose - Adding flagged revisions would create this unnecessary step of editorial review. It makes Wikipedia far less accessible, not confirming to the "anyone can edit" philosophy, and just plainly assumes bad faith. -- クラウド６６８ 22:13, 5 January 2009 (UTC)
22. For my reasons stated here. Altering the protection policy to allow quicker placement of semi/full-protection on pages, and/or expanding the list of pages that should be permanently protected will be far more easy to implement and to manage than flagged revisions for the English Wikipedia. Acalamari 22:15, 5 January 2009 (UTC)
23. Strong Oppose to this whole concept, it makes a mockery of "anyone can edit." I even notice that editors I've had "skirmishes" with agree here. (If you want a "stable" or "more correct" "Wikipedia," revive the Nupedia idea, or go see Theopedia or Conservapedia.) TuckerResearch (talk) 22:53, 5 January 2009 (UTC)
24. Oppose ^^^ --sss333 (talk) 23:58, 5 January 2009 (UTC)
25. Oppose--Cube lurker (talk) 00:25, 6 January 2009 (UTC)
26. Oppose Also, polls and votes are not debates. I don't understand why this was allowed to become one.Leodmacleod (talk) 0:31, 6 January 2009 (UTC)
    • Because we didn't have the debate before the poll. It's actually a good debate, and the next proposal should be better. Septentrionalis PMAnderson 04:51, 6 January 2009 (UTC)
27. Oppose Stan J. Klimas (talk) 00:43, 6 January 2009 (UTC)
28. Oppose per all the above. Arkon (talk) 01:37, 6 January 2009 (UTC)
29. Oppose Unnecessarily undermines the idea that the encyclopedia is open for anyone to edit. --Philosopher ^{Let us reason together.} 01:57, 6 January 2009 (UTC)
30. Oppose - would make basic Wikipedia improvements, such as trying to get an article up to FA, difficult for all people without the ability to oversight their own contributions. Furthermore, creates a new way to editwar - as if we needed that! Shoemaker's Holiday (talk) 03:48, 6 January 2009 (UTC)
31. Strongly Oppose -- Mdandrea (talk) 06:19, 6 January 2009 (UTC)
32. Oppose - There are better innovations to try to improve WP. Experience on German WP for FLR isn't promising. Rd232 ^talk 07:18, 6 January 2009 (UTC)
33. Oppose. Sorry if this rehashes a discussion that has already occurred, but I abandoned my previous account because I was getting too involved with Wikipedia politics and bureaucracy and I just don't have the patience or inclination to wade through everything that has been discussed on this page. I have, however, reviewed the proposal and oppose it for being an unnecessarily complicated solution to a problem that is already being handled somewhat effectively with existing methods. Recently, en.wikipedia implemented a new process for new page patrollers to flag new pages. Unexamined pages turn up in orange (or was it yellow?) on the new page patrol page, and any autoconfirmed user could click as patrolled and that page would be un-highlighted. Why can't that system be implemented for any changes when looking at the recent changes page? Even extend it to watchlists. That method effectively distributes the volunteer labor pool that is available so you don't have 40 RC patrollers reviewing the same legitimate edit to the penis page by an anonymous user while other vandalism edits slip past unnoticed. Meanwhile, the encyclopedia remains one that anybody can edit. Edit conflicts are frustratig when they happen, but imagine if I'm trying to copyedit a low-traffic article that hasn't been "approved" by the privileged elite and some other editor also tries to do the same? Not only can't I see my own edits, but I can't see the fact that some other editor has already modified the same paragraph to fix the same problem, but only with different wording? One of us just wasted a bunch of time. No thank you. (P.S.; now that I've stated my opinion, I'll also note that I'm not going to follow the result or watchlist this page, so if anybody wants to follow up on this, please drop me a note on my talk page and let me know if further comment is requested). Henry8787 (talk) 09:35, 6 January 2009 (UTC)

    I never knew about the orange thing, and agree it's a great idea, especially to implament onto watchlists (though it could backfire too -- not everyone reverts all obvious vandalism they see̲, even if on their watchlist). But I one thing I think you're missing is that, I believe, anyone logged in will see the most recent (unsighted or sighted) version, weather or not they are a sighter. At least I'm almost positive this is an option that can be turned on at the dev level; but more importantly, when you EDIT you're always shown the most recent version -- you can't have multiple branches of unsighted edits. And befor you say "this may confuse people", it already happens a lot in fast changing articles, after all. So I think your worries here are unfounded. ♫ Melodia Chaconne ♫ (talk) 12:41, 6 January 2009 (UTC)

    This is correct: any logged-in user will always see the most recent version of every page (with a note saying either that "this article is 'up to date'" or that "there are some changes that need review"). Whenver anyone goes to the edit window, they see the most recent version of the wikitext, and if there are changes between that code and the stable version, they are highlighted in a diff above the edit box so they can see exactly what has changed (and revert any vandalism that has crept in). Happy‑melon 15:34, 6 January 2009 (UTC)

    That is something else which should be explained clearly in the next take on this; I had been wondering about that myself. It is a very bad idea: It means that editors (the minority) do not see what most readers see; which means that if a sighted entry contains vandalism or error, and an anon fixes it, editors will not notice that anything needs to be done. See WP:Autoformatting for a similar problem. Septentrionalis PMAnderson 18:54, 6 January 2009 (UTC)

34. Oppose I agree with the above and favor it as the better solution. Wandalstouring (talk) 09:43, 6 January 2009 (UTC)
35. Oppose as generating an additional work overhead. Category:Wikipedia backlog has already got hundreds of thousands of problems. Stifle (talk) 12:53, 6 January 2009 (UTC)
36. Oppose "the free encyclopedia that anyone can edit" is a cornerstone to this project and serves as a hook to attract new users. Don't make this cornerstone a sham. These flags would be an insult to newcomers and create a barrier to entry. Watch the rate of new users drop drastically. Furthermore, these flags would create more hierarchy, more backlogs and more red tape. I hope everyone takes Thor Malmjursson's comments here seriously. Gnangarra also makes a good case against all this. Lastly, I fear if this is granted a trial implementation, there will be no turning back, and it will become fully implemented. Kingturtle (talk) 13:19, 6 January 2009 (UTC)

    With flagged revisions anyone still can edit an article as opposed to semi protection or protection were people cannot. Flagged revisions allows removing protection. Finally, you don't want to have a trial because you're afraid it will work out and be found to be a good thing? I'll never figure out the opposition to the only option we have that can solve the vandalism problem. Unless a workable alternative is proposed, opposing flagged revisions is holding Wikipedia back. - Taxman ^Talk 15:30, 6 January 2009 (UTC)

    It does not solve the problem, it just creates another layer of work. Protection is plain simple "Sorry, a large number of people want to destroy good content, please stand by", it treats everyone the same. Flagged revisions is "Sorry, we assume you are a vandal, so a special user™ (who we do not want to call elite but that is what they are) will check if your contribution is worthy". But the problem is not solved: Apply flagged revisions only to some articles, vandals will vandalize others. Apply it to all and masses of good anon editors are scared away because the thrill of seeing what you added disappears and it will lose us a bunch of users as it did de-wiki. Any way, flagged revisions will actually get vandals what they want - that we lose good content due to their actions. Whether directly by their actions or indirectly, the vandals will reach their goal and hurt us. So forgive those opposing that they don't want to implement something that does not solve the problem but creates more work and sacrifices the ability of everyone to edit freely. SoWhy 16:09, 6 January 2009 (UTC)

    I don't agree that "what vandals want" is that "we lose good content due to their actions". While there are certainly committed vandals who want precisely that, and who have developed very elaborate means of causing as much damage as possible, the vast majority of vandalism comes from people who get a tiny buzz out of seeing the eight-most-popular website in the world calling their classmate a wombat. That is the sort of vandalism that FlaggedRevisions can stop, by breaking the 'itch-scratch' cycle of "break a page"→"see that page broken immediately". Yes, it also breaks the cycle of "fix a page, see that page fixed immediately", which we all agree is not a Good Thing. But unlike the casual vandalism, we continually encourage such positive edits to register accounts and become more involved, if only because it means they're more likely to stay and become active contributors. IPs are most useful not as a source of edits, but as a source of editors. In my opinion, knowing that with the trivial step of creating an account they can see their edits immediately visible, is likely to encourage that process, not discourage it. Of course I have no evidence to support that claim, just as there is no evidence to prove otherwise. We desperately need hard data to justify such assertions. Hence the proposal for a trial period. Happy‑melon 16:21, 6 January 2009 (UTC)

    Actually it perfectly solves the problem. Vandalism is not shown to readers of the encyclopedia if that option is chosen. Protection completely removes the ability of some or most people to edit freely, while again, flagged revisions allows everyone to edit freely. Indeed it does require more work, but no one said you could write an encyclopedia without doing any work. And can you confirm the cause of less users on de-wiki or is that speculation? I'm 100% sure there is no way to know and there are less active users on en.wiki anyway. There is something else going on. Finally, no content is lost with flagged revisions. At most someone has to wait a little while to see it. How long do you have to wait between updated revisions of books and textbooks you read or non wiki websites you want to improve? I find that most opposition to flagged revisions are based on similarly incorrect premises. - Taxman ^Talk 18:24, 6 January 2009 (UTC)

    Pages are not currently only protected due to blatant vandalism. I very much doubt that unless the use of the 'sight' function is absolutely restricted to simply certifying that no obvious vandalism exists, the number of protected pages that can be released won't be many at all. MickMacNee (talk) 22:02, 6 January 2009 (UTC)

    No, it doesn't. Please read the discussion below. The most dismaying part of this poll is the facile optimism that FR will solve BLP's, which they can't, or eliminate vandalism, which they won't. If a reviewer ever slips, FR will tend to preserve whatever vandalism he missed. Septentrionalis PMAnderson 18:54, 6 January 2009 (UTC)

    In the extremely small proportion of cases where that may happen, we're not really much worse off than where we are now. However in the vast majority of cases, where schools for example can't (or shouldn't) in good conscience use Wikipedia content because any page at any time may be vandalized, the users of Wikipedia would be much better off with flagged revisions. And the users of Wikipedia vastly outnumber the editors by orders of magnitude. Users shouldn't have to learn how to go into the edit history and search for and compare versions to find one that is vandalism free. So it all comes down to being careful about not missing vandalism in sighted versions. - Taxman ^Talk 19:04, 6 January 2009 (UTC)

    They don't have to. They have to wait a few minutes, or fix it themselves. This will not (it can't with reasonable effort) remove inobvious vandalism, and RCP does a quite good job at removing obvious vandalism. For every problem, there is a solution which is simple, direct, obvious, and wrong; this is ours. Septentrionalis PMAnderson 19:13, 6 January 2009 (UTC)

    Readers don't and shouldn't have to know about things like that. And waiting for a few minutes often doesn't work since a) it may not have been fixed at all and b) it may be vandalized again. And unfortunately RC patrol doesn't do a good enough job at fixing vandalism since it can't. Vandalism is visible on pages for a substantial proportion of page views. Finally, you're opposed to a trial because you're convinced it won't work. Brilliant. Trouble is there is evidence it is working. - Taxman ^Talk 20:03, 6 January 2009 (UTC)

    No, I am opposed to this because the test protocol was never thought through; my reasons are clearly stated at #3. The airy assumptions that a test of FR cannot do harm, and FR must be able to solve our problems are unfounded, however, and support !votes based on them should be discounted proportionately. Septentrionalis PMAnderson 18:33, 7 January 2009 (UTC)

    Well if one were to start discounting, you'd then have to discount the oppose votes based on horridly flawed rationale such as "FR wouldn't allow anyone to edit", etc of which there are many and several types. - Taxman ^Talk 21:55, 7 January 2009 (UTC)

    "Flagged revisions allows removing protection" is also a flawed rationale. MickMacNee (talk) 01:06, 8 January 2009 (UTC)

37. Oppose This sounds like a pretty big step, and I think it will be an exploit for the vandals... -- ErnestVoice ^{(User) (Talk)} 19:52, 6 January 2009 (UTC)
38. Very Strongly Oppose Firstly, what the proposal amounts to is saying to editors: "Sure, anyone can edit Wikipedia--but only in a sandbox, that no one else will see. Nobody but authorized officials can do real editing." I don't care if the Germans like to be treated in this demeaning way. The day this policy is implemented I will request my editing account closed, and I will never edit again.
    Secondly, what we're proposing to create is a layer of bureaucratic overseers lording it over the editors. Wikipedia is already groaning under the weight of all the self-appointed critics on private ego trips, who restrict their activity to flagging articles and chiding the overworked and patient bona-fide editors. Why should we be providing an official niche for people who view the project as a way of fulfilling their power fantasies? Create a layer of bosses who do nothing but affix--and withhold--rubber stamps of approval, and a lot of actual editors will quit. I certainly will. Freederick (talk) 21:28, 6 January 2009 (UTC)

    Sigh, it's comments like this I can't understand at all. Do you not see how it's very little different from how it is now? Edits can easily be reverted now -- the difference with FR is that a good percentage (I dunno the numbers, but I've seen it very high) of people just don't nessesarily see the most recent edit(s). Yes, this may prevent them from seeing good edits but had they looked a week ago it wouldn't have been there either, right? But it also prevents them from seeing the vandalism, which can be pretty bad. People often complain about the lack of censorship on WP, but at least we try to keep to relevent places -- vandalism takes away from the effort. ♫ Melodia Chaconne ♫ (talk) 22:02, 6 January 2009 (UTC)

39. Oppose Only because this functionality is limited to a specific, new usergroup. We can come up with a better proposal that allows the entire community (or at least, logged-in users) to be involved. -- smurdah^{[citation needed]} 22:04, 6 January 2009 (UTC)
40. Oppose More bureaucracy + more technocracy = disaster. --Folantin (talk) 22:09, 6 January 2009 (UTC)
41. Oppose I want a specified end date of the test before I can support one. Reywas92^Talk 22:22, 6 January 2009 (UTC)
42. Oppose Current protocol sufficiently deals with vandalism. All this does is add significant bureaucracy, yet another level of administration, and does not in practice improve wikipedia at any level. Additionally, it's not a test if there's no end date, it's simply a limited implementation. -Drdisque (talk) 22:39, 6 January 2009 (UTC)
43. Oppose. The idea just doesn't go with the spirit of Wikipedia, and would be too hard to implement. Jagun^Talk_Contribs 01:21, 7 January 2009 (UTC)
44. Oppose. per User:Gnangarra, said it perfectly. OlEnglish (talk) 02:21, 7 January 2009 (UTC)
45. Oppose as currently implemented The implementation from the point of view of the registered user that understands what is going on is fine, and I do support that, but the implentation from the POV of the IP user is terrible and need to be improved greatly before I can support this proposal. see Test page? Dbiel ^(Talk) 04:42, 7 January 2009 (UTC)
46. Opposed. Yaki-gaijin (talk) 08:30, 7 January 2009 (UTC)
47. Oppose. Every time I edit, I see Once you click the Save button, your changes will be visible immediately. Obviously that appeals to vandals. It also appealed greatly to me when I started here, and I've never vandalized. It was/is satisfying to correct typos and other errors and leave a page better than I found it. I gradually "got into it", did research, and improved and wrote articles. I'm sure that a great many others "got into it" in a similar way, and wouldn't have bothered if changes weren't visible immediately. I oppose because I believe recruitment would be harmed. - Hordaland (talk) 14:46, 7 January 2009 (UTC)
48. Oppose per experience at DE-WP. All in all a waste of time, see #Comments from DE-WP for a more detailed statement. --X-Weinzar (talk) 15:20, 7 January 2009 (UTC)
49. Oppose. I think we are approaching a diminishing returns on vandalism prevention. Regardless of intent, this seems to add problems with {reviewer} edit (rev?) wars and possibly others. As a minimalist and general hippy, the additional beaurocracy layer is unattractive—I am reminded of the abstraction and disconnectedness of the micro-management system. While this method may also reduce vandalism, it may turn off more benevolent users as well. I suppose I am not opposed to the trial of the method, however I am opposed to the implementation. —Archon Magnus^{(Talk | Home)} 15:33, 7 January 2009 (UTC)
50. Oppose. This gets in the way of contributions from newcomers and could be discouraging. Also, articles as viewed by registered users should match as closely as possible articles as viewed by unregistered visitors. Cmadler (talk) 18:22, 7 January 2009 (UTC)
51. Oppose No   «l| Ψrometheăn ™|l»  (talk) 18:31, 7 January 2009 (UTC)
52. Oppose I think a wiki should be instant. Computerjoe's talk 18:55, 7 January 2009 (UTC)
53. Oppose as bad idea with no remitting graces that can only damage the project. Thanks, SqueakBox 20:24, 7 January 2009 (UTC)
54. Oppose because this plan is inherently bad by adding another layer of aristocracy, and because there are other viable options for fighting vandalism (e.g. eliminating ip editing of mainspace pages). Alohasoy (talk) 20:59, 7 January 2009 (UTC)
55. Oppose Backlog, backlog, backlog. This will be a huge mistake. Much prefer semi-protection. --Chasingsol^(talk) 23:20, 7 January 2009 (UTC)
56. Strong Oppose I first edited as an IP, and I liked to see that the changes I made were constructive from the get-go, and that's what kept me hooked. Spencer^T♦C 01:38, 8 January 2009 (UTC)
57. Oppose -- too much work & too long backlog for marginal benefit. Renata (talk) 02:19, 8 January 2009 (UTC)
58. Strong oppose. --MZMcBride (talk) 02:45, 8 January 2009 (UTC)
59. Strong oppose It goes against the spirit of wikipedia.--Kiyarrlls-talk 05:14, 8 January 2009 (UTC)
60. Oppose to present version of the trial. We must first decide that a vast majority of users will be automatically enrolled as "reviewers". I would definitely vote "no" unless any registered user would be automatically enrolled as a reviewer, perhaps with a few obvious formal limitations (no blocks during last year; no official editing restrictions; at least 1000 edits and perhaps something else). But this had to be decided prior to this poll. Another legitimate concern is deterring IP users, but that would not prevent the trial in my opinion.Biophys (talk) 05:16, 8 January 2009 (UTC)
61. Weak Oppose Too often I see pages marked protected with only light vandalism in the history. Protected pages place a barrier for anonymous contributors that often discourages them from bothering. A feature that allows them to contribute anyway, instead of blocking them outright, would be a nice addition to this wiki. So if the feature is implemented on a limited scale, say for a specific IP range and/or specific articles where vandalism is a problem I say go for it. As long as it lessens to use of protect.--Anss123 (talk) 07:18, 8 January 2009 (UTC)
62. Oppose. In my early usage of Wikipedia, I, too, enjoyed the feeling that a new contributor was assumed to be trustworthy until proved otherwise. There's also the big backlog issue here.Astral Highway (talk) 10:23, 8 January 2009 (UTC)
63. Strong Oppose I'm astounded at this. Whatever happened to the "free encyclopedia that anyone can edit"? Will new editors be attracted to the project when they see something like this? Sounds to me like a good way to reduce participation even more. Chamal ^talk 13:14, 8 January 2009 (UTC)

    In practice, we are currently "the free encyclopedia that anyone can edit except semi-protected and protected pages" - one of the ideas is that this could in some way override our need to use semi and full protection as often as we currently do, and would allow all editors to contribute to a greater number, if not all, articles. This isn't a poll to turn on flagged revisions for all articles, or indeed any article. It's just the technical means to run any trials, which would require a separate consensus to run - one of the proposed trials is to use FlaggedRevs in the way I've described, but without this poll passing to allow the software to be turned on, there's no point even discussing limited trials Fritzpoll (talk) 13:20, 8 January 2009 (UTC)

    While I see protection as a necessary precaution that is implemented under special circumstances, I'm afraid I can't think the same way about flagged revisions. My concern is that new editors (ones who have just found out that they can edit here) will be intimidated and discouraged from contributing to the project, as I have said above. I'm aware of what this poll is about btw. I don't know if I'm stupid but I'm definitely not that stupid :) Chamal ^talk 13:49, 8 January 2009 (UTC)

64. Opposed First off, a small-scale test wouldn't establish anything. The problem with idea is that when its scaled up, the backlog swells. And that issue is likely to be even more serious here then it is on German Wiki. As others have pointed out, it makes the "Encyclopedia anybody can edit" slogan into a farce. Oh sure, anybody can still edit, but only the editor can see the change until it is approved by some bureaucrat. I can think of lots of other ideas for reducing vandalism: semi-protect the top 1,000 vandalized articles; soft-block any IP associated with vandalism for six months; and make vandals do counter vandalism "community service" to get their rights reinstated. Kauffner (talk) 14:09, 8 January 2009 (UTC)

    My comment was simply that as this won't apply to every single page, and possibly not even beyond those that new editors are unable to edit at present, I didn't understand why you would oppose trialling the FlaggedRevs extension. The reason I explained it in the way I did was because your comment implied that new editors would be put off at finding all pages closed off to them in this way, which is not what is being proposed here or anywhere else afaik Fritzpoll (talk) 14:06, 8 January 2009 (UTC)

    I think this is in reply to my earlier comment above Kauffner's vote? Then first of all, I assure you that I did not take your comment personally or as made in bad faith (or anything like that). As for my oppose, I just don't think it's a very good idea to be implemented. It's true that all pages will not be "closed" to new editors, but even so I think it will be harmful. This is just my personal opinion on this. I daresay the trial will be approved, and if its results are good and disproves my concerns, then of course I will not be aainst its use. Chamal ^talk 15:09, 8 January 2009 (UTC)

65. Oppose per Septentrionalis et al. Personally I think FR may be appropriate for other, smaller projects, but not here. Kwanesum (talk) 15:15, 8 January 2009 (UTC)
66. Oppose Strongly. Drifting away from the free encyclopedia that anyone can edit --catslash (talk) 15:44, 8 January 2009 (UTC)
67. Oppose as unwikipedian - this just isn't where I want to see wikipedia going. Also a small scale test would probably work - a large scale implementation would just turn RC patrol and NP partol into a logistical nightmare. Usrnme h8er (talk) 16:04, 8 January 2009 (UTC)
68. Oppose Per all of the above (esp Pmanderson). It has an anti-"we're all in this together" feel to it. There are very dedicated vandal patrollers here, I just don't see a real need for this. Marcia Wright (talk) 16:57, 8 January 2009 (UTC)
69. Oppose - The fundamental principle of Wikipedia is: "The free encyclopedia that anyone can edit". -MBK₀₀₄ 17:33, 8 January 2009 (UTC)
70. Oppose; flagged revisions are only going to create backlogs and piss off good anon editors, who will notice that their helpful edit doesn't show up (factoring in the cache) and leave or start vandalizing in an attempt to get their edit "noticed". All FlaggedRevs is gonna do is further establish IP editors as second-class citizens. -Jéské Couriano ^{(v^_^v)} 22:39, 8 January 2009 (UTC)
71. Oppose; --Farbotron (talk) 23:04, 8 January 2009 (UTC)
72. Oppose Don't like the idea of so many subsets of Users, and don't like the implications of its implementation: the restricting of the possibility to freely edit on Wikipedia. Debresser (talk) 23:56, 8 January 2009 (UTC)
73. Oppose More fine text under "anyone can edit"? No. Icy // ♫ 01:27, 9 January 2009 (UTC)
74. Strongly Oppose The idea of flagged revisions is just... bad, and this really goes against what Wikipedia is. Rockstone35 (talk) 02:03, 9 January 2009 (UTC)
75. Oppose 1) This is punishing everyone for the crimes of anon IPS and fools, the latter of which I've seen relatively few. Better to just have a combination of limited "free" anonymous edits followed by registration of users and sanctioning of those who misbehave. 2) This will create cliques that go around approving each other's (often crappy) edits while doing what they can to stifle other better material, especially on controversial topics. It already happens to a certain extent with tag teaming, canvassing, secret emails etc. on the Israel-Palestine issue, necessitating a whole Arbitration/Palestine-Israel articles in early 2008. Don't let the apparatchiks totally take over. 3) And then there's the backlog issue. Who are you paying to do all that work?? Look at all the crap that persists for years in current articles!! Better to pay people to help people learn to edit better and sanction those who don't. CarolMooreDC (talk) 02:56, 9 January 2009 (UTC)
76. Strongly Oppose I have been a Wikipedia editor for many years now, championing the idea that this projct is something which encourages participation, and extends its ethos to anyone who wishes to contribute. To introduce this "layer" of checking, however minor, is a building of a wall between the ordinary user and the project's main aims. I respectfully request that this trial is cut to the briefest possible time limit, and for the fight against vandalism (which I support) is carried out another way doktorb _words^deeds 05:09, 9 January 2009 (UTC)
77. Oppose As with the others, I think that this just defeats the purpose of "Anyone can edit". Sure they can edit, but not many people will see their changes (I'm assuming most readers have not registered)! --wj32 ^t/c 09:59, 9 January 2009 (UTC)
78. Oppose - primarily for the reasons as stated by Richard75 above - "This is a really bad idea. It will deter new editors, since the intial appeal of contributing to the encyclopedia "anyone can edit" is being able to see your changes online immediately. Would anyone bother if their edit amounted to no more than a saved preview? I doubt it" - fchd (talk) 10:34, 9 January 2009 (UTC)

    But people will see anyway -- the only difference is that an anon is more likely to have something changed already when they start to edit (which certainly happens as it stands now). If anyone adds an unsighted edit, they will be taken to the draft page after they are done editing, so they WILL see the new changes immediately. Also, anyone can switch between the sighted and the draft -- it's just a matter of what is shown on initial arrival at the page. ♫ Melodia Chaconne ♫ (talk) 12:34, 9 January 2009 (UTC)

    estimated is that 1 in every 100 visitors finds the edit button, so what would be the estimate for people who find the edit button AND figure out that they are looking at the wrong version ? Mion (talk) 13:11, 9 January 2009 (UTC)

    When the 'edit button' actually says "edit draft" and the edit screen has a large notice over the top saying "edits made here will be incorporated into the stable version when an authorised user reviews them" (or something similar, I'm sure we'll customise it)? I give our readers enough credit to assume they're not completely stupid. How many of the other 99 readers are actually looking for the edit button? Happy‑melon 14:19, 9 January 2009 (UTC)

    We dont know how many were looking for the edit button but could not find it, so the number of people who could find it is the thing to work with, now this clear sign (large notice at the top), has shown on the German wikipedia that two of every three anonymous editors will leave the project, not taking into account the number of registered people that will leave the project, so i'm curious what sort of text you would like to add to the large notice to prevent that. Mion (talk) 14:29, 9 January 2009 (UTC)

    Do you have evidence to support that rather bold claim that the number of IP editors on de.wiki has fallen by 66% since FlaggedRevisions was introduced? I certainly haven't seen any data that would support that conclusion. Happy‑melon 14:31, 9 January 2009 (UTC)

    The statistics * [2] (updated September 2008), User:Hut_8.5/German_editing_stats (2009),[3] (2009), [4] (live), de:Spezial:Statistik (live) Mion (talk) 14:36, 9 January 2009 (UTC)

    Are there similar statistics to these for a wiki other than de.wiki? Perhaps en.wiki or fr.wiki (or a wikimedia-wide agregate)? Without a control sample to remove systemic error it is impossible to say what proportion of the decline in IP edits (which I agree is present, although probably by closer to one third than two) was caused by the introduction of FlaggedRevs. Happy‑melon 14:47, 9 January 2009 (UTC)

    Sorry, but the statistics of Hut_8.5 do not show a decline in IP edits since the introduction of flagged revisions. There has been a decline of IP edits on de-WP, but that was long before the introduction of flagged revisions in May 2008. IP edits are, as far as we can tell, completely unaffected. Graphically, you can see that in de:Datei:Sichtungsstatistik_Diagramm_2008-10-10.jpg from October 2008. IP edits are in blue, the introduction of flagged revs is where the yellow area starts to emerge. --P. Birken (talk) 14:56, 9 January 2009 (UTC)

    Source of the graphics: de:Benutzer:IP_91.121.86.154/Sichtungsstatistik Mion (talk) 15:16, 9 January 2009 (UTC)

    As I understand it, statistics from pl.wiki and ru.wiki are collected but that will take a few months before enough data is collected, as for the 1/3 2/3 , the anon numbers on the German wiki were as high as 40 % , until de 1st of Jan, low as 14% , only the last week the number of edits on DE show a minor uplift in edits, we have to see what causes it. Mion (talk) 15:00, 9 January 2009 (UTC)

79. Strongly oppose. As they say in the military, If it ain't broke, don't fix it. It will create more problems than solve them. No.--jeanne (talk) 14:42, 9 January 2009 (UTC)
80. Strong oppose for a bunch of reasons. For this to be mildly workable, all editors would have to be able to flag revisions. But apparently that's not true, and coming up with a bureacracy to decide who has those rights - even for a test - would be hopeless. Secondly this will be weird and confusing for most editors that when they go to edit a page, it may be different from what they saw before thanks to unsighted revisions (multiple people trying to fix the same grammar mistake?). Thirdly this was apparently already tested on German Wikipedia, and a median time of *one week* to flag revisions is entirely unacceptable (needs to be more like "half a day"), so I'd say it was already tried and failed. And as others have already noted, flagged revisions still fails at catching the worst kind of vandalism, maliciously false information, so it's not even that much of an improvement - it only catches low-hanging fruit. (I do think this is a useful feature, but only for things like wiki-based publishing where there are editors-in-chief with flagging rights who release stories as "ready to go" using flagged revisions. But that'd be for much smaller scales with clear lines of authority, which doesn't apply here at all.) SnowFire (talk) 17:41, 9 January 2009 (UTC)
81. Oppose. This is a joke right? Freederick has hit the nail on the head above. Another layer of petty officialdom is the last thing we need here. Discouraging editors is the last thing we need. We're not children. Vandalism is not that big a problem that we need to censor all editors until the usual suspects who are supposedly "trusted" come and look at our edits. Will these "trusted" editors all be experts in the subjects they are censoring? How do we know? Who monitors the ability and/or competence of these "trusted" people? Who decides that they are trusted? This is totally and utterly unacceptable. If editors want to be treated like children rather than groun ups then please go to Citizendium and leave us alone here. Alun (talk) 18:12, 9 January 2009 (UTC)
82. Oppose: I could see this being done for BLPs, but oppose it for all other purposes.—Kww(talk) 18:38, 9 January 2009 (UTC)
83. Strongly oppose. Very bad idea. Implementing this would be the end of a freely edited encyclopaedia for registered editors. -- Necrothesp (talk) 19:28, 9 January 2009 (UTC)
84. Oppose: Article creation/improvement should be as much lean as possible. There should be a balance between the quality, the guidelines/procedures to secure that quality etc. and the effort/time required to provide such quality. Logos5557 (talk) 21:02, 9 January 2009 (UTC)
85. Very Strongly Oppose - Per Alun's, Snowfire's, Gnangarra's and Chamal_N's and countless other user's points. This ruins what this project exists to create: a freely editable encylopedia. Vandalism is not such a problem that this is required, and this will still not make Wikipedia articles any better for citations than it is now. Mattie^TK 21:11, 9 January 2009 (UTC)
86. Strong Oppose Per everyone else. This is just a really bad idea. There is no way it will work on a project this size. It will also be very confusing to newbies and to anonymous editors. It'll make the job of editors that much harder and won't help at all. It'd be a nightmare. Kolindigo (talk) 21:51, 9 January 2009 (UTC)
87. Strong Oppose. If the only alternative is semi-protection of all BLPs, flagged revisions are the lesser of two evils. I would find them a very bitter pill to swallow, though. TotientDragooned (talk) 23:16, 9 January 2009 (UTC)
88. Strong Oppose anything to do with flagged revisions. This obviously goes against the spirit of Wikipedia...if people get frustrated because of two-second article deletions, can you imagine the frustration that will result when their edits to normal articles don't show up? — Huntster (t • @ • c) 01:02, 10 January 2009 (UTC)
89. Oppose this system is useless, setting up different flags by itself don't improve quality of the articles. Implementation of Flaggedrevs in Russian and German wikipedias didn't give any real improvement.DonaldDuck (talk) 03:10, 10 January 2009 (UTC)
90. Oppose Would complicate things. Who then would decide which edits are good? Big man power issue. I would vote for more liberal use of indefinate protection from anon editing many pages.--Doc James (talk · contribs · email) 03:23, 10 January 2009 (UTC)
91. Oppose Wow. Per the above opposes, especially Chamal N. This is the encyclopedia where anyone can edit!, or have we forgotten? LittleMountain5 03:58, 10 January 2009 (UTC)
92. Strongly oppose, because that slows down the development process. On browsing facts, the flagged revision is automatically seen, a later development version will be seen only if one wish to edit/maintain, and the contrast when switching from revision to revision will confuse the editor, making him/her abstain from the mental complexity and possible confusion. (This is like transforming Wikipedia to the loony control freak concepts of Citizendum, it's just darn'd stupid). ... said: Rursus (bork²) 12:54, 10 January 2009 (UTC)
93. Oppose, slows everything down. While it is a good idea on paper I don't think this could ever benefit a website the size of this one. Garden. 15:05, 10 January 2009 (UTC)
94. Oppose Really don't like the sound of this. The attraction and the magic of Wikipedia is in the immediacy and simplicity of the editing Bobathon (talk) 20:26, 10 January 2009 (UTC)
95. Oppose It just complicates things that don't need to be complicated, and may make new users think they've got to learn all about the lunacy WP would be with FlaggedRvs before they could be bold. I know my answer even before the trial. And we're not reaching consensus here...so what happens?--el Aprel (^facta-_facienda) 20:35, 10 January 2009 (UTC)
96. Oppose There's plenty of bureaucracy and convention for new users to get caught up in as it is.--llamapalooza87 (talk) 20:50, 10 January 2009 (UTC)

Neutral

1. Strong Neutral I have strongly decided I cannot decide. --209.6.21.168 (talk) 04:44, 5 January 2009 (UTC)

   It is always good to be content with one's position. :)sinneed (talk) 19:03, 5 January 2009 (UTC)

2. Comment I am opposed to implementing flagged revisions in general, but not to trying to learn more about ways to improve WP. So my support or opposition would depend on stuff like how long the trial would run and which pages would be affected. Politizer ^talk/_contribs 14:02, 5 January 2009 (UTC)

   These are things that we're actively discussing at WP:FLR/P. Your comments there would be very much appreciated. Remember that this proposal is only "part 1 of 2": we still need to have a full discussion and a similar consensus-building exercise for each separate trial, so if there is a particular bit of "stuff" that you don't like, you can voice opposition to that individually without having to oppose the entire process, which sounds to me like what you're saying. You can support the principle of a trial process here, but oppose individual trials if you think they are poorly designed or will be damaging. Or, even better, you can get involved with the development process of the trials and help ensure that they're well-designed and effective to start with. Happy‑melon 16:21, 5 January 2009 (UTC)

3. --cremepuff222 (talk) 02:02, 6 January 2009 (UTC)
4. See comment on my oppose. The Helpful One 17:13, 9 January 2009 (UTC)

Discussion

Widely advertised. Happy‑melon 18:18, 2 January 2009 (UTC)

Its not on the Watchlist header ? Mion (talk) 18:23, 2 January 2009 (UTC)

Things aren't added unilaterally to the watchlist header anymore; one of those links is to me proposing that we add it there. Happy‑melon 18:50, 2 January 2009 (UTC)

Can I say that the notion that this has been "Widely advertised" is a farce beyond measure. The day you put a notice in the anon notice explaining to the anons that this is happening is the day that you can say it is widely advertised. Considering this affects anons more so that anyone else your notices borderline on the spirit of wp:canvass for "Selective" notification as for anons will most likely not see this is even happening.   «l| Ψrometheăn ™|l»  (talk) 10:00, 8 January 2009 (UTC)

Errr One reason why I usually don't vote on these matters is that I haven't the faintest idea what the heck they mean. The words are English, I have a very good command of English - having once compiled a rhyming dictionary; reading this stuff makes me think that the Pentagon has had a hand in it. My apologies to whoever did word it - I would be insulted to be compared to the Pentagon. To a specialist, no doubt it is crystal clear. But, as with manuals written by experts (and read by total amateurs), could I ask for these things to be run past a relative newcomer before they are put out for consideration? Peridon (talk) 18:19, 2 January 2009 (UTC)

My best advice would be to go to the Live demonstration at en.labs and have a see for yourself. In one sentence, FlaggedRevisions means that when edits are made to certain articles, those edits are not immediately visible to readers, until they have been "sighted" by someone trustworthy to ensure they do not contain obvious vandalism. In one more sentence, this proposal is to give ourselves the ability to have a 'play around' with various options to work out how best to use this system on en.wiki. Hope this clarifies, feel free to ask any further questions. Happy‑melon 18:25, 2 January 2009 (UTC)

We could do with you giving a summary when they come up with these policy things. That seems nice and clear, thanks. Peridon (talk) 18:44, 2 January 2009 (UTC)

Don't feel bad...I speak English and this is still all very unclear. What I gather is that we'll actually be able to preview the edits as we edit, saving us clicking the preview button. This would replace seeing the code. Personally, I think the idea of guaranteed closed tags is wonderful, but I can only imagine how many unused closed tags there will be, and the once-lightweight wiki may become extremely heavy like Microsoft Word documents due to ghost tags. Bob the Wikipedian ^{(talk • contribs)} 05:49, 6 January 2009 (UTC)

I'm generally opposed to the idea, but if it must be passed, a few suggestions.

1. Make users reviewers automatically after 100 edits with at least 50 in the mainspace to be able to keep up with the site's edit volume.
2. Allow admins to grant revoke the permission as well, revoked users must have an admin grant them again to prevent abuse and reward good-faith editors.
3. Get rid of the "unsighted revision" and "sighted revision" messages found in other projects with FlaggedRevs, it would look unsightly.
4. Allow all edits by reviewers to be sighted (known as the autoreview permission) to make it more streamlined.
5. Create an "editor" class with the addtional permissions of:

• "Unsight" can return the page to the state (but not the version) before being reviewed so any edit will be made to the page itself. Can be undone by a reviewer re-reviewing then page (unless it's under a "review protect" that can be placed by admins, preventing reviewing of the page by non-admins). To keep pages that need to be rapidly edited open.
• "Sightundo" can undo the sighting of another reviewer to undo errors.

1. Allow reviewing of the wikipedia namespace. However only policy and guideline pages should be reviewed.

I reiterate my stance I am opposed to the idea as I think it would turn away newcomers who don't understand or agree with the FlaggedRevs idea.--Ipatrol (talk) 22:26, 2 January 2009 (UTC)

It is a change to protect all pages so that any edits made will be reviewed before any page is changed, is that right? It is an arms length from the public. Of course it is a good idea if I understand it correctly as a step to ensure the accuracy and vandalism protection of articles but it is unlikely to be a good idea across the whole board, is it? Again, a good idea but I reckon it is going to rush in without setting out where it applies. (also) There has never been an announcement to all users (for anything not just this), has there? Will there ever be? Shouldn't fundraising be promoted on all user pages with a community message here and there? ~ R.T.G 01:21, 3 January 2009 (UTC)

The sad truth is, a great many of our most intelligent contributors don't know their foot from their ass. Anything that brings complexity to Wikipedia is going to turn a large many people away. Anything that brings complexity, even the necessary things we have in place now. This is not one of those things. --♥pashtun ismailiyya 04:12, 4 January 2009 (UTC)

Now that this is being publicised across all of Wikipedia, it will dearly help if this could all be clarified as to what, exactly, it is. I haven't the faintest idea what I'm supposed to either support or oppose. The vast majority of Wikipedia users are not particular technical-oriented individuals, but so far much of this information appears to be written for an audience that is more familiar with Wikipedia's technical workings. Unless this is already what is being considered or has been considered before, has there ever been consideration of a rating system for users (a la eBay)? Over time, it could be easier to ignore edits in your watchlist made by established users and you could set your watchlist to highlight those made by those with a negative and/or minimal record. Cheers! --Bossi (talk • gallery • contrib) 18:30, 3 January 2009 (UTC)

• What is consensus and how will we judge it? This poll has been running at ~65% for quite a while, and doesn't seem to have any signs of budging from that. How are we going to be able to judge if there is truly a consensus or if there is an absence of consensus about this issue when we are done. I say that 65% is clearly no consensus, but others might disagree. NuclearWarfare ^{contact me}_{My work} 01:42, 5 January 2009 (UTC)

If we're going to have scalability issues like some people anticipate, then I would think that [5] would be the perfect solution. Kevin Baas^talk 20:53, 5 January 2009 (UTC)

Just a point I've been considering about this straw poll. It's a poll to (attempt to) indicate the community's consensus for a trial of the FlaggedRevisions system. Many of the responses under 'support' are ones saying the trial couldn't hurt, and it's worth a shot, the others are commenting on the idea of FlaggedRevs themselves. As I see it, this could actually have the opposite effect to achieving consensus - this poll should have been more clearly asking if editors supported or opposed a draft of 'x' policy on FlaggedRevisions, with a trial to be held if there was an indication of consensus.

If the poll shows support for a trial, this may be (mistakenly) seen/be used as support for the system as a whole. In the same vein, if it is shown as against a trial, this does not necessarily mean the consensus is that FlaggedRevs should not be used, just that the conditions of a trial should be set differently. Something to think about. - RD ^(Talk) 00:41, 7 January 2009 (UTC)

I don't think there will be enough support, there needs to be consensus which typically entails atleast 75% support.   «l| Ψrometheăn ™|l»  (talk) 18:47, 7 January 2009 (UTC)

::No comprendo The page linked to said GOTCHA. A joke or a feature or a hack??I

have no idea what it means or how it works; which is why I voted to only let registered users edit BLPs. But if gets rid of tag teaming, sock puppets, meat puppets, partisan deletion freaks, and agents of foreign govts I'll be delighted. Ha ha ha. OK, I read WP:Flagged revisions and finally got it. Will opine elsewheres. CarolMooreDC (talk) 22:37, 7 January 2009 (UTC)

I just wanted to mention here as well, that the German Wiki backlog objection argument ignores the fact current Protection policy is more disruptive to a Wiki environment than a FlaggedRevs system. Using FlaggedRevs on popular articles that are heavily trafficked, vandalized and consequently watched by active patrollers & admins -- a backlog simply will not form given the number of editors involved. When a backlog does occur on articles that have become under supervised over time, then a bot automatically nominates FlaggedRevs to be removed. If no one objects, it happens automatically and all held edits go live. The English Wiki has far more manpower available and if FlaggedRevs is used judiciously it free us from using Protections and gets Wikipedia back to its motto of letting anyone edit. Wikipedia's motto in no way guarantees every edit will go live. - RoyBoy 05:50, 8 January 2009 (UTC)

You make a good point. The only version of flagged revs that makes sense to me is the one where flagged revs replaces semi-protection. But that's one of only several trials that are being proposed. Most of them would see flagged revs live ALONGSIDE semi-protection. In those cases, then flagged revs would not be an increase, they'd be yet another layer of bureaucracy. Lot 49a^talk 07:46, 8 January 2009 (UTC)

Im starting to be concerned now that flagged revs could be abused by administrators as a tool in an editwar with other users who dont have the reviewer right, as for the scrutiny for the use of flagged revs will be less than that of protection.   «l| Ψrometheăn ™|l»  (talk) 10:04, 8 January 2009 (UTC)

It's not just administrators who have the ability to sight revisions. That permission is also given automatically to all rollbackers, and there is another user-right 'reviewer' that can, and will, be distributed widely to editors. The standards for getting the ability to sight revisions are likely to be lower even than those for getting rollback, so a huge number of people (probably over ten thousand) will have this permission. As such, edit wars are not very likely to be unbalanced in the way you describe. And if you think about it, it doesn't actually make much difference: as all logged-in users see the current version, the edit war is just as visible to them as before, so it will be sorted out as quickly, if not more quickly, than it would be without FlaggedRevs. And the worst that can happen from the point of view of a logged-out reader is that the article spends some time stuck in the wrong version, which happens anyway with protection but often for much longer and more arbitrarily. Most importantly, even if there is a 'sight war' over one section that results in that section being locked in the Wrong Version, other sections of the page can still be improved by impartial editors, which is not the case with protection. FlaggedRevisions is certainly not a solution to edit wars or POV-pushing, but it is much less disruptive than protection, either full or semi. Happy‑melon 12:02, 8 January 2009 (UTC)

Most importantly, even if there is a 'sight war' over one section that results in that section being locked in the Wrong Version, other sections of the page can still be improved by impartial editors, which is not the case with protection. Can you explain this further? This does not match up to my understanding of sighting which is on a whole-page basis as I understand it. What am I missing? Lot 49a^talk 10:09, 9 January 2009 (UTC)

A Kill Date?

If this "trial" goes ahead, when will it be voted on again to confirm wether flagged revisions stays or go?   «l| Ψrometheăn ™|l»  (talk) 09:45, 8 January 2009 (UTC)

If this proposal goes ahead, there will be subsequent discussions on what exact trials we want to conduct. When those discussions produce a complete and sensible proposal we'll go through the same stages of community ratification that we've done here, and a bureaucrat will judge whether there is consensus to run the trial. Each trial must have a definite endpoint, no trial can be open-ended. Once we've conducted a number of trials and analysed the resulting data, we will be in a better position do decide how we want to use FlaggedRevisions on en.wiki, and if we even want to use it at all. Whenever we want to make a final decision on that, we will need one final round of community consensus to ultimately set FlaggedRevs however we decide. Happy‑melon 11:54, 8 January 2009 (UTC)

History of this page

Anyone else not showing the history beyond December 30th? ♫ Melodia Chaconne ♫ (talk) 18:10, 2 January 2009 (UTC)

Works for me... Happy‑melon 18:21, 2 January 2009 (UTC)

I'm showing 30Dec then 2 Jan - but not my own post! Peridon (talk) 18:21, 2 January 2009 (UTC)

Masses of 2 Jans appeared now. Peridon (talk) 18:22, 2 January 2009 (UTC)

Well there weren't any posts here between 30 December and 2 January, so that explains why you're not seeing those :D. Are the recent posts appearing now? Happy‑melon 18:27, 2 January 2009 (UTC)

Most of the 2Jans (including mine) have gone again from history. I'm in the UK, if that makes a difference.) Peridon (talk) 18:42, 2 January 2009 (UTC)

They're back again including my latest (not this, obviously). Peridon (talk) 18:45, 2 January 2009 (UTC)

There were some history issues on I think WT:RFA a few hours ago, perhaps they are related? davidwr/(talk)/(contribs)/(e-mail) 19:05, 2 January 2009 (UTC)

• Server issues at the moment. See Wikipedia:Help_desk#Servers_getting_out_of_sync. Black Kite 19:22, 2 January 2009 (UTC)

Aha. There were, it looks like, six edits missing when I posted that message, but it seems fine now. ♫ Melodia Chaconne ♫ (talk) 20:18, 2 January 2009 (UTC)

Neither test please

We have two suggested tests. Neither is useful; both will be harmful.

• One is to sight all semi-protected articles for two months. For articles that need semi-protection, this will restore the obligation to revert vandals that semi-protection solved, and place in fewer hands: the reviewers. Furthermore, when vandalism dies down, as it tends to do, it will leave the article sighted. Sighting interferes much more with normal editing than semi-protection does; this is a net cost to Wikipedia in both states.
• The other is to sight all FA's. This is, if possible, worse. Problems with FAs tend to be subtle and complex, requiring sophisticated edits from printed sources. Will the reviewer be able to judge them? I doubt he will even have access to the sources.
  • If this one defaulted to making the unsighted the default visible one, it would have real prospects; at present, one editor can watch an article, and review recent changes to see if they need to be reverted; flagging would make this a tag-team effort. How much of an improvement this is over present capabilities will be seen; we seem to be able to handle most articles now. Septentrionalis PMAnderson 19:55, 2 January 2009 (UTC)

    Will the reviewer be able to judge them? Yes, because reviewers will only need to check the article for obvious vandalism, obvious copy-right violations and obvious libel. Ruslik (talk) 20:30, 2 January 2009 (UTC)

    Then it will not suffice for BLPs, which we need to protect against inobvious but actionable libels. If it will not do that, it has no purpose. Septentrionalis PMAnderson 18:46, 3 January 2009 (UTC)

Please take this failed proposal back to the German Wikipedia and drown it there. Septentrionalis PMAnderson 19:33, 2 January 2009 (UTC)

The first proposal tests whether the amount of vandalism such articles experience reduces in volume once vandals realise that their edits are not being reflected back at them; does the loss of the satisfaction of seeing their work immediately visible on the eight most popular website on the internet discourage them from making such vandalism? I personally feel that testing this on all 3,500-odd semi-protected articles is excessive; I'd rather see a trial on 1,000 such articles so we can compare to the 'control' of the articles that remain semi-protected. I have seen no evidence to support your bare assertion that "Sighting interferes much more with normal editing than semi-protection does"; that is something I would very much like to see some hard numbers on. Numbers that we could best gain by comparing... oh.

You completely misinterpret the role of sighting in the second proposed trial; the suggestion notes in large bold letters that "all revisions are to be sighted unless they are found to contain vandalism, copyright violations, or libel. FlaggedRevisions thereby functions as a low-level filter against obvious vandalism...". There is no "subtle and complex" judgement required; sighting here is to act as a filter against obvious vandalism, to quote verbatim. Of course, whether such a filter is useful is a matter for debate, a debate that we can much better have if we are in posession of some hard data on how effective it is. Data that we can best obtain by comparing... oh. Happy‑melon 23:06, 2 January 2009 (UTC)

Neither of your proposed tests makes comparison possible. Septentrionalis PMAnderson 18:46, 3 January 2009 (UTC)

Any data collected from such a test will be invalid. The current proposal admits, "The proposed configuration does not scale well to a full deployment". If it doesn't scale, then neither will our experience. Consequently, interpreting the results becomes a matter of voodoo: Someone will say, "The number of vandalism edits was ..." and someone else will say, "But the proportion of reviewers to edits will be ..." and they'll both be right. The minimum we ought to do is to make the test as similar as possible to the system we hope to deploy. The current proposal doesn't do that, so it doesn't give us the data we need. Ozob (talk) 00:44, 3 January 2009 (UTC)

If that is the case, then what are we doing now? Astrology? There's no guarrantee that our final deployment won't be a limited deployment; where is it written in stone that any final implementation must cover the entire mainspace? The implementation doesn't scale technically to a full deployment, that's a necessary safeguard. Procedurally and logistically it scales as large or small as we want to make it. If we wanted to conduct a trial over half the mainspace, we could do that with this implementation; it would just be technically very difficult (only in terms of what the surveyors have to do to set it up; for reviewers the situation would be exactly the same as a full deployment). Are you saying you'd support a trial that covered half the mainspace :D ? Happy‑melon 10:55, 3 January 2009 (UTC)

Yes, astrology about describes it; you are proposing to test on a large number of articles with no way of telling whether they would have been better or worse without the mechanic you propose to introduce. Septentrionalis PMAnderson 20:01, 3 January 2009 (UTC)

No, the proposal is that we continue to pour time and energy into the discussion of how we can test FlaggedRevisions, including what metrics and mechanisms to use, safe in the knowledge that when we finally get one, two, three, ten, sensible proposals we will have the technical means to implement them. If you want a another analogy, we propose that we build a lab. Happy‑melon 20:37, 3 January 2009 (UTC)

No, it is a proposal of certain technical means, which are themselves undesirable, to implement a suggestion for testing which themselves require massive rethinking to be implemented. Until we think this through, we do not need any tools; and we do not need these tools at all. If we are going to make sighting ability automatic, we should say so now; if not, we should not bother the developers. Septentrionalis PMAnderson 20:50, 3 January 2009 (UTC)

No, you see, in astrology, you entrust your life to the stars and the planets, who you can at least rely on to be in certain places at certain times. I think a better analogy for the present discussion is the Magic 8-Ball.  :-)

I'm willing to support some sort of test of FRs. I oppose them on principle, but I admit that I don't have the data to back me up; neither does anyone else have the data to support them. But I have objections to the current proposal. I really don't think it's precise enough to decide anything. I mean it: I really don't. When you called it "deliberately vague" above I nearly exploded. My first draft of my comment on that was way over the top. (I'm glad I always click "Show preview"!)

I'm comforted to hear that you don't forsee any procedural or logistical barriers to widespread deployment of the proposed FR system. That's not how I interpreted the caveat in the lead of the proposal—I interpreted it as, "We want to try something, even if we know it won't work!" I've edited the proposal to try to make this clearer.

I almost want to ask you to go through the proposal and put in twice as much detail, but since the poll's already started, it's too late for that. If this poll fails and you want to try again, I'd be willing to look over another proposal before you open a second poll. I'd also be willing to look over specific proposals for tests. If we have to test this thing, then we ought to do it right. Ozob (talk) 22:05, 3 January 2009 (UTC)

A side question: what percentage of BLP articles (rough guess) are categorized as Category:Living persons? I did a dirty quick test of 10 random articles, so 7 are tagged as living, two not tagged, one does not list year of death but the person was young and active in 1960s and can be alive now. NVO (talk) 20:00, 4 January 2009 (UTC)

Suggestion for articles to sight

Hey, I'm really excited to see this trial going forward, after all the time that's been spent discussing mechanisms like this without evaluating them. The big problem currently appears to be choosing which articles to evaluate it on. While one can easily debate about the relative benefits and costs to each class of articles, I think the most important thing is that the regular editors watchlisting a particular article are comfortable with having the feature enabled on it.

So here's my suggestion: let's create a template that is placed on the talk page of every semi-protected and featured article, and any other article anyone wishes to manually place it on. It will describe the new feature and ask the editors of that article to come to a consensus regarding whether it should be enabled on that article. If they approve, they'll contact the surveyor specified in the template. This is much less likely to produce a backlash and more likely to get interested users involved with using the feature. Dcoetzee 19:57, 2 January 2009 (UTC)

Should be active consensus to enroll; that would at least limit this to articles being actively followed. Septentrionalis PMAnderson 20:00, 2 January 2009 (UTC)

That's a very interesting idea. Instead of picking articles by type or subject, you're essentially saying that we should invite editors to suggest articles that they think could benefit from having FlaggedRevs enabled? That would certainly ensure a wide variety of subjects; I can certainly think of half a dozen articles I've worked on that I would nominate. Why don't you jot something down at WP:Flagged revisions/Trial/Proposed trials?? Happy‑melon 22:57, 2 January 2009 (UTC)

Sounds like a good idea to me.-Oreo Priest ^talk 14:46, 3 January 2009 (UTC)

• And permit users to protect articles against having FR. I think it not unlikely that the test will be actively harmful to the articles on which it is tried, and would prefer not to spend my time cleaning up my active watchlist from the harm it does. Septentrionalis PMAnderson 18:37, 3 January 2009 (UTC)

Glad to see this discussed. Pasted from my vote above: there should be a wide selection of articles included in this trial, otherwise the results won't be meaningful. The trial should include at least two of the following: FA article, BLP article, science article, controversial politics article. In each category there should be one high traffic and one low traffic article (traffic with respect to edits/day, not views). Xasodfuih (talk) 11:06, 4 January 2009 (UTC)

Bots?

Consider the following situation:

There are several revisions after the last sighted version when a bot arrives at an article.

• One is a piece of raw vandalism
• One is a constructive edit; to make it vivid, let's suppose it is a correction of a falsehood about a living person, in a separate section from the vandalism.

There are four alternatives I can see, if a bot can create sighted versions:

1. The new sighted version includes the revisions and the vandalism.
2. The new sighted version contains none of the revisions, thus retaining the BLP error.
3. The bot can select which revisions to include. How?
4. This will never happen. Why not?

Septentrionalis PMAnderson 21:44, 2 January 2009 (UTC)

Bots cannot create sighted versions in this situation, so the question makes no sense. Happy‑melon 22:31, 2 January 2009 (UTC)

To expand, the permissions given to bots mean that if a bot makes an edit on top of an already sighted revision, then the edit made by the bot is sighted automatically. If the top revisions is not sighted, the edits remain unsighted. So the 'answer' is 4: the situation cannot occur. Happy‑melon 22:32, 2 January 2009 (UTC)

That should be stated explicitly. It is a necessary condition for this not to lead to disaster.

But I'm not sure it's sufficient; not all bot edits are well-advised. (For example, some bots clean up syntax, and do not stop at direct quotations.) They should wait to be reviewed, like anons. Septentrionalis PMAnderson 18:40, 3 January 2009 (UTC)

I am not aware of bots that add libel, copyrighted material or vandalism to articles. So it does not make any sense to deny bots the ability to autosight their edits. Even if an edit is ill-advise it still should be sighted. Ruslik (talk) 19:44, 3 January 2009 (UTC)

But bots can worsen articles. Waiting three weeks for that to be corrected is a harm to Wikipedia. Septentrionalis PMAnderson 19:57, 3 January 2009 (UTC)

It is stated explicitly: in the PHP code for the specification, bots are given the autoreview permission but not the review permission. It is not technically possible for them to do anything other than the actions given above. I agree that it's not clearly explained in the proposal, but hopefully anyone else who picks up that point will read this thread and see the explanation. Editors can worsen articles too, everyone can. Are you saying that no one should have their edits automatically reviewed? Happy‑melon 20:29, 3 January 2009 (UTC)

You have identified a central problem with all flagged revision proposals (unless the unflagged version is visible), but there is a difference: Editors are presumed to be intelligent, and we assume good faith; bots are dumb, and will go wrong. Septentrionalis PMAnderson 20:53, 3 January 2009 (UTC)

I would say that the more fundamental difference is that humans are assumed to have judgement and bots are assumed not to. That's why humans can review and bots can't. The autoreview permission is an assumption of the good faith of the editor in question, which should apply just as much to bots as to their operators. I agree that bots screw up regularly and with varying degrees of spectacle. Just because an edit has been sighted doesn't mean it can't ever be reverted. That an edit is "sighted" will (probably) indicate that it does not contain obvious vandalism, spam or libel, nothing more than that. Since a bot physically can't add such things, I think we're justified in assuming that they're out to help, not to harm. Happy‑melon 21:25, 3 January 2009 (UTC)

Bots generally have a far lower error rate than human editors. We generally don't review bot edits currently anyway (which is why they have the bot flag). The odds of a bot making an error that's not just a formatting error is near zero. FlaggedRevs is mainly to catch vandalism and other things we really don't want readers to see; formatting errors really don't matter. Mr.Z-man 19:17, 5 January 2009 (UTC)

Sinebot

Sinebot made a strange edit to this page. As a result two my comments (and several votes, which were later restored) evaporated. Ruslik (talk) 22:21, 2 January 2009 (UTC)

Should probably contact slakr. §hep • ¡Talk to me! 22:57, 2 January 2009 (UTC)

Sunset provision

The enabling of any Flagged-revisions functionality (not the individual trials, but the entire schema) should be done only with a clear Sunset provision, which this proposal does not include. This proposal should be rejected on that basis alone. (sdsds - talk) 05:00, 3 January 2009 (UTC)

The only imperative statement in the whole proposal is that "each trial must have a definite endpoint". This is an extremely clear sunset provision for each trial, as you note. However, without an active trial, there is no "Flagged-revisions functionality"; if there are no active trials, the extension is invisible. Happy‑melon 10:50, 3 January 2009 (UTC)

On a technicalitly, there is no statement in the 'Future options' section of when the consensus for keeping FR will be reviewed. The proposal can be seen as allowing the beginning of new trials with specific endpoints indefinitely until one finishes with the right result. MickMacNee (talk) 15:29, 3 January 2009 (UTC)

What is the "right" result? Surely if we can ever agree that a trial has produced the "right" result then the trial period is over? I doubt the community's patience would stretch to an indefinite set of trials, and I trust our bureaucrats to judge the community's mood correctly. If support for continued trials begins to wane, then bureaucrats will be less amenable to beginning them, leading to the "invisible" situation. The sunset provision in this proposal is effectively that the community's willingness to continue is being reassessed at the start of every trial. Happy‑melon 17:55, 3 January 2009 (UTC)

The way to see whether this has produced the right result is to have a control sample which is not flagged, and which is otherwise comparable. Septentrionalis PMAnderson 18:41, 3 January 2009 (UTC)

Definitely, such ideas should definitely be a part of any viable trial. Happy‑melon 20:18, 3 January 2009 (UTC)

I would have said that measuring how much support has waned, given the multitude of different ways a trial can be proposed, is going to be difficult. Why not just say, "if after X months no specific trial config has made it into a roll out discussion, the feature will be removed"? Considering trials are in the order of months, this could be a very long process. MickMacNee (talk) 19:58, 3 January 2009 (UTC)

Doing so doesn't really mean anything, it's just an olive branch to those who are opposed to FlaggedRevisions in any form, since if support wanes the implementation goes into hibernation anyway. That's not to say it's necessarily a bad idea, of course. It would be rather difficult, however, to agree on how long X months should be, especially since as you say this is likely to be a very long process. I would be surprised if the trial phase was over before the end of this year. I think I have enough faith in our bureaucrats to trust them to make the right calls on this issue. Happy‑melon 20:24, 3 January 2009 (UTC)

Wikipedia -- The Encyclopedia that invites you to have faith in bureaucrats! Perhaps that model of governance is a big piece of the philosophical framework that allows some people to support flagged revisions.... (sdsds - talk) 21:13, 9 January 2009 (UTC)

Yes, that sounds about right. Why, is there something we should know about the ability of our bureaucrats to judge community consensus? Happy‑melon 21:44, 9 January 2009 (UTC)

Please indicate which wording in Wikipedia:Bureaucrats supports the assertion that a task like this is appropriate for bureaucrats. Taken to the extreme, bureaucrats could decide every word that apppears on each Wikipedia article page. We don't do that, though, because authoritarianism isn't the model of governance which has attracted so many editors to Wikipedia. (sdsds - talk) 05:21, 10 January 2009 (UTC)

Who determines the parameters of trials?

If we go forward with trials, who will determine the parameters of these trials? The proposal says that "A trial begins when there is a consensus on the pages, metrics and procedural details involved. Each trial must have a definite endpoint; either a fixed time duration or some other objective quantity." Are there going to be separate community-wide discussions about each and every trial or will the trials be put into the hands of a smaller, more manageable group held accountable to the larger community?

Until those questions are answered, it seems that the current proposal is entirely too vague. --ElKevbo (talk) 06:16, 3 January 2009 (UTC)

Each trial will require a separate consensus on which articles to include, how and when the various technical bits are assigned (when to sight, who to make reviewers, etc), when the endpoint is, and (most importantly) whether to go at all. As the bureaucrats are the ones with the technical ability to create 'surveyors', who are the only ones who can actually configure FlaggedRevs on individual articles, judging that consensus is in the hands of the 'crats; if we don't trust them to judge consensus correctly, we have much greater problems than a FlaggedRevs trial :D. While I expect the trial discussions won't attract as wide a community involvement as this discussion, they'll still be open to everyone to contribute. Happy‑melon 10:42, 3 January 2009 (UTC)

Could you at least amend the proposal to make clear that specficic proposed trials that can be proposed, as the four currently standing, do not have to be two months long, and do not have to require admins to allow reviewer rights. There are a lot of things that people clearly believe will happen in this process if implementation for trials is approved, but aren't mentioned anywhere on the page. The status of new pages for example as mentioned above in the opposes as well. MickMacNee (talk) 15:23, 3 January 2009 (UTC)

Amending this proposal while it's in a straw poll stage is asking for a riot, but the /Proposed trials page is entirely fair game (indeed I reverted just this morning an attempt to 'enshrine' those two variables there). Why don't you put something down there yourself? It's not 'my' poll :D... Happy‑melon 17:51, 3 January 2009 (UTC)

That is why WP:VIE strongly recommends against taking a poll until the proposal has been actively discussed, and then only to document an apparent consensus on the result. I have included a list of conditions which might persuade me and some others to support next time; but making proposals which cannot be changed shows a failure to understand that we edit by consensus. Septentrionalis PMAnderson 19:46, 3 January 2009 (UTC)

You've been asleep for about a month if you think this proposal hasn't been actively discussed, both with those active on WT:FLR and the wider community. Did you miss the RfC? Happy‑melon 20:17, 3 January 2009 (UTC)

No, I've just missed that obscure page; I will watch it hereafter. Yes, like most editors, I missed the RfC too; please supply a link. (This is why proposed changes to the whole of WP should go on watchlist notice.) Septentrionalis PMAnderson 21:34, 3 January 2009 (UTC)

If I understand you correctly, it sounds as if each step and parameter of each trial would require another round of community-wide consensus gathering. That, to me, seems unnecessarily bureaucratic and cumbersome. Would it not be more practical for these details to be worked out by a smaller and more manageable group of people? Whatever is done, it still seems that the proposal needs to be fleshed out and made more clear.

In any case, I appreciate your patience! --ElKevbo (talk) 17:57, 3 January 2009 (UTC)

I wouldn't say we need a separate community-wide consensus for each and every trivial detail. In the same way this proposal has evolved, we'd start with a framework, develop the details, invite community input and refine based on those comments, and then conclude with a consensus-demonstrating poll. That's the timeline of a good proposal. Doing so for each proposed trial separately is important for a number of reasons. Firstly, it acts as a check-and-balance to keep our feet on the ground and make sure that what we're doing has and continues to have community consensus. Secondly, it means we can have more than one parallel proposal in the 'pipeline', without which we'd be trying to shove square pegs into round holes to squash all the myriad possible variations on FlaggedRevisions into one implementation. Finally, we can separate that decision-making process from the two most controversial questions: "who arbitrates said decision-making process?" and "should we allow that process to proceed at all?". This proposal is really only to answer those questions: to say that the 'crats, rather than the devs, should judge our consensus, and that yes, we do want to carry this forward at least one more step. I agree that the individual proposals need considerable "fleshing out"; but that's another job for another day, once we've decided whether to let them continue to grow or slaughter them now :D. Happy‑melon 18:12, 3 January 2009 (UTC)

"Evolved"? How? Septentrionalis PMAnderson 19:46, 3 January 2009 (UTC)

If you read the archives, particularly some of the threads at the top of WT:FLR, you can see how this proposal grew out of two individual users' personal configuration ideas; the idea that we should conduct a trial grew organically from that discussion and pretty much snowballed from there. There was never a "Hey guys why don't we do a trial, we could run it exactly like this..." AFAIK. Happy‑melon 20:15, 3 January 2009 (UTC)

On the contrary, that's exactly what this page is; it leaves out many of the important specifications on what a meaningful trial should be, but includes exactly what keys and triggers should be used. Septentrionalis PMAnderson 21:10, 3 January 2009 (UTC)

I can see how it could appear to be such for someone who managed to miss all the discussion beforehand, and the first they heard of it was the announcement on various pumps. However, to conclude from that that the item in question must have been created instantaneously by some Designer is rather similar to certain other theories of questionable scientific legitimacy. The edits speak for themselves: this proposal grew from simple starting points into a more complex entity, pretty much the definition of evolution :D. Now we're keen to take everyone's input on how best to progress it further. Happy‑melon 21:40, 3 January 2009 (UTC)

I've just added some outline trial proposals. In light of the consensus dring a poll issue, if they aren't appropriate on that page, and need to come here, I would not object. Or should I mark them as late additions? MickMacNee (talk) 19:50, 3 January 2009 (UTC)

I'm glad to see some part of this that can be edited. Some of the discussion above implies that the proposals are not what we are currently being polled on, so modifying them should be fine. Septentrionalis PMAnderson 20:10, 3 January 2009 (UTC)

These are very interesting points; I think in particular a trial on Unwatched articles will be an absolute necessity. The /Proposed trials page was split out precisely to allow that page to evolve during this period of high interest, so as Pmanderson says, feel free to make whatever edits there you think are helpful. Happy‑melon 20:13, 3 January 2009 (UTC)

statistics please

Before this trial begins how about posting some stats on article edits, the numbers/percentage of vandalism edits that are true vandalism. How significant is this problem, is this going to address them or create little cabal worlds? Gnangarra 09:39, 3 January 2009 (UTC)

(Using the rule that 80% of stats are made up ...) looking at a small subset of about two hundred articles on my watchlist, about 15% of the articles have had vandal edits which I have seen (actually about 27 out of 180+) in a two month period. On those pages, about 3 to 5% of the edits are by vandals or very clueless newbies. It would be interesting to see if other editors have found similar ratios, or whether my group of "more contentious than average" articles represents worst-case. Extrapolating - in a test of 10,000 articles, I would expect 1,500 to be attacked within a given period of two months. Collect (talk) 23:51, 3 January 2009 (UTC)

I have done some research into this this afternoon. Working from the top of the recentchanges list, limiting to the mainspace and excluding log events, I have gathered the following statistics using a short python script, which I'm happy to post if you want it. From the most recent one million revisions:

• Roughly a quarter of all edits are from IPs (238100 (24%))
• The percentage of all edits that are obvious reversions (rollbacks or undos with things like "vandal", "spam" or "rvv" in the summary) is steady at around 4% (41,425/1,000,000)
• Of those obvious reversions, roughly two thirds are reversions of edits by IPs (25770 (62%))
• Of the individual users reverted, 75% of them are IPs. (17,941/24,211 (74%))

This does not really answer the most important question, which is "what percentage of edits by X are vandalism?", and note also that the method used to identify reversions will systematically underestimate the total number of reversions (and hence the total amount of vandalism). I do not believe, however, that there is systemic error in the last two figures, so I would be prepared to claim that "Three quarters of 'casual vandals' are IPs" and that "Two thirds of 'obvious' vandalism is from IP editors". Any suggestions for improving the depth and accuracy of these results? Happy‑melon 16:29, 4 January 2009 (UTC)

In short (and considering one million edits to be a statistically valid sample) almost 10% of IP edits are non-utile (giving them the benefit of the doubt). And about 2% of non-IP user edits are non-utile edits. This is, moreover, similar for IPs to what the German report claimed. Unfortunately we do not have a breakdown of regstered users by number of edits, and we must also be aware that some cases may be legitimate edit disputes as well (calling an edit "vandalism" does not automatically mean it was vandalism). Basically this means this experiment may not be the way to go (much as I wish it were). We would gain quite nearly the same positive result by making sighting only required for IP edits in the first place (basically a variant of "semi-protection") as we would be implementing flagging of all articles. Collect (talk) 16:47, 4 January 2009 (UTC)

We could test that. If we set up one trial with a bot to run round sighting all non-IP edits to stable versions (we'd have to give the bot 'reviewer' as well as 'bot' rights, because it can't normally do that), we'd be simulating exactly the system you propose. That could be an interesting implementation of FlaggedRevs (a full implementation would give autoreview to all registered (autoconfirmed?) users), certainly worth further consideration. Happy‑melon 17:09, 4 January 2009 (UTC)

Your result that 4% of edits are vandalism contrasts with a figure of about 10% that was being bandied about in Flagged Revs discussions a few months ago. As you point out somewhere else, WP editing has weekly and seasonal cycles. I suspect that the level of vandalism is much lower than average during school holidays for instance! PaddyLeahy (talk) 10:16, 5 January 2009 (UTC)

Note also that the count excludes bot edits, ie reversions by our anti-vandal bots; as I said, the percentage of vandalism is a systemic underestimate. Your point about school holidays is interesting though: I'm repeating the analysis taking one million edits from the bottom of the recentchanges table, which is December 6 onwards; at least some of which will be during school term time. Happy‑melon 10:34, 5 January 2009 (UTC)

Stats from the bottom of the recentchanges table are very much the same as those from the top:

How many revisions to analyse? 1,000,000
Total edits:   1,000,000
IP edits:        274,756 (27%)
Total reverts:    69,615
IP reverts:       45,191  (65%)
Total vandals:    39,309
IP vandals:       29,412  (75%)

I'll try and get the bot edits included. Happy‑melon 11:12, 5 January 2009 (UTC)

While you're doing that, do you think that you could get an estimate of how long articles spend in a vandalized state? Comparing timestamps between edits and reverts should give the start of an estimate. These stats are very useful, thanks! Lot 49a^talk 17:23, 5 January 2009 (UTC)

Also, it looks like 7.0% of edits in the older sample are vandalism. So PaddyLeahy might have a point. Lot 49a^talk 00:26, 6 January 2009 (UTC)

Likely so -- which is a tad more in line with my figures above. Key though is the apparent ratio of IP vandals which is quite nearly the same in each case. Collect (talk) 15:38, 7 January 2009 (UTC)

There are some links to studies over here. The result all seem pretty preliminary, but the main take home I get from them is that ~3% of page views of BLPs are vandalized views ~7% of article minutes of highly visited pages are in a vandalized state and that currently the median time to fixing is about 6-14 minutes (the mean time is much, much higher due to some vandalism that was missed for a very long time in a few cases).

At this point, given how hard a time we seem to be having coming up with good statistics or information on this problem, I feel like we ought to be spending more time gathering that evidence to make a rock-solid case for how serious a problem this really is.

I'm also open to hearing a compelling argument for whether having ~3% of page views of BLPs be vandalized page views is a compelling enough problem that we need to overhaul a significant portion of our editing and article approval processes. edit My tone is obviously sceptical but I am genuinely open to changing my mind on this. Lot 49a^talk 09:10, 8 January 2009 (UTC)

Here is another study. Lot 49a^talk 09:18, 8 January 2009 (UTC)

These are interesting figures and its lower then I thought, I expected to see around 35-40% of edits being vandalism related(edit/rvt) given the wider affect it'll have. To see results in the 3-7% range means that 93-97% of edits are not an issue, it appears to me that maybe we are making mountains in the sky over this. If there was a subset of articles which were attracting a higher rate I'd assess that but I definitely dont see any need based on these. An additional concern would be that complacency will creep into article watching making it harder to address the problems beyond edit/revert stage. As already said maybe a better effort in obtaining stats/measures would be beneficial before considering any trial period. Gnangarra 09:48, 8 January 2009 (UTC)

The more I read into the stats (and I agree that I think we need more studies) the more it seems like the biggest problem is the stuff that sneaks past the watch tower that is RC patrol etc. and then sticks around for a very long time because no one cares or is watching these pages. The median time for reverts seems really good, it's the nutty outliers where vandalism is unfixed for days that need to be brought down. These make the mean unacceptably high (though in aggregate, we're still talking only ~3% of page views showing bad edits live) It's not clear to me how FR solves this problem. I suppose it means that these unfixed vandalism changes would remain unsighted for all that time, but that brings up the backlog problem, the solution to which has been 'bots would auto sight posts after a certain amount of time" which means that the undetected-in-the-first-place vandals would still not be stopped? Lot 49a^talk 10:32, 8 January 2009 (UTC)

Is there a list of unwatched articles somewhere? If so, just advertising that fact might reduce the list. I wouldn't be averse to adding a few to my watchlist, and I'd expect that there are many others in the same position. - Hordaland (talk) 15:42, 9 January 2009 (UTC)

User:Dragons flight/Log analysis may be of interest: analysis of the situation up to October 2007, at which point 10% of all edits were reverted (20% of IP edits); in general the problem was growing with time up to then but now we have reached a bit of a steady state (slowly declining edit rate) maybe vandalism has stopped growing or is even declining as well. PaddyLeahy (talk) 21:17, 10 January 2009 (UTC)

No page will ever change unless sighted / "seconded"

There is probably a lot I don't follow regarding the mechanics, but one thing seems clear, no page will ever change unless sighted.

In other words, were all articles on FR, and were no-one to ever flag anything, Wiki would never change, for better as well as for worse. Under FR, change only happens when manual flagging occurs. That is a lot of work, but it is much less than doubling the normal activity we now have. Even were every future edit to be viewed and either passed or declined, that would be less than double work because reading and deciding take less time than sourcing and composing.

However, there is still a lot of work. That means a few people doing a lot or, on average, people sighting as much as they contribute. I guarded support the proposed trial, though I would recommend on purely mathematical grounds that even IPs should be allowed to sight articles. Quality revisions do not depend on sighters, who may know little about a topic, but on the contributors at a page. The advantage of sighting is mainly at low traffic pages where solo operating experimenters have been saying for some time, in their own unique, way that we should adopt a "display only if seconded" policy.

I have a feeling that mathematics will force us to be generous, or we will indeed only drastically slow genuine improvement and growth of the encyclopedia in our attempt to exclude vandalism. It's worth remembering that more sources are published every day than current levels of volunteers could ever keep pace with. "Seconding" edits is the perfect counter to solo experimenters; however, authorising selected volunteers to render judgments outside their areas of expertise will only lead to burn-out of those volunteers, contributors they clash with, and the encyclopedia itself.

Viewed positively, people's "sighting counts" will be a very important contribution to the encyclopedia, and get us all working more closely together.

"If it were done ... 'twere well it were done quickly."

I support FR so long as IPs are authorised as sighters. Alastair Haines (talk) 14:18, 3 January 2009 (UTC)

Uh, doesn't that defeat the purpose of FR? If were limiting which registered users can sight articles, how does opening it up to IPs help the situation? IPs have no stable or permanent edit record, so even if an IP applys for sighting permission, how do we determine that the next person to edit under that IP is the same person who was given the permission? How do we stop vandals and trolls from using permitted IPs to sight their own edits or the non-productive edits of others? I don't see how FR can ever work unless we know exactly how is doing the sighting, and that they can be held accountable for what they do with the sighting priveleges. - BillCJ (talk) 15:07, 3 January 2009 (UTC)

Btw, I don't need to know anything about an article's subject to know that "This article is KEWL!!!" has nothing to do with nuclear physics or whatever other subject. The main point of FR is to keep the crap out of public view. - BillCJ (talk) 15:11, 3 January 2009 (UTC)

It is a point that everybody needs to bear in mind, under the FR system, there is no-one to "blame" for a perfectly good edit not being sighted, it is just an inherent feature of the system, much like there is no-one to blame if nobody investigates an SSP, or responds to an ANI or other noticeboard post. There is as far as I can see, no specific commitment to even investigate the effects of this basic change in the editting process in the proposal. MickMacNee (talk) 15:17, 3 January 2009 (UTC)

Thanks guys, two good points.

Yes Bill, no expertise is needed to reject "This article is KEWL!!!" which is why IPs can do it. On the other hand, I've been so long out of mathematics, I wouldn't trust myself to know if some "corrections" to the Laplace transform article were cheeky experiments or not. If we are to have "qualified sighters" that's fine, so long as they really are qualified; and that can't be determined within the current Wiki structure. User:BobTheJazzMan sights a correction to the Binary numeral system#Binary arithmetic to ensure it says "1+1=0" and rejects it as vandalism. How long will it take to persuade Bob, who is a trusted Wikipedian with 50,000 edits to music articles, that he's actually making Wiki maths articles less reliable?

I also take Mick's point, we are all to blame if contributors give up donating effort to Wiki because no one gets around to sighting their new Pokemon related article under the strain of having to prioritise where they go sighting, or because they're not a qualified Pokemon expert, or because they think they are.

I'm in favour of FR if it is a way we all take non-expert interest in one another's work, or support the work of others working in similar areas to ourselves. If it's going to introduce a group of "experts" into the system, that's a new thing altogether, and ultimately contributors will want to see verifiable independent, third-party backing for such claims of expertise, and constraints on taking action outside that reliably sourced expertise. That's OK with me, but if I were a maths editor confronted by BobTheJazzMan telling me what's right, because User:WikiRulesOK said he could be trusted, I'd have a good giggle and contribute my future donations to online knowledge via another web-site.

To conclude, I think FR is a brilliant step forward, if it forces us to take a closer interest in one another's work and "second" it for our co-workers. However, if we set up some system where some editors are supposed to be more expert than others, that's another thing altogether. Sighters will regularly be less expert than the contributors whose edits they are reviewing. Perhaps someone can come up with a dozen examples better than my "1+1=0" one. Alastair Haines (talk) 17:39, 3 January 2009 (UTC)

The only way FlaggedRevisions can work logistically is if the group of 'reviewer's make up a measurable fraction of the active user population. De.wiki has over five thousand sighters; we have three times as many articles as them, so we're looking at a reviewer base of at least ten thousand editors. No one is entirely sure how many active editors there are in total on en.wiki, but that must be at least 10% of the total, and including every one of the top quartile by activity. I don't believe that the formation of a 'cabal' in such a situation is really possible.

As for what will happen in such a situation, which I agree is highly plausible, I think the important thing to realise is that there is more to wiki editing than just sighting revisions. We have to actually make revisions as well :D. If User:Foo reverts a 1+1=0 edit and sights it, that situation is entirely analogous to User:Foo stumbling across such a phrase in an article today and 'fixing' it. When User:Bar, a more "expert" mathematician, sees the change, he'll have a quiet laugh, restore the change with an explanatory edit summary, and either sight the change himself or wait for a sighter to see the change (and the explanation) and sight it for him. The only change from the way it currently works is the "sighting" part; the history would be exactly the same, and it would appear very similarly in people's watchlists. Happy‑melon 17:48, 3 January 2009 (UTC)

Thank you Happy-melon, which is a really great name, but I won't ask more about it. You do calm my anxiety on key points. Most importantly, a very large number of sighter/reviewers is intended. I note the proposal suggests all who currently have rollback access, which I believe I have without ever having asked for it. And, incidently, I would never have asked for had a request been necessary. Likewise, even now, I would accept the responsibility of sighting if it was given to me, but I would not ask for it if it wasn't...

except for one thing:

you speak of User:Bar "sight[ing] the change himself". This is the odd thing, it seems that effectively the idea is that anyone can apply to sight her own edits, if she's not considered to be a potential risk of vandalism she'll be accepted. Presumably, if she breaches trust, she could lose this access; however, the main thing is, FR seems simply to be about a way of implementing a kind of "probabationary" feature for accounts. That doesn't quite match the figure of 10% of active editors being sighters, and were I a regular but not high volume contributor not granted the option of sighting my own edits, where others were, I might feel irritated that my good faith contributions have not already been noted and new hoops are being imposed on me.

Anyway, I don't mean to be critical of the FR idea, nor of your comments Happy-melon. I think we agree on most matters of principle and although it might seem there's a gap between your 10% and my 100% (sighting can be lost, but is otherwise automatic) I think that gap can be closed by what we learn from trials. You are doing a great job of helping talk nervous people like me and others through this trial process. That's precisely how a community should work, good for you! :) Alastair Haines (talk) 18:30, 3 January 2009 (UTC)

Thanks for your comments. I think a lot of people misjudge the amount of security we can legitimately expect from FlaggedRevisions, either expecting it to be a panacea to all our ills or to be of no use whatsoever. Of course it's not going to stop all disruptive edits, no technical measure can. What it can do is stem the tide and remove the bulk of the crap that we get deluged with every hour of every day, leaving us humans time to deal with the problems that can't be handled by such processes - and of course, the actual job of writing the encyclopedia :D. I don't see it as a "probation" so much as an expression of good faith: "you've clearly shown some good edits, and no obvious problems, so there's no reason not to give this to you". Obviously if that tool is abused, that indicates that our initial assumption of good faith was incorrect, and so it should be removed. The ultimate position should in fact be the same: all legitimate accounts have the flag, and it has been granted and then removed from all the 'bad' accounts. Of course logistically we're never going to get to that stage, but the principle is indeed the same. Happy‑melon 20:09, 3 January 2009 (UTC)

I do mean to be critical of the FR idea; I began by thinking this an ill-thought out proposal for testing it, but this discussion has convinced me that the original idea was almost as bad.

The example here makes clear what is wrong with it, besides sheer impracticability: suppose User:Foo with his good-faith fix, is an admin, and sights his own edit; there is no requirement that admins know or understand mathematics. Then we have something worse than the present situation, for User:Bar's fix may well have to wait three weeks or longer to actually take effect on the visible side of WP. Septentrionalis PMAnderson 20:24, 3 January 2009 (UTC)

Gosh, it would be nice to have some evidence for how long they'd have to wait that wasn't imported from a wiki with a radically different culture and mentality to ours... :D You raise a good point, and if our median sight time is 21 days it will indeed represent a significant problem. We really do need to confirm for ourselves that we can keep that backlog down. There's only one way to find out: to test and see if we can handle a small set of articles. If we can, we can try a larger set, and a larger set, until we are confident that we have either found our limit, or that we can handle an entire namespace. Some number between zero and infinity is the number of articles that we can successfully sight without building up an enormous backlog. No one here has the foggiest idea what that number is, we have no evidence whatsoever that is really applicable here. Why don't we collect some? Happy‑melon 21:45, 3 January 2009 (UTC)

This proposal admits that this test will not scale. The German Wikipedia as a whole is smaller than we are; tests can only prove that backlogs will exist, they can't disprove it. Septentrionalis PMAnderson 22:30, 3 January 2009 (UTC)

The proposal does not scale technically: the difficulty of maintaning a trial (ie setting which pages should and should not display FLR behavior) increases with the size of the sample. Of course the difficulty in maintaining the pages themselves also scales with the size of the trial, but that's what we're trying to find out. If we decide to have a trial on 6,919,460 articles, we can do that, it will just be a pig to initiate. The data gathered from such a test would be exactly the same as if we had enabled FLR over the entire mainspace. The point is that this configuration is not a sustainable solution for having large numbers of pages displaying FLR behavior. But then again, that's the whole point. Happy‑melon 16:13, 4 January 2009 (UTC)

No, the data from such a trial would be utterly useless, because nobody would ever be able to examine it. (The secondary consideration that there would be no control to compare it to is relatively minor.) Septentrionalis PMAnderson 16:56, 4 January 2009 (UTC)

Oh I quite agree, such a trial would be utterly useless and would have my most strident opposition. My point is that the data gained would be just the same (and equally useless) as if it were gathered from a full deployment. The proposal allows trials of any shape and size we want, with the understanding that larger trials are more difficult to organise. The only restriction is, as you correctly note, our ability to analyse the resulting data, with larger implementations being more difficult to draw accurate conclusions from. As evinced admirably by the mishmash of soundbites and statistics from de.wiki. Happy‑melon 17:06, 4 January 2009 (UTC)

I think autoreviewing as discussed in the section Autoreview delay below would be an effective way of preventing backlogs, at the cost of letting through a small proportion of vandalism; in this system all revisions that have stood as the current revision for a certain time period (say 24 hours) are automatically flagged as reviewed. The vast majority of vandalism is still detected, and no good edits have to wait longer than a predictable, reasonable period to get through. Dcoetzee 02:07, 6 January 2009 (UTC)

Questions for somebody with great patience . . .

I gotta tell you, as a technodolt, I'm just barely able to grasp what is being proposed here. I went to the Wikilab thing and made an edit, looked at the history, and now have some questions. Okay, so if the page viewed by the public does not change until it has been "sighted", what happens when multiple editors attempt to edit that page ere anyone takes time to "sight" it? Will the second editor see the page as edited by the previous editor, or the public page? I assume the former, and if that's the case, when I go to "sight" it, will it show me the edits individually or altogether? If there were six edits made since the last sighting, all by different anons, and edits #2 and #5 were vandalism, will I be able to dismiss those and leave the others? Doesn't all this lead inevitably to at least some likelihood of increased edit conflicts?

As an editor who has recently (and reluctantly) come to the conclusion that perhaps we should require registration to edit _{(it feels to me like 90% of anon edits are vandalism, and 90% of vandalism is from anons)}, I probably should jump on this proposal, right? But like someone in the discussion up there mentioned, one of the things that may motivate an editor in the early going of their Wikipedia career—whether they are anon or registered— is getting to see their edits right away. Are we going to be turning off a substantial portion of our potential editorship with this? Finally, can this process be applied exclusively to anon edits? That is, could it be set so that all edits from registered accounts—even those just created—would appear right away?

Just some questions from someone like everyone else here who just wants the best for the project. Unschool 17:07, 3 January 2009 (UTC)

Firstly, I could just as easily imagine someone getting a kick from seeing his/her edits immediately, as from seeing that another human being has agreed that those edits improve the Free Encyclopaedia.

Secondly, have a look at a page that has not yet been checked. The 'edit this page'-link at the top of the page will presumably read 'edit draft', and will allow you to edit the unchecked version, even showing you what (unchecked) edits were made since the last review. Have a look, experiment a bit. I think this should answer several of your questions. -- Ec5618 17:32, 3 January 2009 (UTC)

These are good questions. The first is very simple: the edit box always contains the latest version of the page wikitext, so there is never any conflict there; editors are editing the current version, whether or not they saw it on the 'view' screen. If there are differences, they are shown in a diff above the edit box, so editors will always know that they've either seen the latest version, or what the changes between the version they saw and the version they're editing are. This would allow them to see, for instance, if a change they wanted to make has already been made. If you're able to sight the page, then after you've made your edit you'll be invited to review the latest changes. A diff will show you all the changes made on top of the most recent sighted revision. If some of them are vandalism and others not, you may need to make another edit to revert only those vandal edits, but you'd need to do that with or without FLR (and with the system, you have a diff at the top of the screen to show you exactly what you're looking for). Once you're in a position where you're happy that the diff between the last sighted version and the current revision contains only positive changes, you can click a button to sight it (and by implication, all the edits before it). You don't have to sight each edit individually; they're sighted versions, not sighted edits.

We're all aware that the 'buzz' an IP gets from seeing their edits straight up in blinking lights is one of the things that is going to be lost with FlaggedRevisions. However, remember that that buzz is not always a good thing: I'm sure a large proportion of vandal edits are motivated by exactly the same instant gratification. Although obviously I can't put any hard evidence to it (yet :D), I hope that the two additional low hurdles (creating an account to see current versions, and getting some sort of reputation to get the 'reviewer' flag) will actually encourage people to make the transition from being the IP who makes the once-in-a-blue-moon spelling correction, to the registered user who makes the occasional gnome edit, to the fully-fledged editor who is an active part of the wikipedia community. I think our encouragement of existing editors is quite good; our biggest chokepoint is in getting IPs to register in the first place. I hope that this will actually help to get them on the map.

On a technical level, yes, we could give all registered users the ability to sight revisions. However, I don't believe that this would be beneficial. IIRC the numbers you quote at 90% are actually closer to 60%; certainly there are a staggering number of vandal edits that do not come from IPs. Sockpuppeteers, hardcore vandals and even casual vandals who use accounts purely to hide their IP addresses, all demonstrate that it is not possible to say with any certainty that all, or even an acceptable majority, of registered users are trustworthy. I would be very hesitant even to put my chips down to say that an acceptable majority of autoconfirmed users are trustworthy. In my opinion, this level of 'trust', which is really very low, is the lowest that requires the human touch; a review (however brief) by a real person who we've already determined to have coherent judgement. Certainly 'reviewer' should be granted very liberally indeed, to almost everyone who asks for it. But I think that having to make that step of submitting a request is important, for two reasons. Firstly, it encourages editor development, as noted above; making a foray 'backstage' is an open door to innumerable 'force multiplier' tools and features that will make them a more durable (less likely to drift away) and effective editor. Secondly, it weeds out the casual vandals and blatant undesirables (spammers and SPAs in particular). All in all, I strongly believe that a lightweight human review for 'reviewer' is an essential component of a successful FlaggedRevisions implementation.

I hope this answers your questions, or at least gives my perspectives on them. Feel free to ask if anything needs further clarification. Happy‑melon 17:39, 3 January 2009 (UTC)

Thanks for your answers, melon. There was a single point which I failed to make clear...I wasn't suggesting that all registered accounts be able to sight edits, I was suggesting that all edits by registered editors not need "sighting". But I can see from your other comments (about people registering to perform vandalism) that you would probably not favor this. One last question that I hadn't thought of before. If I am a "reviewer", are my edits automatically "sighted"? Unschool 18:15, 3 January 2009 (UTC)

If you make an edit to a sighted version (ie there are no changes between the time the last version was sighted and the time you edit) then the version after your edit is sighted automatically. If you make an edit on top of other unsighted revisions, the final version is not automatically sighted. This makes sense since it's versions that are sighted, not edits; if the only change between a new version and a sighted version is an edit by a trusted user, it makes sense to assume that the new version is clean. However, if there are other changes involved, it wouldn't be appropriate to automatically sight the new revision. Happy‑melon 18:19, 3 January 2009 (UTC)

Just one question... "Who's on first?" Seriously... I could not make heads or tails of your last answer. So let's try again... 1) If I am a "reviewer" are my edits automatically "sited" 2) if not, do I have to get someone else to site them or can I site them myself? Blueboar (talk) 22:01, 5 January 2009 (UTC)

Let's say User:123.123.123.123 edits foo. Their changes are obviously not autoreviewed; so after their edits the page has "unreviewed changes". Now let User:Rollbacker come and make an edit. They have made changes to an unsighted version, so their edits are not marked as "sighted": if they want the version after their edits to be sighted (and hence display for anons) they have to "sight" it manually (there is an screen for them to do this immediatley after their edit is processed). Once they've done that, the page is 'up to date', and has no unreviewed changes. Now if User:Reviewer comes along and makes an edit, all the changes that are made have been made by an explicitly 'trusted' user, so User:Reviewer's edits in this case are automatically sighted; no one has to manually mark them as sighted. Anyone who can sight edits can sight all edits, including their own; indeed there are subtle encouragements in the software for people to do this as good 'wiki cleanliness'. I hope this clarifies. Happy‑melon 23:10, 5 January 2009 (UTC)

Question regarding consensus

I'm strongly opposed to this idea, as are many, many others (not to mention, I'm sure, valid and productive IP editors). What are you guys in support going to take as consensus to push this forwards? At the time of writing we're on 93 in support and 38 in oppose, so that's roughly 71% support. In RfA that's considered by most to be the lowest possible percentage to promote an administrator. In RfB, that's not enough. I doubt it'd be anywhere near reasonable enough for ArbCom either. So, what are you guys going to say is the benchmark for you to take this forwards? I'd imagine it should be a lot higher than 70% support. —Cyclonenim (talk · contribs · email) 19:16, 3 January 2009 (UTC)

In this case, it's not up to us do decide. The developers are responsible for judging this particular consensus. That they are neither selected nor best placed to do so is a reason why we need control of this process in the hands of the bureaucrats. Happy‑melon 20:01, 3 January 2009 (UTC)

The very idea of placing this proposal up for a poll before discussing the implementation, and then declaring it unamendable, is a violation of the Wiki way, in providing no avenue to reach consensus; it should be dropped now. Fortunately, developers are unlikely to take notice of anything we do here. Septentrionalis PMAnderson 20:06, 3 January 2009 (UTC)

The point of this straw poll is to see whether there is consensus for taking the idea further, turning on the capability to have a trial and hashing out detailed proposal(s) for trials. As Happy-melon says, if subsequently there is no consensus on any detailed trial proposal, no trial will happen. This straw poll is not going to lead directly to any final decision being taken. Even if we have a trial, and even if there is consensus that the trial was a success, consensus could still change and we could still decide to turn it off again.—greenrd (talk) 10:28, 4 January 2009 (UTC)

I very strongly object to any tests under this protocol. (I have stated my reasons above.) I therefore object to the protocol in itself, and want it turned off now and permanently; I could support tests under other conditions. Others object to any tests of FR at all, because no results would get them to support such a change to Wikipedia. Both of us are entitled to object in toto now, rather than having to catch and object to each test proposal. Septentrionalis PMAnderson 16:51, 4 January 2009 (UTC)

This is my point precisely, and the whole reason to conduct the process in this fashion: it is important that we see whether there is consensus for, and for people like yourself to have the opportunity to comment on, the principle of conducting any trials at all before it makes sense to finalise any particular trial in detail.

What "other conditions" would you apply to the trial architecture? Happy‑melon 19:01, 4 January 2009 (UTC)

Wikipedia:Flagged_revisions/Trial/Proposed_trials#Conditions would be a good start. Not all of those are my ideas, but most of them are good ideas. Septentrionalis PMAnderson 22:19, 4 January 2009 (UTC)

I can't agree with the presented numbers, in sep 2008, registered editors (with more than 20 edits) made 13971 edits stats anons made 6058 edits ( 30,24 %) stats, we can safely assume that no anon editor would vote in favor of this proposal, so 185 sup + 102 opp makes 287 votes *.30 = +86 anon opposing votes, in effect the proposal has just as many opponents as proponents .

Taking into account that after the implementation on the German Wikipedia one of every 5 editors left the project raises the question, is 49 % enough ?Mion (talk) 03:28, 5 January 2009 (UTC)

The above arguments for requiring exceptionally high super-majority to represent consensus seem to be, a) I don't like it, b) All anons would vote like I would so we need to make it harder, c) Full implementation on the German Wikipedia resulted in lots of people leaving.

These seem fallible to me. a) "I don't like it" is obviously not a suitable reason. b) How anons would vote is speculation. Anons are simply editors without accounts. A large proportion of them could support it. c) This is more an argument against the idea, not why we need an exceptional super majority. So it devolves to "I don't like it" again.

I should note also that this is not an irreversible change, or even fundamental change at the moment. It's a trial of functionality, that may either succeed or not once it's tested out. Perhaps when it's time to poll on if it should be rolled out across the wiki, if that ever happens, it might require an exceptional supermajority, but not now. I think a simple majority would probably be good enough for a trial implementation. --Barberio (talk) 03:43, 5 January 2009 (UTC)

For the first A, is not about, I don't like it, the proposal is a change of rule 2. Ability of anyone to edit articles without registering , a change to make visible edits unvisible. One of the five core rules of the foundation. See m:Foundation_issues

For B, i suggest we do roll playing, I do the roll as Sighter and you logout so you become an anon editor, you make an edit and i make the decision about your valuable contribution. Mion (talk) 04:03, 5 January 2009 (UTC)

As I said, these are arguments against the use of Flagged revisions, not for a stronger super-majority requirement for a limited trial of flagged revisions.

You've had a full chance to convince people that your opinion is correct on it's merits. That people still seem to disagree is not a cause to require a greater super-majority considering it's only a limited trial. --Barberio (talk) 04:08, 5 January 2009 (UTC)

At the moment, this has less than 65% approval. Does anyone contend that this is a sign of WP:Consensus, even in our peculiar sense? Septentrionalis PMAnderson 06:52, 5 January 2009 (UTC)

For a trial, yes. --Barberio (talk) 07:01, 5 January 2009 (UTC)

Incidentally, comparing this to RfA votes is misleading, as this vote has a much larger population involved. The difference between 100 and 200 votes is more people than the difference between 10 and 30 votes. --Barberio (talk) 07:07, 5 January 2009 (UTC)

Yes, indeed, it is misleading. 65% of a sample of 300 is very likely to be within a percent or so of a sample of all Wikipedians; 4-2 or even 20-10 are much more dubious. But WP:CONSENSUS defines consensus as a compromise everyone can agree on; there is none such here. Even if all those who would support some form of testing were won over, that would only be 70% or so; 30% dispute this absolutely, and many of the supports are weak, depending on the fraudulent promise that FR will produce reliability and the erroneous impression that the delays on the German WP are minimal.

WP:Consensus also says Articles go through many iterations of consensus to achieve a neutral and readable product. If other editors do not immediately accept your ideas, think of a reasonable change that might integrate your ideas with others and make an edit, or discuss those ideas. That applies even more strongly to a change like this to Wikipedia's structure; the thing to do now is to discuss what changes to this proposal might make it broadly acceptable. It is possible that #just a thought... below, might be one such, but I cannot speak for those who find this unconditionally unacceptable. Septentrionalis PMAnderson 16:07, 5 January 2009 (UTC)

I think you're making a common miss-reading of WP:Consensus, that a single person or a minority, can filibuster any change by preventing an assumption of general consensus. The policy also includes the phrases, "Consensus can only work among reasonable editors who make a good faith effort to work together in a civil manner.", "Consensus is a partnership between interested parties working positively for a common goal.", and "A representative group may make a decision on behalf of the community as a whole.". Filibuster like attempts to set the bar artificially high, or require complete unanimity, are not good-faith efforts to work together. Consensus is not a set of handcuffs that tie the rest of the group to someone who wants to walk off a cliff. --Barberio (talk) 16:43, 5 January 2009 (UTC)

The correct interpretation of "consensus" is that the people with the bigger sticks can say that consensus exists even when others say it clearly does not. "Consensus" is routinely abused on Wikipedia to force through the wishes of cliques who have sufficient control of Wikipedia's power structures to do so. To push through this change, in light of the arguments presented in the straw poll, would be a clear abuse of process. However, as our soi-disant constitutional monarch has said he wants it, and has said elsewhere that he is prepared to impose policy on BLP issues, debate seems pointless. DuncanHill (talk) 16:49, 5 January 2009 (UTC)

Your point, Barberio, if I understand it correctly is, that consensus is like a majorite vote and if the majority is in favor, everyone opposing is a bad-faith editor whose point of view should be discarded? I am sorry, but I always understood that consensus is a question of who has the better arguments, not of what more people like. I'd prefer if some people were to judge consensus here who are not involved here and have no preference...if such people exist. Regards SoWhy 17:06, 5 January 2009 (UTC)

Everyone always believes that their own view is the better argument. So if we were to judge consensus solely on if people were presenting differing arguments they felt were valid, then one person could prevent anything happening by saying "I disagree because the space lizards say to."

Consensus is about trying to get consensus agreement by allowing for discussions amongst people working together in good faith. This does mean that a minority of dissent may occasionally have to be ignored if they can not convince the majority that they have valid arguments. The wikipedia processes do normally allow for 'well the basic majority want X, but the minority have compelling arguments not addressed by the majority' to be used to prevent finding of consensus. But not 'well an overwhelming majority want X, and a minority have presented arguments addressed and rejected'.--Barberio (talk) 17:21, 5 January 2009 (UTC)

If "overwhelming" means "slim" (and that with a debate which excludes most of those likely to be most adversely affected by the trial) then there is an overwhelming majority to implement this trial. If, however, "overwhelming" means what most people use it to mean, then there isn't. DuncanHill (talk) 17:54, 5 January 2009 (UTC)

I just want to point to a relevant past precedent : Wikipedia:Non-administrator_rollback/Poll. It was fully enabled with 304 for and 151 against. Some opposes made apocalyptic predictions much like now. After the poll was closed as implement, some filed a RFAR. Still we have non-administrative rollback now, and Wikipedia still exists. Ruslik (talk) 10:37, 5 January 2009 (UTC)

Unless the poll results change drastically,implementing this on these results would be a disruptive nuisance; anyone who presumes to do so should, at a minimum, be stripped of the tools they have abused. Septentrionalis PMAnderson 16:07, 5 January 2009 (UTC)

It appears that this trial will be implemented at the current count. You may, if you wish, take the issue to arbitration. --Barberio (talk) 16:43, 5 January 2009 (UTC)

Oh, there are so many other stops for disruptive and unsuitable admins before ArbCom; Barberio should feel free to explain his view here. For now, it is the minority even in this section. Septentrionalis PMAnderson 17:51, 5 January 2009 (UTC)

Barberio, there's no reasonable way this can be interpreted as a consensus. We need more discussion about implementation, not games of chicken where we challenge people to go to the ArbCom. JoshuaZ (talk) 20:09, 5 January 2009 (UTC)

• I feel it is perfectly reasonable to oppose this 'trial' on the basis that one would oppose the full implementation of the flagged revisions. discounting opposes on that basis seems like poor form. Protonk (talk) 20:01, 5 January 2009 (UTC)

Non-admin rollback was not a change to the fundamental principles of the Foundation, but rather a technical matter. In addition, for NAR, a developer called a consensus, but this was disagreed with by dozens of editors, even those who supported it. Comparing the two is a false analogy. NuclearWarfare ^{contact me}_{My work} 20:04, 5 January 2009 (UTC)

Discussions of site-wide technical changes like these are always difficult to handle because they cross the least well-defined territory in the balance of power within wikimedia: between the Foundation and the wiki communities. We are a wiki community, which has complicated, sometimes arcane, and outwardly inconsistent means of judging consensus amongst huge groups with vastly differing opinions. The Foundation is a much smaller organisation, with a hierarchy that is both more clearly-defined, and more linear. This technical change, if implemented, will be made by Wikimedia developers who are employed and contracted to the Foundation; they are both entirely obligated to do as the Foundation decides, and entirely immune from action by the community. How, exactly, would we "strip of the tools they have abused" someone with shell access to the database? These are people who could write this entire thread out of the revision tables and make it appear to have never happened.

The Foundation is totally dependent on its communities to create the free content that is its mandate; and yet the communities are totally dependent on the Foundation to organise and finance the environments and structures that 'house' them. The Foundation has to balance the desires of its communities with how well those desires support its constitutional goals, and the communities have to balance what's best for them with what's best for the readers. In this context, the thought that it is possible to put an absolute number on the percentage of support required is even more ludicrous than in most of our other poll situations.

This poll is, I'm sure, attracting attention far beyond the en.wiki community. I would be very surprised if its 'result' was judged solely by a single developer. I would not be surprised if the final outcome is not what anyone expects; in my opinion, it really is completely out in no-man's land. But my point is that this really is not a vote; it's not even a situation where we can apply our customary hodge-podge of vote counting and strength-judging. We could ask a bureaucrat to close it. We could ask all twelve active bureaucrats to present a collaborative analysis. We could ask our ArbCom to adjudicate. But when push comes to shove, it's really not our decision. We're making a request, effectively, for divine intervention, how are we supposed to dictate whether that intervention is granted? Happy‑melon 23:33, 5 January 2009 (UTC)

A hundred and more of us don't want divine intervention, thanks. Septentrionalis PMAnderson 23:54, 5 January 2009 (UTC)

I'm well aware of that, thank you. Well over two hundred of us do. Whose voice is 'louder' in the ears of the developers? I don't know. Some people (on both sides) have put forward some truly awful arguments which evidence little more than their inability to do basic research... will the developers weed out those voices and give them less weight as a bureaucrat would do? I don't know. Will certain voices be given more weight than others as a result of their familiarity to the Foundation (ArbCom, Checkuser/Oversight, etc)? I don't know. My point is not that we should be in any way discouraged from making both our opinions and our arguments heard; merely that trying to second-guess the result is doomed to failure. Happy‑melon 11:15, 6 January 2009 (UTC)

Above in this thread, Barberio wrote: "I should note also that this is not an irreversible change..." That's not the impression I have from other pages on this topic. I'm sure I read that once this gets implemented, it may or may not stay dormant, but that it will never be un-implemented. To me, that suggests many hundreds of hours spent mobilizing for & against dozens of proposals for more-or-less well-thought-out trials. A huge time-waster, in other words. - Hordaland (talk) 22:42, 7 January 2009 (UTC)

To suggest that it can never be "un-implemented" is simply not correct; like everything else on wikipedia, consensus can change and if there is a consensus to remove the extension, the developers will do so. However, such a consensus would need to be very strong; the "other pages" suggest rather that this would be quite difficult to achieve. However, with this proposal, the job of determining whether to allow another trial is not being made by developers each time, but by our local bureaucrats, who are much better at judging the desires of this community - that's why they were appointed. They can perform a more selective analysis of the actual strength of the arguments for and against, rather than a more-or-less straight vote count. So it will not be necessary to "mobilise" in the same way as would be required for a dev request; merely to clearly and coherently put forward the arguments for and against, in a widely-advertised discussion. I think the thought that there will be "dozens" of trials, or even trial ideas that become fully-fledged proposals, is misleading. Happy‑melon 12:21, 8 January 2009 (UTC)

On the contrary, requiring consensus against to turn it off is to declare that it will never actually be turned off. There isn't consensus against it now; there never will be, because some people will always see this as a magic pony which would solve all our problems, if we only wish hard enough. If there were a provision that lack of consensus to continue was enough to turn it off - as the German Wikipedia is clearly divided on it- then I would be more willing to experiment. But that's another point for the next draft. Septentrionalis PMAnderson 23:15, 8 January 2009 (UTC)

The distinction between "turning it off" as in completely uninstalling the extension and burning the extra database tables, and "not using it", is purely semantic; neither will prevent the 'magic pony brigade' from wanting to call in the cavalry, and neither will satisfy those who would only be placated if every copy of the source code was hunted down and destroyed. For the reasonable people in the middle, however, having this configuration installed but there being no consensus to do anything with it, is no different to not having it in the first place. Since each trial requires a positive consensus (and a sunset provision), to suggest anything other than that use of this extension requires continuing positive consensus, is disingenous. Happy‑melon 14:36, 9 January 2009 (UTC)

OK, so now I'm not one of "the reasonable people in the middle," thanks. I do not agree that the diff between uninstalling (or not installing in the first place) and not using is "purely semantic." If we don't install, we avoid long discussions like this one and get back to writing the encyclopedia. If we do install, there'll again be as many opinions as there are Wikipedians about which trial, how to do it, controlls, tests, evaluation etc. And people will be called unreasonable, as I have been here, and likely give up the discussions. Some will give up Wikipedia altogether.

Let the Germans fight it out for another couple of years. There is no hurry. The offer isn't going to go away. - Hordaland (talk) 06:20, 10 January 2009 (UTC)

Reversion

This edit is simply unacceptable. Some of us, clearly, believe that defining the necessary conditions for any future test to be the only point to continuing to discuss this page and the possible tools, instead of unconditionally opposing any future implementation of Flagged Revisions at all.

If Happy melon wishes to suppress discussion, it would simplify matters if he would state his chosen venue of WP:Dispute resolution now. Septentrionalis PMAnderson 21:07, 3 January 2009 (UTC)

This edit should also be mentioned, a few seconds before the one Pmanderson notes. My reasoning is given in the edit summaries; of course I will revert if there is consensus to do so. Happy‑melon 21:49, 3 January 2009 (UTC)

I agree with PMAnderson that it is important to raise these issues, and I agree with Happy-melon that Wikipedia:Flagged_revisions/Trial/Proposed trials is a better choice of venue. As a compromise, I suggest providing a suitable link or links from this front page to the subpage. Geometry guy 23:04, 3 January 2009 (UTC)

Huh?

I am probably as aware as most editors, but I have no idea what "Flagged revisions" are, and all of this talk and all of these references make very little sense to a very busy person. Okay . . . what IS a flagged revision? Yours in puzzlement (and please, no putdowns). GeorgeLouis (talk) 05:16, 4 January 2009 (UTC)

A 'flagged revision' is an edit made by someone who has not yet established themselves as a sincere contributor to Wikipedia. Flagged revisions are saved but not published until someone who has established themselves as a sincere editor reviews the edit and verifies that it is not vandalism. The primary purpose of flagged revisions is to eliminate vandalism, which usually comes from either unregistered users or registered users who have made very few edits. The German Wikipedia implemented an initiative like this several months ago. – SJL 06:46, 4 January 2009 (UTC)

The first two sentences are completely wrong: flagged revisions are not the unverified versions, but the verified ones. See m:FlaggedRevs. Geometry guy 13:48, 4 January 2009 (UTC)

Don't be a dick. I misunderstood and reversed the attribution, but the rest of my explanation is accurate. I was trying to be helpful, after quite a while away from Wikipedia, and you just reminded me why I stopped contributing regularly in the first place. – SJL 18:14, 4 January 2009 (UTC)

A sharper mind and a thicker skin might help. It is kind of important when discussing a trial of flagged revisions that the people voting on it understand what they are voting for, no? Many, apparently, do not. Geometry guy 10:52, 6 January 2009 (UTC)

Oh, pooh! Quit arguing. ("Can't we all get along?") Thank you, SJL. Sincerely, GeorgeLouis (talk) 08:14, 9 January 2009 (UTC)

Can trial also experiment with what IP users see?

As many have noted, it's hard to judge the impact of a change without experiment. So would it be possible to experiment with different appearances to the IP user? Here is one example I could imagine - there are many others:

• In one case, display the latest revision, with an optional button to view the last sighted version (and perhaps labelled latest revision with seal of approval or something similar, since an IP user most likely will not know what a sighted version is.) And perhaps a note that tells them that if they wish, they can create a login and make this the default, since they would not know that either.
• In the other case, display the latest sighted version as in the current proposal.

This could be done across different pools of pages, or sequentially, or randomly, or maybe diliberately set the English wiki up with a different policy from the German one, so the results can be compared.

This could allow us to understand some user behavior that is just speculation now. What percentage of IP editors are discouraged by having their edits not appear right away? What percentage of the time do users wish to see the different (latest, sighted) versions? How many people become registerd, and the first/only thing they do is set the sighted/unsighted preference? Of these users, how many become editors?

If we don't try some experiments like this, we could fall into the traditional computer science trap. A lot of high tech stuff has horrible user interfaces, since developers are selected from those who do not mind mastering arcane interfaces. It's just like the professor who knows the material well, but is a rotten teacher since they can no longer even imagine what it was like to not know the material, much less sympathize with a poor student. Likewise, here we are arguing about the effect on IP users, but since we are all registered users we are not at all typical newbies, and hence our opinions are suspect. So rather than argue about the effect on IP users it would be much better to measure it, if possible. LouScheffer (talk) 06:28, 4 January 2009 (UTC)

Expanding on your thought a bit. I would recommend that the first test involve only special test pages which could be used to establish the format for the basic messages that would be used in the following live tests. I would hate to have new users have to deal with something that experienced users have not even had the chance to review and test. I remain very concerned as to just what the IP users are going to see and just how they are going to have to interface with it. I know that we can change it, but the current default is totally unacceptable that I would not want to see it used in any live test. Dbiel ^(Talk) 20:20, 9 January 2009 (UTC)

Limitations

I would be happy with flagged revisions if

1. Revisions are accepted automatically after a period of time from last edit (say use mean time to vandalism reversion *constant, where the constant is between 1 and 3). I believe I read a paper on wiki which quoted the mean time to reversion. Can't quite remember where though. I may hunt it down later.
2. Articles are, by default, not flagged. Flagging an article should be considered to be almost as bad as a semi-protect -- these are quite similar.
3. A large userbase (say all autoconfirmed users, or some other level of trust) are able to sight revisions

Some features that would be useful

1. A filtering of the article history that is shows only draft & sighted edits. This would make diffing articles that have heavy vandalism a bit easier.

My 2 cents User A1 (talk) 07:14, 4 January 2009 (UTC)

Seconded. Imo very concise simple practical considerations.

Your #1 stops the FR system from making all change dependent on manual sighting—things'll tick over w/out us, phew!

Your #2 allows us to be sensibly selective about applying FR where it's needed, and spare ourselves unnecessary work elsewhere.

Your #3 seems to protect "anyone can edit", or is simply a practical necessity should FR end up being more draconian than your #1 and #2.

Your #4 sounds practical too, but though I'd be content that a filter defaults to "sighted"+"draft", I'd like to have the option to "see all", including who drafted alleged vandalism, and who deemed it to be so.

I'd be v. interested in both PMAnderson's and Happy-Melon's views on these suggestions. Perhaps they could agree on very specific things like this. :) Alastair Haines (talk) 07:50, 4 January 2009 (UTC)

• Number 1 is currently technically impossible, since FR do not have this feature. However 1 is actually not very important for the limited trials proposed.
• Number 2 is already in proposal. In the proposed implementation articles are not flagged unless surveyors manually enable flagging over them on page by page basis.
• I agree with number 3. Reviewer permission should be liberally distributed. Actually Flagged Revisions can be configured so that anybody with a certain amount of edits (other conditions can be attached too) is automatically assigned to the reviewer group. However we decided against including this into the trial proposal, because of the lack of agreement about criteria. In future automatic assignment can be implemented, of course. Ruslik (talk) 08:27, 4 January 2009 (UTC)
• As to filtering, if my recollections are accurate, it is already a part of FR (you can check this on en. labs).

Ruslik (talk) 08:27, 4 January 2009 (UTC)

As a side note #1 could technically be enforced by bots, writing a bot to do this could be done with nasty scraping scripts or with more clever use of the wiki-API (may need modification). But one would hope that such a bot would be located close to the wikimedia network to keep bandwidth down. Of course having it as part of the FR system would probably be most efficient. 121.44.50.78 (talk) 11:00, 4 January 2009 (UTC)

This seems a reasonable kernel for the next attempt at this. Septentrionalis PMAnderson 17:07, 4 January 2009 (UTC)

Report from Polish Wikipedia

As many of you know, we've been using flagged editions on pl-wiki for a while. Initially I was very skeptical about it. However, I changed my mind after a couple of times a vandalized edition was simply not visible to common folks - in my view now it really does increase the quality of output to the outer world. However, I have also noted a serious risk: quite often an established editor might edit a part of an article and accidentally add validity to some nonsense. I would not over exaggerate this risk though: after all to some extent this is what we have now. I disagree with some of the editors above that flagging should be "as bad as a semi-protect". I think that unflagging should be just a little proof that an edition is confirmed by an established editor, and thus should be quite widespread, while flagging last editions from IPs and new editors is only a consequence of this approach. Pundit|utter 07:53, 4 January 2009 (UTC)

• Please explain review procedure in pl-wiki: how deep the scrutiny goes? NVO (talk) 08:01, 4 January 2009 (UTC)

  You mean, in everyday practice? My wild guess would be that it does not go very deep. Some editors will certainly make a big deal of "certifying" some revision, while others would perfunctorily correct a typo without caring about simultaneous confirmation of the article's version. My point is, the bottom line is what we have now (an average Joe come to Wiki and perceives whatever is in there as "confirmed", I don't think everyday users see all the nuances, many do not even realize there is a history button on the page). Thus, flagging will serve a good purpose: occasional Wikipedia users will be more likely to see a sensible revision, rather than rubbish. I don't think flagging may resolve all our problems, but it adds some value. On the other hand I do realize it may be a bit confusing for new editors, whose edits will not be immediately visible to everyone. Pundit|utter 09:12, 4 January 2009 (UTC)

A few questions...

I'm struggling to find a page that explains this idea without techno-babble (no, I don't script antivirus software and design firewalls, so you may as well explain it in Welsh) so I have a few questions-

1. If an IP makes an edit to a page, can they then see it, or will they have to wait for someone to review it?
2. If an IP clicks "edit this page", do they see something in the edit box different to the article if another IP has made edits to it since a revision was approved?
   1. If not, do they edit the approved version, even if there are other edits waiting to be approved?
      1. If so, must reviewers choose the best possible "new" history, discarding the rest?
      2. What if the same IP edits a page several times, as is all too common? Can a reviewer only choose to save a single one of their edits?
      3. If multiple saved up changes can all be approved, what if they conflict with each other?
      4. Are we not going to lose attribution as reviewers choose to slip changes in under their own name, as they can't approve both changes made to a page?
3. Are recent change patrollers (I'm thinking particularly of the 12 years old, never wrote an article brigade) really going to continue recent change patrolling when it turns from the romantic notion of zapping vandalism, hunting down trolls and getting them blocked to the positively thrilling art of clicking to "approve" edits?
4. Does this not effictively mean that we are treating IP editors as vandals by default, meaning that they're guilty until declared innocent?

I'm assuming I've missed something significant here, as I refuse to believe the Flagged Revisions I understand could possibly be supported by anyone who had any respect for Wikipedia. J Milburn (talk) 12:30, 4 January 2009 (UTC)

You can try many of these things out in the live demonstration. An important point to realise is that we're not talking about verifying edits, but versions. The system works more or less as it does now, you see. When IP users visit a page, they see the stable version of the article. That is new. When they go to edit the page, they edit the latest 'draft' version, which includes all edits made since the 'stable' version was flagged. Indeed, the link 'edit this page' reads 'edit draft', to accentuate the difference, and the edit window shows some text to notify users that they are editing a 'newer' version than the one they saw. On top of that, the changes between the 'stable' version and the current draft version are shown, so that the editor can decide whether those changes are as much of an improvement as the new edits the user wants to make.

But the basic process isn't much different as it is now. Editing a page that has been modified saves a new version that includes both edits. Editing a draft saves a new draft that includes both edits.

Please have a look at the live demonstration. It will answer many of your questions. -- Ec5618 13:46, 4 January 2009 (UTC)

I'll have a go at answering your questions. If an IP edits a page, they will see a notice at the top of the edit screen saying (by default) "edits will be incoporated into the stable version when an authorised user reviews them". Once they've saved their edit they will see the article as it was before their changes, with a short explanatory banner including a link to the current version of the page. So the most recent version is only a click away. Whenever anyone edits a page, the contents of the edit window are the most recent version; if this is different to the version the user saw on the edit screen, a diff is provided to highlight any changes. So whenever a user with sighting ability goes to edit or sight a page, they see a diff of all changes since the last sighted version. It is slightly confusing to think of sighting individual edits, what is really sighted is the version of the page in between edits. So It doesn't matter if those changes were introduced in one edit or a hundred; what matters is the changes those edits cumulatively make. Really that's no different to the way things work currently, except that the process is made a little more streamlined and easy to keep track of.

I obviously can't speak for all or even any RC patrollers, but I can say with certainty that this extension isn't going to stop all vandalism. If used correctly, it can make vandalism invisible to the outside world, which is really just as good, but RC patrol is not going to change overnight. I don't know the answer to your question, but I want to find out. That's why we should test it to see if it works.

Obviously a lot of the 'philosophical' issues surrounding FlaggedRevisions are dependent on your personal point of view; but I think that many people overemphasise the extent to which FlaggedRevs represents a change in 'faith assumption'. We already treat IPs as second-class citizens, limiting their abilities, treating their edits with automatic suspicion. Whenever we see an IP contributing to a discussion we suspect a sockpuppet; whenever we see an IP edit at the top of our watchlists, we suspect vandalism. There's no avoiding the issue: I've just parsed the last ten thousand recent changes, found 1,706 rollbacks of which 1,189 are of IPs; of the 385 distinct users reverted, 292 of them were IPs. More data is (as always) needed, but the initial conclusion is that around 70% of vandal edits and 75% of vandals are IPs. With those two thoughts in mind, what we're 'doing' to IP editors with FlaggedRevs actually begins to look rather mild. Are we treating them with assumption of guilt? Yes, I suppose so. Do we do that already? Most definitely. In my perspective, what's new here is a way to approve IP edits, to remove that assumption of suspicion. That's new, that's not been available before; previously all IP edits were equally suspicious. It's a matter of perspective.

You've piqued my interest in edit statistics now, so I think I'm going to go write a script to analyse recentchanges more thoroughly, to try and get some more accurate numbers to play with. That's what this proposal is all about, after all. Happy‑melon 14:20, 4 January 2009 (UTC)

"Once they've saved their edit they will see the article as it was before their changes". This is not true, at least not on the demo install. After an IP user has saved their edit, they will see the most recent version of the article with the results of the edit visible. This shows to them that nothing went wrong and confirms the "anyone can edit" slogan. Only when refreshing the page or coming back to it are they shown the last sighted version. --94.192.121.203 (talk) 14:43, 4 January 2009 (UTC)

That's interesting to know - I never edit from my IP address as an absolute rule because it identifies me very accurately indeed, so I was making my best assumptions from looking at the source code. I presume that there is a note to identify the version as the current version rather than the sighted version? If so, I see that as a rather elegant solution to, as you say, confirm the "anyone can edit" philosophy and to allow them to check that everything went ok. Happy‑melon 16:08, 4 January 2009 (UTC)

On editing, it shows MediaWiki:Revreview-editnotice when the current version is sighted, and MediaWiki:Revreview-edited when there have been edits after sighting. Saving shows MediaWiki:Revreview-newest-basic-i and a note about an authorised users having to review edits to the page. --93.97.227.226 (talk) 01:25, 5 January 2009 (UTC)

And how will newbies react when their edit is visibly registered and then disappears? The tests will not register those who go away confused or disgusted. Septentrionalis PMAnderson 17:00, 4 January 2009 (UTC)

"Hey where's my edit?? Let's do it again!" Clicks on edit like before. "Oh, my edits are visible at the top of the page in green, that must be good. And right above them it says that 1 change needs review, and that Edits to this page will be incorporated into the stable version once an authorised user reviews them." ... "Oh and just to be sure, they're in the edit box too where I wrote them, so there's no way anything could have gone wrong! How long do I have to wait for an authorised user?" Does no answer to the last question make people confused or disgusted?? Haven't accounts of first time Wikipedia experiences shown more surprise that anyone can edit, rather than their attempts at humorous inserts sticking for a longer time? Anyone with any experience in collaborative environments, and heck, experience in working with people, will expect peer review. That's what all you watchlisters are doing already anyway, it's just hidden away to us anons who then have no idea of what's going on behind the scenes and nothing to lure us to participate in it. --94.192.121.203 (talk) 01:25, 5 January 2009 (UTC)

"all IP edits equally suspicious"? I, and Huggle's edit-assessing algorithm, beg to differ -- Gurch (talk) 17:11, 6 January 2009 (UTC)

I will agree with Gurch that "all IP edits are not equally suspicious" but speaking for myself they do all get more attention from me as being potentially more suspicious. - Other factors that I take into account include the edit summary (no edit summary = more suspicion) I consider registered users with redlinked user pages and talk pages to be no different that IP users. Dbiel ^(Talk) 20:38, 9 January 2009 (UTC)

Thankyou Happy-melon, Ec5618 and 94.192..., I do sort of see where I was going wrong while thinking about it. PMAnderson still raises my main concern- this is complicated and bureacratic, and is probably going to scare off potential users. Consider my opposition to this scheme weaker. J Milburn (talk) 23:41, 4 January 2009 (UTC)

Here's my attempt at answering the above questions. Note that some of the details are configurable options in the software. Also note that the use of flagged versions can be enabled or disabled on a page-by-page level.

1. If a non-logged-in user makes an edit to a page, they will immediately see the new version. If they return to the page later, then they will see the "flagged" version of the page, and they will also see a message explaining that there is a newer "draft" version available. They will be able to click on a link to see the new "draft" version, and diffs between the latest draft and the earlier "flagged" version. They will have to wait for someone to review the changes before the "draft" version gets promoted to a "flagged" version.
2. If a non-logged-in user clicks "edit this page", they will be editing the latest version of the page, whether or not that version is a "flagged" version. If the version they are editing is not a "flagged" version, they will also see a diff between the "flagged" version and the latest "draft" version that they are busy editing.
   1. They do not edit the approved or "flagged" version version, they always edit the latest version, whether or not it is "flagged".
      1. Reviewers see only one line of history, just as at present. Reviewers must check the diffs between the older "flagged" version and the latest "draft" version before they mark the latest draft as "approved".
      2. If the same user edits a page several times, and a reviewer wants to choose to save some but not all of theyr edits, then the reviewer will have to use the "undo" function to undo bad edits, or manually edit the article to their liking; after that, the reviewer can mark their own latest version as "flagged".
   2. There is no way for multiple saved up changes to conflict with each other, because there is only a single line of history, and each change (whether "flagged" or not) builds on the previous change (whether "flagged" or not).
      1. If reviewers make any changes before flagging an article, those changes will show up under the reviewer's name in the history.
3. Recent change patrollers will be able to continue the exciting job of zapping vandalism, hunting down trolls and getting them blocked; and will also be able to do the less exciting work of clicking to "approve" edits.
4. This would not mean that we would be treating IP editors as vandals by default.

—AlanBarrett (talk) 19:12, 8 January 2009 (UTC)

One consideration I think people are missing

Not sure how many people read the rest of the page compared to a hit and run "zomg this is horridz!", but one thing to remember is that anyone CAN see the drafts, even if they are an IP; at least that's how it works on the tests, and how I've always understood it. It's simply a matter of what one sees in a normal browsing -- you can switch to the draft any time you want. Yes, only 'trusted users' (or whatever) can site things, but we also have limitations on moving (and yet we still have such people are the one who moved this page to nonsense last night), limitations on making a new article, and of course semi-protection.
Plus, for now at least, this ISN'T about making the whole of WP FR. It's about making a small subset of articles where having the extra layer of control to what the non-editor sees is only a good thing. Earlier I came across someone posting a name and a phone number. Isn't it good that less people see THAT? ♫ Melodia Chaconne ♫ (talk) 12:50, 4 January 2009 (UTC)

It would be a good thing if we could certify the absolute bonesty and clue factor of every single editor before they could make an edit, but then this wouldn't be Wikipedia anymore. It would be a publishing house with a staff. MickMacNee (talk) 22:27, 6 January 2009 (UTC)

possible mathematical analysis to be done?

In "statistics please" supra, an interesting suggestion was made.

“ In short (and considering one million edits to be a statistically valid sample) almost 10% of IP edits are non-utile (giving them the benefit of the doubt). And about 2% of non-IP user edits are non-utile edits. This is, moreover, similar for IPs to what the German report claimed. Unfortunately we do not have a breakdown of regstered users by number of edits, and we must also be aware that some cases may be legitimate edit disputes as well (calling an edit "vandalism" does not automatically mean it was vandalism). Basically this means this experiment may not be the way to go (much as I wish it were). We would gain quite nearly the same positive result by making sighting only required for IP edits in the first place (basically a variant of "semi-protection") as we would be implementing flagging of all articles. Collect (talk) 16:47, 4 January 2009 (UTC)

We could test that. If we set up one trial with a bot to run round sighting all non-IP edits to stable versions (we'd have to give the bot 'reviewer' as well as 'bot' rights, because it can't normally do that), we'd be simulating exactly the system you propose. That could be an interesting implementation of FlaggedRevs (a full implementation would give autoreview to all registered (autoconfirmed?) users), certainly worth further consideration. Happy‑melon 17:09, 4 January 2009 (UTC)

”

Is such a test feasible? Would it delay the current proposed trial, or could it be done fairly quickly? I doubt it requires a great deal of time to run, and I would hope the statistics it furnishes would be of great use in discussing how well or ill the trial fares. Thanks! Collect (talk) 17:18, 4 January 2009 (UTC)

I meant that this is a trial that could be run under the configuration this proposal is considering. Writing a bot to handle the sighting would be fairly easy. If there was a consensus to run such a trial, it could be done very easily with the proposed configuration. Happy‑melon 18:55, 4 January 2009 (UTC)

Why would you need a bot, just give autoreviewed right to all users -- Gurch (talk) 19:18, 4 January 2009 (UTC)

If we concluded that the system was a success and we wanted to do it 'for real', then yes, that's exactly what we'd do. The thing is that implementing that configuration wouldn't allow us to test anything else, whereas by having the configuration proposed, we can with a little more effort simulate this scenario, while also trying other options. Happy‑melon 20:18, 4 January 2009 (UTC)

The idea is to get some concrete numbers to see whether the test as posited is likely to be as beneficial as hoped. If a smaller change has essentially the same benefits, then we should be apprised of that fact. At this point, absent solid figures, but using a sample of one million edits, it would appear that the whole flagging trial may not be any more effective than modification of what is now called "semi-protection." Alternatively, getting solid figures in this manner might prove to be the greatest argument flagging has in its favor. My personal opinion is that the system which requires the least added volunteer time would have the greatest probability of actually getting sufficient volunteers <g>. Collect (talk) 20:22, 4 January 2009 (UTC)

My personal opinion is that the system which requires the least added volunteer time would have the greatest probability of actually getting sufficient volunteers. I feel like this should be a named law (if it isn't already). Collect's Law? Lot 49a^talk 21:50, 8 January 2009 (UTC)

Autoreview period

I realize that this been proposed before, but I was thinking about some of the objections and I think many of them could be addressed by the idea of an autoreview period; any edit that has stood as the current revision for, say, 1 day, will be automatically marked reviewed. In this framework, users with reviewer privileges are solely responsible for expediting this process, so there isn't as much of a scaling problem; users without reviewer privilege would still be able to revert edits to prevent them from becoming autoreviewed. It helps avoid the issue of articles that aren't watched by reviewers never getting reviewed. And statistics show that nearly all vandalism would be caught in this period. Of course it would require an experiment to investigate this option, but it would be nice to at least get the technical support for it.

I also believe this is technically feasible; all that is necessary is that whenever a page is viewed, a check is performed, and the correct revision is autoreviewed if necessary. There is no need to "poll" all articles.

Thoughts? Dcoetzee 19:59, 4 January 2009 (UTC)

I don't like this much, as several of the articles I have watchlisted are not heavily watchlisted by others, and so there is often more than 24 hrs between times that someone takes a look. --Rocksanddirt (talk) 05:19, 5 January 2009 (UTC)

"It helps avoid the issue of articles that aren't watched by reviewers never getting reviewed" - please explain. If no one cares to edit them, even watch, why will anyone care to review them? And if the system simply resets the flag in 24 hours, what's the point? NVO (talk) 12:50, 5 January 2009 (UTC)

The point is that there's a 24 hour window in which to notice and revert the vandalism. Unlike full flagged revisions, it would not catch all vandalism, but it would catch most vandalism (to watched articles); in exchange, good edits would get through without the attention of reviewers. It's sort of a compromise between full flagged revisions and the current system. Dcoetzee 21:39, 5 January 2009 (UTC)

I like the idea, with a slightly longer timespan. As was noted very early in the discussions there's some php that can "sight" the articles if it stays stale for so long. I'll try to find it and put the quote(s) here. §hep • ¡Talk to me! 21:56, 5 January 2009 (UTC)

Not sure what this all exactly would do, but this seems its definitely possible. §hep • ¡Talk to me! 22:06, 5 January 2009 (UTC)

An expiration system, automatically showing revisions that are old enough to IPs, at least for non-blps, would eliminate the harm caused by backlogs and wouldn't decrease significantly the efficiency of flaggedrevs. Cenarium (Talk) 15:37, 20 December 2008 (UTC)

In order to limit or avoid backlogs, I've proposed to automatically 'sight' (more technically, expire) edits after a certain period (for example, 6 hours), with various ways to adapt the system, so that backlogs shouldn't be a problem.
Cenarium (Talk) 19:03, 15 December 2008 (UTC)

However, using an expiration system to show old enough revisions to IPs, at least for non-blps, would solve this problem, and still prevent the quasi-totality of vandalism and other disruption from being seen. Cenarium (Talk) 15:37, 20 December 2008 (UTC)

Watchlist?

When the most recent edit has been reviewed, will it show up differently on a watchlist? If I glance at my watchlist, can I tell which articles have approved edits and which have edits waiting to be approved or otherwise? J Milburn (talk) 23:51, 4 January 2009 (UTC)

Yes, there is an exclamation mark next to entries that have unreviewed versions, and a "review" link to confirm the latest changes. These also appear in the RC feed. The extension has been quite carefully designed to make it as easy and natural as possible to review things :D Happy‑melon 10:24, 5 January 2009 (UTC)

I personally think that the default watchlist entries and links are very satisfactory. The current demo can be used to see the impact on the watchlists, you just need to register on the demo wiki, or look at the history pages which have a similar format. It is the article page and edit page messages and links that need to be improved greatly. Dbiel ^(Talk) 20:45, 9 January 2009 (UTC)

Just a thought...

Sorry if this was already brought up before but, I wonder if anyone considered this idea, reviwer status is given to all users with autoconfirmed rights, and we replace semi-protection with flagged rev if an article is receiving a considerable amount of vandalism. So in theory it will work in a fashion similiar to semi-protection, but instead of blocking out the edits from new accounts and anon's completely, we can flag-rev the article which the autoconfirmed accounts can review anon contributions. Since pretty much anyone who regularly edits Wikipedia with an account pretty much has an autoconfirmed account, hopefully, there is no need to create a new usergroup with this implementation. Y. Ichiro (talk) 02:31, 5 January 2009 (UTC)

This makes sense to me. Actually call flagged revision "semi-protect" so that IP users can edit semi-protected pages in a sandbox like environment. There seems no reason to make all articles subject to "sighting". In this configuration, we would actually be increasing the ability of the general public to make edits. xschm (talk) 02:39, 5 January 2009 (UTC)

I started Wikipedia:Flagged revisions/Semi-protection implementation, if anyone's intrested, putting this into to a concrete proposal. Y. Ichiro (talk) 04:25, 5 January 2009 (UTC)

I'm liking it. Alastair Haines (talk) 08:15, 5 January 2009 (UTC)

I like the concept too; as noted above somewhere, this is something we could test using this trial configuration. Happy‑melon 10:25, 5 January 2009 (UTC)

• This may be the only implementation I could approve, since the problem of good anon edits being lost or delayed is much less serious. On a semi-protected article, such edits (except for an occasional talk page suggestion) are not even being suggested now. Septentrionalis PMAnderson 15:48, 5 January 2009 (UTC)

This is also the only FR implementation that I've heard of that I like. And I do like it, at least as far as it's been described. I still would like to know how we would test it, how we would measure success of the test, and so on before supporting it. And also how we would avoid flag creep (the tendency for FRs, once turned on, to stay turned on even after they're no longer necessary to prevent vandalism). Ozob (talk) 19:12, 5 January 2009 (UTC)

• Ditto to the above. This is the first time I've heard an FR trial that made me think "yes, that's an improvement!" I see that User:pmanderson has already added this as a trial to the list of proposed trials. Lot 49a^talk 19:25, 5 January 2009 (UTC)

I like it too. This is a way in which flagged revisions might actually enhance the principle that Wikipedia is the "encyclopedia that anyone can edit". I would foresee semiprotection being used more widely under such a scheme, but I don't see that as a bad thing: it is better (in my view) to protect more articles, but filter good edits to them, than to protect fewer and forbid all IP edits. This might also contribute to the BLP issue discussed elsewhere. Geometry guy 19:39, 5 January 2009 (UTC)

How do we test it? My suggestion would be to pick about 600 semi-protected articles, split them randomly into three groups of 200, and enable FlaggedRevs on one of them. As noted, this could be done with the trial implementation under consideration here by creating a bot with the 'reviewer' flag that would scan the RC feed for edits to those articles, and review any edit made by an autoconfirmed user. Once those measures are in place, we unprotect the group of articles that are in the 'FLR' cohort, and one of the other groups. Wait a predetermined period of time before resetting everything to how it was before. Then you analyse the data; the 'semi-protected' cohort is your control group, and you have two other groups which should go in generally opposite directions. Plenty of statistics for people to get their teeth into. This would be a very interesting trial. Happy‑melon 20:00, 5 January 2009 (UTC)

Hmm, testing this would be rather difficult using this version of FR as of now. Of course if there is a consensus to implement this in full scale, the devs might need to make some major modifications to the current version of Flagged Rev, such as having administrators being able to groups of users having reviewer status for specific articles, simliar to how protection is done by just clicking some textbox. A built-in system created to give reviewer permission for specific type of groups of user might be helpful, especially when if it is article-dependent too. Y. Ichiro (talk) 20:08, 5 January 2009 (UTC)

Well, as of right now, there's about 63% support for the current proposal. That's almost a two-thirds majority, but it's not exactly consensus. On the other hand, this suggestion managed to get the tentative support of three opponents to the proposal in less than twenty-four hours. This seems to be the way forward.

In order to make a serious proposal out of this idea, it seems like we'd need the following:

1. Technical implementation: Some PHP code, probably very similar to what's already been proposed.
2. Procedures:
   1. Draft policies for when flagged revisions are to be turned on and turned off. Similar to Wikipedia:Semi-protection and Wikipedia:Rough guide to semi-protection.
   2. Draft policy for which edits are to be sighted and which are not to be sighted.
3. Testing: We need a test that measures whether flagged revisions, semi-protection, or nothing is best for heavily vandalized pages. I'm not sure how easy it would be to do this, because pages get semi-protected and un-semi-protected; we'd need to find 600 (or so) articles that would normally be semi-protected for the entire duration of the test. (It'll depend on the length of the test, too.) We need to specify a duration for the test, criteria for success or failure, and a place to discuss the results.

Most of this is already in Y. Ichiro's proposal. I think it wouldn't be that hard to fill in the few remaining gaps, except maybe for details about testing. Does anyone else think it would be a good idea to drop the present proposal and focus on this one instead? Ozob (talk) 07:22, 6 January 2009 (UTC)

Y. Ichiro's proposal will require several serious changes to Flagged Revisions extension (and probably to WikiMedia software in general), which are unlikely in the foreseeable future. See Wikipedia_talk:Flagged_revisions/Semi-protection_implementation#Problems. Ruslik (talk) 12:04, 6 January 2009 (UTC)

That section contains no claim that this is technically unfeasible; but if this is true, it is an excellent reason for opposing implementation of the present system until it is fixed. Septentrionalis PMAnderson 17:44, 7 January 2009 (UTC)

Just like the core MediaWiki software, Wikimedia wikis run the latest stable versions of all extension software. So as soon as any modifications or improvements are made to the FlaggedRevs code, they will be available within days on all live wikis. Such improvements could also receive a higher priority and so be done more quickly if there is a wikimedia site that would immediately benefit from the changes. Like everything else 'wiki' problems are things to be fixed 'on the run' rather than sitting back and waiting for perfection to materialise. Happy‑melon 21:37, 8 January 2009 (UTC)

Purpose?

Apologies if this is covered above, but I was lead here by a notice I found when I viewed my watchlist. It lead me to the Trial page, but at no point on that page does it tell you clearly what the purpose of Flagged Revisions are, just how it will be implemented. I suggest a short "purpose" paragraph should be added. I won't be doing it, as I'm still trying to work out what the hell is being proposed(!), but I think that it would help many, many others like me... Stephenb (Talk) 13:35, 5 January 2009 (UTC)

I advise you to start with Wikipedia:Flagged_revisions, which contains necessary definitions and links. Ruslik (talk) 17:23, 5 January 2009 (UTC)

I did, but that was not the point of my comment. The point was to point out that the link on everyone's watch page leads to something which has very little context, especially for the novice editor, and this will put a lot of people off from reading further and contributing to this discussion. Stephenb (Talk) 17:58, 5 January 2009 (UTC)

Another thing which should be included in any future draft. This is why we discuss before polling, and why hairline majorities do not prevail; we want the best text, with the greatest practicable agreement before implementing any wideranging proposal. Septentrionalis PMAnderson 18:02, 5 January 2009 (UTC)

There is a discussion above that started 22 days ago, and that was just on top of all of the older discussions that have already gone 'round. §hep • ¡Talk to me! 21:52, 5 January 2009 (UTC)

It's not an explanation; and most importantly, it's not in the proposal where people will see it. Septentrionalis PMAnderson 04:07, 6 January 2009 (UTC)

Legal liability of Reviewers

See also: WT:FLR § Legal liability under a sighter system

Here it states that while the legal liability of the Wikipedia foundation would probably be not significantly affected by Flagged revisions, that it could make the reviewer liable. While most people will be prepared to take responsibility for their own edits, this could lead to reviewers being liable for other people's edits, which is a whole different issue. Some sort of clarification of these sorts of legal issues should be provided before we go live with this, even in a trial. I certainly would be unwilling to "sight" articles is I thought there was a significant risk of becoming involved in a court case for liable (or more likely, at least in the EU) privacy breaches.Nigel Ish (talk) 21:04, 5 January 2009 (UTC)

This sounds like legal paranoia to me. Is the editor of a newspaper held responsible if an editorialist is sued for libel? The newspaper as a corporation may be, just as someone might target WMF, but they would not target individual employees other than the writer. However, I'm not a lawyer (and neither are you) so this is all speculation. Dcoetzee 21:44, 5 January 2009 (UTC)

I agree with Dcoetzee. You are no more liable for sighting a revision than you are for editing one. So, if you are inclined to feel paranoid about legal threats for actions on wiki, you should just exercise the same discretion reviewing revisions as you would making them. Protonk (talk) 22:22, 5 January 2009 (UTC)

The, admittedly rather conservative, Opinion from Mike Godwin (the Foundation's General Counsel) is here. It essentially clarifies that, in his opinion, FlaggedRevisions does not make the Foundation any more liable. The explicit statement is that the situation vis avis FLR making sighters liable is a complete legal unknown, suggesting that this acts as a deterrent against potential plaintiffs launching a suit against editors. He also notes that the potential upside for plaintiffs of winning such a suit is fairly minimal in financial terms, a further disincentive. That quote is not the entirety of his e-mail response; the general impression I got from it was that he does not consider the legal ramifications to be a significant issue, at least in the wider context. Happy‑melon 22:42, 5 January 2009 (UTC)

So, the conclusions are that we don't know what the legal position is (particularly outside the US) but its probably unlikely that individual reviewers will normally be sued as a litigant is unlikely to get large sums of money from an individual. It makes me feel slightly easier, particularly if the reviewer stays within the field of his or her normal areas of editing where they are more likely to not let dangerous edits slip through.

However if Flagged revisions is going to work, particularly if/when it gets rolled out large scale, a lot of reviewers will be needed, and there will be pressure to clear articles that most reviewers won't be familiar with. This could either increase risks that things slip through or lead to longer delays if reviewers are not willing to operate outside their normal area of expertise or in higher risk areas through fear of litigation (whether justified or not).Nigel Ish (talk) 20:05, 6 January 2009 (UTC)

Test page?

Is this the current starting point for the demo to this proposed change? - http://en.labs.wikimedia.org/wiki/FlaggedRevs

If it is, I have found it to be a very poor demo indead, or should I say a very disappointing demo. If this is what an IP user will see, I am totally opposed to this proposal.

The following is what is displayed on the page when there is an unapproved edit (note: the leading icon is missing:

Draft [view page] (compare) (+/-)

If I were a new user, I would have absoluting no idea what this meant

And when editing the page the following is displayed:

The latest sighted revision (list all) was approved on 7 January 2009. 1 change needs review.

As a new user, I would have no idea what this meant.

I can see value in the concept, but the implementation is severly lacking.

I like the idea of being able to easily find the last reviewed page, and the history links are very useful for those who know what they mean, but for a new IP user they seem to make Wikipedia more difficult to use. Dbiel ^(Talk) 04:12, 7 January 2009 (UTC)

These are the default messages, which no one has been bothered to customise on en.labs. Every part of the user interface is fully customisable through Mediawiki: messages; we can make them louder or quieter, longer or shorter, include links to help pages or shrink them for convenience. Everything is changeable; these are just the 'bog standard' messages. Happy‑melon 10:40, 7 January 2009 (UTC)

I would be more than willing to support the trial, but only after an initial demo interface has been developed that is at least somewhat acceptable. I am fully opposed to any trial, no matter how limited, that would make use of the current default interface as seen in the demo. EN.Wikipedia is much to widely used to implement any demo that does not fully take into consideration its effects on new users. Dbiel ^(Talk) 14:44, 7 January 2009 (UTC)

One of the goals of the trials is to find which messages are appropriate and necessary. en.lab Wiki is a separate entity, and we have no direct control over it. Without enabling a working implementation here on en.wiki it will be impossible to customize anything. Customization of the interface is actually the first step in any trial. Ruslik (talk) 14:52, 7 January 2009 (UTC)

Nobody is going to display default messages on thousands page here. Initially FR will be, probably, enabled over only a few pages, so that all editors can try them in action. After that default messages will customized based on the feedback from the editors who tried FR on those few pages. Only after customization is complete, any serious trial can begin. Ruslik (talk) 15:01, 7 January 2009 (UTC)

The initial test needs to be done in a sandbox type environment and not on any live pages. No live page should be tested until a basic set of notices can be agreed upon. The first test should not be accessable by new users to Wikipedia (unless they are doing so as part of the testing process and with a full understanding of what the test is about first) This can be easily done by simply creating new test pages, NOT by using any current live pages. Dbiel ^(Talk) 18:41, 7 January 2009 (UTC)

Revision divergence (forking)

I have tried to find some practical information on how the complete procedure would work, but have not been able to find it. My main worry is about divergence of articles (forking in the history). When a revision has not yet been "sighted", subsequent edits would apply to the last sighted revision. After that there will be two imcompatible unsighted versions. The "sighting" process would need to integrate the modifications in both relative to their common ancestor, which is absolutely non-trivial and a heavy burden on the sighter. −Woodstone (talk) 09:37, 7 January 2009 (UTC)

Whenever anyone edits an article, in any situation, the contents of the edit window is always the wikimarkup for the current version of the page. If this differs from what was visible on 'view' before there is a diff above the edit box to highlight what's changed. So while traditional edit conflicts are still easily possible, revision 'forking' of this nature is not. Happy‑melon 10:42, 7 January 2009 (UTC)

So this would mean that I, a born proofreader, would click edit, search for the error I'd just seen, only to discover that it had been fixed, but not yet "sighted" (what a meaningless word!). Meeting that situation a few times, I'll stop bothering.

Worse, as I usually edit a section rather than the whole article, the text I'm looking for may not even be there, having been moved to another section a week or two ago, but not yet "sighted".

There's more than enough rigamarole to learn already for a new editor. I've !voted oppose. - Hordaland (talk) 15:00, 7 January 2009 (UTC)

The editing window would quite clearly point out to the editor that he/she is editing a draft version, and that changes have been made to it by other users. This objection is unfounded. -- Ec5618 15:16, 7 January 2009 (UTC)

No, it is well founded; that will give Hordaland an explanation of what it going on, but he will still not be able to tell whether his typo is in the current unsighted version or not without looking. Hordaland is assuming that he is not a reviewer. Septentrionalis PMAnderson 18:37, 7 January 2009 (UTC)

Yes. Thanks. - Hordaland (talk) 20:45, 7 January 2009 (UTC)

How so? All users would see the same message, and all users would be able to edit the draft in the same way. -- Ec5618 20:51, 8 January 2009 (UTC)

I'll add to that: when editing a page that has been edited since it was last sighted, the user, in all cases, is presented with a difference view at the top of the edit window, showing the changes that have been made to the article since it was last sighted. The user would thus be able to spot quite readily that the error had already been fixed, and be done. The process is quite transparent. Have a look at the demonstration. -- Ec5618 21:07, 8 January 2009 (UTC)

Don't forget, of course, that being a logged-in user, Hordaland will not ever see content that's not in the latest revision anyway. The changes since the last sighted revision are very clearly indicated with a diff display at the top of the edit window, there is no concern over people not knowing what's in the latest version. Happy‑melon 21:14, 8 January 2009 (UTC)

That's another change of specification since you last described it. It was supposed to be only reviewers who saw the latest version. Please make up your mind and put it in the proposal. Septentrionalis PMAnderson 23:18, 8 January 2009 (UTC)

Septentrionalis, many of your comments approach the condition of FUD but that goes well over the line. On every proposed implementation of FlaggedRevs, logged-in users see the most recent rev, flagged or not, unless they set a preference to see the flagged version. Read the proposal before commenting, and especially before telling people to add what's already there. PaddyLeahy (talk) 11:06, 9 January 2009 (UTC)

Thank you; that merely demonstrates why one only discusses one subject in one paragraph. I will divide the statements on logged-in users from those on reviewers for clarity, because I genuinely did not see them, and have had to reread the paragraph to note the change in subject. Hordaland's objection stands, I think; but I oppose all proposals which mean that editors do not see the text we actually display to the rest of the world. That will decrease our rate of corrections and our reliability. Septentrionalis PMAnderson 15:55, 9 January 2009 (UTC)

One general comment

On reading many of the comments here I think I need to point out that the flagged revisions are already enabled on some Wikipedias. A lot of comments read as if the wheel needs to re-invented at EN-WP. That's not the case: Just go to German or Polish Wikipedia to see the flagged revisions in action.

It's kinda like people from EN-WP don't realize there are Wikipedias in other languages too. Sorry, it sounds like the stereotype American that realizes there are countries other than the US too. Please try to not live up to that clichée of people from the English-speaking world just us Germans are trying to not live up to that clichée of bureaucracy and orders and so on. I know this statement is not fair and but that really is the impression I get by reading many of the comments on this page: I can assure you that everything has been discussed before. Open your eyes and go discover foreign galaxies;-)

Anyways, more comments from users at DE or PL would be great. --X-Weinzar (talk) 15:09, 7 January 2009 (UTC)

It's rather hard to "open your eyes" if you don't speak German or Polish, you know? Most people don't- in America, at least, the popular second languages (if you learn one) are Spanish and French. --PresN 14:38, 8 January 2009 (UTC)

Comments from DE-WP

Not the first time that I feel the communities from different language versions are way too much apart from each other. (For those interested: Recent examples include the RfA of User:lustiger seth and de-adminship of Gryffindor at Commons) I think there needs to be a lot more communication which is why I decided to share my thoughts from DE.

Some preliminaries:

• The whole thing has produced megabytes of discussion on DE (yes, MBs!) and still is being discussed. So you can be sure we've discussed every possible aspect already and the community is deeply divided. Still, opinion ranges from „all in all, this does more harm to Wikipedia than all vandals together. How come the German chapter of Wikimedia foundation waste money on this“ to „Best thing that has ever happened to us“. So be careful with anyone stating „well, it's just perfect“ or „greatest bulls*** ever“ but ask for an explanation.

• Success of Flagged Revisions is impossible to measure. You can't measure quality and you can't measure the amount of time spent for checking and approving or disapproving changes (which is, in many cases, time that would be spent when checking your watchlist normally anyway). So everyone is entitled to his own impressions of whether it is useful or not. While it may be useful in some areas, it may do harm on others. It is also almost impossible to tell whether IP editors are discouraged by this or not.

What needs to be clearly defined in case you want to try it out:

• Specify an end date. Otherwise the „test“ may just run forever as it probably would have on DE-WP until the community pressure was strong enough to force a further vote to actually vote on the introduction of Flagged Revs.
• The criteria for flagging need to be clearly defined. On the German Wikipedia, the criteria was to make sure the edits „don't contain blatant vandalism“ (you could call this a winged word by now). Later, people realized „blatant vandalism“ never was problem because 99.9% of this is caught by RC patrol anyways, almost all the rest by „normal watchers“. So what's the point of flagging revisions then? Also, it has shown that it doesn't keep vandals from vandalizing which was one of the main reasons it was introduced for.

Now, discussion is going on whether to change the criteria for flagging. This would create a lot of extra work for the „flaggers“ and the lag would increase.

So the most fundamental question in my view is: Is all of this worth the amount of extra work? As stated above, there is no way to measure this. However, my personal impression is that it's not. There may be a few articles that are not watched by people who can decide between useful edits and not-so-useful edits where „flaggers“ will revert the edit. But this doesn't justify the amount of work involved. Think about what people could do with their time instead: They could actually be improving articles;-) So all in all, while there are positive aspects, I've come to the conclusion that it's rather a waste of time. --X-Weinzar (talk) 15:17, 7 January 2009 (UTC)

I agree. I believe that this is reaching for the diminishing returns on vandalism reduction. Vandalism will never be eliminated in any society. As stated, the RC patrol reverts the majority of the changes almost instantaneously anyway; so my impression is that the latency introduced in the system could be better utilized within WP elsewhere. —Archon Magnus^{(Talk | Home)} 15:42, 7 January 2009 (UTC)

I contest that flagged revisions are ineffective against blatant vandalism; RC patrol and watchlists may result in quick reverts, but the vandalized revision is still visible to some number of readers. On popular articles, or articles that are vandalized often, this can be quite a significant number of readers. Moreover, many vandals will be deterred from introducing vandalism in the first place, once they realize that it's futile. The result is that the overall vandal fighting workload for contributors is much smaller.

Nevertheless, I don't see this as the primary purpose of flagged revisions; their main purpose is to remove the urgency from editing. Blatant vandalism can be left primarily to watchlists instead of RC patrol, because it doesn't need to be reverted that quickly anymore, freeing up RC patrollers to do something else. Edit wars are deterred because changes don't appear immediately, and each editor will have to think a little more about whether their changes will last long enough to be reviewed, encouraging more attention to consensus and discussion. To me "anyone can edit" isn't about instant gratification, it's about anyone having the opportunity to make a contribution with very little effort, and flagged revisions doesn't change that. Dcoetzee 19:41, 7 January 2009 (UTC)

Instant gratification is very satisfying for a new editor. It's pretty satisfying for me, too. My own suspicion is that anything that takes away from that would slow Wikipedia's improvement. And that's something we should avoid.

Regarding X-Weinzar's comments on measurement, I do believe that it's possible to measure these things. There are some proposals for tests. I, for one, will totally oppose any implementation of FRs without some sort of test of its effectiveness. Unfortunately, the present proposal has no provisions for tests. Ozob (talk) 23:25, 7 January 2009 (UTC)

Thank you for the detailed report. I think the summary of the de.wiki experience is: FR is a solution looking for a problem. Xasodfuih (talk) 01:49, 9 January 2009 (UTC)

Something regularly overlooked is indeed the amount of work it creates, work that could have been spent on RC patrol or article writing. Every small fact now has to be checked twice because e.g. if I change a number like 1011 people have died in this incident, the only way to find out whether or not this is blatant vandalism is to re-check the fact. This does make WP more reliable, but at what price? --Pgallert (talk) 10:14, 9 January 2009 (UTC)

Limiting the revisions to flag for large-scale implementations

See Wikipedia_talk:Flagged_revisions#Limiting_the_revisions_to_flag_for_large-scale_implementations Cenarium (Talk) 14:26, 8 January 2009 (UTC)

Not a panacea

Most of the support !votes seem to be cast on the assumption that FR will somehow solve the vast majority of our BLP problems. This is plainly false; the writer of this proposal disavows that view in this discussion, as a misunderstanding: FR are only for obvious vandalism and libel.

One supporter cites the case of Taner Akçam, who was detained going through Canadian customs because our article made a very serious accusation against him (see the article). That is a very bad thing; but I doubt FR would have prevented it. The falsehood was inserted by a named account, now permablocked (I note with amusement that the supporter is too); it appears to have had a footnote, citing a website. That is not obvious vandalism or libel; do we really expect all sighters to go to the amount of trouble required to disprove such an edit? How many sighters will we need, if they are expected to do so? (And if we recruit very many of them, I'm sure the libeller would have volunteered.) I gather on de-wikipedia they don't do any such thing; if we do here, what will our backlogs be? Septentrionalis PMAnderson 18:24, 7 January 2009 (UTC)

Founder thinks they're a good idea for BLPs, says something. Backlogs have been discussed above, we could in theory put in a few bits of code and expire pages after a set timeframe making the backlogs very manageable. Its been discussed of modifying programs like Huggle, Twinkle, and the other counter-vandalism programs to have the ability to sight articles as well. We have an ungodly amount of information to protect, but we also have one of the best taskforces on the planet who could just move around what they do a bit to take in sighting. General comment not towards this section A lot of the comments seem to be missing that this is an RFC for the ability to trial; before the trial would go everything...every little thing would be ironed out and then probably !voted on again before it went live. There's many comments on: there's not enough info on this or that and I won't support unless this is guaranteed; we're not even at that stage yet and a good majority seem to be missing that point. §hep • ¡Talk to me! 06:03, 8 January 2009 (UTC)

• Those who wish to advocate doing what Jimbo says because he says so should consult with him first; he disagrees. Septentrionalis PMAnderson 16:53, 9 January 2009 (UTC)

I think that the point that a good chunk of us are making is that this is backwards. FIRST figure out what you want to trial and THEN set up to trial it. The current order is more along the lines of a police department saying "we'd like to buy a bunch of tasers please - once we have the tasers, we'll sort out the details of how we want to use them". I'm opposed to this broad "let us have A trial, we'll work out the deets later" mentality, but I'm working with other editors on the proposed trials and restrictions section at the same time. Hope this perspective helps! Lot 49a^talk 07:57, 8 January 2009 (UTC)

This is, respectfully, a poor analogy. Until a specific trial is approved, no trial will be conducted, regardless of the outcome of this poll; even if the technical feature is turned on, it's not going to be doing anything until a specific trial is approved. Practically speaking, the only effect of this poll is that it will put other polls and discussions on the table if approved. A latent piece of software is not like a box of tasers. Dcoetzee 11:24, 8 January 2009 (UTC)

I couldn't agree more; that's an awful analogy. If you must compare it to buying tasers, what is actually being proposed is to buy a bunch of tasers and lock them up in a basement, giving the key to the police commissioner, until we decide how to use them. The tasers are there, and when we can present a convincing case for their use, they can be made immediately available, but they are as safely secured against accidental/unauthorised use as they were before they were purchased. The alternative is to spend hundreds of man-hours constructing a detailed plan of action, only for the budgetary committee to say they can't afford them. This proposal is not to say that we want to use tasers in this way or that way or even (and especially) not in any way we like. It's to ask "do we want to try using tasers? If so, we'll need to buy some tasers". Just because we have the tasers in store doesn't mean we have to use them now (without suitable governing policies) or even that we have to use them at all (unlike the real world, it costs us nothing to hold the tasers in store for ten years and then throw them away). It merely notes that if we want to experiment with using tasers in any way, shape or form, we need tasers to experiment with. Finally discarding the taser analogy (:D), Dcoetzee is entirely right: the extension is completely invisible unless and until a specific, complete, thorough and detailed trial proposal gains consensus. Unless and until that happens, it has no effect whatsoever. This really is 'part 1 of 2'. Happy‑melon 21:30, 8 January 2009 (UTC)

My understanding (please correct me if I am wrong) is that the software is already implemented (it's live on WP-DE after all) so turning it on is near-trivial. If that is the case, a separate poll for turning it on in principle seems pointless without a scaffolding of assurance for HOW it will be used once it is turned on.

I think that a latent tool for crowd (IP vandal) control is a pretty good analogy, actually. One of the problems with non-lethal tools like tasers (FR) as a supplement for things like firearms (protecting and semi protecting pages) is that rather than reduce the harm caused by the lethal tools, it makes police officers more willing to use force. So people who would never have been shot get tased and there is a kind of violence-creep. Am I being paranoid? It's very possible. But I think "we have the tools, so we may as well figure out a way we can use them" is a very probably response to turning this thing on. I'd rather have a plan and then enable the equipment. Lot 49a^talk 21:38, 8 January 2009 (UTC)

The issues are not technical but social: the huge amount of contention and debate that this proposal has generated (with arguments ranging from the coherent to the absurd) is testament to how "difficult" it is to implement. Technically it is indeed just a case of flicking a switch, but this proposal is not just about turning it on. It's equally a consensus on whether we want to make the social step of conducting trials and testing FlaggedRevisions with an open mind to its implementation - really it's "are we prepared to let go of our individual gut instincts (be they fire-and-brimstone or pot-of-gold-at-the-end-of-the-rainbow) and approach this from a scientific perspective?". The technical configuration is just a tool to facilitate that process. This proposal is not about FlaggedRevisions, it's about testing FlaggedRevisions, and about whether we want to give ourselves the greatest possible freedom to test it as thoroughly as possible while still retaining complete control over the process, as would befit a properly scientific approach.

I still wouldn't say that FlaggedRevs best suits a taser - I'd give that analogy to the Abuse filter extension, which is also in the works. Perhaps FlaggedRevs is more like a riot shield; it works by keeping vandals out, not by kicking them out. Either way, you still need to have them before you can work out how best to use them. Happy‑melon 21:48, 8 January 2009 (UTC)

Please stop calling me the 'author' of this proposal; not only does it imply an authority and responsibility that I do not have, it demeans the work of the numerous other editors who have contributed to its development. Despite what you might believe, this idea did not jump out of my head one evening and emerge fully-fledged for a vote the following day. Happy‑melon 21:20, 8 January 2009 (UTC)

My view on stable versions

I don't want to take the time to read this whole discussion, but I'd like to point out my arguments for stable versions. Jason McHuff (talk) 12:48, 8 January 2009 (UTC)

Question re tagging

One feature of Flagged revisions, is that edits by logged on users (who aren't reviewers) and bots will not be seen by everybody if they are on top of an un-reviewed edit by an IP until the version is reviewed. While for general edits this may merely be a nuisance, what about more time sensitive edits, such as (particularly) prodding an article or adding an Afd tag. In this case the fact that not everyone can see the tag could mean that IP or non-logged on users will not realise that an article needs help until possibly it is too late. Would it be possible to tweak the way we do things so that the clock doesn't start on these processes on a FR page until the tag has been "sighted" and anyone can see it? What happens on de and pl about these issues?Nigel Ish (talk) 18:40, 8 January 2009 (UTC)

I guess you could hard-code the interface to disallow the addition of tags to unreviewed pages. I guess it is pretty pointles even saying that benign tags like {ref-improve} should potentially not be seen by IPs. MickMacNee (talk) 19:15, 8 January 2009 (UTC)

A user who is experienced enough to be adding CSD/XfD tags to articles is experienced enough to ask for and receive the 'reviewer' flag in almost all proposed implementations. Happy‑melon 21:32, 8 January 2009 (UTC)

2005 WP:Block all anonymous edits

A very old discussion (short) where some of the same concerns we have now were raised several years ago. Collect (talk) 19:11, 8 January 2009 (UTC)

You wouldn't know it from some of the support votes, but Flagged Revisions is being proposed so that we do not have to force all editors to register. MickMacNee (talk) 19:19, 8 January 2009 (UTC)

As I've commented before, flagged revisions does not make it more difficult for anyone to make a contribution; it only delays the publishing of their contribution. This is the distinct difference between FR and no-anonymous-editing. That's not to say it has no negative effects, but it's a different thing. Dcoetzee 23:24, 8 January 2009 (UTC)

'More difficult' depends on which set of articles it is applied to. If it is going to be applied to every single BLP, irrespective of whether they were being protected beforehand, then obviously it is going to be more difficult for IPs to edit. If it is going to be applied to all articles, even more so. If applied just to protected articles, then it depends if you think changing from having to ask to edit, to having to wait for an edit to be approved, is making anything any easier. This is why asking for a poll when every supporter has conflicting reasons for believing it of benefit was unwise. Nobody can make a conclusive argument and nobody cna make a conclusive counter argument, because even the basic issues such as which article set to apply it to have not been agreed. 15:18, 9 January 2009 (UTC)

I fail to see why this is the case. The poll needs to be held separately, if nothing else, because the devs don't care about our policies and the way we'll use it. They just want to know if they should turn the software on or not. Since no specific trial is proposed, having the software turned on will not make a blind bit of difference to the daily running of Wikipedia - no pages will be flagged or anything. In that sense then, having this poll is just as good as having a poll on a specific trial. Since no trials can run without another community discussion, in which the different factions of faith in FR will have to come to some consensus about it, I don't really see why a lot of the people above are opposing it (except those who are against FR on principal, which I completely understand) Fritzpoll (talk) 18:23, 9 January 2009 (UTC)

The logical benefit from deciding which general but incompatible uses have the most general support to go forward for specific trials before you switch it on is just obvious to me. These discussions are already way too complex, convoluted and hard to follow without intentionally making it more so further down the line by not even starting with some basic assumptions, all seemingly just for the convenience of devs. It is horrifying to think what percentage of the community (mainly IPs) are already automatically disenfranchised from just this poll, never mind the future massively complex multi-way multi-aspect discussions that are due to come under your model. MickMacNee (talk) 19:00, 9 January 2009 (UTC)

I agree, there might have been some aspects that could have been discussed first, but as far as I can see, these are just the parameters for the technical implementation. Everything else that would be needed for a trial can be determined by the parameters of individual trials. A sitenotice announcing this poll might have been a good idea, except that it doesn't really affect them at present. I would oppose the implementation of any trial that wasn't advertised on a sitenotice where all (including IPs) could see it, FWIW. Fritzpoll (talk) 19:19, 9 January 2009 (UTC)

That's not the only such discussion. Disabling editing by people without accounts is a perennial proposal, also to be found at m:Anonymous users should not be allowed to edit articles and repeatedly at the Village Pump and elsewhere. It is perennially countered by those who point out that people without accounts are actually responsible for most of our content, and that in some cases it is the people without accounts who are quietly fighting the vandalism of the people with accounts. Uncle G (talk) 01:46, 10 January 2009 (UTC)

Closing time for this poll

The straw poll on implementation will be a week old in about five hours, and the rate-of-change of both !votes and discussion is inevitably declining. What is a suitable time to close the poll and present it to the developers for evaluation? This evening? After it is ten days old? Two weeks? Happy‑melon 12:06, 9 January 2009 (UTC)

Two weeks at least, ideally a month IMO for such a change. MBisanz ^talk 16:07, 9 January 2009 (UTC)

IMO practically any time now, except that at least 24 hours notice should be given. - Hordaland (talk) 17:36, 9 January 2009 (UTC)

No reason to close yet, people are still voting, Wikipedia will still exist after this is over. Give it at least another week. — neuro^(talk) 18:00, 9 January 2009 (UTC)

I agree that we should not close at such a time as to prevent significant numbers of contributors from participating; however I think we approach the point of diminishing returns - leaving it on the watchlist for a month would not result in significantly more participation than leaving it for just a few more days. I concur that the close should be announced well in advance. Happy‑melon 22:05, 9 January 2009 (UTC)

The reason why I say a week is because we are not in a rush to get this implemented - we will still be here no matter how long we wait. There is no harm in waiting for a little bit of time, I'd say at least 5 days warning would be preferable. — neuro^(talk) 22:51, 9 January 2009 (UTC)

Because this affects IP users in a huge way, can this please be placed in a place where IP users will see it? And can something be added to WP:Flagged revisions? It's hard to get here from there. I hope this isn't closed before IP users find out about it and have a chance to comment. 141.151.174.108 (talk) 21:50, 10 January 2009 (UTC)

participation

No matter which side you're on, it sure is nice to see 450+ people chiming in. Both sides are making very compelling arguments. I'm glad to see so many people care so much about this project. Cheers to all, Kingturtle (talk) 17:12, 9 January 2009 (UTC)

Indeed. Too bad so many people hold the wrong opinion. :) --ElKevbo (talk) 21:53, 9 January 2009 (UTC)

I don't want Wikipedia becoming a walled garden. That's why I oppose. doktorb _words^deeds 10:02, 10 January 2009 (UTC)

Vandalism problem

If flagged revisions do become policy (to which I am strongly opposed), what happens when the vandals figure out that they can still vandalise pages by creating huge backlogs? E.G: Possibly submitting up to 100 revisions with nonsense like "Mr. Example is a load of poo" and/or "I have hairly legs, hehe" in them. Huggle can quickly revert normal vandalism, will it be able to quickly dismiss silly revisions that vandals submit? - Sorry if this has already been covered or if i've missed the point of flagged revisions completely! But this possibility is bothering me. John Sloan (view / chat) 17:23, 9 January 2009 (UTC)

It's no different than now is it? People still have to revert such nonsense now, and people can still be blocked just the same for vandalistic edits even under FR system. ♫ Melodia Chaconne ♫ (talk) 18:13, 9 January 2009 (UTC)

Doesn't seem pertinent to the poll in question. Sounds more like something to consider as part of a trial - else we'll never know. Fritzpoll (talk) 18:19, 9 January 2009 (UTC)

In fact it would be nice to be able to flag a revision "bad", which would eliminate the need to revert, and make the whole process quicker and lighter-weight than now. The idea would be that if you click "edit" by default you get the most recent non-bad revision. You could still start from a bad revision via the history list, just as yout can start from an old revision now. The ability to flag (or unflag) "bad" would be part of the same package as the ability to flag (effectively "good") in the present implementation. This would also reduce history overload on pages which currently go vandal - rvv - vandal - rvv etc, making it easier to follow the useful history of the page. (Off topic, I know, but people are reading this page...) PaddyLeahy (talk) 18:42, 9 January 2009 (UTC)

I think doing that WOULD give credence to all the oppose votes who think this goes against the "anyone can edit" edict. As it stands on WP now, you click edit, you edit the most recent version of the page, whether or not there's been a change. This is something that FR should not change one bit -- which is why all those oppose votes don't hold much candle IMO. ♫ Melodia Chaconne ♫ (talk) 20:25, 9 January 2009 (UTC)

Flagging an edit a bad is not a good idea, in that it will still need to be reverted from the draft eventually. The biggest problem we have today with vandalism, comes when there are multiple new edits and the newest ones are valid edits. It is too easy to assume that the vandalism was removed at the same time as the good edit was added. Dbiel ^(Talk) 20:55, 9 January 2009 (UTC)

The point of my suggestion is that with this change we don't have to revert, ever. You only need to edit the text if you have something constructive to add. Seems like a benefit to me, but each to his own! I also don't see why being flagged "bad" would be any more traumatic to new editors than having their edit reverted (with a dismissive edit summary), which is what usually happens now. PaddyLeahy (talk) 19:56, 10 January 2009 (UTC)

toothpick or blanket

All the discussion ahs been around using flagged revisions as a blanket approach, in the section above Wikipedia_talk:Flagged_revisions/Trial#statistics_please in there the discussion said that only around 3-7% of edits would be within the target of this proposal. That means we are talking about applying it to 93-97% edits where its unnecessary, this makes a blanket approach very hard to justify, I think long term even if implemented many editors will become lazy and just review all edits as a matter of course.

So how do we use this as a tool like a toothpick, against the 3-7% of edits? What if flagged revision was available as an admin tool like semi-protection and full protection are. Could it be made into a user specific condition for arbcom/ANI remedies where an editor could be restricted to having their edits reviewed ie an enforced mentoring. Gnangarra 03:18, 10 January 2009 (UTC)

The main point of FlaggedRevs is to apply a minimal level of checking before our passive readers see the page, but in your model there's lots of visible disruption before any sanctions are taken, which defeats the point (why not just ban these users, as now?). I don't see a positive flag as "unnecessary": this check will significantly improve our reputation if we make it clear to the public what is going on. And flagging is mostly light work: edits by experienced users and bots would be automatically sighted, so reviewers only have to take positive action for edits by non-reviewers (IPs and newly-registered users). And of course we want to shut out a larger fraction of these than 3-7%. For instance from HappyMelon's statistics, 25770/238100 = 11% of IP edits were reverted manually, and then there would have been lots of bot reversions which he didn't count. And that was a low-vandalism period. PaddyLeahy (talk) 20:33, 10 January 2009 (UTC)