Wikipedia talk:Flagged revisions/Sighted versions/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

My opinion

I like the idea, but I think that sighting should be done very liberally, i.e. any non-vandalism version gets sighted. Otherwise, we'll have:
a) Endless reversion wars
b) Very restricted openness
c) A cabal of reviewers who can decide "what is truth, what's not"

My proposal, which does not differ significantly from the current version, is:

• Editors' versions automatically get sighted
• Sighting cannot be undone (except by admins and quality version reviewers (edit: and the person who did the sighting in the first place, obviously Mel sa ran (formerly Salaskаn) 14:41, 4 August 2007 (UTC))), when an editor abuses his privileges repeatedly his editor status can be revoked
• Versions get sighted once it's confirmed that the version isn't vandalised. NPOV or "being around for several days" is not a requirement as this is very POV and can lead not only to the edit wars we have today, but also to frequent "sighting wars".
• Anyone with an account sees the current version (not the sighted version) by default, for the sake of Wikipedia's openness and for detecting vandalism quickly.
• Anonymous editors see the sighted version, for the sake of Wikipedia's reliability and accuracy and to make vandalism less attractive. There is a very prominent "CURRENT VERSION"-button on the top of each page though.
  • Example: <random anon vandal> alters the article on George W. Bush slightly to let it include "In 2007, Bush admitted to have made enormous mistakes during the Iraq War, and apologised for it." Then a student needs some general info about Bush for his term paper, and does a Google run on George W. Bush. He gets Wikipedia as the first result, and sees an encyclopaedic text. The student, having no idea about what kind of site Wikipedia is and not knowing that everyone can edit it, prints the text. A few minutes afterwards, a Wikipedian reverts the libellous addition, but in the end, there's incorrect information included in the student's paper, because of WP vandalism. That's why it's important for anonymous passers-by to see the last reviewed version.
• Of course, one can always alter this option in their personal preferences.
• The quality system is fine as it is proposed now.

Does anyone have any ideas or comments? Sala Skan 17:45, 8 June 2007 (UTC)

Well, let's focus on what is different in this proposal. First, I agree that NPOV is a too subjective criterion to be practically useful. I'm not sure about whether deprecating reviews is a good idea, or not. However, I will here focus on just one point. I think automatically sighting reviews is a bad idea. I suppose the rationale is to minimize the impact of this system on content disputes, but nobody will prevent people from sight their own contributions. I would prefer to manually sight even my own edits. I can think of the following reasons.

1. On heavily edited pages, I have sometimes edited a section, and vandalism has slipped through (either because somebody edited a section meanwhile I was editing and the software cleverly merged it, or I simply didn't notice it). In any case, this is a problem even today. When you see in the edit history that I've edited after an anon, does this mean I have checked the anon's edit to be okay? I've seen subtle vandalism slip through like this. Having a way to compare (and see a diff) with the last sighted version would be very helpful.
2. If my edit isn't automatically sighted, I would be more bold in doing some rather imposing wikignoming changes. For example, I sometimes browse a page, and notice images are very badly placed. However, you never know, if the regular contributors to that page, intended it this way, so often I don't bother changing this stuff.
3. Finally, I think I would not sight my own edits unless they are minor fixes, so that at least one other editor reviews them. This is my own preference, perhaps due to my insecurity, but I would simply like to be able to contribute in this way. Of course, in an area where I do consider myself an expert, I would probably sight my own edits; but I often edit outside my field of competence, which is more fun.

So personally, I would probably not like my edits to always be sighted, and people who want their edits sighted shouldn't be prevented from sighting their own edits, but then they should look at the diff since the last sighted version to check that vandalism hasn't slipped through. --Merzul 12:11, 10 June 2007 (UTC)

I think Salaskan's version is a great step forward: it recommends a small change to that is likely to both gain a strong positive consensus and also make a huge difference. At present, even though I advocate for Wikipedia at my university often, I am reluctant to actually call up pages in front of college administrators or other professors for fear that the article has been recently vandalized. Many (perhaps even most?) visitors don't know how Wikipedia articles are created and edited, so giving even a little protection against blatant mistruths and vandalism would be a huge improvement. As far as Merzul's concerns go, I think automatic sighting could be a per-user option (like auto-watching of pages). Personally, I check the diffs of every page I edit at least against the last edit by someone I trust, so I would like the auto-sighting option. I don't think it should be considered a grave mistake to "missight" a page which had vandalism that you missed--anyone with the "sighting" flag could still remove it and perhaps anyone without the tag could revert to the previously sighted version. (I'm consciously using "sighted flag" here as opposed to a new "editor" designation--I don't think we need a new class of user, in the same way acct's over 4 days old don't get a new designation, and I especially hope we don't take away the term "editor" from everyone else who contributes to Wikipedia who won't have this extra option).

If this level of flagging turns out to be a success, I think we can consider larger flags ("quality" or "stable") in a short while. I think that the goals which those flags aim for (allowing for bolder improvements to large articles) are also important, but are distinct from the vandal reducing aims of sighting. -- Myke Cuthbert (talk) 04:10, 12 June 2007 (UTC)

adding another class of wikipedia users?

let me just say first off that i work on both Wikipedia:WikiProject Vandalism studies and Wikipedia:Version 1.0 Editorial Team. in terms of vandalism and quality, the editor class and reviewer class helps both projects immensely and would in fact bring a lot more reliability and credibility to Wikipedia. this is in fact a very good idea.

the immediate problem i see however is that Wikipedia under no circumstances should accrue any more classes of users. Administrator, Check User, Bureaucrat - is in my opinion, 2 too many. the last thing we need is to add more to this list. also the last thing we need is having to explain to 100,000 nonactive users why their edit didn't show up in the most recent stable revision. this spawns another RfC like process from complaining users, and we don't need any extra processes either.

like i said, this is a very good idea. it's just the pitfalls and the costs outweigh the benefits, unless someone has a really good way to approach the problems above. i'd love to hear em if they're out there. JoeSmack ^Talk 19:03, 8 June 2007 (UTC)

I think we need at least one new class of user, and without some kind of new process not much will change. Note that this is essentially identical to an essay I wrote a while ago, see User:Rick Block/Keeping sewage out of the wine. -- Rick Block (talk) 02:20, 9 June 2007 (UTC)

True. I just don't think the unproven benefit will outweigh the cost yet. Interesting essay, it is very similar indeed. JoeSmack ^Talk 12:41, 9 June 2007 (UTC)

Check User and Oversight are just 1 right-groups that are there for security/block use, they don't really act as a serious user class. Voice-of-All 04:33, 9 June 2007 (UTC)

Really? I think they are quite serious user classes. They have a lot of power. JoeSmack ^Talk 12:36, 9 June 2007 (UTC)

Yes, they are rights that require good judgment over serious matters, but their scope is very very limited, unlike things like Sysops or Editors, which have rights that significantly effect articles/users/and content. They are just two small groups of users that deal with special vandals and libel, they are not large enough nor have rights that affect the encyclopedia enough for me to use the word "class".Voice-of-All 15:56, 9 June 2007 (UTC)

I wasn't thinking of size I was thinking of abilities. Any ability that one group of people have over another puts them in a different class - a qualitative difference. Size is quantitative, fuzzy in this case because your idea of 'not large enough' isn't the same as mine. :) JoeSmack ^Talk 15:25, 10 June 2007 (UTC)

(←) Ok, but what is the "cost" in having these classes? You agree that there might be some benefit to vandalism and quality, but what danger do you see that defeat these benefits? --Merzul 16:11, 10 June 2007 (UTC) More specifically, do you think the editor class is also a bad idea, or is your concern mainly with the reviewer class, or is this objection more general than the specifics of the two classes. --Merzul 16:44, 10 June 2007 (UTC)

Allow me to register my objection as well. It's not just a new editor class, it's a new class whose active involvement is required to make things work. Backlogs on underwatched pages is a major danger. Once a page gets marked by someone in that class, it can become totally stuck until someone from the same class gets around to it again. By contrast, the current RC patrol requires nothing special, even users who aren't logged in can, and do, revert vandalism. Why not just hold edits not made by "autoconfirmed" accounts (the same ones which can't edit semi-protected pages) for 6 hours or something? The FAQ says the whole point of this proposal is to remove the incentive of having vandalism show up immediately, and this accomplishes that in a way that is a) wayyy simpler and b) works with the current RC patrol without requiring extra work from anyone, let alone from a subset of users. --Abu-Fool Danyal ibn Amir al-Makhiri 18:56, 10 June 2007 (UTC)

Comment - This is an excellent alternative proposal. Badagnani 18:58, 10 June 2007 (UTC)

Um, how would this work exactly? Specifically, who would get to see these edits and what would happen if an autoconfirmed account makes an edit after one of these edits? And, would you apply this to all articles? -- Rick Block (talk) 19:02, 10 June 2007 (UTC)

An example of how this could work: logged-in users see the current version. Logged-out users see the most recent version that a) was made by an autoconfirmed account, or b) stayed in place for some interval, like 6 hours. Any vandalism not noticed in 6 hours would still get through, but this would remove the "immediate" incentive. I don't know if it would need to apply to all articles or not. --Abu-Fool Danyal ibn Amir al-Makhiri 19:10, 10 June 2007 (UTC)

This proposal also helps prevent against crappy/POV/inaccurate (good faith) changes. Basic the version that shows of the last autoconfirmed user doesn't do this. Nevertheless, that kind of feature would maybe be nice to add to the extension. However, I am not sure how to implement that without causing too much db load (otherwise I would have done that earlier as I've read it on bugzilla before). Voice-of-All 19:16, 10 June 2007 (UTC)

Hmm...actually if SELECT all revisions with rev_timestamp > now - 6 hours, then load the users from rev_user and check if they are autoconfirmed and take the newest revision where they are I'd have the desired one. If one is not found I could take the first revision after 6 hours. Assuming there are not a lot of pages with many edits in the last 6 hours it shouldn't be too bad. This could be an auxilary to flagging (if enabled).Voice-of-All 19:21, 10 June 2007 (UTC)

But what's the caching impact of this? I assume what you have now purges the squid cache only if an edit is confirmed by an editor (or the article is not one that is marked as needing editor confirmation). I suppose you could schedule a purge 6 hours from now, but that seems a little bit tricky. This proposal could be implemented with the existing change if a bot were allowed to be an editor. -- Rick Block (talk) 20:07, 10 June 2007 (UTC)

Indeed, that would be another mess, and 'autoconfirmed' now does not mean the user was autoconfirmed when they made the edit, which is why coding this would be a mess. Voice-of-All 22:07, 10 June 2007 (UTC)

Well, if you interpret the requirements as exact. We could pick autoconfirmed-now, or autoconfirmed-then, whichever is simpler. If exactly 6 hours (or whatever interval) is too hard, maybe we could make it give or take an hour and schedule a task every hour or two to make the necessary cache purges? My impression is that it would still cover a large majority of vandalism, wouldn't it? --Abu-Fool Danyal ibn Amir al-Makhiri 02:13, 11 June 2007 (UTC)

Abu-Fool, this proposal is not only about vandalism, but about a shift from quantity to quality :) Now, about the issue... this might generate a back-log, but this is not an artificially created back-log, this would be a backlog of unwatched and non-reviewed pages that may contain copyright infringements and libel! These "editors" (non-vandal Wikipedians watching pages) are already needed, and they are already doing this work. I mean, is a page stuck in an older inferior version really a more serious problem than a lesser watched page stuck with libel? I think this alternative proposal isn't bad, but wouldn't increase my trust in Wikipedia as a reliable source. I mean vandalism is just the start, but the key goal here is to improve quality and enable peaceful and calm discussion of new changes. --Merzul 22:46, 10 June 2007 (UTC)

Others above seem to think this is about keeping vandalised versions from being shown. I see you've removed the FAQ and stated rationale with the comment that "it's already in the proposal". In fact, after I read the proposal and before I read the top of the talk page, my impression was precisely the opposite: I didn't know what the point was. The rationale wasn't stated clearly at all.

I am even less in favour of this now. There must be a clear specific need for something like this, and the change must be focused on that need and nothing else. Enabling peaceful and calm discussion of new changes is rather unrelated and doesn't seem to be a clear need anyway, we already do that reasonably well. --Abu-Fool Danyal ibn Amir al-Makhiri 02:13, 11 June 2007 (UTC)

This is extraordinary--we started out with assurances from those editors "in the know" that this proposed feature was only for preventing vandalism, then it was stated that it was really to enhance articles' quality (and that the Board has stated that this WILL happen); then it was stated that editors' input is desired, then it was stated that editors' input doesn't matter anyway and should not be solicited by spreading notice of this discussion; then it was stated again that the proposal is really for preventing vandalism, then it was stated that it isn't really about fixing vandalism, but for promoting quality. I did ask early on for full transparency about this (not 80% or 90%) and I guess I'll have to ask again. It really does seem that many of the editors here do not really know, or, even worse, that they are not divulging what the actual root motivation(s) behind the rush to impose this huge proposed change to Wikipedia are. Badagnani 02:43, 11 June 2007 (UTC)

I will explain myself and then stop commenting here because it seems I'm only causing confusion and raising suspicion. I removed the FAQ because it isn't maintained, and doesn't reflect the direction the proposal is taking. I see nothing wrong with a proposal constantly changing, and that different people want to use the software differently, or if someone even change their mind!

Here is my interpretation of the situation. Jimmy Wales and the foundation are worried about quality. In an interview Mr. Wales even stated that they considered hiring an advisory panel of experts. Once more, I know nothing more than what I've read in the news, and I hope he doesn't hire a panel of experts, but I agree with Wales about one thing though, in the field of humanities Wikipedia is very weak. There are serious problems, and ignoring them, won't make them problems disappear.

Could this be the panel of experts you heard about? heqs ·:. 18:09, 16 June 2007 (UTC)

No, those are management/business/marketing experts to help run the site. Voice-of-All 20:27, 16 June 2007 (UTC)

You should think of this proposal as the community's attempt to solve a large number of problems, so some of us has no clue what the foundation is up to. In the end, it is completely fine to reject this proposal, but the problems will remain; and will have to be dealt with in some way or another. That's why I would prefer that we can come up with a solution ourselves.

Respectfully, Merzul 08:44, 11 June 2007 (UTC)

Merzul, I find your comments very helpful and enlightening. I do believe we have many experts here, but for particular fields there may be only one, or two, or three across the whole Wikipedia. This may be due to the fact that this is an unpaid, volunteer operation. Nevertheless I think we do quite well. There are some glaring lacunae such as, for example, contemporary dance--there don't seem to be many people here, yet, who are knowledgeable and active in this subject--but, of course, as new, knowledgeable editors eventually discover WP then we build that way. We're creating new articles all the time and we each build and maintain in our own areas of expertise. So my answer would be that we do have a great many experts already, working actively. The WikiProjects do help to coordinate efforts though, for similar reasons, many things are still lacking, such as a project to get "dot-on" maps on all city articles. This seems to have been abandoned by the editors who formerly were gung-ho about taking care of it, and we would of course need more Wikipedians to take photos for the articles where FU photos have been eliminated. I believe these types of things to be probably more important than the "policing" functions that seem to be being promoted at the moment. Badagnani 08:52, 11 June 2007 (UTC)

Dear Badagnani, thank you for your very kind comment. I still think I should let other people continue the discussion because my comments are all over the place :) Briefly, I think you are right that the efforts you describe are probably more important, but I don't see this idea as policing or a form of negative control mechanism that will prevent our work. In any case, I will take some time to think, but rest assured that I'm taking a break in a good mood and confident that we are all trying to figure out ways to improve Wikipedia, so don't worry if my tone seemed a bit negative. Thanks again for your kind words, Merzul 12:41, 11 June 2007 (UTC)

