Wikipedia talk:Flagged revisions/Trial/3

One consideration I think people are missing

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

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

possible mathematical analysis to be done?

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

“

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

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

”

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

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

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

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

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

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

Autoreview period

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

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

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

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

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

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

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

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

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

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

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

Watchlist?

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

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

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

Just a thought...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I would just like to say, YES, this is the ONLY flaggedrevs proposal I support, I switched my vote after hearing about this, as it actually HELPS the wiki atmosphere by opening semiprotected pages for anon and new user editing. I am very interested in watching this go forward.--Res 2216 firestar 18:39, 11 January 2009 (UTC)[reply]

Purpose?

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

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

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

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

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

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

Legal liability of Reviewers

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

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

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

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

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

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

Two things:

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

Test page?

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

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

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

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

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

And when editing the page the following is displayed:

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

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

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

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

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

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

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

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

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

Revision divergence (forking)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

in a primary article view:

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

in an edit session:

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

One general comment

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

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

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

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

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

Comments from DE-WP

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

Some preliminaries:

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

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

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

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

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

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

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

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

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

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

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

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

To my opinion (based on the experience in German WP), it's quite important to implement some tests to evaluate major expectations on impact of FR. Furthermore, it might help to reduce a lot of discussions on interpreting influences of FR. --Septembermorgen (talk) 12:50, 21 January 2009 (UTC)[reply]

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

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

Limiting the revisions to flag for large-scale implementations

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

Not a panacea

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

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

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

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

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

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

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

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

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

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

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

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

My view on stable versions

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