Jump to content

Wikipedia talk:Flagged revisions/Trial: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
→‎Oppose: question
Line 460: Line 460:
:Firstly, I could just as easily imagine someone getting a kick from seeing his/her edits immediately, as from seeing that another human being has agreed that those edits improve the Free Encyclopaedia.
:Firstly, I could just as easily imagine someone getting a kick from seeing his/her edits immediately, as from seeing that another human being has agreed that those edits improve the Free Encyclopaedia.
:Secondly, have a look at a page that has not yet been checked. The 'edit this page'-link at the top of the page will presumably read 'edit draft', and will allow you to edit the unchecked version, even showing you what (unchecked) edits were made since the last review. Have a look, experiment a bit. I think this should answer several of your questions. -- Ec5618 17:32, 3 January 2009 (UTC)
:Secondly, have a look at a page that has not yet been checked. The 'edit this page'-link at the top of the page will presumably read 'edit draft', and will allow you to edit the unchecked version, even showing you what (unchecked) edits were made since the last review. Have a look, experiment a bit. I think this should answer several of your questions. -- Ec5618 17:32, 3 January 2009 (UTC)

::These are good questions. The first is very simple: the edit box always contains the latest version of the page wikitext, so there is never any conflict there; editors are editing the current version, whether or not they saw it on the 'view' screen. If there are differences, they are shown in a diff above the edit box, so editors will always know that they've either seen the latest version, or what the changes between the version they saw and the version they're editing are. This would allow them to see, for instance, if a change they wanted to make has already been made. If you're able to sight the page, then after you've made your edit you'll be invited to review the latest changes. A diff will show you all the changes made on top of the most recent sighted revision. If some of them are vandalism and others not, you may need to make another edit to revert only those vandal edits, but you'd need to do that with or without FLR (and with the system, you have a diff at the top of the screen to show you exactly what you're looking for). Once you're in a position where you're happy that the diff between the last sighted version and the current revision contains only positive changes, you can click a button to sight it (and by implication, all the edits before it). You don't have to sight each edit individually; they're sighted ''versions'', not sighted ''edits''.
::We're all aware that the 'buzz' an IP gets from seeing their edits straight up in blinking lights is one of the things that is going to be lost with FlaggedRevisions. However, remember that that buzz is not always a good thing: I'm sure a large proportion of vandal edits are motivated by exactly the same instant gratification. Although obviously I can't put any hard evidence to it (''yet'' <tt>:D</tt>), I hope that the two additional low hurdles (creating an account to see current versions, and getting some sort of reputation to get the <tt>'reviewer'</tt> flag) will actually ''encourage'' people to make the transition from being the IP who makes the once-in-a-blue-moon spelling correction, to the registered user who makes the occasional gnome edit, to the fully-fledged editor who is an active part of the wikipedia community. I think our encouragement of existing editors is quite good; our biggest chokepoint is in getting IPs to register in the first place. I hope that this will actually ''help'' to get them on the map.
::On a technical level, yes, we could give all registered users the ability to sight revisions. However, I don't believe that this would be beneficial. IIRC the numbers you quote at 90% are actually closer to 60%; certainly there are a ''staggering'' number of vandal edits that do not come from IPs. Sockpuppeteers, hardcore vandals and even casual vandals who use accounts purely to hide their IP addresses, all demonstrate that it is not possible to say with any certainty that all, or even an acceptable majority, of registered users are trustworthy. I would be very hesitant even to put my chips down to say that an acceptable majority of autoconfirmed users are trustworthy. In my opinion, this level of 'trust', which is really very low, is the lowest that requires the human touch; a review (however brief) by a real person who we've already determined to have coherent judgement. Certainly <tt>'reviewer'</tt> should be granted very liberally indeed, to almost everyone who asks for it. But I think that having to make that step of submitting a request is important, for two reasons. Firstly, it encourages editor development, as noted above; making a foray 'backstage' is an open door to innumerable 'force multiplier' tools and features that will make them a more durable (less likely to drift away) and effective editor. Secondly, it weeds out the casual vandals and blatant undesirables (spammers and SPAs in particular). All in all, I strongly believe that a lightweight ''human'' review for <tt>'reviewer'</tt> is an essential component of a successful FlaggedRevisions implementation.
::I hope this answers your questions, or at least gives my perspectives on them. Feel free to ask if anything needs further clarification. <font color="forestgreen">[[User:Happy-melon|'''Happy''']]</font>‑<font color="darkorange">[[User talk:Happy-melon|'''melon''']]</font> 17:39, 3 January 2009 (UTC)

Revision as of 17:39, 3 January 2009

RfC on implementation

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

I think this kind of trial is a good idea, since without it, we'll never have the evidence for an informed discussion of the implementation of the extension and its effect on Wikipedia. That said, I think that the current proposal does not say enough about how limited the trial will be. I may well have read it incorrectly, but it seems as if surveyors will be able to mark pages flagged indiscriminately suring the trial. Is this the intention, or is there meant to be some limitation in scope? Fritzpoll (talk) 11:36, 15 December 2008 (UTC)[reply]
Technically they can mark any page in the main space or portal space. However their actions, of course, will be limited by the relevant policies by the mandate that the community will give them. One of the proposed trials is to enable Flagged Revisions over featured articles and portals (see here). This proposal is just a technical framework: specific trials should be discussed separately. Ruslik (talk) 12:20, 15 December 2008 (UTC)[reply]
Sounds fine then - I can't see anything wrong with the proposal as it stands. Fritzpoll (talk) 12:39, 15 December 2008 (UTC)[reply]
Fritzpoll, you haven't done any newpage patrol at all. You have no idea what sort of backlog this sort of thing creates. Even if we just limit it to cursory skims of newpages, we wind up with, literally, weeks of backlog, and almost no one helping. DS (talk) 04:18, 20 December 2008 (UTC)[reply]
I can assure you that I have done newpage patrol. Just not in the past 2-3000 or so entries in my logs thanks to a couple of lengthy runs at Huggle and spells of blocking/unblocking. Unless you viewed the entire log you wouldn't know this, which is fair - of course, it means there was no basis to your assertion either, which is not as fair :) I am fully aware of the never ending backlogs in this place, but there are ways around it, the most obvious of which is not to implement it over every single article, just over some of our more vulnerable ones. Best wishes, Fritzpoll (talk) 08:32, 20 December 2008 (UTC)[reply]
Ah, my apologies - I misread your log. My overall point stands, though: in the year since the implementation of the newpage patrol flag, which is analogous to the revision patrol flag, thousands and thousands of articles have gone unpatrolled. DS (talk) 14:44, 20 December 2008 (UTC)[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)[reply]

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

That is indeed a perennial objection to the concept of FlaggedRevisions, but it is based on assumptions: while those assumptions are sensible, and may apply to en.wiki, you simply cannot say so with certainty until we have tried. The "don't give an inch or they'll take a mile" stance is not really applicable here because taking the second inch (having the implementation extended across the whole wiki) is no easier than taking the first (having FlaggedRevs installed at all). Both require developer intervention and so cannot occur without consensus. So I don't think you're being fair to say that "a trial will likely lead to a full implementation" as if that were a unequivocally bad thing. The trial will lead to an implementation only if we conclude that that is the right thing to do. If, as you believe, we are unable to maintain FlaggedRevs on en.wiki, then it will be impossible for us to attain consensus for its deployment. Having had a trial period only puts us in a better position to make that choice, it does not encourage one or other outcome. Happy‑melon 15:51, 15 December 2008 (UTC)[reply]
In my opinion, it would be a bad thing actually, and for the reasons I already specified. I've seen enough evidence to reasonably conclude that we would have unmanagable backlogs and don't like the idea of gambling with it. Of course this is only an assumption, just as your optimism is an assumption (and everybody who has an opinion one way or another is assuming). Have you researched/been following the other wikis that have implemented it as I have? - Rjd0060 (talk) 15:55, 15 December 2008 (UTC)[reply]
I certainly have, and I agree that it is a serious concern, such that I would probably have opposed most of the wider implementations that have been proposed previously without evidence to the contrary. I maintain that we cannot be certain either way without such evidence. But the point at which we need to make the ultimate decision "do we think we can handle a full FlaggedRevisions deployment?" is not being made with this proposal; with this system it will be delayed until we have gathered enough evidence to say whether it is viable. When that day comes, we'll be in a much better position than we are now to answer that question correctly. Without this trial implementation, however, we will continue to be entirely in the dark as to the true answer, and so any other implementation would be a complete leap of faith. If, as you believe, any full implementation will be a failure, we will be able to see that from the trials. So if you are correct, those trials will strengthen your position, not weaken it. There is no "gamble" as you claim, because this implementation is not at 'risk' of turning into a full deployment. You are right about one thing: everybody who has an opinion is assuming things. Why don't we take the opportunity to replace those assumptions with facts? Happy‑melon 16:08, 15 December 2008 (UTC)[reply]
It is perfectly reasonable to look at other wikis who have implemented this to see what issues they have faced. I've done so and made my opinion here and nothing at this point is really going to change my opinion unless they say that the 10,000++ revision backlog was a software glitch. I'm comfortable with the amount of "research" I've done on this and comfortable with the conclusions I've drawn. But, there are other people here :-). - Rjd0060 (talk) 16:13, 15 December 2008 (UTC)[reply]
That's certainly an opinion you're entitled to, and I agree that there is some evidence to support it. If it is true, then these trials will only provide more such evidence, and convince more people that FlaggedRevisions is unworkable. So why do you oppose them? :D Happy‑melon 16:25, 15 December 2008 (UTC)[reply]
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)[reply]
To me the backlog thing is not a big deal. I'd like to see flagged revs for the simple reason that it allows you to keep track of what the latest stable version of the page was. An example of where this was an issue is the recent vandalism to the Spike Video Game Awards yesterday there were over 200 vandal edits to the page, and it became very easy to loose track of what the good version was. Even if we used flagged revs for nothing but that it'd be useful. We can't really be recognized as a creditable source until there is an easy way for users to go back to a reviewed version of a page, ideally a reviewed version that has been thoroughly checked above what would be considered sighted. The only practical way to do this is with something like flagged revs. —Nn123645 (talk) 05:15, 16 December 2008 (UTC)[reply]

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