I believe that many things in Wikipedia (ie Featured portal, Featured sound and many WikiProjects) have very little community input. According to the link on the top of this talk page, if we create another approval system for clearing revision backlogs, then even less editors will go to the projects mentioned above. OhanaUnited ^{Talk page} 21:41, 15 August 2007 (UTC)

i say we should combine this task with another class. which one I don't know.Arttic00 19:10, 23 August 2007 (UTC)

Granting editor rights

This is currently rather inconsistent. We used to have editor rights granted automatically based on the 3 criteria, now it is given by admins based on 4 criteria. I think this is a bit weird, I can think of 2 alternatives that make sense, and both seem okay to me:

1. Users are given rights automatically after a fixed set of criteria, but admins can give earlier. [1]
2. Admins can give these rights to any user they trust is not a vandal. (If only admins give the rights, then certainly a confirmed e-mail account is completely irrelevant.)

Also, the current standards seem very high to me, especially since I'm not sure if I am myself particularly "clueful". --Merzul 23:15, 10 June 2007 (UTC)

1. Yeah, I agree, I'd get rid of the 500 edits/6 months thing if there is to be no autopromoting. Voice-of-All 06:26, 12 June 2007 (UTC)

Vandalism and/or quality checking?

Is it just for vandalism or is also quality checking? I think a lot of us are wondering this. I also think a lot of us are kind of floating between the two ideas "just vandalism" and "vandalism and quality". We're probably unclear about what exactly this will impact because we're kind of waiting to see how it could be used in actual practice. I ask myself, would I support or oppose this it if was more than just vandalism checking. I honestly don't know, but I'm excited to find out. What I'm trying to get at is, I think some of us are unsure of what exactly to support, because we don't want to write the idea off, but we want to be cautious. A lot of us really want to at least test the concept, in some shape or form, before we can honestly comment on how we should use it. We got this proposal that doesn't really know what it's proposing anymore.

Maybe we should be asking more than one question (do you support this idea or not). Like "Question 1, do you think this would help for vandal fighting" then "Question 2, in addition, do you think some level of quality checking could later apply". Or even "Would you like to see how this works in action before commenting". I find myself at that last example, in that I don't think I can give an accurate response without seeing some kind of indication of what will happen.

What I would love to see is just some kind of test, even if just for a week, so we can actually get our hands on this and really see what we're dealing with. -- Ned Scott 07:02, 12 June 2007 (UTC)

All registered users will see and edit the most recent version of a page

How about giving all readers the option of turning this on or off. Anonymous editors would see the stable version by default, registered users would see the latest version. There could be a small icon somewhere for the version to be switched from recent to stable (e.g. a small tick imposed on an article for stable, and a small clock for most recent). Users could alter this permanently in their preferences. Richard001 03:21, 15 June 2007 (UTC)

That's the plan I believe. This is more for 'drive by' viewers than regular contributors. →Ollie (talk • contribs) 03:49, 15 June 2007 (UTC)

Yes. The way it works is that a tab with the text "Current revision" is placed between the "Article" and "Discussion" tabs, and when viewing the current revision, there will also be an "edit" tab. —METS501 (talk) 03:47, 18 June 2007 (UTC)

I think it is a good idea to allow all registered users to see the most recent edits. I still worry about adding classes of users, overall though. I wonder if some viewpoints and people who have them will be censored out or have less priveledges. I already feel this is the case to some extent in deletion arguments. If 'sighting' etc is added I fear it will get so bureacratic that it will drive new users away. I'm a fairly new user myself and there is enough complexity to the system already. Adding more will probably discourage people. Moonbug 19:16, 23 August 2007 (UTC)

I endorse Richard001's idea. I was thinking the same thing myself. Makes perfect sense. I'd let readers change the version by clicking on a tab on top of the page in the same area where "discussion", "history", "edit" are. It would probably be nice if there were some kind of notice in color at the top of the page (more subtle than the typical colored notices we now have) so that the type of version we're looking at is instantly recognizable to a registered user. It would be noticed, generally, only if it changed. Perhaps a somewhat different background color? Noroton 21:51, 23 August 2007 (UTC)

Per:WP:BOLD

If the point of a wiki is to let everyone be able to edit it, flagged revisions whouldn't work. It is like if someone submits a change to make, and then editors must check if the edit is not harmful. But then, WP:BOLD will be rendered useless, because no one's gonna care about being bold if it is reviewed by an admin. Also, that whould create an HUGE backlog of articles. I think we are better the way we already are.-Flubeca (t) 19:28, 23 June 2007 (UTC)

Unless this was significantly changed recently, it does not quite work how you seem to think. Every page would not automatically get this, only ones that are somewhat comprehensive and stable are tagged as "sighted", this can be done by anyone with "Editor" rights, which will be given quite liberally, not only to admins. Only pages tagged as "Quality" would be harder to update as this would require a "Reviewer" (which has to be given by a bureaucrat). "Quality" would only be given to the best pages, like FA quality pages though. Mr.Z-mantalk¢ 20:06, 23 June 2007 (UTC)

I understand that. However I still think this whould be a bad idea. -Flubeca (t) 16:37, 24 June 2007 (UTC)

Time-delay

I support the general idea of stable versions. Though, instead of require all articles and changes to be approved, how about some time-delay mechanism. Changes from newbies or anons. don't go live immediately, but there is a time delay. (so many minutes or some other amount of time) I'm not sure one particular amount of time is suitable for all articles. Right now we have semi-protected articles and non-protected articles. Maybe one length of time be applied to what currently are semi-protected articles and another time length for non-protected articles. And, users logged in would see the live version no matter what. A time delay would allow us to flag vandalism, but non-vandalism edits would go through. Don't want this to be overly complicated. Also, having some sort of filter, like User:MartinBot, is helpful. Though would be good if bad edits (as determined by whatever filter MartinBot uses) were delayed, rather than go live and then reverted. If an edit has blanked a page (or deleted large portions), it needs to be checked or delayed. If an edit includes naughty words, it must be checked, etc. I'm not sure of specifics, but some sort of stable version or time delay would be a good thing for Wikipedia, to help reduce instant gratification that vandals get from seeing their edits go live immediately. --Aude (talk) 19:55, 23 June 2007 (UTC)

Time-delay is a bad idea. It'd eliminate one of the fundamental concepts of Wikipedia, the fact that anyone can edit it now, and the changes will be visible immediately. A time delay will greatly reduce the number of new editors, stunting the encyclopedia's growth. Pyrospirit (talk · contribs) 18:34, 23 August 2007 (UTC)

This is my concern too. As a newer user myself I can testify that there are already hurdles to getting involved. Being automatically classed as a second class editor to start would just drive people away. I hear that sighting privledges would be given liberally, but what does that mean? How will it be decided. I worry that it will make it less accessable. Moonbug 19:20, 23 August 2007 (UTC)

I think sighting will cause no more of a problem than new users being unable to move pages or edit semi-protected pages. It wouldn't make people second-class users; rather, it would simply grant users more rights with greater experience. Pyrospirit (talk · contribs) 19:25, 23 August 2007 (UTC)

Explanation could possibly be clearer?

"Users who have been around for some time can be granted (possibly automatically) rights that would let them review page revisions."

Initially I read "let them review page revisions" to mean let them click on the History tab, look at the list of edits, and click on them to view an earlier version - the implication then being that others could not do any of these things. Reading further I gather that "review" here means something rather more than this (i.e. checking the article and flagging it). Maybe that could be made clearer in the sentence quoted? Matt 00:54, 24 June 2007 (UTC).

Additional point: I also don't really understand the significance of the sentence: "The crucial issue here is that all registered users will see and edit the most recent version of a page." "Crucial issue" makes it sound like this is a central component of the new proposals, but isn't this just what happens at the moment? Should it read "The crucial issue here is that all registered users will continue to see and edit the most recent version of a page."? But even this kind of implies that non-registered users won't edit the most recent version, whereas surely they will have to? Matt 01:15, 24 June 2007 (UTC)~.

Yes, "crucial issue..." doesn't make much sense. What was intended was something like "The crucial difference from Citizendium or other stable version proposals..." is that everything will continue as normal for registered users. (Non-registered users will see the flagged revision, but they will of course still edit the most recent version.) I don't know exactly how to phrase it... --Merzul 13:51, 24 June 2007 (UTC)

I changed it to read: "All logged-in users will continue to see and edit the most recent version of a page. Users who are not logged in may not see the most recent version of a page by default, but will always edit the most recent version." I hope this is correct... if not maybe someone could fix it. Matt 20:50, 25 June 2007 (UTC).

Comment

Probably this has already been mentioned (apologies, I haven't read all the above!). One thing that troubles me about this proposal is the length of time it might take before good edits are reviewed and made the version that people see by default. I can see worthwhile additions and corrections languishing unreviewed for months and months. Would there be some mechanism for flagging up edits needing review, and would there be enough editors to cope with the volume? Matt 00:54, 24 June 2007 (UTC).

I believe flagged revisions are only for high-traffic pages, though I'm sure there would be a Special:UnflaggedPages and enough willing editors if the scheme were to be expanded. CloudNine 08:27, 24 June 2007 (UTC)

And like 200 backlog pages getting created per minute. -Flubeca (t) 16:38, 24 June 2007 (UTC)

Indeed, there is a Special:Unreviewedpages that lists either those pages that have not been reviewed or those pages that have been reviewed but not marked as quality. AmiDaniel (talk) 18:40, 24 June 2007 (UTC)

So, flagged versions will not be used for all pages. Will be used only for high-traffic pages, such as those currently semi-protected. Would flagged versions also be used for featured articles? good articles? what else? It seems more manageable to use flagged versions only on some pages. This should be made clear on the Wikipedia:Flagged revisions proposal page. --Aude (talk) 15:22, 25 June 2007 (UTC)

Yes, if the proposal is meant to apply only to selected articles (such as high-traffic articles) then this should be made clear in the text. Currently several passages seem to imply that it will apply to all articles. Matt 20:58, 25 June 2007 (UTC).

There is a notice though on pages that haven't been sighted. Someone requested that this notice be removed. This is probably a good idea (for at least any potential trial period). This system could then be used only on pages where there is consensus on that particular talk page that sighting would be helpful. --Merzul 22:01, 25 June 2007 (UTC)

Sorry, I think we might be talking at cross-purposes here. I was referring to the explanation of the proposal at http://en.wikipedia.org/wiki/Wikipedia:Flagged_revisions, not to any on-screen messages that might appear alongside articles. What I am suggesting is that if this proposal (particularly the fact that latest edits may not be seen by default) is intended to apply only to selected articles, as someone said above, then ideally this should be made clear in the explanation. Matt 01:04, 26 June 2007 (UTC).

Search engines

Search engines were mentioned above in #Major choice, because search engines are anonymous users. I point out that Wikipedia's servers are aware of at least some search engines (such as in feeding changes to them). Should an attempt be made to treat search engines differently than anon readers? An advantage to Wikipedia is a better reputation by presenting higher quality articles to searchers. To avoid Wikipedia deciding how to treat this type of user, maybe search engine crawlers could request the article flag level when asking for an article. The flag type option then could be used by crawler programmers to use if they wish to, and articles for anonymous users who don't request a certain flag type would use the anon default behavior. (SEWilco 17:35, 24 June 2007 (UTC))

There are no robots-restrictions placed on "Current version," so search engine crawlers can gladly follow the "Current version" tab, provided no modifications are made to robots.txt to prevent that. I'm not sure how engines such as google would index Current versions, but I figure they will wind up as the result of searches somehow. AmiDaniel (talk) 18:44, 24 June 2007 (UTC)

The name of the "Current version" link could be documented in the crawler feed API documentation, wherever that is. (SEWilco 04:06, 25 June 2007 (UTC))

Actually, I wouldn't want search engines to go to the current version, since that would somewhat defeat the purpose of spam prevention, as linkspammers could freely edit an article and have their links show up in search engines, regardless of being sighted or not. Dr. Cash 05:33, 17 August 2007 (UTC)

What's the next step?

Can we start a trial with a few pages and see how it goes? Tom Harrison ^Talk 15:40, 25 June 2007 (UTC)

Would be helpful to get a sense of how this might work. From what it sounds like, flagged revisions would not be applied to most pages, but just high traffic/frequently vandalized pages (the way semi protection is applied) and maybe to featured articles. If that's the case it will be helpful, and be a manageable number of pages. For now, let's try it out on a small number of pages. --Aude (talk) 15:46, 25 June 2007 (UTC)

Good idea, let's experiment on some pages that have been semi-protected forever. I think God or George W. Bush are good places to test this. Since these pages can't be edited by anons, there is absolutely nothing to lose. --Merzul 22:13, 25 June 2007 (UTC)

Indeed. It would be interesting to see what would happen if everyone was allowed to edit the current version. It actually might move us closer to our 'anyone can edit' philisophy (compared to protecting pages). CloudNine 09:36, 26 June 2007 (UTC)

I agree that moving the permanently semi-protected or protected pages should be the first test step for flagged revisions. Especially for those pages whose protection is entirely or mostly based on vandalism. However, I think that before we can do a test, we'd need to be sure that there's consensus (whether here or at the Board level) on what makes an Editor an Editor (I still don't like that term for the lowest revision right). My thought on that is that it should be a rather low threshold, but at least at first it's best to start a little too high and adjust down later. It's always easier to give privileges than to take away. -- Myke Cuthbert (talk) 19:28, 26 June 2007 (UTC)

The interface to review pages is quite awful in my opinion, with too many options. Until that is improved, I wouldn't want to use this extension here. Prodego ^talk 00:47, 28 June 2007 (UTC)

I agree; it does need to be made a little clearer. CloudNine 21:39, 28 June 2007 (UTC)

Reorganization of main page

Hello, I reorganized the main page to separate out the two different levels of flagged reviewing that we've been discussing here. I tried to include some of the points on which there seems to be a consensus and fix up some of the prose without changing the meaning. But mostly I wanted to put everything relating to "sighting" together and everything relating to "quality" together.

If I added anything that seems incorrect on the basis of discussions here, please change it back--please assume that any incorrect change probably reflects my lack of understanding of some aspect of the project rather than an attempt to put my POV in the article. Best, -- Myke Cuthbert (talk) 20:24, 25 June 2007 (UTC)

I saw these as merely different levels of validation, but for the sake of clarity and per Ned Scott above, the change you made is probably very helpful. I notice some people are against one kind of validation, while liking the other, so probably keeping these two separate is a good idea... --Merzul 22:41, 25 June 2007 (UTC)

"Quality" Title

If the quality status is granted by one person, isn't that against Wikipedia:Consensus? -Flubeca (t) 18:38, 29 June 2007 (UTC)

Well, I'm sure a quality version on high-traffic pages would be agreed upon first. (It's much like how consensus works at the moment; many people put foward their view, and a single person carries out the action involved). CloudNine 18:54, 29 June 2007 (UTC)

I think even non-high traffic pages should do that. It should be a requirement. -Flubeca^Talk 18:29, 30 June 2007 (UTC)

Suggestion

I whould like that some mods be integrated:

1. $wgFlaggedRevsOverride whould be set to tab mode.
2. $wgFlaggedRevValues whould be set to what we currently have. (Stub,Start, ect...)

-Flubeca^Talk 18:36, 30 June 2007 (UTC)

Editor Rights

The current proposal says the software will grant it to anyone which an account over 60 days old, 500 edits, and an email address confirmed. This seems to be awfully low as far as requirements go to grant someone the ability to chose what page readers will see. This ability will affect what readers who don't know about the behind scene work will see. I don't think this ability should just be given out based on three requirements. A user could easily have 500 edits and a two month old sleeper account and could flag a page. I think we should have high requirements (1000 edits?) or a simple process for granting it. Just an idea. ~ Wikihermit 00:57, 2 July 2007 (UTC)

Well the last thing we should do for a "process" is make an RFA like process. The "automatically get the rights" thing does not seem good. A "simple" process could just be something like WP:GAC where administrators review an editor's contributions and give the rights. Fun Pika 01:12, 2 July 2007 (UTC)

At present, the requirement to choose what page readers will see is no account, 0 edits, and no email address. So I don't see 500 edits as too low--possibly even far too high. In particular, I know a number of editors who use their accounts only to make major (positive) contributions to main space articles (without a lot of small saves in between), so it will take them a long time to reach 500 edits. I think though that autoconfirmed editor status should be something that admins can take away without any sort of arb com process.

In the end, I don't think any of us knows what the actual right number should be, but I think we can agree that it should be high enough to get rid of the most vandalism while discouraging the fewest real contributors. Maybe that should be 1000 edits and 3 months. Maybe that should be 50 edits and one month (by that time, I certainly was making major contributions with few errors). -- Myke Cuthbert (talk) 01:32, 2 July 2007 (UTC)

We don't have to make it either. A simply Request for Account-like page could do. Voice-of-All 04:25, 2 July 2007 (UTC)

I agree that we should definitely have a way of requesting and giving (and removing) the right which is not tied to automatic promotion, but I think that there will be people who slip through the cracks--those who don't use Wikipedia for any sort of socialization or who work extensively on obscure topics might never request, or be granted, editor rights. How about a compromise (if the nearly all-volunteer programming team is willing to consider implementing it): similar to the "new messages" or "vote" banners, why not have a "Please consider applying for Editor rights (click here) (dismiss)" banner appear automatically for logged in users after some number of edits. I think if it's a banner application, then it should be a low number.

I also think there is consensus here that at least sighted revisions should be used at least as a test case on a few consistently semi-protected articles; others agree? What would be the next step, oh higher ups? -- Myke Cuthbert (talk) 23:49, 5 July 2007 (UTC)

Some thoughts collected

I've read over this, and have various thoghts/suggestions/agreements, but to make them all in the relevant threaded place would seem a little chaotic, so I'm making them all here.

1. The basic premise of sighted and quality revisions is great.
2. Not showing un-sighted revisions to the 'public' by default (or ever?) causes me a little concern, unless sighting is a very straightforward easy process. Given this, I suggest/support the following:
   1. Ability to 'sight' and article is basically the same as being able to edit semi-protected pages: only registered users who have been registered for a certain time. However, after this, no other qualification should be required. However, the right should be (temporarily) removable without otherwise blocking the user.
   2. The only restriction on sighting a revision, other than users who can/can't do so, be that no user may sight their own revision.
3. Who may mark a revision as 'quality' is a more knotty problem; I don't claim to have any sort of sane solution. However, some points might be:
   1. It may conceptually be seen as separate to most administrator tasks; it might not. I think the distinction may be subjective.
   2. Letting everyone I describe above as able to 'sight' revisions mark them as 'quality' is probably a bit of a stretch. Recognising quality is far harder and more subtle than recognising a lack of vandalism.

That sort of summarises my views, informed by what I've read and my own experiences... take what you will... SamBC 22:30, 6 July 2007 (UTC)

Admins are totally unqualified to recognise quality edits. Only people with subject expertise can do that. Baridiah 22:09, 18 August 2007 (UTC)

Admins are mop and bucket cleaners of wikipedia not quality experts, some admins make the worst additions to articles imaginable, but they assist in other ways like dispute resolution. Equally there are only 1300 admins and they are already stretched quite thin. I just don't think we have the systems in place to actually control the level of work this is going to create. And its all done on the premise that vandalism is a significant problem - which it isn't, wheres the proof that vandalism is out of control? most vandalism is spotted within minutes of being made. I rarely ever come across pages which have had vandalism for years. WikipedianProlific ^(Talk) 18:54, 23 August 2007 (UTC)

Integrating Flagged revisions with WP 1.0 ratings

Sooner or later, we'll need to switch from the current talk page- and bot-based article assessment system (Stub, Start, B, GA, A, FA) to one that is managed through flagged revisions. It's not necessarily something we want to do at the beginning (then again, maybe it is). But when that happens, we should probably put some effort into rethinking the assessment system itself. At the minimum, we need a new class between Start and B; there's an enormous range that can qualify as Start, and not much consistency in how well-developed an article must be before it meets B standards. Also, with the way GA has evolved, increasingly a mini-FA process, the A class is basically useless.

A more interesting possibility is to create distinct rating categories for 1) completeness and formatting, 2) prose and picture content, and 3) sourcing.

