Wikipedia talk:Flagged revisions/Archive 8

Archive 5

Archive 6

Archive 7

Archive 8

Archive 9

Automatic sighting after a certain period

I think it would be appreciable from a number of points of view that, when an edit hasn't been sighted for x time, for example 24 hours, then the software automatically sights it. Primarily because Wikipedia is free for editing, and there is no reason that a backlog of non-sighted edits delays a good edit for days. Secondly because vandalism is generally reverted within minutes, or hours on lesser watched articles, so it wouldn't particularly reduce the expected effects of sighted revs. Of course, it would reassure users worried that it could impair the openness of Wikipedia. We could put the delay in a message so that we can modify it based on consensus. Cenarium ^Talk 02:15, 27 October 2008 (UTC)

This could be a good idea, since it avoids edits appearing for either (a) 24 hours, or (b) until sighted. That said, I have a number of concerns with this implementation which I'll need to think about. – Thomas H. Larsen 22:45, 31 October 2008 (UTC)

Reasons to automatically sight edits after a reasonable amount of time:

• Avoid huge backlogs of edits to sight that would dramatically reduce the openness and free editing nature of Wikipedia, and in the long run that would mean a decrease of anonymous and new contributors.
• Vandalism is generally reverted within minutes (even seconds) on high profile pages, and within hours on most pages, so it won't significantly decrease the efficiency of sighted revisions.

We could use different delays before automatic sighting, for example 24 hours for IPs, 18 hours for users, 12 hours for autoconfirmed users and 5 minutes for 'established' users, and of course immediate for surveyors. 'Established' would be a group between autoconfirmed and surveyor with only this specificity that edits are automatically sighted faster, that is granted automatically after certain conditions, and can be assigned and removed by sysops. Cenarium ^Talk 01:18, 8 November 2008 (UTC)

• Automatic sighting seems very largely to negate the purpose of the whole exercise, and the time-frames suggested seem extremely short for the generality of articles or even of FAs. Some older FAs seem barely to be on anyones watchlists. Johnbod (talk) 22:10, 13 November 2008 (UTC)
  • You forget that anti-vandalism tools, like Huggle, can catch all articles and vandalism is generally reverted within minutes, and to the extreme, within hours on most pages. If some edits are delayed by days, weeks or months because editors haven't some 'surveyor' rights, then it's the end of open-editing and will inevitably reduce the appeal of Wikipedia to new editors. Confirming that "any edit will be visible within 12-24 hours" will make flagged revisions acceptable. Without this, we'll never have support for flagged revisions, it's clear. Cenarium ^Talk 03:32, 14 November 2008 (UTC)

FWIW this is bug 4397[1], currently marked as WONTFIX. - (User) Wolfkeeper (Talk) 16:50, 14 December 2008 (UTC)

Due to lack of support. If we have consensus for flagged revisions with expiration on the English Wikipedia, but not for flagged revisions without it, then this will probably be revisited and worked out. Cenarium (Talk) 18:52, 18 December 2008 (UTC)

On full implementation: expired revisions

Main page: User:Cenarium/Flagged revisions/Expiration system

Still trying to address the problem of backlog for a full implementation, with acceptable edits getting unsighted for long periods. I proposed above that edits be automatically sighted after a certain period of time, however it should be properly distinguished from manual sighting, and doing so technically may be a bit cumbersome. With a similar goal, a system of expired revisions could be created to show to IPs revisions when they are old enough, and are not positive to an automatic vandalism check (see below). The principle is that when a revision is old enough, it is marked as expired and the latest expired revision is showed as the stable version if no later sighted revision exists. The rules are listed there. This system could be deactivated by admins on a page. Since there is still the, albeit unlikely, case where a vandalism edit could expire and be showed to IPs, we could use the abuse filter to prevent a revision matching certain filters from expiring. There seems to be an appreciable use of the abuse filter in conjunction with sighted revisions, for example preventing a surveyor from sighting certain revisions identified as 'very bad', since there is still the case where a vandal could access surveyor rights. Cenarium ^Talk 04:00, 29 November 2008 (UTC)

There is a special page to maintain the queue of outdated reviewed pages. I don't see why you'd need or want anything else.  — Mike.lifeguard | ^@en.wb 06:19, 29 November 2008 (UTC)

I suppose you are referring to Special:Oldreviewedpages. But all the problem is that they won't be sighted for long periods of time and thus good revisions will be long delayed to public view. This is with the lack of openness the number one opposition to flagged revisions. If revisions that are old enough and automatically verified as unlikely to contain vandalism are showed to IPs, this is a step in the good direction. Our editing volume is so important and the number of regular editors so small in comparison to the total number of editors that if we don't use this kind of system, we'll be quickly overburden. Using automatic processes like the Abuse filter, and semi-automatic tools like Huggle is, of course, necessary if we want that FLR works on Wikipedia. And even so, we won't be able to keep up with the number of edits, so an expiration system is inevitable if we don't want weeks-old or months-old unreviewed pages. Cenarium ^Talk 14:47, 29 November 2008 (UTC)

Just adding a note that this will probably affect anonymous readers only. They can still see the draft if they want - either clicking the link, or creating an account.  — Mike.lifeguard | ^@en.wb 06:22, 2 December 2008 (UTC)

There could plausibly be a bot that automatically sights revisions if they have been in the Special:Oldreviewedpages list too long.- (User) Wolfkeeper (Talk) 21:58, 14 December 2008 (UTC)

For the trial maybe, but not for a full implementation. That would be too much server load compared to a built-in, automated process. And it would mark an edit as sighted, while it is not exactly what we want since it has not been reviewed by a user. While marking a revision as expired, will recognize expired revisions as such, and will be dealt with differently. I'm thinking about creating a subpage where we can discuss the issue, generally and more technically. Cenarium (Talk) 18:58, 18 December 2008 (UTC)

Believe wholeheartedly that an expiration system is required for keeping flagged revisions a democratic process. I would actually go further, and make the expiration period a function of the volume of edits that a page sees and the size of the diff, so that pages with significant volume have a shorter fuse for expiration. After all, significant volume implies more attention that can address the changes. Similarly, larger diffs mean more content to review so the expiration should be longer. 70.247.162.50 (talk) 01:01, 1 February 2009 (UTC)

RfC opened

I have opened an RfC on the /Trial implementation: Wikipedia talk:Flagged revisions/Trial#RfC on implementation. Happy‑melon 17:59, 14 December 2008 (UTC)

I wanted to open a RFC (or something like it) myself, but you beat me at this! Ruslik (talk) 18:20, 14 December 2008 (UTC)

Thanks. I'd like to announce this via watchlist notices as well, but I'm not sure if this would be the best path of action—suggestions, anybody? – Thomas H. Larsen 02:23, 15 December 2008 (UTC)

I think this should be a gradual 'ramp up': we'll start with the RfC, then spam the boards with it. Then we can add it to {{cent}} and by the time we actually come to have a poll a Signpost/watchlist combo will be appropriate. At the moment making it too visible will do more harm than good: we need time to iron out any problems before they're jumped on by the rampaging hordes... :D Happy‑melon 13:30, 15 December 2008 (UTC)

That's a good point. – Thomas H. Larsen 03:50, 16 December 2008 (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)

Question

I have tried to quickly find the answer to this question in a few different places, including this page and its archived pages (without, admittedly, reading all of the thousands of posts), but I haven't found it. Can someone please explain, in relatively simple terms, what this "flagging" thing is all about, as it relates your average everyday editor or reader of Wikipedia? And please try to do it without doing things like using "flagged" and "sighted" to define themselves (which is one of the reasons I need to ask the question in the first place.) And please, please try to do it without sending me to a Wikipedia in a language I don't understand. (I almost fell off my chair when I saw the tag at the top of this page, suggesting I do exactly that.) In other words, let's say this proposal or a trial of it are implemented. Let's also say I am a regular editor, no special privileges, but not a new editor, and I make an edit to an article. What happens to it? Do people still see it right away? Or not? Or what? And then change the hypothetical to, I am an IP editor, and answer the same questions. And then change it to, I have just created an account and am making my first edit, and so on. And any other categories that apply. And then, from the standpoint of the reader, I get the impression that different readers are going to see different things, but I do not know who is going to see what, and when. 6SJ7 (talk) 23:20, 19 December 2008 (UTC)

Here's the quick version: It allows us to pick a version of a page and mark that version as "sighted". This means that that version will be the version of the page people see when they go to the article (although logged in users may pick if they see the newest edit, or the "sighted" version). This means that if someone comes along and edits a page to add "LOLZ" all over it, that version won't be shown to the public. New edits are "sighted" if they are not vandalism, although the exact process of all this is still being worked out here. --Falcorian ^(talk) 02:21, 20 December 2008 (UTC)

Ok, so it is called the "sighted" version because it is the version that is designated to be seen (or "sighted", I guess) by any reader who is not logged in, or by any logged-in editor who chooses to read that version. Is that correct? Thank you for the explanation, Falcorian. 6SJ7 (talk) 05:14, 20 December 2008 (UTC)

That's the gist of it! We're still trying to hammer out pretty much all the other details though... --Falcorian ^(talk) 08:35, 20 December 2008 (UTC)

Then perhaps a section should be added to this page to include an example of how flagged revisions and sightings works, describing who gets to see what and when. The current version doesn't actually provide much explanation. Dl2000 (talk) 18:36, 28 December 2008 (UTC)

That's entirely dependent on the configuration that's chosen. Mr. Z-man 18:43, 28 December 2008 (UTC)

You can try FR yourself on en.labs. Ruslik (talk) 18:49, 28 December 2008 (UTC)

/Trial progress

I think we are now approaching the stage where we can consider moving forward with this proposal. We have numerous comments on the RfC, which are generally favourable. I have asked for input from our friendly local 'crats, who have declared happiness with their part in the process. I have spent a few hours today mucking around with en.labs to make its implementation as closely as possible mirror the proposal here; I think it's pretty good. Have a play here and tell me what you think. I'm inclined to wait now until after Christmas, but maybe we should be thinking about opening a poll in a few days time? It will need to be open for a couple of weeks, so well into the new year, to gain the necessary consensus. Thoughts? Happy‑melon 14:41, 24 December 2008 (UTC)

Hi Happy-melon, sort of discussion is running on Wikipedia:Protecting BLP articles feeler survey. cheers Mion (talk) 15:21, 24 December 2008 (UTC)

I am looking at that, and I generally like what I see. However, any presentation to the developers must demonstrate a very clear consensus for the exact configuration proposed, which does mean a specific straw poll "shall we implement config X?". Happy‑melon 15:53, 24 December 2008 (UTC)

I noticed two possible technical problems:

1) 'autopatrolother' right assigned to reviewers and rollbackers. It will enable autopatrolling of the edits that these usergroups make to non-reviewable pages. Currently only sysops have this ability. Should it be removed?

2) Bots usergroup. Should 'review', 'autoreview', 'unreviewedpages' and 'movestable' rights be assigned to this group too?

Ruslik (talk) 16:49, 24 December 2008 (UTC)

Ooh, good catches. Certainly autopatrolother shouldn't be granted any more widely than it is now. I don't think we should give review to bots, but autoreview and movestable will be utterly crucial, otherwise we'll have to go round sighting all of Sinebot/MiszaBot/etcBot's edits! Happy‑melon 17:33, 24 December 2008 (UTC)

I thinks bots and sysops still need to have 'autopatrolother' (they currently have 'autopatrol' right). So added it to these user groups. Ruslik (talk) 19:26, 24 December 2008 (UTC)

AFAIK, the main namespace is pretty much the only one that gets patrolled anyway, giving some trusted-ish users autopatrolother shouldn't really matter. Mr. Z-man 00:34, 25 December 2008 (UTC)

Editor view only

I have a question regarding an editor making a contribution and as I understand it that editor is the only one seeing the article complete with the attribution, all other visitors see the last sighted version. Editor A makes a contribution, now comes editor B and makes a contribution which is only live shown to editor B, and not to editor A ? or is editor A upgraded to see the version of editor B as well (actually as soon as you make a contribution to an article flagged revisions is shut off for you and other editors on the article ?)Mion (talk) 12:18, 30 December 2008 (UTC)

All logged-in users see the most recent version of a page, no matter who edited it and when/whether it was sighted. So if editor A makes a contribution, editor B will see the page with that contribution whether the edit was sighted or not. Let's say that editor A is not a 'reviewer' and so cannot sight edits. He edits the article foo; to editor A, editor B and editor C, the article now appears with that new change immediately visible. To the IP 012.123.234.123, however, the article appears as it was before A edited it. Now let editor B come along and make another edit to the article, which she then sights. Now to all viewers the page displays the content after A and B's edits. Happy‑melon 13:20, 30 December 2008 (UTC)

But if editor A, and B are IP users ? not uncommon with a 33% IP user base, does editor A see the edits of editor B, or is editor A given the impression that the contribution was allright and still watches version A, which is actually changed to the version from editor B ?(until the sighter comes by) Mion (talk)

I see your question. The answer is that editor B will view the page, and will see the original page (before editor A's edit). When editor B clicks 'edit this page' (it actually says "edit draft") the edit box appears containing the current code (after editor A's edit), plus a diff of editor A's changes, plus a notice explaining what's going on. When editor B has finished editing, the next editor will see the up-to-date wikicode plus the diff of both A and B's changes. By far the easiest way to explain is with an example: this page on en.labs is currently in the state you suggest after an editor "A" without sighting permissions has made an edit to it. Have a look at what happens if you try to edit as an IP. Hope this helps. Happy‑melon 13:53, 30 December 2008 (UTC)

You're not a Sighter, then you're a Vandal

As this question is explicit about flagged revs, i'll ask it here:

Further testing on DE shows some effects. The setup is as followed

1 Administrators

2 Sighter

3 Registered trusted users

4 Registered untrusted users

5 Unregistered untrusted users (IP)

I have 2000+ edits on DE, and so i'm automaticly promoted to Sighter, but I only contribute content and corrections to DE, no patrolling, dont run a Cluebot, so I requested to have the Sighter status removed (de:Wikipedia Diskussion:Gesichtete Versionen#Sichter abstellen , back to the former state. What happends is that my edits from now on are not shown to the public until a Sighter comes by, my edits end up in the hidden queue, you can see that on [2]. Mion (talk) 08:01, 1 January 2009 (UTC) In effect, my status on the German wiki changed from trusted user with 2000+ edits to vandal with 2000+ edits, regardless of the type of article, is there an option implemented that I can keep my current status ? Mion (talk) 09:25, 1 January 2009 (UTC)

No, your status reverted to a "registered trusted user" as you describe it; are your contributions to de.wiki being arbitrarily reverted? Why would you want to have sighter status removed? More importantly, why would you then complain about not having the benefits of the 'sighter' group? :D Happy‑melon 11:27, 1 January 2009 (UTC)

I'm not a patroller on DE, so i want to go back to group 3 Registered trusted user, the status i had before, so they did keep me as an autoconfirmed user, but in effect, i'm downgraded to group 5, as a not trusted user, and no, i'm not reverted, the edit is still handled as an edit in the sandbox [3] , until a sighter comes by. Mion (talk) 11:33, 1 January 2009 (UTC)

You have to logout to see the effect. Mion (talk) 11:40, 1 January 2009 (UTC)

There is no difference between 2 Sighter and 3 Registered trusted users. When you wanted to have your editor rights removed, you became a registered untrusted users, because there is nothing else. And you are right, that's a nuisance both to you and the german wikipedia, so please ask to get your rights back. --P. Birken (talk) 13:11, 3 January 2009 (UTC)

So, in effect i'm a vandal with 2000+ edits ? Mion (talk) 15:59, 3 January 2009 (UTC)

No, you're an "untrusted user"; or rather, someone who has asked to be treated as an untrusted user. You'd be a vandal if people weren't sighting your edits, were reverting them, and were thinking of blocking you. Hyperbole only clouds the issue. Asking for rights to be removed because you weren't planning on using them is stupid (look at my block log to see how much I use that permission), doubly so when you then realise that you've actually tied your shoelaces together in the process. Go to wherever the de.wiki equivalent of WP:RFR is and ask for your flag back. Refusing to do so and then complaining that you don't have the permissions associated with it is, I have to conclude, rather silly. Or am I missing the point of your comments? Happy‑melon 16:52, 3 January 2009 (UTC)

I think he's claiming that the lack of immediacy is tantamount to being untrusted. 70.251.156.202 (talk) 19:09, 1 February 2009 (UTC)

I don't see the reason why you requested to have your status removed. There is no extra responsibility as sighter. There is no group 3 in the german wikipedia.--Don-golione (talk) 02:11, 12 March 2009 (UTC)

Legal liability under a sighter system

A few people in the proposed trial are referring to libel, and the review/prevention of libelous contributions. I just wanted to know if anybody has seen the legal ramifications of one editor 'sighting' another editors contributions as ok, when in actual fact it is libelous, be discussed before. As I understand it, reviewers are not going to be much more than trusted users, so where is the expectation that they can accurately judge what is and isn't libel coming from? And what does the presence of a more formal 'moderating structure' have on the legal position as I understand it, that Wikipedia itself is immune from claims of libel, which instead are filed against the original contributor. If I sight a libelous version under the Wikipedia sanctioned system, do I become a co-accused in any claim? Or is there simply no legal difference between libel in the public versions available to all, and libel in the unsighted versions available to registered users only?

As a side note, has anybody commented on the inherent bias it could produce in Wikipedia review process if reviewers who are more aware of the US libel laws (which differs significantly from the next largest superst of contributions, the UK) end up sighting more articles than other reviewers? How well (if at all?) do the Germans know the US libel laws (I have not looked to see if they actually have the presence of libelous material in their sighting criteria, so if its irrelevent just scratch it) MickMacNee (talk) 16:19, 3 January 2009 (UTC)

See Wikipedia:Protecting BLP articles feeler survey/General discussion#Would flagged revisions make Wikipedia legally liable?. Ruslik (talk) 17:14, 3 January 2009 (UTC)

I've e-mailed Mike Godwin and asked him to comment; don't hold your breath, but it would be nice to have his opinion. In the interim I think Newyorkbrad's opinion in the thread Ruslik linked is the most authoritative (his credentials are well known, and his integrity is beyond dispute). Happy‑melon 18:04, 3 January 2009 (UTC)

I agree its probably all speculative, but I think the fact that other forums have moderators, it probaly indicates that the Foundation is not a risk by having organised systems. What I would like clarification on (or an official foundation statement of 'no idea') is, 1. Is it legally relevant whether libel is not visible to the general public, if it can still be seen by millions of registered editors?, and 2. Is a reviewer in any way even likely to be held as liable for sighting a libelous edit? MickMacNee (talk) 20:11, 3 January 2009 (UTC)

I think the general consensus is that implementing FlaggedRevs can't be detrimental to the Foundation's legal position; it is at worse neutral and at best a good-faith attempt to improve their handling of libel etc. I guess there are some parallels to deleted revisions, which are still visible without logging to 1,500 unvetted, unidentified users; from the fact that the give-non-admins-view-deleted discussion was axed by Godwin I suspect there might be some mileage in making questionable material less visible being a Good Thing. As for the legal liability of individual editors, I expect (hope certainly) that we're still no more liable than we would be if we made an unrelated edit to the page (and thus were unquestionably 'there') but failed to remove the libel or whatever, that is, guilty (perhaps, in a tenuous fashion) of failing to react to it, but probably not complicit in its addition. But then I'm not a lawyer, so don't put too much on these ramblings. Happy‑melon 21:00, 3 January 2009 (UTC)

