Thanks to Brion, who pointed out the matter of readabilty to me. Accordingly, please allow me another, nicely formatted and more to the point, posting:
It has been said that Wikipedia is „work in progress“ and will probably continue to do so. On the other hand it ails from the fact that at no given point in time you can be certain to have a simultaneously
1.
consistent (with respect to various articles on a similar topic)
2.
unvandalized and
3.
correct (with respect to a single article) throughout Wikipedia
From my point of view, compared to those three points the shortcoming of the non-completeness of WP dwindles to almost nothing.
Let me draw your attention to the fact that the construction plans for roads to stability – or at least local optima – have long been laid out by physics. Heat a dynamic system quickly then let it cool down in a slower and controlled fashion, allowing less and less dramatic changes to take place as time passes. Simulated annealing (http://en.wikipedia.org/wiki/Simulated_annealing) is the magic spell that might work for wikixyzs in a way similar to that in the real world.
The rationale behind my suggestion is of course that articles that have matured over time are - statistically speaking - less likely to improve when large modifications are made than relatively new ones. Some of the articles have reached a stage where well-meant editing effectively mucks up the inner structure and logic.
What I think reasonable is to lift the threshold for substantial edits, maybe not by limiting access but by asking for more substantial background information from the authors (references, printed, electronic,...) than the simple comment line. There is too much unproven and partially unprovable information in the WP. That could have been prevented long ago by obliging the authors to give references for their information. Besides, this task would make it successively harder to simply put established statements upside down. Whereas scientific journals have peer review to prevent superfluous or erroneous contributions, WP only offers the weak weapons of discussion pages (for everyone) and reverts (mostly by admins, who can't always claim erudition in all the domains they are watching, I guess).
So why not confer a little bit more of responsibility to the authors!? He/she could be aided by predefined lists, checkboxes, comboboxes (for ref.type, etc.). Asking a little more information from authors could be a substantial part of the rising editing threshold necessary for "cooling down" WP a bit.
I find myself increasingly involved in hunting down vandals and their work – partly due to the ease of use WP offers for non-serious edits, too, and I can‘t help feeling that a larger and larger part of WP keeps a larger and larger part of the community busy with just keeping up the existing standard. We mustn't be sure of still finding enthusiatic acclaim in the years to come when WP becomes a battlefield in a fight against distracting, redundant or plain wrong infobits.
Comments from both the user/admin and developer side welcome.
Best,
kai (kku)
Kai Kumpf wrote:
The rationale behind my suggestion is of course that articles that have matured over time are - statistically speaking - less likely to improve when large modifications are made than relatively new ones. Some of the articles have reached a stage where well-meant editing effectively mucks up the inner structure and logic.
Looking at our recent JFK-assassin mess, it doesn't need a large edit to mess up an article. The jerk who submitted the misinformation just needed "he was under investigation for killing JFK".
So why not confer a little bit more of responsibility to the authors!? He/she could be aided by predefined lists, checkboxes, comboboxes (for ref.type, etc.). Asking a little more information from authors could be a substantial part of the rising editing threshold necessary for "cooling down" WP a bit.
Because * /demanding/ things (which is effectifely what asking for sources boils down to) from volunteers might cool edits more off than we'd like * this can be gamed (mark it as a minor edit, or write "google" under sources, or give some non-existing or out-of print book, or a book in an obscure language, or set up your own fake page and then give it as source, or...)
I find myself increasingly involved in hunting down vandals and their work – partly due to the ease of use WP offers for non-serious edits, too, and I can‘t help feeling that a larger and larger part of WP keeps a larger and larger part of the community busy with just keeping up the existing standard. We mustn't be sure of still finding enthusiatic acclaim in the years to come when WP becomes a battlefield in a fight against distracting, redundant or plain wrong infobits.
As Brion already stated correctly, the current Wikipedia is an eternal beta version. Validation (how's that coming, BTW?;-) will eventually give some hints to the "end user", but it probably would not have caught the JFK blunder either.
The only way to give Wikipedia a "quality assurance" (limited to human errors, of course:-) would IMHO be a method where someone takes *professional* (not financial or legal:-) responsibility for the quality of an article. Also, this can't just be any user - user accounts are created far too easily for this. It needs to be someone who has the trust of the communtiy, someone with the "power" to say "this article version is good as it is", without having to defent this against trolls or revert-warring against vandals.
That directly leads to a (relatively) small, elite (!=cabal) group of peer reviewers. The cathedral filtering the bazaar, as I said before. This could be done externally (software's in the making), or within wikipedia. The latter would be nicer, however, it might lead to more conflict between those who can peer review and those who can not.
(It goes without saying that none of the above would alter the wiki in any way; it would be an additional feature with no technical impact on the normal Wikipedia editing).
I hope to have a demo site up shortly.
Magnus
Replying to myself for update: You can now try out an external import-only site at:
http://magnusmanske.de/wikipeerdia
("wikipeerdia" was jokingly suggested by Brion a long time ago :-)
How-to: * For testing, anyone can import * Importing is done by clicking on a red link, or on "edit" on an existing page * The import page will show the current en.wikipedia version * You can chose another version in the column on the right * Click the "import" link for the version you want to import * The import will show up as an edit, with the version ID in the comment
Currently, main namespace, categories, and templates are imported. Other namespaces, as well as all talk pages, can be edited normally.
Image import - not yet.
Give it a try and tell me what you think!
Magnus
Magnus Manske wrote:
Currently, main namespace, categories, and templates are imported. Other namespaces, as well as all talk pages, can be edited normally.
Image import - not yet.
Give it a try and tell me what you think!
Why does importing Current Events not work? It's fun, btw!
Gerrit.
Gerrit Holl wrote:
Magnus Manske wrote:
Currently, main namespace, categories, and templates are imported. Other namespaces, as well as all talk pages, can be edited normally.
Image import - not yet.
Give it a try and tell me what you think!
Why does importing Current Events not work?
I just imported Current Events, worked just fine. Maybe the wikipedia was slow to deliver data, and I can't turn off the 30-second-limit for PHP from my provider :-(
It's fun, btw!
Don't overdo it, you'll have to do it all over again *if* there's a "real" site someday :-)
Magnus
--- Magnus Manske magnus.manske@web.de wrote:
The only way to give Wikipedia a "quality assurance" (limited to human errors, of course:-) would IMHO be a method where someone takes *professional* (not financial or legal:-) responsibility for the quality of an article. Also, this can't just be any user - user accounts are created far too easily for this. It needs to be someone who has the trust of the communtiy, someone with the "power" to say "this article version is good as it is", without having to defent this against trolls or revert-warring against vandals.
That directly leads to a (relatively) small, elite (!=cabal) group of peer reviewers. The cathedral filtering the bazaar, as I said before. This could be done externally (software's in the making), or within wikipedia. The latter would be nicer, however, it might lead to more conflict between those who can peer review and those who can not.
(It goes without saying that none of the above would alter the wiki in any way; it would be an additional feature with no technical impact on the normal Wikipedia editing).
I hope to have a demo site up shortly.
The cathedral filtering the bazaar
This sounds wonderful. Make it so! :) I dont edit in the area I majored in (biology), but would love to help filter in that area.
At a recent library conference I spoke at, I openly admitted that Wikipedias biggest problem is that there is no stable/reference version; the whole thing is a draft. I think we now have enough articles that are good enough in at least the larger wikis that we can start creating a stable version that consists of snapshots of our good articles (featured articles are a different beast; those are our best articles).
Editing would go on as it does now and there would be no forks in development; periodically a new snapshot of the development version will be taken to serve as the new stable version. A prominent link to the stable version would be placed on top of the article and cur diffs between it and the current development version would be added. People would need to log in and change their preferences to see stable versions by default (the other way around would hide vandalism in the development version; besides, the most recent/up-to-date version should be on top anyway).
-- mav
__________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Daniel Mayer wrote:
Editing would go on as it does now and there would be no forks in development; periodically a new snapshot of the development version will be taken to serve as the new stable version. A prominent link to the stable version would be placed on top of the article and cur diffs between it and the current development version would be added.
*nods vigorously*
People would need to log in and change their preferences to see stable versions by default (the other way around would hide vandalism in the development version; besides, the most recent/up-to-date version should be on top anyway).
IMHO the opposite needs to be true; reviewed, stable versions need to be right on top, as what the public sees by default.
Sure, there'll be a big fat message showing that 78573 more edits have been made to [[George W. Bush]] since this reviewed version, with a handy link to go right to it and see the changes, but they're gonna see the stable copy first.
We've spent so much time hyping Wikipedia that it's become quite popular at its present location; a separate or hidden click-through stable set will basically never be seen and can't reasonably answer the (totally valid) criticisms that a reference site needs to be a little bit conservative on its public face.
By all means, we should let the vandalism and the JOSH IS GAY and the GWB penis pictures and the occasional bit of alleged libel -- and the genuine building up and back-and-forth of new material development -- happen one level removed from the millions-of-hits-per-day.
Most of those visitors *aren't* participating editors, and on a relatively mature site like en.wikipedia we need to recognize this and act accordingly to meet their requirements as well as those of visitors who start participating. Will it be a speed bump? Yes, it will. But with an industrial firehose-sized stream of visitors, a speed bump is NOT A BAD THING.
-- brion vibber (brion @ pobox.com)
IMHO the opposite needs to be true; reviewed, stable versions need to be right on top, as what the public sees by default.
Sure, there'll be a big fat message showing that 78573 more edits have been made to [[George W. Bush]] since this reviewed version, with a handy link to go right to it and see the changes, but they're gonna see the stable copy first.
We've spent so much time hyping Wikipedia that it's become quite popular at its present location; a separate or hidden click-through stable set will basically never be seen and can't reasonably answer the (totally valid) criticisms that a reference site needs to be a little bit conservative on its public face.
By all means, we should let the vandalism and the JOSH IS GAY and the GWB penis pictures and the occasional bit of alleged libel -- and the genuine building up and back-and-forth of new material development -- happen one level removed from the millions-of-hits-per-day.
Most of those visitors *aren't* participating editors, and on a relatively mature site like en.wikipedia we need to recognize this and act accordingly to meet their requirements as well as those of visitors who start participating. Will it be a speed bump? Yes, it will. But with an industrial firehose-sized stream of visitors, a speed bump is NOT A BAD THING.
-- brion vibber (brion @ pobox.com)
I agree on this. And hope it will get done.
Waerth/Walter
Brion Vibber wrote:
IMHO the opposite needs to be true; reviewed, stable versions need to be right on top, as what the public sees by default.
Sure, there'll be a big fat message showing that 78573 more edits have been made to [[George W. Bush]] since this reviewed version, with a handy link to go right to it and see the changes, but they're gonna see the stable copy first.
We've spent so much time hyping Wikipedia that it's become quite popular at its present location; a separate or hidden click-through stable set will basically never be seen and can't reasonably answer the (totally valid) criticisms that a reference site needs to be a little bit conservative on its public face.
That sounds about right to me. Software developers of course have already arrived at that solution---grab the old, stable, conservative version if you're going to be whiny; if you use the CVS version, don't blame us if it's not done, because it's not supposed to be. =]
(Although those of us who are eventualists haven't been "hyping Wikipedia" in the first place. Perhaps those who have been hyping it before it's ready shouldn't have been.)
-Mark
--- Brion Vibber brion@pobox.com wrote:
Daniel Mayer wrote:
People would need to log in and change their preferences to see stable versions by default (the other way around would hide vandalism in the development version; besides, the most recent/up-to-date version should be on top anyway).
IMHO the opposite needs to be true; reviewed, stable versions need to be right on top, as what the public sees by default.
And when they read something that needs to be fixed or added, they will be reading an older version. Clicking 'edit' at that point would produce a confusing result; an article that would likely have the fix or fact they wanted to added. Principle of least astonishment should rule here. Also, the most up to date version should be, well, on top. Everything else is part of the revision history. That just makes more intuitive sense to me.
Sure, there'll be a big fat message showing that 78573 more edits have been made to [[George W. Bush]] since this reviewed version, with a handy link to go right to it and see the changes, but they're gonna see the stable copy first.
That would only *start* to make sense when more than a small fraction of articles are part of the stable version. Otherwise there would be a confusing mix of stable and development versions displayed to readers depending on if the article has a stable version or not.
We also still want to encourage further growth and improvement of articles that have stable versions, no? Hiding the most recent version takes away the immediacy and instant self gratification one gets when editing. It is a major hook to attract new editors (and until we get our high turnover rate in check, we need to still encourage lots of new users to join).
This would also harm an area we are pretty good at: updating articles whose subject is in the news. If stable versions were displayed by default, then any updates that reflect current events would not be displayed until a new stable version is selected. That would either mean that we would need to have very low standards on the selection of stable versions in order to keep up with updates, or it would kill much of the motivation to update those articles in the first place (a more rigorous selection process - which is what we want, right? - would be too slow to keep up).
We've spent so much time hyping Wikipedia that it's become quite popular at its present location; a separate or hidden click-through stable set will basically never be seen and can't reasonably answer the (totally valid) criticisms that a reference site needs to be a little bit conservative on its public face.
The public face of Wikipedia has always been a work in progress. True, right now I think the pendulum is too far to the openness and development side. But presenting stable versions by default would fundamentally change the whole character of the project and swing the pendulum too far in the other direction, IMO. At the very least we should start this the way I have set out: Prominent links to the stable versions when they exist. We could also put under construction: you can help! icons on all the development versions.
In short: We should make it more obvious that development versions are just that *and* we should give people the option to use stable versions (even the option to see those by default where they exist or even to *only* see those versions). Adding to what we do now is what we need. Making fundamental changes to what we now have, which has been rather successful, would, IMO, be a mistake.
The goose that laid the golden egg does not need a sex change operation; she just needs a new set of clothes and some additional tools to help in egg care.
Most of those visitors *aren't* participating editors, and on a relatively mature site like en.wikipedia we need to recognize this and act accordingly to meet their requirements as well as those of visitors who start participating.
A fraction of readers stream-in as editors. But offering them a static website by default will severely restrict that stream.
-- mav
__________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Daniel Mayer wrote:
--- Brion Vibber brion@pobox.com wrote:
Daniel Mayer wrote:
People would need to log in and change their preferences to see stable versions by default (the other way around would hide vandalism in the development version; besides, the most recent/up-to-date version should be on top anyway).
IMHO the opposite needs to be true; reviewed, stable versions need to be right on top, as what the public sees by default.
And when they read something that needs to be fixed or added, they will be reading an older version. Clicking 'edit' at that point would produce a confusing result;
If you were to dive into the editing world, you'd first be taken to the current development version. Principal of least astonishment, after all!
That would only *start* to make sense when more than a small fraction of articles are part of the stable version.
It starts to make sense *the second* we're seen as serving the general public. That time is already past; the foundation and many volunteers have favored publicity and we're very much in the public eye as a resource, not so much as an in-progress effort. We've not stepped up to our responsibilities to be clear about what we are and what we provide; either we need to put a big "Bug off!" on every page and tell everyone to go away while we play around for another five years, or we need to get serious about being a public resource.
Otherwise there would be a confusing mix of stable and development versions displayed to readers depending on if the article has a stable version or not.
We also still want to encourage further growth and improvement of articles that have stable versions, no? Hiding the most recent version takes away the immediacy and instant self gratification one gets when editing. It is a major hook to attract new editors (and until we get our high turnover rate in check, we need to still encourage lots of new users to join).
The time is past that we can pretend we're just a few geeks editing for fun. To serve the public -- and that *is* the point of an encyclopedia -- we need public-facing pages that have been reviewed.
This would also harm an area we are pretty good at: updating articles whose subject is in the news.
Those same articles will be very actively worked on by reviewers, I have no doubt. If they are in fact slower to update, THEN GOOD! We *need* to be slower to update.
We *need* to be more careful and deliberate.
We *need* to be more selective.
We *need* to be less of a crap conduit.
Explosive growth is *not* our primary concern today. We already have way too many articles; we need to concentrate on quality. Concentrating on "growth" will just keep us in the death spiral we're in now.
The public face of Wikipedia has always been a work in progress. True, right now I think the pendulum is too far to the openness and development side. But presenting stable versions by default would fundamentally change the whole character of the project
Something which is necessary!
and swing the pendulum too far in the other direction, IMO.
I disagree.
A fraction of readers stream-in as editors. But offering them a static website by default will severely restrict that stream.
That'll be a good thing.
-- brion vibber (brion @ pobox.com)
--- Brion Vibber brion@pobox.com wrote:
If you were to dive into the editing world, you'd first be taken to the current development version. Principal of least astonishment, after all!
The version they dive into edit would *not* be the version they first came upon and read. I fail to see how that would not be at least a little confusing.
We've not stepped up to our responsibilities to be clear about what we are and what we provide; either we need to put a big "Bug off!" on every page and tell everyone to go away while we play around for another five years, or we need to get serious about being a public resource.
Making the distinction between development and stable versions and linking to stable versions serves both purposes.
The time is past that we can pretend we're just a few geeks editing for fun. To serve the public -- and that *is* the point of an encyclopedia -- we need public-facing pages that have been reviewed.
And my idea of having stable versions linked from development versions does not serve that? There are hundreds of other websites out there that provide static mirrors of our content. So Wikipedia does not need to concentrate on that.
When we get a critical mass of stable articles, the mirrors almost certainly will choose to only host those. If readers what to use Wikipedia to view stable articles by default, then they just need to create an account and set their preferences.
But *WIKIPEDIA IS WHERE THE DEVELOPMENT HAPPENS* And we are far, far, from being a comprehensive source of human knowledge. Let's not pretend that our current article count is at all adequate to serve our goals. It is not.
Those same articles will be very actively worked on by reviewers, I have no doubt. If they are in fact slower to update, THEN GOOD! We *need* to be slower to update.
Maybe the really popular and heavily-edited articles, but not the more obscure topics that need to be updated. Heavily-edited articles should instead have delayed edits for anons and new users. Articles that are not heavily-edited should not have that though.
We *need* to be more careful and deliberate.
We *need* to be more selective.
We *need* to be less of a crap conduit.
And all of that is served by my idea; stable versions prominently linked from development versions that are clearly identified as such. My plan adds to our current methods, which have brought us far.
Explosive growth is *not* our primary concern today. We already have way too many articles; we need to concentrate on quality. Concentrating on "growth" will just keep us in the death spiral we're in now.
And concentrating on stagnation is the key? I don't think so. We need to balance growth with quality. Under my plan, editors will still be highly motivated to get articles to the point where a reviewer can mark a version as stable. Hiding the development version by default effectively means we don't much care about further improvement to the article. It also means less motivation to editors (who have all their work hidden away until a reviewer finds time to review it).
The public face of Wikipedia has always been a work in progress. True, right now I think the pendulum is too far to the openness and development side. But presenting stable versions by default would fundamentally change the whole character of the project
Something which is necessary!
Why? We have come very far with our current model. Let's *add* to it instead of replace it. We should we consider fundamental *only* if adding to our current methods does not work. Otherwise we risk throwing the baby out with the bathwater.
A fraction of readers stream-in as editors. But offering them a static website by default will severely restrict that stream.
That'll be a good thing.
Hiding development versions and greatly reducing new recruitment will result in development versions that, on average, deteriorate with time, instead of improve.
Sunshine is the best medicine. Development versions need more sunshine than stable versions do. Just make it very clear to the reader what is what and that they can log-in to view stable versions by default.
-- mav
__________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Daniel Mayer wrote:
Hiding development versions and greatly reducing new recruitment will result in development versions that, on average, deteriorate with time, instead of improve.
Sunshine is the best medicine. Development versions need more sunshine than stable versions do. Just make it very clear to the reader what is what and that they can log-in to view stable versions by default.
That seems reasonable, so long as it's very clearly/prominently labeled as the development version, rather than "stable version" just being another one of the tabs next to "history" and "edit this page" or something. Basically, it should be possible to respond to any "I found [inaccuracy x] in Wikipedia" with "well, did you check the stable version, or the one we very clearly marked as in development?"
-mark
Daniel Mayer wrote:
--- Brion Vibber brion@pobox.com wrote:
If you were to dive into the editing world, you'd first be taken to the current development version. Principal of least astonishment, after all!
The version they dive into edit would *not* be the version they first came upon and read. I fail to see how that would not be at least a little confusing.
We've not stepped up to our responsibilities to be clear about what we are and what we provide; either we need to put a big "Bug off!" on every page and tell everyone to go away while we play around for another five years, or we need to get serious about being a public resource.
Making the distinction between development and stable versions and linking to stable versions serves both purposes.
It might be a start, but it still leaves us with unreviewed crap by default.
The time is past that we can pretend we're just a few geeks editing for fun. To serve the public -- and that *is* the point of an encyclopedia -- we need public-facing pages that have been reviewed.
And my idea of having stable versions linked from development versions does not serve that?
No, it doesn't. It keeps the crap out in front, leaving us with a permanent reputation as unreliable and dangerous.
There are hundreds of other websites out there that provide static mirrors of our content. So Wikipedia does not need to concentrate on that.
If we don't want to concentrate on it, then we need to make a serious effort to keep people *off* of Wikipedia and divert them to those "static mirrors". This means backpedaling on the last couple years of publicity and going out of our way to:
* Prevent linking to articles at *.wikipedia.org * Keep pages at *.wikipedia.org out of search engines, or very lowly ranked * Get rid of any "citation" features that encourage people to reference pages at our site.
When we get a critical mass of stable articles, the mirrors almost certainly will choose to only host those. If readers what to use Wikipedia to view stable articles by default, then they just need to create an account and set their preferences.
If you keep putting something else out in front, that's what mirrors are going to want. (It's also what the crappy leech-mirrors are going to get by default.)
But *WIKIPEDIA IS WHERE THE DEVELOPMENT HAPPENS* And we are far, far, from being a comprehensive source of human knowledge. Let's not pretend that our current article count is at all adequate to serve our goals. It is not.
Our "article count" is, if anything, too high. Article count is meaningless at this point; pretending a growth in article count is helpful is not going to get us anything but big numbers to toss around press releases and look impressive.
Explosive growth is *not* our primary concern today. We already have way too many articles; we need to concentrate on quality. Concentrating on "growth" will just keep us in the death spiral we're in now.
And concentrating on stagnation is the key? I don't think so. We need to balance growth with quality. Under my plan, editors will still be highly motivated to get articles to the point where a reviewer can mark a version as stable. Hiding the development version by default effectively means we don't much care about further improvement to the article. It also means less motivation to editors (who have all their work hidden away until a reviewer finds time to review it).
Concentrating on "growth" leaves us in a stagnating rut where we never have anything that's safe to show in public. Why bother improving it if it's going to have a penis picture on it whenever anyone goes to look at it?
The public face of Wikipedia has always been a work in progress. True, right now I think the pendulum is too far to the openness and development side. But presenting stable versions by default would fundamentally change the whole character of the project
Something which is necessary!
Why? We have come very far with our current model. Let's *add* to it instead of replace it. We should we consider fundamental *only* if adding to our current methods does not work. Otherwise we risk throwing the baby out with the bathwater.
I'm recommending we add to it, not replace it. Why do you think otherwise?
A fraction of readers stream-in as editors. But offering them a static website by default will severely restrict that stream.
That'll be a good thing.
Hiding development versions and greatly reducing new recruitment will result in development versions that, on average, deteriorate with time, instead of improve.
I believe this to be false. Making it *visible* that development is happening by having a clear distinction, a visible marker of progress from the last stable revision, and a review process that is interactive, should *encourage* improvement in quality.
Sunshine is the best medicine. Development versions need more sunshine than stable versions do. Just make it very clear to the reader what is what and that they can log-in to view stable versions by default.
If you want sunshine, then let us have stable reviewed versions up front so there's light at the end of the tunnel!
-- brion vibber (brion @ pobox.com)
--- Brion Vibber brion@pobox.com wrote:
It might be a start, but it still leaves us with unreviewed crap by default.
unreviewed≠crap
Please, don't buy into what the Wikipedia naysayers spew. We have lots and lots of good content that is constantly improving; just because it is not formally reviewed does not make it crap. We in fact have lots and lots of good to great articles. I would not call them crap.
No, it doesn't. It keeps the crap out in front, leaving us with a permanent reputation as unreliable and dangerous.
Not if it is clearly marked as a development version.
If we don't want to concentrate on it, then we need to make a serious effort to keep people *off* of Wikipedia and divert them to those "static mirrors". This means backpedaling on the last couple years of publicity and going out of our way to:
- Prevent linking to articles at *.wikipedia.org
- Keep pages at *.wikipedia.org out of search engines, or very lowly ranked
- Get rid of any "citation" features that encourage people to reference pages at
our site.
No - that would be the wrong thing to do. I think a great many people will want to link to the most up-to-date version (or the version they read via the cite feature). If they want to link to the stable version, then they can also do that.
If you keep putting something else out in front, that's what mirrors are going to want. (It's also what the crappy leech-mirrors are going to get by default.)
We give them the option to only download stable versions. I'm sure a great many will do that instead of having to worry about hosting unvetted content. Fixing bad articles on Wikipedia is a lot easier than on a static mirror. So that is the logical place to have those.
Our "article count" is, if anything, too high. Article count is meaningless at this point; pretending a growth in article count is helpful is not going to get us anything but big numbers to toss around press releases and look impressive.
Who said anything about numbers? I want us to cover the sum of human knowledge. We won't be anywhere near that goal for years (even at current growth). Yeah, that will require us to have many, many more articles, but the point isn't to have a high number for bragging rights.
Concentrating on "growth" leaves us in a stagnating rut where we never have anything that's safe to show in public. Why bother improving it if it's going to have a penis picture on it whenever anyone goes to look at it?
I'm advocating less concentration on growth than there already is. At the same time, I don't want to ruin what we already have.
Having something safe to show in public? I want to have something that is good and improving. The 'good' part of that is well-served by having stable versions, but the 'improving' part is not well-served by hiding the development version from potential editors.
I'm recommending we add to it, not replace it. Why do you think otherwise?
You want to hide the most recent version of articles with a static version. That is very, very different from what we do now. It is very different from what has made us work.
I believe this to be false. Making it *visible* that development is happening by having a clear distinction, a visible marker of progress from the last stable revision, and a review process that is interactive, should *encourage* improvement in quality.
Why bother improving something when it is hidden away in a closet somewhere?
Sunshine is the best medicine. Development versions need more sunshine than stable versions
do.
Just make it very clear to the reader what is what and that they can log-in to view stable versions by default.
If you want sunshine, then let us have stable reviewed versions up front so there's light at the end of the tunnel!
Cute :)
-- mav
__________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Daniel Mayer wrote:
--- Brion Vibber brion@pobox.com wrote:
It might be a start, but it still leaves us with unreviewed crap by default.
unreviewed≠crap
Please, don't buy into what the Wikipedia naysayers spew. We have lots and lots of good content that is constantly improving;
Sure, lots of it. We also have crap, lots of it.
-- brion vibber (brion @ pobox.com)
--- Brion Vibber brion@pobox.com wrote:
Daniel Mayer wrote:
--- Brion Vibber brion@pobox.com wrote:
It might be a start, but it still leaves us with unreviewed crap by default.
unreviewed≠crap
Please, don't buy into what the Wikipedia naysayers spew. We have lots and lots of good content that is constantly improving;
Sure, lots of it. We also have crap, lots of it.
Then we need to work on identifying what article versions are good enough to be called stable, clearly label everything else as development, and tag appropriately within the development versions (NPOV dispute, clean-up, factual accuracy dispute, etc). We can use delayed-editing to slow down edits to some articles, protection where needed, and even some more clamping down on anons and newbies in ways that would reduce the load on the people cleaning up after them w/o harming recruitment of good editors too much. But we still have lots and lots of work to do even on the articles we already have, so we should not downplay development by hiding development versions.
-- mav
__________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
To give maximum choice, I have just written a new MediaWiki extension which allows for *one* revision of an article to be declared "stable".
A select group of users can declare an article version as "stable". In the default setup, the "select group" is everyone, but that would have to be tightly restricted in an live setup. For this purpose, I propose the creation of a new user group, like buerocrats and sysops, called "prozacs" - after all, they are supposed to stabelize the wiki ;-)
My implementation supports only one stable version per article. If a new stable version is selected, the information about the "last" stable version is removed. The advantage is that this setup works without any additional database reads (of course it still has to write information on setting a new stable version).
Setting a version as stable is currently not logged; this isn't a technical problem, but sheer lazyness on my part.
There is a problem with templates; even a stable version will use new templates. I do not have a neat soultion for that, except generally limiting write access to templates. However, misinformation through a template will be hard to achieve anyway, compared to directly editing article; also, template changes will be noticed rather quickly.
This complements the validation feature and the external "import-wiki". Now all the community has to do is chose. Simple, eh? ;-)
Tech stuff: * CVS, module "extensions", file "StableVersion.php" (note the database change described at the beginning of the file) * requires latest MediaWiki from CVS (because of hooks) * does not log "stable version setting" (yet)
Magnus
--- Magnus Manske magnus.manske@web.de wrote:
To give maximum choice, I have just written a new MediaWiki extension which allows for *one* revision of an article to be declared "stable".
Yay! You rock! :)
A select group of users can declare an article version as "stable". In the default setup, the "select group" is everyone, but that would have to be tightly restricted in an live setup. For this purpose, I propose the creation of a new user group, like buerocrats and sysops, called "prozacs" - after all, they are supposed to stabelize the wiki ;-) .
There is a problem with templates; even a stable version will use new templates. I do not have a neat soultion for that, except generally limiting write access to templates. However, misinformation through a template will be hard to achieve anyway, compared to directly editing article; also, template changes will be noticed rather quickly.
Why not just copy the source HTML of a reference stable revision at the time of marking and serve that? That way whatever was in the template at the time of the snapshot will be displayed as the stable HTML copy.
This complements the validation feature and the external "import-wiki". Now all the community has to do is chose. Simple, eh? ;-)
Yep. The article validation feature could eventually be used to automatically feed a list of top reviewed article versions. Those with the ability to mark revisions as stable would use that list to select stable versions. Policies on each wiki would dictate the standards that the stable-making "prozacs" would need to follow.
Did I mention yet, that YOU ROCK! :)
-- mav
__________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Daniel Mayer wrote:
Why not just copy the source HTML of a reference stable revision at the time of marking and serve that? That way whatever was in the template at the time of the snapshot will be displayed as the stable HTML copy.
Copying the state of the template at the time sounds like the most foolproof solution, but it will have to be a copy of the wikitext rather than an HTML copy if we want to keep all our various user-configurable display features (e.g. date and link formatting).
-Mark
Delirium wrote:
Daniel Mayer wrote:
Why not just copy the source HTML of a reference stable revision at the time of marking and serve that? That way whatever was in the template at the time of the snapshot will be displayed as the stable HTML copy.
Copying the state of the template at the time sounds like the most foolproof solution, but it will have to be a copy of the wikitext rather than an HTML copy if we want to keep all our various user-configurable display features (e.g. date and link formatting).
Of course, the most *elegant* way to solve the template problem would be to use the stable version of a template when displaying a stable article. We don't want an immutable page, after all, just a "stabelized" one, to assure quality. Right?
But somehow that screams "dependency and caching hell"...
Tech note : Besides page_latest, there's now page_stable (default=0), which could be used for template queries (with page_latest as fallback).
Magnus
Magnus Manske wrote:
Setting a version as stable is currently not logged; this isn't a technical problem, but sheer lazyness on my part. There is a problem with templates; even a stable version will use new templates. I do not have a neat soultion for that, except generally limiting write access to templates. However, misinformation through a template will be hard to achieve anyway, compared to directly editing article; also, template changes will be noticed rather quickly.
Would a neat solution be to attach a list of the revision IDs of all templates in the stable version, so that when the page is called up it calls up those versions of the templates? Or is this harder than it sounds?
- d.
David Gerard wrote:
Magnus Manske wrote:
Setting a version as stable is currently not logged; this isn't a technical problem, but sheer lazyness on my part. There is a problem with templates; even a stable version will use new templates. I do not have a neat soultion for that, except generally limiting write access to templates. However, misinformation through a template will be hard to achieve anyway, compared to directly editing article; also, template changes will be noticed rather quickly.
Would a neat solution be to attach a list of the revision IDs of all templates in the stable version, so that when the page is called up it calls up those versions of the templates? Or is this harder than it sounds?
So, a new table to store all revision numbers of the templates used in the stable article version. And the templates used in *these*, too. (And so on.) And tell the parser to use these. (What if one of these revisions was deleted? Use the "nearest"?) And all that from within an extension.
Ask Erik Moeller about WikiData and "revision consistency hell" ;-)
Don't get me wrong, this is possible, no doubt; but I'm still struggling with the logging system (my attempt is half-broken, could someone take a look there?). IMHO templates (in this context) are a problem, but a very minor one, compared to what the feature achieves otherwise with very little mess.
If templates turn out to be a big problem later, we can just say (globally): * If showing a stable version, use the stable (in contrast to the latest) template version, if such is set (latest remains fallback)
That would minimize messing with the system while giving high-quality results, with a minimum of special cases.
Magnus
Magnus Manske wrote:
David Gerard wrote:
Would a neat solution be to attach a list of the revision IDs of all templates in the stable version, so that when the page is called up it calls up those versions of the templates? Or is this harder than it sounds?
So, a new table to store all revision numbers of the templates used in the stable article version. And the templates used in *these*, too. (And so on.)
Ew. Ew ew ew. I forgot templates in templates. Ew.
(That buggers that solution to the same problem with article validation. Ah well.)
Bah, I guess storing the wikitext of the stable version separately would be the least worst solution then?
- d.
Magnus Manske wrote:
To give maximum choice, I have just written a new MediaWiki extension which allows for *one* revision of an article to be declared "stable".
[snip]
Neat!
Magnus, it'd be great if you could pop into #mediawiki on irc.freenode.net from time to time and chat with the boys; Tim was already working on a tagging system which does this sort of thing, expanding from Salvatore's earlier partial-protection experiment. We'll see how the pieces fit together. :)
I'll go look it over...
-- brion vibber (brion @ pobox.com)
Magnus Manske wrote:
- this can be gamed (mark it as a minor edit, or write "google" under
sources, or give some non-existing or out-of print book, or a book in an obscure language, or set up your own fake page and then give it as source, or...)
What's wrong with using an out-of-print book as a source? It might be the only source for this 18-people remote saami village in the Kiruna municipality of Lapland?
As Brion already stated correctly, the current Wikipedia is an eternal beta version. Validation (how's that coming, BTW?;-) will eventually give some hints to the "end user", but it probably would not have caught the JFK blunder either.
Parts look more like alpha than like beta to me.
That directly leads to a (relatively) small, elite (!=cabal) group of peer reviewers. The cathedral filtering the bazaar, as I said before. This could be done externally (software's in the making), or within wikipedia. The latter would be nicer, however, it might lead to more conflict between those who can peer review and those who can not.
A problem with a bazaar is that the products sold might not conform to the norms that current society holds.
Gerrit.
Gerrit Holl wrote:
Magnus Manske wrote:
- this can be gamed (mark it as a minor edit, or write "google" under
sources, or give some non-existing or out-of print book, or a book in an obscure language, or set up your own fake page and then give it as source, or...)
What's wrong with using an out-of-print book as a source? It might be the only source for this 18-people remote saami village in the Kiruna municipality of Lapland?
Nothing's wrong with that. But if I were a subtle vandal and had to cite my sources, I might cite some out-of-print book, hoping noone will get a hold of a copy soon. Thus, using "cite your sources" to prevent subtle vandalism doesn't work.
As Brion already stated correctly, the current Wikipedia is an eternal beta version. Validation (how's that coming, BTW?;-) will eventually give some hints to the "end user", but it probably would not have caught the JFK blunder either.
Parts look more like alpha than like beta to me.
Considering Microsoft sells beta-stage software as "stable", the borders are kinda fluent there :-)
That directly leads to a (relatively) small, elite (!=cabal) group of peer reviewers. The cathedral filtering the bazaar, as I said before. This could be done externally (software's in the making), or within wikipedia. The latter would be nicer, however, it might lead to more conflict between those who can peer review and those who can not.
A problem with a bazaar is that the products sold might not conform to the norms that current society holds.
It's not like the reviewers would come in from another reality. IMHO, many Wikipedians would qualify. The point is that there would be a higher standard of quality; people who import substandard articles would soon be excluded. The main rule would be along the lines "Import *only* if you *know* this article is good".
Magnus
On 12/6/05, Magnus Manske magnus.manske@web.de wrote:
Gerrit Holl wrote:
Magnus Manske wrote:
- this can be gamed (mark it as a minor edit, or write "google" under
sources, or give some non-existing or out-of print book, or a book in an obscure language, or set up your own fake page and then give it as source, or...)
What's wrong with using an out-of-print book as a source? It might be the only source for this 18-people remote saami village in the Kiruna municipality of Lapland?
Nothing's wrong with that. But if I were a subtle vandal and had to cite my sources, I might cite some out-of-print book, hoping noone will get a hold of a copy soon. Thus, using "cite your sources" to prevent subtle vandalism doesn't work.
I'd raise the standard for anonymous contributors even higher, though, especially for potentially controversial facts. Just citing an out-of-print book that no one can get a hold of isn't enough (of course, the number of these books is decreasing thanks to projects like Google Print).
Wikipedia can do without the really obscure facts for a few months. Put 'em in the talk page and/or list them on [[Wikipedia:alleged facts that need to be researched]].
Anthony
wikipedia-l@lists.wikimedia.org