When a fuller rating system happens, will it be better to have "sighted" and "quality" as a separate rating category, or should the fuller rating system supersede the none/sighted/quality ratings (under the assumption that any rated version is sighted, and a high-rated article is synonymous with quality)?--ragesoss 03:28, 7 July 2007 (UTC)

I think that there is a value in a distinct 'sighted' system, as a variety of relatively minor edits may occur on a page, without it being re-assessed, but it is still valuable to know that these more recent versions are not affected by vandalism and so on. This is to say, rated implies sighted, but sighted does not imply rated. SamBC 03:35, 7 July 2007 (UTC)

I don't think it necessitates any change in the rating system, but if you want to discuss the topic meaningfully I suggest you take to to WP:Assessment. Richard001 04:31, 7 July 2007 (UTC)

Reviewers by category

Hello -- First, thanks to "Voice of All" for comments and participation; I (and perhaps others?) did not realize that one of the programmers of the extension was actively reading and contributing to this page and the project page. It's a big boast to the energy of people trying to give comments/think through scenarios to know that a developer is listening.

Perhaps this is better on the Extension talk, since it involves quite a bit of programming, but it's also a culture questions, so this might be good too. For the "Reviewer" right, is it possible to make it a category specific right? I know that changes what is currently a bool into an array, possibly another table, etc., but it might be something really important to think about. For instance, I am not an administrator and I definitely don't think that the "reviewer" right in general would be at all appropriate. But I am a prof. of Medieval music, so I think I could improve WP by identifying particularly good and stable versions as a reviewer in that category. Could the software accommodate this type of specificity?

The advantage of using article categories is that they are already there and they organize well into overlapping groupings. The largest objection to using them is that of course I could add [[Category:Medieval Music]] to "Mario Cuomo", deface the article, and then slap a quality tag on it. I think though that like admins abusing their powers, this type of change would be reverted quickly by calling an admin or other reviewer, and my reviewer right would be taken away just as quickly (probably along with Editor, etc.).

Just some thoughts. -- Myke Cuthbert (talk) 20:15, 7 July 2007 (UTC)

That's an interesting suggestion; however, it is also one that adds a tremendous amount of complexity to the software and, I fear, bureaucracy to its use. Group permissions are not dynamic--a person in a certain group has all of the rights of the group, not just certain of its rights on certain pages or categories--as such, implementing your suggestion would require the development of a completely new access-control system for FlaggedRevs, which presently just uses standard group permissions (namely, 'editor' and 'reviewer'). Such a rights system would have to be implemented similar to that of forumware such as phpBB or SMF whereby a page or category maintains a set of groups and users become members of the groups of that page. It's not just as simple as converting a "bool into an array," unfortunately. To answer your question, "Could the software accommodate this type of specificity," yes, it could, but it would not be an easy task by any means, and I doubt it is one we will be willing to pursue unless there is strong demand for it. AmiDaniel (talk) 22:00, 9 July 2007 (UTC)

Ah, I hadn't considered that it would involve rewriting the permission system of MediaWiki beyond the flagged revs module. Given that, it doesn't seem worth working into an early version of Flagged revisions, esp. considering how high a priority getting a working version of at least Sighted revisions is to the foundation and many editors (can we still use that term? :). I thought that maybe the per-page verification that semi-protection and full-protection provide could be used, but I can see now how these hooks would be different.

There is one user of MediaWiki which I think would have a strong demand for this implementation, given how they are trying to structure their rights model, but I don't think it's Wikimedia's job to write extensions to benefit its competitors, so maybe their developers should add this extension on their own. Still, I think in the long run if we're going to have people assuring that certain articles are "quality" it is going to mean having the article reviewed by experts who can vouch for completeness, recent interpretations, etc., in addition to MoS concerns. Such experts will seldom be WP:Administrators.

Thanks for the comments. I'm really excited by the prospects of not needing a 24/7 vandal patrol. -- Myke Cuthbert (talk) 23:37, 9 July 2007 (UTC)

Hey! I am writing another extension mainly for CZ :3 Voice-of-All 12:16, 13 July 2007 (UTC)

Oh cool! Lots of great things happening on the development front. Glad to know also that others are working on both projects. Hey when did " " change to "leave a comment"? I guess it is clearer. :) -- Myke Cuthbert (talk) 15:16, 13 July 2007 (UTC)

What if the revision shouldn't be marked?

This question has probably been answered before, but I haven't read it. What happens if an edit is vandalism? Can editors, or reviewers "delete" that revision, in the sense that they have marked it as "Unreadable", or vandalism? It seems to me, that having the little box at the top of the page saying "One revision to be checked", when the revision to be checked is vandalism, would be a little weird, because the reviewer (or Editor) can't mark it as a "bad" revision, can they?

You make a new version which removes the vandalism, and mark that one 'sighted'. The easiest way to make the new version is often to simply revert to an already ok'd version (when the only changes since then are vandalism). -R. S. Shaw 03:32, 6 August 2007 (UTC)

Second Question, would edits made by users with "Editor" or "Reviewer" status be automatically flagged as Sighted, similar to the Patrol function? (Not enabled on Wikipedia) GrooveDog (talk) 15:52, 22 July 2007 (UTC)

No plans for such, as the whole revision gets flagged. Say an 'editor' edits a section after another one was vandalized. That would make that risky. Voice-of-All 22:51, 9 August 2007 (UTC)

Flagged revisions v. Stable versions

I'm curious how flagged revisions differs at this point from the German stable versions system. What details are different? I think I understand but I'd like to see this set forth by someone who's been closely involved. Also wondering whether we have a firm date yet for implementation. Durova^Charge! 16:03, 23 July 2007 (UTC)

The main difference seems to be the name. GO AHEAD, priests, we want this .. (sinking to their knees .. praying .. singing) --Bernd-vdb 14:39, 25 July 2007 (UTC)

Better get rid of "Editor" rights or you'll just confuse people

I recommend "Reviewer rights." ←Ben^B4 08:10, 4 August 2007 (UTC)

So do I. The word "editor" is already in widespread use for everyone who edits Wikipedia, and that is only the natural meaning of the word. Mel sa ran (formerly Salaskаn) 14:42, 4 August 2007 (UTC)

'User' or 'Wikipedian' are also used, but I use editor myself quite often and I think it could easily be confusing. I'd just go ahead and change the wording. Richard001 00:21, 5 August 2007 (UTC)

Yes, "editor rights" is unnecessarily confusing. However, "reviewer rights" is not suitable because it is (in the proposal) already used for a different right, as you will see if you read further through the proposal. It designates the ability to set "quality" attributes, not for setting the "sighted" attribute.

I suggest "overseer rights" because it is not overused like editor and reviewer, and hints at the related capability, that of setting the sighted attribute. Other possibilities are surveyor rights and inspector rights, although I find the latter implies too much authority. -R. S. Shaw 03:21, 6 August 2007 (UTC)

I like overseer. Referee is another option. Richard001 04:32, 6 August 2007 (UTC)

No. "Overseer" implies a person with the Oversight permission. Mel sa ran (formerly Salaskаn) 15:38, 6 August 2007 (UTC)

So what can we use then? Referee or editor seem the only remaining suggestions. Richard001 23:14, 6 August 2007 (UTC)

How about "sighting rights", in parallel with "sighted version"? -- Jitse Niesen (talk) 02:52, 7 August 2007 (UTC)

Looks fine to me. Mel sa ran (formerly Salaskаn) 02:54, 7 August 2007 (UTC)

Agreed that co-opting editor is a problem. I think "reviewer" was already going to be used for the more controversial "quality" tag (which better fits what giving a "quality" tag entails), and that overseeing is problem because of the oversight permission. I like "surveyor" though I could also go with the less poetic "sighter" because, in the end, I don't think that the word for "the person with a 'sighter' tag" is going to be used often. It's like how we don't have a short term for "registered user who has been around for at least four days," even though this status conveys a few extra privileges. I hope that the "sighting" ability will mainly be used to reduce vandalism and obvious bad edits on WP and thus will be wholly uncontroversial once it's adopted. -- Myke Cuthbert (talk) 02:57, 7 August 2007 (UTC)

Agreed. See also my proposal above. We should mark any page that isn't vandalised or trolled as sighted, to prevent the tool from getting used in content disputes. Mel sa ran (formerly Salaskаn) 02:59, 7 August 2007 (UTC)

I like "surveyor" as well, with "sighter" as an acceptable alternative. I think "reviewer" should be reserved for assigning "Quality" status, and "editor" is right out.--ragesoss 01:55, 16 August 2007 (UTC)

Agree. Editor is too broad a term and Reviewer is more suitable for the high quality level of articles. How about "Inspector" or "Scrutinizer", in line with my suggestions below for replacing the discriminatory "Sighted" term. Hu 21:02, 16 August 2007 (UTC)

I admit to being confused! The last thing we need is new jargon. If we are talking about an editor who is trusted to have a few extra permissions/priviledges we are talking about a trusted editor.ClemRutter 18:27, 23 August 2007 (UTC)

Just do it

Is there some technical reason why this has not been implemented yet? If not, why not just start now with the policy as given on the current page (unchanged for two months) and see how it pans out? It seems a blatantly obvious improvement, the only argument being how to fine-tune it to get the best results, which can be done after it goes live. The franchise for automatic "editor" status is pretty tight (almost as tight as for Foundation board elections) so it will certainly exclude common-or-garden vandals. I'd be happy to see a smaller edit count required, but the main thing is to get going. The worst that can happen is that too trigger-happy sighting freezes up a lot of pages as seen by the outside world, as suggested by some commentators above. IF that turns out to be a problem it can be solved by extending the franchise by reducing the number of edits required. But it shouldn't be necessary if we ask people only to sight pages on their watch list, at least at first. (We probably need a "Please sight this page" noticeboard as well).

As for reviewed status, there obviously needs to be a debate about how reviewer power is awarded and how it should be applied. It can be trialled by initially restricting to new FAs and FAs which pass FAR, with "reviewer" status initially given to the admins who close the debates (I doubt they would over-use it since Raul654 is a strong advocate of allowing edits by anyone). PaddyLeahy 13:21, 13 August 2007 (UTC)

Because the idea of this sweeping change is not universally accepted (and, in fact, is not even known to the vast majority of editors since it has not been publicized properly). Badagnani 21:25, 13 August 2007 (UTC)

Replacing a bad job with a worse one