Mike Godwin has allowed me to post his response, which was as follows:

“ So far as I know, there has never been a case that directly addressed the issue of whether review of a wiki article, followed by its being labeled "sighted" or "flagged", creates liability for the labeller. I can imagine a circumstance in which someone might try to base a theory of liability on such review -- the plaintiff might argue that the review somehow endorsed or validated the allegedly libelous statements in the article -- but that circumstance hasn't come up yet.

Note also that many non-American jurisdictions tend to be more willing to find creative ways to impose theoretical liability on editors.

The counterbalancing factor is that most plaintiffs want to be able to reach the money at the Foundation, not individual editors. And "sighted" revisions won't help plaintiffs do that, in general.

--Mike

”

Typically conservative; the general message seems to be "no one has a clue". It seems to implicitly support the assumption that the system won't make the Foundation any more liable; and that, given the limited compensation to be gained by suing an individual editor rather than the Foundation itself, plaintiffs are extremely unlikely to try given the uncertainty over their legal position. I don't think legal liability is a major concern of his here. Happy‑melon 16:59, 4 January 2009 (UTC)

I've been deeply concerned about this issue as well. The Seigenthaler incident involves an article which could easily have been flagged by a user who is not completely alert. (I would estimate that it passed under the radar of at least a few new page patrollers who saw the article but didn't spot the offensive sentence.) Under an flagging scheme, I think the media would come pretty hard down on a volunteer who gets fooled into approving an edit like that, even if the flagger were not legally liable. I wonder if a possible solution is to make the flagging process totally anonymous; no record of any sort should be made on who flagged what edits. There should be no log which a small priveleged group can see as is the case with checkuser and oversight, I mean no log whatsoever. The only person who can identifiably be associated with an offensive edit is the person who made the edit, not the person who approved the edit. Sjakkalle (Check!) 07:21, 6 January 2009 (UTC)

This sort of anonymity is deeply against wiki philosophy; transparency and open-ness is an absolutely fundamental tenet of what we do. There is no such thing as "no log whatsoever"; if a legal case was brought, the wikimedia developers would be subpoena'd; they would tear the server logs apart and extract the evidence of who did what from the raw data if they had to. There is no way to conceal from a court the fact of who sighted what edit unless the entire system was reconfigured with that express purpose in mind... and I suspect a court would view such an effort with immediate suspicion, which is the last thing we want. So given that a court would have the data one way or another, what's the point of witholding it from everyone else?

This sort of issue is precisely why we don't require people to edit under their own name; if the thought of media ridicule concerns you, edit under a pseudonym that you can throw away, as you do now. Happy‑melon 11:01, 6 January 2009 (UTC)

OK, the foundation is not at risk by implementing FR, we have no grounds to say what the liability of sighters will be, so the only thing left I want to see cleared up is whether a libel is legally less actionable if it is only visible to registered logged in users. i.e. is there any actual legal benefit to implementing FR with regards protection from libel claims? MickMacNee (talk) 17:11, 6 January 2009 (UTC)

I've asked Mike again, hopefully he'll respond, although don't hold your breath. My distinctly non-legal Opinion is that there is probably some crossover with the view-deleted debacle. That viewing restriction was rather more pronounced - it was proposed to rescind the status quo which was to hide a lot of material with a high libel content from the vast majority of readers - but the situation is similar. Godwin said that rescinding this viewing restriction would be legally "disastrous". I can imagine that implementing FlaggedRevs would have a more moderate but still arguable positive effect in comparison. Happy‑melon 17:36, 6 January 2009 (UTC)

21 days?

The major argument for this proposal has always been "But it works on the German Wikipedia". In fact, this translated report says that the German WP is, with great effort, keeping the median time between sightings down to 21 days. This means that half of all sightings take longer than three weeks.

This is a tolerably good description of failure, on a smaller project far more committed to this idea. Can we declare this historic now? Septentrionalis PMAnderson 19:54, 3 January 2009 (UTC)

If you can persuade a sufficient number of the 96 people who patently don't share your opinion that this is sufficient new insight for them to completely reverse their position, then yes we can. Work within the system, please. Happy‑melon 19:59, 3 January 2009 (UTC)

How many of that 96 (and which 96 are we talking about?) have any idea that this "successful implementation" is a scandalous failure? Septentrionalis PMAnderson 21:37, 3 January 2009 (UTC)

It's 106 now. Since I assume they all read the relevant discussions surrounding this topic before declaring their support, they're all familiar with exactly what's going on at de.wiki. It's not exactly a secret. Happy‑melon 21:51, 3 January 2009 (UTC)

You do? What WP have you been editing? In most polls, the !votes are based on the question and sometimes the few voices expressed immediately before their own; it is the exceptional !vote which is based on the entire poll, much less any outside information, like that in another section of the same page. This naïveté may explain why Happy melon insists so vigorously on an idea which assumes a level of activity incompatible with experience and with human nature. Septentrionalis PMAnderson 22:06, 3 January 2009 (UTC)

I don't want a 3 week backlog. A reviewer bot that sights revisions (that don't contain anything on a special blacklist) after 48 hours would be a good idea. That way, a few pieces of vandalism would get through, but it would be a lot less than now. Dendodge Talk^Contribs 22:16, 3 January 2009 (UTC)

The moment you start talking about bots and flagged revisions, you've completely undermined the ostensible purpose of flagged revisions. –Outriggr § 07:57, 4 January 2009 (UTC)

This thread is an example of misunderstanding of the statistics from German Wikipedia. Majority of edtis on de.wiki are sighted without minutes or hours and never show up in the list of unsighted pages. 1 week median or 21 days maximum only represent the average "ages" of those few revisions that were not sighted quickly and ended up in the list. So backlogs in German Wikipedia are not so awful as they seem. Ruslik (talk) 09:06, 4 January 2009 (UTC)

Please read median. The report may be false, but it says that 50% of sightings take place a week or more after the last one; that is not "few". Septentrionalis PMAnderson 17:19, 4 January 2009 (UTC)

the median time articles edited by non-sighters wait is unfortunately currently not recorded, but if of course lower - most edits are checked be RC patrol, watchlists or wikiprojects/portals within minutes to hours. The time articles wait is not known. 1 week is median of the waiting time of the articles listed there (in the list of unreviewed articles). All this thread is based on the misinterpretation of the statistics. Ruslik (talk) 17:52, 4 January 2009 (UTC)

I have just asked for, and received, "Sichter" rights on de.wiki, which means I can now see the contents of de:Spezial:Seiten mit ungesichteten Versionen, the list of all articles with unreviewed edits. The very first thing I notice is that the top article, that is, the article that has been waiting the longest for review, is marked as being "Raketengrundgleichung (-232) (review) (20 days) [sighted] (15 users watching)" (my emphasis). I believe there has been a mistranslation. I will endeavour to determine the actual median as we understand the term. Happy‑melon 22:45, 5 January 2009 (UTC)

There are 11,983 articles on de.wiki currently with unreviewed versions. The 5,992^nd article is de:Tauhid-Moschee, the oldest unreviewed edit being at 19:35, 1 January 2009 (UTC); four days and three hours ago. Although not optimal, this seems to me a much more reasonable length of time. Happy‑melon 23:01, 5 January 2009 (UTC)

I don't think that is the median time before an unsighted edit is sighted. Your sample consists of articles that are currently unsighted. This sample is biased towards edits that take long to sight, so it overestimates the mean time before an unsighted edit is sighted. A better sample would be to take the last (say) 10000 unsighted edits. -- Jitse Niesen (talk) 00:27, 6 January 2009 (UTC)

Perhaps an example helps to explain my point. Suppose that 90% of the unsighted edits take a minute before they are sighted and that 10% take a month. Then the median time before an unsighted edit is sighted is a minute. However, at any given moment almost all the articles that appear on the list of articles with unreviewed versions come from the 10%, so the median time for the articles on the list is much longer. -- Jitse Niesen (talk) 00:35, 6 January 2009 (UTC)

That's correct, an excellent point. So the median time for an individual edit to be sighted is in fact lower, probably considerably lower. Happy‑melon 11:03, 6 January 2009 (UTC)

Thanks Jitse. This is exactly the point that I wanted to make with my comments above. The real median time is significantly lower. Ruslik (talk) 12:18, 6 January 2009 (UTC)

3 weeks is the maximum time on DE. The mean wait (which is actually useful) is 6 days per aka's tool. We are working on getting that down too. Aaron Schulz 14:25, 6 January 2009 (UTC)

Although presumably that mean calculation is also based on data from de:Spezial:Seiten mit ungesichteten Versionen, so the same issues would apply. Either way, the numbers are far lower than the 21 days intially believed. Happy‑melon 15:27, 6 January 2009 (UTC)

I'm not sure the numbers have a downtrend, the numbers on articles to Sight are up de:Wikipedia Diskussion:Gesichtete Versionen#Meinungsbild Mion (talk) 21:25, 8 January 2009 (UTC)

I just removed this statement from the project page. Per the above discussion, it is false, and moreover it seems to be directly influencing the voting in the current poll for the trial implementation. To summarise the above points:

1. The German report said that median time for waiting is "about a week", contrary to the statement by PM Anderson above that it is 21 days which was also stated on the project page. The de:wp is aiming (apparently successfully) to keep the maximum wait to less than 21 days.
2. As also pointed out in the German report, but not very easily understood, it is crucial to realise that the mean or median age for currently-unflagged edits is much longer than the mean or median time for an edit to be flagged. This confusion is a classic blunder by statistical novices. The reason is that a list of unflagged edits is not a fair sample of all edits: it is obviously and strongly biassed towards edits which wait for a long time before flagging. For instance, if most edits are flagged immediately (because made by editors or bots with flagging rights) then the median time for flagging is zero, but the median for unflagged pages is obviously finite. (I can write down the formulae to prove this if you like).

What we really would like to know is the median time an edit by someone without flagging rights goes before being flagged (discounting edits that are eventually reverted rather than flagged, because it doesn't matter much how long this takes). This information is there in the logs if anyone on de:wp feels like extracting it. PaddyLeahy (talk) 11:48, 11 January 2009 (UTC)

Up to date and long time statistics can be found under http://de.wikipedia.org/wiki/Benutzer:ParaDox/Tabelle/noch_zu_sichtende_Artikel. The median you mention is the green curve labeled T4 in the last graph. Otherwise, we are currently at max waiting time around 16 days, still falling. --P. Birken (talk) 21:02, 20 January 2009 (UTC)

Median-time till sighting (time between editing and sighting; graph T4) is several hours declining in tendency. --Septembermorgen (talk) 15:18, 21 January 2009 (UTC)

"It's 106 now. Since I assume they all read the relevant discussions surrounding this topic before declaring their support,"

That's a hell of an assumption. And what's 106 users to the userbase of Wikipedia, miniscule? MikeLieman (talk) 21:49, 25 January 2009 (UTC)

Isn't the German project trying to implement flagged revs on all of their articles? Of course that will take a long time, and that was a silly move on their part. If we only implement it on articles that would otherwise have been protected, the back log will be 1% of the German wiki, would be easily manageable. --Arctic Gnome (talk • contribs) 22:00, 25 January 2009 (UTC)

Happy‑melon of course mentions only de.wiki. What about Polish Wikipedia where it works perfectly ? :). He hasn't say a word 'bout this, Sir Lothar (talk) 19:46, 19 September 2009 (UTC)

Speaking my piece: The "This is bull" report

What the hell is the world coming to?
::-Jackie Gleason in Smokey and the Bandit

...or should I say, "What the hell is Wikipedia coming to?". Being a big supporter of freedom and Wikipedia, I think this quote proves what is going wrong here. We are implementing the big brother process on Wikipedia, which is supposed to be free for anyone to write! We are going farther and farther away from purpose here!! If you are reading this, look at your upper left corner on your screen, under the globe. It says "Wikipedia, The Free Encyclopedia". Do we really think we are that anymore? I cannot see how people still think we are, especially if we are asking for something so communist to enter the society and project we work on as a global community! This is why I have detailed my piece here as "bull", because that is my belief of Flagged Revisions. Here are many reasons and explanations to why we should not go with the track we are going.

1. Flagged revisions are not the right thing for the eminent backlogs that we already sustain. Over the past few weeks, I have been watching on Wikipedia and off-Wikipedia people talking. Several have complained that important processes, such as the Suspected sockpuppets area, or Good article nominations. I have brought these up, because they are critical areas in maintaining this project's biggest purpose: writing articles and being the encyclopedia we are supposed to be. Doing this, will only cause massive backlogs everywhere. Do we need these backlogs? One word: No.

2. Flagged revisions just adds more bureaucracy and monarchy, along with more anarchy, to Wikipedia. Nobody wants any one of these three words alone. We are a democracy. We elected and do the best work with freedom of expression, interest, media, opinion, and decision. We don't want to be a dictatorship or communistic society that limits what they can actually do to improve Wikipedia. What the in world are we thinking??? Did communism work in the Soviet Union? Do you see Stalin or Lenin and them running Europe? No, because the democracy that is America helped stop it. We do not want to go through this, do we? It is a ridiculous thought.

3. How is Jimbo Wales god? He isn't. Not even on Wikipedia. Wikipedia has no god, Wikipedia has no dictator, Wikipedia has no Queen Elizabeth. Jimbo is nothing but a say in what goes on in this community. You can ban me for this if you'd like, but, Jimbo Wales is not our decision maker. He will never be. We, as people, are supposed to make the decisions of what is to happen on our site! Jimbo may be the head of a great foundation, that has beliefs that I very much agree with. I very much disagree by what some people have shown in regards to this debate and prior debates. I have seen some people support things, a lot of which Jimbo himself has voted support or oppose on, under the theory that If Jimbo supports/opposes it, I support/oppose it as well. Is this a way of mind, or just people giving in to a person, who on Wikipedia, has little power? As far as I am concerned, if we are to be listening to anybody's important decisions, it should be the Arbitration Committee's. They often make the final decision on what happens in disputes. We should not be making decisions only because of Jimbo. He is not god, he is not the president, he is not a supreme court judge. He is a public orator, and spiritual leader, not our boss.

To conclude, there are three major problems. They are: 1) Backlogs, 2) Communistic/Big brother way of thinking, and 3) We look up to Jimbo for way too much. We need to think what's right for us. We are not communisitic. We are not Stalin, Lennon, Hitler, or the Egyptian emperors. Jimbo is not god, Jimbo is not President Bush and/or Prime Minister Brown, Jimbo is not emperor. Jimbo, is basically a spiritual figure, such as the Dalai Lama, Buddha or Confucious. We do not follow "big brother" beliefs. We have the 1st amendment rights we are given and we should use them correctly. In retrospect, we are running as an American democracy, and that is HOW IT SHOULD BE. I will end on a quote.

• ...There is pride in every American heart and its time we stand and say....
• ...That I am proud to be an American, where at least I know I am free...
• ...And I won't forget the men who died, who gave that right to me...
• ...And I gladly stand up...
• ...Next to you and defend her still today...
• ...Cause there ain't no doubt I love this land...
• ...God bless the U.S.A....

  -Lee Greenwood in God Bless The USA (1984)

(Note: If you want to bring up any issue about this report, or want to call me out, bring it to my talk page.Mitch32^{(Go Syracuse)} 22:09, 3 January 2009 (UTC))

Well, since this is a discussion page rather than a place for personal monologues, I'll reply here instead.

We won't know if there's going to be massive backlogs until we try it. Evidence from Wikinews and the German Wikipedia suggests there won't be massive backlogs.

You say this is going to add bureaucracy, monarchy, communism, and anarchy to Wikipedia? I'm pretty sure at least some of those are pretty much impossible to add together. Also, Wikipedia is is not a democracy, its closer to anarchy really.

What does Jimbo have to do with anything? Besides the fact that he supports this, he has basically nothing to do with this.

The First Amendment does not apply on Wikipedia.

Mr. Z-man 22:49, 3 January 2009 (UTC)

Mitch, while I don't really agree with your arguments, I think your concern is well-justified. Flagged revisions are potentially dangerous for Wikipedia. They could move us closer to Citizendium, which is a bad thing. Citizendium is going to bomb - it is probably bombing already. Sanger does not believe in the brute force of 150 thousand active editors and 200 thousand edits per day (which is Wikipedia at the moment) - he appears to think that quality and volume (an encyclopedia has to have both) will come from "experts". Of course, he is mistaken. Mark those two numbers: if they start do go down, Wikipedia goes down with them, flagged revisions or not. Freedom and equality (or meritocracy, if you will) are not just values in themselves, they made Wikipedia a success; lack of freedom and equality will make Citizendium a failure. We are playing with fire here. Still, I voted "Reluctant support" just out of curiosity - I want to see it in action, only then I can draw some solid conclusions. It's early to get worked up over this. GregorB (talk) 01:27, 6 January 2009 (UTC)

Mitch, Jimbo Wales is like Queen Elizabeth II. The only difference is that Jimbo can make big decisions about how Wikipedia is run, whereas the Queen has no say on how England, Great Britain or the Commonwealth is run. --Joshua Issac (talk) 14:56, 11 January 2009 (UTC)

We'd be a hell of a lot better off with Our Liz, in my opinion. DuncanHill (talk) 00:21, 17 January 2009 (UTC)

• Actually, recruiting Queen Elizabeth or King Juan Carlos will be an enormous asset. Not some Hollywood plastic smile, but a real royalty with thousand-year-long-pedigree. Won't hurt fundraising either. NVO (talk) 19:52, 17 January 2009 (UTC)

what about POV and misleading refs and other content problems

I think one of my biggest problems with this sighting/flagging thing is that it only deals with obvious vandalism. The impression you get is that once someone with sighting privileges looks at and approves an article, that it is somehow more trustworthy. But that is very misleading. These sighters only do what the totally uninformed reader is already very well able to do: that is, they don't think that a page replaced by the word penis is real content. But the subtler content issues, the sneaky POV stuff, the refs that don't actually support an assertion, those things that would fool an uninformed reader into believing something that may not be true, they also fool the sighters. Sighters are basically uninformed about the subject of the article, and with the mass of edits they have to approve, there is no way to ask them to be informed. If what we are looking for is a way to have casual readers be more able to trust wikipedia, then obvious vandalism is not the problem and flagged revisions won't do a thing. There are a ton of anti-vandalism tools out there, what we need are some better anti-POV-pusher tools. xschm (talk) 20:49, 6 January 2009 (UTC)

Did I miss the memo about WP changing from a full volunteer effort? ♫ Melodia Chaconne ♫ (talk) 21:53, 6 January 2009 (UTC)

