[Wikipedia-l] Re: Stable versions policy

Wed Dec 28 13:21:15 UTC 2005

Displaying vandalism instantaneously is the real problem and better work flow management will help
to mitigate that problem a great deal. Delayed edits for anons and new users will also help; even
going so far as preventing any edit by an anon or new user from being saved (and thus displayed)
until a trusted user has checked it for obvious vandalism. Many things can be used to minimize the
risk of showing obscene vandalism to readers. Let's at least *try* those before doing something
that will fundamentally change the character of the project. 

We also need to make sure that live versions are clearly marked as the latest but unreviewed
version of articles. That readers need to be extra careful with those versions but at the same
time should not regard stable versions as infallible either. 

If the stable designations is to mean anything, then the amount of review needed to get it will
ensure that stable versions will be, on average, significantly less current than the live version.

So showing stable versions by default will *kill* one of the best aspects of Wikipedia; its
ability to record history as it happens. It will also encourage needless forking of articles with
stable versions whenever its subject is in the news. Not because doing that is best for covering
the subject, but *only* to be able to report on the current events (no stable version = live
version is displayed). 

For these reasons and others, I am **EXTREMELY** against hiding the live version behind stable
ones on Wikipedia. If that is what they want, then there will be plenty of mirrors that will only
display stable versions of our articles. Or they could simply choose to view stable versions by
default; either by clicking on a 'View stable version of this article' link for selected articles
or logging in and setting their preferences for that. 

Hiding the live version behind a stable one is like cutting your nose off to spite your face. It
tries to solve a problem that does not exist; the Nature article showed that we are on the right
track with our current methods. We just need better ways to prevent the display of obvious
vandalism at any time (even a few seconds is unacceptable since a reader may have loaded the
article during that time). We *DO NOT* need to also hide all the other valid edits that go on.
Hiding those just to prevent the display of vandalism is a blunt tool that *will* cause more harm
than good. We need to focus on our real problems and surgically target solutions to combat them.

Don't get me wrong; I'm all for having a stable article system in the mold of the old sifter idea.
It will be very useful as part of workflow management and attaining our goal to have print and
CD/DVD versions of our content. It will also be useful on the website since it gives readers the
option to cite slightly more trustworthy versions if they value that over having the most
up-to-date version that has only been checked to make sure there is no obvious vandalism.
Prominent links to the stable version should be provided along with easy ways for readers to
choose to only view those by default if they want. But the wikipedia.org website is where the
development of the content goes on. So that needs to be the focus. We just need better workflow
management to ensure we don't display obvious vandalism to readers.

Again, being current and up to date is our most lauded characteristic. Hiding the live version
behind stable ones kills that *unless* the 'stable' label is diluted and bastardized to only mean
'no obvious vandalism'. 

-- mav

__________________________________ 
Yahoo! for Good - Make a difference this year. 
http://brand.yahoo.com/cybergivingweek2005/