Of the two proposals presented here I would somewhat support the quality proposal. With the sighted revisions proposal, no one can see the vandalism. However, nobody except "editors" can see any constructive edit an anonymous user makes until a cabal of "editors" approves it. Anonymous users are editors and real people as well. With this proposal vandalism still needs to be reverted. Except with this, the vandalism won't be noticed until a logged in user comes along and reads the article, since the former vandalism patrol will be too busy "approving" typo fixes. I believe the first proposal goes against the spirit of Wikipedia. The second one does as well, but it can be justified. If we do go ahead with the second one we'll need to do it in a way that doesn't add another class of users. I would prefer a system where any two or three users could approve an edit to a featured article. If they can't reach unanimous consensus the edit will be reverted and the issue brought up on the talk page.

There's always going to be bad edits. To me, this system is like slapping a semi-protected notice on every article that's been "sighted". When an article is semi-protected an anon has to ask for an edit to be made. If an article is "sighted" the anon can make the edit, but 99% of the world can't see it until a "superior editor" says that the edit is good enough. I unfortunately cannot use the phrase "If it ain't broke, don't fix it", but I can assure you that Wikipedia will be broken by this proposal more than it will be by immature vandalism that quickly gets reverted. Psych less 20:49, 15 August 2007 (UTC)

As I read the policy, any anon reader can see the current version just by clicking on the "current version" tab. So if anons feel like fighting vandalism there is nothing to stop them...the sighted version is (i) a convenience for the (surely large majority) visitors only interested in using the site. (ii) hopefully a serious deterrant to casual vandals as they are no longer defacing the default view. To me, the main advantage is that editors who currently spend a lot of time vandal whacking (not me) will be able to do something more constructive.

Also, given the amount of checking requested before sighting, it's likely that the majority of pages will not have a sighted version, at least not for a long time.

By the way, reading around this topic, there was supposed to be an experimental introduction of this system on the German wikipedia. Did this happen? If so, what was the reaction? (It doesn't seem to be implemented there at the moment, as far as I can tell with essentially zero German language competence.) PaddyLeahy 21:05, 15 August 2007 (UTC)

The software isn't finalized, so it hasn't been implemented there just yet. Voice-of-All 02:12, 16 August 2007 (UTC)

Regarding what Psychless says, I would be in favor of Bots (or the software) auto-sighting changes which haven't been reverted after a certain amount of time (five days?) which aren't major reductions of page length or contain obvious profanity. I'm mainly looking for a system which prevents 99% of obvious B.S., vandalism, and defamation of character from ever appearing on the screens of casual users of Wikipedia. Hence I'm also in favor of allowing a preference for automatic sighting after editing the way there is one for automatic watch-listing after editing. I tend to edit pages only after reading them (or at least reading the diffs from the last time I read the page), and certainly if I were to edit an unsighted page, I would check for vandalism. I don't think I need to always add an extra step to saving my edits. -- Myke Cuthbert (talk) 02:07, 16 August 2007 (UTC)

I don't think that's a good idea. Remember, the bit about Seigenthaler assasinating Bobby Kennedy stayed in for months without reversion, and things like that being auto-sighted is an invitation to have everyone complain "Wikipedia claims that 'This guy assasinated JFK' is free of vandalism!" Auto-sighting on an edit, though, is a good idea. -Amarkov moo! 02:20, 16 August 2007 (UTC)

Right, auto-reviewing on edit will be a feature. Voice-of-All 13:28, 16 August 2007 (UTC)

I agree with Psychless. This proposal hides the vandalism, but does nothing to prevent against them. This is like an osterich sticking its head into the sand thinking there's no enemy around. We can't pretend the vandals didn't edit the article, because they already done it! Furthurmore, at the moment, anyone can go revert vandalism. This proposal suggests less editors able to do so, thus increasing their revert workload. OhanaUnited ^{Talk page} 13:46, 16 August 2007 (UTC)

Any user, or non-user, can still revert the current revision, such as removing vandalism. The sighted one is far less likely to be vandalized, so it doesn't have a real revert workload. Not to mention that by removing much of the incentive to vandalize, there may be less vandalism anyway. Voice-of-All 14:32, 16 August 2007 (UTC)

You're looking for a system that prevents 99% of the aforementioned vandalism? I believe we already have that. This sighting system is going to make editing very complex since editors are going to have to "sight" every edit they make. An auto-sighting system would make the whole process useless. So with this system we now need a "sight patrol" that needs to "sight" every helpful contribution and the vandalism will be encountered through this process and reverted as well. So let's say the vandalism doesn't get reverted. What does this system do besides hide the problem. This proposal seems to have good intentions, but this system won't work. The phrase: "The librarians are hiding something" -Stephen Colbert, will become very close to the truth with this proposal. I also hate the idea of "improving our public image" with this. Our public image will improve as the actual content of the encyclopedia improves. Psych less 00:35, 17 August 2007 (UTC)

About the "auto-reviewing on edit" - Just to be sure, that will only apply to articles that have already been marked as "sighted" correct? Mr.Z-mantalk¢ 00:54, 17 August 2007 (UTC)

Yes. Voice-of-All 22:00, 17 August 2007 (UTC)

Thoughts about 'proven' editors seeing the current version

I have a thought regarding the current version. As I understand it, the recent 'confirmed' revision gets shown to the anons and Joe Public, and the current version to proven editors (although this may be an optional setting?).

What would happen if the 'current' version was not automatically shown to the proven editors (unless there is no recorded quality revision for an article)? In this way any proven editor who is just browsing/researching - believe it or not, it still happens - will still be sure of a non-vandalised version and would also be prompted to approve the recent edits (removing any backlog situation, and confirming any genuine edits that may not be displayed for a length of time.

Am I right in thinking that this extension would be automatically installed across the wiki? If so, may I suggest that the default setting is for everyone to see the quality version, with the option for proven editors to choose to see the most recent? This would allow the browsers-who-edit-occasionally to be sure of a good revision, and encourage the editors-who-browse-occasionally to check the recent edits and 'up' the flagged revision to a newer one.

Anyway, please discuss. –MDCollins (talk) 23:26, 15 August 2007 (UTC)

I agree that there should be an option to set it that way, but the default for logged-in users should be to facilitate editing. -Amarkov moo! 02:11, 16 August 2007 (UTC)

MDCollins' is the best argument for making the sighted/quality the default for logged in editors I've seen yet. It may end up being such an important distinction between browsers-who-edit and editors-who-browse that in the future we may want to ask about the preference at account creation.

What might be the best option: Set "recent by default" for people with current accounts, so that this extension doesn't change the view editors are used to, and make "sighted/quality by default" the default for all accounts created after the flagged revs are introduced, so that getting an account doesn't change the behavior those people are accustomed to. -- Myke Cuthbert (talk) 02:14, 16 August 2007 (UTC)

Approved and Stable versions

Citizendium and the German Wikipedia have both tried this. Does anyone know how those projects have faired with there different systems? How are the problems encountered in their systems been taken care of with this system? Don’t get me wrong, I too long for the day when it will be flaggers vs. anti-flaggers instead of deletionists vs inclusionists, but let’s not rush into this without learning from previous attempts.--Rayc 02:30, 16 August 2007 (UTC)

Agreed. Why did we have the German Wikipedia beta test this if we have nothing to glean from their experiences? Can someone create some type of report on how the German Wikipedia implemented this feature and what their experiences were? Kaldari 22:17, 16 August 2007 (UTC)

According to Voice of All in an above thread, the software has not been finalized yet so it is not implemented in de-wiki yet. Mr.Z-mantalk¢ 00:58, 17 August 2007 (UTC)

Support implementation

I'll go on record in support of this, mainly because of conversations with non-Wikipedians. The vast majority of people who visit this site are looking for reliable information, period. Their major concern is whether the articles they read have been corrupted. Anyone who desires to go beyond that to the nuts-and-bolts of wiki editing can do so, so this is win-win. Not perfect, perhaps, but far better than what we have. Let's go for it. Durova^Charge! 04:58, 16 August 2007 (UTC)

Same. Stable versions are not only necessary in push for higher quality, but they'll also be good PR (Well, yes, but teh CIA trolls couldn't get at the stable version!). Something needs to be troll-proof. Moreschi ^Talk 17:36, 16 August 2007 (UTC)

I hope we're not doing this because it's troll proof. No concievable technical measure (except restricting editing to a certain group of editors that never changes) can totally prevent trolls. -Amarkov moo! 18:07, 16 August 2007 (UTC)

I support implementing these policies as soon as possible. Kaldari 22:23, 16 August 2007 (UTC)

I also think we should implement this within the next few weeks, rather than waiting for de-wiki to try it out first. My experience with non-Wikipedians mirrors Durova's: this will be a considerable benefit to the majority of readers. Of course, it isn't troll proof. It just reduces the incentive for juvenile vandalism, since most of it won't ever be seen except by Wikipedians.--ragesoss 03:32, 17 August 2007 (UTC)

Against the whole spirit of a wiki

I support this in theory, but viewing a non-current page by default goes against the whole spirit of a wiki. A huge number of good contributions come from non-logged in users, and while this proposal will not prevent them from contributing, it seems inevitable that it will confuse. This in particular: "users who are not logged in may not see the most recent version of a page by default, but will always edit the most recent version." That’s just asking for trouble. Perhaps there should be a reverse of this idea, so that all users see the current version, but there is an option to view a reviewed history version. Think outside the box 13:00, 16 August 2007 (UTC)

The spirit of a Wiki is that anyone can contribute. This keeps that open and retains the ability for anyone to view all revisions. Durova^Charge! 18:05, 16 August 2007 (UTC)

Indeed. This effectively helps us get closer to the spirit of a wiki: since vandalism will not be immediately displayed to readers, semi-protection will become less and less common and more users will be able to edit pages; a good thing. CloudNine 18:07, 16 August 2007 (UTC)

Well, yes, they can still contribute. I would say that 70% of our readers do not know that there are revisions. Let's say I'm an average person reading an article. I happen to notice a typo; I click edit. Now I'm likely editing a different version of the page, I assume someone must have edited it by the time I clicked it. I fix my typo, hit preview, then click save. The article is the same. I try to refresh my browser, think I must have made a mistake then try to fix it again. When I hit edit I see the typo is fixed! What! I go back to the article and it still doesn't show the change. I get angry, finish reading the article, and likely do not contribute again since I think my computer is messed up or the editing system is messed up. This whole system of approving edits is idiotic. Would you like to wait for some "superior" person to approve all your edits? Any thinking person knows that vandalism is inevitable on a wiki like this. Vandalism gets reverted very quickly, so I believe it is rare for an average reader to see it. Psych less 00:50, 17 August 2007 (UTC)

Agreed. That's exactly what I've said since the beginning. But I've also been told, more than once, that "This is going through no matter what you say," since Wikipedia's rulers apparently see a need to emulate Citizendium in this regard. Badagnani 00:54, 17 August 2007 (UTC)

Actually, sysops can configure the UI messages to make the tag on the top of the page make it even more obvious that users/anons can edit that the "edit this page" tab. Also, the tag shows the number of unreviewed changes, which pings up each time an edit is made (unless autoreviewed). This can be configured to be more obvious if needed, again, by sysops editing MediaWiki messages. Also, no one said that reviewers are "superior" to any anon, but their edits by and large, unlike half of anon's, won't be vandalism. Just saying "vandalism is inevitable", which, yes "thinking people" get, which is part of the reason for the proposal, doesn't really help our readers, many of whom don't know is actually a wiki (including people I've met). And this will home in the decline of semiprotection indeed. IMO, people should look more closely at what is being proposed and what potentials/configurations/modifications are possible, rather than just firing off snide one liners (such as the oft "trying to emulate Citizendium" remarks). Yes, like anything, it has drawbacks, but most of the reasons people are giving against any idea of stable version don't hold much water, at least so far. Much of the first criticism people made was based on failing to actually read the proposal/extension page thoroughly. Voice-of-All 01:47, 17 August 2007 (UTC)

(outdent) I see the legitimate side of this objection and I think it can be addressed through communication and outreach. Durova^Charge! 06:33, 17 August 2007 (UTC)

I don't think this proposal will go through unless the community supports it. However, I personally think this proposal is a very good idea, and should be implemented, albeit with a little tweaking. Pyrospirit (talk · contribs) 18:03, 23 August 2007 (UTC)

It would probably be a fairly minor change to the software so that once a reader has made an edit they are sent to the most recent (non-stable) version of the page for the rest of their browsing session. This would substantially reduce the 'wtf my edit is gone' factor. --Gmaxwell 18:35, 23 August 2007 (UTC)

Terminology Naming and number of inspectors

We need a better term than "Sighted". The implication is that blind users are excluded. Further, there is no explanation of what the term derives from or means exactly and I am at a loss to imagine how or why it was chosen. Why not call it "Presentable" or "Reviewed" or "Inspected" or "Examined" or "Scrutinized"? Of these, the first, "Presentable" is the lowest level and probably the most appropriate term because it connotes the least amount (none) of fact-checking.

As an aside, I would suggest at least two editors and possibly three to inspect an article before it gains this status, otherwise it becomes another way for a single editor with an agenda to have an oversized impact on Wikipedia. Collusion is not likely to be a problem for more than a couple of articles because it becomes possible to compare edits and see patterns if collusion exists. Hu 20:57, 16 August 2007 (UTC)

I think inspected versions and quality versions sounds good. In my opinion, it should only require one trusted editor (surveyor) to make a revision sighted/inspected (whichever term we end up using), but I agree that marking a revision as quality should require 3 reviewers to mark it as such. Or, maybe allow a revision to be marked as quality by 3 or more surveyors in agreement. Pyrospirit (talk · contribs) 17:58, 23 August 2007 (UTC)

Why?

Yes, I do get the core reason why we are doing this. We're trying to combat vandalism and other thing. Heck, I've got a proposal of my own to combat vandalism. I have heard about this idea (patrolled edits) before, and I think it was tested on the de.wp before (?). But I think more than any other proposal I've seen, this is in great contradiction to the spirit of Wikipedia. WP is an ever moving and changing encyclopedia. When you edit something it goes live the second after you press save. There are a couple reason I don't like this proposal:

1. By giving certain users (those with over 500 edits) the permission, it reeks of elitism. It took me from the start of June till the end of July last year to rack up 500 edits. If I would have seen your edits are important to us, but you must wait for someone who is obviously more knowledgeable than you to approve your edits, I would have left. I'm not even joking. I would have said "This isn't worth my time to see if some person I don't know thinks I'm good enough to edit their encyclopedia".
2. The sheer amount of work that this'll add. Wikipedia gets 10s of edits per second. We don't have enough users to approve every single one, much less write the best encyclopedia we can. There are already enough backlogs here. As was said above somewhere, some articles will stay the same to readers for months because they aren't watched by regular users. Only the main articles will get updated regularly. Some articles literally live on annons editing (Saskatchewan Roughriders is one I know of). And how about current events? The shootings and bombings? News agencies have talked about our updating of current events, which will be lost if this is implemented.
3. Let's face it, the only reason Wikipedia works is because of the immediate gratification. If people are told they have to wait for their article to be reviewed, it takes away from that. Wikipedia is part of Web 2.0, the idea that we as a general public can put information and other stuff up ourselves. From the kids to the intellectuals, everyone can edit Wikipedia, anyone can write Wikipedia. When you put a review up, it's no longer writing. It's submitting to a review board something that you think is good (eg, a band that's good, signed, kind of well known, meets WP:BAND) that mainstream editors do not care about. All the sudden we're being cared for and coddled again. Your throw out all the stops and you have Wikipedia. You put them back in, and you've got Citizendium.

People may not like it, but those are my reasons. But then again, what do I know? I'm just a reader, editor, administrator. -Royalguard11(T·R!) 02:11, 17 August 2007 (UTC)

Interesting. As for 1), note that the "500" is a rough guideline of this proposal draft, and even if it where the recommended number, it would and should never be a hard number. Actually, for some users, it can be 50, really. Where people request editor rights, a quick look through contribs will show that some users like to make less, but larger edits. As for the others, note that the stable version need not be the default, which would resolve issues of pages falling out of date/removal of instant gratification. Also, the number of people that meet requirements to review pages (having been around for long enough and trusted to not be a vandal) would be much larger the the number of admins. But even with the option to not make it the default, I am not convinced that everything would fall behind. Current events that are edited up to the minute likely would have people there to review it, people who review are prompted to watchlist pages they look over, and unreviewed edits are flagged in watchlists/recent changes. And a group of thousands of editors (1 alone can check for vandalism) isn't really an "approval board" IMO. Voice-of-All 02:29, 17 August 2007 (UTC)

