Magnus Manske wrote:
I don't know if you've seen my test page, but just below the title, there's a line "This is the stable version. The current working version is [[here]]".
Perhaps choosing words that less drastically separate the two versions will make it psychologically easier to bridge the gap that makes readers into editors.
"This is the public version. An updated, editable draft is [[here]]."
I think this would still get across the point that one is more stable and reliable, without creating an atmosphere that denigrates the ongoing process.
--Michael Snow
Michael Snow wrote:
Perhaps choosing words that less drastically separate the two versions will make it psychologically easier to bridge the gap that makes readers into editors.
"This is the public version. An updated, editable draft is [[here]]."
I think this would still get across the point that one is more stable and reliable, without creating an atmosphere that denigrates the ongoing process.
Well, it does imply that the "stable" version isn't public.
Why can't it be "This is a work in progress. An older version of more reliable quality can be found [[here]]"?
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/
IMHO, Havnig a Stable Version is a Good Thing, however changing how editing works is not. I would be in favor of keeping everything the way it is now, except: Allow the version to be flagged as validated, DO NOT show it be default, and call it something friendlier like 'Last Version for Publication', with a tab on the top, the introduction text in this link should not say this is a perfect article, etc; just that it is the last version that was selected for export to other media's, these versions are periodically updated, to update this version (follow this link or steps for validating a new version).
xaosflux
----- Original Message ----- From: "Daniel Mayer" maveric149@yahoo.com To: wikipedia-l@Wikimedia.org Sent: Wednesday, December 28, 2005 8:21 AM Subject: Re: [Wikipedia-l] Re: Stable versions policy
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/ _______________________________________________ Wikipedia-l mailing list Wikipedia-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
Bryan Derksen wrote:
Michael Snow wrote:
"This is the public version. An updated, editable draft is [[here]]."
Well, it does imply that the "stable" version isn't public.
Gah. I meant the editable version isn't public, of course.
*edit*
wikipedia-l@lists.wikimedia.org