The proposed trial will be only about 'sighted'/'unsighted' revisions. Any expansion of the rating scale will require developer intervention. However I am open to consider a more complicated scale if the community deems it necessary. The potential length of the trial? I can only express my personal opinion here: 6-12 months. The first trials will involve only a few thousands articles, so Special:OldReviewedpages is unlikely to grow extremely large. Ruslik (talk) 20:26, 15 December 2008 (UTC)[reply]
You have the right general idea, certainly. As you point out, many of your questions are best answered by a few well-planned trials! Happy‑melon 21:03, 15 December 2008 (UTC)[reply]
If an editor makes an edit to an article, and the editor is a 'reviewer', can they mark their own edit 'sighted' or does it have to be a different editor who marks it 'sighted'? --Pixelface (talk) 01:46, 16 December 2008 (UTC)[reply]
In the proposed implementation the edits of reviewers are marked sighted automatically. Of course, this function can be disabled if there strong objections against it. Ruslik (talk) 06:16, 16 December 2008 (UTC)[reply]

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

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

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

  • Argh where did the bold words come from? However, you are aware that the proposal you're actually discussing is just the technical configuration, not any particular trial? Implementing your proposal would require exactly the same implementation as is proposed here. We removed the specific details of the trials for precisely that reason: no matter how we trial, we still need the technical ability to trial. Why don't you move this suggestion to Wikipedia talk:Flagged revisions/Trial/Proposed_trials? Happy‑melon 20:48, 15 December 2008 (UTC)[reply]
    • Well, it seemed like that's what all of you were discussing. My apologies for not reading fully into each comment. And yes, I would support a decision to trial, as per my last post.
    • I'm confused now. The objective of this discussion is to figure out whether or not to start a trial of some form? - NuclearWarfare contact meMy work 01:51, 16 December 2008 (UTC)[reply]
      You are right the objective is whether to start a trial of some form. However for this to happen we need to agree on a configuration of Flagged revisions that is necessary for trials to start. This configuration should be of limited nature, but simultaneously flexible enough to enable fine tuning during trial period. Ruslik (talk) 07:58, 16 December 2008 (UTC)[reply]
  • As of right now, Category:Featured articles has 2,336 articles and Category:Semi-protected has 2,058 pages (1,873 articles I think). There are 5,601 GAs according to GimmeBot (although I count 5,610 currently) and 1,152 featured lists (although I count 1,148). FAs/FLs/GAs is 9,089, and plus semi-protected articles (ignoring any overlap) is 10,962. I think 123 FAs are semi-protected, I think 5 FLs are semi-protected, and I think 155 GAs are semi-protected. So I think there are about 10,679 articles currently on en.wiki that are FA or GA or FL or semi-protected. --Pixelface (talk) 03:15, 16 December 2008 (UTC)[reply]
  • I don't have the energy to dig through all the archives on this, but I believe that with the sighted revisions model a "backlog" isn't really a concern -- if there are no sighted versions, the gentle reader simple sees the latest version, as it is now. So nothing changes, except that we could ensure quality on articles that need it, perhaps focusing on particularly needy articles: FAs, BLPs, semi-protected articles. Given that, I support this trial plan (but then, I support turning flaggedrevs on for good). (Which is to say: I support this proposal. I got lost with all the different trial proposals. -- phoebe / (talk to me) 07:39, 16 December 2008 (UTC)[reply]
    • Yeah and if this is just about what unlogged-in readers see, I suppose a 'reviewer' would not need to 'sight' each new edit, they could just 'sight' the newest revision they find without a ton of vandalism on it. --Pixelface (talk) 19:44, 16 December 2008 (UTC)[reply]

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

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

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

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

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

Thanks for your comments. Some of your questions have easy answers, others are more thought-provoking. An edit can only be sighted once: once marked as sighted, that specific edit cannot be 'unsighted'. The only way to reverse the effect of the edit is, as usual, to revert the edit (and mark the reversion as sighted). So I don't think we have to worry about "sight wars" as you call them, as they will just be normal edit wars. There is an issue, however, in that edit wars can now become unbalanced if one editor is a reviewer and the other isn't. I would think that edit warring in this situation would be dealt with severely, possibly resulting in loss of reviewer rights. Newest sighted revisions always take priority, just like more recent edits at the moment. Only one reviewer can sight an edit, it cannot be 'multiply sighted'. When to give and revoke reviewer status is a key question to answer in the trial period, as is when to sight a revision. Check out http://en.labs.wikimedia.org/wiki/Tablature for an example of a page that is currently displaying behavior similar to what the trial pages will show; you can check out what warnings and messages will be displayed for yourself. Happy‑melon 21:10, 16 December 2008 (UTC)[reply]
Thanks a lot for your answers. I looked at the Tablature page, and it was quite helpful. Looking at the history, I see a "Visual comparison" button and a "Wikitext comparison" button. Does that come with the FlaggedRevs extension? I also see "sighted" and "validated" next to edit summaries. What's the difference? Is 'validated' used to mark a "quality" version and 'sighted' to mark a "stable" version? --Pixelface (talk) 22:48, 16 December 2008 (UTC)[reply]
Well, this is not quite right. Sighted page can be unsighted (depreciated), see an example here. However any revision that does not contain vandalism, libel or copy-right violation must be sighted. If one reviewer overlooked something, the revision may be unsighted by another. Though Flagged revisions should not be used to resolve content disputes. Ruslik (talk) 04:57, 17 December 2008 (UTC)[reply]
The VisualDiff system is an experimental parser stage, not part of FlaggedRevs; although hopefully it will be coming soon to live wikis. You're quite right about 'sighted' vs 'validated'; the en.labs implementation uses three 'grades' of sighting, not two - sighted overrides unsighted, and validated overrides sighted, if the page is so configured. This initial implementation here does not use "qurality" revisions; it's something to think about at a later stage. Thanks for the info on 'unsighting', Ruslik, I wasn't aware that that was the case. However, I maintain that 'unsighting' an edit should not be condoned; if there is a legitimate reason why the edit should not be visible, then the correct response is to remove that problem and sight the clean version. I hope it's not a problem we're going to encounter; of course, you never know till you try. Happy‑melon 13:12, 17 December 2008 (UTC)[reply]
What happens if a vandal becomes a 'reviewer' and all their edits are automatically marked 'sighted'? What should happen to the person who made the vandal a 'reviewer'? What happens if a well-meaning 'reviewer' marks several revisions 'sighted' but did not catch the vandalism on the page and their 'reviewer' abilities are questioned? I really think a plan (when to sight, when to unsight, when and who gives reviewer status, when and who revokes reviewer status) needs to be in place before the trial starts. --Pixelface (talk) 21:10, 18 December 2008 (UTC)[reply]
I couldn't agree more, these are things that the 'crats will want to see clear guidelines for before allowing a trial to proceed. However, they are entirely distinct from the technical issues considered by this proposal and so, I hope, the fact that we haven't yet decided on such things as these should not prevent this stage of the process from going forward. Most importantly, these are things that might well change as we become more familiar with FlaggedRevs and what we can and can't expect from it, so it would be highly inappropriate to prescribe them rigidly at this time. In response to your general question, I'd say the situation is very much analogous to incorrect asignation of rollback, as the two permissions are on a similar level of sensitivity. Happy‑melon 21:55, 18 December 2008 (UTC)[reply]
  • The answer seems to be that we should give this a go; in a temporary, monitored, and clean fashion. If we never try it we won't know if it doesn't work here. Never trying seems to be keeping us in the dark for a function that could end up being useful. §hep • ¡Talk to me! 21:29, 17 December 2008 (UTC)[reply]
  • We have so many backlogs that people don't deal with as it is. Look at Newpage patrol, I know few users that do that. This looks like it would do more harm than good in general to the project. Wizardman 04:17, 20 December 2008 (UTC)[reply]
    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)[reply]
  • I strongly oppose any possible implementation of this feature in any way. This takes away much of the purpose of the site, which is to allow anyone to contribute. I can already imagine the huge backlogs. If implemented, I could look up an article about a building that caught on fire five days ago and burnt down. I would see nothing about the fire, and the article would say the building is still standing. It could take quite a while for someone to get around to "flagging" that revision. Plus, more and more tasks to do. More and more backlogs. I do not like it. DavidWS (contribs) 03:02, 22 December 2008 (UTC)[reply]
    Your opinion on FlaggedRevs generally is, of course, one you're entitled to, and it is not that uncommon amongst en.wiki users. However it is currently based on nothing more than, as you yourself put it, your imagination. Can you prove that five-day backlogs would be commonplace? We can, with this trial. If you are in fact correct and FlaggedRevs is unworkable on en.wiki, these trials will point that out very clearly. Then you will have actual evidence to support your position. In that situation, having had a trial will make it harder, not easier, for FlaggedRevs to be deployed more widely on en.wiki. Happy‑melon 11:50, 22 December 2008 (UTC)[reply]
  • Can the benefits of FlaggedRevs be proven? Yes, by conducting one or more small, controlled trials and seeing tangible benefits. Can you prove that the "huge backlogs" and "[loss] of the purpose of the site" will come to pass? Yes, by conducting the same trials and seeing the tangible downsides. Opinions are great and the whole point of this discussion (and the megabytes that have preceeded it) is to obtain as many of them as possible. Evidence for those opinions is even more valuable. I couldn't agree with you more: "no trial before people have been allowed ot state their opinions". If you take even the quickest skim through the archives linked to at the top of this page, you will see that we have just about every opinion on the spectrum. My contention is that we should have "no deployment without trials", for exactly the same reasons. Once again, this proposal, if the consequences of a full deployment of FlaggedRevs are as dire as you claim, this proposal will strengthen your position. Why then are you opposed to it? Happy‑melon 15:48, 27 December 2008 (UTC)[reply]
  • I have not claimed very much at all. At the top of this page you ask people to not register simple supports or opposes. Therefore you should not use this page to say that you have consensus for anything, even a trial. To get back to the general question, I doubt a small trial of a few articles and many people watching will give us any information about the backlogs if flagged revs is applied to millions of articles. --Apoc2400 (talk) 16:12, 27 December 2008 (UTC)[reply]
  • If you have not claimed very much, I'm confident that I have claimed even less. Where do I or anyone else claim that there is "consensus for anything, even a trial"? This is a discussion phase, where everyone is encouraged to put forward their comments and arguments that may influence the development of the proposal. You are quite right to say that this process does not produce a clear consensus, that will require a straw poll, which we are now planning. At this time, you have the opportunity to present your opinions, which will be welcomed, and the reasoning behind them, which will be contested; that is the nature of constructive discussion. You and everyone else who contributes to the eventual poll will be encouraged to read through this discussion and use it to form and inform their own opinions. I simply do not agree that your concerns, valid though they are, are actually in opposition to this proposal. This is not a discussion on "should we enable FlaggedRevs on "millions of articles""; it is not even a discussion on "should we enable FlaggedRevs on any articles". It is proposed merely to give ourselves the technical ability to enable FlaggedRevisions on a small set of articles in a controlled fashion and for a limited time without further developer intervention. Everything else, including the situations that concern you, are expressly excluded from the proposal. Happy‑melon 16:25, 27 December 2008 (UTC)[reply]

New userrights group

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

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

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

