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
• Wikipedia:Protecting BLP articles feeler survey contains a survey of FlaggedRevisions on BLP articles

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)

Related discussion continued below. Thanks, Mailer Diablo 19:41, 13 January 2009 (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)

I think it should be: Please note that flagged revision in this form do violate the anyone can edit principle as all edits remain invisible to visitors of the site until Sighted, you have to logout to see it because of the SUL [1]. Mion (talk) 01:59, 11 January 2009 (UTC), (Note, the edit is now Sighted)

Well your claim regarding the German is simply not true, but seems there is a great deal of confusion and maybe your impression is due to a lack of German language skills. So again All edits remain immediately visible in the German Wikipedia (sighted or not), but if a sighted version exists then the latest sighted version will be the default display - however the reader can always choose to see the latest version, by clicking at the according info at the top right of the article (click on "zur aktuellen Version"). The sighted status only decides about the default display but the reader is also informed how to access the latest version, meaning the sighted status does not block readers from accessing the latest (unsighted) edits.--Kmhkmh (talk) 03:57, 14 January 2009 (UTC)

Following the statistics 9 out of 10 articles have a first sighting, at the moment 93 %[2] of the articles are not showing the latest version, and only 1 in every 100 visitors is looking for the edit button, so 1 in every .... will look for this show me the latest version button? Mion (talk) 04:09, 14 January 2009 (UTC)

Actually I'm not sure how you got this from the page. The information i get there is that 93% are showing the latest version (literally reviewed in their newest version). The other info that only 1 in 100 will use the latest version/zur akktuellen Version button i cannot find at all right now. However to state that again - all readers can access the latest version - if they choose not to, then that's their choice (and possibly an indicator that they actually do prefer the sighted version to the latest one, which actually makes an argument for flagged revisions). However the current wording for the suggested implementation of the english version of flagged revisions differs from the German one in exactly that crucial issue (the accessibility for all readers) and I'm not sure whether that's intended or an oversight/mistake - i've asked melon for clarification on that--Kmhkmh (talk) 04:52, 14 January 2009 (UTC)

Let me rephrase it correctly:at the moment 93 %[3] of the articles are not showing the latest version but the older sighted version.Mion (talk) 05:20, 14 January 2009 (UTC)

Are you sure you are reading the link correctly? The way I read it is that "11935 modules have an out-of-date review" and "806474 modules are reviewed in their newest version" - "That is 93.17 percent" that ARE showing the newest version. Dbiel ^(Talk) 05:49, 14 January 2009 (UTC)

No, i'm not sure, the current numbers are not representive at all anyway.Mion (talk) 06:20, 14 January 2009 (UTC)

And after 1 year of trials and 8 months of live implementation there is still no statistical evidence from the German Wikipedia on any improvement....., maybe if you could provide the statistics ? Mion (talk) 02:16, 11 January 2009 (UTC)

A statistic to prove what exactly?--Kmhkmh (talk) 03:57, 14 January 2009 (UTC)

As I have outlined some hundred miles below, there is no way to measure success in this field. You can measure the lag of flagging and all that stuff but there is no way to measure success of the whole thing. --X-Weinzar (talk) 12:35, 14 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)

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 [4] 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)

Sighting versus reviewing

I'd like to see a clear distinction maintained between sighting and reviewing. Sighting is about verifying that an article (or a diff) contains no obvious vandalism or other gross forms of badness. Reviewing should be more than that; for example, reviewing could include fact checking, assessment of readability, assessment of completeness. The proposal currently under discussion deals entirely with the process of sighting, not with reviewing, except that it uses the term "reviewer" for the name of a user group. When (if) this proposal is implemented, please rename the user group to "sighter", not "reviewer". Documentation and system messages will also need to be checked for confusion between sighting and reviewing. —AlanBarrett (talk) 13:05, 15 January 2009 (UTC)

Sighter is an ugly military term, really we shouldn't use it. The proposed implementation is used for trials only, we won't have additional usergroups except surveyor, so reviewer won't be confused. Other possibilities of name may include patroller, but we'll see later what kind of groups we'll need in future implementations. It's also quite certain that fast-checking, assessment of completeness or readability affecting editability so much will never be accepted on Wikipedia. Cenarium (Talk) 19:26, 15 January 2009 (UTC)

IMO, sighter sounds much more "civilian" than patroller. However, this is just my opinion. Admiral Norton ^(talk) 19:07, 16 January 2009 (UTC)

Any suggestion is welcome. Cenarium (Talk) 21:56, 16 January 2009 (UTC)

Here's one suggestion. I too dislike sighter/sighting. Would checker/checking perhaps be better? (I mean that in the sense of quickly checking, rather than fact-checking as part of a review.) --Tryptofish (talk) 17:20, 19 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)

Apparently there is but only Admins can see it (probably to prevent vandals from picking easy targets). I'd sign up for a service where I got some articles assigned to me to watch :) Lot 49a^talk 22:56, 10 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)

Lots of nice material -- at the time, then, 7% of edits were reverted and made by IPs. About 3% were reverted and made by registered users. Total IP edits have fallen, and the percentage of them which are reverted has fallen, though not as greatly as the drop in reversions of edits by registered users. Thus, vandalism is apparently reduced, especially from its peak, but there is still a substantial problem left. The issue boils down to -- is flagging the optimal way to proceed? Collect (talk) 23:12, 10 January 2009 (UTC)

But these stats obviously don't include all the vandlaism that would be occurring if lots of pages were not semi-protected? Or am I missing something. They only show the current reversion rate for edits to non protected articles, which misses all the attempted vandalism of the most popular but consequently protected targets. Mfield (talk) 23:22, 10 January 2009 (UTC)

As per Gnangarra, I would also expect some solid statistics laid down before such noise were made. That is, nobody is here exactly knows the extent of the problem (vandalism) but we're still voting for a trial (aiming to solve that problem) to be implemented or not. How would the results of this trial be interpreted then, be compared against what? It seems to me that some users would like to have some fun time with this trial even not knowing what's going on. I suspect german and russian wikis have had any real improvement after the implementation of that flag thing.Logos5557 (talk) 00:09, 11 January 2009 (UTC)

The German Wikipedia couldn't find any statistical improvements after 8 months of flagging, so discussion is ongoing to increase the requirements for Sighting de:Wikipedia_Diskussion:Gesichtete_Versionen#Ergebnis_Teil_1_-_Kriterien_f.C3.BCr_die_Sichtung_.28Vorschlag.29, which will increase the current backlog further. Mion (talk) 00:25, 11 January 2009 (UTC)

Mion, could you point us to any statistics on WP:DE regarding improvements?--Jo (talk) 09:21, 15 January 2009 (UTC)

Yes I can point to statistics at Wikipedia:Flagged_revisions#Statistics, and de:Wikipedia_Diskussion:Gesichtete_Versionen#ParaDox.27s_Tabellen_und_Diagramme, (with thanks to all who are working hard to provide them). More stats are expected. Mion (talk) 10:04, 15 January 2009 (UTC)

Statistics

Available statistics are at:

• http://stats.wikimedia.org/DE/ (updated September 2008)
• User:Hut 8.5/German editing stats (2009)
• User:Hut 8.5/DEWP reviewer stats (5 may 2008- 12 dec 2008)
• http://s23.org/wikistats/wikipedias_html.php (2009)
• http://vs.aka-online.de/cgi-bin/rchiststat.pl?dur=86400&lim=30&wp=DE&hl=&fl= (live)
• http://toolserver.org/~aka/cgi-bin/reviewcnt.cgi?lang=english&action=images&project=dewiki (live)
• http://toolserver.org/~aka/cgi-bin/reviewcnt.cgi?lang=english&action=outofdatereviews&project=dewiki (live)
• http://toolserver.org/~aka/cgi-bin/reviewcnt.cgi?lang=english&action=overview&project=dewiki (live)
• de:Spezial:Statistik (live)

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,880,773 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)

I would just like to say, YES, this is the ONLY flaggedrevs proposal I support, I switched my vote after hearing about this, as it actually HELPS the wiki atmosphere by opening semiprotected pages for anon and new user editing. I am very interested in watching this go forward.--Res2216firestar 18:39, 11 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)

Two things:

1. You are legally responsible for your edits, and sighters will be legally responsible for their sights. You are legally responsible for everything you do, there's no reason to expect an exception here.
2. In many countries, editors in fact get sued and fined if a journalist publishes a libel in their newspapers. Where I live, the legal term for "editor-in-chief" translates as "responsible editor". Zocky | picture popups 05:09, 12 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)

Even after this sensible explanation, I can still not find the procedure in the proposal. The procedure for anon's, regular named users and reviewers should be crystal clear. Why don't you add them very prominently to the proposal. I now gather the following:

• in a primary article view:

• anonymous users will see the latest sighted version
• logged-in users will see the latest edited version
• all users can switch between the edited and sighted version

• in an edit session:

• anyone will start from the latest edited version and be shown a "dif" with the latest "sighted" version

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)

I know. I already apologized while writing this. It was mostly targeted at comments like two threads above me (#Test page? and numerous comments whose authors didn't seem to be aware of the fact that Wikipedia comes in other languages too and that there are projects who have introduced the FlaggedRevisions already. You don't need to speak German or Polish or whatever for this. For example if you wonder about what the layout FlaggedRevs in effect will be as was the question in the above mentioned thread just go to those Wikipedias, not to the en.labs-wiki. --X-Weinzar (talk) 13:53, 14 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.

I occasionally edit in German WP, but as I have less than 200 edits there, they have to get sighted by another user. After initial skepticism, I found that this considerably adds to satisfaction, at least for me: My edit is still immediately visible - just perhaps one click away - but after a while, my edit gets sighted, which means at least one other user has actually noticed and read my change. Now isn't that great? :-) I cannot judge to what extend the system really helps the RC patrollers, but I think it certainly does no harm. -- Momotaro (talk) 21:15, 21 January 2009 (UTC)

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)

To my opinion (based on the experience in German WP), it's quite important to implement some tests to evaluate major expectations on impact of FR. Furthermore, it might help to reduce a lot of discussions on interpreting influences of FR. --Septembermorgen (talk) 12:50, 21 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)

Close it out it out at the end of January. Not everyone edits every day or even every week, and while I've been editing every day for the last week I only noticed the message about this on my watchlist a few hours ago (just didn't see it before that, others might see it and might not have time to click on it, or might click on it and not have enough time to read and understand what in the hell is going on here). There is absolutely no reason to close this early. Let people comment, ask questions, and discuss. The more people are aware of/invested in this process the better. If there's a way to let regular or semi-regular IP contributors know about this, then we should absolutely do so. --Bigtimepeace | talk | contribs 22:01, 12 January 2009 (UTC)

I for one would have missed voting in the poll had it been closed after a week or so. Even after two months off from editing, the only thing I've checked for updates is my recent contributions list - as you can only sit still for so long in a southern clime. I think for most of the Australian editors, the watchlist is simply too big to manage right now, and a month's grace period should mean that everyone sees this page. Ottre 03:41, 14 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)

No, we still would have to revert, because the vandalism would still be present in the draft revision. Remember, when you edit the article, you always edit the most recent revision, regardless of whether it's been flagged. This situation would be no different than it is now; just revert the vandalism. Pyrospirit (talk · contribs) 23:38, 10 January 2009 (UTC)

Flagging bad means the "current draft" becomes the previous non-bad version. Functionally, my proposal is equivalent to a revert except that it doesn't create a new entry in the history list. For frequently-vandalised pages this would cut the history list almost in half and make the actual development of the page much easier to follow. PaddyLeahy (talk) 11:59, 11 January 2009 (UTC)

Your proposal, would, in that case mean the deletion of all the edits since the bad one. A terribly bad idea, and one which would discourage people from editing completely - why edit if its going to be deleted because of something an IP slipped in before you. It would also be liable to abuse.Nigel Ish (talk) 18:29, 11 January 2009 (UTC)

Good point, the rule should be "latest non-bad" version; I was assuming that only the latest draft is likely to be flagged. PaddyLeahy (talk) 18:50, 11 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)

There is a toothpick proposal at WP:Flagged protection. Testing for that purpose, and with safebuards, would be acceptable to me; if we could avoid giving the impression that it was the camel's nose in the tent, it might be acceptable to a substantial supermajority. But the proposal is still, sensibly, under development. Septentrionalis PMAnderson 01:18, 11 January 2009 (UTC)

I actually support the use of flagged revisions as a blanket measure on all articles, as long as there's a technical provision to sight pages that haven't been edited in a certain time (e.g. 24 hours, but I could see this go as low as just an hour or two, it would still do good). I believe "anyone can edit with minimal effort" is what matters, not instant gratification; it's natural and acceptable for there to be some predictable amount of delay, no different from posting to a moderated mailing list. Dcoetzee 02:29, 11 January 2009 (UTC)

