Wikipedia talk:Flagged revisions/Trial

Related discussions

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

RfC on implementation

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

New userrights group

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Visibility of the test

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

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

Deciding on individual trials

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

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

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

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

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

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

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

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

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

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

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

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

Wikipedia:Protecting BLP articles feeler survey

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

• Wikipedia:Protecting BLP articles feeler survey

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

Report from the German Wikipedia

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

Just wait for a German Wikipedian to come by :)

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

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

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

Straw poll on implementation

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

“ Should the proposed configuration of FlaggedRevisions be enabled on the english wikipedia? ”

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

Support

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)
2. I participated in creation of this trial proposal. So I support. Ruslik (talk) 17:57, 2 January 2009 (UTC)
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)
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)

   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)

5. Support. --Barberio (talk) 18:17, 2 January 2009 (UTC)
6. Support Xclamation point 18:19, 2 January 2009 (UTC)
7. Support --Jimbo Wales (talk) 18:29, 2 January 2009 (UTC)
8. Avruch ^T 18:30, 2 January 2009 (UTC)
9. 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)
10. 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)
11. 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)
12. 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)
13. Support a trial, certainly. Martin 18:40, 2 January 2009 (UTC)
14. I'm all for experimenting with new ideas, let's see how it works out. RichardΩ612 Ɣ ɸ 18:44, 2 January 2009 (UTC)
15. support --Malcolmxl5 (talk) 18:46, 2 January 2009 (UTC)
16. Support, we've discussed this to death. Let's get some experience with it.-gadfium 18:49, 2 January 2009 (UTC)
17. Support Flagged revisions would be a great improvement. JoJan (talk) 19:03, 2 January 2009 (UTC)
18. Support. Absolutely - nothing to lose, everything to gain, especially regarding BLPs. Black Kite 19:19, 2 January 2009 (UTC)
19. 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)
20. Strong support: The only reason people ever criticise us is that we're not reliable - the sooner we implement FlaggedRevs, the sooner we remove any criticism of Wikipedia. Dendodge Talk^Contribs 19:26, 2 January 2009 (UTC)

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

21. shoy (reactions) 19:35, 2 January 2009 (UTC)
22. 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)
23. Support -- Ed (Edgar181) 19:56, 2 January 2009 (UTC)
24. 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)
25. Reluctant Support - I oppose Flagged Revisions in principle with all the force I can muster, but I suppose that there is no practical way to make a reasoned decision than to see them in action. J.delanoy^gabs_adds 20:06, 2 January 2009 (UTC)
26. 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)
27. Support - Something needs to be done to repair Wikipedia's reputation. - Trevor MacInnis (Contribs) 20:13, 2 January 2009 (UTC)
28. 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
29. 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)
30. 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)
31. 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)
32. 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)
33. 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)
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)
35. Support. Seems like a well-designed framework for testing out FlaggedRevs.--ragesoss (talk) 21:36, 2 January 2009 (UTC)
36. Support - Fritzpoll (talk) 21:40, 2 January 2009 (UTC)
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)
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)

Oppose

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Discussion

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

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

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

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

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

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

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)

History of this page

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

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

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

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

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

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

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

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

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

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

Neither test please

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

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

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

Suggestion for articles to sight

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

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

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

Bots?

Consider the following situation:

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

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

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

1. The new sighted version includes the revisions and the vandalism.
2. The new sighted version contains none of the revisions, thus retaining the BLP error.
3. The bot can select which revisions to include. How?
4. This will never happen. Why not? Septentrionalis PMAnderson 21:44, 2 January 2009 (UTC)

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

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

Sinebot

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