But the idea is that readers (ie, not logged in) will only see the "stable" version. When I read Wikipedia, I want to see the most recent up-to-date version without having to log in. Of every page. For the average person (non-user), this is going to make a huge difference. This would be the largest change in the history of Wikipedia. It would be the equivalent of, say, Mozilla making daily builds of yesterdays trunk for average testers as opposed to todays. -Royalguard11(T·R!) 03:16, 17 August 2007 (UTC)

Re your item (2): in fact nearly every anon edit does get reviewed, as you can see from the fact that something like half of them get reverted (which suggests that most of the unreverted edits must have been looked at and "passed"). If flagged revisions have the effect that optimists hope for, vandal edits from anons will be dramatically reduced while good faith edits will not. I don't know how much trouble it will be to set a "sighted" (whatever) flag, but assuming it is a one-button push this suggests significantly less effort would be needed than now. Especially if the sighting retains some element of the original intent of "stable" versions, in which case the advice would be not to flag every good edit as soon as possible, but to re-sight at a relatively sedate pace (what that means would depend on how much edit traffic the article was getting: for breaking news stories it might be every 5 minutes). PaddyLeahy 03:34, 17 August 2007 (UTC)

The point is, disclaimers notwithstanding, Wikipedia will at some point be sued by some celebrity whose page is vandalized with libelous content and the entire site may be shut down. I think we've already come close. A trustable, completely open content encyclopedia is an oxymoron. The goal is an encyclopedia, not the world's largest wiki. Letting any asshole with a browser write whatever they want on any page anywhere invites vandalism. If we're going to continue as a project we have to start exercising some sort of control. -- Rick Block (talk) 03:38, 17 August 2007 (UTC)

I think we can find a way to make this all work in practice - to retain the most of the "instant gratification" aspect, to value good faith edits by anons, while vastly improving the reliability of Wikipedia. We may need to tweak the system to get the right balance, but heck, we really need this.... Walkerma 03:53, 17 August 2007 (UTC)

In response to "readers (ie, not logged in) will only see the 'stable' version" That is true. This means that they will not see subtle vandalism, like a changing of a date or other barely noticeable inaccuracies. Of course if readers want to see the most recent version, there will be a link on top of the page (See commons:Image:Taggedrev.png for an example) to see the current version. Mr.Z-mantalk¢ 04:11, 17 August 2007 (UTC)

Manageable proposal focusing on quality