Wikipedia's greatest obstacle

The underlying assumption of flagged revisions is that we are frustrated in achieving the goals we have set for our encyclopedia primarily by editors who make contributions "the rest of us" think are unhelpful (see e.g. {{uw-test1}}). With flagged revisions, we could prevent those contributions from becoming immediately visible, and it is asserted this will improved the "appearance" of our encyclopedia.

The flaw in this thinking is that having an encyclopedia that sometimes includes "test" edits or vandalism isn't our greatest obstacle. Our goal is nothing less than to build a completely comprehensive encyclopedia of all human knowledge. Our greatest obstacle is that we don't have enough contributors to do that. Anything that discourages new editors will make it more difficult for us to achieve our goal.

Flagged revisions would discourage new editors; flagged revisions would make our greatest obstacle even more difficult to overcome. (sdsds - talk) 08:10, 11 January 2009 (UTC)

I can agree with the spirit of this post. The problem I have with 'flagged revisions' is the implied snobbery of some editors thinking it is acceptable for them to grant others the right to edit an article. But in my years here, I have found the existing fight against vandalism or dodgy edits to be good enough (just), a situation which I cannot see improving if there is a backlog of revisions in the inbox of a select bunch of "respected" editors.

I must also wonder if, by accepting this proposal, we are not putting a fireblanket over the ability of editors to create such articles as the 2008 Mumbai attacks, or current Gaza/Israel conflict article. How could we ensure that an editors own POV leanings don't come into the choosing which version of an article to allow? doktorb _words^deeds 08:47, 11 January 2009 (UTC)

