Wikipedia:Flagged revisions/fact sheet

• Special:Stableversions: Lists all revisions of a page that have been marked as stable
• Special:StablePages: List of pages manually configured to show the stable version as the default page to unregistered users (though this can be set as the default)
• Special:Stabilization: Used to change the version of pages that unregistered users see (stable or current)
• Special:Unreviewedpages: List of articles that do not have a stable revision set, or that have revisions that need review
• Special:Reviewedpages: List of articles that have a revision marked as stable
• Special:Log/userrights: The log of all manual rights changes, which would include changes to "editor" and "reviewer" rights
• Special:Log/review: Log of all revision flagging
• Special:Log/stable: Log of all changes to what version of pages is seen by unregistered users

The FlaggedRevs extension offers a wide range of options for configuration.

Userrights

who gets to do what

• +editor will almost certainly be added to the +sysop user group
• This could also be done for other usergroups too, e.g. +autoconfirmed (any account older than four days)
• Allow users to add themselves via Special:UserRights
• Manually assigned by admins and/or bureaucrats (in the same way that +rollback is now)
• Set automatically by some metric (and could then be manually removed); the available metrics are:

• Days since account creation (autoconfirmed is this set as four days)
• Total edit count
• The user must have at least X edits that are Y or more days apart, e.g. must have been around for at least 100 days and made at least 100 edits
• Exclude deleted edits from edit count
• User has a confirmed e-mail address
• User has a userpage
• Minimum size of userpage
• Number of article edits in the past 30 days

• +reviewer can be assigned as a "higher" privilege to allow pages to be flagged in a special way (e.g flagging as Featured), if it was felt that a hierarchy of responsibilities was useful.

Metrics

against what criteria are articles assessed

• There is no real technological limit to the number or types of criteria
• Almost any criteria could be used, but we must make sure that they are the best ones by which to judge the project
• Likely source for criteria would be the various quality drives
• Currently, dewiki has one metric of "not-vandalised", and one, unused, of featured-like content.

Visibility

who sees what by default

• Basic tenet: All revisions of all articles (except deleted/oversighted ones) will always be visible to everyone.
• However, FlaggedRevs gives the possibility that certain usergroups (e.g. anonymous viewers) will default to the most recent revision that matches some criterion.
• An example would be that, if merely flagging articles as "Featured" or "Not featured", anonymous viewers would first see the Featured articles
• A feature exists such that view can be defaulted to particular flags on a per-page basis as a form of page protection; this could for example be used as "flagged-protected".

Proposed configurations

Three metrics proposal

Note: This is a proposal, not necessarily "how it's going to happen".

This is based on the

Please comment on this proposed configuration on the talk page.

Metrics

Three metrics, any of which can be set by any +editor:

• Non-vandalised, a basic on/off flag to say merely that the article doesn't have obvious vandalism in it
• Quality, a 7-segment flag with the same values as the WP1.0 rating scale - A+ ("Featured") | A | A/B ("Good") | B | C | Start | Stub
• Priority, a 4-segment flag with the same values as the WP1.0 rating scale - Top | High | Mid | Low

Rights

Two rights available, with only one being actively used:

• +editor is set/removed by any sysop (like +rollback is now), and included in sysop user rights group
• Edits made by +editors are automatically-flagged as "Non-vandalised"; other flags are not altered by editing, only by reviewing.
• +reviewer is left unused for the time being.

Visibility

• Anonymous viewers see the revision most recently flagged under "Non-vandalised"; a link to the current live version is displayed at the top of the page, with a note.
• Logged-in users have the option to set their viewing behaviour to be the same, but by default will have current behaviour (see latest revision).

Scenarios - viewing

For all users, anonymous or otherwise, articles will gain a message at the top with one of three general messages, tailored to the audience:

• "Checked for vandalism" (An article whose latest revision is flagged as non-vandalised)

  For anonymous users - No message? It's what they should expect of us.

  For regular users - A green tick? It's what we should expect.

  For +editor users - A green tick? It's what we should expect.

• "Updates since checked" (An article whose latest revision is not flagged as non-vandalised, but a previous one is)

  For anonymous users - "This article has been updated since this revision was published - see changes"

  For regular users - "This article has been updated since a revision was last published - see changes"

  For +editor users - "This article has been updated since a revision was last published - see and approve changes"

• "Not yet checked" (An article which has never had a revision flagged as non-vandalised - i.e., new articles)

  For anonymous users - "This article has been drafted but not yet published - see draft"

  For regular users - "This is a draft of an article which has not yet been published"

  For +editor users - "This is a draft of an article which has not yet been published - approve"

Scenarios - editing

When a user (anonymous or otherwise) looking at the last-published clicks edit, they will see a message saying "This article has been updated since this revision was published; here are the changes to the article from the version you were looking at:" and then a diff box between latest and latest-flagged revisions.

Normal editing from live revisions results in no change from current behaviour.

Alternate proposed minimal configuration

Note: This is a proposal, not necessarily "how it's going to happen".

