The article on Christmas is set to be on the Main Page on December 25th.
It used to be Featured quality. That was a year ago. Since then, it has had 600 major edits, 500 other edits, and is nearly unreadable.
Compare the originally Featured version to the current version: http://en.wikipedia.org/w/index.php?title=Christmas&diff=32012542&ol...
Now, it is up for FARC: http://en.wikipedia.org/wiki/Wikipedia:Featured_article_removal_candidates/C...
To prevent stagnated articles from being presented as "top quality" on the Main Page, there seems to be two solutions: set a time limit for Featured Articles, which requires them to be renominated on FAC if they become too different from their original Featured versions; or, implement the "stable article" option that Tim Starling has talked about, which would allow admins to set a "last good version" to be presented to the public at all times, while the real version is somehow edited "behind the scenes". As productive edits pile up, admins can set a newer version as the "last good version". While this can still result in an article being drastically-changed, it is much more likely to be changed for the better in the long run.
brian0918
Hi all, I made a proposal for a validation system at http://meta.wikimedia.org/wiki/User:Aoineko/Validation. Any comment are welcome! (here or on the talk page, in French, English or Japanese). Regards,
Aoineko / Guillaume Blanchard
Brian wrote:
The article on Christmas is set to be on the Main Page on December 25th. It used to be Featured quality. That was a year ago. Since then, it has had 600 major edits, 500 other edits, and is nearly unreadable.
Compare the originally Featured version to the current version: http://en.wikipedia.org/w/index.php?title=Christmas&diff=32012542&ol...
Now, it is up for FARC: http://en.wikipedia.org/wiki/Wikipedia:Featured_article_removal_candidates/C...
To prevent stagnated articles from being presented as "top quality" on the Main Page, there seems to be two solutions: set a time limit for Featured Articles, which requires them to be renominated on FAC if they become too different from their original Featured versions; or, implement the "stable article" option that Tim Starling has talked about, which would allow admins to set a "last good version" to be presented to the public at all times, while the real version is somehow edited "behind the scenes". As productive edits pile up, admins can set a newer version as the "last good version". While this can still result in an article being drastically-changed, it is much more likely to be changed for the better in the long run.
brian0918 _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Guillaume Blanchard wrote:
Hi all, I made a proposal for a validation system at http://meta.wikimedia.org/wiki/User:Aoineko/Validation. Any comment are welcome!
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
Magnus Manske wrote:
Guillaume Blanchard wrote:
i all, I made a proposal for a validation system at http://meta.wikimedia.org/wiki/User:Aoineko/Validation. Any comment are welcome!
I have already implemented most of this as an extension. Exceptions:
- Only one version can be stable/validated at any time.
Why? To save space into the DB?
- 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
What is the opinion of the community about the validation feature? The French community heard from news-paper Jimbo wants this kind of feature in the future but we wondering if there is already any roadmap or some kind of official plan. Am I right if I say the article *reviewing* (public grade) is an interred concept?
In what way the Tim's implementation differ from yours?
Aoineko / Guillaume Blanchard
Guillaume Blanchard wrote:
Magnus Manske wrote:
Guillaume Blanchard wrote:
i all, I made a proposal for a validation system at http://meta.wikimedia.org/wiki/User:Aoineko/Validation. Any comment are welcome!
I have already implemented most of this as an extension. Exceptions:
- Only one version can be stable/validated at any time.
Why? To save space into the DB?
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.
- 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
What is the opinion of the community about the validation feature? The French community heard from news-paper Jimbo wants this kind of feature in the future but we wondering if there is already any roadmap or some kind of official plan. Am I right if I say the article *reviewing* (public grade) is an interred concept?
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?
In what way the Tim's implementation differ from yours?
The major difference I can see is that there's no working demo of it right now :-)
Magnus
Magnus Manske wrote:
Guillaume Blanchard wrote:
Magnus Manske wrote:
Guillaume Blanchard wrote:
I have already implemented most of this as an extension. Exceptions:
- Only one version can be stable/validated at any time.
Why? To save space into the DB?
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.
We will probably need to have the ability to rate versions as being "stable version candidates", otherwise it will be difficult to move from an older stable version to a newer.
By being able to rate/tag a newer version as a stable version candidate, it could then be voted/rated/approved to either eventually become the next stable version, or to be supplanted by another candidate. Users should be able to see not only the history of all versions, but of (say) all versions ever marked as stable, or the larger set of versions marked as candidates for stability.
-- Neil
Neil Harris wrote:
Magnus Manske wrote:
Guillaume Blanchard wrote:
Magnus Manske wrote:
Guillaume Blanchard wrote:
I have already implemented most of this as an extension.Exceptions:
- Only one version can be stable/validated at any time.
Why? To save space into the DB?
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.
We will probably need to have the ability to rate versions as being "stable version candidates", otherwise it will be difficult to move from an older stable version to a newer.
By being able to rate/tag a newer version as a stable version candidate, it could then be voted/rated/approved to either eventually become the next stable version, or to be supplanted by another candidate. Users should be able to see not only the history of all versions, but of (say) all versions ever marked as stable, or the larger set of versions marked as candidates for stability.
For simple things like spelling errors, this system would be way too complicated for approving a newer stable version.
Brian <brian0918@...> writes:
Neil Harris wrote:
We will probably need to have the ability to rate versions as being "stable version candidates", otherwise it will be difficult to move from an older stable version to a newer.
By being able to rate/tag a newer version as a stable version candidate, it could then be voted/rated/approved to either eventually become the next stable version, or to be supplanted by another candidate. Users should be able to see not only the history of all versions, but of (say) all versions ever marked as stable, or the larger set of versions marked as candidates for stability.
For simple things like spelling errors, this system would be way too complicated for approving a newer stable version.
Hmmmm... that's an interesting corner case. But I think regardless that Neil's proposed review process is the way to go. By vote or bureaucrat action, a particular version of an article is nominated for review, users vote on it, and if it is accepted it becomes the "stable" or "approved" version, with various view privileges (e.g. always shown by default, with older AND newer versions only accessible from a special tab). The editing process continues "in the background" however, with later additions to the article eventually converging into a new review candidate, which then becomes the new approved version of the article. Using your example of the [[Christmas]] article, Brian, the version which became "Featured" would be the one users see by default and remain that way until an expanded or otherwise improved version of the article came along. This process should also curb revision wars and make editing a much more deliberative process, since editors will no longer be able to control what users see by default by grabbing control of the top version of an article.
With that said, one problem I noticed with the current review feature implementation (aside from allowing only 1 rating per user of an article, and thus implicitly limiting each article to a single "stable" version) is that it does not force users to vote on a particular revision (though I guess this could be achieved by locking the article). Thus you could get X votes for revision 1000, and Y votes for revision 1001, but the 2 sets of review data cannot be aggregated because the revisions may be substantially different.
Brian wrote:
Neil Harris wrote:
Magnus Manske wrote:
Guillaume Blanchard wrote:
Magnus Manske wrote:
Guillaume Blanchard wrote:
I have already implemented most of this as an extension.Exceptions:
- Only one version can be stable/validated at any time.
Why? To save space into the DB?
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.
We will probably need to have the ability to rate versions as being "stable version candidates", otherwise it will be difficult to move from an older stable version to a newer.
By being able to rate/tag a newer version as a stable version candidate, it could then be voted/rated/approved to either eventually become the next stable version, or to be supplanted by another candidate. Users should be able to see not only the history of all versions, but of (say) all versions ever marked as stable, or the larger set of versions marked as candidates for stability.
For simple things like spelling errors, this system would be way too complicated for approving a newer stable version.
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
Ray Saintonge 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?"
I hope that's not a serious question. :)
Humans are fallible. In the real world, some mistakes will make it all the way to the printers', despite multiple reviews and proofreads. When somebody finally catches them (after you've got a room full of boxes ready to ship out to schools), you mark them down for reference and fix them in the next printing.
A stable-marked wiki page of course is faster to fix than a printed pamphlet or book, since you can declare a new version stable at any time instead of waiting until the 10,000 copies you printed up are used.
-- brion vibber (brion @ pobox.com)
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
Guillaume Blanchard wrote:
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?
Forget validation. It was an odd name for review. I actually can't remember why I called it that... In other news: * "review" = everyone and their grandma can give their opinion on article versions * "stable" = a few selected people can call a version on an article "stable" if they deem it good enough for the unprepared reader. To come: * "review" might become a way to guide the tagging of "stable" * "stable" versions will be served to anons is available instead of the latest version. Logged-in users will have an option.
This seems to be compatible with your proposal.
Magnus
On Wed 21 Dec 2005 09:21:55 +0100, Magnus Manske wrote:
- "stable" = a few selected people can call a version on an article
"stable" if they deem it good enough for the unprepared reader.
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)
Leon Planken wrote:
On Wed 21 Dec 2005 09:21:55 +0100, Magnus Manske wrote:
- "stable" = a few selected people can call a version on an article
"stable" if they deem it good enough for the unprepared reader.
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.
First, there's almost nothing that doesn't happen in the current setup already upon error discovery. The only difference is that a supposedly good version is now known to have an error.
Second, no branching. Never. Ever. Branching in wikis is evil. Evil (tm)!
So, the solution I see is rather obvious: * Remove the "stable" mark * Leave it at that. Obvoiusly, there's only the crappy current version and the buggy (formerly) stable one. * Optionally: Use my "Tasks" feature to mark the article appropriately for fixing/rewriting :-) * Wait until a new, improved version emerges which can be marked "stable"
If there's no version worthy of "stable", none should be marked as such!
Magnus
Magnus Manske wrote:
Second, no branching. Never. Ever. Branching in wikis is evil. Evil (tm)! If there's no version worthy of "stable", none should be marked as such!
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.
Leon Planken wrote:
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.
The 'stable branch' idea sounds workable - no changes beyond typos or seriously problematic content (e.g. libel, copyvio). Particularly if combined with Magnus' idea of a Mediawiki installation that only receives the "good" articles/versions from a read-write Wikipedia.
Jimbo's original request for a ten-minute delay for anon readers would be a better idea for presenting a less unpolished face to the world, IMO, but I understand that's presently considered a technical nightmare and is unlikely in the short term.
- d.
Guillaume Blanchard wrote:
What is the opinion of the community about the validation feature? The French community heard from news-paper Jimbo wants this kind of feature in the future but we wondering if there is already any roadmap or some kind of official plan. Am I right if I say the article *reviewing* (public grade) is an interred concept?
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.
wikitech-l@lists.wikimedia.org