In light of my recent comments I feel I should state my ideas on how this proposal should work. I feel that the featured articles process could be improved. The featured and good article processes are a way to assure the reader that the article they are reading is of the highest quality. I believe there should be two processes, to simply give them names I will call them: Highest Quality and High Quality. High Quality articles will be subject to the FA criteria, excluding criterion 1a. I believe that engaging prose is not what most readers are looking for in a quality article. An article can have an average level of prose and still be high quality. People nitpick about prose at FAC, but rarely help fix it. Highest Quality articles will be subject to all of the FA criteria and the article must be examined by a subject expert. The definition of subject expert will require much debate, I am certain. I believe that High Quality articles should have a silver star at the top of the article, giving a short explanation of the High Quality process. Highest Quality articles would have a golden star, and one or more green checkmarks. The checkmarks would say when you hover over them: This article has been as being factually correct and comprehensive by [subject expert's name]. The link would go to a page that tells about the subject expert and their examination of the article.

How does this fit into the proposal? Well, I completely disagree with the sighted version proposal. I've stated my disagreements with it elsewhere. High and Highest Quality articles will be granted the quality status by administrators and bureaucrats after they have passed the processes. When a user has the quality version open, and they click edit, a message will explain that they may be editing a different revision of the page than the quality one. It will also say the changes they make will only show on the "current revision" page. Every month a process would determine whether the current revision is an improvement of the article. Some changes to the current revision may need to be made for it to pass. Any editor can request that the current revision be compared to the quality revision, up to once a week for Highest Quality articles and up to once every three days for High Quality articles.

These are my ideas. Since this proposal is likely going to go through one way or another let's focus on assuring quality. Psych less 03:58, 17 August 2007 (UTC)

The primary issue (there are others) with this proposal is one of scale. There are nearly 2M articles, but only about 1500 FAs and less than 3000 GAs. Combined, this is less that 0.3%. Adding any overhead at all to either of these processes will slow them down. At the current FA promotion rate (roughly 70 per month) the percentage of FAs has been dropping (i.e. there are more than 10,000 articles created per month, and the creation rate is increasing faster than the FA promotion rate). Any system rooted in the current FA or GA processes will address only a miniscule portion of the articles we have. Increasing the overall quality requires a systemic solution. The current system (open wiki with semi or full protection in exceptional cases) is simply not doing it. -- Rick Block (talk) 04:21, 17 August 2007 (UTC)

Your comments barely address my proposal. My proposal is to keep FAs and GAs from losing their status because of bad edits, make a process with slightly higher standards than FA and an official one that has somewhat higher standards than GA but is more official. I would prefer to keep this "sighting" proposal out of the quality one. The percentage of FAs is dropping because many people are writing new short articles. Quality is going to take time, we have to accept that. Judging by your previous comments I see you're in favor of the "sighting" system so why are you so worried about overhead here as well? My proposal is trying to set an attainable level of quality and assure readers they are reading articles of the utmost quality. Psych less 04:37, 17 August 2007 (UTC)

Addressing only FAs or GAs or any other very selective set of articles does next to nothing. I'm tremendously worried about overhead (it's what inhibits scale). I think any solution has to: 1) allow lots of folks (many, many more than the current number of admins and bureaucrats) to judge whether edits are "good" and 2) allow the 80% of Wikipedia's users who never make any edits to avoid seeing crap. I think 95% of people have good intentions (AGF and all that - but I actually believe it). The issue is coming up with a way to keep the 5% of the people who are assholes from ruining life for the rest of us. If we assume 80% of Wikipedia's users never make any edits (I think that's a pretty good guess), and 95% of the rest have good intentions, we're left with a 1% sort of problem. This is not really worth worrying about unless the amount of effort involved in cleaning up after them or the legal risk is not acceptable. I think we're there on both counts. So, I think inconveniencing new and anonymous editors (by showing them the last "sighted" version, but not stopping them from editing) is a reasonable tradeoff. My opinions on this are not a secret, see User:Rick Block/Keeping sewage out of the wine if you're interested. -- Rick Block (talk) 04:59, 17 August 2007 (UTC)

I fail to understand your logic. If I understand you correctly, you're saying that about 1% of users are causing a problem. We should implement this proposal because we're spending so much time cleaning up after them. It will be twenty times more work if 20% of users edit. You're going to have to sight every edit anyone makes. So that means every good editor is going to have to "sight" their edits because of immature idiots posting profanity and nonsense. To me it sounds like we're punishing all users, new and anonymous users even more so. We're also just hiding the vandalism problem. It's still going to happen, it's still going to get reverted. Only, since the vandal patrollers will be so busy sighting good faith edits, it will get reverted much slower. It's really easy to tell newer users that they can't do something. You wouldn't be too happy if I told you that I was going to approve every edit you made for a month because I think you're probably going to deface some article. If 80% of users never edit I can gurantee that 99% of them will never click the current revision. It is also much more likely that the current revision will be better then the sighted revision rather than worse since most edits are made in good intentions. I've read your essay, and cannot say I agree with it. You've let the vandals win when they lead you to believe they're causing so much trouble that you have to implement a proposal like this that hurts everyone, just to hide this commonly known problem of ours. Psych less 15:23, 18 August 2007 (UTC)

Let me turn this around. Your proposal is that all edits to some number of articles (FA or GA or High Quality or whatever) be generally withheld from view until being reviewed by existing admins and bureaucrats, these "special" articles are quite visible somehow (silver or gold star), nothing at all changes for the other 99 % of our articles, and that given enough time the number of monitored articles will grow. This is similar to other proposals I've seen and IMO is basically equivalent to protecting all FAs (forcing anyone other than an admin to propose changes on the talk page rather than directly making changes). The basic problems I have with this sort of approach are:

1. admins are not the right set of people for exercising content control - they're not subject matter experts (except by coincidence) but merely folks the community trusts with the revert/block/protect/delete set of tools.
2. to get to even a fairly minimal number of "special" articles (like 100,000) will apparently take at least dozens of years (we're at about 1500 FAs after 5 years, the promotion rate is currently running at about 2/day - if we charitably call this 1000/yr it will be about 100 years before we get to 100,000).
3. no matter how visible we try to make them, the "special" articles will not be considered by most people to be any different than the rest of our articles. 80% of our readers never edit, don't know they can edit, don't know we have FAs or GAs, and don't think of Wikipedia as anything other than that place Google finds nearly every time they look something up. If no "quality" related processes are put in place universally, no matter what we do for some percentage of our articles we will forever be tarred with a "Wikipedia is completely unreliable" brush.
4. this does nothing at all for the bulk of our articles, which now number nearly 2M. Even if we have 10,000 people willing to watch for vandalism, that means each of them must watch 200 articles (with no overlap).

I agree that because most people are trustworthy, even without every article being watched vandalism will tend to be corrected (given enough time). The problem is we have 100,000 articles on living people, and at least as many on companies and other organizations, any one of which might decide to sue us if their article gets vandalized - potentially resulting in the entire site being shut down. If we do nothing for the bulk of our articles, I believe this is a way more likely outcome in the next 100 years than that we end up with 100,000 FAs. So, what's your alternative suggestion?

Mine, which I think is consistent with the flagged versions implementation, is that essentially all regular editors be allowed to make changes that immediately take effect, but changes from other users pend until one of the "regular editors" (not just admins or bureaucrats, but any "regular editor") looks at it. Note that this doesn't mean that all changes anyone make have to be checked by another user, just changes made by folks who aren't yet tagged as being "regular editors" (I'm not sure, but perhaps you've missed this aspect of flagged versions - "regular editors" can and presumably will "sight" their own edits). The barrier to being tagged as a "regular editor" is very, very low (it happens automatically after some time period or number of edits, or by request). I think most edits are made by "regular editors" (statistics on this would help, but I don't know of any), so with this scheme no one needs to look at most edits only the edits made by folks who aren't yet "regular editors". I don't know the statistics, but I'd think this would only be a relatively small percentage of the edits we get (maybe 20%) and that overall it will take much less time and effort on the part of the "regular users" than what now happens (which is that no one really knows who to trust, so trusts no one and looks at all changes to every article on their watchlist). -- Rick Block (talk) 01:53, 19 August 2007 (UTC)

Overall I don't hate the whole idea quite like I did before. I still think it's going to add unnecessary hassle to regular editing, but it can't hurt things too badly if we just try it. According to this the libel has to affect there standing in the community: i.e. George W. Bush gets impeached because someone wrote that he cheated on his wife or is a stupid purple elephant in his wikipedia article. So I think having constant lawsuit-phobia when you discuss the proposal is a little unnecessary as well. I also think that number would be closer to 60%. When the same site turns up as #1 a lot, you might actually go to the main page or wonder what the "edit this page" button means. As long as the backlog for unsighted edits can be kept to a manageable level I believe this proposal could work. Psych less 16:37, 20 August 2007 (UTC)

A few points

1. It is very important that access to set the first level of 'approval' be granted automatically by the software. I agree that brand new users should not have this, but it essentially fills the same role as 'semi protection' does currently and should be widely available. That said, I would actually suggest a rule like, "article edits on more than 30 different days". Under a rule like '30 days and 100 edits' a vandal could still create ten accounts, wait 30 days, make 100 userpage or even vandalism edits quickly, and then be 'qualified' to approve revisions... the 'days on which article edits have been made' counter method would prevent any such sort of 'blitz attack' from multiple accounts. Also, in some cases a static IP might qualify to have this access, but that would have to be set by an admin.
2. The German version of this proposal had a feature where if the current revision has been marked 'approved' and the user making a new edit has access to mark revisions 'approved' then the new version is automatically marked 'approved'. I didn't see that in this writeup, but may have just missed it. I think this is an important factor to include... as it will result in articles that are regularly edited being constantly kept in an approved state as each editor is responsible only for their own edits and doesn't have to go back and review everything done by others since the last 'approval' flag was set.
3. The 'Sighted' and 'Quality' names were presumably derived from translating the similar categories from the German proposal. I might suggest something more like 'Reviewed'/'Examined'/'Checked'/'Looked at' and 'Featured'/'Verified'/'Approved'.
4. I think the higher verification setting should be synonymous with 'featured article' status... which, once this is implemented, will hopefully grow even stricter - to require that all references actually be looked up and verified to contain the information they are purported to. When that happens our 'featured' articles would finally be every bit as carefully fact checked as any print encyclopedia (indeed, more carefully checked).

Looking forward to implementation. This will fix ALOT of problems, but it needs to be done right. The controls on who gets to mark revisions approved are absolutely crucial. --CBD 13:26, 17 August 2007 (UTC)

Quick note - I just added some of the main points from the German plans to the page, as well as links. Walkerma 17:32, 17 August 2007 (UTC)

• I agree strongly with points 1 & 2. One of the key problems here is scaleability; the accumulation of backlogs of unsighted revisions isn't going to help anyone, so the sighting privilege, whatever it's named, needs to be made as widespread and transparent to use as possible. I also agree that requiring edits on 30 separate days would make a lot of sense in filtering out vandals. Could the software also review the user's talk page history for vandalism warnings? In concert with widespread autoprivileging, admins would also need to be empowered to temporarily remove the privilege without too much hassle. Espresso Addict 23:07, 17 August 2007 (UTC)
  • I would suggest that we initially set the automatic threshold high. That way, only the more experienced users will get the new functionality right away. Other users can still request it on a page like that used for requesting Vandal Proof or AWB; they put their name down and an admin checks their contibs to make sure they are not a vandal. Once we work out any possible kinks and loopholes in the policy here, determine the possibility of abuse, and get people used to the new system (once this gets rolling it should be quite noticable) and acquainted with the rules, we set the automatic threshold lower. Mr.Z-mantalk¢ 00:06, 18 August 2007 (UTC)
    • Actually, I'd suggest the opposite -- setting the initial threshold very low, and ratcheting it up if that causes huge problems. Otherwise the reduction in the abilities of very large numbers of editors would be likely to cause significant loss to the project of valuable editors; Vandalproof etc aren't good models, as they are additions to an editor's abilities. Don't forget that, compared with the current system, there's no risk even from setting all logged-in editors as auto-sight-privileged & autosighting all their edits. On the other hand, the risk of (1) alienating existing good contributors; & (2) building up impossible backlogs of revisions to check both seem very real.

In fact, one way of rolling this out might be to default all logged-in users to auto-sight-privileged, and then remove privileges for vandals or those otherwise abusing them. Espresso Addict 00:35, 18 August 2007 (UTC)

Not entirely, the users are actually given the right at that point, rather than implicitly. This was is clearer for users and shows at Listusers, however, it can also be reversed by admins removing the flag. If we give it *too* liberally, we will not a lot of right stipping. On the other hand, stripping them is much harder than blocking someone. Personally, I'd start liberal, and tighten later (or maybe loosen if it really seem like a good idea). I lowered the 500 to 300. I'd like it much lower, but that would require better heuristics, perhaps like the "30 days with an edit" idea. Any other good suggestions are welcomed. It's hard to find something that is efficient enough for the MySQL database to handle with little impact. Voice-of-All 00:47, 18 August 2007 (UTC)

'Assume good faith' seems to suggest that the threshold ought to be set as low as possible, and I really do think there's a significant risk of putting off newbie editors if the threshold takes a long while to reach. Is there any research on how quickly logged-in vandals are identified -- how many edits an obvious vandal has to make on average before someone slaps a vandalism template on their talk page? Espresso Addict 02:55, 18 August 2007 (UTC)

Research would be good: this is not covered by WP:WPVS yet. Newbie editors will still be able to see the effect of their edits on the current version...most good-faith newbies will be aware of the vandalism problem and not mind waiting a bit for their contribution to appear in a sighted version. Experience suggests that plenty of newly-autoconfirmed users don't understand the system well enough to get sighting powers immediately, even excluding vandals, so we want a hurdle substantially higher than 2 days/no edits: 30 days seems reasonable, but most people will need much longer to reach 300 edits. I like 30 days with an edit, if implementable. PaddyLeahy 10:28, 18 August 2007 (UTC)

I'd like to see some research on the skill level of new editors. In my experience, many hit the ground running. (For example, I recently welcomed an editor whose first logged-in edit was to correct a minor inaccuracy of mine in interpreting a reference which I'd scanned too hastily.) It may well vary with subject area; many of the highly competent newbie editors I've encountered here have been in rather technical subjects, which are likely to attract computer-literate academics used to the notion of referencing.

Perhaps another way of going about it would be to allow any sight-privileged editor (not just admins) to give the sight privilege to any other editor? Sort of the converse of placing a vandalism template on the editor's talk page. That's perhaps unrealistic, but a noticeboard where sight-privileged editors could recommend newbie editors who have plainly already got the hang of contributing but don't yet meet the auto-guidelines might be a realistic possibility. Espresso Addict 02:03, 19 August 2007 (UTC)

Hmm...I suppose that's a good idea to try. We'd be no worse off than now. If any "sighter" could give it to others, we would never have backlogs on the page to request the rights. The deterrent of having it removed should stop most abuse. Though only admins should be able to remove it though. Voice-of-All 04:08, 19 August 2007 (UTC)

The more I think about this the more I like the idea of any sight-privileged user being able to pass on the privilege. It seems to foster a sense of community rather than adding to all the layers of bureaucracy which can feel off-putting to newbies. Espresso Addict 05:56, 19 August 2007 (UTC)

Vandal plays nice for a while. Gets 'sighted' setting. Gives it to 100 sockpuppets. Mixes in a bunch of innocent newbies too. Makes a mess. If there is a log of everyone they have given 'sighted' access to those accounts will eventually have it removed and/or be blocked... which would hit the innocent ones too. But in the meantime a few of those hundred accounts could have given sighted access to 100 MORE vandal accounts... meaning that admins would have to check the logs on all of them. In short, we might as well not even bother having 'sighted' restrictions... under such a methodology they'd slow the legitimate users down, but not the vandals.

I think thats rather pessimistic. Very few will go through the pain of getting so many sockpuppets. Even if everyone did that, we would at worst have the same amount of vandalsim we have now... Brusegadi 21:34, 23 August 2007 (UTC)

My take on 'sighted' access is that in order to get it a user should have to do more to improve the encyclopedia than they are likely to undo in the time before the access was removed if they started abusing it. Any system which allows large numbers of accounts to get the access without doing much or anything positive for the encyclopedia is counterproductive... that includes letting anyone who has it give it out, requiring a specific number of edits, requiring a waiting period, or even requiring a waiting period AND a specific number of edits AND approval from a user that has it. All of those are easily circumvented.

On the other hand, it shouldn't be restricted to just admins or require months of dedicated work to get the access. That creates a bottleneck which would discourage editing. Any user who steadily makes improvements to the encyclopedia should get it automatically. Hence my 'edits to article space on 30 different days' suggestion. Yes, a vandal could make one minor edit a month to get the access... but they'd have to do that on each account they wanted to have it... and if those minor edits weren't actually improving things it'd get noticed and 'sighted' access with-held. By the time they reached the point they could actually vandalize the public version they might not want to anymore... and if they did they'd be quickly blocked and have to go through the whole process for another month to be able to vandalize for a few minutes again. --CBD 21:15, 19 August 2007 (UTC)

Thought of several more things;

1. When a user viewing the 'public' version hits the 'edit' link my understanding is that they get the 'current' version... which may no longer have the text (or even section) that they were planning to change. Thus, I'd think the first thing we should show, before the edit window, are all the changes from the 'public' version to the most recent. This both lets the person know why they aren't seeing what they expected AND shows a user everything which they are going to be 'approving' if they flag their own changes as ok.
2. When a user saves a case after editing it they should get the 'current' version even if they are normally always shown the 'public' one (either because they've chosen that or are not logged in). This is so that they will see the change they just made. I believe this is the current intent/way it works, but if not then it should be. Allows the user to get that immediate satisfaction, prevents confusion over 'why did it not save', et cetera.
3. If the above suggestion on '30 different editing days' is adopted then, rather than giving admins the ability to set and unset permissions, I'd suggest allowing them to increase or decrease the 'number of editing days' required for the access to be set. This could serve to replace blocks for edit warring, POV pushing, et cetera with temporary loss of the ability to approve revisions. Doesn't stop users from contributing, but encourages them to do so more positively. Also avoids backlogs of requests to set the permission... users would just have to 'work off' the delay much as they would currently 'wait out' a block. Think this would do alot to improve the way we handle disruption and conflict.
4. How will redirects be handled? My understanding is that, as it stands, an IP/new user could redirect the 'George W. Bush' page to a new 'George W. Bush is a big loser' article that they had just created. While the new article would not be 'Sighted' it would still be displayed to all users because it would be the only version available. The edit creating the redirect itself would not be 'Sighted' either, but if that gets resolved before the 'what version do we display' it wouldn't matter... and if we DON'T resolve redirects first then people could be getting old versions of articles that have been moved or merged and are now significantly different.
5. Tie the ability to edit semi-protected pages, create new articles, and move pages to the ability to set pages 'sighted'. Users doing any of these things should have displayed a general understanding of Wikipedia's practices.

--CBD 22:23, 19 August 2007 (UTC)

Redirects will not apply be default unless it is reviewed, just like any other edit. So you would still get a stable GWB version. Voice-of-All 08:21, 20 August 2007 (UTC)

Probably the best way to handle it, but there will need to be some sort of 'unreviewed redirects' patrol to make sure that we don't have legitimate redirects which aren't working. Also may be some confusion in that the unreviewed redirects WILL work for logged in users... so different users clicking a single link will wind up not just at different versions of a page, but entirely different pages. --CBD 09:01, 20 August 2007 (UTC)

CBD makes some great points -- as we go further down the list I agree with more and more of them. The possibility that a puppet master would give the right to a ton of sockpuppets is rather disturbing, even though in general I like the version where surveyors can give the sighting permission to other surveyors. We may need a tool to identify and fix this problem--will there be a way for editors (or at least admins) to see to whom an editor has given this privilege? Tieing the ability to edit semi-protected pages, create new articles, etc., to surveyors seems reasonable since as CBD points out it requires the same general understanding of WP and Mediawiki as we'd expect from surveyors. Point #2 is also important to reduce confusion.

BTW -- it sounds like we've definitely committed to a two-stage rollout with the anti-vandal stage (sighting) being the major point under discussion now and Reviewing/Quality being placed on the back burner? I think the project page should be updated to reflect that. Best, -- Myke Cuthbert (talk) 18:06, 20 August 2007 (UTC)

Some notes on the deployment of this feature

Hello,

I'm the point of contact from the WMF Board on flagged revisions for the time being. I will discuss our deployment strategy next week with Sue Gardner, who is currently heading WMF operations. To clarify, nothing is set into stone yet, and we want the community to be part of the process every step of the way.

It is likely that the next thing that will happen is a very public beta test of the extension on a dedicated test wiki, with a call to developers to systematically improve the usability and scalability of the extension. After that, my recommendation will be that each wiki community is given the choice to deploy this extension or not, with a clearly defined process for making a decision to do so.

Regarding the deployment parameters, my personal opinion is that it would be foolish to immediately set the extension to always show the last "sighted" revision to unregistered users. When we do not yet know whether the sighting of revisions will scale, immediately changing the default of all pages could massively impact usability of day-to-day users and new contributors. I also suspect that there are significant usability problems with showing different revisions to registered and unregistered users.

Unfortunately, the extension does not support setting the default view on a per-page level yet. With that functionality, it would be possible to organically expand the number of pages whose default view is the last "sighted" revision. Without that functionality in place, I would be reluctant to change the default view at all.

But this is just my recommendation, and if the en.wp community feels that we should roll out the extension with the default view changed for all users, this is what will happen. It may make sense to have a poll on various aspects of the configuration at the end of the public beta.--Eloquence * 19:17, 17 August 2007 (UTC)

That's great. Do you know a rough date for the launch of the beta test? Mel sa ran 19:20, 17 August 2007 (UTC)

No, though I expect that it will be very soon, given that there are already a couple of public sites running the extension.--Eloquence * 19:31, 17 August 2007 (UTC)

Very useful to have input from Eloquence. Queries: (i) For clarity, will the beta test be started before a "per-page" option is available? (ii) What benefits do you see in introducing sighted versions without them being the default for unregistered users? (iii) is de:wiki still enthusiastic for this? (Since the plan for a de: beta test is now a year old). PaddyLeahy 20:07, 17 August 2007 (UTC)

(i) Yes, unless someone codes it really fast. ;-) But the initial public beta won't be on a production site, i.e., it will likely be populated with some demo content only. (ii) The biggest practical benefit would be for people using our content outside Wikipedia.org: offline readers, mirrors, people printing copies or making WikiReaders, and so forth. These users would find it easier to get vandalism-free content. But even the average reader may find it helpful to be able to immediately click through a sighted revision. And for our community, we can collect some data on how quickly we typically review changes, and then decide how widely (if at all) we want to change the default view. But I would definitely prefer it if we immediately had the option to do so on a per-page basis. (iii) I think they will be happy for something to happen at this point, and don't care too much about the specifics. Hence dewiki could be a good test case for setting an entire wiki into a different default view.--Eloquence * 20:45, 17 August 2007 (UTC)

IP users (including those who read without editing) already get a cached version of pages I believe, so they are already not getting the most recent version of many pages unless they purge the cache on every page. I can't recall any complaints about that. My point is, will it really be that much of an inconvenience to get the sighted version if they don't plan to edit? If I were just using Wikipedia just to read, I would want the most correct information. If they get the sighted version, that is much more likely to be free of inaccuracies and subtle vandalism (date changes, name changes, etc.) than the most recent version. Mr.Z-mantalk¢ 00:15, 18 August 2007 (UTC)

No, it is up to date. Although I can't find code to clear caches of pages that use images on commons when edited (aside from commons pages) and external wiki templates, every other change should use HTMLCacheUpdate() using the internal link tables(category,template,image,page) to purge all pages that use the page/image you edited. Voice-of-All 00:55, 18 August 2007 (UTC)

Eloquence's personal opinion about not enabling the main function of this mechanism seems misguided to me. If readers still see the current (often vandalized) version of an article, then the mechanism has essentially nil effect. There may be a few additional boilerplate boxes displayed here and there, but essentially nothing different happens from now. Surveyors can toggle 'sighted' states as much as they want, but nothing happens except that an editor looking closely will see that the state has been changed.

I think it is much better to have 'sighted' have a real effect (reducing display of vandalism). I think surveyors will be much more motivated to use it consistently when they are actually affecting the quality of the presented Wikipedia. Vandals will be less inclined to vandalize only when stop they having the effect they desire. We need have the 'sighted' flag affect article display. -R. S. Shaw 19:48, 20 August 2007 (UTC)

I wonder why it is necessary to have software support for enabling this feature per page? Can't we just set the policy to be such that during the roll-out:

1. The initial sighting of a page should only be done by an administrator, and as a consequence
2. Non-admins should only sight pages that have been sighted at least once before.

The only software change would be to remove the warning message on non-sighted pages, then any such page would behave as if this feature is not enabled. Naturally, any editor could break the rule, but then I can right now prematurely close an AfD without the software preventing me... So I wonder, is software support really needed for per-page sighting (other than removing the "unsighted" warning)? --Merzul 10:54, 20 August 2007 (UTC)

Problem of discouraging new good-faith contributors

If this system is to be adopted, considerable thought needs to be given to making sure that good-faith contributors who haven't registered or are newbies don't feel that their contributions are disappearing into a black hole. The problem of recruitment & retention of knowledgeable editors is, I believe, as acute as that of controlling vandalism, and the proposed change would seem to run the risk of controlling one at the cost of severely exacerbating the other.

This would probably need to include an explicit message on saving that the edits have been accepted but won't be publicly visible until they've been sighted by an experienced editor, efforts on the part of all the WikiProjects &c to sight revisions to the articles under their umbrella extremely rapidly -- preferably within hours, and a noticeboard for non-sight-privileged editors to bring edits that have languished for more than, say, 48 hours. Espresso Addict 23:26, 17 August 2007 (UTC)

I think most good-faith editors will not mind that. On the other hand, most vandals will. I think its good. Most people who hunt for vandals now can just hunt for pages in need of approval. Yet, the second task will be less daunting than the first. We win. Brusegadi 21:36, 23 August 2007 (UTC)

Sighted revisions

The way that I read this proposal, edits made to an article would not appear to most users until they have been Sighted. Is that correct? If so, it seems to be me that we don't have the manpower to constantly be sighting revisions, and the backlog of unsighted revisions would make it so that the newest version of many articles would be unviewable for a fairly long amount of time. I would be more inclined to support this proposal if revisions appeared immediately without being sighted, at which time the default version shown to unregistered users would be the most current version. Then, a user could sight a revision, and that would become the new default.--Danaman5 16:39, 18 August 2007 (UTC)

How come we don't have enough manpower to do this when we do have enough manpower to check & revert most vandalism within minutes? The workload will be much less. If this proposal is implemented, vandalism doesn't need to be reverted until someone finds something constructive to add. And now Wikipedia is well developed, few if any constructive additions make such a difference that they need to be sighted within minutes or even within a day (breaking news stories apart). Also, anon-IPs can always choose to look at the latest vandalism if they click on the "LATEST UNCHECKED VERSION" tab, or if they edit. PaddyLeahy 17:22, 18 August 2007 (UTC)

The idea that Wikipedia is well developed is simply false; just in my areas of interest, there are huge numbers of topics relating to biology, medicine, history of science/medicine, academic journals, literature & UK geography that are either not covered or covered by clearly inadequate stubs, and discussions I have encountered suggest that many other areas are also sparsely covered. If constructive edits are ignored for days the quality of the encyclopedia will suffer for readers, and -- in my view more importantly -- contributors will be put off and might walk away from the project. The problem of recruiting and retaining contributors with expertise across a wide range of subject areas is a perennial area of discussion; I feel it is at least as important a problem for the project as that of vandalism. Espresso Addict 00:40, 19 August 2007 (UTC)

On the other hand, one of the main reasons why they are leaving is the constant fight against vandals, POV pushers, and good-meaning but ill-informed editors. It is extremely frustrating for an expert to spend many hours on writing a good article, put it on Wikipedia, have another look a month later and see that it is degraded. Thus, I think that a more robust approach to fighting vandalism and POV pushing like the proposal will actually help in retaining contributors with expertise. -- Jitse Niesen (talk) 02:00, 19 August 2007 (UTC)

That's certainly a significant factor in the loss of expert editors; however, I'm aware of at least one who left because of bad experiences with the drive-by tagging brigade labelling his/her contributions as substandard, and that rationale for leaving would only be exacerbated if their contributions didn't even show up. Espresso Addict 02:14, 19 August 2007 (UTC)

(unindent) Jitse, your argument about good articles becoming degraded over time applies well to the "quality versions" section of this proposal. It is indeed tough when someone improves an article to good or featured status and then sees it degraded. That's why I support the quality versions portion of the plan. However, I believe that the sighted versions portion goes too far, in that it makes every edit a hassle. If we want to retain experts, we have to find a middle ground, where they know that their valuable contributions will not be degraded, but also that they can build the article up from a stub without too much trouble.--Danaman5 04:33, 19 August 2007 (UTC)

...Although I just realized, most of this proposal only applies to unregistered users anyway. I suppose it will work just fine if registered users have the option to always view the most current revision, regardless of whether it has been checked, it wouldn't really change anything for us.--Danaman5 04:45, 19 August 2007 (UTC)

It is a site setting. By default, when you log in, you affirm being more of an editor. Logged in users see the current revision by default, to keep editing smoother. Voice-of-All 06:22, 19 August 2007 (UTC)

Well, I'm an "expert" in the sense that I have a Ph.D. and write scientific papers. As such, I'm used to the writing process consisting of months of negotiation with co-authors, followed by a wait of up to several months to receive expert review, which has to be answered in detail, followed by several more months before actual publication. I can't imagine that any genuine experts would be put off by the sighting process. As pointed out elsewhere, problems for experts on WP include that we expect to do OR and be able to put across our own POV, it's a pain to dig up references for things we've known for so long we've forgotten where we learned them, and it's irritating having to argue with people who don't have a clue. None of which are particularly noble reasons, and a lot of us do stick with it. Though we often find ourselves editing on anything but our own speciality... PaddyLeahy 09:00, 19 August 2007 (UTC)

I do think that Espresso Addict makes an important point. It's not only that experts will have to wait for their edits to appear, but that they have to wait for some random person whose only quality is to have made the necessary number of editors to get surveyor rights. It's not that easy for people who have studied a subject for years to accept that their contribution is deemed equally valuable as that of the random man in the street.

Still, I think that the net effect of the proposal is positive, but we have to be careful to mitigate the negative effects. It's important that contributions will be sighted (or is it now surveyed?) within a couple of days, at most. It is hard to guess in advance whether that will happen; I'm hopeful, but we should keep an eye on it if the proposal is accepted, and even go back if good contributions linger for too long. Other important points are communication, and that the surveyor rights will be made readily available.

By the way, how will the transition take place? I presume all articles will start unsighted, so we'll have to sight a million of articles. That will take some time. -- Jitse Niesen (talk) 14:28, 19 August 2007 (UTC)

Everything would be sighted at first except for articles with tags which obviously mean they shouldn't (like speedy deletion, prod and deletion tags, maybe also transwiki tags). —The preceding unsigned comment was added by Eyu100 (talk • contribs)20:56:40, August 19, 2007 (UTC).

No, I think all articles start out unsighted. This is probably a Good Thing. It allows obscure articles to continue to be edited exactly the same as before, with immediate publication of all edits. This state continues until a surveyor marks it sighted (or reviewer as quality). For low-traffic, newish, stubbish articles this is probably an appropriate state, and these articles are thus not subject to the 'interminable wait for publication' that some think will be so awful.

Highly edited (and often vandalized) articles will quickly be marked sighted by a regular, and thus will be protected from vandalism. We should let this process spread naturally, and not have a campaign to go mark everything sighted, because this will allow the protect to be applied to those that most need it (and those that have active editors). Note too that this will probably 'scale' well - as surveyor-empowered editors make normal edits, they can do sighted-marking if they want to. -R. S. Shaw 00:40, 20 August 2007 (UTC)

This is a bad idea that would make routine good editing a lot more hassle

Many, perhaps most, valid edits are minor things - grammar, formatting, categorisation, simple factual updates etc - and all of those edits would be more hassle if this was implemented. Therefore I believe that is would hamstring the whole project by reducing the amount of such good edits. There is an underlying false assumption that articles reach a point where they don't need much more editing - many of the most trafficked articles cover rapidly changing subjects that need to be updated a great deal. Baridiah 22:05, 18 August 2007 (UTC)

The review form shows after each edit. If the current revision is tagged, and a "surveryor/sighter" makes an edit, it can even be autoreviewed. And many people should have sighting rights too. Logged in users see the current revision by default, so it's just edit as normal for them. Given that the incentive to vandalize sighted pages would go down, we could move some time wasted on reverting that to reviewing. Also, spelling corrections don't need to be urgently reviewed straight away. Voice-of-All 06:25, 19 August 2007 (UTC)

Auto-sighting surveyor edits

Could someone who knows about how Mediawiki merges stuff comment on this. I have this vague recollection that I once edited a section of a page and someone inserted very rude vandalism by editing a different section. This went unnoticed for quite some time, I assume because other people thought I had checked the previous edit.

Is this possible that he inserted this at the same time as I was editing the page and then the software merged our edits? In any case, this vandalism went unnoticed for a very long time, and when I noticed it, I was searching the edit history to find the idiot who had let such blatant vandalism into the article. I was quite embarrassed when I saw that I had edited immediately after the vandal.... I like to think that this was merged, but perhaps I was just sloppy.

In any case, I'm a bit afraid of the auto-sighting idea, and so I made some bold edits to the proposal. I hope other people will be equally bold in fixing this stuff, if my fears are not well founded.

Cheers, Merzul 12:08, 20 August 2007 (UTC)

I was one of the main proponents of auto-sighting, but I can see that it's not gaining community consensus, so it's fine to remove it from the proposal. It seems unlikely to be implemented at least in en:wp anytime near the rollout, so having it in the project page is likely to be confusing. If, as Eloquence suggested, in the test phase everyone is seeing the most recent version then the main rationale for auto-sighting surveyor edits disappears.

I didn't think of this merge possibility, thanks for bringing it up. Best, -- Myke Cuthbert (talk) 17:52, 20 August 2007 (UTC)

I'd think this is almost pointless without both auto-sighting and making the default for non-logged in users (and the squid cache and Google searches and mirroring) the most recent "sighted" version. If everyone sees the most recent version, not the most recent "sighted" version, what have we accomplished? Seems like the probability that anyone would click the "view most recent sighted version" would be extraordinarily low. Unlike some other changes we've made, I hope we keep some statistics on this one. -- Rick Block (talk) 18:30, 20 August 2007 (UTC)

See comment by Eloquence above. I'm always slightly taken aback to realise how much off-site copies of wikipedia content drive foundation policy...it reminds me of the "crowdsourcing" cartoon on Angela Beesley's blog [2].PaddyLeahy 19:39, 20 August 2007 (UTC)

I'm not a fan of auto-sighting. I think that the sighting should be a intential act by a surveyor. --Rocksanddirt 19:44, 23 August 2007 (UTC)

Extend this policy to include the revisions of policy pages that were accepted as official policy

See my proposal on Wikipedia:Village pump (proposals). It was a proposal similar to this, but it also proposed that links be available on official policy pages to the revisions that became policy, so that if the content of the policy is changed without consent or universal knowledge, this can be discovered and not mistaken to be the originally agreed-upon policy.--64.149.189.119 19:05, 22 August 2007 (UTC)

This isn't a bad idea. I've often seen established editors unilaterally add a sentence or two to a policy in light of an ongoing dispute. This would force community discussion before that is done.--Danaman5 19:35, 22 August 2007 (UTC)

It sounds like a quite good idea. I would think that Policy might need the quality level of flagging while guidelines only the sighted level? The counter-argument is that people who read the policy pages know that WP is a Wiki, that things change, etc. However, I have seen sentences jump into policy without any sort of consensus and "minor edits" of guidelines remove important caveats. -- Myke Cuthbert (talk) 05:08, 23 August 2007 (UTC)

I really like this idea. -- Ned Scott 05:16, 23 August 2007 (UTC)

Definitely, Wikipedia has always had a problem with people sneaking out to the barn wall with a can of paint in the middle of the night. Nobody notices and suddenly there's this gawdawful 'policy' (that never really was policy because the community never accepted it) being enforced with blocks and its own templates and a noticeboard... until it all gets tracked back to the source and stomped out with much wailing and gnashing of teeth about how people are 'changing the policy'. I'd definitely prefer this be at the 'quality' level so that only things which truly have consensus show up on the policy pages. --CBD 12:21, 23 August 2007 (UTC)

Straw poll

Please say whether you support or oppose this proposal. Eyu100^{(t|fr|Version 1.0 Editorial Team)} 15:50, 23 August 2007 (UTC)

Discussion about the poll

No, please do not. Polls are not the way to solve premature discussion of features people haven't yet used. Instead, why don't we talk enthusiastically as to what we'll do with the system when the Foundation switches it on?

James F. (talk) 17:21, 23 August 2007 (UTC)

The Wikimedia Foundation says it'll listen to the community either way. You're welcome to try out the software; see the top of this page. CloudNine 17:27, 23 August 2007 (UTC)

Actually, I helped advise the writers of the software. :-)

James F. (talk) 17:30, 23 August 2007 (UTC)

I do apologise :) CloudNine 17:31, 23 August 2007 (UTC)