This (section, not fr's) is one of the more interesting posts in the last several years. Where is the page that discusses Wikipedia goals, shows metrics, with todo lists? I see truly interesting pages deleted for lack of notability. This does not seem to be striving for complete information. I personally have had page creations marked for deleted within seconds (even before I could get to the talk page to add project banners...) By the same token, I do believe that vandalism and inaccurate articles are the bane of our existence. Something HAS to be done about those issues. ANY motion in that direction, I see as a good thing. But I wish the "goals" page existed. -- Mjquin_id (talk) 01:56, 19 January 2009 (UTC)

Canvassing?

I'm not sure what to make of this, which User:Promethean has advertised on a very large number of users' talk pages (eg). The message, "say no to Flagged revisions" with a link to the #Oppose section above, was MfD'd as canvassing, but was snowball-kept after Promethean changed the link to not point specifically to the 'oppose' section. It is rather disconcerting, therefore, to see an edit where Promethean changed the link back just under an hour later, eight minutes after the MfD was closed. Promethean also seems to have substituted a number of these templates, such that the WhatLinksHere no longer accurately reflects the number of transclusions in existence. All of the substituted templates link to the 'oppose' section.

The MfD was open for less than ninety minutes, although I do not disagree with SoWhy's WP:SNOW closure given the content of the discussion. I am more concerned that the discussion was not linked to here and the fact that this template is in use (and links, as of this post, to the 'oppose' section of the straw poll) was not remarked upon. I am interested in obtaining wider comment on the situation. Thoughts? Happy‑melon 12:13, 11 January 2009 (UTC)

Short comment on that: I closed the MfD because its scope was only if the template itself can be seen as canvassing, which I think everyone at the MfD agreed can't be more canvassing than most userboxes. The way it was promoted to talk pages though could be regarded as such (although I doubt it) but we cannot MfD behavior, only pages. SoWhy 10:00, 19 January 2009 (UTC)

Always thought that the anti-canvassing rule on wikipedia was silly and never more so for a major issue like this. I'd be very happy to display a pro-flagging equivalent! PaddyLeahy (talk) 12:21, 11 January 2009 (UTC)

I hate the anti-cancassing rule. But User:Promethean should be blocked for inordinate bad faith manipulation of this whole thing (see the point above about the incorrect issue of 21 days). In my opinion. But that's just me. ♫ Melodia Chaconne ♫ (talk)

I'd already voted oppose and was offered the gawdy userbox to use if I wished. It wasn't added, just offered. I chose to not use it and not respond. If it was only offered to people who'd already !voted no, then it's certainly not canvassing. Spamming, maybe, but not canvassing. - Hordaland (talk) 13:14, 11 January 2009 (UTC)

It wasn't canvassing in my opinion because he only showed the link to those that had already made up their mind. And displaying the template with a link to #Oppose is no worse than displaying a notice about an RfA or similar discussion. Its in my opinion a really trivial thing that shouldn't really have any affect on the outcome Alexfusco⁵ 17:56, 11 January 2009 (UTC)

I got the note and displayed the box until I switched to support, I agree with Alex, this is trivial and should not have much of an effect.--Res2216firestar 18:28, 11 January 2009 (UTC)

Just noting that as the creator of the image I strongly disagree with the mass messaging, but I don't consider it 'canvassing'. — neuro^(talk) 23:08, 11 January 2009 (UTC)

This is not canvassing but certainly aggressive campaigning with the objective to sway consensus in a community discussion. The template also adds to the incomprehension on the subject of this poll, which is not whether we want to massively enable flaggedrevs on all articles, but whether we can enable the proposed configuration in order to make trials that have to be supported by consensus. Those factors will have to be taken into consideration when closing the poll. Cenarium (Talk) 01:04, 12 January 2009 (UTC)

No more so than the repetitious reverence for Jimbo. Anyone who closes a poll of just over 60% approval on a change of this magnitude as anything other than no consensus may expect to explain themselves to ArbCom. Septentrionalis PMAnderson 18:11, 12 January 2009 (UTC)

As I said somewhere above, Wikipedia:Requests for arbitration/Brion VIBBER is perhaps the most amusing idea I've seen all week. Happy‑melon 18:36, 12 January 2009 (UTC)

Yes, four weeks ago on Wikipedia_talk:Flagged_revisions/Trial#RfC_on_implementation you said "A clear consensus is required to present to the developers to have the extension installed". I thought Brion VIBBER is a lead developer ? so whats amusing ? Mion (talk) 19:08, 12 January 2009 (UTC)

The fact that Pmanderson proposes to take the Wikimedia Foundation's Chief Technical Officer to the en.wiki Arbitration Committee for alleged breaches of policy. A clear consensus is indeed required, but to suggest that we have any control over how that consensus is judged is what's amusing. The best we can do is present coherent arguments, and to get widespread involvement. I'm not sure if this is the highest turnout we've had in Wikipedia's history, but it's certainly coming close; that's the definition of "strong consensus": something that reflects the opinions of the widest possible array of Wikipedia editors. What this poll is judged a consensus for is entirely out of our hands. Happy‑melon 19:56, 12 January 2009 (UTC)

So a high turnout = "strong consensus"? Not at all. Wikipedia is not a democracy, and a majority vote is not enough. Septentrionalis PMAnderson 22:18, 12 January 2009 (UTC)

This isn't canvassing; canvassing is an attempt to sway a large number of user's opinions in a community decision. Promethean sent the message to people who had already opposed. –Juliancolton ^{Tropical Cyclone} 18:25, 12 January 2009 (UTC)

Where are the reverences ? Which percentage of users even knows about Jimbo's position ? Jimbo's statements are rather turned in reasons to oppose. What will have to be taken into consideration is that most comments are for or against an unrestricted implementation on all articles like on de.wiki, which is ... off-topic. The majority of comments are not to the point. Cenarium (Talk) 19:16, 12 January 2009 (UTC)

Anybody who glances at the first nine supports; and plainly some have done so. And what percentage of editors have been swayed by Promethean? As his edits say, he wrote those who had opposed. Septentrionalis PMAnderson 19:46, 12 January 2009 (UTC)

Users noticing the template on a userpage, especially from users they know, are driven-by. Even if it's not clearly forbidden by policy, it's a deliberate attempt to sway consensus by inciting users to vote 'no'. More have seen them than Jimbo's !vote, but overall none have a major influence. Cenarium (Talk) 22:56, 12 January 2009 (UTC)

• The point is whatever we decide it is. For those who wish to say this need not be tested because they oppose FR whatever the results (I am not one, yet; although Cenarium may persuade me), that's the point. Septentrionalis PMAnderson 19:52, 12 January 2009 (UTC)

(ec) AGF? If indeed the "majority of comments are not to the point," then the point has been poorly presented. However, it seems to me that some proponents dismiss valid concerns, such as mine. This discussion has already taken hundreds of man-hours. The parameters & evaluations of each trial are to be decided by consensus = hundreds more man-hours. With that much invested, it is human nature to want not to backtrack. Such concerns are not off-topic. - Hordaland (talk) 20:01, 12 January 2009 (UTC)

Please reread what I said, i.e that most comments both in the support and oppose sections are (increasingly as the poll run) directed at whether we should massively enable flaggedrevs or not, which is not was is asked here, but whether we can enable a passive configuration in order to make specific trials, each one requiring consensus. I wouldn't be opposed to use an editnotice to clarify this in a neutral manner (as has been done for the mosnum RFCs). If your concern is that changes won't be visible immediately (and thus decrease participation), then I agree that it is also a concern, and it is one of the reasons I am opposed to a full, unrestricted implementation. But the trials are not of this kind. Trials are limited and require consensus. More long-term proposals range from using a light version of flaggedrevs instead of semi-protection, or a semi-automatic implementation where only edits identified as probable vandalism are not shown. I do not believe that those trials will open the door to a full, unrestricted implementation, the community is too strongly opposed to this, but is is indeed a concern to a few users. Cenarium (Talk) 22:56, 12 January 2009 (UTC)

Example where Flagged revisons would have helped

This is an example of a good faith IP user unknowingly hurting an Wikipedia article. He views the article and sees some very obvious vandalism and edits the article to remove it. (see diff1) The problem with the removal of the vandalism is that it should have been removed using the undo function which would have also added back the valid section of text deleted by the previous IP user who added the vandalism in a single edit. (see diff2) Had flagged revisions been in place, the good faith editor would have never seen the vandalism in the first place. The partial reverting of vandalism is the single biggest problem in Wikipedia in our fight with vandalism. It is also the main reason that most long term vandalism is permitted to remain in Wikipedia. Dbiel ^(Talk) 20:13, 11 January 2009 (UTC)

This is a recurring problem indeed, but it also happens with registered users. It is something that could be partially handled by the semi-automatic flaggedrevs proposal: we could use a special page listing articles with suspect revisions (see this for details, though this is hardly readable), it would detect many such cases. Cenarium (Talk) 20:42, 11 January 2009 (UTC)

No need for Flagged revisions there, the existing tools are Cluebot ,SoxBot III etc they are already able to counter such vandalism. Mion (talk) 20:55, 11 January 2009 (UTC)

If they were able to catch all vandalism, libel, etc, that would be nice indeed. But this is not the case. Cenarium (Talk) 21:02, 11 January 2009 (UTC)

An example was given, the bots are able to handle the given example, and now you're raising the requirements ? Mion (talk) 21:05, 11 January 2009 (UTC)

The bots haven't reverted it, they revert only a small part of all vandalism edits, even when such edits match their filters. And this is a blanket revert, while a combination of the abusefilter and flaggedrevs would defer all suspect edits to the analyse of a trusted user. Cenarium (Talk) 21:17, 11 January 2009 (UTC)

It requires only a small amount of people to run bots like this to handle big ranges of articles compared to the sighter scenario which creates a huge backlog, to answer your other question, the German wikipedia is discussing changes in the criteria for analysis by sighters because the current system isn't working (not all vandalism, libel, etc are caught), by making the criteria stricter, it takes more time, which will increase the backlog. Mion (talk) 21:30, 11 January 2009 (UTC)

The difference here is that in the proposed semi-automatic implementation, only edits that match the filter are 'delayed' to the draft page, and other edits are unaffected, and since most vandalism edits are quickly reverted, the backlog won't grow as big as it would in a total, unrestricted implementation like on de.wiki (that I would oppose very much), since when a new edit makes the latest revision no longer 'suspect', it is shown to IPs. Cenarium (Talk) 21:50, 11 January 2009 (UTC)

the proposed semi-automatic implementation: only edits that match the filter are 'delayed' As other (obvious) vandalism is caught by the bot and directly reverted, 97 % of the edits by IP's is ok, so 2,5 of the edits are questionable, now the German wikipedia needs human eyes to filter this vandalism and libel (see the discussion to raise the criteria), the question comes up: can you show me a ruleset (the filter in the proposal) for a bot, for lets say 100 articles, that allows the passing of the 97% good edits+catching the 2,5% of edits that contain libel and smart in dept vandalism ? Mion (talk) 22:36, 11 January 2009 (UTC)

Your assumption that almost all obvious vandalism is reverted by a bot is incorrect, even if we count quick Huggle reverts or quick manual reverts (less than one or two minutes after the edit), still a considerable part of obviously vandalized versions remain visible for a few minutes or hours, if not more. The semi-automatic proposal would prevent this, and provide a special page listing articles containing suspect revisions, thus detecting incomplete reversions. As you know it, a perfect filter doesn't exist, but we would have much more liberty than in anti-vandalism bots' filters. They could be specialized for certain types of articles, for example articles on living persons, or articles targeted by a sockpuppeteer, or against a specific type of vandalism that can't handle bots without too many false positives. Cenarium (Talk) 00:46, 12 January 2009 (UTC)

This is also the sort of situation where FR are most risky. The anon made an obviously useful edit; there is a risk that any flagger will not check further, but will flag the repaired text; at which point the text lost to the vandal may well be permanently lost, unless someone goes behind the flagging. Septentrionalis PMAnderson 01:14, 12 January 2009 (UTC)

When flagging, the diff to the latest flagged revision is given, so any user with a little understanding of revision history can make the appropriate actions. There are many more cases where text will be saved thanks to flagged revisions than lost because of bad flagging. Cenarium (Talk) 01:57, 12 January 2009 (UTC)

That's precisely the problem. Diff1 by itself is an excellent edit, and any flagger should be tempted to confirm it. Septentrionalis PMAnderson 02:45, 12 January 2009 (UTC)

No, the latest flagged revision would be presumably this one, so the diff to the latest flagged revision would be this, which clearly indicates a lost of information. Anyway, history should always be checked before flagging, but this diff is a signal. Cenarium (Talk) 19:28, 12 January 2009 (UTC)

Except with FR, it wouldn't have happened that way in the first place, so it's something of a strawman to put it that way. ♫ Melodia Chaconne ♫ (talk) 03:09, 12 January 2009 (UTC)

@Cenarium:my assumption is correct, because in the proposal a small set of articles is targeted, you need a bot for this set, so if you take a SoxBot III as a tool to build the filter upon it will revert the obvious vandalism on this set, however in this proposal there is still the problem that you can't create a valid ruleset for the proposed FILTER and thats why this specific trial proposal can't work. Mion (talk) 10:32, 12 January 2009 (UTC)

We have no need for bots, the abuse filter automatically checks all edits and acts based on its own filters. When an edit matches some filter with an action 'deflag', it's 'moved' to the draft page until a no longer suspect revision exists (in particular, when reverted). Cenarium (Talk) 19:28, 12 January 2009 (UTC)

ok, so instead of Soxbot III the abuse filter to handle obvious vandalism, still the additional filter set for the 97% good edits+catching the 2,5% of edits that contain libel and smart in dept vandalism is missing. Mion (talk) 23:36, 12 January 2009 (UTC)

We can't catch everything, but anti-vandalism bots can continue to work as normal (they will never catch and revert every obvious vandalism, but a considerable part, the abuse filter will catch and defer even more). There is more support to enable flaggedrevs on blps, a semi-automatic implementation could help here too: instead of deferring suspect edits, it would allow edits identified as non-controversial (like interwikis, additions of links to an existent page, etc). There I think the proposed expiration system (old enough revisions are visible to IPs, e.g. 48 hours) would help too, as backlogs would still be important. The abuse filter could also be used to report specific edits to blps, like 'death announcements' to a special page (with the option to defer if supported by consensus). Cenarium (Talk) 00:46, 13 January 2009 (UTC)

There is NO support to enable flaggedrevs on blps, as that is no vote but to bring up arguments, and yes the abuse filter can do everything cluebot can, the rest of the arguments is assumption as there are no possitive statistics from the DE wiki, in fact, it doesn't matter if you handle users as second class citizen with a waiting time of 48H, 6 days or 21 days, remember they are volunteers Mion (talk) 01:39, 13 January 2009 (UTC)

From the discussion, there is more support to enable flaggedrevs on a blp that there is on another article. The all or nothing argument is getting weary here, we can enable flaggedrevs on certain articles and/or restrict it to a subset of edits. In any case, and especially in the perspective flaggedrevs is, restricted or not, enabled on a vast class of articles, the additional benefit of a semi-automatic (virtual) flagging will be to avoid deferring most non-controversial edits. It can do better than ClueBot, since it is more adaptable and reactive, and would be especially useful against persistent sockpuppeters, often causing undesirable semi or full protections. If you do not believe that this or an expiration system would be a benefit on the basic implementation like on de.wiki, then fine, but you can't reproach me of trying to find ways to improve the system. As I said, I'm opposed to massive unrestricted implementations, but I still believe that an article with a reasonable flagged revision system is better than a semi-protected one. And I don't see disadvantages to a semi-automatic implementation if the filters are well designed. Also, using flagged revisions (flagging sysop-restricted) in a dispute instead of full-protection may work well. Cenarium (Talk) 03:19, 13 January 2009 (UTC)

There is your IF, show me the FILTERS well designed Mion (talk) 03:25, 13 January 2009 (UTC)

I am not familiar with the abuse filter's filters, so I can't code specific filters. I assume we could initially adapt the filters from the anti-vandalism bots, since they are clear-cut cases, then propose new filters for community approval, then implement them if there is consensus. If a filter causes too much trouble (read too many false-positives), then revise it and remove if it can't be fixed. I can only extrapolate, since there is no wiki where both extensions exist as far as I know. Cenarium (Talk) 03:46, 13 January 2009 (UTC)

Thinking of it, as Flagged Revs is enabled on the de.wiki, why don't you do the proposed trials on the de.wiki, looking at the current state, it can only go up with other approaches ? Mion (talk) 02:12, 13 January 2009 (UTC)

Abuse filter:"Please keep in mind that this extension's aim is not to catch simple vandalism, as some bots already do. This extension will help preventing harm from some known persistent vandals (hagger), with very specific modi operandi. It won't catch childish vandalism or page blanking" Mion (talk) 13:59, 21 January 2009 (UTC)

Requests for Surveyorship?

Continued from New userrights group discussion

Looking by the previous discussion on the usergroup 'surveyor'. So how are we going to choose surveyors? RfA-style? Crats no longer play mere technical roles, but social roles too in determining consensus. We already have enough politics in choosing administrators, we do not need to bring it to a whole new level - where editors start asking how should the usergroups get hierarchically arranged! I support FlaggedRevs in principle, but certainly not implementation in this form... - Mailer Diablo 19:40, 13 January 2009 (UTC)

At least for the duration of the trials, we really shouldn't be adding and removing flagged revisions from articles arbitrarily. Only a few people need to have it just to set up the trials at the beginning. Dcoetzee 00:17, 14 January 2009 (UTC)

It's obvious isn't it? If this thing were to be implemented, then in reality any editor with a proper account and an arbitrary number of edits and time served should automatically be deemed trusted. Say 1,000 edits and active for a year? Something like that. Then they get to OK edits. The last thing we need is more politics, if it's automatic for experienced users then there is no politics. Personally I think anyone with say 10,000+ edits should automatically become an admin and I think arbcom members should be drawn randomly from the community, with say 100 serving at a time. But then I hate hierarchy of any kind, and Wikipedia is doing it's best to turn itself into an authoritarian system "ruled" by those with the best networking and political skills. Alun (talk) 08:50, 14 January 2009 (UTC)

You've confused surveyors with reviewers. Dcoetzee 09:00, 14 January 2009 (UTC)

So we have "sighters", "reviewers" and "surveyors". Any more utterly absurd types of elitist sinecures we should create for the budding "content police". Surely we need a better hierarchy than this. Maybe some more military sounding "ranks" perhaps? Alun (talk) 10:51, 14 January 2009 (UTC)

BTW I didn't use the words "surveyor" or "reviewer". But reading this, it looks to me as if one needs the "reviewer" right to "survey" pages and then mark them as "sighted". So these seem to be all the same thing. Can you clarify the difference between a surveyor and a reviewer for me? Alun (talk) 11:06, 14 January 2009 (UTC)

This "surveyor" doesn't sound like the version that was put on the table for this trial proposal. - Mailer Diablo 14:03, 14 January 2009 (UTC)

Sure. I didn't make up the names, but it is the reviewer who reviews and sights (or flags) revisions. The surveyor is a position that exists only for the duration of the trial; they have the ability to enable or disable flagged revisions on specific articles. The purpose of this is of course to allow us to conduct a structured small-scale experiment. Dcoetzee 18:40, 14 January 2009 (UTC)

Surveyor is already taken Wikipedia:Flagged_revisions/Quality_versions#Reviewer_rights, Reviewers are surveyors who can mark pages as "quality" in addition to "sighted". Or would you like to test Quality versions in the same run ? Mion (talk) 20:46, 14 January 2009 (UTC)

On the de.wiki you get the Sighter status as you're registered for 60 days, you're not blocked before AND you made 300 edits, as a Sighter with "review" rights you can only validate edits from others, if a page is Sighted and you make an edit, your edit is not going live before its approved by another Sighter.

Update The group Sighters has now review + autoreview rights. Mion (talk) 17:25, 14 January 2009 (UTC)

Now discussion is ongoing on the de.wiki because of r45636, autoreview is enabled on the system, with the following set: All users with a confirmed email address, 1 year on the project and more than 3000 edits become autoreviewers, in effect, this group is auto sighting its own edits, the edits go directly live if the last version was a sighted version, if there are edits from others to sight in the article all stay invisible until another Sighter validates, its similar to the Bot-flag on de.wiki. Mion (talk) 10:46, 14 January 2009 (UTC)

Err...we really should just have one group, whatever it's called. Aaron Schulz 18:01, 14 January 2009 (UTC)

I think it should be called "editors". Now there's revolutionary. Alun (talk) 19:19, 14 January 2009 (UTC)

I am very sceptial about FR, BUT, I always say (maybe as a [European] liberal, heh), that it is always best to have a role in a situation which purports to improve the lives of other people than stand on the sidelines shouting. So I would be interested in putting myself forward for this "editor/what have you" role. doktorb _words^deeds 19:29, 14 January 2009 (UTC)

1. Like this

   Surveyor Sighter admin

   1 Sighter (reviewer + Autoreviewer) 300 edits AND 60 days

   2 Admin (reviewer + Autoreviewer)

   3 Registered users 3000 edits AND 1 year (Autoreviewer)

   4 Registered untrusted users (auto confirmed) 10 edits AND 4 days (none)

   5 Registered untrusted new users (none)

   6 Unregistered untrusted users (IP) (none)

SSA would be more clear. Mion (talk) 21:13, 14 January 2009 (UTC)

On the Twelve day of the trial, my b'crat gave to me..... - Mailer Diablo 06:20, 15 January 2009 (UTC)

Don't you think that too much emphasis is put on the "edit count" of an editor. I happen to have a low edit count compared to other users who have been around for about the same amount of time I have. I am confused as to who would have what, because of my edit count would I be considered a "untrusted user" or because of my rollback rights or being here more then a year would I be a reviewer? -Marcusmax(speak) 21:30, 14 January 2009 (UTC)

60 days and 300 edits is enough for reviewer (Sighter), its unlikely that editors with less get rollback rights granted. Mion (talk) 21:39, 14 January 2009 (UTC)

Let's only discuss the trial here, as it confuses to bring up other implementations that we know won't happen on Wikipedia anytime soon.

1 Surveyor (can review and change page configuration) (informally granted for the needs of a trial is best option)

2 reviewer (can review) (any user with no recent vandalism or libel edits with minimal time and edits here)

3 User (can't review, see latest rev per default)

4 IP (can't review, see latest flagged rev per default)

Cenarium (Talk) 21:55, 14 January 2009 (UTC)

Hmm, I'm skeptical about how much sense it makes to show logged-in users the latest rev by default. After all, many logged-in users are only occasional editors and primarily readers. Dcoetzee 00:29, 16 January 2009 (UTC)

Users can configure their preferences to see the latest flagged rev. Cenarium (Talk) 14:29, 16 January 2009 (UTC)

I'm still kind of confused here, so maybe someone can explain it to me in basic terms. I'm not an administrator, I do not plan to be one, and I've a megaton of edits dating back to 2007. I often make a lot of edits a day. If Wikipedia becomes Flagged Revisionpedia - will I be able to make an edit and immediately view it? For a random example, if I go to the page Melissa and change "Full of wrath" to "full of wrath" (or, just to be daring, delete "or Full of wrath" alltogether), will that be visible immediately? All Hallow's Wraith (talk) 11:59, 18 January 2009 (UTC)

First off, there would be FAR more sighters than admins. Secondly, ANYONE can view the most recent version of a page, the main difference is what you see initially. If you're seeing the sighted version, you can click a link to switch to the draft, and vice versa. Also, any edit made by anyone will show the editor the draft version when done. ♫ Melodia Chaconne ♫ (talk) 12:41, 18 January 2009 (UTC)

On the German wiki there are 312 admins and -/+ 50 active sighters, User:Hut 8.5/DEWP reviewer stats/ Mion (talk) 12:50, 18 January 2009 (UTC)

Of course, you would have sighter/reviewer rights. Any user with minimal experience (1 month here/100 edits for example) will be granted reviewer rights, unless s/he recently vandalized or added libel. But why would Melissa have flaggedrevs on ? This is not a proposal to use it on all articles, and most users supportive of a trial would oppose it. Realistic long-term proposals are: using it on blps, on articles instead of semi-protection, etc. Proposed trials are described here. Cenarium (Talk) 13:21, 18 January 2009 (UTC)

A lot of people are confused. From my understanding, the original proposal I saw at Flagged revisions was only 'reviewer', which flags a revision as reviewed. This version of the proposal wants to have 'reviewer' and 'surveyor', with the latter deciding which article is to have flagrevs turned on and only given out by crats. If that is true, it isn't that hard to guess that people probably would have to go through one of the most politicized processes on Wikipedia to ask for it..... - Mailer Diablo 11:03, 19 January 2009 (UTC)

I agree that the terminology is confusing if you try to read the various proposals together. Rather, think of them as progressive evolutions on the same idea; the user groups that are available, and the permissions they have, have changed as the discussion has progressed. As such, it is both impossible and confusing to try to directly compare the groups from proposals that differ in time.

The 'surveyor' permission is intended to be a stricly temporary role, one that is retained only as long as is necessary. The best current analogy is the role of stewards on small wikis. If a small wiki without local oversighters needs an edit to be hidden, they can make a request on meta and a steward will give themselves oversight permissions on that wiki, hide the edit, and then remove the permissions immediately afterwards. In a similar manner, when we have a consensus to start a trial we will have a need for one or more surveyors. We probably use an informal RfA-style process to select a few users who we believe are trustworthy with the extra tools, and the bureaucrats will flag them. Once the trial is completed, the permission is no longer necessary and so the surveyors will either resign (they have the ability to remove their own surveyor status) or be deflagged by a bureaucrat. If we need more surveyors at a later date, we can reappoint previous users or nominate new ones, as desired. But 'surveyor' is not a permanent position. Happy‑melon 13:05, 19 January 2009 (UTC)

Here's my prediction - 'surveyor' becomes permanent (as the "trial" would be) because the community and the originators would not be able to find the momentum to shift the (by then) status quo when the trial is implemented. (hey, we don't even have a bright-line date when the trial ends?) We are running on a Wiki with the size of 2.7m articles, not 270 articles. Are you aware how difficult is it to remove any userright/position that is admin and above over here?

Like it or not, this is how it's gonna actually work. The 'surveyor' usergroup would then be seen as higher than admin but lower than B'crat. People would queue up for them at RfS, thinking as part of the Content Certifying Committee of the Surveyors Socialist Cabal Union of the WWWP they would be able to a exert subtle but more control over articles and an extra hat, adding on to the hierarchies of Wikipedia. Bad, bad, bad idea. - Mailer Diablo 13:28, 19 January 2009 (UTC)

While the analogy is entertaining, I don't believe your concern is justified. On this issue, the proposal is crystal clear: indeed the only imperative clause in the entire proposal is that "each trial must have a definite endpoint". Similarly, the proposal is quite clear that "For each trial, a bureaucrat will appoint several 'surveyor's... At the designated end of the trial, the surveyors will... remove themselves from the 'surveyor' group". There won't be a Requests for Surveyor process, in the same way that there is no RfO for Oversight or RfC for Checkuser - the positions are created only when they are needed. For a bureaucrat to create surveyors outside the scope of a trial would be a violation of the proposed policy, which we trust them not to make (that's why they're 'crats in the first place, because we trust them). User rights such as admin, 'crat, checkuser, oversight, etc, are difficult to remove on this wiki because they can only be unset by stewards, and the only group on en.wiki that has the authority to instruct the stewards to take action is the Arbitration Committee. The situation is totally different with 'surveyor', where they can not only resign (and would be expected to do so at the appropriate time) but can also be deflagged by the bureaucrats. Failing to resign their surveyor status at the end of a trial is an overt violation of the proposed policy, for which a suitable reaction would be... loss of surveyor status. And lo, we have twenty users capable of taking that action. So your doomsday situation can only occur with the co-operation of the entire bureaucrat community. Do you have any evidence to suggest that this is likely to occur? Happy‑melon 13:46, 19 January 2009 (UTC)

"Each trial"...Are you sure one trial can even be completed? A "trial" till this day -> Article creation restricted to logged-in editors on "experimental basis", post-Seigenthaler, Seigenthaler 1 year after

"We probably use an informal RfA-style process"..."There won't be a Requests for Surveyor process" Well, even "RfO" and "RfC" is up for reform and be handed out to more editors who will use them. -> CheckUser and Oversight appointments reform. Furthermore, some WMF projects do hand them out by RfO/RfC.

"So your doomsday situation can only occur with the co-operation of the entire bureaucrat community."
Y not? -> Carnildo's re-promotion, Ryulong's RFA passing at 69.4%!?

What makes you think that everyone is willing to follow policy down to the letter? - Mailer Diablo 14:40, 19 January 2009 (UTC)

So you are comparing a knee-jerk reaction 'experiment' that was announced and implemented unilaterally and without any consideration of a review process, with a proposal that has been evaluated by over six hundred editors and which excludes an explicit prescription that every trial must have an endpoint (a level of prescription that is rarely used in policy, even in core principles)?

You misunderstand the nature of the proposed checkuser/oversight appointment process, which is about as far from RfA as you can sensibly get, if you think it is intended to lead to a proliferation of the CU/OS rights. Checkusers and Oversights will be appointed through that process only when they are required; if anything, the proposed endorsement method enshrines that principle rather than eroding it. Surveyors will be appointed in the same way.

There's really little I can say on your apparent distrust of the bureaucrat community; the examples you offer are like comparing chalk and cheese. Both situations are controversial, but there's a whole world between making controversial decisions, and endorsing an overt policy violation and abuse of power. IAR is not a catch-all "ignore any policy you disagree with" (and remember that there are a number of bureaucrats ranked on both sides of this discussion) but "ignore policy in situations where you ernestly belive that you are following the spirit if not the idea". If you honestly believe that there is a genuine risk of our entire bureaucrat cadre misinterpreting three policy clauses so badly as to essentially invert their meaning, there's very little else I can say. Happy‑melon 15:10, 19 January 2009 (UTC)

Crucial difference between the (successful) German implementation and suggested English trial

There seems to be a small but important difference, which actually matters a great deal to much of the discussed criticism of flagged revisions. In short: While the suggested English implementation arguably severely interferes with the "all can edit"-principle the German implementation does not.

This is how the German implementation works: An article displays in the default mode with a button at the top right (zur aktuellen Version allowing all readers to switch between the default view and the latest edit, when they are not identical. From the perspective of the (anonymous) reader all that the sighted status does, is influencing the default display, but he can always access the latest nevertheless. The default is the determined the following way:

1. if there is a sighted edit, the default display is the latest sighted edit
2. if there is no sighted edit, than the default display is the latest edit.

Note that this means all edits by anyone continue to go live immediately (just not in the default display) and if new articles is created by an IP it is in the default display even.

Here is the suggested English implementation: When FlaggedRevisions are enabled on a particular page, logged-out and anonymous users will see the most recent sighted revision, and all edits to that page can be sighted by members of a second usergroup, 'reviewer'. By default, all logged-in users, reviewers or not, see the most recent version of such pages, although this can be customised in personal preferences.

Here is no mentioning of a button allowing all readers to see the latest edit (and hence ensuring all edits are live immediately).--Kmhkmh (talk) 11:29, 15 January 2009 (UTC)

The proposed implementation in the english wikipedia will also have the button you are talking about. It's true that the text you quoted does not mention "a button allowing all readers to see the latest edit", but that doesn't mean that the button won't be present, it just means that the proposal is not very easy to understand. The actual proposal is at Wikipedia:Flagged revisions/Trial, especially in the "Technical implementation" section of that page. The proposal is phrased in terms of the way certain software configuration options will be set, not in terms of the observable behaviour of the software when it is configured in the proposed way. You can try the Live demonstration on en.labs.wikimedia.org to get a better idea of how the software works. Reading some of the answers to questions asked by other people would also have shown you that "all can edit" and "all edits by anyone continue to go live immediately (just not in the default display)". —AlanBarrett (talk) 12:43, 15 January 2009 (UTC)

well thanks for the clarification, unfortunately this site is rather long, so i didn't read all comments on that matter. However just reading some of the comments seems to indicate that many people are/were not aware of it, so it might be a good idea to explicitly include that fact in the quoted suggestion, which btw was taking directly from "Technical implementation" section of that page. The problem is, that the actual configuration of that button is crucial, i.e. it is not "just" some minor configuration issue to be settled after the test, but it should be an integral part of testing itsself. Also for most readers/editors the behaviour, i.e. the behavioural description, is the only thing that matters. So it's not a good idea to leave out such information from a proposal on which readers/editors are expected to vote. --Kmhkmh (talk) 13:03, 15 January 2009 (UTC)

Oh, I agree, the proposal should have been better worded. —AlanBarrett (talk) 15:32, 15 January 2009 (UTC)

(This is tongue in cheek, don't shoot me!) - The easiest way to word the proposal is done in 5 words. "This idea has been abandoned!" :) Thor Malmjursson (talk) 19:11, 17 January 2009 (UTC)

If hundreds comment or vote here

How come the number of people playing around here measures in the tens? I'm just sayin'. David in DC (talk) 18:17, 15 January 2009 (UTC)

Good question. But most people propbably just read the implementation description (i hope at least) and considered that info sufficient, also you can look at the other WPs already using flagged revisions to see what it looks like. also personally i found it annoying that testing seem to require (yet another) account.--Kmhkmh (talk) 04:17, 16 January 2009 (UTC)

I subscribe to your last sentence, Kmhkmh. That was also my impression when I took a look. - Hordaland (talk) 10:10, 16 January 2009 (UTC)

Thanks for the link David. In this implementation one can sight their own edit, which I thought we are not going to be allowed to do here? BTW Kmhkmh I was a bit annoyed by having to create another account, but then saw the link to unified accounts, so I unified my accounts, it was a piece of cake Special:MergeAccount. I had no idea this was possible before, so that's a real result!! Apparently if you unify your accounts yu automatically get an account in en.labs. Alun (talk) 13:29, 16 January 2009 (UTC)

If you have a global account, you can log in in most Wikimedia wikis. In the proposed implementation, an edit by a reviewer is automatically flagged if the latest revision is flagged, and any user with no recent vandalism or libel can become reviewer on request. Cenarium (Talk) 14:36, 16 January 2009 (UTC)

I tried, it does not work at all. All I could see is that sorry title page; where's the content to be watched? NVO (talk) 06:00, 17 January 2009 (UTC)

This test page is rather worthless from my point of view as it does not fuction anywhere near what we are talking about here. We say that an IP user will not see an unreviewed page. Yet the test page displays the unreviewed page when not logged in. It does include a not that the current version is unreviewed, but the link looks like this [[Help:Page validation|current revision]] - The link should be to the current revision on to a help page. It provides no information on what an IP user will see. And when logged in (after having set your permisions as a reviewer) the only option is to site the article. The test page is just a total waste of time. 207.78.65.254 (talk) 04:57, 17 January 2009 (UTC)

Separate page for votes

I just moved the votes to a separate page because this one is becoming monstrous and most discussions are still too alive to archive. Apologies if this screwed something up, but I don't have the fastest computer and this talk really hangs while loading. Estemi (talk) 17:21, 16 January 2009 (UTC)

I'm sure I've read somewhere summaries of the ongoing polls with # of people pro/cons. Can anyone please provide a link to such a report (also in my talk)? I've been searching for these infos for hours now. --Elitre (talk) 21:44, 16 January 2009 (UTC)

Link was half way up the page. I've added another one at the top.Ronhjones (talk) 22:10, 16 January 2009 (UTC)

---

Looks like it is being adopted

The godking has said he will be asking for flagged revisions to be switched on soon. [5]. DuncanHill (talk) 00:14, 17 January 2009 (UTC)

This is a total kick in the teeth to the community. 60% has never been enough support to delete an article, let alone throw away a foundation principle. Switching off anonymous article creation didn't work one iota; this won't either. Sceptre ^(talk) 18:18, 17 January 2009 (UTC)

You may wish to view the continued conversation in that same area then, which may be found here. It's starting to get a little heated but it may be worth keeping up with. Thor Malmjursson (talk) 18:28, 17 January 2009 (UTC)

(ec) I respect Jimbo in general, but I really wonder how a 60% support ratio can be considered strong support. We would never trust a user with admin tools below 75% or a crat below 85% but we should implement such a feature with 40% of the community opposing? If this were any other discussion, any admin would consider this a no-consensus close, but surely not a support one. But then he talks about it coming "without any question at all", it kind of sounds like he would have implemented it no matter how the poll would have ended. Just lucky for me that I already speak German, seeing that Jimbo apparently wants us to become de-wiki step-by-step. SoWhy 18:34, 17 January 2009 (UTC)

SoWhy - I have already stated to Jimbo that using de-wiki as a comparison for Flagged Revisions is pointless. The German Wikipedia is about 3 times smaller than English Wikipedia, and my main concern is that we're gonna have major issues with queueing for review. I have done new page patrol on de.wikipedia a couple of times, and your new page creation rate is much slower than en-wiki. We're gonna be swamped. Thor Malmjursson (talk) 18:43, 17 January 2009 (UTC)

It looks like he announced it on a radio programme, then in passing on his talk page. Maybe he's unaware of this talk page? DuncanHill (talk) 18:37, 17 January 2009 (UTC)

It's kind of hard to miss, it is our biggest poll in history... :D Happy‑melon 19:04, 17 January 2009 (UTC)

Looking at the top of Wikipedia talk:Flagged revisions, it appears that editors were not entirely free from pressure from him in this matter. DuncanHill (talk) 19:13, 17 January 2009 (UTC)

It certainly wouldn't have been appropriate on the staw poll page itself (note how Jimbo (support #7) didn't give any comments in the actual poll?) but note that A) that's been there for months, and B) the box wasn't posted by him - when he originally made the comment, it was rather more low-key. Anyway, this is rather tangential to your previous point, isn't it? Happy‑melon 10:06, 18 January 2009 (UTC)

Iceflow: Isn't this, actually, for good? The sooner this nonsense fails, the better. If this buttongame is inevitable, I'm for a full deployment as soon as possible - no test can imitate scale factors. NVO (talk) 19:48, 17 January 2009 (UTC)

No. It's not good, far from it. Screw FUD. This is a clear case of messing up our values and our world. If you want full deployment, fine, you are entitled to your view, but you're rapidly heading into a minority. Over 40% of users here now don't want this at all and its getting closer, last time I checked, just over 126 people between the support and oppose camps. Thor Malmjursson (talk) 20:29, 17 January 2009 (UTC)

Here's the thing -- the poll's numbers aren't exactly correct. Most of the 'votes' (from BOTH sides, but far more in the oppose) seem to be voting as if it 1) Weren't just a trial and 2) Is going to be on all articles. It seems to be the poll was handled quite badly, causing people to really not understand what it is they were voting on. ♫ Melodia Chaconne ♫ (talk) 20:14, 17 January 2009 (UTC)

The voting numbers are spot on according to people's views. The first step to implementation is testing. Sightly off topic, and just an example, look at the UK's membership of the European Union. It was only joined by the UK as a trial and for free trade which we could pull out of at any time. Now the whole of the UK is practically run from Brussels and we're on the verge of losing the last bit of our national identity, our currency. Flagged Revisions is gonna be a suck in. We'll start with the trial, the results "go" in WP's favour, and we wind up stuck with it. If we don't stop it now, we'll never stop it. Thor Malmjursson (talk) 20:36, 17 January 2009 (UTC)

I disagree with Melodia's statement - a lot of the "Support" votes explicitly mention that they're only supporting a trial, with some being along the lines of "well, it's just a trial". If it was a poll on actual full implementation, many of those might've voted against. All Hallow's Wraith (talk) 11:47, 18 January 2009 (UTC)

Nobody is going to enable FLR for all articles overnight. It has never been proposed. I personally think that this is unnecessary. However some articles like BLP may benefit from them. Ruslik (talk) 20:22, 17 January 2009 (UTC)

Yes, but my point is it seems many people answering the poll are thinking that's what it's about (more or less), based on their explanations. But that's just the way I see it. ♫ Melodia Chaconne ♫ (talk) 21:57, 17 January 2009 (UTC)

Maybe they just don't believe that it will stop at a trial? Many bad things were introduced step-by-step, grinding away opposition by saying "it's just limited cases". Studying law, I know some good examples: Wire-tapping for example has been introduced into German law with the promise that it will only be used in cases like murder. Nowadays it's being used for a score of crimes, even such crimes as forgery or bribery. Many who opposed this law with the slippery-slope-argument were ridiculed that they were opposing something that noone planned. Now we know they were correct, but the damage has been done. I think the same may as well apply in this case and people may want to prevent it. Apart, of course, that this feature, no matter how limited its use, does in fact remove "anyone can edit". SoWhy 22:32, 17 January 2009 (UTC)

I see that as a matter of opinion. If you want to hold "anyone can edit" to that level of purity, then the principle is already dead in the water. What are protection and semi-protection templates? What does blocking IPs and preventing anonymous page creation do? Flagged Revisions takes, on the other hand, only delays the appearance of contributions. Sure, you can argue that FLR will be abused to block valid contributions, therefore killing "anyone can edit", but it's not as if WP:AFD and reverts aren't abused in the same way. Estemi (talk) 22:44, 17 January 2009 (UTC)

Exactly. Especially if it's used in place of semi-protection/protection, it offers more editing ability, not less. Not to mention, blocking anyone in general means that "anyone can edit" isn't true if you want to get all technical. But this has all been said before, in a better heading devoted to such. ♫ Melodia Chaconne ♫ (talk) 23:16, 17 January 2009 (UTC)

Thor Malmjursson (who apparently lives in the UK; who'da guessed) gives above the example of the UK's trial membership in EU "which we could pull out of at any time." Similarly, SoWhy gives other "slippery-slope" examples, stating: Many bad things were introduced step-by-step, grinding away opposition by saying "it's just limited cases". Several of us have argued along these lines. Above, these arguments are not answered; the "answers" involve only anyone-can-edit purity, which is not the (main) point. Ignoring the slippery-slope concerns has practical consequences. We've already used many hundreds of man-hours reading, discussing and !voting. If/when the trials begin, even more man-hours will be required to define and evaluate them -- how many of them is unknown. I have opposed and I think this argument should be taken seriously. Thanks, - Hordaland (talk) 01:03, 18 January 2009 (UTC)

I strongly support this proposal--I think that we should at least try flaged revs in some limited fashion before rejecting them. But I think that this kind of disregard for the community's wishes is terrible. Because Jimbo has indicated that he will be moving forward, I think that the community now needs to open a dialogue not on weather flaged revs themselves are a good idea, but if enabling them despite clear lack of consensus is a good idea. I urge my colleagues to recognise that this action will split and damage the community, even if you think that flaged revisions ultimately could be a good thing. We need to speak up now if we are going to keep this from happening. Cheers, — Jake Wartenberg 03:56, 18 January 2009 (UTC)

Agreed, we need a poll on WP:Flagged protection, the proposal that Jimbo seems to support, before it goes forward.--Res2216firestar 04:03, 18 January 2009 (UTC)

I don't even want the extension switched on--that's what this proposal is about--without consensus, which we clearly don't have. And that needs to happen before we even think about doing trials. — Jake Wartenberg 04:10, 18 January 2009 (UTC)

(unindent) Please refer to this clarification by Jimbo: "I, too, do not support turning on FlaggedRevs in the configuration the Germans are using, as I consider it to be much too aggressive. I am also willing to be proven wrong, and who knows what we will find. My view is that it should be "as a protection type system"", then continuing that he would be in favor to use it instead of semi-protection and more liberally for blps. So the implementation he proposed to turn on would indeed be the proposed trial implementation, and I suppose he would support, among the proposed trials, to use it instead of semi-protection and on most problematic bps. Cenarium (Talk) 16:50, 18 January 2009 (UTC)

trial or not

Hi all

I, and I suspect others, was just wondering why the word "trial" does not appear in the proposal line ?

At the moment it reads "Should the proposed configuration of FlaggedRevisions be enabled on the English Wikipedia?"

I was under the impression that it was only a trial.

I expected to see "Should the proposed configuration of FlaggedRevisions be enabled for trial on the English Wikipedia?

can someone clarify as i have spent some time reading about it now and would like to vote !

thanks Chaosdruid (talk) 09:21, 18 January 2009 (UTC)

The "proposed configuration" is a trial. Estemi (talk) 09:41, 18 January 2009 (UTC)

I understood after reading many of the articles, comments and pages that it is supposed to be a trial, but i wonder if there aren't people out there who haven't yet voted simply because it appears that we are actually "straw polling" on having flagged revisions implemented, rather than a trial

I feel that it would be a wonderful thing if locked pages could be opened up by flagging, but that having "normal" and new pages flagged would slow down and possibly detract from the freedom we all enjoy at present. I did try the demo though, and admit that it is easy to use.

Still, my objection is only because if i vote "yes", i am still voting for flagged revisions to be enabled, and not to be put in trial - if this was a pollster approaching me in the street with "we will do this" and they said it was only for a trial i would vote no, if they said "we will do this for a trial period" i may well vote yes, as signing the first one means that they could say "well you voted for it to happen without us trying it out" .
I am not assuming that this is the case, but am pointing out that it could be and, to avoid confusion, simply sticking those words in would help sway at least one voter to yes rather than undecided

Chaosdruid (talk) 10:04, 18 January 2009 (UTC)

It says on the proposal page, on the first line in boldfaced and italicized letters no less, that this is a limited trial implementation. How much clearer can the point be made? Estemi (talk) 10:11, 18 January 2009 (UTC)

By putting it in the header line on the voting page Chaosdruid (talk) 12:09, 18 January 2009 (UTC)

The current proposal is not about an actual trial of flagged revisions; it's about turning on some software options that would be needed before one or more future trials of flagged revisions could be performed.

If the current proposal is implemented and the software features are turned on, the features would nevertheless remain unused (for the time being), and nobody except people in a special user group would even notice that the features were turned on. The only change would be that people in the special user group (called "surveyors") would get a new user interface that would allow them to turn on "flagged revisions" behaviour on some articles.

If the current proposal is implemented, surveyors would not (yet) be authorised by policy to turn on flagged revisions for anything. Some future proposals could give surveyors permission to configure certain articles to work the "flagged revisions" way for a trial period. Only after such future proposals (if any) are passed will you see a real difference in how any articles are viewed and edited.

If you can imagine any future flagged revisions trial that you would support (for example, using flagged revisions on some heavily vandalised articles, or on some pages that hardly ever get edited, or on a few randomly chosen pages, or whatever), then you should support the current proposal to turn on the software features that would allow that future trial to take place. If you can't imagine any future trial that you would support, then you should vote against the current proposal which would make those future trials possible.

It appears to me that many of the people voting "oppose" on the current proposal have misunderstood the proposal, and I don't blame them for that, because the proposal hasn't been well explained. —AlanBarrett (talk) 19:34, 18 January 2009 (UTC)

Thanks you for that explanation, after trawling through numerous pages of extreme legnth and various links, i did the trial on Wikilab, and enjoyed it lol

With your explanation I am more than happy to vote yes, as I know that eventually this will benefit Wiki much more than it will detract.

Chaosdruid (talk) 19:40, 18 January 2009 (UTC)

One of the problems with setting it up like this is something that SoWhy explained earlier. A lot of people "just don't believe that it will stop at a trial? Many bad things were introduced step-by-step, grinding away opposition by saying "it's just limited cases". Studying law, I know some good examples: Wire-tapping for example has been introduced into German law with the promise that it will only be used in cases like murder. Nowadays it's being used for a score of crimes, even such crimes as forgery or bribery. Many who opposed this law with the slippery-slope-argument were ridiculed that they were opposing something that noone planned. Now we know they were correct, but the damage has been done. I think the same may as well apply in this case and people may want to prevent it. Apart, of course, that this feature, no matter how limited its use, does in fact remove "anyone can edit"." Now, you can say that each case will individually require consensus, but I'd prefer to just vote on each case one at a time. If I support this software importation, I have no idea if Flagged Protection (the only trial I support at the moment) will be one of the ones up for vote. If someone started an RfC about Flagged Protection, I'd be happy to support it, but until then, I must oppose. NuclearWarfare _(Talk) 19:53, 18 January 2009 (UTC)

Yehbut sometimes "grinding away opposition" just means showing people that their fears were irrational, so that what was initially unpopular becomes acceptable. And if you think the powers that be are hell-bent on imposing this even if it continues to be unpopular with a significant minority of users, then they are not going to pay any attention to this debate so you're wasting your time here. Since bureaucrats will have control over who gets the key "surveyor" right, you had better spend your time trying to elect bureaucrats you can trust. PaddyLeahy (talk) 20:55, 18 January 2009 (UTC)

Support and Opposition by editor experience: a study

Full study is complete and in last section.

Beginnings

I wanted to know how experienced editors were who were for or against the flagged revisions proposal, so I researched total edit counts of a small sample. I started at #301 for support and #201 for oppose (opposes hadn't hit 300 yet).

Update: now not so small, n=120. My results, supports #301-360 and opposes #201-260):

Edit Count	Support	Oppose
>10000	24	12
1000-9999	21	29
100-999	9	14
<100	6	5

If anyone wants, continue consecutively from where I left off (support #326, and oppose #226) and report your results here. Just make a copy the table for your results and I'll integrate the data. Diderot's dreams (talk) 03:35, 19 January 2009 (UTC)

Comments

Too small of a sample size to mean anything, IMO. Try researching editing time instead of edit counts. After all, when people like j.delanoy support it, everything gets messed up. NuclearWarfare _(Talk) 04:01, 19 January 2009 (UTC)

I was editing it as you wrote just because of edit count average skewing as you said. I'm redoing it, dividing the votes by edit count range, not using an average. As for sample size, I know that's why I put so far. The title's a bit of a teaser to get people to contribute, but I'll change that too! Diderot's dreams (talk) 04:12, 19 January 2009 (UTC)

Sounds like work for a bot. If you want, I can offer to write one by tomorrow (I don't believe a read-only bot requires approval to run). Melissa 4.0 (talk) 09:34, 19 January 2009 (UTC)

A bot certainly would be ideal to get the job done. All bots require approval to run, though, and must be written by an "editor in good standing". Your account has only made a few edits. If you can get it approved, then it would be great, but I don't see how that could happen. Maybe you have another account?

Another approach would be to save the entire voting page to a home computer, then extract the user names and votes, query SQL tools (an off-wiki site) for the edit count, and tabulate the data. This wouldn't require running a bot on Wikipedia.org. Can you write something like that? If you can, please go right ahead. And could you include the source code? Diderot's dreams (talk) 15:19, 19 January 2009 (UTC)

That's what I had in mind. Is Wannabe Kate good for getting the edit count, or is there something more efficient? I'm still undecided about publishing the source code. Melissa 4.0 (talk) 15:59, 19 January 2009 (UTC)

X!'s edit counter is a bit faster. _(Talk) 17:10, 19 January 2009 (UTC)

My main concern now is mass automated use of these tools a violation of Wikipedia/Wikimedia policy without bot permission, etc.? I am going to ask someone in the bot approval process about this now.

OK, I've looked at bot policy and if does't edit anything, it's not a bot. It's just a analysis tool and Orange Mellon's comment below applies. Diderot's dreams (talk) 18:45, 19 January 2009 (UTC)

Oh noes, an unapproved read-only bot!1!! What people don't know will not hurt them (plus search engines do this continuously). — CharlotteWebb 21:19, 19 January 2009 (UTC)

Which tool to use? Wannabe Kate is OK but slow and undercounts a bit (I tried it on my account), we should avoid it if possible to avoid criticism. I couldn't get X!'s edit count to work. Can you guys? I have been using | SQL's tools.

Thanks so much for offering to write a program, Melissa. Before I run it on my computer, I need to see the source as you are effectively an anonymous editor. It doesn't have to be released publically, but can be emailed to me. Diderot's dreams (talk) 18:14, 19 January 2009 (UTC)

If you only want the total edit count, just use the API [6]. This is super-fast because the number is stored and incremented every time you edit, rather than counting the edits each time you check it. Deleted edits are not subtracted from it, if that matters. — CharlotteWebb 21:19, 19 January 2009 (UTC)

What wasn't working about it? I could check it fine. CharlotteWebb, my edit counter does use the API. Xclamation point 02:11, 20 January 2009 (UTC)

Now that's just silly to use the API for one step of the program when you already have database access. I guess the best way to do it would be to use the API as a backup for everything, but only when it cannot connect to the toolserver database. That's besides the point. If people only want the total edit count they are not going to want to put names in your tool one at a time. That would take too long and contain a bunch of information they don't need. — CharlotteWebb 04:20, 20 January 2009 (UTC)

It wouldn't give any results when I tried yesterday afternoon (more than once). It worked fine just now. Diderot's dreams (talk) 13:01, 20 January 2009 (UTC)

Progress statistics from the poll

I have been doing some analysis of my own, although my focus is more on the changes over time than the background of the voters. Some results are shown in the graph to the right. I note several things. Firstly, the percent support has been largely static for about ten days now, at almost dead on 60%. This notwithstanding the considerable fluctuation in net support over the same period. This confirms to me that the poll is reaching the stage where significant further variation is extremely unlikely, given the very large weight of the existing contributions compared to new votes. In addition, the rate of contributions is declining steadily, and the time between votes is rising correspondingly.

I have not yet made any attempt to extract the user associated with each vote or any corresponding background data on them. I may do so at a later date. Happy‑melon 17:33, 19 January 2009 (UTC)

Thanks for your comment. The poll does seem to be winding down, but the question of how differently experienced voters responded is still valid even if the poll is over. The issue of flagged revisions doesn't end with this poll, so the question is still out there: do more experienced users favor flagged revisions more, and if so then why? My study is to determine the answer to the first question. And that is enough for now, so let's please not discuss about why at this time. Diderot's dreams (talk) 17:50, 19 January 2009 (UTC)

Automated read only activity works on the out-of-sight-out-of-mind basis. Wikimedia serves over six billion page views a month. If you do something automated that's on a sufficiently epic scale to be at all noticeable, you deserve to be mauled for it. But this will be merely a drop in the ocean. Using a messy combination of excel, notepad and a quick python script, I now have the raw data required (editcounts, group membership and registration date for all participating users) for a full analysis. Give me some time to analyse it. Happy‑melon 18:22, 19 January 2009 (UTC)

Yeah I checked bot policy, and what we are talking about isn't a bot by definition. My concern was violating policy, I realise that 1000 automated queries of SQL's Tools or whatever isn't going to impact Wikipedia servers that much. Since you've gone ahead on your own, could I please have a copy of the raw data so I can finish my study? Diderot's dreams (talk) 18:47, 19 January 2009 (UTC)

Study results

	Sup	Opp	Neut	Net+	%+
By user group
Administrators	129	48	4	81	71.3%
Rollbackers	117	66	3	51	62.9%
Checkusers	7	0	0	7	100.0%
Oversighters	7	0	0	7	100.0%
Anons	1	2	1	-1	25.0%
Non-admins	253	216	4	37	53.5%
All	382	264	8	118	58.4%
One edit one vote
All	5,949,184	2,857,468	115,979	3,091,716	66.7%
By edit count
0<edits<100	11	10	0	0	52.4%
100<edits<1000	35	54	0	0	39.3%
1000<edits<5000	93	66	2	0	57.8%
5000<edits<10000	70	40	0	0	63.6%
10000<edits<50000	150	86	5	0	62.2%
50000<edits	21	6	0	0	77.8%

edit count	votes	pct.
Participation by Edit Count
0 edits (anons)	4	0.6%
0<edits<100	21	3.2%
100<edits<1000	89	13.6%
1000<edits<5000	161	24.6%
5000<edits<10000	110	16.8%
10000<edits<50000	241	36.9%
50000<edits	27	4.1%
Total	654	100.0%
Participation by Sysop Status
Administrators	181	27.7%
Non-Admins	473	72.3%

I have completed my analysis (apogies for not seeing your request, Diderot, I haven't checked this page since my previous post). The summaries are in the table to the right; they make interesting reading.

It seems that FlaggedRevisions is in general more popular amongst users with higher permissions: all analyses show an increase in support over the baseline. The admittedly very limited samples of checkusers and oversighters are unanimous, which is notable in itself (for reference, there are currently 37 checkusers and 34 oversighters on en.wiki).

The "one edit one vote" row shows how the votes stack up when the voice of each editor is weighted according to how many edits they have made; so a user with ten thousand edits effectively casts ten thousand votes, while an editor with only a hundred edits casts 100 votes. Obviously this is not a particularly equable way to judge a poll, but it is very interesting to note that the balance of net and percentage supports closely mirror the one-editor-one-vote tallies.

The breakdown by edit count is perhaps the most interesting result. Support appears to be stronger amongst those with very few edits than amongst those with slightly more; indeed there is a region where there is net opposition to the proposal. For improved gradation I have created and uploaded another graph, visible to the right, which orders voters by their edit count rather than by the time they submitted. The height of each line is essentially the number of voters who took a particular position and had less than x edits. The blue line is net support, which briefly dips below the x axis before rising to its final value of +118 or so. net support count hovers very close to zero for editors with less than a hundred editors, reaching a high of +2 and a low of -3 (this section of the graph contains 25 editors). It dips sharply below the axis to reach a low of -22, before rising back to zero and beyond. The point at which the line crosses back into the positive is at around 4,250 edits, there are 254 contributors below this point and 400 editors above it. Very interesting.

My source data files are extremely messy but I can publish data from them if anyone still wants the raw values, although I can't upload them here as .xls files are blacklisted. If anyone wants more or different statistics (I still have a set of account registration dates that are thus far unused), just say the word. Happy‑melon 21:09, 19 January 2009 (UTC)

A completely random fact: the editors who have commented on this poll are responsible for over three percent of all edits to en.wiki. Happy‑melon 22:36, 19 January 2009 (UTC)

I have added results for non-admins, and a table of participation by edit count. Interesting results. Diderot's dreams (talk) 23:33, 19 January 2009 (UTC)

Here's my interpretation of the study: The voting results show divisions by experience about flagged reviews. Those with "some experience" with Wikipedia are opposed to FRs. (100-1000 edits, by a 20% margin). Those with less experience seem evenly divided, although the sample is maybe too small to tell. Those with more experience (>1000 edits) increasingly favor FRs. This verifies what has been said before by the opposition: that FRs are one more way to make WP more complicated and difficult for the less experienced to contribute, and easier for the more experienced to get their way in editing conflicts.

The results say something about Wikipedia democracy too. The "some experience editors" are underrepresented in the voting, only 13.6% of voters. They must be a much higher percentage of editors than that. Certainly "expert editors" (>5000 edits) are not nearly 57.8% of editors, which was their pct. of voters. The "inexperienced" and anons are hardly represented at all. So the decisions at WP are made by the "expert editors".

Why don't the less experienced vote? Three factors, I think. They are (1) unaware of the procedures or its importance, or (2) are too busy learning the ins and outs of editing the encyclopedia, or (3) are busy making edits in their initial enthusiasm. Their ignorance is perpetuated by the prohibition about canvassing and the way voting is done-- nobody is sent a ballot, there are no set election dates, there is just an informal notice when they log in, if they log in.

For flagged revisions, this study shows that consensus does not really exist for its implementation. Only 53% of non-admins agree, and a large class of editors, for whom the effects will be different are opposed. Maybe that's OK for a trial run, but for a final implementation the support must be greater and more uniform.

Diderot's dreams (talk) 20:25, 20 January 2009 (UTC)

I don't think I can agree either with your analysis or the majority of the conclusions you draw from it. You make the extremely common statistical mistake of failing to consider possible systemic errors, and estimate their maximum possible impact on the results. For instance, you correctly note both that a smaller percentage of the population of users in the 100-1000 edit range contributed than did other populations, and that the percentage of those users who did contribute that supported was also lower. It is statistically equally plausible that the sample taken from that population was biased in opposition to the proposal (for whatever reason) as it is that the 100-1000 edit population is overall less supportive of the proposal. Since the sample was self-selecting (rather than randomly chosen), the presence of such a bias is in no way inconsistent with a completely fair ballot; it merely means that users in that population who were opposed to the proposal were more likely (for whatever reason) to contribute than users who supported. I suspect that you are at least partially correct in that the overall level of support in the 100-1000 edit population is lower, but to assert that it is a full twenty percent lower is not supportable. Statistics are dangerous tools.

Your second analysis (of the relative balance of involvement in the decision-making process) is framed in such a way as to reduce the impact of such statistical uncertainties; you are probably correct to conclude that highly-active users make up a larger proportion of the sample who voted than the active editor population as a whole. However, remember that said population is itself biased: an active user is more likely to have a high edit count (as only active users have the opportunity to increase their count), and a user with a high edit count is proably also more likely to be active (as they are more likely to be committed to the project). Taking the simplest possible situation in which edits to a wiki are distributed completely randomly across pages, and hence the edits to a voting page are a random sample, you would still expect to see a higher proportion of those edits being made by the more active users, as each highly-active user has mor edits to be potentially selected. Imposing the condition that only one edit from each editor can be counted (a feature of a ballot) and the proportion of highly-active users' edits included will rise further.

I agree with some of your conclusions, but others appear entirely arbitrary: to conclude from an apparent reduced support amongst users with lower edit counts that "FRs are one more way to make WP more complicated and difficult for the less experienced to contribute, and easier for the more experienced to get their way in editing conflicts" is entirely unsupportable. The implication, although I know you are merely repeating others' comments, is that the statistics 'prove' that the proposal is a diabolical scheme to suppress users with lower edit counts, which those insightful users have seen through and oppose. There is simply no way you can support such a sophisticated assertion with these simple figures.

The conclusion "So the decisions at WP are made by the 'expert editors'" is more defensible, and appears superficially correct. My issue here is to challenge the underlying assumption that this is necessarily a Bad Thing. Wikipedia is explicitly not a democracy, and implicitly is somewhere between a noocracy and a timocracy: the weight of users' 'votes' is dependent primarily on their level of respect within the community, and on how coherent and persuasive their arguments are. Most importantly, users gain "respect" primarily by demonstrating a commitment to, and constructive record in, building and maintaining the encyclopedia. This is why we give vandals, trolls and sockpuppets zero weight in discussions, and give more weight to more respected users. As a high edit count is correlated with (although not directly related to) increased 'respect', as is higher user rights, it is probably neither surprising nor detrimental to see greater influence being wielded by more 'respected' users, provided that this is an entirely natural situation and is not being encouraged or enforced. By summarily discounting the opinions of the 181 administrators who participated to note that "Only 53% of non-admins agree", you discarded fifty five percent (4,878,294) of the edits involved. That is, the group of administrators, who make up just a quarter of the contributors, have made over half the edits. Should they be accorded a correspondingly larger voice? No, of course not. Should their voice be artificially suppressed because of a perceived imbalance? Equally not. Statistics are a dangerous tool. Happy‑melon 18:34, 21 January 2009 (UTC)

Thank you for the reply. First let me say I do not think there is a conscious scheme to thwart newer editors. There is a phenomenon occuring, but it is not a conscious scheme. I would have said so if I thought it was. Now some replies to your specific points.

I haven't failed to consider systemic bias in the results for "some experienced" editors. One doesn't discount results because it is theorectically possible to have systemic error, such error is always theoretically possible. You need to present a compelling argument or evidence of a specific systemic error. This you haven't done. 89 people voted, and voted "NO" by a 20 point margin. You must accept the fact, or show this systemic error.

One thing I will say. Eighty-nine may be too small a sample size. There is some possibility that the actual percentages of the entire group could be substantially less or more. Not likely, but possible.

I see no way to discount the conclusion that higher count editors have participated at a much higher rate. If you just count active editors, I'm sure the result would be the same.

I did not conclude that "FRs are one more way to make WP more complicated and difficult for the less experienced to contribute, and easier for the more experienced to get their way in editing conflicts" because of the statistics presented. The statistics simply support that conclusion. My analysis is not just a scientific analysis of the data, since this page is a discussion the issue of FRs. The conclusion is my belief based on my own experience, and the experiences of others.

I am not disregarding the opinions of "expert editors", I am just saying the total vote does not represent consensus, because of edit-count class support differences and razor thin support amongst all non-admins.

Thank you for correcting me that Wikipedia is not a democracy. I always understood that for article content debates. I knew also for policy making, but these straw polls and talk of consensus really fool you into thinking it is one. After all, what is consensus but "agreement by some number above a majority" coupled with "amongst varied groups or interests."? The former is democracy. I thought we had an advisory democracy when it comes to making policy. But more experienced editors have more power in the decision making process, because voting and advising is more known and accessible to them for the reasons I stated in my interpretation, and a lack of potentially correcting mechanisms, such as campaigning. The participation rates make that clear.

This study has opened my eyes that we don't have an advisory democracy, but an advisory aristocracy. So let me comment on our monarchy with an advisory aristocracy. Expert editors have much advisory power in creating and shaping policy. This naturally leads to policies which favor them, and the needs and interests of underrepresented groups are likely to be underconsidered, and over time degraded. Further, I have noticed a certain tendency towards contempt and arbitrary dismissal of lower count editors. We have fewer new editors who stick around these days. This leads to stagnation. All of these things are characteristics of aristocracy, and reasons not to have it.

All types of the editors are important to the success of the encyclopedia: anons, "inexperienced", "some experience", "expert editors": all should have equal access to voting. We recognize the superiority of democracy in some organizations, like countries. We need to recognize it here.

I am also against the idea of monarchy, here or anywhere where it wields power. Even a benevolent, sagacious, and successful monarch. But lets leave that for another time.

Diderot's dreams (talk) 15:02, 23 January 2009 (UTC)

Moved from the voting page

Moved from the voting page as the discussion is getting big (and difficult to follow). --X-Weinzar (talk) 13:26, 19 January 2009 (UTC)

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

   • Well, there is no way to do without RC patrol. You can't let them vandalize dozens of pages and console yourself by thinking "well, none of this will be visible anyways, we can revert this at some point later".

   Why not? We can!

   Well, think about how edits would pile up. The first IP blanks the page, now another user wants to add something to the article. Obviously, he will edit the last flagged revision. But what about this case: There is one useful edit, then some bad edit and then some useful edit again, and they all pile up. Now when YOU want to continue editing you first have to go through the stack of non-flagged revisions to choose between good and bad edits that argued about each other's additions? In that case, you can't just edit the last flagged revision but have to merge the best edits from the stack of non-flagged revisions.

   • I don't think any of them feels that flagged revision would "spoil their game". Besides, they could just return to playing Counter-Strike or whatever in case they should really feel unnecessary ;-)

   Well, there's this and this but he's probably not being serious...

   I can assure you from my experience at DE:WP: Flagged Revisions have no influence on vandalism. Vandalism fighters will still be needed and, as outlined before, vandalism still needs to reverted as quickly as possible.

   • 1) You won't have much fun turning off semi-protection at topics like rap stars, porn stars, wrestlers.

   First we'd have to turn it on; hardly any of these are semi-protected on en:wp (de:wp uses semi-protection a lot more). Of course if we don't implement FlaggedRevs there is a strong push to semi-protect all BLPs.

   • Semi-protection is still useful.

   Often asserted, but have you (de:wp) actually tried to turn it off now you have FlaggedRevs? If so can we have a translation of the report where it is shown that didn't work? PaddyLeahy (talk) 02:46, 18 January 2009 (UTC)

   There was recently a discussion at the administrators' noticeboard where someone complained that so many articles were semi-protected (especially articles about music for teenagers). As one user put it, there are already enough stupid edits by auto-confirmed users in those topics. If you would turn off semi-protection you would have to revert every few minutes. The few useful edits would not be worth all the work having to revert all the time and would also mess up the page history. So there was consenus that there are articles where you just can't turn off semi-protection. (all those sentences are more or less quotes, except for the last one which I use to summarize the discussion)

   • (There will also be some articles where someone forgot the semi-protection but that's a different topic).

   Quite. If we didn't tolerate human error we wouldn't have wikipedia at all.

   • 2) If you give out "sighter" permission to everybody you can forget about the experiment or about the flagged revisions altogether. Of course, you could argue about what the requirements should be. I think what we have is okay. Automatic basis doesn't work, than you can forget about it too.

   Not everybody but 10-100 times as many people as admins (not for a limited trial, obviously). And evidence please on the last point. PaddyLeahy (talk) 02:46, 18 January 2009 (UTC)

   Actually, I'm not sure what you meant by "automatic basis". I understood it as giving the right to every registered user. Did you mean giving it on automatic basis to like users with 300 edits? --X-Weinzar (talk) 13:25, 19 January 2009 (UTC)

   • 3) That's an interesting suggestion. I wonder whether "we" (de-WP) have actually considered to do this. --X-Weinzar (talk) 12:57, 14 January 2009 (UTC)

No Consensus

The voting shows that 58% have supported the proposal.

As this is effectively equivalent to a 'constitutional' change, going as it does to the heart of what the wiki is all about, one would expect a minimum of 66.6% or even 75% (in the case of certain nations) before it could be made.

Reading the supports and opposes, it is also clear that support is often grudging and weak, while opposition is usually vehement and angry.

Pushing these changes through in the face of this large and passionate minority would have catastrophic effects on the morale of the wp-community - it could even open up 'civil war' between an anti-censorship group, and a pro-control and bureaucracy group.

Why take such a damaging step for so little real gain?

Riversider2008 (talk) 15:21, 20 January 2009 (UTC)

As further evidence of lack of consensus, may I point out that only 53% of non-admins supported it, users with 100-1000 edits opposed it by a 20 point margin, and the majority of people who voted (58%) are "very experienced" editors (>5000 edits), a small group of wikipedians. Diderot's dreams (talk) 20:34, 20 January 2009 (UTC)

Why is turning on a piece of software that won't be used until after another straw poll equivalent to a "constitutional change"? Fritzpoll (talk) 15:32, 20 January 2009 (UTC)

if you can't see how, you've missed something fundamental about the WP. Tell me exactly how can this be turned off once it has started? A huge backlog (91% of articles in Germany) with unsighted edits that would suddenly be unleashed on the community. Once this is in, there's no going back. Riversider2008 (talk) 15:36, 20 January 2009 (UTC)

Because if this proposal passes, no pages would be flagged? If no trials were approved by a further consensus, the software would be there, but never used? That no more than a handful of people are suggesting implementing it across all articles like the Germans did? So tell me, how is installing a dormant piece of software a constitutional change? Fritzpoll (talk) 15:39, 20 January 2009 (UTC)

You're going to a tremendous amount of effort to implement something that you now say won't actually do anything. Sorry, this makes me more suspicious than ever. You mention 'further consensus' - there is no consensus on this by any definition of the word.Riversider2008 (talk) 15:42, 20 January 2009 (UTC)

I'm not, personally, and I think the implication of conspiracy is silly. The developers need a straw poll on turning the software on - this is that poll. The proposed trial configurations are variously listed at WP:FLR/P - read the proposal yu're voting on would be my suggestion - it has always been this limited a proposal. The "further consensus" was assuming consensus was achieved on this poll - if there is no consensus, we will not be able to trial things like replacing semi-protection and full protection with flagged revisions (see the trials page) which would expand the ability of people to edit, rather than limit it Fritzpoll (talk) 15:51, 20 January 2009 (UTC)

There is no implication of a conspiracy, just that the language you have used is imprecise. Clearly the intention of the trial is to justify further use of FR, and the belief is that it will somehow deter vandalism. The metrics being used do not really measure success - they will not measure the number of potential new editors deterred by this departure from the key assumption that all editors have equal rights to edit, and equal accountability for what they do.Riversider2008 (talk) 16:00, 20 January 2009 (UTC)

I'm sorry, that's how your comment that was I was saying made you "suspicious" sounded and I apologise for my misunderstanding. The intention of the proposal being voted on here is to turn the software on in the hope that further trials can be run to assess whether, as you claim, the perceived benefits are as good as claimed. Personally, I would like to try WP:Flagged Protection out for a couple of months to see if we could let anonymous editors and newly registered editors contribute to articles - to my mind that is more synonymous with our "constitutional" philosophy that "anyone can edit" than our current situation.

As to metrics, they can only be based on specific trials, not on this software configuration - so it makes sense that these aren;t in this proposal Fritzpoll (talk) 16:06, 20 January 2009 (UTC)

I accept your apology, and would like to apologise in turn, if I implied any sense of 'conspiracy'. I hope that those who make the final decision will respect the deeply felt objections of the 'FR-skeptics'/'WP-Purists'. —Preceding unsigned comment added by Riversider2008 (talk • contribs) 16:13, 20 January 2009 (UTC)

I'm glad we were able to have this exchange in a relatively cordial manner, and I acknowledge your concerns. For my part, I have no idea if it will work or not - I'm just willing to try it to give people a chance to edit who wouldn't otherwise be able to. Best wishes, and good luck to whoever makes the call. Fritzpoll (talk) 16:16, 20 January 2009 (UTC)

Just my own two cents. If we do a limited trial and find out we can't maintain the content (edits are waiting weeks to be cited and edit rates are declining), we can shut off the system and just set all edits live, as they are now. So the idea of resistance to turning off the system because it will foist edits on us is a bit misleading, since it would just reset us to the prior status quo. MBisanz ^talk 17:35, 20 January 2009 (UTC)

The people that left the project won't come back, the damage is done, so yes on a tech (dev) level you can reset to the prior status quo, but you can't restore the social damage, as the people left, there is no tool to communicate with them. Mion (talk) 07:52, 21 January 2009 (UTC)

Outdent - I am going to post a part from a message left by a user, User:X-Weinzar from the German Wikipedia, and a member also here. In his words: "I just read your statements at Jimbo's talk page. Here's one thing I can assure you from my experience at DE-WP: Flagged revs have no influence on vandalism at all, vandalism hasn't declined.". So Flagged Revs have done nothing to stem vandalism on Wikipedia, where it's been used already, and DE-WP have got it switched on right across the board. So what is the point of implementing it here, other than causing more red tape for us to go through? Thor Malmjursson (talk) 17:43, 20 January 2009 (UTC)

Depends how you're intending to use it - if in a limited way like WP:Flagged Protection rather than the full implementation the Germans did it might work: we won't know unless we try. Comparisons to the German experience on both sides of this debate are meaningless - that's why we need to perform limited trials Fritzpoll (talk) 17:50, 20 January 2009 (UTC)

The question that those making the decision must now ponder, is not "Are FRs a good idea?" or even "which side won the vote?", it is "is the community able to come to a consensus about this?" all the evidence from the comments left by people voting is that there is NO CONSENSUS ACHIEVABLE and that progressing down this path will be the start of deep and potentially irreperable ruptures among the editorial community. Riversider2008 (talk) 20:52, 20 January 2009 (UTC)

Don't be so sure that unclear consensus will prevent FLR. Look at WP:N. Now, speaking as a filthy inclusionist, if we were to hold an advertised straw poll about the overall state of notability, I would guess more than 50% of votes would favor major revisions, and if advertised to anonymous voters over 66%. Nevertheless, the policy stands ironclad today. Why is this? Because the most important editors repeatedly decided in its favor. Call it the death of Wikipedia or its maturation, but the cabal is real. And it seems they will decide for FLR (I am not saying this is good). Estemi (talk) 21:29, 20 January 2009 (UTC)

@Riversider2008: Consensus does not trump doing the right thing, doing no harm, doing what is moral, doing what may be legally required. You say doing the right thing in this case may well cause deep ruptures? I say the project may well be better off without editors so wedded to consensus they are unwilling to fix the BLP problem. Just get on with it. ++Lar: t/c 15:27, 22 January 2009 (UTC)

Fair point Lar. Perhaps I was being overly pessimistic when I said 'NO CONSENSUS ACHIEVABLE', if both sides are prepared to think and work hard then some real consensus might still be possible. See my most recent comments lower down: 'Alternative Proposals' Riversider2008 (talk) 23:17, 22 January 2009 (UTC)

Announcement by Jimbo Wales

See [7]. DuncanHill (talk) 23:08, 21 January 2009 (UTC)

""You can edit this page right now" is a core guiding check on everything that we do. We must respect this principle as sacred". Riversider2008 (talk) 13:45, 22 January 2009 (UTC)

We're not going to enable it massively on all articles like on de. There are various proposals. I think the best option is to use it as an alternative to semi-protection, with lower requirements than the semi-protection policy when it comes to blps. And the first step is to implement a trial, limited in time and size. Cenarium (Talk) 14:45, 22 January 2009 (UTC)

So it's OK to break your 'sacred principles' as long as it is only in a "trial, limited in time and size"? Would this stand up as a defence? "Darling my affair with the au pair was only a trial, limited in time and size"... Riversider2008 (talk) 15:12, 22 January 2009 (UTC)

lol.. It wouldn't. But we already break our sacred principles when protecting pages, when we have some benefit in doing so. So we should do the same with flaggedrevs, only use it when it's fully justified and outweighs the negatives. And a page with flaggedrevs is better than a semi-protected one, no ? Cenarium (Talk) 15:31, 22 January 2009 (UTC)

Yes, "You can edit this page right now" is very important. Flagged Revisions in no way harms that ideal. Anonymous users will be able to edit pages that have the "Flagged Revisions" behaviour turned on. And their edits will be visible to anybody else immediately. What changes is that other readers will have to click an extra button to view recent unapproved changes, but that doesn't mean that the unapproved changes are not visible, or that it was impossible for the unapproved changes to have been made at all. Implying or stating that Flagged Revisions will remove the ability for anybody to edit is unreasonable, and appears to illustrates either a lack of understanding of the proposal, or a deliberate attempt to distort the proposal. If you want to argue against Flagged Revisions, there are plenty of honest arguments, such as "clicking an extra button is too much work for readers", or "readers won't notice the extra button", or "patrolling edits to flag them is too much work for trusted users", or "there might not be enough trusted users to do all the extra work", or "the user interface is too difficult to understand", or "the interface will scare people", or "the delay before edits are approved will discourage people from editing" or "I don't think it will reduce vandalism", or some others that I can't think of right now; please don't use dishonest arguments like "people will not be able to edit this page right now" or "unapproved edits will not be visible to anonymous users". —AlanBarrett (talk) 16:04, 22 January 2009 (UTC)

The rhetoric is merely being oversimplified. Anyone who understands the method by which FlaggedRevs works (which is a reasonable assumption of readers of this page) should understand that anyone can still edit—when people argue that FlaggedRevs* (*with flagged-revisions-visible-by-default enabled) denies editing rights to some, they are obviously not arguing that "people cannot edit", they are arguing that "people effectively cannot edit". Effective editing is something very important: many people opposed to FlaggedRevs in the proposed form understand that few passive users (as opposed to active editors) will follow a link marked "see most recent revision" when they already have a Wikipedia article in front of them. Please, in future rebuttals, consider what people mean as well as what they say—your accusation of "dishonest argument[ation]" is galling. {{Nihiltres|talk|log}} 16:20, 22 January 2009 (UTC)

Alan I think your comments would be better suited on my user page. I have not been dishonest. If I have misunderstood the proposal as meaning that anonymous users will not be able to see the edits, that misunderstanding is also shared by some advocates of FR: see[8] where it is stated that only users with "higher rights" will be able to see edits. The strongest argument for FR is not to 'wreak havoc' on the lives Living Persons. If there are genuinely no other methods that Biographies of Living Persons can be protected FR might well be justified, but only then and only for that purpose, and then only with Cenarium's honesty (displayed above) that this does possibly contradict some of WP's 'Sacred Principles'. Riversider2008 (talk) 16:19, 22 January 2009 (UTC)

Sorry, I didn't mean to pick on you; I meant to make a general comment about a type of argument that I have seen over and over in this poll. Maybe I should have started a new section. —AlanBarrett (talk) 18:35, 22 January 2009 (UTC)

Propose to close the poll on Friday

In light of the new directions that this process is taking (vide section above and User talk:Jimbo Wales) that put this poll increasingly 'in the past', but recognising that there is no overwhelming requirement for haste, I propose that this poll is formally 'closed' at ~17:40 on Friday, three weeks after it was opened. I believe that the situation is passing the point where an extra X contributions to the poll are likely to have a significant impact on how we proceed hereafter. Are there any objections? Happy‑melon 23:35, 21 January 2009 (UTC)

I second closing this on Friday, we need to get this testing to give the community in general a better feeling of what this is about. -Marcusmax(speak) 01:34, 22 January 2009 (UTC)

Close it now. If Jimbo is going to pull rank and impose this on us then let's stop wasting time here and move on. --ElKevbo (talk) 01:45, 22 January 2009 (UTC)

Agreed, it was entirely pointless to even read all the arguements above. Leaving this open to trick other editors into wasting their time would serve what purpose?Yobmod (talk) 08:42, 22 January 2009 (UTC)

There's no point in keeping it open, it was essentially "closed" when Jimbo interpreted its results as a consensus for turning on flagged revs. Actually it probably really should be closed asap so we end with the rough numbers Jimbo was looking at when he made his decision.--Bigtimepeace | talk | contribs 09:53, 22 January 2009 (UTC)

Close it now. Not because "Jimbo is going to pull rank and impose this on us" but because the outcome is clear. The margin is not changing significantly, so keeping it open does not gain anything. Get on with the implementation. Disclaimer: I would be here arguing for implementation of this regardless of the poll results. Wikipedia is not a democracy. As MW technology changes and advances, some things just need to be adopted for the good of the project, regardless of popular opinion. ++Lar: t/c 12:05, 22 January 2009 (UTC)

Not a democracy, no, but precisely what is and is not "for the good of the project" is often very much subject to debate, as is the case with flagged revs. There are a lot of opinions on this issue (some don't even want to try it, some think we should implement all over asap, others are agnostic until we run some limited trials, some are okay with it for BLP's but not much beyond that, etc.) and we still need to hash this all out at some length in my view. I must say I'm not a huge fan of the "this is the right thing to do, period" argument (nor its inverse argument on the other side) being thrown around here so cavalierly, particularly since we have not even tested it yet and have no idea how well it will work, to what extent it will be practical or scalable, etc. There are a lot of uncertainties and it would be good if everyone, whether they like the idea of flagged revs or not, could admit that. Both sides of this debate have made very legitimate points and as we discuss this further and gather data from testing opinions might well change. Everyone should be open to the possibility that flagged revs will be a huge or minor success, or a huge or minor failure, or something in between. --Bigtimepeace | talk | contribs 12:39, 22 January 2009 (UTC)

Well, if it fails, the next step is to get rid of all BLPs, I guess. Those saying "this won't work" or "this will be too much work to do" need to get out of the way of those prepared to do something to solve the BLP problem, which may well be the biggest problem facing this project, bar none. Again, this technology was lacking when WP was first created but if it had been available, it should have been used from the get go. ++Lar: t/c 15:24, 22 January 2009 (UTC)

Just to be quite clear, I am very concerned with the BLP problem and am very much prepared to do something about it, as I'm guessing are many who are wary of flagged revs. I'm not at all convinced that flagged revs will solve or even do all that much to mitigate the BLP problem, nor that it will not create other significant problems as well. But now that it's been decided to have a trial (which I opposed solely because I did not necessarily believe that it was "just a trial," which still concerns me), I'm quite open to learning more about the extent to which flagged revs improve our BLPs and to the possibility that it will be a success. I'm also open to the possibility that there are other, better solutions beyond deleting BLPs (and would add that, since there are tons of BLP issues on non-bio articles, if we at some point decided to get rid of BLPs in reality I think we'd basically have to shut down the entire project). I'm basically asking those in favor to be open to the possibility that it will not work all that well, and that there may be other things we can do with respect to BLPs in combination with or instead of flagged revs.

I have a lot of respect for your opinions in general Lar, but your previous comment only reinforces the concerns in my comment before that. Editors who take some degree of issue with flagged revs are not exclusively an uncaring bunch with no concern for BLP who simply need to "get out of the way" as you put it. Concerns that flagged revs might move the project away from allowing anyone to edit are not illegitimate, and I don't think it's at all helpful to tar editors who have those concerns with the "you don't get BLP" brush. I get a much stronger "the other side is crazy" view from supporters of flagged revs that from its detractors and I just don't think that's constructive. --Bigtimepeace | talk | contribs 19:30, 22 January 2009 (UTC)

We wouldn't have to shut down the entire project. We could still write about Pokemon.  :-) Ozob (talk) 20:45, 22 January 2009 (UTC)

Concur with Bigtimepeace, there are a multitude of extensions available (Liquidthreads, Babel, etc), the community decides what it wants and how it wants it (with the last word given to the WMF, but it rarely happens), so whether it's good for the project is the predominant question and the answer is not always obvious. It's not like enhancements of existing software. There are cases like revision deletion or selective blocking were support is quasi-universal, but it's not always the case. Now the level of community consensus needed is all the debate, but this being only a limited trial, it should be enough for the devs, with the request of Jimbo. Cenarium (Talk) 14:59, 22 January 2009 (UTC)

I also agree with Happy-Melon's suggestion above to close the poll. Ozob (talk) 20:45, 22 January 2009 (UTC)

Actually, I'd suggest you come up with a consensus about the duration of a poll before it starts next time ;-) I'll add a note to the poll that it's going to end friday at 24:00 UTC. --PaterMcFly (talk) 22:05, 22 January 2009 (UTC)

I don't see the poll fluctuating much, the sooner the better at this point. §hep • ^Talk 22:30, 22 January 2009 (UTC)

Alternative Proposals

On his talkpage JimboWales says this:

"Those who are in the minority who are opposed to this are invited to make an alternative proposal within the next 7 days, to be voted upon for the next 14 days after that, a proposal which is clearly aware that you are in the minority and that does not attempt to simply re-hold the same vote. I ask you to seek some detailed policy around the use of the feature that you think both you and the supporters can agree upon. Simply engaging in FUD and screaming is not going to be helpful, but I trust that outside of a few, most of the people opposed can actually work cogently with others to find a reasonable and responsible compromise position.

One possibility, and I ask you to simply consider this, although I do not support it. Suppose the plan were to simply replace the current semi-protection feature with the flagged-revisions feature? So that everything would be as it is today, with the added simple benefit that anonymous ips and new users would be able to edit things that today they are not able to edit?

Suppose further that, because the feature is softer, it could be used in a slightly broader set of cases. What set of cases should those be?" (my emphasis RS)

Those of us who have been vociferous in opposing the trials therefore now need to meet this challenge by thinking clearly about a compromise that would work for both sides - I think this is the real definition of reaching a 'consensus', in a way which cannot be achieved merely by holding a poll. I suspect there is room for a consensus around such a compromise, possibly on the lines Jimbo has sketched out.

If it could be achieved, what would be the bare bones of such a consensual proposal? (Since the strongest argument for FRs is to prevent Living Persons having havoc wreaked on their lives, perhaps a strong limitation of the use of FRs to BLPs and other places that are currently protected and semi-protected would be my initial feeling. I cannot see any case for further extending their use to topics that do not currently have some kind of protection inflicted on them). Riversider2008 (talk) 22:39, 22 January 2009 (UTC)