You misunderstand the purpose of the flag. Yes, the setting and unsetting of pages could be most efficiently done by a bot, and indeed it probably will. In order for the bot to be able to make those changes, it will need the 'surveyor' user right! Surveyors are different only in that they have the technical ability to make the changes; which pages they change and for how long will be governed by the community and relevant policy. The situation is entirely analogous to bureaucrats: crats have the technical ability to change any user into an administrator, but the users who receive that treatment are selected by the community at RfA. Bureaucrats are chosen not for their ability to judge who should be made admins (because they don't do that), but because they are trusted to use that technical ability on behalf of the community. In the same way surveyors wield the technical ability to implement FlaggedRevisions on behalf of the community, they would not themselves be responsible for selecting the pages. Happy‑melon 15:56, 15 December 2008 (UTC)[reply]
I have no objection if the group contains only specialized bots (or if the flagging is done by a MediaWiki pseudobot, which I guess would be more of a hack, but a possible implementation). I just want that the oversight of the process is by the community, not by a group of people wearing a certain hat. Kusma (talk) 16:08, 15 December 2008 (UTC)[reply]
That's absolutely the case; the community will decide what to do to which pages, and the surveyors will execute those wishes. Having the flagging done by a maintenance script (the 'pseudobot' you describe) would introduce a very long delay between decisions being reached and the actions actually being implemented, which includes correcting errors and ommissions. Having a trusted on-wiki user to make these changes is definitely the simplest solution. Happy‑melon 16:23, 15 December 2008 (UTC)[reply]
I object to any new ability being automatically given to, or exercised by administrators. Part of the project page, foresees, administrators doing this function almost exclusively and having an untoward ability to prevent any reviewer they choose, by simply revoking their reviewer privileged. I see wheel-wars in this. We already have edit-warring, now we'll be able to allow admins to go-to-war over which editor should be a reviewer. This is not a good thing. Surveyor and reviewer should be settable only by bureaucrats or higher to prevent this. They typically do not war between themselves, and understand much more clearly than admins how to be fair to the community-at-large, not imposing a view by force. Wjhonson (talk) 04:45, 16 December 2008 (UTC)[reply]
For the full implementation of flagged revisions we need at least about 10,000 reviewers. Do you think that ~ 10 active bureaucrats can handle this? In addition, sysops can give and remove rollback now. I am not aware of sysops mass removing rollback to prevent rollbacking their edits. Such behavior would be an abuse of power. Ruslik (talk) 06:24, 16 December 2008 (UTC)[reply]
I agree with Ruslik. The distribution of 'editor' flags will be conducted in exactly the same format, and probably in the same place, as rollback, IPBE, and the various other rights that admins already have the ability and authority to assign. There is no evidence of the systematic abuse of this existing process that you seem to be afraid of, so I can't see any reason not to extend it to this process as well. Happy‑melon 13:55, 16 December 2008 (UTC)[reply]
(outdent) I think 'surveyor' is unnecessary, technical control of pages is already in the purview of +sysops, and if there is a page issue a sysop should be able to fix it without using extraordinary means (that may be possible using existing tools like moves/deletes). — xaosflux

Talk 12:03, 18 December 2008 (UTC)[reply]

Sorry, but I do not understand what you mean. Do you want to abolish surveyor usergroup and give all FR tools to sysops? However this will mean full implementation of Flagged Revisions, not just a trial, because once you give the tools to all 1600+ sysops there will be no simple way to stop the experiment. Ruslik (talk) 13:48, 18 December 2008 (UTC)[reply]
Yes there would be, remove the Flagged revisions extension.... — xaosflux Talk 12:04, 19 December 2008 (UTC)[reply]
Removing an extension is not simple, it will require consensus before filling bugzilla request. Since the consensus is difficult to achieve the FR extension will stay, and the trial will become a full implementation without any consensus for this. The consensus should be required to continue trials not to stop them. Ruslik (talk) 12:37, 19 December 2008 (UTC)[reply]
As for reviewers, this is a simple enough permissions that letting sysop +/- it for others should be a non-issue, we have ways to deal with wheel warriors. — xaosflux Talk 12:03, 18 December 2008 (UTC)[reply]
As for using a bot, I'm confused; is the trial scope so large it can't be managed? As for full implementation wouldn't this be name-space wide? — xaosflux Talk 12:03, 18 December 2008 (UTC)[reply]

Visibility of the test

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

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

Deciding on individual trials

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

I prefer to think of it as breaking the problem down into manageable chunks rather than being abstract, but I take your point. It is in fact being deliberately vague in an atempt to separate the specifics of the trials from the implementation required to conduct them. I think that, given that we're handing the power to initiate trials (by creating surveyors) to bureaucrats, who are after all appointed based on their ability to gauge consensus, that we don't need to worry about a trial starting without consensus. Do you have any suggestions for a more explicit phrasing that is not overly bureaucratic? Happy‑melon 22:38, 15 December 2008 (UTC)[reply]
I was thinking about the level of consensus required. There is a difference between the rough consensus used at WP:AfD and the stronger consensus required at WP:RfA. But I'm happy to leave it to the discretion of the bureaucrats.
I think it is important that it's very difficult for the proposed implementation to evolve sneakily from a trial to a full deployment. Should this be made more explicit, for instance by modifying the second sentence so that it reads "The proposed configuration does not scale well to a full deployment, ensuring that it is only used for limited trials." Or is this perhaps patronizing by stating the obvious?
Incidentally, I went through the Q&A of the candidates for the recent Arbitration Committee elections. By my count, and there are a couple of borderline cases, there are two against flagged revisions (Lifebaka and Wizardman), ten with no or unclear opinion (Carcharoth, Hemlock Martinis, Lankiveil, Risker, and six who didn't answer the questions), and sixteen in favour. Of the top seven candidates, six are in favour and one doesn't know. -- Jitse Niesen (talk) 16:20, 16 December 2008 (UTC)[reply]
It's not "difficult" for this to extend to a full deployment so much as technically impossible :D. I to am willing to trust the bureaucrats to evaluate a 'sufficiently strong' consensus. Interesting point on the ArbCom candidates. Happy‑melon 17:49, 16 December 2008 (UTC)[reply]
Each area of proposal should get a seperate consensus. i. e. Get one for FAs, or A class, or GAs, or BLPs, or whatever, then address the next if it seems worthwhile. Don't say "Flagged Revs at all?" then "Okay, on what?" - that's too confusing. WilyD 17:38, 16 December 2008 (UTC)[reply]
Why is that confusing? Happy‑melon 17:49, 16 December 2008 (UTC)[reply]
You're likely to get a mandate to implement flagged revisions, but not in any particular class of articles, or not representing consensus. In the nominal case where GAs, FAs and BLPs are each supported by 1/3 of people for first implementation, you might think they're all equal. If the 2nd choice of the GA and BLP supports are both FA, for instance, then they're not equal. In practive the outcome is likely to be substantially messier. "Should we have flagged revs on FAs?" "Should we have flagged revs on GAs?" and so forth yield much clearer answers. WilyD 19:15, 16 December 2008 (UTC)[reply]
I disagree. You seem to think that, if this proposal is accepted, then we are duty-bound to implement FlaggedRevs somewhere and in exactly one place, and hence we will be confused over where exactly. That's not the case; if this proposal goes through and then we can't get a consensus to trial anywhere in particular, then so be it, we don't have any trials and hence no FlaggedRevs. If this proposal goes through and then we see clear consensus for trials on FAs and BLPs, then we trial in both areas. This proposal is not "should we have FlaggedRevs?" but "should we give ourselves the technical ability to have FlaggedRevs"; it's just a stepping-stone. But it's a stepping stone that will be needed by any implementation of FlaggedRevs,(IMO) makes intuitive sense to agree on it separately. Happy‑melon 13:17, 17 December 2008 (UTC)[reply]
I'm not suggesting that. Zero, or two, or whatever still could result in the fashion of "Where?" I'm talking about. But maybe you're right, that "Ability to implement when wanted?" is the first step. WilyD 15:24, 17 December 2008 (UTC)[reply]
While I agree we should have a seperate !vote for each type of article (FA, GA, BLP, Protected, etc...) I don't see any reason not to figure out whether people want any sort of trial first, and then hammer out the details. --Falcorian (talk) 18:38, 16 December 2008 (UTC)[reply]

Wikipedia:Protecting BLP articles feeler survey

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

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

Report from the German Wikipedia

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

Just wait for a German Wikipedian to come by :)
P. Birken (who has been deeply involved in this project all along) published a report on wikide-l two weeks ago - in German, though. I'll try to translate it this afternoon, and I'm alerting him of this discussion. --dapete 11:36, 28 December 2008 (UTC)[reply]
Translation at User:Dapete/Report on Flagged Revisions, December 14, 2008. Enjoy (or not). --dapete 12:50, 28 December 2008 (UTC)[reply]

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

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

Straw poll on implementation

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

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

Support

  1. Per all my various posts and throughts on the Wikipedia:Protecting BLP articles feeler survey that I began. rootology (C)(T) 17:48, 2 January 2009 (UTC)[reply]
  2. I participated in creation of this trial proposal. So I support. Ruslik (talk) 17:57, 2 January 2009 (UTC)[reply]
  3. Something that's been long overdue, although I think that the surveyor function should be bundled with the admin tools. bibliomaniac15 18:08, 2 January 2009 (UTC)[reply]
  4. Support this seems a reasonable configuration (probably agreeing with Bibliomaniac above however), however I would much prefer that the first proposed trial be a small random selection of BLPs (all beginning with Q or Z for instance) firstly because I think (ref. Wikipedia:Protecting BLP articles feeler survey) BLPs is where the strongest support for flagged revisions can be found, and secondly because they will be a fair sample of wikipedia's articles (small, long, little edited, widely edited, etc.) rather than the existing two proposed samples which would not be representative of wikipedia's wider articles. Davewild (talk) 18:16, 2 January 2009 (UTC)[reply]
    That definitely sounds like a good possible trial. Why don't you write that up on the /Proposed trials page? Happy‑melon 18:19, 2 January 2009 (UTC)[reply]
    I have added it to the proposed trial page. We can change the letter as needed if people think it should be larger or smaller group. Davewild (talk) 22:54, 2 January 2009 (UTC)[reply]
  5. Support. --Barberio (talk) 18:17, 2 January 2009 (UTC)[reply]
  6. Support Xclamation point 18:19, 2 January 2009 (UTC)[reply]
  7. Support. This has been a long time coming, and will add a little bit of professionalism to articles. Ec5618 13:18, 3 January 2009 (UTC)
  8. Support --Jimbo Wales (talk) 18:29, 2 January 2009 (UTC)[reply]
  9. Avruch T 18:30, 2 January 2009 (UTC)[reply]
  10. I believe flagged revisions are potentially a great improvement but there are unknowns like whether or not a substantial backlog will develop. So we need a trial. -- Jitse Niesen (talk) 18:34, 2 January 2009 (UTC)[reply]
  11. Support - This is worth trying. I think it will be helpful in dealing with problems on BLP articles. Also would support a trial for featured articles. --Aude (talk) 18:35, 2 January 2009 (UTC)[reply]
  12. I think this feature is needed to improve the reliability of Wikipedia articles. A trial would be a good way of demonstrating its effectiveness. Wronkiew (talk) 18:35, 2 January 2009 (UTC)[reply]
  13. Support A trial will give us some hard evidence as to how the system works, and will allow us to make a better judgment as to whether to implement it across more articles. --Falcorian (talk) 18:38, 2 January 2009 (UTC)[reply]
  14. Support a trial, certainly. Martin 18:40, 2 January 2009 (UTC)[reply]
  15. I'm all for experimenting with new ideas, let's see how it works out. RichardΩ612 Ɣ ɸ 18:44, 2 January 2009 (UTC)[reply]
  16. support --Malcolmxl5 (talk) 18:46, 2 January 2009 (UTC)[reply]
  17. Support, we've discussed this to death. Let's get some experience with it.-gadfium 18:49, 2 January 2009 (UTC)[reply]
  18. Support Flagged revisions would be a great improvement. JoJan (talk) 19:03, 2 January 2009 (UTC)[reply]
  19. Support. Absolutely - nothing to lose, everything to gain, especially regarding BLPs. Black Kite 19:19, 2 January 2009 (UTC)[reply]
  20. Support. Extremely strong support in fact. It's definitely worth a trial, and there's a lot of support at the BLP feeler survey. - Taxman Talk 19:23, 2 January 2009 (UTC)[reply]
  21. Strong support: The only reason people ever criticise us is that we're not reliable - the sooner we implement FlaggedRevs, the sooner we remove any criticism of Wikipedia. Dendodge TalkContribs 19:26, 2 January 2009 (UTC)[reply]
    Flagging should make us less reliable, and makes us more like Citizendium. Both are bad. Septentrionalis PMAnderson 19:36, 2 January 2009 (UTC)[reply]
    How would it make us less reliable? Things have to be checked before going live, meaning factual inaccuracies don't make it into articles. Dendodge TalkContribs 00:50, 3 January 2009 (UTC)[reply]
  22. shoy (reactions) 19:35, 2 January 2009 (UTC)[reply]
  23. Support Give it a try. It's better to evaluate in practice rather than keep discussing in theory. MrMurph101 (talk) 19:49, 2 January 2009 (UTC)[reply]
  24. Support -- Ed (Edgar181) 19:56, 2 January 2009 (UTC)[reply]
  25. Support. This has been long discussed and a successful experiment will be invaluable, no matter what the conclusion is. Dcoetzee 19:59, 2 January 2009 (UTC)[reply]
  26. Reluctant Support - I oppose Flagged Revisions in principle with all the force I can muster, but I suppose that there is no practical way to make a reasoned decision than to see them in action. J.delanoygabsadds 20:06, 2 January 2009 (UTC)[reply]
  27. Support. Opposing something based on guesses about the results, especially guesses that contradict what information we do have, is not helpful. Mr.Z-man 20:08, 2 January 2009 (UTC)[reply]
  28. Support - Something needs to be done to repair Wikipedia's reputation. - Trevor MacInnis (Contribs) 20:13, 2 January 2009 (UTC)[reply]
  29. Support implementing this at small scales and going from there seems the best way to catch any tech or philosophical problems that could arise from it. --MASEM
  30. Support - No way a trial about this can be bad. I've been following this for over a year now and have seen all the pros and cons put forward multiple times. All said and done, I cannot see any harm in a test run and hope this finally goes forward rather than the circles it's been in for ages. Almost all issues with this are already issues in the first place as the way things stand now, so it can only really help, not hurt. ♫ Melodia Chaconne ♫ (talk) 20:21, 2 January 2009 (UTC)[reply]
  31. Support - how can I, as a scientist, judge something without an empirical test? The data of others is fine, but I'll always understand my own data better ... WilyD 20:21, 2 January 2009 (UTC)[reply]
  32. Support with Reservations, born of both my apprehensions over how such a program would actually interact with everything from the various sub-cultures on a day-to-day basis to the greater architecture of the system over time (and my own opinions and proposals), and my conviction that evidence is better than the absence of evidence. Ngorongoro (talk) 20:52, 2 January 2009 (UTC)[reply]
  33. Support It's certainly worth experimenting with. There is no harm in a trial, and benefits to be gained either way. --.:Alex:. 20:58, 2 January 2009 (UTC)[reply]
    Support - Something needs to be done to repair Wikipedia's reputation. - 20:12, 2 January 2009 (UTC) —Preceding unsigned comment added by 24.83.204.61 (talk) This template must be substituted.
  34. Support: There are a couple of pages on my watchlist that could really benefit from this. --Carnildo (talk) 21:15, 2 January 2009 (UTC)[reply]
  35. Support. Seems like a well-designed framework for testing out FlaggedRevs.--ragesoss (talk) 21:36, 2 January 2009 (UTC)[reply]
  36. Support - Fritzpoll (talk) 21:40, 2 January 2009 (UTC)[reply]
  37. Support There's not going to be anything negative from trying. Stop being picky eaters and eat the damn vegetables! §hep • ¡Talk to me! 22:01, 2 January 2009 (UTC)[reply]
  38. Support, this is a very sensible first step. We can change who are reviewers, and other configuration items, after we have made the first step. Some are worried there is a scaling problem: I seriously doubt that the community as a whole will be overwhelmed, as implementing this will mean that some tasks no longer need to be done with as much urgency (e.g. reverting vandals; NPP). My opinion is that this extension will be a net time saver, but of course the first few weeks are going to be extra busy as we learn the subtleties of the feature, and the addon tools like Twinkle may take a few weeks to be ready to help us process this queue quickly. John Vandenberg (chat) 22:22, 2 January 2009 (UTC)[reply]
  39. Tactical Strong Support, because I think this is the stupidest idea I have ever heard of, and I would like to see it fail as soon as possible so we can archive it as a really bad idea, and be done with it forever. Jerry delusional ¤ kangaroo 22:57, 2 January 2009 (UTC)[reply]
  40. Worth a try If it goes down in flames at least we'll know to look for other options. Dance With The Devil (talk) 23:42, 2 January 2009 (UTC)[reply]
  41. Support I think I explained my reasoning before, so I don't repeat here. -- Taku (talk) 00:30, 3 January 2009 (UTC)[reply]
  42. Qualified Support As scalability is a major issue, I would prefer a full real test on a defined subset of vwey actively edited articles rather that the proposed trial which might not reach levels where real results will be seen. Data from a potentially very limited test might not be valid if the use of flagging were extended to large numbers of articles. The earlier real data is gathered, the better. I also have some concernes with "reviewers" as a new level of authority rather than extending sighting to all editors with sufficient experience (who, presumably, are quite unlikely to be the vandals we seek to prevent). Collect (talk) 00:56, 3 January 2009 (UTC)[reply]
  43. Support - All previous efforts on controlling vandalism and unwanted edits have been frustrating to participate in, when so many people look through the same revision again and again, without any control on what's already been done. A patrolling system without visual indicators to raise the attention and interest of editors can't get sufficient participation either, when there is no cue and no visible effect. Flagged revisions has all of this, and I believe enough users will participate when it's available, like they have with Wikipedia generally. --Para (talk) 01:12, 3 January 2009 (UTC)[reply]
  44. Support --Jake WartenbergTalk 01:28, 3 January 2009 (UTC)[reply]
  45. Strong support, for a number of reasons.
    • Firstly, I'd like to point out the necessity of a trial—so much of the English Wikipedia community's understanding of this feature has been shaped either by rumour, gut feeling, or opinion, not by hard, proven facts. A trial—multiple trials, even—is necessary if we are ever to reach the point where we can all engage in an intellectual, reasoned debate over the flagged revisions extension.
    • Secondly, reliability is paramount to an encyclopedia project—whether or not said encyclopedia is produced via strong collaboration. Reliability gives knowledge value, not openness. This feature actually does not harm openness itself, it merely gives experienced users an opportunity to engage in constructive checking and review of edits made by others. This two-person approach is important from both a practical and a scholarly approach.
    • Thirdly, Wikipedia currently suffers seriously from malicious edits that can seriously damage the lives and reputations of real people—most notably, libellous alterations. We have a moral duty to our readers, and to the subjects of our articles on biographies of living persons, to ensure that libel and other forms of disasteful, horrible material do not appear publicly.
    Please support this feature! – Thomas H. Larsen 03:12, 3 January 2009 (UTC)[reply]
  46. Strong Support. I've been here for four years and never, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever did I think this day might actually come. RyanGerbil10(Four more years!) 04:54, 3 January 2009 (UTC)[reply]
  47. Support Esp for BLP. --mav (talk) 06:00, 3 January 2009 (UTC)[reply]
  48. Strong Support - way overdue. Let's just do this please - even in a limited way, but let's get started. Note that this is a trial and not some sort of permanent implementation. Let's see what the trial results in, and re-evaluate. To the opposers - supporting this is not the end, it's just a step along the path, so let's just use it to obtain real data here - Alison ❤ 06:19, 3 January 2009 (UTC)[reply]
  49. Support - should have been done in 2007. I've had some wild and wrongful things written about me on Wikipedia. It will be helpful to see exactly which characters flag through the libelous garbage. Which will hopefully beget a sense of responsibility, and thus less garbage. -- He called me with jack high (talk) 06:49, 3 January 2009 (UTC)[reply]
    Is the expectation here that reviewers will have some form of legal experience? Would you take action against a reviewer if under the Flagged Revision system he/she becomes somehow particularly 'responsible' for the passing of material you deem "libelous garbage" but they mistakenly or willingly don't see it the same way. MickMacNee (talk) 07:28, 3 January 2009 (UTC)[reply]
  50. Broadly Support, although I'd like to see the permissions handed out a bit more liberally. As many people say, the trick is to get something up and running, and then we can look at how it's performing, and what changes we might like to make. I support flagged revisions in general, and I therefore support getting anything sensible and small-scale up and running, lest we remain stuck in a permanent quagmire of deciding what colour we would like our wheels to be. — Werdna • talk 07:01, 3 January 2009 (UTC)[reply]
  51. Support the proposed setup. I generally support FlaggedRevs, but still have questions about the feasibility of the backlog and other problems. This setup will allow us to explore these issues instead of standing still as we have been doing for too long.--Danaman5 (talk) 08:33, 3 January 2009 (UTC)[reply]
  52. Qualified Support; the proposed trial on letter-limited BLP articles seems very clever. The qualification is that there be a strong presumption that after the trial FR not be implemented, unless the trial is a superbe success ~ a success agreed to by a super-majority of users. Probably this is what sdsds meant by Sunset Provisions below. Cheers, LindsayHi 08:48, 3 January 2009 (UTC)[reply]
  53. Support I believe that this can only be an improvement, but we absolutely need a trial to confirm whether that's true or not. Bring it on!Anaxial (talk) 09:28, 3 January 2009 (UTC)[reply]
  54. Support We won't know if this is good or bad if we don't try. I'm rather optimistic that a trial doesn't spell total doom either way. – sgeureka t•c 11:34, 3 January 2009 (UTC)[reply]
  55. Support - good configuration for small-scale trials. --B. Wolterding (talk) 12:36, 3 January 2009 (UTC)[reply]
  56. Support, let's try it for a set amount of time, it will allow us to judge if it is ready for prime time. --Steven Fruitsmaak (Reply) 13:12, 3 January 2009 (UTC)[reply]
  57. Support; article protection, particularly semi-protection, is woefully overused. Anything at all to take the edge off of that is a welcome change. I'll take a little delayed gratification rather than not being able to edit an article at all any day. HiDrNick! 13:17, 3 January 2009 (UTC)[reply]
  58. Dubious support, I'm not personally convinced that flagged revisions is a great idea, but I'm open to it being tested - and BLPs seems a good place to do so. My largest concern is that, after a brief period of novelty value, a huge backlog of revisions to be sighted will develop; so if any kind of long-term backlog develops during a smaller-scale test I'd encourage people to consider how badly a site-wide implementation is going to go. ~ mazca t|c 13:18, 3 January 2009 (UTC)[reply]
  59. Support, but only on a very small subset by now (maybe on what is currently known as "semi-protected articles"). I tried the demo and am happy with it, I just have a problem with the comment field of the sighting dialog: Am I required to write a comment just to say "I have read this article and found no blatant nonsense in it" ? Nicolas1981 (talk) 13:20, 3 January 2009 (UTC)[reply]
    Sighting is equivalent of stating that there is no vandalism in the article. Comments are optional. Ruslik (talk) 13:24, 3 January 2009 (UTC)[reply]
  60. Replacing semi-protection with flagging seems like an obvious improvement. Including BLPs seems reasonable too. But why guess? Needs to be tested, sooner the better. Angus McLellan (Talk) 13:50, 3 January 2009 (UTC)[reply]
  61. Support trial. I have strong reservations about this idea, but let's see how it works in practice. There should be a wide selection of articles inlcuded in this trial, otherwise the results won't be meaningful. The trial should include at least two of the following: FA article, BLP article, science article, controversial politics article. In each category there should be one high traffic and one low traffic article (traffic with respect to edits/day, not views). Xasodfuih (talk) 13:53, 3 January 2009 (UTC)[reply]
  62. Support per my comments on the BLP feeler survey. ~~ [ジャム][t - c] 14:03, 3 January 2009 (UTC)[reply]
  63. Support trial, because it should be abundantly clear that this issue isn't going to disppear without a trial, and because we had a 2 to 1 margin in favor during the last poll on implementing for BLPs (Wikipedia:Protecting BLP articles feeler survey) ... but only for BLPs. There's more to say, but I'll wait til we have some trial data to discuss. - Dan Dank55 (send/receive) 14:07, 3 January 2009 (UTC)[reply]
  64. Support Makes watchlisting easier. — Edokter • Talk • 14:19, 3 January 2009 (UTC)[reply]
  65. Support: worth a trial, then we can decide whether to implement it or not. bahamut0013wordsdeeds 14:24, 3 January 2009 (UTC)[reply]
  66. Yes do it If it doesn't work turn it off. Spartaz Humbug! 14:26, 3 January 2009 (UTC)[reply]
  67. Strong support. If it doesn't work, we can turn it off. Massive benefits if it works, no long-term drawbacks if it does not. Ironholds (talk) 14:35, 3 January 2009 (UTC)[reply]
  68. Strong Support -- It is an excellent limited trial. This protracted pro and con debate about flagged revisions could continue ad infinitum, but is yet only based on theory. A real world test will finally provide some concrete evidence to decide on the practicality of flagged revisions for the English Wikipedia. It is time to move forward and get some answers. — CactusWriter | needles 14:40, 3 January 2009 (UTC)[reply]
  69. Support Ealdgyth - Talk 14:46, 3 January 2009 (UTC)[reply]
  70. As soon as possible, especially on BLPs. -- Jeandré, 2009-01-03t14:50z
  71. Strong support: It's about time! - BillCJ (talk) 14:59, 3 January 2009 (UTC)[reply]
  72. Support - it's a good idea, which has been in use over at de:wikipedia for a while now. A trial run should expose some of the issues and benefits of such a system. – Toon(talk) 15:05, 3 January 2009 (UTC)[reply]
  73. Timid support - this is trial basis only, and appears to have potential. I'm quite worried however that it will greatly confuse many editors (especially new ones - "where's my edit?"), and the advancement of pages will slow down considerably. At very least, we should and must place a note on top of the edit page, if not the regular page itself. Magog the Ogre (talk) 15:20, 3 January 2009 (UTC)[reply]
  74. Support I haven't had the time to check through the tiny minutiae, but the limited proposal seems sound, and is a way for our quality to increase without locking out anonymous edits entirely. Der Wohltemperierte Fuchs (talk) 15:22, 3 January 2009 (UTC)[reply]
  75. Support Given that so much of my watchlist is filled with random vandalistic edits and/or reversions, I look forward to seeing if flagged revisions can help. --moof (talk) 15:25, 3 January 2009 (UTC)[reply]
  76. Support Good experiences in de-WP. --Leyo 15:27, 3 January 2009 (UTC)[reply]
  77. Support with skepticism – There are potential problems with a full-scale implementation that a small-scale test will not make apparent. The test must include high and low traffic pages. The test should include some newly created pages. I am concerned with the effect on little-watched pages where reliable editors make quality changes, and are then unable to make those changes appear to the public. Any wide implementation should include a usergroup whose edits are trusted and auto-sighted - to not have that would mean pointless extra work sighting the edits of trustworthy editors. Of course, un-trusted editors means known vandals and newbies, and we don't want to discourage newbies by making their edits not show up. Vandalism is a drawback to the nature of a wiki; this proposal addresses that by taking some of the positive wiki nature out of the wiki. — Swpbτ • c 15:43, 3 January 2009 (UTC)[reply]
  78. Support, Tom Harrison Talk 15:56, 3 January 2009 (UTC)[reply]
  79. Support trial - It goes slightly against Wikipedia's slogan -"anyone can edit" as only 'reviewers' will be able to change the content displayed on the page instantly, but still worth a try. I think 'reviewer' flag should be given to all autoconfirmed users. --Unpopular Opinion (talk) 15:59, 3 January 2009 (UTC)[reply]
  80. Support — Past due, really. This is great. Cheers, Jack Merridew 16:03, 3 January 2009 (UTC)[reply]
  81. Support. The time has come to make a proper usable trustworthy encyclopedia available to the user. The only way to do this now is to present guaranteed reviewed content to them. I might propose to limit it to FAs and possibly GAs though - that is, stuff where the main content has consensus and been worked over a lot. Articles in development (i.e., everything else) may benefit less. Unusual? Quite TalkQu 16:28, 3 January 2009 (UTC)[reply]
  82. Support. I like the idea, as i think it would really help the stability aspect. --♬♩ Hurricanehink (talk) 16:33, 3 January 2009 (UTC)[reply]
  83. Very Strong Support per Unpopular Opinion. Willking1979 (talk) 16:35, 3 January 2009 (UTC)[reply]
  84. Support – Potentially a very useful enhancement to the wiki, merits a full trial. Rjwilmsi 16:42, 3 January 2009 (UTC)[reply]
  85. Support per my comment further down the page. Just make sure the specifics of implementation are reasonable. Estemi (talk) 16:51, 3 January 2009 (UTC)[reply]
    By "reasonable", I mean that only well-developed articles (eg B quality or higher) should have flagged revisions and "stable" pages. Obviously, requiring gainsaying/approval for ALL changes on Wikipedia would be a huge mistake and cripple the growth of early-stage articles. Flagged revisions should be in place on high-traffic pages. Estemi (talk) 17:02, 3 January 2009 (UTC)[reply]
  86. Support for reasons already stated by many others above me. CIreland (talk) 17:07, 3 January 2009 (UTC)[reply]
  87. Strong, happy, enthusiastic support. It's a test, not an implementation, and empirical testing is the way to find out whether it is good or bad, whether the fears of the opponents will prove true or not. No rational person should fear finding out the truth. I'd gladly support a test of SP too. --Tryptofish (talk) 17:20, 3 January 2009 (UTC)[reply]
  88. Support - for the reliability of WP. --Harald Khan Ճ 17:27, 3 January 2009 (UTC)[reply]

Oppose

  1. — Aitias // discussion 18:04, 2 January 2009 (UTC)[reply]
  2. to conduct one or more trials is to vague Mion (talk) 18:13, 2 January 2009 (UTC)[reply]
    Each trial will require a separate consensus; we can support or oppose each on separately. This proposal is just to give us the technical ability to conduct any trials at all. Happy‑melon 18:20, 2 January 2009 (UTC)[reply]
    If the first trial request fails support by the community there is no reason to implement the configuration ? Mion (talk) 18:28, 2 January 2009 (UTC)[reply]
    There is if the second request succeeds. If every request fails then the implementation remains completely unusable, so does no damage. We can implement the technical changes without committing ourselves to actually doing any trials, but we can't do any trials without the technical changes, so it makes eminent sense to do the changes first before getting into the details of specific trials. Happy‑melon 18:49, 2 January 2009 (UTC)[reply]
    IF the second request for a trail succeeds, its early enough for this vote, you save the energy of doing the unusable implementation ?Mion (talk) 18:58, 2 January 2009 (UTC)[reply]
    I don't see your point. If the first, or second, or third, or fourth, or nth trial gains consensus, we will need this implementation. So we would need to have this discussion and straw poll in any of those instances. If none of the trial proposals gain consensus, there is no harm whatsoever done by having this extension inactive in the background. 99% of the "energy" required to implement this proposal has already been expended, the effort required to finish it off is trivial. It would actually be more effort to not proceed with this proposal than to continue. Happy‑melon 19:04, 2 January 2009 (UTC)[reply]
    I trust this is not a declaration of intent to poll until you get your way; but the implementation is unnecessary, and undesirable, until there is consensus on how to implement it.Septentrionalis PMAnderson 19:10, 2 January 2009 (UTC)[reply]
    Certainly not; "my way", like everyone else's personal preference for FlaggedRevs, is one distinct set of policies that I suspect is going to be one of the more popular trial choices. If it fails to gain consensus, "I" have nothing to gain from proposing a myriad of variations. But the reason the general FlaggedRevs discussion has run round in circles for the past six months is because every man and his dog has "his way" and dearly wanted wikipedia to implement it as our one-and-only shot at FlaggedRevisions, thereby splitting the "general support for some implementation of FlaggedRevs" camp into dozens of parts. With this proposal, we can ask everyone to cough up their ideas again, have a think about which ones might be the best, even try the top few to see how they work. Then we can make an informed decision about which one, if any, is best for wikipedia, and how (if) to deploy it. I have seen no reasoning whatsoever to suggest that having this implementation without a consensus to use would be in any way "undesirable". Happy‑melon 22:36, 2 January 2009 (UTC)[reply]
  3. Very Strongly oppose. The fundamental problem with flagging is a problem of scale, as explained here; this "test" avoids the real questions (although it would be fascinating, and unsurprising, if flagging proved to be ineffective even at the small scale.) In addition, the creation of a new flag for sub-admin status is another step of bureaucracy and ego, which we have always consistently opposed. See also #bots? and #neither test please, below. Septentrionalis PMAnderson 19:08, 2 January 2009 (UTC)[reply]
    I agree that this proposal does not consider many of the questions that we need answers for before deciding on a final implementation of FlaggedRevs. It's not supposed to. It's supposed to provide evidence to inform us when we make those decisions. It would indeed be fascinating to see that flagging proved ineffective in the trials. I think we should be given the opportunity to see for ourselves. In regards your other reason, I point you in the direction of rollback, IPBE, account-creator... we don't seem to have opposed the creation of additional user groups very "consistently" so far. Happy‑melon 23:29, 2 January 2009 (UTC)[reply]
  4. Oppose - for two reasons, at least. First, in this proposal 'bots are given more capability than registered users. That represents an underlying flaw in the thinking of those who propose this "solution." Second, the terminology invented by this proposal, specifically but not limited to "sighted" and "unsighted", has no commonly understood meaning in American English that maps well to the underlying implementation. (sdsds - talk) 19:07, 2 January 2009 (UTC)[reply]
    I prefer to think of it in terms of how we populate the 'reviewer' user group. In an ideal world, we could independently review every user for editor status, and approve them individually. Unfortunately, we also have to get a substantial number of reviewers immediately or any FlaggedRevs implementation will inevitably fail. So we consider "which groups of editors can we promote en masse to reviewer status?" Essentially, where have we already judged a group of editors to be at least trustworthy enough to be reviewers? Admins are obvious candidates; we trust them with much more than mere sighting. Rollbackers ditto. As for bots, consider what we're really giving them. Bots are just scripts that repeatedly do actions that have community consensus, actions that would be too numerous for humans to do manually. As such, every action performed by a bot must meet the low standard to be considered 'sighted', as they must also meet the much higher standard of having community support. However, it would not be appropriate for bots to go around sighting edits made by other editors, which is why if you look closely bots are given the autoreview permission but not the review permission. So when a bot makes an edit on top of a sighted revision, that edit is automatically sighted - if we didn't do this then someone would have to run around behind all of our maintenance bots sighting their edits manually, which completely defeats the purpose of having a bot in the first place. But when a bot makes an edit on top of an unsighted revision, that set of edits is not sighted, as is quite appropriate since the underlying edit needs human review. Bots are already given access to permissions that are not available to registered users; why is giving them a few more somehow taboo? I'm not going to comment on your second point, although if you want to 'translate' the terms into ones that make more sense to you and other American editors, we'd be delighted to see such translations. Happy‑melon 19:22, 2 January 2009 (UTC)[reply]
    So only admins and bots can actually change the visible form of test articles? I regret not being able to make my opposition stronger. Septentrionalis PMAnderson 19:39, 2 January 2009 (UTC)[reply]
    I got that as saying admins, rollbackers, bots (autorev), and then most likely ACC. The other users could get approved individually if they wanted to be reviewers. §hep • ¡Talk to me! 22:05, 2 January 2009 (UTC)[reply]
    Admins, rollbackers, bots in certain situations, and anyone else who asks for and receives the 'reviewer' user right. This proposal makes no statements about who may be elegible for the latter category; that's for us to decide, and decide very clearly, at a later date. I will eat my hat if the consensus on that is not "give 'reviewer' to anyone who asks for it unless there is an obvious reason not to". Happy‑melon 22:40, 2 January 2009 (UTC)[reply]
  5. Oppose. First, the proposal would enable a specific configuration of flagged revisions, but the proposal admits that it would not scale to wide deployment. Why even test a system like this? We should turn FRs on only to trial either a fully working system or a simplified version of that system. We should not trial FRs with a configuration that does not reflect how they would be used in practice. If there is no consensus for what a working system might look like, then there is no consensus for how to trial FRs! So the present proposal is premature.

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

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

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

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

    I'd argue that even if the proposal is technically very different from the final wide-scale implementation, as long as the user interface is similar it's still valuable as a mock-up for an experiment. A version of the final system would be ideal, but I think it's better to test something to motivate and direct future changes, so that we can begin iterating. Dcoetzee 22:10, 2 January 2009 (UTC)[reply]
  6. Per This post. But it looks like I'm in the minority. If we do go with a trial, a gradual implementation should be rolled out (few thousand articles a week, tops.)NuclearWarfare contact meMy work 22:47, 2 January 2009 (UTC)[reply]

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

  7. Oppose: For the reasons I explained here. - Rjd0060 (talk) 22:48, 2 January 2009 (UTC)[reply]
  8. Oppose. Vague scope of the test (who picks the articles to be censored), vague review procedure (FAC level? NPP level?) etc. NVO (talk) 01:02, 3 January 2009 (UTC)[reply]
    The proposal is deliberately vague, becuase we're not trying to decide on any particular details such as those at this point. Each trial will require a separate consensus on precisely the details you note. All we're doing here is saying "if we get that consensus, we want to have the technical ability to implement it". Happy‑melon 11:04, 3 January 2009 (UTC)[reply]
  9. Oppose Wikipedia has always worked on a basis of trust, we have always said that being an admin is nothing special and most importantly its an encyclopaedia that anyone can edit. Flagged revisions says you can edit but your edit cant be seen we dont trust you. It places importance on having tools creating an importance that shouldnt be there. The worse thing is flagged revisions makes the presumption that all edits are malicious and increases the power of POV pushers/Cabals to control article content. In all of this people appear to be loosing sight of the characteristics that made Wikipedia what it is. Gnangarra 01:29, 3 January 2009 (UTC)[reply]
  10. Opppose I cannot support any move to technically implement Flagged Revisions for a series of trials until there are actual concrete proposals for how the specific trials will be undertaken, specifically, the articles to be included, the duration, the method of reviewer approval, and the specific data to be collected to show success/failure. The current set of four suggested trials all use the same duration and method of reviewer approval, so I could not support any of them as I don't agree with either a 2 month duration or an admin approval process. Additionaly, the proposed questions to be answered by the trials miss out a fundemental point, will Flagged Revisions increase the level of perceived beaurocracy to the point where potential contributors/contributions are lost? It is all very well tinkering at the edges by measuring backlogs or the changes in the amount of 'reader exposed' vandalism, but if you don't propose to measure the effect on one of the fundemental basic advantages of Wikipedia, then what's the point of the trials? I consider myself an experienced editor now, obviously with an account, but that all started from the gradual introduction to the site's ways from making sporadic IP edits. The up front complexity of Flagged Revisions looks to me at least to have massive potential to deter those intial good faith IP contributions which can then lead to better things. I want absolute assurance that these trials will be able to provide proof they will be a net benefit to the project in that respect. MickMacNee (talk) 01:47, 3 January 2009 (UTC)[reply]
    Expanding on my theme of what this proposal needs to commit to measuring, before it even gets to a stage of fine tuning trial details, here are some questions I think need adding to the proposal page Procedural implementation section:
    What effect, if any, does the Flagged Revisions nature of delayed visibility for edits made by constructive unregistered users have on their overall contribution history, and on the total and ratio of conversion of unregistered into registered users?
    What effect, if any, does the use of sighting to filter out basic errors have on the perceptions of the factual accuracy of unsourced or unreviewed but sighted articles?
    What effect, if any, does the selective protection of a sub-set of article types such as BLP's or disputed pages have on the wider perception of Wikipedia as an information source on all topics?
    What effect, if any, does the presence of Flagged Revisions have on the nature, volume and response time at the help desks and other advice/request forums?
    MickMacNee (talk) 07:47, 3 January 2009 (UTC)[reply]
  11. Strongly Opppose. Unnecessarily complicated for no real good. 63.3.15.129 (talk) 02:14, 3 January 2009 (UTC)[reply]
  12. Oppose Pace Black Kite, there is a good bit to lose—I don't imagine that I need set out that argument once more here—and very little to gain; I am utterly unpersuaded that the net effect on the project of the implementation of flagged revisions should be positive, and I cannot imagine that any trial experience should lead me to think otherwise, my opposition's resting on my firm rejection of flagged revisions as inconsistent with my understanding of how our enterprise (at least as regards the formulation of online content) ought to work. Joe 04:45, 3 January 2009 (UTC)[reply]
    If you are so confident that a trial would not provide any evidence in favour of implementing FlaggedRevisions more widely, shouldn't you be supporting it? If all it does is show that FlaggedRevs is a Bad IdeaTM, it would strengthen your position, not weaken it. Happy‑melon 11:07, 3 January 2009 (UTC)[reply]
    What is there to lose in a trial of the system? Black Kite 14:25, 3 January 2009 (UTC)[reply]
    If the trials are not framed and measured objectively, quite a lot. MickMacNee (talk) 15:42, 3 January 2009 (UTC)[reply]
  13. Oppose per WP:NOT#BUREAUCRACY. This may appear to be worth a try, but it increases the "hierarchy of participation" to WP and decreases its ease of universal use at the same time as increasing Admin workload. Furthermore, I do not agree with that this will be the by any means the most effective way of protecting our BLPs, most of which are see no more than a couple of 'tweak edits' a year and many of which remain unsourced for long periods and are so either a high-risk category or no risk at all, depending how you look at it. Tagging doesn't deal with that problem. Having said that, I'm tempted to go tactical with NuclearWarfare, though. Ohconfucius (talk) 06:31, 3 January 2009 (UTC)[reply]
    I would definitely encourage you to do so. I'm not yet convinced that this is "the solution" for BLPs myself. However, I want to see for myself rather than make blind guesses based on vague extracts from a foreign language wiki with a radically different culture. I really hope that this will actually decrease the strength of the apparent hierarchy, not increase it. WP:DEAL to the contrary, there are as you say significant jumps in perceived 'status', particularly between admins and non-admins. By creating an intermediate level, I think we can smooth out some of those gaps. There's nothing wrong with there being a hierarchy of respect and trust, as long as the hierarchy of technical tools is the same shape and size. Currently it's not, I agree that that is a problem; I think that this may be one step on the road to correcting that. Happy‑melon 11:15, 3 January 2009 (UTC)[reply]
  14. Exceptionally Strong Oppose - We launched this on Wikinews, and it nearly lead to all out bloodshed, mutiny and resignations. I personally have been editing here for over 4 years, and quite frankly, I don't need someone else reviewing my damn work to make sure its correct before other people see it. If this gets implemented here, I WILL RESIGN. I've been doing this long enough to do the work without having a bloody overseer! Thor Malmjursson (talk) 07:44, 3 January 2009 (UTC)[reply]
    May I ask you to provide evidence of bloodshed on Wikinews? In addition, you are a rollbacker now, and therefore you will automatically become a reviewer if FR are enabled. Then you will be able to sight others edits yourself, and moreover all your edits to sighted revisions will be sighted automatically. So I do not see any problem here. Ruslik (talk) 09:03, 3 January 2009 (UTC)[reply]
    I didn't say it CAUSED bloodshed, I said it NEARLY caused bloodshed. And since I am not allowed by the rules of IRC to publish any logs from discussion on there, I cannot provide evidence of this situation. Rest assured however, that the discussion on WN's IRC channel almost lead to 3 of us, 2 who are accredited reporters (myself and one other) walking out on the project. The main reason was that initially, not everyone was going to be given editor status (reviewer). I only relented when this was reversed. I am however, still completely and fundamentally opposed to FR being implemented in ANY form, trial or otherwise. Since with Flagged Revs, you are not allowed to sight your own work, this potentially means everything I create as a new article having to be sighted by someone else. I am not accepting that in any way. I don't care if I get God Mode from this. If it happens, I'll shut the door on my way out :) Thor Malmjursson (talk) 09:14, 3 January 2009 (UTC)[reply]
    The reason why edits of a reviewer to an article (whose last revision is not sighted) are not automatically sighted is that the unsighted revision may contain vandalism. In my opinion, the best solution is: if you are going to edit an article whose last revision is not sighted, you should simply check and sight this article yourself before making your edits! Then you can edit it, and all your edits will be sighted automatically. Again I do not see any problem. Ruslik (talk) 09:32, 3 January 2009 (UTC)[reply]
    And again, you miss the point. My biggest beef is simple. If I create any New article, I cannot, by the terms of FR, sight it myself. It HAS to be done by someone else. I have been here long enough to know how to create an article and what kind of content to put in it without having to have someone else check up to make sure I did it right before it gets published. Now do you understand why I am pissed with this idea? Thor Malmjursson (talk) 09:40, 3 January 2009 (UTC)[reply]
    That s the problem this is being done because an edit may contain vandalism, what percentage of all mainspace edits are actually vandalism? Gnangarra 09:36, 3 January 2009 (UTC)[reply]
    Ok, I understand you now. However currently there is no rules about the use of sight function on Wikipedia. They will be created in the future (if FR are enabled). So I am not against allowing creators of the articles (if they reviewers) to sight their own articles just after creation. The risk is low, because reviewers are trusted members of the community. Ruslik (talk) 09:48, 3 January 2009 (UTC)[reply]
    In addition the proposed setup does not mean that the flagged revisions will be enabled over all articles including new ones. FR will be enabled just over a subset of highly visible articles. New articles will not need to be sighted unless FR are enabled over them manually. Ruslik (talk) 09:58, 3 January 2009 (UTC)[reply]
    In fact the "rules of FR" don't require anything like this. There is nothing to technically prevent reviewers sighting their own work, be it new pages or edits to existing articles. On en.wiki I suspect that would be encouraged. The "rules" you rail against are the policies set up by en.wikinews, policies that I very much doubt will ever be enacted here. If such policies are ever enacted here, you'd be quite within your rights to walk out (I would probably join you). But don't assume that all FlaggedRevs implementations are equal; that's one thing we've learnt the hard way. Happy‑melon 11:03, 3 January 2009 (UTC)[reply]
    English Wikinews or another one? I don't remember any near-bloodshed. --Steven Fruitsmaak (Reply) 13:15, 3 January 2009 (UTC)[reply]
  15. Oppose Needlessly complex and a deterrent to new editor contributions that should not be accepted, especially given the preexisting tools available. That said, I think it somewhat inappropriate that this was even opened up for discussion prior to closure of the widely publicized strawpoll, and that notice of this discussion was so deeply buried in that conversation. Limiting visibility in this manner undoubtedly skews the results of this straw-poll in favor of the editors who were initially promoting the concept. MrZaiustalk 13:14, 3 January 2009 (UTC)[reply]
  16. Oppose Completely unnecessary and needlessly complex. It makes a farce of "Anybody can edit" by creating groups of editors who by definition are the only ones who can edit freely without restrictions. We can just abolish WP:AGF for anon editors completely then, seeing that this proposal will assume they are making bad edits that need to be reviewed. So this creates much more work, new structures and more drama...and for what? I saw it on de-wiki, where I got that "sighter"-status - anyone can get it with a few edits and a bit of history, so we are just inviting vandals to become "reviewers" and then they can wreak havoc, seeing that most people will think reviewed versions are without problems. We got options to protect the content already which are not having such problems. Regards SoWhy 13:37, 3 January 2009 (UTC)[reply]
    So you are proposing instead of making farce of "Anybody can edit" simply to abolish "Anybody can edit" principle and protect all sensitive articles? Ruslik (talk) 13:45, 3 January 2009 (UTC)[reply]
    I think what he was getting at was that the current and usually temporary protections with clearly established editing procedures are already well understood and functional and don't require the creation of a new user class, needlessly complicating the already complex guidelines and editor-hierarchy of the wiki. That said, the automatic status mentioned in the parent post doesn't seem like a valid point to complain about, as it sounds an awful lot like the status required to edit a semiprotected article. MrZaiustalk 15:47, 3 January 2009 (UTC)[reply]
    That is a simplistic comparison to say the least. By definition, SP'd articles are being watched by many people, more than enough to see and respond to {edit requests}. Blanket sighting of all articles, including the back-waters and niche topics which nobody is frequently watching, is a totally different prospect. MickMacNee (talk) 16:02, 3 January 2009 (UTC)[reply]
  17. Oppose I just don't like it. The result of a trial is very likely get misrepresented or taken to show something it doesn't. Maybe if we had a specific trial proposal to consider I would change my mind. --Apoc2400 (talk) 13:47, 3 January 2009 (UTC)[reply]
  18. Oppose "Anyone can edit" ? Anyone can, as long as your edit gets subsequent approval. This will double the workload of editors. GreyWyvern (talk) 14:49, 3 January 2009 (UTC)[reply]
    Why are you so sure? Currently all new changes and newly created articles are patrolled. Patrollers mark edits as patrolled or revert them. Flagged revisions will simply replace patrolling. You can think about FR as patrolling "on steroids". This analogy can help you to understand what FR really mean. Ruslik (talk) 15:29, 3 January 2009 (UTC)[reply]
    The advantage of replacing patrolling with sighting is a philosopical issue, as well as a technical issue. If nobody patrols a good contribution, then no harm is done by default. If nobody sights a good contribution, harm is done by default. If nobody patrols a bad edit, harm could be done, if nobody sights a bad edit, no harm is done by default. It is very much AGF vs. ABF. MickMacNee (talk) 15:39, 3 January 2009 (UTC)[reply]
  19. Oppose: We won't even require people to register an account (which still makes it the encyclopedia anyone can edit), no reason to do this, which actually restricts things much more than requiring account registration, which takes all of 8 seconds.--IvoShandor (talk) 15:09, 3 January 2009 (UTC)[reply]
  20. Oppose: There are some articles I've worked on that haven't had another editor - muchless an administrator - pass by them in three or four years -- I can't imagine the frustration of someone trying to update information in them and having to wait indefinitely to see if their changes are even accepted, before being bold and adding further changes. I also see a "refusal to flag" becoming a new form of edit war between our less-than-noble administrators - all in all, it's a poorly-conceived plan. Sherurcij (speaker for the dead) 15:39, 3 January 2009 (UTC)[reply]
  21. VERY Strongly oppose I agree with SoWhy and GreyWyvern above - This would make a complete farce of the "Anyone can edit" principle which is at the core of Wikipedia, and introduce the possibility that completely valid and accurate edits may be blocked simply because the person responsible for approving the edit is unaware of the information (for example, the information is in a printed publication or TV broadcast only available in one country, and the person responsible for reviewing the edit is in a different country and has no access to this source), or because it differs from their own personal opinion. The only way this could be avoided is if all edits are reviewed by multiple persons located in different parts of the world, and passed if they receive a majority vote from the reviewers - and we know that will never happen. And who is going to appoint the reviewers? What will the criteria for becoming a reviewer be? How can we be sure they are truly impartial and have sufficient knowledge of the subject to be able to accurately assess the validity of each edit? Wikipedia already has far too many self-appointed "experts" who delete any edits they feel do not match their own personal views - Can you imagine the chaos this could bring if they had the validity of being one of the official subject reviewers??? For this reason, I believe this is a VERY bad idea, which will drive away a significant number of existing editors, and also scare away potential new ones. I myself would have to think long and hard about my continued participation here if such a scheme was introduced, and would very probably leave for pastures new. Emma white20 (talk) 15:41, 3 January 2009 (UTC)[reply]
    You seem to misunderstand the proposal. Reviewers are not supposed to check the validity of edits. They are only supposed to look for obvious vandalism, libel and copyright violations. Therefore any revision that does not contain the above mentioned statements must be sighted. Ruslik (talk) 16:47, 3 January 2009 (UTC)[reply]
    Not "must" but "should". There is no obligation on any reviewer to sight anything. Nobody can be punished for not sighting a page, whatever its contents. MickMacNee (talk) 17:00, 3 January 2009 (UTC)[reply]
  22. Oppose: This is a really bad idea. It will deter new editors, since the intial appeal of contributing to the encyclopedia "anyone can edit" is being able to see your changes online immediately. Would anyone bother if their edit amounted to no more than a saved preview? I doubt it. Richard75 (talk) 15:42, 3 January 2009 (UTC)[reply]
  23. Strongest possible oppose although I'm in the minority here. As Richard above, this will deter people from the idea this is an encyclopaedia which anyone can edit. Not only that, but it's one we should be able to edit when we want and without having every edit checked by 'higher-up' users. This idea promotes the idea that we value our members over IPs, which I don't believe in at all. IPs contribute highly to this encyclopaedia despite others vandalising it. Therefore, I cannot support a trial of this system. —Cyclonenim (talk · contribs · email) 15:52, 3 January 2009 (UTC)[reply]
  24. Oppose for pretty much all the reasons above. We don't need this kind of German bureaucracy.The Magnificent Clean-keeper (talk) 15:57, 3 January 2009 (UTC)[reply]
  25. Absolutely, positively, hell no. Flagged revisions are a bad idea on so many levels, and against the open wiki spirit. So oppose. SchuminWeb (Talk) 15:58, 3 January 2009 (UTC)[reply]
    Comment. Wikipedia is part of the larger free culture landscape, akin to GNU/Linux in promoting open standards, free knowledge, and widespread participation in our cultural future. Now let me ask you this. In Linux kernel development, does every contribution of code automatically upload and install to every Linux user's computer? Because that's how I see Wikipedia in its current state.
    Revision control and versioning are not limiters of freedom or creativity. They merely seperate workshop from distribution center, providing the end-user with a polished product while leaving the workshop -- saw-dust filled and chaotic -- in another room. In the workshop, the "wiki spirit" can pulse stronger than ever, because contributors need not feel afraid when "being bold" and making ambitious changes to an article. The implementation of versioning with "stable" and "unstable" branches does not undermine openness or the wiki spirit. It just moves the inevitable mistakes and mishaps in the development process out of the realm where they can do real damage. Estemi (talk) 16:48, 3 January 2009 (UTC)[reply]
    A good analogy. But we have to be clear about what we are defining as "damage". Linux certainly takes no responsibility for defective code if they release it, but they did not decide to have a QA system instead of automatic uploading. The perception of damage can take many forms on Wikipedia, where the automatic availability of open content is a prime mission. Is a sighted article free of obvious vandalism but still unreferenced or subtlely POV any more damaging? Is a libelous statement about a BLP any more damaging than straight lies and misinformation about, say, a product? Wikipedia is now seen as a timely source of unfolding information (whether we want it to be or not), is the discouraging of that type of contribution more or less damaging? I can't count the number of times I have ended up expanding articles based on a single unreferenced but timely line added by an IP. Will that source of inspiration to the "workshop" from unregistered users dry up with the up front comlexity or time delayed updating of Flagged Revisions? And I am not entirely sure even that restricting the viewing of libelous content to registered users only makes any difference from a legal damage point of view (I have requested information at the main page here). I am all for a trial of Flagged Revisions if it is to try and measure it merits against these basic issues, I am not for it if it is merely here to make the lives of the "workers" easier. MickMacNee (talk) 17:27, 3 January 2009 (UTC)[reply]
  26. Strong Oppose: I really don't see the advantage to the idea of flagged revisions. I agree with the above commenters; this will make a farce of the slogan "the encyclopedia that anyone can edit." By restricting free editing to only an elite group it is unfairly subjugating everyone else, creating more work for that elite group and reducing the ease with which all other editors can edit the encyclopedia. Why should rollbackers, administrators, and bots get to say that they don't trust editors who are established users and not vandals, or IP users who are making good edits? It doesn't make sense to me, and as far as I can tell protecting pages and undoing vandalism seems to be working well enough without most edits being reviewed by this elite group in the manner enumerated in this proposal. I don't like it, because it's a terrible idea that will discourage new editors from contributing to Wikipedia and furthermore the whole concept goes against Wikipedia's principles. A Stop at Willoughby (talk) 16:19, 3 January 2009 (UTC)[reply]
  27. Strong Oppose per those above me. Is this the end of wikipedia? Wizardman 16:26, 3 January 2009 (UTC)[reply]
  28. Oppose. Timeline: Proposal to implement Flagged Revisions. Two weeks later: Proposal to rename project to "Citizendium". Bleeech. --Cryptic C62 · Talk 16:46, 3 January 2009 (UTC)[reply]
  29. Oppose - Wikipedia should be all-live, all the time. Flagged revisions are against the main point here. —La Pianista (T•C) 16:56, 3 January 2009 (UTC)[reply]
  30. Oppose - against the wiki spirit of "anyone can edit" and will eventually create a massive backlog, like NPP has already. Sceptre (talk) 16:59, 3 January 2009 (UTC)[reply]
    Why are you so sure that this quite a limited proposal will create (or worsen) backlogs? Ruslik (talk) 17:35, 3 January 2009 (UTC)[reply]
  31. Oppose, strongly. Come on, we're the encyclopedia that anyone can edit. –Juliancolton Tropical Cyclone 17:27, 3 January 2009 (UTC)[reply]