Still, this poll is vastly premature. Discussion ought to be the order of the day, for a while yet.--ragesoss 18:09, 23 August 2007 (UTC)

I think a preliminary straw poll is fair game at this time as thus far the overwhelming majority of visitors to this talk page are in staunch opposition. No one really seems to be saying "yes you could do this... but how about me make a couple of changes", the majority infact seem to be advocating simply forgetting this idea asap as it is unworkable on every precievable level on which it could reasonably operate. WikipedianProlific ^(Talk) 18:05, 23 August 2007 (UTC)

I also think this poll is inappropriate, at least at this time. Wikipedia is not a democracy. Polls are evil. Polling is not a substitute for discussion. We're supposed to reach decisions by discussion towards consensus. Polls just turn into a bunch of WP:ILIKEIT vs WP:IDONTLIKEIT lists. And people who want to add meaningful discussion could already do so. —DragonHawk (talk|hist) 22:24, 23 August 2007 (UTC)

Support

1. Eyu100^{(t|fr|Version 1.0 Editorial Team)} 15:50, 23 August 2007 (UTC)
2. --B. Wolterding 15:56, 23 August 2007 (UTC)
3. CloudNine 16:01, 23 August 2007 (UTC)
4. It would significantly improve the reliability of Wikipedia. MessedRocker (talk) 17:16, 23 August 2007 (UTC)
5. WATP ^(talk) • _(contribs) 17:18, 23 August 2007 (UTC)
6. -- Myke Cuthbert (talk) 17:20, 23 August 2007 (UTC).
7. Zginder 17:23, 23 August 2007 (UTC)
8. --Danaman5 17:30, 23 August 2007 (UTC)
9. Tuvok [^{T @ lk}/_{Improve me}] 17:32, 23 August 2007 (UTC) — I also agree with Badagnani, but I think we can solve that problem by further publicizing this proposal and discussion. (two edit conflicts)
10. This will improve Wikipedia for the readers which is most important. Davewild 17:36, 23 August 2007 (UTC)
11. This solves one of the biggest problems ive seen in wikipedia so far Debeo Morium 18:04, 23 August 2007 (UTC)
12. Though I really don't like polls like this. Voice-of-All 18:10, 23 August 2007 (UTC)
13. Without stable versions, Wikipedia is finished. We simply will not be taken seriously in academia if we cannot present stable versions of articles that are not only unvandalized but also quality-assured: in addition, we must have a mechanism to prevent once-great articles deteriorating through accumulated rubbish. Oh, and proposals are not decided by voting on them. Moreschi ^Talk 18:12, 23 August 2007 (UTC)

    As an academic, I know how to cite & recommend a specific version if needed, and I'd rather see Wikipedia succeed on the strength of its constantly-improving content, with novice users fully involved in the rapid & messy evolution (which is how our existing articles got as good as they are). Wareh 18:21, 23 August 2007 (UTC)

    Yes, but once articles get to a certain level, as a general rule they don't improve. Further editing is either trivial or plain unconstructive. Plenty of articles here do reach a "peak of perfection", from which they only get worse. Moreschi ^Talk 18:34, 23 August 2007 (UTC)

    I've seen frustrating losses, but never a "peak of perfection" in the articles in my field (Classical antiquity). Most of the best articles, incl. FA's, could be vastly improved and do get improved. Wareh 18:49, 23 August 2007 (UTC)

    I think the number of articles that get de-featured is good enough evidence for what I'm talking about. Yes, FAs do improve and often can be improved, but a large number (particularly on popular articles) slide rapidly downhill. Moreschi ^Talk 18:51, 23 August 2007 (UTC)

14. Brusegadi 21:41, 23 August 2007 (UTC)
15. Of course. --ST47Talk·Desk 18:15, 23 August 2007 (UTC)
16. Alas, premature polls. Stable versions represent much more than just a PR boon. One of the big, and legitimate, anxieties of many readers is that they don't know who "used the facilities last", so to speak. Having an assurance that recent changes were checked at least by someone is a step up. I expect that the net result will not be to turn off new contributors, but to attract more new contributors. Many would-be editors are turned off by the prospect that anyone can come by and destroy their work maliciously; this will provide a modicum of positive reinforcement for new editors, when their edits are validated in sighted versions. It will also increase the level of interaction that new editors experience; too often new editors go for quite a long time and never even know whether anyone has read what they added. We shouldn't get too worried about the "quality" flags. It just builds into the system something we've been doing for a while in a more ad hoc fashion: we already point out specific revisions as certified Featured Articles and Good Articles, and this makes those designations more transparent to readers.--ragesoss 18:34, 23 August 2007 (UTC)

    I forgot to mention one of the major, major benefits of this. Because sighted versions are limited to articles that are free of clean-up tags and major problems, this will provide a workable system of selecting articles for offline versions of Wikipedia, and updating articles for new releases without having a Wikipedia 1.0 reviewer recheck each article manually.--ragesoss 18:40, 23 August 2007 (UTC)

    And in response to the argument that this is more bureaucratic trouble than it's worth... I find that argument ridiculous. The beauty of it is that it can be implemented gradually, since articles with no flagged versions will behave just as they do now. Articles that see significant editing will naturally see more attention from multiple users, including those with sighting rights, so that long backlogs of unreviewed good edits will not be common.--ragesoss 19:09, 23 August 2007 (UTC)