This is based on the idea that FlaggedRevs should have as little an immediate impact as possible on the way the wiki works, while simultaneously using the advantages inherent in such a content-management system.

It is intended to offer the advantage of tagging exactly what we review in the way we already review it: we note "sighted" ("not vandalism") to aid in fixing vandalism and we note "good" or "featured" on the revisions which became good or featured, which might involve periodic review of featured and good articles to flag more recent versions as "featured" or "good" (where such a review would be lighter than a full FAC as it could assume general quality throughout the article with an emphasis merely on checking the changes made since the last review)

It avoids the fundamental problem of limiting what people see; in this way it best corresponds with the foundation issue of open editing.

Please comment on this proposed configuration on the talk page.

Metrics

One metric, to keep it as simple as possible

• Quality, a three-segment flag with the options "Sighted", "Good", and "Featured".

  This is used on individual revisions such that new revisions do not carry forward ratings; "Sighted" is available to +editors and "Good" & "Featured" is available to +reviewers. The separation of the top flags to +reviewers helps to prevent a random editor abusing the feature by tagging their spam, vanity page, attack article, hoax, etc. as a Featured article.

Rights

Two rights available

• +editor is set/removed by any sysop (like +rollback is now), and included in sysop user rights group
• Edits made by +editors are not automatically-flagged as "Non-vandalised"; each revision is evaluated individually. +Editors can add "Sighted" flags.
• +reviewer is given out by some (not yet planned) process to recognize active GA and FA reviewers, and is largely open, but subject to community consensus to add ratings to articles. +Reviewers can add any flag.

Visibility

• All users see the most recent revision by default
• Administrators can set "sighted-protection" to force the most recent "Sighted" or better version to appear instead for anonymous users.
• Logged-in users always see the most recent version regardless of such protection, but can see that the protection is there.

It is to be noted here that a box or other explanation should reveal the flagging-status of the page, with options to view the most recent flagged version or, in the case of "sighted-protection", to see the most recent version of the page. If a version exists with a higher flag than the current version, then there should also be an option to view that version. This box could be loosely modeled on the old-revision boxes we already use.

Flagged revisions have already been implemented in the following Wiki projects, according to de:Hilfe:Gesichtete_und_geprüfte_Versionen#.C3.9Cbersicht:

• Wikipedia
  • Alemannisch
  • Classical Chinese
  • German *
  • Esperanto
  • Interlingua
  • Polish
  • Russian
  • Hungarian
• Wiktionary
  • German
  • Ukrainisch
• Wikibooks
  • English
• Wikinews
  • English
  • French
  • Portuguese
• Wikiquote
  • Russian
• Wikisource
  • Russian

* Headlines here read:

• Namespace
• Total number of pages
• At least one version reviewed
• Number of pages reviewed in current version
• Percentage of pages reviewed in current version
• Pages with unreviewed versions

Sebastian's experience

I've been asked to write about my experience, and I think the best place is here. It would be great if others could add similar sections. I recently spent a couple of days on the German Wikipedia, where flagged revisions have been implemented since May 6, 2008. At the German Wikipedia, anyone with more than 300 edits becomes a reviewer, but exceptions are granted upon request.

As a major difference to English, I noticed that vandalism is much less rampant; Over 90% of IP accounts were teachers, or people correcting some detail about their home town or hobby. To find pages that need flagging, I used several ways:

1. Add hoc through watchlist. The watchlist contains a link to "review" a page, which will bring up the diff to the last flagged revision with a button to acknowledge that diff.
2. de:Spezial:Seiten_mit_ungesichteten_Versionen - Pages with unreviewed revisions: These had usually one to three edits since the last flagged revision. While it was easy to check the one-edit diffs, this was much harder when there were intermediate steps, because the normal diff doesn't display them. (See my two scenarios in bug 16489.)
3. de:Spezial:Ungesichtete_Seiten. List of pages that have never been reviewed. Considerably more effort than the previous if you want to make sure that there is no overlooked vandalism in the history.
4. http://toolserver.org/~magnus/deep_out_of_sight.php: Works by categories, which is very nice when you're interested in a certain area. I found it not quite as comfortable since there was more navigation required, and no information in the list other than the name of the article.

Reception in the community: It seems that while a majority generally likes the concept, few people are willing to do any extra work for it. Some people feel that the organizers were stretched too far and conclude that the feature should have been implemented on a smaller scale first. There is a small, but strong opposition group, primarily among RC patrollers who feel that the problem of vandalism should be solved by increased patrolling. Editors in this group generally object to being automatically granted reviewer rights and had their rights revoked. The reason for this is that each page a reviewer changes is flagged as "automatically reviewed". The objectors perceive this as

Discussion about guideline: When I was there, a big discussion about a guideline for how to check articles was under way. I haven't checked if they reached a conclusion by now. But that may not be so relevant for us; many people just go with their gut feel, just as we do when we check recent changes. The concept works just as well that way. — Sebastian 22:10, 30 December 2008 (UTC)[reply]