It's certainly true that FlaggedRevisions is not the panacea to all our problems with destructive editing. That doesn't mean that it's not a good idea. We already have ten thousand tools to combat subtle errors such as those you note. They're called editors, and currently far too many of them spend their entire wiki-lives reverting trivial vandalism. Every tool we create is intended to deal with a little bit more of that casual vandalism, to give the humans the chance to do the really difficult work. FlaggedRevisions is, in one sense, just another anti-vandalism tool. It is likely to be that much better an anti-vandalism tool, however, because it works in completely the opposite way to most. Most of our anti-vandalism tools, from Twinkle to CheckUser to ClueBot, are designed as 'force multipliers': they amplify one particular user's ability to deal with casual vandalism so that one positive editor can 'ward off' many vandals. They are ultimately tools that involve only one person. FlaggedRevisions, on the other hand, is an attempt to spread the workload, to involve all our established editors in combatting casual vandalism. The overwhelming majority of editors don't get involved in 'dedicated' anti-vandalism patrol because that just doesn't interest them; but when they see an article on their watchlist that looks like it might have been vandalised, they go check it out and revert it if it has. FlaggedRevisions acts as a 'force multiplier' for all users, turning everyone into active anti-vandals. Every time they sight an edit, they are making a positive statement about the quality of the encyclopedia, not just 'restoring the status quo' by reverting vandalism. As such, yes, it is another tool against casual vandalism, and you are quite right that it will not solve our deeper issues. But by freeing up time and energy of humans to work on those issues, it contributes indirectly to progress in that area as well. Happy‑melon 22:08, 6 January 2009 (UTC)

The more things we ask flaggers to check for, the slower they will be able to work and the longer it will take to get revisions approved. This will result in larger backlogs and will be a bigger deterrent to new and unregistered editors. Hut 8.5 22:16, 6 January 2009 (UTC)

I guess what I am saying is that sighters are not making a positive statement about the quality of the encyclopedia. All they will be saying (all they can say) is that they didn't notice any vandalism. Any wikipedia editor who notices vandalism will revert it already. What we don't need is positive statements about the same content that still contains the same level of dubiousness that it always did (and probably always will). Flagging is just just going to create busy work. It is spreading the work that the force multipliers are now doing back out among people who will have to do it piece by piece by hand. Vandalism is the cost of openness and currently openness is winning the war. It is very rare to go to a page randomly and find it vandalized. I don't understand what the big concern is. xschm (talk) 22:49, 6 January 2009 (UTC)

I have added proposed Trial 11 to see if being a Reviewer takes on any significance other than being a vandalism/nonsense/libel(?) checker. I am concerned that removing someone's Reviewer status will become 'Block Light', and that it will become the culture that as long as pages in the 'public space' are not being protected due to edit warring/POV pushing, everything is OK, or that consensus among Reviewers (rather than 'untrusted' users, registered or unregistered) becomes more important in settling content disputes in the 'public space'. MickMacNee (talk) 23:57, 6 January 2009 (UTC)

Limiting the revisions to flag for large-scale implementations

A possibility for large-scale implementations would be to limit the number of edits to review, not only by limiting the number of pages with flagged revisions, but also by limiting the number of revisions inducing a stable/draft divergence for individual pages. The soft line is: none, the hard line is: all, there are mediums. For example, an automated process could check if an edit is likely to be vandalism or not, based on the latest flagged revision and successive edits. If an edit is identified as potential vandalism, it'll be 'moved' to the draft page, and the latest revision that has not been identified as potential vandalism is set as the stable version. This would require some sort of filtering of edit, function that can be provided by the abuse filter. This would require a close collaboration between the two extensions. Examples of rules for the filter could be "redirect to non-existent article", "blank", "redirect an article which is featured, or linked from main page, etc", "mass addition", "mass removal", and other rules for typical vandalism that already use anti-vandalism bots. But those could be more inclusive, since the edit is not reverted, but deferred to the analyze of a trusted user. This would require another user right, since it is also aimed to prevent vandalism by autoconfirmed users and edits to flag would be limited and in vast majority vandalism. This would prevent readers from seeing most vandalism, that is generally reverted within minutes, but would have no effect on the vast majority of edits. This is compatible with the semi-protection implementation, the only change will be that in order to flag an edit on a 'semi-flagged' page that has been identified as potential vandalism, it requires the additional user right. If we want, we could have the option to flag all edits of a specific page, either using a filter or through direct configuration of a page, but we can also disable it. We could also use filters for specific categories, for example Category:Living people. Cenarium (Talk) 14:24, 8 January 2009 (UTC)

I think it is slightly unhelpful to consider FlaggedRevisions as working on anything other than pure versions: talking about "moving edits" or "number of revisions inducing...". FlagedRevs works on versions, changing that would be a large and fundamental shift. That said, I think your general idea here is a very good suggestion: that we can adopt more than one position between "obvious vandalism" (ClueBot reverts or abuse filter disallows) and "obviously positive" (autoreviewed). Integration between the activities of the AbuseFilter and the actions of FlaggedRevisions can only be a positive development, because AbuseFilter is the exact opposite: it works on edits and nothing else. Let each do that which it is best at, and we'll all benefit. Happy‑melon 17:40, 8 January 2009 (UTC)

That was essentially expressions, the two combined would have this kind of effects. It would be positive to have more liberty for versioning, and using the abuse filter to check edits and then base versioning on it could be worthwhile. That would require much development and tests on other wikis. Is the abuse filter available on en.labs ? Cenarium (Talk) 19:58, 8 January 2009 (UTC)

Sorry, perhaps that was a little harsh; I do agree that the result of a FLR/AbFil combination would be very powerful. I don't think AbuseFilter is available on any wikimedia sites as yet, but Werdna has recently been contracted by the Foundation to polish it off, so I'm sure they'd be amenable to firing it up either there or on test.wiki. While we're at it, an interwiki to en.labs wouldn't go amiss :D Happy‑melon 22:10, 8 January 2009 (UTC)

I think it is a very interesting proposal! It should be seriously considered. Ruslik (talk) 22:22, 8 January 2009 (UTC)

See also Wikipedia talk:Flagged revisions/Trial#Example where Flagged revisons would have helped, why this proposal isn't working. Mion (talk) 10:43, 12 January 2009 (UTC)

You have not shown that this proposal isn't working. The abuse filter has two choices when confronted to an edit: warn user or disallow, deferring the edit to a trusted user is another, intermediary response. Cenarium (Talk) 18:42, 15 January 2009 (UTC)

Multi-level sighting options

Summary: Let me be an Editor; just don't force me to sight when I edit.

I tried the test wiki a couple of days ago, and I was surprised to not find a checkbox that I could check or uncheck to not sight an edit I made. There was a third checkbox on the edit page; but it didn't seem to do anything.

So I suggest a "Sight this edit" checkbox on all edit pages presented to those with Editor status.

Furthermore, to combat the "objectors" problem in Sebastian's experience at the German Wikipedia, I suggest two radio buttons on the Editing preferences tab. The controls would look like:

By default, sight:

• All edits
• Edits to sighted versions

The "All edits: option would make "Sight this edit" checked by default in all cases. The "Edits to sighted versions" option would instead make "Sight this edit" checked only when editing an article that was already sighted. If editing an unsighted article, the checkbox would be unchecked by default. This would prevent the "forced labor" problem, as an editor could elect to only sight his/her own changes by default.

-- Ken g6 (talk) 19:32, 9 January 2009 (UTC)

Worth noticing

[4]. Seems like it is going ahead. DuncanHill (talk) 00:33, 17 January 2009 (UTC)

Is this appropriate?

Is it really appropriate to have that quote from Jimbo Wales in an alert box at the top of this page? Especially the point about everything other than his opinion being fear, uncertainty and doubt? How is this not pov-pushing? Kolindigo (talk) 19:44, 17 January 2009 (UTC)

Not in the least appropriate. DuncanHill (talk) 19:49, 17 January 2009 (UTC)

Why not? Each of the three words is applicable; the negative connotation of their combination is used by both parties. Don't overestimate the weight of this yellow box. NVO (talk) 19:54, 17 January 2009 (UTC)

There is no counter to it from any of Wikipedia's other sole co-founders or godkings. DuncanHill (talk) 19:56, 17 January 2009 (UTC)

It is also untrue. Jimbo is talking about his personal preference for flagged revs, not necessarily the way it would be implemented. A lot of the backers of flagged revs seem to want it on the whole encyclopedia, not just as a replacement for (lower level of) protection. Most of the proposed trials don't match jimbo's description. xschm (talk) 18:26, 18 January 2009 (UTC)

Why flagged revisions is essential to fixing the problems of scale and reliability

Wikipedia is and will remain "the encyclopedia" that anyone can edit. However, this feature creates a layering, a layering that has for a long time been necessary but not achievable without this feature. Without flagged revisions, yes, unless an article is protected,which stops nearly all editing or severely inhibits it, there must be constant defense not only against vandalism, but also against the insertion of unreliable information or the removal of text accepted by consensus. Immediate editing by anyone is in conflict with reliability, unless we could guarantee that all edits were immediately reviewed. That happens with highly controversial articles, but not with much of article space. And with controversial articles, if they are in frequent flux, we don't know what version a casual reader will see.

So how can we have immediate editing by anyone and reliability? It's simple: immediate editing is confined to a layer below the top-level default layer. Anyone may propose an edit. In standard deliberative process, it was realized long ago that if a motion couldn't find a second, it was a waste of time to debate it. If we have a publisher which automatically, without review, publishes what someone writes, we'd consider that tantamount to "self-publishing." We have been that publisher, which is one reason why we are so attractive to linkspammers and POV-pushers and vandals.

With a bit more sophistication in the structure, we could actually become a truly reliable source, ourselves; but we, of course, still would not want to rely on that except in uncontroversial ways. As a reader, though, I expect an encyclopedia to be reliable. Wikipedia has guidelines and policies that require reliable sources, but the enforcement of this and the unevenness of our consensus process for applying and interpreting these has made reliability an unrealized ideal.

If there is substantial delay in sighting revisions, this means that the revisions haven't been accepted by anyone with the easy-to-obtain privilege. Obviously, such edits can't be considered to be reliable, no matter who made them.

There is an issue of responsibility that has been raised with BLPs and libel. If I sight a revision that creates libel, I have joined the original editor in personal liability, whereas with the present system, only the original editor is liable, there is no requirement on anyone that the libel be removed, until and unless Wikipedia is contacted by the potential plaintiff. What happens with flagged revisions is that someone else must be willing to assume personal responsibility for that edit, as if they had made it themselves. With "POV-pushing edits" that involve policy violations, we now must have two editors who risk sanctions, not one. Is this a restriction on editorial freedom? I think not; in fact, damage from "POV-pushing" edits is greatly lessened and is confined to the labor of sighting them, instead of creating a problem with readers. My sense is that Wikipedia can become, to some degree, more tolerant and conflict will be more focused on disputes between those with sighting privileges; if we see "tag-team" sighting, if you'll approve mine I'll approve yours, we will have more focused debates and, if necessary, sanctions that don't bite newcomers who stumble into a minefield, just because they take us as our advertising claims: "anyone can edit."

Sighting a revision should not merely be a confirmation that it isn't vandalism. It should be the sighter taking responsibility for the edit as if it were his or her own, which would require verifying sources, etc, unless the sighter is so convinced that an editor is reliable (and sources are difficult to verify) that the sighter is, indeed, willing to assume reliability. Everyone makes mistakes, but if I think that an editor is reliable in this way, it means that I consider the probability of error to be so low that it matches, more or less, my own error rate or is even better. Nobody is obligated to sight a revision, but there is obviously a very good reason why we confine sighting to experienced editors. It's risky. And it is valuable and essential, so doing "sighting patrrol," done well, will be far more of a service to the project than is current vandalism patrol, which is like falling off a log, an easy video game to play in odd moments. Sighting would ordinarily still be easier than writing, because the sources should be laid out and a draft text put together. We need to work out certain details.... thus we really need a test of the concept, i.e., the present proposal. --Abd (talk) 17:21, 18 January 2009 (UTC)

If sighting an edit makes me just as responsible and liable as the original editor, I shall refuse to sight any edits. DuncanHill (talk) 17:42, 18 January 2009 (UTC)

I want "sighting" to be a lightweight check for obvious badness; it should merely be a confirmation that it isn't vandalism. The very name "sighting" implies simply that somebody has looked at ("had sight of") the version or the diff under consideration. I believe that there's also scope for a more heavyweight "reviewing" process, but please don't use the same term for both concepts. —AlanBarrett (talk) 20:27, 18 January 2009 (UTC)

Flagged revisions allows for "lightweight" sighting and "deep validation" sighting. But in either case, I'd suggest, sighting an edit does make the sighting editor responsible. Suppose an edit is a BLP violation. If you sight it, it may then escape further notice. I'd say that while "lightweight" sighting may be of some value, it's only valuable for vandalism detection; vandalism patrol currently involves a high inefficiency, as many editors may look at a few edits, and may miss others. Having a sighted flag that is used this way -- the edit isn't obvious vandalism or obvious BLP violation -- would be worthwhile, but wouldn't greatly increase reliability, outside of more quickly and reliably identifying vandalism. The fact is that any reader can also detect vandalism. "Oh, I see that the politician I was considering voting for was caught having sex with a cow. Says so on Wikipedia, must be true!" More likely, if it wasn't sourced and verifiable, the reader, as an IP editor if not registered, might remove it. I've seen a fair amount of vandalism reversion from IP editors.... It will be important exactly how flagged revisions is implemented, and there certainly could be layers of implementation.