17. GDonato (talk) 18:54, 23 August 2007 (UTC)
18. Strong support for surveyor flag and sighted revisions only, which I believe would be an excellent addition. Weak support for very limited use of the reviewer flag and quality revisions; I still don't wholly like the idea. Pyrospirit (talk · contribs) 18:59, 23 August 2007 (UTC)
19. AnonEMouse ^(squeak) 19:11, 23 August 2007 (UTC)
20. I have to agree with Pyrospirit here - I very much like the sighted version idea, but I just don't see how the quality idea could work without becoming unmanagable. As a rather infrequent editor of Wikipedia, I still feel like somewhat of a newbie, and doubt I'd feel able to survey articles even if I was granted the right to do so. Wrldwzrd89^talk 19:17, 23 August 2007 (UTC)
21. Support Let's try it out. Seems like a great idea. I'd help out.-BillDeanCarter 19:23, 23 August 2007 (UTC)
22. Support As long as reviewer status is handed out quickly and easily, I don't see why not. It will most likely aid in keeping our better-quality articles in good shape, and reduce vandalism, while not being a huge barrier. Sxeptomaniac 19:32, 23 August 2007 (UTC)
23. Support - the public believes something like this happens now. I suggest that controverial topics use an outside surveyor. --Rocksanddirt 19:39, 23 August 2007 (UTC)
24. Support: Will improve Wikipedia for everyone from casual readers to experienced editors. And if instead it doesn't, it will quickly get switched off again. PaddyLeahy 19:46, 23 August 2007 (UTC)
25. Strong Support - Adding more reliability improves Wikipedia, as long as there are enough Surveyors to go through the edits, so that back logs don't become too long. --Jhattara ^{(Talk · Contrib)} 20:01, 23 August 2007 (UTC)
26. Support Sure, why not, my watchlist notice seems to think it's a good idea. ˉˉ^anetode╦╩ 20:59, 23 August 2007 (UTC)
27. Weak Support But only as an alternative to semi-protection. There are so many problems with this proposal (how to tell editors from readers, loss of instant gratification aspect, unmanageable backlog, etc.) that I don't think it will really be effective at improving overall article quality. It could make a good stopgap against vandalism, though, and isn't as heavy-handed as protecting a page. --Jaysweet 21:35, 23 August 2007 (UTC)
28. We could definitely make this work. Mr.Z-mantalk¢ 21:45, 23 August 2007 (UTC)

Oppose

1. Badagnani 16:00, 23 August 2007 (UTC)
2. Alientraveller 17:07, 23 August 2007 (UTC)
3. Will provide yet another source of contention for articles in controversial topics. Raymond Arritt 17:10, 23 August 2007 (UTC)
4. From my limited understanding of the current proposal, this has staggering potential to quickly and disastrously become unmanageable. Fvasconcellos (t·c) 17:15, 23 August 2007 (UTC)

   Limited understanding indeed ;). In any case, would you mind explaining how? MessedRocker (talk) 17:17, 23 August 2007 (UTC)

   Can anyone say "Backlog"? "The right may also be given automatically by the software to editors who meet the following conditions." So, autoconfirmed on a new level. May or will? If not, how will "Surveyor" rights be granted? Will there be an organized process? A "drive"? Will editors simply be allowed to ask for such rights, and admins will chase down a Category:Requests for Surveyor rights? How will we handle revocation of rights? Will there be a "Surveyor abuse" noticeboard?

   Regarding reviews. Will there have to be an RfA-like process for Reviewer rights? Will project members automatically be assigned such rights? Admins only? FAC regulars?

   How will erroneously flagged revisions be handled? What will happen when disputes arise? Will we have "Flag wars"? I agree this would probably cut down on vandalism and project a more positive image of Wikipedia, but the "back office" work—which, let's face it, constitutes the bread-and-butter of WP editing—would increase tremendously. Fvasconcellos (t·c) 17:28, 23 August 2007 (UTC)

   Those questions (especially the reviewer rights) appear to be have been answered on the policy page. CloudNine 17:33, 23 August 2007 (UTC)

   None of these things have to be big problems. With an automatic rights level of 300 edits, I expect the volume of rights requests would be manageable. Abuse can be handled through existing bad-behavior channels. The same rules would apply to flag warring as edit warring: discuss things and come to an agreement rather than revert repeatedly. As far as added processes, this is a pretty light-weight proposal. The Quality parameters probably need to be refined more, but as long as it begins as strictly limited to articles that have been certified as Featured or Good, that aspect can be rolled out gradually, without a rights-granting process right away.--ragesoss 17:45, 23 August 2007 (UTC)

5. .V. 17:19, 23 August 2007 (UTC) This seems like a very bad idea. I can only imagine the fights that would crop up over this one.
6. Me5000 17:28, 23 August 2007 (UTC)
7. Too liable to cause arguments, I think. I also think that it goes against the "anyone can edit" dictum that we pride ourselves on. Vandalism isn't that rampant, anyway, and given the level of anonymous edits that are actually valid, I think the log would quickly become umanageable. On the subject of sighted pages, some requirements, such as "unencyclopedic content" are subjective (for example, trivia is, but that didn't stop at least one article from becoming featured), while the spell-checking and stub requirements discriminate against non-specialists and non-native speakers - as anyone can edit, anyone similarly can improve. Will ^(talk); 17:35, 23 August 2007 (UTC)
8. Oppose this implementation. I consider "stable versions" to be both desirable and an inevitability, but the selection of those versions should be a pure wiki process, not requiring a new class of users and user rights. FA should be a model for how to promote good versions without closing the process to anyone. In the form proposed here, you're trying to solve a social problem via technical constraints.--Father Goose 17:53, 23 August 2007 (UTC)
9. A dangerous kind of tinkering with the very DNA of the successful Wikipedia. Stable versions are better but still counterproductive if the encyclopedia's mass audience is not looking at the latest (usually greatest IMO) edit. Wareh 17:55, 23 August 2007 (UTC)
10. Decided to change my vote - sorry. Increases risks of more unsettling disagreements(In my opinion anyway) Scarian ^Talk 17:57, 23 August 2007 (UTC).
11. WP:CREEP. Whispering 17:57, 23 August 2007 (UTC)
12. Unwiki. This will help nothing. --- RockMFR 17:59, 23 August 2007 (UTC)
13. Massive oppose, its not only unhelpful its frankly destructive. I'd sooner have advertising on pages than this. WikipedianProlific ^(Talk) 18:03, 23 August 2007 (UTC)
14. Strongly Oppose If I wanted to edit Citizendium, I would be doing so. This also has a vastly exaggerated idea of the average quality of FAs. Septentrionalis PMAnderson 18:24, 23 August 2007 (UTC)

    Strongly, because the reviewer status is another way for wiki-bullies to get their way; an utter disaster. Septentrionalis PMAnderson 20:12, 23 August 2007 (UTC)

15. Strong oppose of "quality" flagging (as presently proposed) - Weak support of "sighted" flagging. See my (long) comment below. SteveBaker 18:29, 23 August 2007 (UTC)
16. I want people to trust Wikipedia. I don't think this is the way to do it. The current system isn't broken, what we need is more honest-to-goodness citations, not an increased redunant workload. --Ybbor^Talk 18:34, 23 August 2007 (UTC)
17. Wikipedia isn't a beaurocracy. It's too confusing, and too difficult to understand as a guideline or policy. If it's to be implemented, it needs to be made simpler. GreenJoe 18:41, 23 August 2007 (UTC)
18. Strong Oppose - per Will.--Bryson 18:43, 23 August 2007 (UTC)
19. Oppose (edit conflict) Will overload review system. Also an outright violation of WP:AGF OhanaUnited ^{Talk page} 18:45, 23 August 2007 (UTC)
20. Strong Oppose. This is going to end up backfiring on us in hotbed articles, because different cultures have different definitions of what they consider "quality" on certain articles (for example, Israelis and Palestinians on matters regarding Israel/Palestine. There is no way we can implement this encyclopedia-wide because of the presence of such battlefields. -Jéské ^{(v^_^v Kacheek!)} 18:48, 23 August 2007 (UTC)
21. Oppose If this system were to be implemented, I think that it would discourage the many IP editors making constructive contributions from editing because they wouldn't immediately see the results of their work posted online - if they don't enter the edit mode a second time, they would have to wait until some registered user approves of their edit. As I see that the majority of the contributions on my watchlist from IP editors are constructive (albeit the constructive edits tend to be on the more obscure articles), this would not be a good thing. Lisatwo 19:02, 23 August 2007 (UTC)
22. Oppose I think the "Quality" idea will not work they way its supposed to. "Sight" makes more sense, but I think it will still discourage the great wikignoming of some IPs. The whole things seems to change the tone of Wikipedia. I am not yet convinced, so I say keep things the way they are. With over 1.9m articles this could be a real fiasco for many articles "stuck" in one or no "sight" limbo. --Bobak 19:14, 23 August 2007 (UTC)
23. Oppose; See my point-by-point criticism -- Ken g6 19:21, 23 August 2007 (UTC)
24. Oppose Sue Wallace ♥♪♫♥♪♫ 19:25, 23 August 2007 (UTC)
25. Oppose This is a bad idea which will discourage new editors while creating more bureaucracy and backlogs. Wikipedia should remain a free encyclopedia that anyone can edit, not "that anyone can edit-provided-their-edits-are-approved-by someone-who-does-not-necessarily-knows-more-about-the-article-than-you-but-has -been-around-longer". --Victor12 19:30, 23 August 2007 (UTC)
26. Oppose This will most likely discourage new users (and probably many established users, as well) from editing, both because improvements will not appear immediately and because of the hierarchical system it introduces. I agree that this seems to change the tone of Wikipedia. ~ Danelo 20:18, 23 August 2007 (UTC)
27. Oppose WP:BURO SashaNein 20:20, 23 August 2007 (UTC)
28. Oppose Not a bad idea in theory but it will only discourage new users. Most users start editing with a few minor edits as an IP before deciding to sign up. Not seeing their changes display straight away might discourage them from persevering. Dave101→talk  20:27, 23 August 2007 (UTC)
29. Oppose this proposal collides with multiple policies, guidelines and core traditions of Wikipedia. And I think it's unpractical. Premature poll anyway, this needed a lot more discussion. Húsönd 20:28, 23 August 2007 (UTC)
30. Oppose, the time saved fighting vandals will be more than eaten up by the fresh layers of bureaucracy. As for the criteria, unencylopedic is too flimsy to be applied fairly in all circumstances, it's a bias magnet. The new ability of admins to de-reviewerise people will give bad ones new opportunities to make mischief. The Quality control suggestion is even worse; it will greatly enhance the ability to WP:OWN articles.--Nydas^(Talk) 20:45, 23 August 2007 (UTC)
31. Oppose - hmmmmmm. How shall I phrase this? I know: 'Please, not more process .... aaaaaarghhhhh!'. This idea, no matter how good its intentions or how positively it starts out, will, ultimately, descend into a best a lack of trust for users and IPs (necessary I think for principles such as assume good faith) and at worst a hugely bureaucratic and hierarchical system. I can just about see the point if the user rights are automatically assigned after a short period, preventing the holders from getting a feeling of 'power', but feel that the system is maybe a little too Citizendium-like (Citizendiummy? Citizendish? Meh.). I have very deep misgivings about losing the 'anyone can edit and their edits will show up immediately in the mainspace' principle. However, I am impressed to see such an innovative idea being presented to the community - that ideas such as this elicit such strong discussion in the community perhaps suggests that some changes are needed. Unfortunately, this is not the change for me. ck lostsword•T•C 21:29, 23 August 2007 (UTC)

Counter-proposal 1

"Yes" to a review process and stable versions, but "no" to the suggested implementation here, a "Reviewer" (or "Surveyor") user class with special power over content.

1. Father Goose 19:42, 23 August 2007 (UTC)

Comment

• However, this poll attracts mainly only those interested/fascinated by this idea. It has not been publicized well to the vast majority of editors, for obvious reasons. In fact, a notice was placed on everyone's watchlist and one of the editors active here removed it within 1 hour. This editor later stated that it was best that most editors did not know about this proposal, and just let the people who had already decided *it WILL go through whether you object or not* work on it. So, that's a serious drawback to this poll, and will obviously skew the results, unless a serious effort is made to let the community know that this Citizendium-like proposal is being discussed here. Badagnani 16:00, 23 August 2007 (UTC)
  • I'll put a notice up. I think it's in everyone's interests to publicise this proposal. (Although the first time this notice was placed it was essentially a new proposal; I don't think the editor in question was trying to hide the discussion maliciously) CloudNine 16:05, 23 August 2007 (UTC)
    • Done. It's important to note it's not being hidden; there's a notice up on the Community portal, so it's not taking place behind closed doors. CloudNine 16:09, 23 August 2007 (UTC)
• Comment - No such message is showing up. Badagnani 16:30, 23 August 2007 (UTC)
  • Puzzling. I reverted to a previous version with the same message. Will investigate. Fixed. CloudNine 17:06, 23 August 2007 (UTC)
• Hi, I don't know if any of you notice this, but Citizendium is not our enemy. And including a process for stable revisions makes us no more like Citizendium than being an encyclopedia makes us like Britannica. MessedRocker (talk) 17:28, 23 August 2007 (UTC)
  • You are talking to a brick wall. Voice-of-All 18:18, 23 August 2007 (UTC)
  • Yes, Citizendium is our enemy; several of our bad editors, who happen to have academic credentials, have gone there, and duly abuse their special positions to impose POV. Septentrionalis PMAnderson 18:39, 23 August 2007 (UTC)
    • How does that make Citizendium our enemy? If problem editors are being lured away by Citizendium, I'd say that makes Citizendium our friend! Anyhow, a modest number of productive editors have joined Citizendium as well (not all with academic credentials), and most of the content Citizendium produces doesn't suffer any more from bias problems as Wikipedia content does. Citizendium certainly has some weaknesses relative to Wikipedia, but that doesn't mean that everything they do differently is wrong or worse than the way we do it.--ragesoss 20:15, 23 August 2007 (UTC)
• As VoA says above, we don't even have the policy worked out yet. This is going to result in dismissing the entire idea because some of the details are faulty. -Amarkov moo! 21:36, 23 August 2007 (UTC)

Disallowing editing from users not logged on

Heres my two cents worth. When my 5 year old jumps on and simply deletes things on wikipedia, creating work for others to revert, I think just by placing this simple criteria saves a lot of inadvertent mistakes, time, and introduces some form of accountability and traceability. all the best. --T3Smile 17:23, 23 August 2007 (UTC)

T3, see WP:PEREN. That idea is going to be kicked out at the door. -Jéské ^{(v^_^v Kacheek!)} 17:34, 23 August 2007 (UTC)

Not a good idea...

There should never be a system where one particular version is "the right version" (i.e. a "quality" version.) We need to acknowledge that consensus can -- and will -- change, and sometimes, it will change drastically. The idea of having a "stable version" to work off of shifts the preference toward past consensus instead of future consensus. Not only is this just a bad idea because of the inevitably contentious nature of the system, it will also go against the Wikipedia philosophy. .V. _[Talk|Email] 17:35, 23 August 2007 (UTC)

And when a better version of an article comes, we make that the new stable version. MessedRocker (talk) 18:03, 23 August 2007 (UTC)

Unfortunately, it's never that simple. What constitutes a "better version" of an article is argued by Wikipedians day and night. .V. _[Talk|Email] 19:51, 23 August 2007 (UTC)

If we want a system where no particular version is the right version, why do we privilege the most recent version? Why not have a random edit from the article's history come up each time someone visits the page? The fact is, when vandalism, POV pushing, etc. are figured in, the most recent version of established articles is quite often no better than earlier versions. This extension is a recognition of that situation. -- Myke Cuthbert (talk) 21:00, 23 August 2007 (UTC)