Guillaume Blanchard wrote: I have already implemented most of this as an extension. Exceptions: * Only one version can be stable/validated at any time. * History highlighting is not yet implemented. Why is this not in use? * Pages with templates are not stable. One has to cache the template versions at the moment they are declared stable/valid. * Tim is working on his own implementation. Magnus

Guillaume Blanchard wrote: No. I just didn't see the point of having multiple stable versions. One will do just fine. Also, the "stable version" concept will be confusing to newcomers. Suppose you get the stable version by default, and decide to edit it. You'll be served the source text of the current version. WTF? *Several* stable versions will be even more confusing, with little benefit. There's the Review feature, which replaces the current Validation feature (which is already in the code, but inactive). See my other mail on this list for that. Let's call the one we're talking about "stable version", shall we? The major difference I can see is that there's no working demo of it right now :-) Magnus

Neil Harris wrote: For simple things like spelling errors, this system would be way too complicated for approving a newer stable version.

Brian wrote: The issue of having multiple stable versions seems different from how stability is determined. If version A is stable there should be a simpler routine to follow when a new version that has only such minor differences is made stable. But then I could also as: "why version A was considered stable if it had spelling mistakes?" Ec

I'm totally confusing between "validation", "review" and "stable" concepts and who want what!? On a dynamic site like Wikipedia the "stable" concept seem very odd for me. Does that imply any restrictions to modify the article further? Are we all ok to say an article is never really finished? Actually, the only problem I see is we can't give any kind of guaranties about the exactness of a given article's revision. The featured article label is problematic (at least on French Wikipedia) because we give it to an article (instead of a revision) and with the open system used by Wikipedia we can't assure the future revisions will not contain any errors. In an other hand, any kind of restriction of editing a validated article is contrary to the open spirit of the Wikipedia project. Finally, I think we must clearly separate the review and the validation process. The first is a nice optional feature that tells what the community thinks about an article and/or revision quality, while the second is a really important feature that just tells "(we really think) there is no error in this revision" (this mean an article can be incomplete but "valid"). ("Review" and "validation" are the right words to describe the above?) My proposal [1] only relate to "validation". The main idea is to allow marking any revision of an article as "valid" (by community consensus, validators or an other process to be determined) and use this flag to change some navigation behaviors and give some visual feedback. 2 navigation behaviors: - Validate: When consulting an article with a validated revision existing in history, this validated version is show (otherwise the more recent non-validated revision is shown). When viewing a validated revision and a more recent non-validated exist, a link to this revision is add in navigation panel ("last development"). [default for anonymous] - Development: As now but when a validated revision exist in article history a link to this revision is add in navigation panel ("last validate"). [default for logged users] Visual feedback: - A validated article revision has a different class (CSS) to allow customize its style (different background color, specific information box, etc.). - History highlights (via style) the validated revisions. Any comments are welcome here or on the proposal talk page. Aoineko / Guillaume Blanchard [1] http://meta.wikimedia.org/wiki/User:Aoineko/Validation/en

On Wed 21 Dec 2005 09:21:55 +0100, Magnus Manske wrote: Imagine the following sequence of events: - an article is marked stable - the article 'development' version is heavily edited for a while, not necessarily for the better - a critical error that needs to be fixed immediately is discovered in the version marked as stable (this is possible, the review feature being a process involving humans) I see three possibilities: - the stable flag is removed, the mistake is corrected in the 'development' version, which could then be nominated as 'stable' again - the critical error is corrected in the stable version, making a separate branch in the article history (this would mean a rather big addition to the MediaWiki software to allow for history branches, right?) - the stable article, with the error corrected, is saved as the latest 'development' version which is then marked stable; the previously latest 'development' version is still available through article history (poor man's version branching, rather horrible I think) The second solution above (branching) could also be implemented by allowing just two branches: a 'development' branch and a 'stable' branch. Or just a separate namespace (if you will) for stable articles, editable only by users with the appropriate rights. Leon (aka Oliphaunt) -- I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much, of course - the computer industry didn't even foresee that the century was going to end. -- Douglas Adams (1952 - 2001)

Magnus Manske wrote: I must admit there's a lot to that view :-) I think allowing a 'stable branch' with severely restricted checkin isn't too horrible, if it's not the main Wikipedia. I mean something with change restrictions about as stringent as ancient versions of Solaris get. - d.

Guillaume Blanchard wrote: en: is begging for it. We think it can be used to get en: or a subset up to release quality, and we're envious of de: being on its third DVD edition ;-) - d.