As to being unwilling to stand behind a sighting of an edit, to be responsible for it, if this is frightening, so too should any editing be frightening. If you check an edit out, look at the source cited, looks good, you'd be pretty safe, even if it did turn out that something was awry: you'd have "deniability." I.e., it looked reasonable, and reasonable people would agree that, even if you were wrong, you weren't reckless. With a sighting, you have now two editors standing behind an edit, so if you've done due diligence (the level that's due in connnection with the type of sighting that is established), you'd be quite safe. However, I'm not concerned about editors who don't want to sight, who just want to edit articles. That's fine! Not everyone needs to do this kind of work. I'm also unconcerned about backlog. As long as anyone can see *all* the editing, not just the sighted edits, it's an improvement, not a step backward. --Abd (talk) 01:54, 19 January 2009 (UTC)

If I revert obvious vandalism, am I then "sighting" the previous version (i.e. the one I have reverted back to)? DuncanHill (talk) 02:06, 19 January 2009 (UTC)

No. --Abd (talk) 03:00, 19 January 2009 (UTC)

It's an excellent proposal. It simply calls for removal of 99% of existing content and reducing it to the body of actively edited and actively watched texts. "Substantial delay in sighting revisions" - if today nobody cares to watch/edit/reference the bulk of wiki articles, why would they go for "sighting", whatever it means?. NVO (talk) 03:35, 19 January 2009 (UTC)

Why assume such a singularly stupid method of implementing it? One of the problems is that Wikipedia creates work and rework and rework and more rework until we are sick of it. Some of the work that now goes into rolling the boulder back up the hill would go, I predict, into article validation. Who knows, we might even attract some experts, if we stop insulting and blocking them. --Abd (talk) 05:17, 19 January 2009 (UTC)

Most of the work prevented is by making it less attractive to anons to make an edit (-50%) and about attracting new users, that is going down at an abnormal speed (User:Hut 8.5/German editing stats). Mion (talk) 13:27, 19 January 2009 (UTC)

Why? The text above says "If there is substantial delay in sighting revisions, this means that the revisions haven't been accepted ... can't be considered to be reliable, no matter who made them." This means that these revisions must be deleted, doesn't it? NVO (talk) 17:46, 19 January 2009 (UTC)

To quote WP:V; "Wikipedia is not a reliable source." FR won't make it a reliable source; most of our serious problems are caused by the incompetence or malice of long-established accounts. "[Politician X] is a poopyhead" is a minor nuisance, which any sane reader will ignore for the minutes before RCP catches it, and that is what the advocates of FR claim it can do. Septentrionalis PMAnderson 14:42, 26 January 2009 (UTC)

It won't be as difficult to 'sight' new edits to articles as people think because the actual number of new edits will plummet. The internet is an immediate medium and Wikipedia's unique selling point is that anyone can edit it and see their work up there immediately. Remove the USP and you destroy the secret of Wikipedia's success. Compare a comment thread on a website which is retrospectively moderated (lively and combative) against one for which comments require approval (dead as a doornail). The numbers of new edits and editors are falling anyway, and this is going to turn a decline into a collapse.

Adding a layer of bureaucracy won't improve Wikipedia's reputation for veracity because it's used as a quick reference for casual users and always will be, anyone wanting expert opinion is always going to seek it elsewhere. This has been an incredibly successful project because of the vast amount of unpaid work done by volunteers and casual users whose only reward has been the validation of seeing their additions up there for all to see straight away. Take away that carrot and the bunnies aren't going to be frolicking in this field any more.

The suggestion below that a 'sighted' version of any article be available to users is a good one, if people are determined to go ahead with this, but it shouldn't be the default version that first comes to view. Seriously, you're going to wreck this place if this goes ahead. You're trying to turn yourselves into the Encyclopaedia Britannica in an effort to claim its reputation for reliability but you're actually going to transform yourself into a second rate version of the thing you defeated by being a first rate wikipedia. Nick mallory (talk) 01:13, 27 January 2009 (UTC)

Announcement from Jimbo Wales

See [5]. DuncanHill (talk) 23:04, 21 January 2009 (UTC)

A light weight alternative

Instead of making the flagged version the default view, put an icon or tab on each page that would let a reader see the flagged version with a diff from the current version. Add an opt in preference for those who wish to see the flagged version by default. We would still be "the encyclopedia anyone can edit," but readers could quickly check and judge for themselves whether recent changes are likely to be valid. Most vandalism, in my long experience, is quite obvious in a diff. For the rare exceptions, readers would have to follow up on any refs supplied. Add a simple way for trusted editors to update the sighting after checking a diff and things should work smoothly without any 21 day limits. --agr (talk) 02:46, 22 January 2009 (UTC)

- - - - - - - - I don't contribute to wikipedia very often, and more than half the data that i contribute is ultimately removed usually because of inadquate references (which is annoying when the source document is simply not in any library system), but overall i think the system works fairly well as it stands.

But if vandalism is truly such a big issue then this lightweight alternative seems a viable option. - - - - - - - - —Preceding unsigned comment added by 203.214.83.44 (talk) 00:45, 27 January 2009 (UTC)

Virtual domain alternative

As another alternative, I suggest a different 'virtual domain name' for a Wikipedia site that shows the flagged revision by default. i.e. new.wiki.riteme.site would show all new edits,

reviewed.wiki.riteme.site would show the flagged version.

wiki.riteme.site would go to a site asking the visitor to choose which version of the article they want to see. Leave the choice up to the viewer, I suppose.

The option should only be presented for articles that have a reviewed version. --Mysidia (talk)

It should be presented for all articles but with a banner of "No reviewed version for this article" for non-reviewed articles. That way people could make it their default site and not be switching between the two. In any case... I think it'd be hard to get this to happen... gren グレン 07:18, 26 January 2009 (UTC)

Request for arbitration

I've filed a case to ask the arbcom to look into Jimbo's announcement that flagged revisions will be turned on, and whether he has the support of the community/arbitration committee to do so. Sceptre ^(talk) 15:59, 22 January 2009 (UTC)

Asking a bureaucrat to look at it might be a better idea. They at least have some mandate for judging consensus in discussions. Hut 8.5 16:13, 22 January 2009 (UTC)

Yes. In fact, it would've been better for a 'crat to declare consensus, or lack of. Consensus cannot be judged by Jimbo impartially as he is a known major proponent of flagged revisions. However, as Jimbo has declared it by fiat, the Arbitration Committee are the only people who can overturn it. Sceptre ^(talk) 16:18, 22 January 2009 (UTC)

Although, mind you, Brion also is allowed to refuse to implement it. And he may well do so, as the poll falls below his requested consensus. This may make it a moot point, but there are issues behind the closing that need to be addressed to. Like whether Jimbo enjoys immunity from our guidelines and policies or not. Sceptre ^(talk) 16:23, 22 January 2009 (UTC)

I don't think this is really in the scope of ArbCom. It may be true they can override certain rulings, but there's nothing that says they can prevent a founder decision someone disagrees with. It's a big can of worms to open, to say someone can bring to ArbmCon any one action someone disagrees with. --Mysidia (talk)

It ought to be in ArbCom's scope; if not, who reviews Jimbo's actions? The real world has had quite enough of prominent persons who act without review, prompted by idiot analyses in the Washington Post (if not the Washington Times); I don't see why Wikipedia should take up the practice. Septentrionalis PMAnderson 00:45, 26 January 2009 (UTC)

The community, perhaps? It could be a little different, I suppose, if the community overwhelmingly objected to Jimbo's actions on this matter, and Jimbo refused to budge, and further escalated matters. But Jimbo's decision is essentially a policy matter, and ArbCom's reason for existing doesn't have anything to do with setting policies.

Arbitration is supposed to be a last resort during a dispute process, when mediation, discussion, and all other possible measures have failed. There is no evidence that there has been any attempt to the mediate the matter, or for that matter, that there is even truly evidence of a dispute that needs to be settled. --Mysidia (talk)

The Kennedy test

Has anybody else actually looked at what happened at Ted Kennedy after his collapse on Tuesday? The edits which involve a claim of his death are listed at Talk:Ted Kennedy#What happened.

This is what happened, and the likely effect of FR if it had been in effect on the article at the time of an unexpected event. The first edit on the subject was at 19:44 UTC

1. An anon inserted Kennedy's death at 19:50; another anon took it out at 19:51. This would not have made to the sighted version under FR; but it would have taken longer to remove from the unsighted text, because no anon would have seen it.
2. Kennedy's death date was added to text by Newbie A (a vandal) at 19:59
3. Before this was removed, Anon B added "January 20, 2009" as a free-standing paragraph.
   • An admin reverted this to Newbie A's edit. Under FR, this would have sighted the vandalism. Anon C removed Newbie A's edit at 20:03; this would not have sufficied under FR.
4. Newbie A altered the death date in the first line at 20:02, and this was removed at 20:04 by an established account. FR would have kept this out of sighted version.
5. An established account added Kennedy's death at still another place at 20:02, but noted no confirmation in the edit summary. Under FR, this would probably have been flagged; it was removed at 20:05.
6. another pair of anons put in a claim of death, and took it out again immediately, just before the article was semi-protected at 20:03.
7. The death date was restored by an established account at 20:06, and removed at 20:08. Under FR, this would have been flagged. (The edit summary on the insertion was rvv, so it may be a confusion as to which way he was editing, or like #5, a confusion on the facts.)

Out of these seven, three would have made it into the sighted text. I think the case that FR would have prevented this, as the Washington Post praters claim, is open to much doubt. Septentrionalis PMAnderson 00:45, 26 January 2009 (UTC)

Thank you for the detailed analysis; it certainly weakens the claim that the false claims were 100% preventable. Personally I'm not averse to a big test as long as there's a sunset clause that's a short time away (like, two weeks). Tempshill (talk) 04:02, 26 January 2009 (UTC)

Thanks for the analysis, although I'm not sure I can agree with you on your bullet to point 3. When the admin reverted the edit, his edit would not have been autosighted as it was made on top of unsighted edits. In order to make the changes visible, he would have needed to review the article manually, whereupon he would have seen a diff of all the changes since the last sighted version, including the changes by Newbie A. As an unsourced and contentious claim, it would certainly have been noticed and in all likelihood removed. But there is no risk that the addition of the death-date would have been 'accidentally' sighted because that's not how the system works. Happy‑melon 08:56, 26 January 2009 (UTC)

The page was tagged with the "current events" template, so visitors should have been aware that they shouldn't rely on recent information. I understand that sticking to the facts is important but minor mistakes (minor because of the template) are in my opinion an acceptable price to pay for the ability to edit an encyclopedia and know that world sees your work immediately, not after some bureaucratic process you don't understand at all. I very much prefer the current system. Pietrow (talk) 09:28, 27 January 2009 (UTC)

Another analysis

I analysed the edits to the article from the beginning of 2009 up to 22 Jan. Some things I observed with respect to FR:

1. The article is only editted 7 times in 2009 until reports of the seizure trigger a flurry of activity
   1. 2 of those edits are from registered users and make unsourced and unnattributed changes to content in the infobox
   2. none of those edits were malicous, even with 2 edits from an IP (formatting changes)
2. For all the subsequent IP editor contributions until protection is affected (20 Jan, 19:44 - 20:03):
   1. 5 IP editors make 'good' edits, including 1 adding {current} and 1 removing a poor POV/peacock paragraph present since the start of the year, the remaining 3 reverting death claims
   2. The 3 IP users reverting false death claims outnumber the 2 that add it (one reverter being the first user to do so on the article)
   3. 8 other editors are attempting to update the article with info they presumably got from sources, or improve that info added by others, but none of this effort is referenced
   4. 1 IP makes a test edit
   5. No IP editor manages to add any properly sourced info before the article is protected
3. Following semi-protection, in order:
   1. Enigmaman (talk · contribs) rewords Chappaquiddick incident, changes "The Senator swam to safety, but Kopechne died in the car" to "Ted Kennedy swam to safety, leaving Kopechne to die in the car." This lasts from 20:54 to 21:13.
   2. DoenerKebabMitKohl (talk · contribs) adds that Kennedy "and urinated in his trousers" to the lede. This lasts from 01:37 to 01:42 (after a self-revert)
   3. Tatterfly (talk · contribs) adds Category:People with epilepsy to the article. This lasts from 05:53 to 05:58, and 16:01 to 16:12
4. Since the start of the year the article had included the statement "District Attorney Dinis chose not to pursue Kennedy for manslaughter", which was not removed until the last edit on 22 Jan, well after all the attention from the seizure.

I am open minded as to what this may or may not mean, I may or may not come back with some firmer conclusions. I note initially that all edits made by non-trusted users would not have been immediately sightable without modification under WP:BLP, even though their edits are overwhelmingly good intentioned, (and in this small set don't match some of the stats about IP vandalism I have seen) and can even excel in timely and helpfull affirmitive action, if not in content referencing. I also note the difficulties in grading/judging what constitutes a libelous/defamatory edit, or what just makes Wikipedia look bad. I also note that in 'current event' type situations, queuing and bunching together proposed changes has obvious merits in avoiding the mistakes made by all levels of user, even admins. I also note the possible difficulty of judging whether editors, even long term ones, deserve trusted status.

Possibly the most pertinent for any trial, I note that to meet Jimbo's stated claim that FR would have "100% prevented" the press attention this got for Wikipedia stating Kennedy had died for a few minutes, somebody has to make the case for why this unprotected, quiet, edit war free article that had previously laid un-molested for 20 days would have been under FR at all to make that claim true, particularly if the premise is not to be simply that all BLP's/all of Wikipedia, are to be subject to FR.

MickMacNee (talk) 05:22, 26 January 2009 (UTC)

26 January 2009 - Practicality

I would like to address the practicality of flagged revisions.

In my opinion, applying it to all articles or to all new articles would be incredibly counterproductive. I find that a huge number of articles are simply not checked over for long stretches of time. Many articles in the categories I focus on, (independent music in particular) do not receive high editing traffic. Similarly, I focus on copyediting and counter-vandalism, and there are a great many of these things that are ignored and stay in place. Many of the factual errors I have encountered have been in place for long periods of time as well. If we do not already have enough editors checking over these things, the introduction of flagged revisions for new articles would by necessity cause a backlog. I honestly don't think that we can cope with it, particularly if the number of 'trusted editors' is small.

If something really must be done to all Wikipedia pages, I would support semi-protection rather than flagged revisions. I don't like either of them, but semi-protection seems the lesser evil to me. It would cause no administrative backlog, nor would it stifle registered users. It certainly wouldn't stop all vandalism, but that is an unrealistic goal anyway.

I can understand using the flagged revision system in a pragmatic manner to target problem articles in the short term, if that really is necessary. If flagged revisions is implemented at all, we'll need to have the maximum possible number of trusted editors, so I suppose an automatic process would be necessary. A limited revision period would be nice too, so that an ignored edit will not forever be condemned to limbo. Some other people on this page have also raised other suggestions to minimize the harm.

I hope that the Wikipedia community will not be overzealous in their efforts to combat vandalism with this method, because it has the potential to cause a much bigger problem than the one it was meant to solve. BecauseWhy? (talk) 04:01, 26 January 2009 (UTC)

In my opinion, applying it to all articles or to all new articles would be incredibly counterproductive. -- good thing noone's planning that then, huh? ♫ Melodia Chaconne ♫ (talk) 04:36, 26 January 2009 (UTC)

Well, it appears to me that there are people advocating this in various places. For example, over at the BLP protection discussion, there's a whole section for it. Similarly, it appears that a report about the German Wikipedia's implementation has reported the type of problems that I mentioned regarding workload. So, I thought it important to address the issue. Granted, I have been absent from Wikipedia for a while, so I have probably missed things. BecauseWhy? (talk) 05:06, 26 January 2009 (UTC)

On the off chance nobody noticed it...

I was very surprised that searching for "BBC" on this talk page didn't find any matches...

[6] (featured prominently on the main page of the BBC News International website)

Nice going, Jimbo. heh, it's amazing that the same guy who came up with the brilliant idea for Wikipedia also has such a poor vision for how to make the project succeed... --Jaysweet (talk)

I only heard about this "flagged revisions" idea from reading the BBC News Online article. Surely they could've found a better photo of Jimbo... Jolly Ω Janner 22:31, 26 January 2009 (UTC)

Yikes, you're right about the photo. Aside from the fact that it makes him look like some sort of Buddhist rabbi (not that there's anything wrong with that), it makes him look like he has a lot less hair than he actually has. 6SJ7 (talk) 09:40, 27 January 2009 (UTC)

Summary

I really am trying to stay abreast of this proposal, but just cannot do it. Can there be a summary created? A page with "decisions", like "it has been decided..." Something like this? -- Mjquin_id (talk) 19:29, 26 January 2009 (UTC)

==Why?==
 Goal to reduce vandalism; reduce # of articles dropping in quality, etc.
 I never have see a list?
==Status==
Where are we?
 Straw vote taken; passed
 Tech team testing code - expect to be done on xxx date
 tentative implementation of code "merely meaning the code is ready"
==Implementation==
Once the code is in place; several trials have been suggested.
* Where: BLP's, FA's, anything tagged with {{tl|flagged}}
 [[Wikipedia:List of flagged revision trials]]
* How: Any [[WikiProject]] group can add {{flagged}} to any article that they believe should be stabilized or is seeing huge new
traffic. (link to process page)
* When: schedule per group or trial?

===Reviewers===
* People in WikiProjects with over 2 yr or 2000 edits will be granted reviewer
* People may request "here"; link to some request mechanism
* Complaints may be addressed "here"; link to reviewer oversight committee (There will be complaints; justified or not) Probably
should go to an associated WikiProject, then to an admin team, then to the 'crats?

==Metrics==
*#  of vandal edits to FA articles per month (showing number "blocked")
*#  of vandal edits to BLP articles per month (showing number "blocked")
*#  of IP Edits per month to FA articles for each month (include the last year for comparision)

No Flagged revisions!

People who edit need to prevail. An untruth staying online for a while rarely happens, and effects so few, it's not worth all of the downsides. Scifiintel (talk) 21:46, 26 January 2009 (UTC)

The process seems unnecessarily complex and implicitly negative - why not encourage more people to "adopt some articles and look after them" and encouraging monitoring of "recent changes"? What happens with breaking news stories?

Which articles are going to be FR'd and why - some topics are inherently likely to "have their WP articles rearranged" (current head of state versus the one 23 predecessors ago etc); sometimes one corrects a typo without signing in - and given that some recent examples of vandalism etc have involved "obscure topics" or acredited editors going in strange directions etc.

Are we going to end up with several "current WP pages" - for those who are and who are not signed in and for editors etc? (With all the possibilities for confusion thereby arising.)

Not saying that there shouldn't be buffering of text in some cases but consider if there is a simpler way. Jackiespeel (talk) 22:25, 26 January 2009 (UTC)

Where can I vote against this abomination? --IdiotSavant (talk) 09:42, 27 January 2009 (UTC)

Good question IdiotSavant. The idea that we trust some users more than others on content is terrible. Thehalfone (talk) 16:17, 27 January 2009 (UTC)

I heard about this idea after the poll was conducted. I argue against it. It's against what's made Wikipedia the useful resource that it is up till now. If this poll were taken again today, I wonder what the results would be. Then again, the rumor I hear is that Jimbo wants to go ahead, regardless of what users think. vsync (talk) 17:00, 27 January 2009 (UTC)

You have it the wrong way around. The current setup is against what made Wikipedia a useful recousce because we have to have so many pages protected. With flagged revs we'll be able to open up every page to editing again. --Arctic Gnome (talk • contribs) 18:59, 27 January 2009 (UTC)

Read that as "we'll be able to protect every page." Admiral Norton ^(talk) 15:31, 28 January 2009 (UTC)

Why would we want to put flagged revs on every page? I haven't seen any regular wanting it applied everywhere, you're just making a straw man argument. The proposal specifically differentiates itself from the German model by letting us only put flagged revs on the articles that need it. --Arctic Gnome (talk • contribs) 13:45, 29 January 2009 (UTC)

Consensus and notice for proposals like this

For proposals that are this far-reaching, I feel Wikipedia should notify us on login the way they do with donation requests. This one proposed change has the potential for large consequences for Wikipedia, and I feel that it making a change like this requres a larger group consensus than demonstrated in the original vote, in which approx. 700 people participated. --Zippy (talk) 17:19, 27 January 2009 (UTC)

Support. Otherwise it excludes the vast majority of the userbase from decisionmaking and gives the impression that important decisions affecting everyone are made by a tiny self-appointed clique of insiders. --IdiotSavant (talk) 00:55, 28 January 2009 (UTC)

Support also. For reasons given above. Thehalfone (talk) 09:01, 28 January 2009 (UTC)

Support. I was very disappointed to see the vote was already closed. This proposal basically kills off a lot of anonymous editing. I only recently created an account after editing for several years (very intermittently though) and the most important motivation was the knowledge that every edit I made was visible to me and the average visitor. If I knew my edits went on hold pending review I wouldn't have bothered. Pietrow (talk) 12:10, 28 January 2009 (UTC)

• Strong support. Probably only the most active of users found the watchlist notice and, now that we're being linked to by Slashdot, I believe we should have a new poll and enable anonymous users to vote, as they're the ones who will suffer the most of this idea's negative consequences. Admiral Norton ^(talk) 15:34, 28 January 2009 (UTC)
• Most regular users keep their account logged in, so they'll never see that announcement. It makes more sense to put an announcement on the watch page, like they did, because that is where the page that regular users will most often look at. --Arctic Gnome (talk • contribs) 13:48, 29 January 2009 (UTC)

Do you have statistics on how many users start on the watch page? I honestly don't know, but in my case, I start most often with User Contributions. --Zippy (talk) 22:09, 31 January 2009 (UTC)

An alternative to flagged revisions: delayed editing reconsidered

I saw something like this being discussed above and I thought it deserved a better look in as a possible alternative to flagged revisions. (Although I think the software implementation would be quite similar.) Just because a patch request was rejected doesn't mean it shouldn't reconsidered.

Here's my proposal:

Anon and not yet auto-confirmed editors would have to wait a certain (reasonable short) amount of time before their edits become visible, say 2 hours. On the system their edits would be marked as pending along with indicating a time when they would be published. In the mean time the version published on the internet would be the latest non-pending version. the editors concerned would simply be told:

- the delay is for anti-vandalism reasons, and

- if they edited by accident they could revert their edit. (Hopefully more vandals would revert themselves.)

Most vandalism is reverted in a short period so most vandalism would be reverted before it went live. Editors could confirm (the waiting time would be abridged) or reject these edits after seeing the diff. Thus readers wouldn't see the majority of vandalism and vandals would loose the encouragement of having their edits immediately visible.

Confirmation or rejection would be make simple for a large group of trusted editors, but would still be possible for other users by making an edit.

For articles which are currently semi-protected, the waiting time would be lengthened and editing delays could be imposed on a wider group of editors.

Waiting times could also be increased for certain users. Anons and even some new users could be flagged as possible vandals by admins (and possibly by trusted users), thereby increasing their waiting periods.

I think we have to be clear about what we intend to use Flagges Revisions for. If it's about instituting a quasi-editorial board for featured articles, then Flagged Revisions might be the answer. If it's just an anti-vandalism device to insure people aren't reported as dead before they actually are, it just might be over-kill. — Blue-Haired Lawyer 19:46, 27 January 2009 (UTC)

What you propose is basically flaged revision with auto-sighting after x amount of time (something I believe already an option with the FR system), and a message. No matter WHAT is put into effect, anyone who edits MUST edit the current page, weather or not it's sighted (or whatever); there cannot be a case where an edit waits for publishing while others can edit the older one without it.♫ Melodia Chaconne ♫ (talk) 20:17, 27 January 2009 (UTC)

I'm not sure if it is an option. The whole language of "sighting" suggests that a article revision is reviewed (read thoroughly and it's merits debated) before being flagged.

Anyway, I'm not proposing two different versions. If a anon and a registered user edited a page in succession, both edits would be published (unless the registered reverted the anon). And the registered users edit would effectively abridge the anon's delay, making both visible to the world-at-large. (The effect being that delays would very frequently be less than 2 hours.) — Blue-Haired Lawyer 20:46, 27 January 2009 (UTC)

Flagged revisions is a bit of software that can be configured in a large number of ways. It can have up to 99 types of flags, each with their own settings. One could used as Melodia Chaconne stated above, a two hour delay. Z gin der 2009-01-27T20:55Z (UTC)

In which case my proposal is merely a different way of implementing Flagged Revisions. On the up-side it makes the proposal more feasible. — Blue-Haired Lawyer 22:47, 27 January 2009 (UTC)

For what it is worth, an automatic short delay for new / anon users is probably my preferred approach to implementation. Of course I proposed something similar four years ago or so. Dragons flight (talk) 22:11, 27 January 2009 (UTC)

Yesterday's fringe position, is today's moderate one. It make you think. — Blue-Haired Lawyer 22:47, 27 January 2009 (UTC)

Actually I'm not sure these is a setting in Flagged Revisions to make pages automatically sighted after a certain time frame. As far as I can see a user with reviewer status (it's still not clear who these will be) is given a small box on each article by which they can review revisions. The default options are:

Accuracy: Unapproved - Sighted - Accurate - Well sourced

Depth: Unapproved - Basic - Moderate - High

Readability: Unapproved - Acceptable - Good - Concise

and a form field box for comments. This seems very much like full on editorial control to me. In my proposal there'd just be accept and reject. And there wouldn't be a backlog of revisions needing to be reviewed. — Blue-Haired Lawyer 16:26, 29 January 2009 (UTC)

