Reviewed article version

Concept: Add the possibility to mark reviewed versions of an article (sometimes called stable versions) to improve overall reliability of WM content especially for first-time/read-only users. The last reviewed (or "stable") version of an article will be presented to anonymous users by default. Such a scheme would require some changes to the database, and - to be useful - some changes to the wikimedia software.
See also the discussions around Article validation, which is actually a separate procedure from the software / database additions to mark certain versions as "reviewed" and our longterm goal Wikipedia 1.0. This whole concept can be viewed as a generalized method of managing meta data of articles.

Goals

Primary:

99% Vandal-proofing: vandals lose interest in vandalising pages if their changes aren't immediately visible to the whole readership.
Pages involved in a heavy edit war should look stable to visitors (there's nothing quite like seeing some text to reference, and finding it gone 10 min later when you return).
More reliable: readers don't see unchecked information (in articles, where stable versions exists).

Secondary:

The planned mirror servers for reading Wikipedia don't need that much updates (means less traffic to the main server, where the editing of articles in the central database is done)
Notes to reporters and schools using WP as a reference should have something better than "there are lots of us keeping an eye on things" backing up our descriptions of accuracy and reliability.
Minimal interface changes: minimal change for users (keep it simple)

Basic implementation ideas

No branches as in CVS. Only specific versions of an article get the "stable" tag. In the meantime the article can be edited and the next stable version will be that new one that gets the next stable tag. Branches as in CVS and traditional software versioning with major and minor number are definitely way to complicated out of two reasons:
- Merging of content between different branches of an article is not trivial.
- There is no maintainer of an article, so none can dictate what exactly is a minor (and thus an acceptable) change to a stable version.
Stable tags are created by votes. If a version has more vote points than a specific limit it is labeled as stable in mediawiki software either fully automatically or by an admin. (there is need for a good voting system to prevent users from creating fake accounts for pushing bad versions)
Mirror servers for page reading will host the last version of an article (if there is no stable version) or the last stable version of an article. If a user has the "unstable-view" on he will get automatically the latest version from wikipedia main servers (editing is always done on the main servers).

Vote system

Completely user driven

Users give votes to the versions of an article they find good. This can be one version or all versions of this article until the last reviewed version (those preferential vote systems are mathematical proven to be as fair as possible in respect to the voters intent for those kinds of one winner votes, e.g. presidential elections).
The first version which gets more votes than a specific limit is automatically the new reviewed version. From now on only versions later than that one can be voted.
Perhaps: For ease of coding and maintaining consistency in the DB, only one by the first voter determined version of an article can be in vote (in most cases when there is no edit war the most recent version) until this vote is over.

Admin as executor

Only Admins should be able to mark an article Version as "reviewed" after a vote, (they act as executioners for reviewers, who need not be admins).
The procedure to mark an article would be determined by the community and also the voting: For major changes probably along the lines of determining excellent articles (as on the german WP), for minor changes using a simplified approach, for 'Patches' maybe just one of the previous reviewers (it is supposed to allow for typos, etc).
Perhapes: For ease of coding and maintaining consistency in the DB, only one by the first voter determined version of an article can be in vote (in most cases when there is no edit war the most recent version) until this vote is over.

Definitions, Backwards Compatibility

If there is no stable version of an article everything is as it is now for this article. Most articles won't need a stable tag (now), so nobody is required to use this.
Two views of the system: stable and latest. Default is "stable" (also for anonymous). If there is a stable version make a note and link to the newer unstable version (e.g. as tab at top next to the edit, talk, version and other tabs).
Make a user option "Show always latest version of articles"
When a user tries to edit the article, show the latest version, as for any user (and a warning to look first in the unstable version if he went directly from stable version to edit).

DB Extensions

The suggested change to the DB schema needs to be as small as possible. It tries to be flexible as well, with the change not imposing any procedural structure, just offering a possiblility, as outlined below.

The DB needs additional information for selected article versions. This can be done

by either adding these fields to the existing cur / old tables,
or by having a separate table, that carries attached information to a selected article version.

Needed would be

(1) summary vote points

(2) vote list with reviewers and their individual vote points for this reviewed version (and additional comments)

(3) perhapes a link onto last reviewed version (last version with vote points above a certain limit)

In my opinion, the most important step to get a revision system (if desired) under way, is to make it possible in the DB; uses and details can be determined and developed over time. (And probably will and should evolve, according to the needs and experiences.)

Advantages and Potential

Use is optional

Nobody is forced to use this feature. It remains (almost) invisible to all but those who are interested.

Structured History

Marking revisions of an article puts a structure onto the article history. This way it is easier to follow the overall development of the article.
One misses, obviously, all the 'rejected' contributions. Those are also in the current changelist difficult to find.
A peer Review becomes more easy for subsequent reviews, because one does not start at zero, but at a reviewed article.

Have a 'good' version available

Those preferring a checked but maybe outdated version get what they want.
People working on a hard-copy release (CD/DVD/Paper) can use, e.g. the latest reviewed version, and can be relatively sure that at least someone looked and approved of the content. The final proof would be simpler.
Also, people generating a hard-copy version can mark their review in the on-line WP, thus putting value back into the project.

Marking value

Contributers turned away by the attitude: "I contribute, and the next idiot wrecks havoc" see their work preserved.
There is an added incentive to increase the quality of an article. Having ones article marked as a stable version, with ones name attached, pleases the ego.

Other

Vandalism is discouraged, because it becomes less relevant.
Edit-wars are less useful, because back and forth changes may not make it into the next stable version.
Working more goal oriented toward the next revision (assuming there are some standards, that need to be met in order to 'advance' an article).

Multi-language

Contributers may want a feature "Show me, if there is a major stable version in one of the languages I know", easy to have a software solution (bot) for this, hard to do it by hand.

Disadvantages and Problems

Nupedia-Angst

Nupedia failed, and such a system is too similar to Nupedia. There will just not be the people marking stable Versions.

Reply: People are currently working on reviewing and excellent articles. The new feature is just marking permanently what is happening already.

Recent Changes Will Suffer

Since the most recent version becomes less important under this scheme, people will cease monitoring the recent pages. Errors and distortions will have it easier to creep in.

Reply: A new automated list "recent changes against most recent stable version" might alleviate this problem.

Reply: The "recent changes" are too large to be useful anyhow. Few people keep track anyhow.

Or, the stable version will suffer if it is not updated. if a page has been marked as stable, does its shaddow unstable have to go through all the hops to get in spelling corections to the stable

Too Much Coding Required

True. A lot of work.

Deleting Article Version

Deleting an article version that is itself a reviewed version will require a lot of consistency checks and updates of many DB fields. Very messy.

Voting system

Everything stands and falls with a clever vandal proof voting system which additional needs to force the user to be objective.

Perhapes combining the vote system with some kind of web of trust solves this problem. Further ideas are welcome.

As a class project I wrote out some ideas for this. (I apologize that it is off-wikimedia; I haven't had a chance to move it over yet. Feel free to copy stuff over to here to discuss it, or I may find time at some point.) Essentially, it is a more general framework which easily would implement the proposal on this page as well as many other possibilities. It works by having users rate 1) other users, 2) entire articles, and 3) specific edits. This enables the software to get an idea of different people's thoughts on articles in the wiki. Lbs6380 02:32, 11 Mar 2005 (UTC)

No automatic counting of votes, please. The process should be very much like en:Wikipedia:Featured article candidates or de:Wikipedia:Kandidaten für exzellente Artikel, with the criteria reduced to the question: "Are all facts correct and is everything impotant mentioned in the article?". A web of trust only tempts certain people to game the system. --Kurt Jansson 19:45, 19 Mar 2005 (UTC)

Kurt of course this system never wants to aim at "featured articles". A reviewed version has another focus than the process you mentioned. The reviewed version only means that this version is NPOV and checked for best accuracy out of a bunch of versions but never if everything important is mentioned within the article. This type of review can't be done with a automated voting cause you first need to create the versions that have all content desired. The reviewed version system is e.g. very helpful if you have an edit war with some persistent vandal ongoing. You vote one version as reviewed and our dear vandal has now no desire to create a new version, has it will never be a reviewed one and so his potential readership is now very much smaller. Of course this kind of system needs to be designed very well thought to prevent playing tricks with it. Arnomane 17:15, 20 Mar 2005 (UTC)

Don't make the voting system "clever", because that means it will be complicated. The system should be this simple: anyone can cast one vote to support a version of an article. Any extra rules you add will only encourage playing games with the system instead of writing an encyclopedia. This can be a great proposal if you keep it simple. Rspeer 21:58, 14 May 2006 (UTC)[reply]

Related ideas

Article validation feature - software patch for a very similar idea
Automatic edit war squashing - User:ssd's writing, as of 4/2004
en:Wikipedia:Stable versions