Discussion

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

Its not on the Watchlist header ? Mion (talk) 18:23, 2 January 2009 (UTC)[reply]
Things aren't added unilaterally to the watchlist header anymore; one of those links is to me proposing that we add it there. Happy‑melon 18:50, 2 January 2009 (UTC)[reply]

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

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

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

  1. Make users reviewers automatically after 100 edits with at least 50 in the mainspace to be able to keep up with the site's edit volume.
  2. Allow admins to grant revoke the permission as well, revoked users must have an admin grant them again to prevent abuse and reward good-faith editors.
  3. Get rid of the "unsighted revision" and "sighted revision" messages found in other projects with FlaggedRevs, it would look unsightly.
  4. Allow all edits by reviewers to be sighted (known as the autoreview permission) to make it more streamlined.
  5. Create an "editor" class with the addtional permissions of:
  • "Unsight" can return the page to the state (but not the version) before being reviewed so any edit will be made to the page itself. Can be undone by a reviewer re-reviewing then page (unless it's under a "review protect" that can be placed by admins, preventing reviewing of the page by non-admins). To keep pages that need to be rapidly edited open.
  • "Sightundo" can undo the sighting of another reviewer to undo errors.
  1. Allow reviewing of the wikipedia namespace. However only policy and guideline pages should be reviewed.

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

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

History of this page

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

Works for me... Happy‑melon 18:21, 2 January 2009 (UTC)[reply]
I'm showing 30Dec then 2 Jan - but not my own post! Peridon (talk) 18:21, 2 January 2009 (UTC)[reply]
Masses of 2 Jans appeared now. Peridon (talk) 18:22, 2 January 2009 (UTC)[reply]
Well there weren't any posts here between 30 December and 2 January, so that explains why you're not seeing those :D. Are the recent posts appearing now? Happy‑melon 18:27, 2 January 2009 (UTC)[reply]
Most of the 2Jans (including mine) have gone again from history. I'm in the UK, if that makes a difference.) Peridon (talk) 18:42, 2 January 2009 (UTC)[reply]
They're back again including my latest (not this, obviously). Peridon (talk) 18:45, 2 January 2009 (UTC)[reply]
There were some history issues on I think WT:RFA a few hours ago, perhaps they are related? davidwr/(talk)/(contribs)/(e-mail) 19:05, 2 January 2009 (UTC)[reply]
Aha. There were, it looks like, six edits missing when I posted that message, but it seems fine now. ♫ Melodia Chaconne ♫ (talk) 20:18, 2 January 2009 (UTC)[reply]

Neither test please

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

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

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

The first proposal tests whether the amount of vandalism such articles experience reduces in volume once vandals realise that their edits are not being reflected back at them; does the loss of the satisfaction of seeing their work immediately visible on the eight most popular website on the internet discourage them from making such vandalism? I personally feel that testing this on all 3,500-odd semi-protected articles is excessive; I'd rather see a trial on 1,000 such articles so we can compare to the 'control' of the articles that remain semi-protected. I have seen no evidence to support your bare assertion that "Sighting interferes much more with normal editing than semi-protection does"; that is something I would very much like to see some hard numbers on. Numbers that we could best gain by comparing... oh.
You completely misinterpret the role of sighting in the second proposed trial; the suggestion notes in large bold letters that "all revisions are to be sighted unless they are found to contain vandalism, copyright violations, or libel. FlaggedRevisions thereby functions as a low-level filter against obvious vandalism...". There is no "subtle and complex" judgement required; sighting here is to act as a filter against obvious vandalism, to quote verbatim. Of course, whether such a filter is useful is a matter for debate, a debate that we can much better have if we are in posession of some hard data on how effective it is. Data that we can best obtain by comparing... oh. Happy‑melon 23:06, 2 January 2009 (UTC)[reply]
Any data collected from such a test will be invalid. The current proposal admits, "The proposed configuration does not scale well to a full deployment". If it doesn't scale, then neither will our experience. Consequently, interpreting the results becomes a matter of voodoo: Someone will say, "The number of vandalism edits was ..." and someone else will say, "But the proportion of reviewers to edits will be ..." and they'll both be right. The minimum we ought to do is to make the test as similar as possible to the system we hope to deploy. The current proposal doesn't do that, so it doesn't give us the data we need. Ozob (talk) 00:44, 3 January 2009 (UTC)[reply]
If that is the case, then what are we doing now? Astrology? There's no guarrantee that our final deployment won't be a limited deployment; where is it written in stone that any final implementation must cover the entire mainspace? The implementation doesn't scale technically to a full deployment, that's a necessary safeguard. Procedurally and logistically it scales as large or small as we want to make it. If we wanted to conduct a trial over half the mainspace, we could do that with this implementation; it would just be technically very difficult (only in terms of what the surveyors have to do to set it up; for reviewers the situation would be exactly the same as a full deployment). Are you saying you'd support a trial that covered half the mainspace :D ? Happy‑melon 10:55, 3 January 2009 (UTC)[reply]

Suggestion for articles to sight

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

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

Should be active consensus to enroll; that would at least limit this to articles being actively followed. Septentrionalis PMAnderson 20:00, 2 January 2009 (UTC)[reply]
That's a very interesting idea. Instead of picking articles by type or subject, you're essentially saying that we should invite editors to suggest articles that they think could benefit from having FlaggedRevs enabled? That would certainly ensure a wide variety of subjects; I can certainly think of half a dozen articles I've worked on that I would nominate. Why don't you jot something down at WP:Flagged revisions/Trial/Proposed trials?? Happy‑melon 22:57, 2 January 2009 (UTC)[reply]
Sounds like a good idea to me.-Oreo Priest talk 14:46, 3 January 2009 (UTC)[reply]

Bots?

Consider the following situation:

There are several revisions after the last sighted version when a bot arrives at an article.
  • One is a piece of raw vandalism
  • One is a constructive edit; to make it vivid, let's suppose it is a correction of a falsehood about a living person, in a separate section from the vandalism.

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

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

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

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

Sinebot

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

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

Sunset provision

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

The only imperative statement in the whole proposal is that "each trial must have a definite endpoint". This is an extremely clear sunset provision for each trial, as you note. However, without an active trial, there is no "Flagged-revisions functionality"; if there are no active trials, the extension is invisible. Happy‑melon 10:50, 3 January 2009 (UTC)[reply]
On a technicalitly, there is no statement in the 'Future options' section of when the consensus for keeping FR will be reviewed. The proposal can be seen as allowing the beginning of new trials with specific endpoints indefinitely until one finishes with the right result. MickMacNee (talk) 15:29, 3 January 2009 (UTC)[reply]

Who determines the parameters of trials?

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

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

Each trial will require a separate consensus on which articles to include, how and when the various technical bits are assigned (when to sight, who to make reviewers, etc), when the endpoint is, and (most importantly) whether to go at all. As the bureaucrats are the ones with the technical ability to create 'surveyors', who are the only ones who can actually configure FlaggedRevs on individual articles, judging that consensus is in the hands of the 'crats; if we don't trust them to judge consensus correctly, we have much greater problems than a FlaggedRevs trial :D. While I expect the trial discussions won't attract as wide a community involvement as this discussion, they'll still be open to everyone to contribute. Happy‑melon 10:42, 3 January 2009 (UTC)[reply]
Could you at least amend the proposal to make clear that specficic proposed trials that can be proposed, as the four currently standing, do not have to be two months long, and do not have to require admins to allow reviewer rights. There are a lot of things that people clearly believe will happen in this process if implementation for trials is approved, but aren't mentioned anywhere on the page. The status of new pages for example as mentioned above in the opposes as well. MickMacNee (talk) 15:23, 3 January 2009 (UTC)[reply]

statistics please

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

No page will ever change unless sighted / "seconded"

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

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

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

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

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

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

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

Uh, doesn't that defeat the purpose of FR? If were limiting which registered users can sight articles, how does opening it up to IPs help the situation? IPs have no stable or permanent edit record, so even if an IP applys for sighting permission, how do we determine that the next person to edit under that IP is the same person who was given the permission? How do we stop vandals and trolls from using permitted IPs to sight their own edits or the non-productive edits of others? I don't see how FR can ever work unless we know exactly how is doing the sighting, and that they can be held accountable for what they do with the sighting priveleges. - BillCJ (talk) 15:07, 3 January 2009 (UTC)[reply]
Btw, I don't need to know anything about an article's subject to know that "This article is KEWL!!!" has nothing to do with nuclear physics or whatever other subject. The main point of FR is to keep the crap out of public view. - BillCJ (talk) 15:11, 3 January 2009 (UTC)[reply]
It is a point that everybody needs to bear in mind, under the FR system, there is no-one to "blame" for a perfectly good edit not being sighted, it is just an inherent feature of the system, much like there is no-one to blame if nobody investigates an SSP, or responds to an ANI or other noticeboard post. There is as far as I can see, no specific commitment to even investigate the effects of this basic change in the editting process in the proposal. MickMacNee (talk) 15:17, 3 January 2009 (UTC)[reply]

Questions for somebody with great patience . . .

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

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

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

Firstly, I could just as easily imagine someone getting a kick from seeing his/her edits immediately, as from seeing that another human being has agreed that those edits improve the Free Encyclopaedia.
Secondly, have a look at a page that has not yet been checked. The 'edit this page'-link at the top of the page will presumably read 'edit draft', and will allow you to edit the unchecked version, even showing you what (unchecked) edits were made since the last review. Have a look, experiment a bit. I think this should answer several of your questions. -- Ec5618 17:32, 3 January 2009 (UTC)
These are good questions. The first is very simple: the edit box always contains the latest version of the page wikitext, so there is never any conflict there; editors are editing the current version, whether or not they saw it on the 'view' screen. If there are differences, they are shown in a diff above the edit box, so editors will always know that they've either seen the latest version, or what the changes between the version they saw and the version they're editing are. This would allow them to see, for instance, if a change they wanted to make has already been made. If you're able to sight the page, then after you've made your edit you'll be invited to review the latest changes. A diff will show you all the changes made on top of the most recent sighted revision. If some of them are vandalism and others not, you may need to make another edit to revert only those vandal edits, but you'd need to do that with or without FLR (and with the system, you have a diff at the top of the screen to show you exactly what you're looking for). Once you're in a position where you're happy that the diff between the last sighted version and the current revision contains only positive changes, you can click a button to sight it (and by implication, all the edits before it). You don't have to sight each edit individually; they're sighted versions, not sighted edits.
We're all aware that the 'buzz' an IP gets from seeing their edits straight up in blinking lights is one of the things that is going to be lost with FlaggedRevisions. However, remember that that buzz is not always a good thing: I'm sure a large proportion of vandal edits are motivated by exactly the same instant gratification. Although obviously I can't put any hard evidence to it (yet :D), I hope that the two additional low hurdles (creating an account to see current versions, and getting some sort of reputation to get the 'reviewer' flag) will actually encourage people to make the transition from being the IP who makes the once-in-a-blue-moon spelling correction, to the registered user who makes the occasional gnome edit, to the fully-fledged editor who is an active part of the wikipedia community. I think our encouragement of existing editors is quite good; our biggest chokepoint is in getting IPs to register in the first place. I hope that this will actually help to get them on the map.
On a technical level, yes, we could give all registered users the ability to sight revisions. However, I don't believe that this would be beneficial. IIRC the numbers you quote at 90% are actually closer to 60%; certainly there are a staggering number of vandal edits that do not come from IPs. Sockpuppeteers, hardcore vandals and even casual vandals who use accounts purely to hide their IP addresses, all demonstrate that it is not possible to say with any certainty that all, or even an acceptable majority, of registered users are trustworthy. I would be very hesitant even to put my chips down to say that an acceptable majority of autoconfirmed users are trustworthy. In my opinion, this level of 'trust', which is really very low, is the lowest that requires the human touch; a review (however brief) by a real person who we've already determined to have coherent judgement. Certainly 'reviewer' should be granted very liberally indeed, to almost everyone who asks for it. But I think that having to make that step of submitting a request is important, for two reasons. Firstly, it encourages editor development, as noted above; making a foray 'backstage' is an open door to innumerable 'force multiplier' tools and features that will make them a more durable (less likely to drift away) and effective editor. Secondly, it weeds out the casual vandals and blatant undesirables (spammers and SPAs in particular). All in all, I strongly believe that a lightweight human review for 'reviewer' is an essential component of a successful FlaggedRevisions implementation.
I hope this answers your questions, or at least gives my perspectives on them. Feel free to ask if anything needs further clarification. Happy‑melon 17:39, 3 January 2009 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flagged_revisions/Trial&oldid=261710934"