I've decided to post this as a formal proposal here: Wikipedia:Delayed revisions. — Blue-Haired Lawyer 20:38, 29 January 2009 (UTC)

Make “Recent Changes” More Obvious & User-Friendly

Wikipedia currently has a “Recent Changes” page which summarises changes recently made to articles. Presently, this is a tool mainly used by those very much involved with Wikipedia. However, could this not be made more “user-friendly”, and thus opened up to a larger audience? If more people were encouraged to check recent changes, it would surely result in more revision and thus quick changing of erroneous claims.

I don’t think anyone views Wikipedia as the final word on all knowledge anyway (many schools do not allow it to be utilised at all – a stupid rule indeed). Rather, it is more an “aggregator” of facts, the most important of which I believe would certainly need to be verified by another reliable source. For example, the page on the death of George Reeves has often stated incorrect information for large periods of time. The point here is that it changes constantly; this is good, it’s what Wikipedia is meant to be. By its own laws, Wikipedia will never be a 100% “bible of fact”.

I believe this issue has been exaggerated. The errors used as an example were corrected very quickly. An overhaul such as the one suggested by Wikipedia’s founder will certainly be counterproductive to everything that makes Wikipedia one of the most visited websites in the world. —Preceding unsigned comment added by 202.92.90.161 (talk) 23:00, 27 January 2009 (UTC)

Question

If this goes into effect, lets say I make an edit. Would it have to be reviewed before it could appear?-Kieran4 (talk) 15:08, 28 January 2009 (UTC)

Judging by your 905 edits, I assume you'd get the "autoreview" flag. However, I've heard some statements here that still make me wonder about that. Admiral Norton ^(talk) 15:37, 28 January 2009 (UTC)

Thats a big issue for me. I wouldn't appreciate it if my edits have to be reviewed, I think I have proven myself a reliable editor by this point.-Kieran4 (talk) 15:53, 28 January 2009 (UTC)

Indeed, this is one of my biggest gripes about the feature on the numerous foreign language wikis that I update interwikis on; they won't give me the autoreview flag because I'm not active enough (despite the fact that I've got 45k+ global edits, I don't have enough on that particular wiki). EVula // talk // ☯ // 20:33, 28 January 2009 (UTC)

Each language has the right to choose their own use of flagged revs, but now that we have unified login, it would be possible to set up a universal autoreview status. I know that universal permissions are being discussed somewhere on Meta. --Arctic Gnome (talk • contribs) 13:55, 29 January 2009 (UTC)

FlaggedRevs documentation

We now have a number of parallel discussions now ongoing that consider possible implementations of the FlaggedRevs functionality, covering a huge range of configuration options; however, they all have a number of things in common, and I think that these areas should be the focus of our attention. Foremost, every proposal must either include an explanation of, or make an assumption that readers are familiar with, the FlaggedRevs user interface and how the flagging process works.

It is my belief that an important step forward for FlaggedRevs on en.wiki is to create a full but accessible documentation for the aspects of FlaggedRevs that are invariant across all the proposals: how pages are reviewed, how flagging is encouraged, how the workflow of the wiki is affected. An easily-accessible explanation of what the extension will entail and what features it will provide will, I think, go a long way towards resolving some of the innumerable 'trivial' concerns with the entire principle, and leave us free to focus on the important and legitimate issues.

This documentation needs to be independent of any particular configuration of FlaggedRevs, and focus only on the aspects that apply to all users on all wikis. It needs, in effect, to be "site neutral". Partly for this reason, I propose that we write this documentation on http://www.mediawiki.org, in its public-domain Help: namespace. This way, our work will be accessible to any other wiki that wishes to consider FlaggedRevs, and we can ensure a fair and neutral representation of the system. mediawiki.org is a website run by the Wikimedia Foundation, and is part of its SUL network: if you have a global account, you already have a login there - you should be logged in automatically. It runs MediaWiki just like en.wiki, and all the same features are available; it has most of the same community standards as en.wiki although its focus is on the documentation of the MediaWiki software. And it's where all our help content is running away to anyway :D. Since it will be a public-domain resource, once written it can be copied or moved in its entirety without any of the licensing issues that bug us constantly on normal wikis, so we can get it back here without any trouble at all, while moving it from here would be much more difficult.

I have begun work on a framework for the documentation on the appropriate page at mediawiki.org. I have added a few notes on the talk page for those who haven't been to mediawiki.org before. If anyone is interested in helping with this little project, your assistance would be very much appreciated. Happy‑melon 20:28, 28 January 2009 (UTC)

The importance of immediacy

Any move to increase the time from edit to publish is contrary to the entire trend of the modern information society. It is a testament to the success of Wiki as model that mainline news media has picked up this story - the revolutionary has become the status quo. We are in danger of going down the route taken by all 20th Century organisations when they become big enough to become targets: increase in policing and security, sacrificing accessibility and a constant cycle of reinforcing rules to close loopholes. Due to the size of the content, surely vandalism is like graffiti in a city: annoying if it's on your wall but hardly prventing the city from functioning? Btljs (talk) 13:13, 29 January 2009 (UTC)

Deferred revisions

Wikipedia:Deferred revisions is a new proposal to use the abuse filter to defer suspect edits for review without the need to enable 'classic' flagged revisions, but able to work with it. Please express your opinions on the talk page. Cenarium (Talk) 18:36, 29 January 2009 (UTC)

The general consensus

Does seem to be against the proposal on various grounds.

There may well be an argument for flagging up certain categories of changes - newbies, IP-address-only changes (though a proportion will be of the correcting typow without signing in type) and 'significant changes to text' - but otherwise it is likely to cause a certain amount of chaos, several people trying to improve an article and creating edit conflicts etc.

What happens if Editor X scrambles a text into incomprehensibility/puts in a typo - accidentally or deliberately, or a libel gets put into the text - such things could persist longer than at present. 14:05, 30 January 2009 (UTC)

You apparently think there is a general consensus against flagged revisions, but the straw poll indicates that a substantial consensus believes we should try it.

As to your second and third paragraphs, you seem to misunderstand the mechanism. Chaos due to "edit conflicts" would not be caused by flagged revisions. There would still be exactly one active draft to edit at a time; unreviewed edits are still present in the current, latest, and only editable version, it's just that that version may not be what the unlogged-in public sees. -R. S. Shaw (talk) 22:56, 30 January 2009 (UTC)

Have a look at the analysis of that straw poll. Summary: Admins were very much for it, other users with accounts were evenly split and IP users (those that would be disenfranchised) were not really represented. Thehalfone (talk) 14:09, 31 January 2009 (UTC)

People responding on these seem to find issue with the subject.

The explanation of the mechanism in the article does seem to be somewhat ambiguous. From what User:R. S. Shaw says there will still be two versions of the text - so I (and X other users) spot an error, decide to sign in and change it, and find it has already been done: if it happens often enough people may stop doing edits.

Most edits (even by newbies or where 'signficant sections are changed') are likely to be uncontroversial.

Why should people be forced to sign in to see the fully updated version - and, as with the library terminal I am presently using:

'Account creation from this IP address (number) has been temporarily restricted. This is probably due to persistent vandalism from the IP address you are editing from, which may be shared by many people if you are connected to the Internet via a proxy server (used by most schools and corporations and some Internet service providers) or dial-up access.

The guard mentioned below was (probably) not signed in - so would still see the incorrect version etc (and the same might well apply to other examples).

And - what about 'currently changing events' - for example the (theoretical) "Effects on UK of snowstorm of 2 February 2009"?

A nuanced system is probably appropriate - with an "override facility" (to allow for unexpected and confirmed major changes, proven major errors etc). Jackiespeel (talk) 15:41, 2 February 2009 (UTC)

Why should people be forced to sign in to see the fully updated version -- they aren't. Anyone can see the draft version by clicking "see draft" or whatever. Also, as far as "seeing it's already fixed", well doesn't that happen already on fast moving articles? ♫ Melodia Chaconne ♫ (talk) 16:51, 2 February 2009 (UTC)

So will the 'person passing through' checking a fact, loo at the draft version for corrections as well as the "article page as it is"? With a rapidly changing story which version of the article will the casual viewer see?

The question perhaps is - what proportion of Wikipedia pages are subject to vandalism and other negative activity (as distinct from mistyping, the products of multiple editings and similar)? What proportion of vandalism - overt or subtle - and creative reworking or similar do persist for any length of time? Whatever systems are employed will not prevent, for example,the recent fake biography and the fake medical complaint incidents.

Given the number of pages created, changed and updated each day, how will the whole process be managed? In the vast majority of cases there will be no issue with the change - so the what will be the point of flagging the change?

As I said above, there is an argument for flagging certain (categories of) articles or changes, but having a permanent revolution of checking might prove counterproductive. Jackiespeel (talk) 15:18, 3 February 2009 (UTC)

Then again...

I'm not really so keen on this whole Flagged Revisions thing but here's an extract from my watchlist a minute or two ago:

• (diff) (hist) . . m Talk:Ireland; 21:52 . . (+207,286) . . Zzuuzz (Talk | contribs) (Reverted edits by 78.53.225.160 (talk) to last version by Jmundo)
• (diff) (hist) . . m Talk:Republic of Ireland; 21:51 . . (+74,544) . . Catgut (Talk | contribs) (Reverted edits by 78.53.225.160 to last version by Jmundo (HG))
• (diff) (hist) . . m Republic of Ireland; 21:51 . . (+101,486) . . Catgut (Talk | contribs) (Reverted edits by 78.53.225.160 to last version by Jmundo (HG))

And the Naturalization article was left almost completely blank for an entire day (!!) before anyone (me as it happens) noticed anything was wrong. We really have to sort this out somehow! — Blue-Haired Lawyer 22:17, 30 January 2009 (UTC)

Yes, even though much is now caught quickly, much vandalism stays in all too long. Flagged revs will make the delays in catching vandalism acceptable since the web in general will not have to see it by default. My watchlist is filled with "Reverted" edits; there's a huge amount going on. -R. S. Shaw (talk) 23:01, 30 January 2009 (UTC)

We don't have enough users to oversight all pages though, so it's why I propose Wikipedia:Deferred revisions: edits automatically identified as suspect are deferred until review. Cenarium (Talk) 17:48, 31 January 2009 (UTC)

The problem with flagged revisions is similar to the problem with RFA...

In that the majority of people agree that something needs to be done, but people are too split over what to do about it. Some are fundamentally opposed to flagging revisions at all. Some, like myself, are opposed to anything that doesn't make anonymous editing accessible. Some think that FR needs to be employed on a small subset of articles. And finally, some don't want IPs to edit at all. Resulting in a normal distribution, where half of people are moderate, and the other half are at ideological poles. This produces an impasse similar to RFA, and thus we get nowhere. Thoughts? Sceptre ^(talk) 03:56, 31 January 2009 (UTC)

There aren't as many options when we acknowledge that both extremes are unworkable. We can't have blanket semi-protection or flagged revs across the wiki, that violates our fundamental policy of everyone can edit. On the other side, we can't just leave BLPs and high-traffic articles alone, otherwise we are going to be committing libel with every vandal strike and will suffer the legal and ethical consequences; also articles like France or Star Wars will have to be reverted every other minute from vandals. The only two options that I can see are protecting controversial, famous, and BLP articles with semi-protection like we do now or with flagged revs. --Arctic Gnome (talk • contribs) 04:43, 31 January 2009 (UTC)

The other option is invest more in bots, the Germans made 1.578.272 edits for sighting and they didn't reach the target (obvious vandalism), if we invest that amount of time and energy in the development of the bots and let them target the BLP and high risk articles .... Mion (talk) 23:27, 30 January 2009 (UTC)

That would help with obvious vandalism, but the danger with BLPs are more subtle vandalism that bots can't notice. --Arctic Gnome (talk • contribs) 15:57, 31 January 2009 (UTC)

Who is arguing that FR will solve more subtle vandalism, and on what evidence? Happy-melon is responding to all such demands that FR isn't built to do that, and it isn't. Septentrionalis PMAnderson 19:26, 31 January 2009 (UTC)

In so far as articles would be read and reviewed before they were sighted, FR would very likely eliminate most subtle vandalism as well as the most obvious stuff. — Blue-Haired Lawyer 19:51, 31 January 2009 (UTC)

Wishful thinking. The point about subtle vandalism is that it's subtle; one of the cases in which WP has already gotten someone into trouble was an article which made very serious accusations against the subject, who was arrested and detained in a Canadian airport, because some security guard read and believed our article. But the edit had a source (which did make the charge) and a footnote leading to it; are reviewers expected to perform the level of checking required to catch that? and if so, how are we going to avoid editting lags which make the up-to-three-weeks of the German Wikipedia look moderate?

Wikipedia is not a reliable source; the fix is to get the word out that it isn't. Septentrionalis PMAnderson 20:02, 31 January 2009 (UTC)

So how does the fact that it doesn't prevent this occasional case make it somehow bad that it'll prevent most others? And when you continue to spout incorrect info about the "editing lags", one can't assume good faith from you any more. ♫ Melodia Chaconne ♫ (talk) 20:16, 31 January 2009 (UTC)

Its 18,2 days with a median of 6,1 days, 3 weeks is close enough to be correct de:Wikipedia Diskussion:Gesichtete Versionen#ParaDox's Tabelle: Noch zu sichtende Artikel-Entwürfe. Mion (talk) 20:21, 31 January 2009 (UTC)

The expected editing lag is because this is what the Germans check, and this is what the surveyor group has to check on BLP's. Mion (talk) 20:40, 31 January 2009 (UTC)

I think the length of this page says something about the topic.

Can someone explain how editing lags can be avoided - even if a system such as that on Project Gutenberg is set up?

There is no way that vandalism, 'attempts at being amusing' and everything in between can be eliminated entirely - even if far more restrictions are applied to editors. Only a small proportion of articles are likely to be subject to even subtle vandalism. There are going to be at least as many cases of misundertandings, mistypings, multiple-editing incoherences and similar instances (plus multiple point of view conflicts etc).

If someone really wants to create havoc, visibly or subtly, they will manage to do so, whatever the restrictions imposed.

Possibly some analysis should be done - without knowing the scale of the problem the appropriate #proportional# response cannot be decided upon. Jackiespeel (talk) 18:32, 3 February 2009 (UTC)

WikiLove

I've poured a cup of tea for anyone and everyone in any way involved in this (including people opposed to it). I may crosspost this notice in a few other places. --Thinboy00 @079, i.e. 00:53, 4 February 2009 (UTC)

Possible solution?

Maybe there could just be an option to toggle flagged revisions on and off.

In the "toolbox" section (under the search bar, under interaction) there could be a "Flagged revisions" button.

There, you can choose to toggle flagged revs on and off. (Regardless of whether you are an IP or a registered user)

What happens is pretty self explanatory - if it is on, then you see the article as of its last sighted revision, and if it is off, you see the last version of the page, regardless as to whether the edit was sighted or not.

I don't know if this has been suggested already, but it seems like a relatively simple way to make everybody happy. (You want flagged revs? Turn them on. You don't want them? Turn them off.)

Inferno, Lord of Penguins 23:10, 4 February 2009 (UTC)

It seems to me most of the proposals aren't for flagged revs everywhere, so this would be flagged revs only on some articles and then, even there, only for some people. I can't imagine anyone bothering to turn it on, but then my bias is that I don't think flagged revs is a good idea. Maybe people who do think it is a good idea would turn it on. But the real goal is (I think) to protect the innocent occasional wiki-users from having to see vandalism. The default position would presumably be on (for those articles where flagged revs were on at all), but if you wanted the instant gratification of seeing your edits, you could turn it off. All in all, I think Inferno's idea is a worthwhile one. xschm (talk) 01:18, 5 February 2009 (UTC)

A few thoughts on the subject:

Whatever the system of controls introduced, vandalism, Murphy's Law's of editing, errors, inelegances, persistence of obsolete information correct recording, in good faith, of incorrect information and other sources of error and the occasional 'incident' will occur, as with other communications media. (How does Wikipedia's record compare with other media?)

Has any study been made of the editing of Wikipedia articles? How accurate is my supposition that most changes to most articles are neutral or positive? To what extent would the flagged changes system actually improve the correctness of Wikipedia as a whole - or create a false sense of security as to its accuracy? How will people be persuaded to do the checking of articles changed - and how would it be done? A system like Project Gutenberg's Distributed Proofreaders? Going by the extended stay of some articles on the various Wikipedia Open Task lists, it is quite probable that certain articles will likewise languish awaiting correction. What would the situation be with talk pages? What is not wanted is a system that seemingly requires more work to produce the same result, and potentially discourages participation (You correct a typo, receive a message 'Your amendment will be checked, and has been placed in a queue. Please check here (click button) to see its progress towards public view. Thank you for your cooperation and patience. We hope you continue contributing to Wikipedia.') (NB - this #is# meant to be tongue in cheek.) - or which has to be reversed fairly quickly as impractical. Jackiespeel (talk) 14:58, 5 February 2009 (UTC)

Just to clarify - I am not against the idea in toto, but it does seem to create the potential for confusion (from 'casual passer by not checking' to potential legal) - but it will be most useful if done selectively. Jackiespeel (talk) 14:55, 9 February 2009 (UTC)

Usability

Just an FYI and a thought really.

I recently asked a colleague, who has never been a logged-in editor of Wikipedia (mostly just a reader) what he thought a "flagged revision" might be. He thought it might either be a revision of the software, or a revision of the document flagged for some purpose: "perhaps it has been vandalised?". It never occurred to him that this is simply another view of a "draft/published" versioning system, and that the "flagged revision" was one that had been published for all to see. I also asked him what "sighted" might mean: his answer was "someone has seen the article? I don't get it.".

Looking at these answers objectively, I understand where he came from: "flagged" has absolutely no specific meaning, "sighted" is even more ambiguous, really.

So, in all of this arguing, perhaps the proposers could take a step back and consider whether the current proposal is intuitive to non-Wikipedians, and re-consider the confusing terminology? This might actually help the argument, too (in that I'm sure some editors don't actually realise exactly what they're arguing about!) Stephenb (Talk) 12:12, 10 February 2009 (UTC)

de-wiki and misinformation made easy

Just a thing I came across in my daily blog read:
As we all know de-wiki has a flaggedrevs system for all articles. A German Wikipedia user inserted a fake name in the article about the new German minister of the economy. But then the interesting part began: Since the guy was new in office, several reliable German newspapers (and tabloids) copied this name from de-wiki into their content. When the addition was challenged, guess what happened? Right! Those reliable sources (which copied from de-wiki) were now cited in support of the change! And voila, article with incorrect information - approved! Source (German)
Please don't start another discussion about flagged-revs now, I just thought it might be a funny item to share. It does prove though that misinformation can easily be introduced, even with flaggedrevs enabled So Why 22:07, 10 February 2009 (UTC)

I agree that that's highly amusing. I don't believe, however, that it represents a 'problem' either with FlaggedRevs in particular, or the wiki process in general. An incorrect statement was made. The statement was challenged; it was supported from reliable sources. The statement therefore met the necessary standards for verifiability (or would have here, anyway) of "verifiability, not truth". The fact that the statement was untrue is actually irrelevant: if respectable newspapers think that copying tips from Wikipedia is a good idea, then the egg is on their face, not ours. It's not our place to second-guess the reliable sources; we just document what they say. And when more reliable sources crop up to highlight the error, well then we can just rewrite the passage to explain how "several reputable newspapers erroneously claimed[1] [2] [3] that Smith had been made Minister, having seen the name posted on Wikipedia..." and lo and behold, the mistake is itself a notable piece of encyclopedic content. We really can't lose :D Happy‑melon 22:50, 10 February 2009 (UTC)

True, although maybe they copied it due to some sense of false security they gathered by flagging revisions. Like "Wikipedia now checks all revisions, that means they check them for errors. Let's copy them!" ;-) So Why 08:34, 11 February 2009 (UTC)

Flag protection, patrolled revisions and deferred revisions

I have made three proposals related to Flaggedrevs. The proposals are a variant of Flag protection, Patrolled revisions and Deferred revisions. Comments would be appreciated to see if there is support for some of them and what to do next. Cenarium (talk) 15:21, 22 February 2009 (UTC)

Blogs

A list of blog posts on the issue. Sdedeo (tips) 22:37, 9 September 2007 (UTC)

Framework for evaluation

I would like to see some kind of consensus on what the requirements are for a flagged revision system. It seems to me that there's considerable disagreement about what the purpose behind them is. If there was a framework, we could evaluate the alternatives in light of these priorities, and make an informed decision by evaluating each alternative according to our goals. That said, here is my understanding of the situation, and some of the important metrics the community may be applying:

Problem: Quality has become a desired attribute in the community to prevent random (or intentional) drift in a backward direction. We wish to do this while maintaining the spirit of empowerment and democracy that has been Wikipedia's identity; this is a root principle. If we choose to compromise it to add a new attribute (quality) that wasn't present before, we need to understand the impact of this.

So, in my evaluation, we need to understand:

• Does the proposal maintain the spirit of Wikipedia?
  • Does the proposal result in significant collateral damage?
  • Does the proposal allow democratic access to the mechanisms of control?
    • Does the mechanism assume good faith, to leverage our users good will?
    • Does the mechanism leverage the effect of time to dampen conflict?
  • Does the mechanism promote progress?
  • Does the mechanism promote consensus?
• Does the proposal improve quality?
  • Can we afford to wait for a better technical solution in the near future?

Please note that I think most proposals I've seen *will* promote the quality of Wikipedia. I believe the key distinguishing features will be the costs imposed on the collective goodwill. Delegation to mechanism by default has the effect of empowering the mechanics. I believe we should do everything possible to make the mechanisms as transparent as possible to counteract this effect. Honestly, I haven't seen that done in this discussion. 70.251.156.202 (talk) 19:00, 1 February 2009 (UTC)

I've put my finger on why I'm concerned about the flagged revisions mechanism. It's because it is fundamentally asymmetric. It creates a mechanism for separating two classes of users in a non-democratic way. This should be avoided and/or mitigated at all costs, if you value the democratic process. Wikipedia is founded on a symmetric editing process; any editor can edit/revert any other. I think we need to maintain this fundamental symmetry in any new mechanism, or risk it being corrupted by those in the position of power. 70.251.156.202 (talk) 19:22, 1 February 2009 (UTC)

Idea that might help

I'm really late to the party and this is probably the wrong forum, but could someone explain why we couldn't work in collaboration with search engines to help solve the problem FLR is entangled with? For example, we could arrange that search engines like Google cache the last edit that has remained for more than ten minutes, rather than the last edit. Seems reasonable to me; it'd at least prevent the Obama incident from recurring. —Anonymous Dissident^Talk 13:36, 6 March 2009 (UTC)

If the last edit is a correction on some errur in the article it would show the wrong version, most people improve an article rather than vandalizing it. Mion (talk) 18:14, 6 March 2009 (UTC)

No forced vandal whacking: Flagged revisions now

I have a radical proposal.

1. Those who object to flagged revisions can do the vandal whacking work.
2. Those that want flagged revisions sit back and let those who object to that do the vandal fighting.

Add this user box to your page:

This user demands flagged revisions NOW and refuses to do vandal fighting.

Vandal fighters, good luck, I hope many will sit back and see you guys do the work. -- Kim van der Linde ^{at venus} 19:51, 11 March 2009 (UTC)

Nice, but not wildly constructive. ╟─Treasury Tag►contribs─╢ 20:21, 11 March 2009 (UTC)

Might make the point, though. Thanks Kim. (you have to ask yourself, why are the poll results skewed, time after time... why do old timers and admins favour flagged revisions more than less seasoned users and non admins... what do they know about it?) ++Lar: t/c 20:35, 11 March 2009 (UTC)

Wow, it is not wildly constructive? No, having to fight vandalism is constructive. I think Jimbo should just implement it, with all with roll-back can flag, and the relevant policy pages will be done within days. The current talk and talk and talk and talk has been wildly constructive I see, we are still whacking vandals and no flags in sight! My guess is that my userbox and actions are MORE constructive than the archives of talk conducted here. Once the vandalism is out of control because many do not fight it anymore, I think many of the nah sayers will be glad to have flaged revisions. Especially when more and more hughly embarrasing vandalism remain for grab for the press. -- Kim van der Linde ^{at venus} 21:00, 11 March 2009 (UTC)

I do take your point, but it's not constructive in the sense that it's not going to move us forward. If some anti-terror law is under debate in Parliament, politicians have long realised that the, "OK, if you won't let us fight terrorism properly then you can all get blown up," argument doesn't work. Making jibes at the opposition isn't helpful IMO. But don't mind me :-) ╟─Treasury Tag►contribs─╢ 21:11, 11 March 2009 (UTC)

Wrong analogy, I think... the better analogy is if some significant fraction of workers at a particular skilled trade go out on strike, (for example air traffic controllers) there's an impact on the operation (for example, flights) that their trade supports. Either the issue causing the strike needs to be resolved satisfactorily (for example by implementing new air traffic procedures), or the workers need to be replaced (for example, as Reagan did when faced with an ATC strike). Every strike starts somewhere. Perhaps I've misinterpreted what Kim is suggesting here though. ++Lar: t/c 21:29, 11 March 2009 (UTC)

(answering Kim) What you may end up with in that case is flagged revs at some point in the future, along with an embarrassing legacy in the press that will take time to recover from. If the community is so wedded to the consensus idea then try deciding the first question first - shall we have flagged revs, followed by the actual form later. Or better yet, don't let the community decide. WP:NPOV is an editorial issue laid down from above, why shouldn't this be the same. ARBCOM needs to stand up and say that:

• Flagged is turned on, and it will not be turned off
• For X months we will try this variant
• After that period it will be reviewed

No-one can argue with them, because there is no recourse for appeal except to Jimbo. 203.24.135.66 (talk) 21:42, 11 March 2009 (UTC)

If you want to replace the volunteers as Reagan did you have to get them from Citizendium, and the problem with volunteers is, once they walk away changing the procedures is useless as they already left the project. And 4 months ago this was a solution looking for a problem, BLP was just one of the options, if you want to improve, improve Cluebot. Mion (talk) 21:49, 11 March 2009 (UTC)

Sorry? A solution looking for a problem? BLP has been an issue for years. Cluebot is a solution for vandalism, not well written defamatory content. 203.24.135.66 (talk) 22:00, 11 March 2009 (UTC)

if you do not want to end up with that bad legacy, enable flagged revisions NOW, and that won't happen. Don't blame those who want flagged revisions, blame those who oppose it. And tell those editors to work harder in fixing the vandalism, because THEY WANT TO DO IT THAT WAY and block flagged revisions; do not blame me, or Lar, or many others because we are fed up with those that block flagged revisions and whine that there is to much vandalism. -- Kim van der Linde ^{at venus} 22:12, 11 March 2009 (UTC)

Wait, so people are saying that users should stop reverting vandalism until flagged revisions are implemented? That would just make things worse. So, unless things go a particular way a group of users want it, they're going to bitch and not do anything till it's implemented? That doesn't help the encyclopedia. If anything like that happens, Jimbo might as well just pull off a Teddy Roosevelt, and prevent editing overall until the issue is fixed, which would be worse then lots of talking. Deavenger (talk) 22:02, 11 March 2009 (UTC)

Except for the BLP subjects, who may welcome such a decision. 203.24.135.66 (talk) 22:06, 11 March 2009 (UTC)

@203.24.135.66 current progress indicates that the cluebot AI type can handle defamatory content in the near future, and as this encyclopedia is not finished today, there is no reason to introduce measures with a lot of side effects as the market will give us the tools/algorithms in the coming years(http://www.wolframalpha.com/). Mion (talk) 22:12, 11 March 2009 (UTC)

I guess we disagree. I think that action is required now, not in a few years.

203.24.135.66 (talk) 22:23, 11 March 2009 (UTC)

Then start the project Cluebot BLP and start writing...Mion (talk) 22:27, 11 March 2009 (UTC)

Right, as if a bot ever can catch vandalism like this in Hyacinth Macaw: they have red wings. They have not, no bot will know that. Get real, no bot can fix this. -- Kim van der Linde ^{at venus} 22:35, 11 March 2009 (UTC)

Piece of cake for a bot, as databases keep opening up, comparision with descriptions in other databases will filter out the anomalies, as per NOR original desciptions are not allowed all descriptions can be cross checked. Mion (talk) 22:41, 11 March 2009 (UTC)

I have an idea, till such a good working bot has been developed, we enable flagged revisions, and when the bot is working, it can do automated flagging on content it has checked. In that way, we do not have to wait for something that is CLAIMED to be possible, but for which no working prototype has been shown. -- Kim van der Linde ^{at venus} 22:53, 11 March 2009 (UTC)

Such a bot that could detect good content from bad could write the encyclopedia on it's own, couldn't it? I think I saw this story in a film somewhere. It didn't work out, as I remember. 203.24.135.66 (talk) 22:58, 11 March 2009 (UTC)

Indeed, let the stuff explode. I write good content, and as soon as the flagged revisions are implemented, the good content is quickly enough found and flagged. Vandal whacking is like coorborating with a evil empire under the guise that it could be worse if you would not help them. And no, I am not going to bitch about the vandalism that piles up in the period between now and when flagged revisions are implemented. It piles up already anyway. Sometimes, you have to take a prinicpled stand to actually make a change. if you want to fight vandals, be my guest, there is enough to do for you, but I rather spend my time on more constructive things, like writing good content. -- Kim van der Linde ^{at venus} 22:17, 11 March 2009 (UTC)

"OK, if you won't let us fight terrorism properly then you can all get blown up," Indeed, so, put the flagged revisions on, and fix all the details after that. Waiting longer is like having no sensible way at all to do anything. Vandal whacking is like throwing terrorists out of the country but have the border open to everybody without immigration. Not useful. Flagged revisions is like having immigration to keep the terrorists out. -- Kim van der Linde ^{at venus} 22:12, 11 March 2009 (UTC)

I don't quite understand the argument here. FlaggedRevs doesn't prevent vandalism. It prevents people from seeing it, and as a result may reduce some of the motive. But there will still be vandalism with FlaggedRevs and it will still have to be reverted. Mr. Z-man 21:39, 12 March 2009 (UTC)

Arguably there will be less vandalism, which is goodness. Further since it's not visible, it can be undone at leisure. So there is less pressing need to fix it immediately. ++Lar: t/c 05:00, 13 March 2009 (UTC)

Try it, it won't hurt!

It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. —Franklin D. Roosevelt. -- FayssalF - ^{Wiki me up®} 17:13, 12 March 2009 (UTC)

since there is no way to get consensus for any type of flagged revision thing prior to implementation, is there a mechanism to get someone to just implement it? and then as we sort out the details of who/what/when/how/how long/were/etc, we begin to hide the egrigeousness that burns out OTRS and Oversight'ers faster than we should? --Rocksanddirt (talk) 20:53, 12 March 2009 (UTC)

Yes. WP:ARBCOM as the sole body here that cannot be usurped, need to rise out of their present mandate and just do it. 203.24.135.66 (talk) 21:06, 12 March 2009 (UTC)

They already have a mandate to implement this, at least for BLPs. ++Lar: t/c 05:00, 13 March 2009 (UTC)

Let's see what we can get

... and Keep It Simple Stupid.

The discussion about flagged revisions has largely died down, again. I say we restart it, and pull it through this time. Jimbo says he is working on something, but it has been a while. Also, while Jimbo may be the god-king of Wikipedia, he is not omniscient, and is unlikely to come up with a better proposal than us.

I am convinced that it is possible to get consensus if we present a clear proposal. However, this proposal must be written with the goal of reaching consensus, not going as far as possible.

After reading the various proposals, I want to start with this. Please answer the questions given.

Administrators can enable flagging on:

• Any article, under similar circumstances as semi-protection.
• Any biographies of living persons (BLP), as long as the flagging backlog is short. Priority to articles that seem to have few to no editors watching.

Any user can edit. It is not shown to anonymous readers until flagged by a reviewer Reviewers:

• Shall the "reviewer" right be given automatically?

• After how long? 100 edits + 3 months?

• Admins can give/take away the reviewer right
• Shall reviewer be tied to rollback?
• ..or shall we make all current rollbackers into reviwers, but keep the rights separate

Shall edits by reviewers be flagged automatically?

• Edits by admins?
• Shall edits by bots be flagged automatically if the previous revision is flagged?

Shall we automatically flag revisions after a time limit, say 1 week?

Do we need a trial?

• No, start with a few articles and roll it out gradually?
• Yes, a time limited trial?
• Yes, a trial period where we try flagging, but readers still see the newest revision, flagged or not?

I intentionally kept this simple with as few new user groups and protection levels as possible. Perhaps we want a new group to help admins enable flagging on articles, and perhaps we want a kind of full-flag-protection where only admins can flag revisions. However, let's start simple and add that later if needed.

What we need to do now is discuss and make a consensus proposal. I suggest spending two weeks doing this. After that we open an RFC to see if there is consensus. This would take about a month, and if there is consensus, then we can start turning this on towards the end of April. Optimistic? Yes, but possible. --Apoc2400 (talk) 15:20, 11 March 2009 (UTC)

I made pretty much the same suggestion here. — Blue-Haired Lawyer 15:29, 11 March 2009 (UTC)

Yes I saw it. The difference is that I prefer to do it in the other order: Instead of starting with a straw poll, start with discussion and create a clear proposal together. Then hold an RFC/straw poll on a well-defined proposal. Do you want to help out? --Apoc2400 (talk) 15:34, 11 March 2009 (UTC)

I have several responses and concerns:

• Flag revs should be BLP and BLP related. Any time an article can do real damage to real people - even in theory, it deserves heightened protection, at any administrator's discretion, in conflict, default to on. Issues outside of BLP that cause real damage can also be flag reved but should go through a consensus process (AfFR or RfC), not admin discretion.
• If flagged revs are BLP focused, then the reviewer permission should be at a higher level of scrutiny, that is, a sort of big deal (between rollback, but the permission should not be tied to any other permission - BLP judgment is different from DR judgment and consensus judgment. Most admins should be able to get the sighting right, but who knows, maybe some don't. Most experienced users should be able to gain the sighting right, but defaulting to off in the event of disagreement.
  • I do not mean here any disagreement, but significant and reasoned disagreement. This is a judgment call, one that should be given to all administrators. I'd normally say 'crats, but we don't have enough. Another possibility is any reviewer can grant (but not remove) the reviewer flag. A noticeboard may be in order, but those are details we can work out later
• Sighting is not automatic, unless there is a reversion to a previously sighted version (if this can be implemented). Reviewers may sight their own revisions, a power that can be revoked quickly if abused.
• Reviewers are obligated to sight revisions that they disagree with but that do not violate BLP. Normal editorial practices must persist.
• 2 week trial period, targeting a cross section of BLPs and a couple non-BLP articles of various visibility OR 2 week trial of what I've described above.
• I have concern with the idea of giving priority to low activity articles is that those articles are the ones which are in the greatest need of improvement, and initial improvement (fact and content generation) often comes from IP and redlink users. Leaving an article barely readable isn't much more helpful than protecting it from drive by vandalism.

Lets get this show on the road.--Tznkai (talk) 16:55, 11 March 2009 (UTC)

Reviewers are obligated to sight revisions that they disagree with but that do not violate BLP. Normal editorial practices must persist. -- but if they disagreed, 'normal editing' would mean they'd revert it, would they not? Why should an edit be sighted and reverted, instead of just rejected, especially if the later takes less time? ♫ Melodia Chaconne ♫ (talk) 17:12, 11 March 2009 (UTC)

I understand you want to extend FP to many articles and have very high requirements on reviewers, but I think it is necessary to do just the opposite if we want consensus on this. Ideally only the most trusted users should review BLPs, but there is no way that the hundred or so that are really active on BLP issues will be able to watch over half a million BLPs + whatever other articles. Too strict requirements for becoming a reviewer also gives a strong impression of a cabal. With a lower requirements there will be bad sightings, but some improvement on BLP issues is better than nothing. Anyone who persistently sights libelous edits will have the sighting permission removed. (Addendum: Compare this proposal to semi-protection of all BLPs which is seen as quite extreme, but would actually make a rather low barrier to libelous edits)

I suggest automatic sighting after one week as a safety valve. If an edit is neither sighted or reverted in reasonable time, then the flagging system is failing. Hopefully it will never get to that.

As long as edits are sighted quickly it would not really stifle the improvement of new articles much at all. High-profile articles like Barack Obama on the other hand is likely to have a lot of edits and would swamp the reviewers when the edits are better dealt with by the regulars of that article.

I strongly agree with the spirit of Reviewers are obligated to sight ... Normal editorial practices must persist. One of Wikipedias greatest strengths is that every edit is accepted unless reverted. If somebody disagrees with an edit a little bit but not enough to revert, then it sticks. However, I don't see how it is practically possible. How would we prove that sighter A did not sight an edit because he disagreed with it, and that he didn't just miss it. --Apoc2400 (talk) 17:50, 11 March 2009 (UTC)

I'm less concerned with creating an enforceable mechanism than creating a cultural standard - a norm. The idea is that reviewers will understand that sighting is not a tool for editorial disputes - likewise, I'm very much ok with the idea that the reviewer flag is easy on, but also easy off: users are assumed to be trusted, but we're also willing to quickly remove the permission if there are problems. Is there a way where auto-sighted articles will show up on a separate list so volunteers can review them? Kind of like recent changes.

I'm still very concerned by the new and underdeveloped articles. Click random article a few dozen times, and you'll run into stubs that have been around and untouched since 2006, and I think Flag revving them will make that problem worse. I myself started out as an IP editor - and I imagine if I couldn't "see" my revisions, I may never have started getting into it, and thus never bothered registering an account 3 months later. With BLPs, that may have to be the compromise we make, but I hope someone can think of something clever instead.--Tznkai (talk) 21:02, 11 March 2009 (UTC)

We don't have consensus to use flaggedrevs arbitrarily on blps, and we won't have it. Let's face it, the blp survey, the trial discussions, all show it. Another discussion in this sense will end in no consensus and the community will be a little more tired of FlaggedRevs. We need to break the issue in two: one passive flag used for all blps, one active flag for certain blps, with a use defined by an appropriate protection policy. Cenarium (talk) 18:00, 11 March 2009 (UTC)

I do like your idea. The number of BLPs with active flagging can surely be increased over time if the system works well and edits are flagged in a timely manner. Tye last flagged protection proposal got shot down mostly by a bunch of pro-FR people who saw it as an attempt to water down FR. Today they probably realize it's either something like that or the status quo. --Apoc2400 (talk) 18:09, 11 March 2009 (UTC)

I think the problem is as follows: we need to improve our monitoring of blps, but we do not have consensus to use 'strict' FlaggedRevs arbitrarily for blps. We need to propose something that has a chance of being adopted. So, I think we could start by proposing the use of a passive flag for all blps, and use an active flag on a case-by-case basis, with use defined by the protection policy. It's what I propose in Wikipedia:Flag protection and patrolled revisions. See also this essay. Cenarium (talk) 17:43, 11 March 2009 (UTC)

Could you explain the difference between passive and active flagging to me? I'm not sure I know what you mean.--Tznkai (talk) 20:47, 11 March 2009 (UTC)

I think passive means after a certain time it gets flagged anyway. If so, I'm not keen on that idea. We should keep our backlogs down but every flagging should be on purpose. ++Lar: t/c 20:56, 11 March 2009 (UTC)

I think what Cenarium means with passive flagging is that flagging is enabled, but readers see the latest version, flagged or not. This does not have any direct effect on content, but gives us way to make sure that every edit to BLPs is checked.

Back to time limit, I think the best solution would be that if a revision is not flagged or reverted within one week, then flagging is temporarily disabled on that article. Readers will see the latest version until someone gets around to flag or revert. However, I don't know how difficult this would be to archive in software or with a bot. --Apoc2400 (talk) 22:22, 11 March 2009 (UTC)

My view on this is that I favor any partial measure that is likely to get implemented and that is not going to stand in the way of a better measure. That said I do not favor giving flagger or reviewer out under any process that does not involve review by humans. Mere edit count or tenure are insufficient. ++Lar: t/c 20:56, 11 March 2009 (UTC)

Passive flagging is the wet-dream of vandals, because once the default time has elapsed, nobody thinks it might be vandalised, because we have flagged revisions, don't we? :-) -- Kim van der Linde ^{at venus} 21:03, 11 March 2009 (UTC)

See above. Also: It only happens if an edit goes un-flagged but also not reverted for a week. --Apoc2400 (talk) 22:22, 11 March 2009 (UTC)

To do so is making it relative easy to vandalise. There is no objection that some content is not visible, there is objection to have bad content visible. -- Kim van der Linde ^{at venus} 22:48, 11 March 2009 (UTC) reply

Can you explain why getting review must be manual? It does create a very strong impression of a cabal. Reading through oppose comments to flagged revisions in the recent polls, I see a lot about FR giving too much power to certain groups. I actually think that even giving review right to IPs would be a vast improvement, as long as you can not review your own edit. --Apoc2400 (talk) 22:22, 11 March 2009 (UTC)

Let those with fears for the cabal deal with the shit then. Are they willing to do that? Can they do that. Let see how long Jimbo is willing to deal with piles of vandalism and corresponding news items because some people are afraid for the cabal. Really, opposing is easy, because it does not oblige you to anything. -- Kim van der Linde ^{at venus} 22:48, 11 March 2009 (UTC)

Make the "cabal" huge enough that it doesn't matter. I reiterate my support for easy on easy off.--Tznkai (talk) 00:12, 12 March 2009 (UTC)

(Undent) We're talking a lot about backlogs, without any understanding of how bad they are, because we have no data. How about turning on flagrevs for two months on a set number of articles (say, 3000 across a cross section of BLPs and other articles of varying profiles), getting a group of sighters, and seeing how fast the backlog grows?--Tznkai (talk) 08:45, 12 March 2009 (UTC)

Like some variant of WP:Flagged protection and BLPs? :) I keep being told that noone wants BLPs to be flagged any more strictly than other articles... Fritzpoll (talk) 10:42, 12 March 2009 (UTC)

Just imagine, flagged revisions will make it easier to deal with vandalism, and people are afraid that there will be a backlog in flagged revisions? That implies that the backlog in vandalism removal is even larger. And people are opposed to flagged revisions. I think the lost the overview of the complete picture. A test is not going to work to get an idea how much backlog will arise, because articles in such a test will have more people on it than the average article on wikipedia once it is implemented. -- Kim van der Linde ^{at venus} 13:26, 12 March 2009 (UTC)

I don't want to protect BLPs in any way more than others. I'd like the world to collectively get over it, read Wikipedia (and for that matter, mass news media) with a critical mind, check their own facts. I'd like a million strong army of volunteers well read on BLP policy going every revision with a finetoothed comb. That isn't going to happen, so flag revs will have to do. I'm honestly not concerned about simple vandalism, I'm concerned about "real" harm that can and I'm led to believe, does happen, to real people, because of inaccuracies on Wikipedia. Likewise, I'd like for Wikipedia to stop being used a tool for ne'er-do-wells and the malicious to do social violence unto others. Flagged revisions is a way to do that. I realize that any sort of trial cannot accurately replicate 2.7 million articles under flagged revisions, but any sort of pilot program and the subsequent experience and data is better than arguing on principle and ignorance.--Tznkai (talk) 13:52, 12 March 2009 (UTC)

Let's trying to compromise and find something that has a chance of being adopted here. If people refuses to do that, we'll necessarily fail, again. We know that the concept of using flagged revisions actively for arbitrary blps has no chance of gaining consensus: the blp survey, the trial discussions, etc, it's clear that proposing this will result in another no consensus and we will be in the same situation, with the status quo. What I propose is this:

• Using a passive flag for all blps (that is, it just act as checkpoints, doesn't act on edits but it sill allow to monitor blps)
• Make it "active" on a per-page basis, when ? being determined by a policy (to be merged in the protection policy, and initially with the same requirements).

See User:Cenarium/On FlaggedRevs for more on this. We won't receive much of the classic opposition to FlaggedRevs and it'll still be a huge improvement over the present situation. See the proposal. Cenarium (talk) 13:47, 12 March 2009 (UTC)

I'll proceed in three steps:

• bring Wikipedia:Flag protection and patrolled revisions to VPR and various FlaggedRevs/BLP-related forums for a preliminary discussion
• if there's some support for it, make a centralized discussion, work things out, address concerns, etc
• if there is a good support and a reasonable roll out strategy is found, watchlist notice to gather final consensus for implementation

Cenarium (talk) 16:55, 12 March 2009 (UTC)

Hold up. We're definitely not going to get anywhere unless we can actually educate editors on what Flagged Revs in general and I still don't understand what active and passive flagging is, and what the difference. Try explaining it like I'm reading Simple.--Tznkai (talk) 17:28, 12 March 2009 (UTC)

A passive flag will simply allow reviewers to flag a revision, but it won't affect the version viewed by readers. It means that we can monitor the pages, it'll give a list of all pages that have not been flagged, and changes to flagged pages (and it's filterable by category, so by Category:Living people). An active flag will affect the revision viewed by readers by default, it'll be the latest flagged revision.

My proposal is, broadly speaking, to use a passive flag for articles (and in practice especially for blps), and to "active it", on a per-page basis. When the flag should be "activated", should be determined by a specific 'protection' policy. It's also explained in this essay. Cenarium (talk) 17:52, 12 March 2009 (UTC)

I'm for the idea of passive flagging. I don't want the entire encyclopedia to have this, as it will create backlogs and other problems, but this way, it should make everybody happy, for the most part.Deavenger (talk) 20:17, 12 March 2009 (UTC)

I like your proposal Cenarium, but please write a very simple explanation of what passive flagging means. I understand it now, but it seems like everyone gets it wrong the first time. Also, do we really need "Full Flag Protection"? Normal full protection is still available. Also, what requirement for becoming a reviewer do you suggest? --Apoc2400 (talk) 21:04, 12 March 2009 (UTC)

If I understand this correctly, passive flagging would essentially create a list of articles that have not vetted by a reviewer yet, similar to how new page patrol works?--Tznkai (talk) 16:55, 13 March 2009 (UTC)

Passive flagging: More work, no benefits

Ok, if I understand it correctly, passive flagging mean that revisions are flagged, but that it does not have any effect on what the visitor gets to see. Correct? So, what is the benefit? All I can see is a load of work, for the case that the flagging is activated because of issues. So, why not leave the initial flagging till the moment it is activated, as a requirement for the admin who turns on the flagging? -- Kim van der Linde ^{at venus} 17:23, 13 March 2009 (UTC)

It helps focus our resources to make sure all edits are checked. If an edit is flagged then other people can skip and check other things. Also, we don't have to use it. --Apoc2400 (talk) 18:20, 13 March 2009 (UTC)

You needn't to flag all revisions. It's the advantage of being passive: there's no hurry and it's not terrible to have a backlog. It allows to monitor changes to all blps that have been patrolled at least once and to list all that have never been patrolled. At the present time, we have no way to do that so efficiently: we can't cope up with the level of editing blps receive. We only have recentchanges and a few disparate tools for that, a passive flagging would provide a structured and optimized monitoring system (by reducing the changes to check). Cenarium (talk) 22:08, 13 March 2009 (UTC)

It'd be nice, but I'd like something a bit more substantial.--Tznkai (talk) 22:14, 13 March 2009 (UTC)

In cases of blp violations on an article, an administrator can use an 'active flag' on this page, temporarily or indefinitely, as a protection measure. The precise use would be circumvented by a special protection policy. (I'll also comment in the Another idea section.) That's the idea behind Wikipedia:Flag protection and patrolled revisions. Cenarium (talk) 22:22, 13 March 2009 (UTC)

If there's no effect on what the reader sees and its just an internal note to other editors, then there's no motivation to actually do the work. Mr. Z-man 22:20, 13 March 2009 (UTC)

Our blps suffer from being too little watched and blpvios remain unnoticed... It'll allow to bring them to the attention of reviewers. Note also that reviewers are autopatrolled, saving us some work. Cenarium (talk) 22:26, 13 March 2009 (UTC)

It also wouldn't hurt. Perhaps we should split flagged protection and passive flagging into two separate proposals and run polls for both at the same time. As long as there is not a long list of "hardline" proposals as well we avoid the "I'm just voting no to everything related to flagged revisions" effect. --Apoc2400 (talk) 22:38, 13 March 2009 (UTC)

We have, essentially, watchlists and (linked)recentchanges to keep track of changes to blps. And only a few edits out of the total are actually reviewed, and we can't improve that much given our resources. Special pages like User:MZMcBride/BLPs or Category:Unreferenced BLPs list only those that have been noticed, and aren't dynamic or complete enough to provide an optimal monitoring system. A passive flag will allow to bring the attention of unnoticed or unaddressed ones (Special:UnpatrolledPages), and monitor changes to blps patrolled at least once (Special:OldPatrolledPages). A random BLP may be patrolled once every 5 or 10 edits, depending on visibility and editing volume, but it'll still allow to reduce the availability to readers of a blp violation, and notice those that suffered from repeated blp violations, so that we can flag protect them. Actually, it's less effort to check a diff (that may contain several intermediary edits) and click on a patrol link if it's ok, or investigate further if not, than checking edits one by one on the watchlist or via history. And it'll save time for other users who would have checked the edits. Cenarium (talk) 22:50, 13 March 2009 (UTC)

Wikiproject based implementation?

Ok, I am thinking, what about a wikiproject based implementation. Suppose, that the wikiproject XXX has agreement among the regular editors who do most of the checking that they want to implement flagging, so that they have more time for more sensible things than vandal whacking. Would that be acceptable for the community? -- Kim van der Linde ^{at venus} 17:24, 13 March 2009 (UTC)

Nay. I'd rather not formalize Wikiprojects as part of our bureaucracy. Wikiprojects have no governing policies or even norms, and zero consistency in quality and participation. Not to mention a nightmare waiting to loom at the intersection between multiple projects. Another drama filled noticeboard would actually be less dramatic.--Tznkai (talk) 17:36, 13 March 2009 (UTC)

No, wikiprojects don't own articles. --Apoc2400 (talk) 18:21, 13 March 2009 (UTC)

Support if done right. I don't think all the negatives above apply - most intersections are not turf wars, and I don't think Kim was saying WikiProjects "own" articles, only that they should patrol them - but WikiProjects also care about keeping a specific group of articles in good condition. I would propose that WikiProjects be asked to help in patrolling articles under their purview, as a way of supplementing the centralised system being proposed. However, even a fully WikiProject-organised system would get my vote, if organised well. Walkerma (talk) 03:01, 15 March 2009 (UTC)

Another idea

Not my preferred proposal, but I'm trying to find a consensus point here.

Flagged revision capability is turned on wiki-wide, accessible from the protection button. Administrators may turn on flagged revisions for any individual article to address.

• BLP violations on high profile articles (high visitor traffic)
• BLP violations on low activity articles. These articles are subsequently tagged for a new type of clean up in some sort of attempt to get them adequate expansion.
• Extensive vandalism or edit warring that would normally be addressed with full protection.
• By consensus for any article.
• By and large, flagged revisions will be treated similar to protection.

This I believe, is very similar to WP:Flagged protection except that the controlling policy would be targeted at BLP problems and long term vandalism, and is in no way linked to semi-protection. The essential goal here is not to control edit warring or vandalism per se, but to ensure the outward face to the public remains stable and safe.--Tznkai (talk) 17:49, 13 March 2009 (UTC)

This is weaker than what I have proposed previously, but is a step in the right direction, and so is a compromise that I can support. The only thorny question is - who can review? Fritzpoll (talk) 17:56, 13 March 2009 (UTC)

I would prefer a higher standard than rollback, but lower than adminship, but at this point I'll accept anything so long as sighting is removable and logged.--Tznkai (talk) 18:05, 13 March 2009 (UTC)

Agreed - we can decide these details in flight. If the initial system doesn't work, it can always be changed. Let's just get on with it Fritzpoll (talk) 18:11, 13 March 2009 (UTC)

Can work, and I am in favour of giving everybody with rollback also flagging opportunities, and you can loose those them easy as soon as you are caught misusing. I am pretty siure that once it is implemented and people get used to it, they will love it. -- Kim van der Linde ^{at venus} 18:17, 13 March 2009 (UTC)

Yes, it should be easy to loose the review right. You don't need it for editing, so it's not a right. --Apoc2400 (talk) 20:09, 13 March 2009 (UTC)

It shouldn't be contained in the rollback usergroup, because sometimes, users are granted rollback while they are not even autoconfirmed ! It's really a tool-like right. Of course, we can revisit this later. But for now, I think they should be separate. When a user asks for rollback at WP:RFR, and an admin thinks the user would make a nice reviewer, it could be proposed or granted to the user in the same time. I still think we should keep the autopromotion to reviewer rights relatively high, then consider lowering it later (because, when we have given the rights too largely, it's hard to repair this, but it's easy to lower thresholds). It could also be requested at WP:RFR. Cenarium (talk) 00:06, 14 March 2009 (UTC)

I like this proposal also. Let's implement it now. Deavenger (talk) 20:50, 13 March 2009 (UTC)

That would be for the policy matter, but which implementation should we use ? I propose Wikipedia:Flag protection and patrolled revisions because it's a versatile implementation, that can be adapted to consensus. For example: autoreview is enabled by default for autoconfirmed users, but can be disabled on a per-page basis. The original flagged protection implementation also had no reviewer user group (it was any autoconfirmed user). Consensus will also say where we should use semi flag protection. Consensus will say where we should disable autoreview, and where we should use full flag protection (disputes for the most part). But this is a policy matter, that I don't want to explicitly state in the proposal, for now. Let's wait to see if we have consensus for it implementation, then only discuss policy. Do you agree with this approach ? I should also mention that I merged the idea of a passive flag with the proposed implementation, although we can also consider them separately. Cenarium (talk) 22:54, 13 March 2009 (UTC)

A controlling policy has to come along with technical implementation, even if the controlling policy is vague. If flagged revs is going to be "sold" to the public, we need to have a clear explanation of what we're doing.--Tznkai (talk) 22:56, 13 March 2009 (UTC)

The problem is that if we propose a too strong policy along with the proposed implementation, then it'll be opposed, to the point we won't have consensus. So I prefer to start by gathering consensus for an implementation, of course with an outline of how we're going to use it, and when we have consensus for the implementation, agree on a specific policy. So that we should proceed in this order:

1. Gather consensus for a certain implementation, outline its use, then:
2. Gather consensus for a specific policy on how to use it, then:
3. implement the implementation, with use determined by the policy.

Now, we should consider whther Wikipedia:Flag protection and patrolled revisions is an acceptable implementation for what we want to do with FlaggedRevs. Cenarium (talk) 23:14, 13 March 2009 (UTC)

If we learnt anything from the recent polls it is that people want to know what they are voting for. Please do not leave anything for later consensus. If we do, people will assume the worst and vote against. Of course anything can be changed by later consensus, but the proposal must have a defined starting point. --Apoc2400 (talk) 23:25, 13 March 2009 (UTC)

That's true. In fact, we should really present this as a trial, and note that, say, two months after the implementation, a community discussion will happen on whether we should continue with the implementation, modify it, or completely disable it. With the understanding that the policy should be the same for the two-month trial period, then that after that, of course, we are free to change it based on consensus. Based on an idea of Apoc2400, I think we could outline the use like this:

• "For the trial period, the requirements for applying semi flag protection to an article are the same as for semi-protection, but it can be applied more liberally to biographies of living people as long as the review backlog is short."
• "For the trial period, the requirements for applying semi flag protection with autoreview disabled to an article are those for semi flag protection with additionally, evidence that the disruptive actions are due to autoconfirmed users (sockpuppetry considered)."
• "For the trial period, the requirements for applying full flag protection are the same as for full-protection."

Then if the implementation is accepted, we can work out the details of the policy, before the implementation. Cenarium (talk) 23:54, 13 March 2009 (UTC)

Too complicated: lets keep it simple, with only one kind of flagging for now. Most people don't know flag revs do, let alone what semi flag protection would be.--Tznkai (talk) 01:02, 14 March 2009 (UTC)

If I made this more complicated, it's in order to satisfy everybody. If we don't allow autoreview for autoconfirmed users by default, people will find it too restrictive. If we allow autoreview for autoconfirmed users, people will find it too lenient. And we just can't treat disputes the same way we deal with normal vandalism, since reviewers would presumably be involved in the disputes. We can avoid going into unnecessary details, but those three levels are needed for a viable implementation. Cenarium (talk) 01:17, 14 March 2009 (UTC)

I disagree, but its entirely possible its because I don't fully understand your proposal. I think its either too complicated, or you haven't explained it clearly, or some combination of the two.--Tznkai (talk) 01:32, 14 March 2009 (UTC)

If we use semi flagged protection for disputes, and if reviewers are involved in the dispute, it won't have any effect: since their edits will be automatically flagged or they'll flag their edits, or unflag the edit of others, so this would trigger flag wars. So we need to use a higher flag: that only admins can use: they 'validate' a revision when it's consensual or non-controversial compared to the latest validated. That would be full flag protection, the equivalent of full protection.

Now, we have the choice between automatically reviewing edits by autoconfirmed users (if the previous revision is), or not. If we choose to do so, people will say that it's too lenient or inefficient for some cases, that it can't help with persistent sockpuppetry, POV-pushing, etc. So we would have to use more of full flag protection, which would be bad because it would restrict editing for more people and overburden admins. So people would oppose.

On the other hand, if we disable autoreview for autoconfirmed users, people will say that this is even more restrictive than semi-protection, that in most cases, this is not necessary, etc, and they'll oppose.

So I propose to autoreview autoconfirmed users by default, but to have the option to disable this: so that it pleases everyone. Cenarium (talk) 01:49, 14 March 2009 (UTC)

I don't think flagged protection should be used to solve disputes. If autoconfirmed users are edit-warring then we have normal full-protection. Also, those who oppose low requirements for becoming a reviewer will also oppose auto-flagging for autoconfirmed users. On the contrary, the requirements to have your own edits auto-flagged should be higher than for flagging other peoples edits. In my opinion, we should have only one level of flagged protection, rather low requirements for become a reviewer, but edits by autoconfirmed users should not be auto-flagged. Edits by bots, admins and perhaps reviewers can be auto-flagged if the previous revisions is flagged. --Apoc2400 (talk) 09:42, 14 March 2009 (UTC)

The idea of flagged protection has been accepted by most traditional opponents of FlaggedRevs because it is more permissive than semi-protection. If we don't autoreview autoconfirmed users, they will oppose, especially if it's intended to be used more widely than semi-protection. But there is an option to deactivate autoreview for non-reviewers, so why only wanting one when we can have both ?

Those who oppose low requirements for reviewers won't oppose that much to autoreview precisely because there is the option to turn it off. And they should also note that edits by autoconfirmed users can also be checked via patrolled revisions. Flagged protection is really a measure of protection, not that much of monitoring.

Disputes are not limited to edit-wars, and full protection is not only used for disputes. Some full protections are long-standing, and thus harmful, having an alternative to full protection would be very appreciable. It would also be an entirely new way to handle disputes, more wiki-like, new revisions would be validated when consensual or non-controversial, it would help in the development of consensus. Maybe it won't work all the time, but it's a progress, and certainly worth a trial. Cenarium (talk) 15:05, 14 March 2009 (UTC)

Can you explain what objections you have to the idea I posted up above?--Tznkai (talk) 18:37, 15 March 2009 (UTC)

The requirements appear relatively low for using flagged protection (or imprecise), and thus we'll have opposition straight away for that. I think we should start progressively (my interest is to have the support from as many people as possible, to have consensus for an implementation). The requirements for the two-month trial should be the same than for normal protection, if possible with a more liberal use for blps. And after the trial period, we should discuss the requirements again, and build a special flagged protection policy. I'd oppose the use of a single flag also, for the reasons mentioned above.

But we can run several trials in the same time with the implementation I proposed. I designed it specifically so that it can be largely adaptable and so used for a variety of trials. You can try to gather consensus for your proposed trial. Cenarium (talk) 19:42, 15 March 2009 (UTC)

Alternative: Time-limited invisibility

Please see Wikipedia talk:Flagged protection and patrolled revisions#Alternative: Time-limited invisibility. - 7-bubёn >t 15:02, 18 March 2009 (UTC)

Wikipedia:Flagged protection and patrolled revisions

It is proposed to run a trial of Flagged Revisions at Wikipedia:Flagged protection and patrolled revisions. The proposal is divided in two parts:

• Flagged protection: an article can be 'protected' by an administrator so that the version viewed by readers by default is the latest flagged version. This is a modified version of the original flagged protection proposal.
• Patrolled revisions: a 'passive' flag used to monitor articles, especially blps, for vandalism, blp violations, pov pushing, etc, that can be used for all articles, but has no effect on the version viewed by readers.

The proposals are independent but supplement each other. They involve the creation of a 'reviewer' usergroup. This implementation can support secondary trials. The main trial should run for two months, then a community discussion should decide the future of the implementation. Cenarium (talk) 22:51, 15 March 2009 (UTC)

A poll has started at Wikipedia talk:Flagged protection and patrolled revisions/Poll. Cenarium (talk) 18:33, 17 March 2009 (UTC)

This poll is scheduled to end on 1 April 2009. Cenarium (talk) 21:57, 28 March 2009 (UTC)

Rewrite

I have rewritten this page to keep it in line with recent developments, and added info on WP:FLPPR, as this proposal has gained consensus for a trial implementation. Cenarium (talk) 16:48, 11 April 2009 (UTC)

Poll on reviewer autopromotion for flagged protection and patrolled revisions

There is currently a poll on the autopromotion of reviewers at Wikipedia talk:Reviewers#Poll on autopromotion, for the trial implementation of flagged protection and patrolled revisions. For information, see general documentation and overview. All users are invited to comment, and to participate in the elaboration of a reviewing guideline as well. Cenarium (talk) 13:49, 12 April 2009 (UTC)

Question

Has there been a consensus on when/if we're having a trial for this? Just wondering. Jwkpiano1 (talk) 03:28, 19 May 2009 (UTC)

No. Nothing ever happens at the Grand Hotel. -R. S. Shaw (talk) 20:31, 17 June 2009 (UTC)

Do we have all the experts here

Do we seriously consider that, all the reviewers will be experts in all topics or is it just the keeping off the vandals that is the underlying objective? We must consider that, an expert in say on Mining topic shall sit by his PC and wait for his stuff getting approved or may be wait for someone to visit his edit. We may lose on other things which one might want to share out of sudden instinct and spur of moment and may be a valuable piece of information. I franky do not believe that the pace with which the world is building around, the bureaucracy imposed by flagging shall limit the pace of development to the capacity of bottleneck. A lot of articles and headings need revisions and expansions and who has the time to get stuff approved. Roles of admin as defined should be crusaders or barriers is athing that needs decision. Trust or distrust needs to be decided as well. Vertical.limit (talk) 08:55, 17 June 2009 (UTC)

While the terms of promotion to reviewers is I believe unclear, there is almost no chance that reviewers will have to be in a specific topic area. Also there is no need for anyone to sit by their PC, non-reviewers will simply submit referenced material as normal, reviewers will simply approve it when they see it. I'm not sure, but perhaps you are under the mistaken impression that when an article is awaiting review it can't be edited. This is not the case. Nil Einne (talk) 06:31, 18 June 2009 (UTC)

Analysis on German Wikipedia

Has there been an analysis done of FR on the German WP? They have had it in operation for just over year so there should be enough data around in order to do it. -- Alan Liefting (talk) - 11:08, 21 June 2009 (UTC)

Wikipedia: The free encyclopaedia that anyone who behaves can edit

Wikipedia: The encyclopaedia that anyone can edit is a frequent used argument against flagged revisions, but is it actually true? No, when you do not behave, you can get blocked, banned, and your edits will even be actively undone if you evade your ban. So, the slogan should be rewritten to Wikipedia: The free encyclopaedia that anyone who behaves can edit. So, who will be affected by flagged revisions? Those that we smack around already anyway. if you add libel to the project, we ride your ass. if you vandalize, we ride your ass. And if you behave, you quickly enough get the opportunity to flag revisions yourself. So, the major difference is that if you are new, you have a period in which your edits are not immediately visible for the world at large, but when you behave, it will be fast enough that way. Is this small window really the major reason many hold flagged revisions up? -- Kim van der Linde ^{at venus} 18:05, 13 March 2009 (UTC)

I speak for the anonymous IP editors, whose interests I am concerned for in that they are the farm from which we get new editors.--Tznkai (talk) 18:10, 13 March 2009 (UTC)

That's true, but this would be a method for filtering out those whose intentions are good. I'm sure a well intentioned IP editor understands the need for some control as well as you do. 122.49.135.223 (talk) 22:35, 13 March 2009 (UTC)

In my opinion good intentions and self-control may not go together. An editor may have good intentions but be quick-tempered. In fact I was quick-tempered at the early stages and only now I try to keep cool in the heated debates. SkyBon^{Talk\Contributions} 12:35, 26 July 2009 (UTC)

You may claim to speak for them... but I don't think you're properly representing all of them, you need to speak on behalf of the vandals and unsourced content editors, and defend their actions, or you only speak for a subset. Statistics I've seen but can't recall the location of at the moment show that contribution types skew... anons are responsible for more problematic edits on average, per edit, than registered editors are. ++Lar: t/c 11:37, 15 April 2009 (UTC)

I'm not going to bother editing Wikipedia if my changes aren't visible to me and others immediately, and I think this will apply to most people, really. So for the articles this is implemented for, this basically means shutting off edits from and alienating the large group of "Hey, I have some information that could improve this article! I think I'll just go ahead and add it."-users, who only edit once or twice, and only because it is so easy to edit.

It has been my impression that these users really are the lifeblood of Wikipedia, both being a source of a large fraction of the total information here, and also forming the pool from which more experienced editors are recruited. This group is also responsible for most vandalism by far, 'tis true, but this doesn't mean that its contributions aren't important. In my opinion, a fit analogy for implementing this widely is "sawing off the branch one is sitting on".

Finally, let me point at Nupedia, and point out that it didn't take off (becoming Wikipedia) before the heavy editing restrictions were lifted. 84.208.81.75 (talk) 07:31, 25 August 2009 (UTC)

Wikipedia with flagged revisions would not be directly comparable to Nupedia. The big restriction at Nupedia was that only credentialed 'experts' could edit, which greatly restricted the pool of potential editors. The English Wikipedia will still be open to anyone to edit, but it may be a while before the edits become visible to readers. Will that discourage some 'good' editors? Yes, quite possibly. Will it dramatically reduce the crap edits (vandalism, promotional edits, jokes, trolling, POV edits, etc.)? I'm sure it will. -- Donald Albury 13:40, 25 August 2009 (UTC)

"It has been my impression that these users really are the lifeblood of Wikipedia", most IP users are vandals; not opinion but actual fact, that has been analysed time and again. Wikipedia has restrictions at the moment, IPs can't create articles, can't edit protected pages and can't vote on certain community pages. The flagged revisions will take a layer of protection off, meaning IPs can edit more, but that their edits will not be visible immediately. This means that they can still edit, and can edit more pages but the thrill of seeing graffiti on the wall for vandals will be curtailed, which will mean less need for editors to waste their time reverting vandalism, which means more time to actually edit. Wikipedia doesn't need hundreds of new articles, it needs the currnet ones ot be improved. Darrenhusted (talk) 16:26, 25 August 2009 (UTC)

Can you link to one of those analyses please? Thanks! --Falcorian ^(talk) 16:45, 25 August 2009 (UTC)

Actually "most IP users are vandals" is wrong. It has been demonstrated that most vandals are IP users, but that's not the same thing. Only about 20% of edits made by unregistered users are reverted. I should also point out that only about 0.1% of articles are protected, and nearly half of those have some sort of expiry date. Implementing flagged revisions on all articles would open up a tiny number of pages while closing off a huge number of others, so claims that it will actually open up Wikipedia are also wrong. The number of people blocked for vandalism on the German Wikipedia didn't drop after flagged revisions was introduced, so it won't necessarily reduce the number of vandals either. Hut 8.5 18:11, 25 August 2009 (UTC)

Noone said FRs would be implamented on all articles. It'll mainly be a replacement for (semi-)protection. ♫ Melodia Chaconne ♫ (talk) 18:22, 25 August 2009 (UTC)

NY Times reports on Flagged revisions for BLP

I just saw this in the NY Times online:

Officials at the Wikimedia Foundation, the nonprofit in San Francisco that governs Wikipedia, say that within weeks, the English-language Wikipedia will begin imposing a layer of editorial review on articles about living people.

The new feature, called “flagged revisions,” will require that an experienced volunteer editor for Wikipedia sign off on any change made by the public before it can go live. Until the change is approved — or in Wikispeak, flagged — it will sit invisibly on Wikipedia’s servers, and visitors will be directed to the earlier version.

--SteveMcCluskey (talk) 21:38, 24 August 2009 (UTC)

On-line at Wikipedia to Add Layer of Editing to Some Articles -- Donald Albury 22:43, 24 August 2009 (UTC)

I saw that article and am confused; will this policy only affect pages that would previously have been semi-protected? Or all pages about living people?--Lkjhgfdsa (talk) 23:01, 24 August 2009 (UTC)

I understand it to mean that flagged revisions will apply to all BLP articles. This makes sense, given the growing concern for keeping harmful misinformation out of BLP articles. -- Donald Albury 00:00, 25 August 2009 (UTC)

No, the media don't get things right as usual with wp. It'll be applied only for pages meeting the requirements for semi-protection, only a little more liberally for BLPs because there's a limited admin discretion. This is what the community approved : Wikipedia:Flagged protection and patrolled revisions, nothing else. Cenarium (talk) 18:52, 25 August 2009 (UTC)

Not sure if it's entirely relevant, but Mashable (a popular social media blog) just published a story about Flagged Revs: [7]. VI ^talk 23:17, 24 August 2009 (UTC)

Slashdotted as well. Titoxd^{(?!? - cool stuff)} 05:42, 25 August 2009 (UTC)

There needs to be an easy-to-read FAQ targeted toward to the media and the laymen about the changes being proposed. Common questions include: which articles will this effect, who approves the edits, is this permanent, etc. Again, make it clear and concise and it'll help prevent some of the misinformation being spread. Mahanga^Talk 19:25, 25 August 2009 (UTC)

We don't seem to have any official confirmation of which configuration is being implemented, we can't write an accurate FAQ without it. Hut 8.5 20:00, 25 Aug.ust 2009 (UTC)

See information [8]. There is now a lab setup that will be used in the coming weeks as a testing grounds. There is still no fixed schedule as to when the english wikipedia will enable flagged revisions. —TheDJ (talk • contribs) 20:35, 25 August 2009 (UTC)

"Per the wikisignpost twitter, @wiki_nihiltres has a Flagged Revisions primer. May clear up some of the widespread media confusion/misreporting." Mahanga^Talk 14:01, 26 August 2009 (UTC)

• FWIW, there are still close to 1,000 BLP UnCat items, and over 23,000 Bio articles w/o a "Living=" parameter. Does anyone know if they will get added to the FR automatically when properly assessed? (provided that FR gets implemented prior to the completion of those two items). link — Ched :  ?  15:10, 26 August 2009 (UTC)

There has been a post written about Flagged Revisions on the Wikimedia Blog. --Falcorian ^(talk) 16:15, 26 August 2009 (UTC)

Manual vandal-whacking enriches Wikipedia

Fixing obviously wrong information is one of the lowest-bar activities able to be performed on Wikipedia. Both my own experience, and the anecdotal experiences of others I know, suggests that performing a fix on obviously wrong content can be a good catalyst for getting people familiar with Wikipedia editing and lead to them becoming a valuable member of the project. Let's not be quick to assume that, even were a method of preventing vandalism that has zero false positives to be available, that it would enrich the project. (Besides which, I like vandal-whacking. It's nice that not everything has to be a struggle to cite policy or find sources; sometimes you can just be right.) - DustFormsWords (talk) 04:53, 6 November 2009 (UTC)

That is an excellent argument. I agree. Whatever happened to Flagged Revisions, anyway? I saw an article in a major newsmagazine today that listed Flagged Revisions on Wikipedia as one of the things that happened in 2009. Did they get that one wrong? All Hallow's Wraith (talk) 16:55, 7 December 2009 (UTC)

I find vandal-whacking to be a deeply frustrating activity. It's so obviously necessary, there are so many of them, and despite the many forms it takes, they show no creativity whatsoever. I would enjoy Wikipedia more with fewer vandals to whack. --Alvestrand (talk) 18:10, 7 December 2009 (UTC)

Looking for more information about legal question

A while ago, I asked a question about flagged revisions putting legal burden on those who green-light revisions. (The discussion is here Wikipedia talk:WikiProject Flagged Revisions#Legal question about flagged revisions.) I feel this question is directly raised by the stated purpose of flagged revisions to protect biographies of living people from libelous content. Yet the only response I got to my question was a single, "We don't know"-type answer. This was disappointing.

I haven't followed the issue every day. I hope some information related to the answer has appeared in the meantime; so I was wondering if anybody has some links to other discussions that try to answer this specific yet fundamentally important question. I find it beyond belief that the Wikimedia Foundation can be on the verge of making a change like flagged revisions yet not have a (very good) answer to somebody worried that they are setting themselves up for a legal trap. Jason Quinn (talk) 23:00, 18 December 2009 (UTC)

Real-live article example

Damir Ibrisimovic has an idea for rewriting the perception article which involves mechanisms for locking data on pages. Sounds like flagged revisions, no?

If possible, we would like to use the Wikimedia labs machinery to create the rewritten article. I logged in and it looks like editing can occur now. It just wouldn't be prime time as it would be on the encyclopedia. But Damir Ibrisimovic might be just as happy using the machinery as it stands. It would also serve as proof of concept at some level. --Ancheta Wis (talk) 02:41, 10 February 2010 (UTC)

At what point do we stop being a wiki?

A wiki is "a website that allows the easy creation and editing of any number of interlinked web pages." I wonder, as we introduce more restrictions and review processes before a created or edited page can go live, at what point do we cease to be a wiki and become just one of the many non-wiki sites out there (e.g. newspapers that invite letters to the editor) that review content submissions and posts the ones that they accept? There are a lot of sites, like MySpace, that only allow users to freely edit certain pages, while others are under the control of site administrators, although you can give them suggestions on what to put on those pages. There might come a point at which Wikipedia is less like a wiki than many of the Internet that we don't normally consider to be wikis. Tisane (talk) 19:34, 25 March 2010 (UTC)

There is no point where that happens for the wiki. Flagged revisions is switchable on and off for individual articles. When/if an article is by consensus finished, would you still want vandals editing it? Would you still want people that have a 99.99% chance that they cannot improve an article because there have been tens of thousands of people editing it already, would you want to allow them to still edit it directly?- Wolfkeeper 20:05, 25 March 2010 (UTC)

The point of the project isn't to create a wiki anyway, it's to create an encyclopedia.- Wolfkeeper 20:05, 25 March 2010 (UTC)

There are plenty of wiki's with far more restrictive policies then we'll ever have. For example, some are only editable by a very small number of editors, without any registration system (commercial sites and some university sites for example, e.g. [9] or the US intelligence agency wiki). Nil Einne (talk) 18:58, 4 April 2010 (UTC)

FlaggedRevs is a MediaWiki extension, released on June 4, 2008

It was released in June 2008? Why hasn't this been implemented yet, then? Are these part of the marvellous "teachings" of the Foundation that will purportedly make the other wiki communities "more efficient and educated"? SalaciousBreadcrumb (talk) 18:11, 15 January 2010 (UTC)

Well (a) it took a while to get consensus on whether to use the feature and what to use it for on this wiki, and (b) the implementation that eventually gained consensus hasn't been finished by the developers yet. Hut 8.5 19:25, 15 January 2010 (UTC)

Then why don't make a "closed beta" for the whole project, which isn't indexed thorougly by search engines? The most likely answer is "because JimboMimbo can't get money", but that follows greed, not honesty. SalaciousBreadcrumb (talk) 20:02, 15 January 2010 (UTC)

There is already a open beta of the FlaggedRevs extension [10] as discussed in this very wikipedia page since October 1 so to be honest I'm not really sure what you're talking about. Forking en.wikipedia and implementing the beta flagged revisions on one of the forks is a rather silly idea if that's what you were suggesting. Although there's only one developer working on the project it's been stated the reasons for the delay have little to do with funding and adding more isn't going to help. Nil Einne (talk) 19:02, 4 April 2010 (UTC)