Wikipedia talk:Stable versions/archive2

From Wikipedia, the free encyclopedia

You have new messages (last change).
Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Contents

Good idea, but what we really need is branching

I like this idea, but the big problem with publishing a version of the article in the way you propose is that the history is lost. Worse still, protecting the release page, while important, prevents us from making later necessary changes such as severe errors that were missed. Moving the article is not an option, since it can no longer be edited for future releases.

What we need, pursuing the software development analogy, is branching. We need a way to branch off a version from the current version that will have the same history but will no longer be edited except for "fixes"; that is, new content will not be added, extensive refactoring will not be done, it will just be fact-checked and small fixes done. This could be enforced by a strict review process. This will enable it to become more "polished" over time while the current version continues to grow in depth and organization. At a later time another "release" could supplant the old one, perhaps with an option of viewing the previous "release" if desired.

The end result would be the same we see with software: the release version becomes very reliable and is suitable for public use at all times, but without all the cutting-edge content (our equivalent of features) of the current version. Deco 01:29, 7 December 2005 (UTC)

good idea. how about still having protected pages but fixes (republication) of those protected release articles are a speedy process just like we have Wikipedia:Speedy delete. -- Zondor 01:59, 7 December 2005 (UTC)
While I see what you're getting at, I think it would become outdated fairly quickly, and unless the articles were to be specifically and thoroughly checked, I don't think they would be likely to be any more accurate than the live 'pedia. Ambi 04:47, 7 December 2005 (UTC)
Let's be more clear about the goals we have. The purpose of the proposal is to produce an end product that is to be consumed. ie. To be printed and to be used in schools in which students rely upon. Any article that is left unprotected is not considered fully trustworthy because at any given time, it could be subjected to vandalism no matter how quick we respond to it. Yes, they have to be thoroughly checked if it is ever to be used in court cases. If the stable versions are still left unprotected, we are still at the original problem in trying to reach Wikipedia:1.0 because how can you starting printing them while they are still being edited (unprotected)? Articles can continuously be improved forever but it has to come to an end at some point. Protection is a declaration of the final revision. Plus, they can always be republished. Once we get 10,000 strong finally revised articles, we just click Print and Wikipedia:1.0 finally becomes a reality. -- Zondor 06:56, 7 December 2005 (UTC)
This is what I envisioned with this, too. Are we going to try to establish "stable versions" of every article in full, though, or are we going to only work on print-sized segments of articles likely to be included in a print distribution? I suspect the latter would be of more use for a print edition and would scale much better, enabling us to produce a much more accurate final product. Ambi 10:28, 7 December 2005 (UTC)

(unindenting for space)

I agree that free editing of the "release version" defeats the point. Instead, it should be protected against all editors except for a small set of "owners" who contributed significantly to the original article and can be trusted. These people would be advised of the type of changes that are acceptable for a release version, such as spelling/grammar fixes and accuracy problems. Suggested changes would be noted on the talk page, and owners would seek a consensus about whether the changes are appropriate. The person who organizes the release (an administrator) would select the original owners, and the owners would have the power to add new owners. It could be tricky though to avoid a situation where a camp representing one viewpoint gains political control over the change approval process. Deco 22:21, 7 December 2005 (UTC)

I want to stress that it's not sufficient to republish the article, because while the working article might have additional corrections, it is also likely to have new content or reorganization that has not been reviewed as thoroughly as the content of the release version (as it should - that's the purpose of the working version.) It may be desirable to copy some fixes from the release version back into the working version (or vice versa), but this may involve nontrivial modification of the changes due to content drift. Deco 22:53, 7 December 2005 (UTC)
  • Branching in this way is much more like what I've been thinking and I think it has the potential to be much more valuable. The idea's could be combined though and we'd be able to see which offers more value. The idea would be to have the wild open branch, a stable branch and a released version. If anyone knows how FreeBSD's branches work, this will be really clear. The released version would be what this proposal is currently focused on. One, unchanging page that is only replaced by a later, better version. The stable version would be editable by trusted editors only, and trusted would be figured out later, but be limited to editors that have shown they make good edits. Good diff functions between the freely editable version and the stable version should be able to make keeping them in sync fairly straight forward. This means there is always a trusted version available to the reader, and they have the option of whether they want to see the newest material, a checked over one with the newest material, or a recently picked locked version. I believe if done right this could be the missing link between Wikipedia's current poor state on average and the level of respectability that a project like this could get to. What this stable version offers:
    • Still up to date and able to improve quickly
    • No vandalism. Only registered, trusted editors can edit it.
    • No revert wars. Anyone revert warring immediately loses their trusted status.
  • I believe the current system cannot get most articles to a truly high level, but a system with additional methods like this could. I don't think just having a single locked version will do enough. - Taxman Talk 20:26, 21 December 2005 (UTC)

Variant on the branching idea

We could establish a "stable versions" namespace; at any given time, Stable:Foo could refer either to nothing or to one version of the article Foo. In the absence of controversy, any administrator could establish a version as stable, or move forward (but probably not backward, which would usually mean controversy) what version was considered stable. In the presence of controversy -- that is, lack of consensus as to what version is stable -- I would argue that, by definition, there is no stable version. As usual, it's hard to say exactly what constitutes consensus, but that is no different issue here than everywhere else on Wikipedia. We'd need some sort of polling process (a la WP:AFD or WP:FAC to deal with controversy. -- Jmabel | Talk 22:41, 9 December 2005 (UTC)

I see where you're getting at, but I don't really see much benefit in doing so. The "stable version" would be only the tiniest bit more reliable than the live encyclopedia, yet it would take quite a bit of work to create and continually keep updated. Ambi 02:38, 10 December 2005 (UTC)
I'm rather interested in this process in order for it to reduce the amount of work, not to increase it. I am hoping that the time saved in dealing with mediocre edits more than makes up for the time spent declaring a stable version. Right now, I spend an unhealthy amount of time reviewing minor edits. I could be a lot more productive if I were to review only major edits, less often. I am hoping that with a good "stable version" policy, it will be easier to create good articles, not harder. linas 02:52, 10 December 2005 (UTC)

Two things came to my mind from my experience. (1) I think no one would disagree that some sort of branching-support is ultimately needed. Many problems in wikipedia seem to be related to a poor revision control. A particular one I frequently face is that some people like to stabilize articles as much as possible in terms of factuality, style and etc. They thus dislike people (namely ones like me) who add half-barked materials like incomplete proofs or demonstrations or somehow experimental elaboration of a topic, which might not work in the end. When I just want to put some draft, I couldn't care less about the format or English grammar. But I know that irritates some other people. This happens because people are seeking different objections in the same branch. The branching support should eliminate this problem effectively. (2) The need for the accountability is absolute, and many commenting here appear to be missing this. Wikipedia has been, indeed constantly, criticized for the lack of accountability. We can try to do the best job in accuracy, that's ok; we here believe that wiki is the best way to achieve this. But the accountability is a different matter. There are people, ones like librarians I think, who need some old-style assurance; the "explicit" notice that the article was peer-reviewed and verified and some people or institution does guarantee what the article says is true and if not you can sue them. You think we don't want this? I don't think so; an encyclopedia has to be equipped with this kind of assurance not wiki-assurance, which may suffice to many like me. -- Taku 14:08, 10 December 2005 (UTC)

How, though, do we go about achieving this? Ambi 00:33, 11 December 2005 (UTC)

Well, I thought that the idea is that this project can help. First, Having two versions, when the article becomes long, complete and frequently edited, is a good starting point for more sophisticated branching. Secondly, if the page is protected, at least that guarantees that the article does not contain any error that is not spotted by wikipedia editors. (That is, the stable version addresses one primary criticism that anyone can edit an article in wikipedia) In short, this is what the project page says. I have, however, one constructive suggestion that I think is unmentioned so far. Articles in wikipedia are usually checked by a number of users using watch list or recent changes or user contributions. This fact, however, is not necessarily apparently to outside people. Thus, we can make it this more explicit. In particular, when we extract a stable version, some qualified person like one with Ph.D., among contributors to the article, put his name to say that he assures that he or someone he trusts read and fact-checked the article. -- Taku 22:37, 11 December 2005 (UTC)

Well, since this is information about the article rather the the topic it more properly belongs on the talk page. I agree that having two versions helps.
Protection would work okay, but any changes would have to go through an admin then. In the short term, a good way with dealing with this might be to have some kind of "request for changes to stable version" page where people propose and debate changes to stable versions in a public forum. Admins could watch the page, close out debates, and enact the result, just as on AfD. In the long run, I think this forum would be swamped and we'd need something like the "article owners" feature I described above. Deco 00:53, 12 December 2005 (UTC)

Certification

FYI, There is a proposal at User:DavidLevinson/Future involving certification of articles by "individuals", "clubs" and "leagues". The quality of the article could be judged in part by the reputation of the certifying club, and vice-versa: the reputation of the club follows from the quality of the articles it certifies. Different clubs might use different certification processes (e.g. one club might use the current WP:FA process, another club might use domain-expert peer review, and a third some anti-elitist npov policy). linas 20:27, 15 December 2005 (UTC)

Article validation feature "going live soon"

FYI, see meta:Article validation feature which is going live real soon! There seems to have been little or no discussion of this feature, and the demo is also hopelessly confusing at this point. However, it seems relevent and possibly central to this discussion. linas 22:14, 15 December 2005 (UTC)

This looks like a really great tool for fighting vandalism and other bad changes, which is also a motivation for stable versions, but in my opinion stable versions (as I imagine them) still solve an important problem that article validation does not: in the stable version of an article, new and unpolished "rough draft" content which has not been edited for style and fact-checked is never present. In a working article, it's necessary to have changes that in the short term detract from an article until they're "cleaned up". Any change to a stable version not only undergoes great scrutiny, but changes with substantial "risk" of detracting from the article even in the short term would be disallowed entirely (such changes would only come in with the next "release" from the working version). Deco 02:17, 16 December 2005 (UTC)
Yes, but how does one "pick" which version shall be the "stable version", and isn't "article validation" just another name for "picking the stable version"? linas 17:45, 16 December 2005 (UTC)
Hrm, maybe I'm confused about exactly what article validation does. I have to look at this some more. Deco 21:34, 16 December 2005 (UTC)
Okay, after looking further at this I better understand article validation. Article validation allows users to rate a particular version of an article. New versions which have not received a sufficient number of positive ratings are not displayed by default. Users have the choice of seeing the latest positively-rated version or the most recent version. This seems to be very similar indeed to the original proposal discussed here (without branching). Deco 23:26, 16 December 2005 (UTC)

Related discussions on article validation

I just discovered meta:Article validation proposals which offers up 32 distinct proposals!! for how to validate an article. I am taking "validate an article" to be a synonym for "pick a stable version". Given the number of proposals there, coupled with the general vagueness as to how to pick a stable version here, leaves me wondering how we'll make forward progress. linas 22:43, 15 December 2005 (UTC)

When I started this project page, it was called Requests for publication - picking articles one by one for quality check by consensus. People have decided to mercilessly transform it to some other preconceived concept of stable versions. -- Zondor 00:43, 16 December 2005 (UTC) -- Zondor 00:51, 16 December 2005 (UTC)

OK, this comment, and Deco's comment above leave me confused: In order to "publish", one must pick a "version" to publish. I am presuming that the version that is picked is the "stable version", and that the process for picking the "stable version" is the process of "article validation". Am I wrong? If these are different concepts, then can someone explain the difference? In particular, how can one "publish" without "picking a version" and "validating that version"? The discussion is mutating because there hasn't been a particularly clear statement of what the discussion needs to be about. linas 17:41, 16 December 2005 (UTC)
Sorry, I'm being confusing — I have a somewhat different concept of stable versions from the original author. Please ignore me. :-) Deco 21:37, 16 December 2005 (UTC)

A thought re voting

I like the idea of having users vote on whether an article is good enough to call "stable". However, sockpuppets and such could be a problem. I recall that when we elected the current board, only registered users who had made some number of edits (400?), going back for a certain length of time, were eligible to vote. (Not sure of details, can't find the page.) Some such qualification for voting on article stability would not burden most legitimate editors, but would create a difficult hurdle for vandals. Tualha (Talk) 10:51, 18 December 2005 (UTC)

A very anti-wiki policy

I think this a policy that goes against the spirit of Wikipedia and that will probably do more harm than good. Neither of the two models proposed are beneficial. The first one is quite unpalatable for Wikipedia, particularly the notion of protecting articles once they are completed. The second one, where the stable article would be placed at a different namespace or subpage causes confusion, as there would be two versions of the same article. I think this whole argument has a false premise - that Wikipedia somehow tends to becoming a completed, final work. We haven't worked here as volunteers to complete an encyclopedia that will then be locked and published. Rather, Wikipedia is designed to always stay open, both for minor changes and updating, but also because there will never be a truly perfect article. For this reason, it is very important that even once articles are featured, they remain open to change, and not only for updates. As new contributors come, they will make them even better. I think this is what has made Wikipedia so successful in the past - this collective nature of work, this constant refinement, etc, and continuing to do so is important at any price. I think vandalism hasn't proved to be such a destructive force that we can justify applying this very anti-wiki policy. Ronline ✉ 09:28, 20 December 2005 (UTC)

I don't have a problem with it. IMO, we do need a stable revision. It won't effect the main body of work, surfers will still see the most up2date version. - Ta bu shi da yu 10:09, 21 December 2005 (UTC)

This is the typical respond from those who are opposed (not personal),but why not make an suggestion also? I think it's naive to think articles only get better,only looking at Feature article removal canidate tells a different tale.

Not to mention that when someone clicks on an article they don't know that the version they are looking at is vandal free.They can't assume the data they want to use is checked and safe.Of course a paper encyclopedia can have errors too,but at least their page can't be factually destroyed at any moment.Vandal patrol is nice,but when someone vandalises a page and some student loads the page a second later,the patrol is powerless.

So as is wikipedia will forever be a bunch of text written by people who like to write about stuff as a hobby,but it will never be USEFULL information source.As a result the "encyclopedia" word should be removed.

Or should it?One of the goals was to make a free encyclopedia.So something that contributes toward this can't be against the project.Some flexibility will be needed and rejecting every proposal without making a counter offer that's reasonable isn't the way to go--Technosphere83 10:43, 20 December 2005 (UTC)

I think it's very clear what my suggestion is: abolish this policy and maintain the status quo :) I admit that once an article becomes very developed, there is a probability that it worsens, but I think by simply watching it, that chance can be reduced significantly. However, I think the potential that an article will be either updated or improved is much greater and much more useful than the chance that a potential change will cause problems. The point of whether an article is good-quality or not shouldn't be dealt with under the stable versions policy, but by the validation policy. Yes, I support informing users that a certain article has been featured and verified for accuracy. That is why I think that it's important to inform readers on the actual article if an article is featured. However, I don't support taking that further and basically locking articles or creating duplicate versions. The main point I'm trying to get at here is that in a free encyclopedia, just like in a free society, there is a downside. There is a cost for freedom, but I think in the case of Wikipedia, just like in the case of a political system, it's worth it. I think we've got to accept that vandalism will always be a problem at Wikipedia, but instead of trying to go against the very founding principles of the system in order to combat it, we should simply be paying more attention to patrolling it. If I had to choose between a vandalism-free encyclopedia and an encyclopedia that is ever-richer and ever more updated, I'd definitely choose the latter. That's why I've come to Wikipedia - and use Wikipedia as a reference frequently - and not to Britannica and Encarta. Ronline ✉ 10:58, 20 December 2005 (UTC)


Hah,that's the point you CAN'T use wikipedia as a serious reference at the moment,because even if there is this (nobel) patrol they can't ,and I repeat, can't help when someone vandalises a page (in the worse case factually) and a user loads the page a second later.At that instant the damage is done.The user (let's assume it was a FA) thinks he can thrust the info while he's actually using false info.

I don't care if someone vandalises a page with "my cock is bigger than yours",because that is an obvious case of vandalism,I'm much more worried of vandals that tamper with facts.These vandals make wikipedia unsuable.Even if it only is a potential problem as long as I don't know if I can thrust the loaded page,wikipida will remain a nice idea that never really worked. --Technosphere83 13:02, 20 December 2005 (UTC)

  • "I don't care if someone vandalises a page with "my cock is bigger than yours". Good, 'cause I've been meaning to do that for weeks now... </joke> I'm No Parking and I approved this message
Well, in practice maybe that argument in applicable, but I can tell you from experience that I have used Wikipedia extensively, both for personal information and for research, and never so far have I made fun of myself by using false facts from Wikipedia. Ronline ✉ 09:59, 21 December 2005 (UTC)
I was interested in Cold fusion, it turned out, that it is currently heavily disputed. In the past, it was a featured article and I would have liked to view it's state at that time, but currently this requires a lot of digging through the history and is only possible for those who know enough about wikis. A stable snapshot would have been very usefull. Markus Schmaus 07:41, 8 January 2006 (UTC)
On this specific point, a suggestion was made a few weeks ago to link to the promoted version in the FA tag. This was only partially implemented; the Talk page FA tag on recently promoted articles includes: "a current or previous version has been identified" where "version" links to the history page (like clicking the History tab). If it went all the way and linked to the promoted version, there would be one low-impact, effective solution to ID-ing FAs after time has passed. --Tsavage 22:23, 20 January 2006 (UTC)

Ronline, you might be a little too optimistic about the quality of our articles. Take the recent RfC concerning Roylee, for example. This user has been editing lots and lots of articles, adding authorative sounding bits that actually were of the worst pseudo-scientific kind. He largely went unnoticed. The real problem is that you can't really say that this is an exception; at present, we simple have no way of knowing that. — mark ✎ 10:41, 21 December 2005 (UTC)

That those problems went unnoticed means that none of the editors editing the article knew enough to spot the error. How would splitting the article into a stable and working version help this? If the people editing the article don't have enough knowlege, neither will the ones voting to make it a stable version. Noticing problems like this relies on having many editors with enough knowlege about the subject. This can be accomplished by increasing the number of editors. Placing restrictions on editing and adding delays for the main results to appear on the main version of the page will probably have the opposite effect. Amaurea 09:08, 28 December 2005 (UTC)
Going back to address this argument, the important thing about stable versions is that they stop the in-flow of new facts that need to be fact-checked. If the article stands still long enough, eventually someone knowledgable will notice the error in the stable version and it will be corrected. Once this is done, the stable version is inequivocably more accurate than before. As long as new stuff is arriving, knowledgable people simply can't keep up - they're very busy people and there's a lot of articles to inspect. Deco 02:34, 6 January 2006 (UTC)

Different proposal

Is it possible to have an extra tab "stable version" that has the latest agreed version of an article?This would mean that the main article would still be edible but the last "reviewed" edition of the article would be displayed on the "stable version" tab page.

I've come to understand that, although I might be wrong here,when you use a link of a version in the history you don't need to lock the page because you can't edit it anyway.

This would however make it impossible to make error corrections,so an article that goes up should be well checked.Even so the chances in theory could be made much faster than a paper encyclopedia. At the same time it would remain in the spirit of "wiki",because the actual article is still edible. --Technosphere83 10:54, 20 December 2005 (UTC)

But you see - that would be basically paying lip-service to the open nature of Wiki. It's like telling people: you can edit an article, but all your edits will have to be reviewed by experts before the article gets published. Having two versions of an article defeats the purpose of wiki, aside from making it much more confusing. Once you implement this policy, everyone will go straight to the stable version. And, for someone's edits to make it to a stable version, it has to go through a rigorous process. So, in practice, Wikipedia becomes sort of like Nupedia - a peer-reviewed encyclopedia rather than a truly free encyclopedia. I'm making a plea to everyone here - please remember of the origins of Wikipedia. We started out as a truly free encyclopedia, and it's been that absolute freedom - that anyone can edit the encyclopedia - that's made Wikipedia so successful. Imposing boundaries for the sake of trying to combat vandalism due to media coverage is not only a grave breach of the founding principles of Wikipedia, but would harm our sustainability in the future. Thanks, Ronline ✉ 11:03, 20 December 2005 (UTC)
I very strongly agree with this view in its entirety. If I may add, there seems to be a fundamental split in the community in what "encyclopedia" means, or more precisely, in who confers the ultimate status of being a "real encyclopedia". In fact, Wikipedia is already a real encyclopedia, developed and functioning according to its own rules that are radically different from any other encyclopedia, and yet that result in a product fully comparable with other recognized encyclopedias. With all this talk of quality, the celebrated Nature expert scientest peer review, published only a month ago, pointed out that, in 40-odd selected articles on science topics, WP is comparable with Britannica. Yet, there seems to be some need for an extra "approval" that I don't quite get. Many people, myself very much included, profitably use WP on a regular basis, and have been for months if not a couple of years. It is working. In many instances, it is by far the best place to get a quick overview of a topic (any topic) and pointers to further research, whether that be by identifying relevant terms to further check out, or in references (print and otherwise), or in direct web links. The vetting process for any sort of separate stable version is going to be very complicated, inevitably quite arbitrary, and has the very real potential to turn a dynamic, functional, modern, digital, distributed encyclopedia into a imitative static version of existing print-bound publications. It is dangerous to mess with essential nature, especially when it is a radical concept that works. "Anyone" is a very powerful concept that shouldn't be diminished. --Tsavage 22:32, 20 January 2006 (UTC)
Quoth: Once you implement this policy, everyone will go straight to the stable version.. Exactly. Which is precisely why it's necessary, if the primary intent here is (as Jimbo and company routinely remind us) to serve the world rather than foster some sort of club. Any entity (commercial or otherwise) that willfully ignores the needs of its customers is doomed. Let's not be doomed. Jgm 23:14, 20 January 2006 (UTC)
IMHO, that's another potentially polarizing, and fundamental, view. Contrary to a "customer-focussed" strategy, which put another way, is essentially an us-and-them scenario, I believe that the editor is the user. This is not a romantic notion. I found Wikipedia as a user, and "became" an editor because I could, it was a natural extension of...being a customer, enabled by the software and whatever I saw as embodied in "anyone can edit". The two for me are never going to separate. However, in becoming more involved, at different periods, I do quite of bit that is outside of my direct user interests. The precise reasons for this aren't quite apparent to me, but it definitely has to do with a rough equality and a direct connection with the dissemination of information (maybe the "thrill of editing a high-traffic page", but I think more than that, the feeling of being able to make a difference, to have my vote count). Remove that, reduce that greatly, and I become not an editor, but a volunteer worker. Might as well just have an entrance exam, where you get assigned a security/expertise level and whatever tasks and privileges that go with it.
This is not a strong emotional overreaction, because what I see in this discussion is mainly broad (emotional?) concept, and I don't mean lack of a functional plan, I mean, there is no (re)statement of WP position or principle around "stable version", only proposals for core changes to infrastructure and policy based on things like: "it's an encyclopedia, not a club", "it's about the user", "the Founder says"...it sounds more political than process-oriented. I understand the goals, but I don't see any hard fact-based, thoughtful reasoning. Everyone here must have access to much more data than I do, because I've watched a core of maybe 50 articles for two years, some of them quite controversial and with their periods of...strife, and without exception, they've only gotten better. Do we have some examples, like 1,000 or even 100 selected articles, chosen for "importance", "controversiality", "volatility", that have been (are being) monitored over a period of...three months, six months, a year to see what actually happens to them? If the walls are crumbling, or even if this is simply the next positive evolutionary step, what exactly is it based on, what is it fixing, what exactly will it improve? --Tsavage 01:14, 21 January 2006 (UTC)
This "different proposal" is very similar to a (later) suggestion that I have made. If structured properly it would resolve the problems of edit wars, vandalism, article quality and provide a definite edition for each published version of an article. The walls are not crumbling but they could be improved. loxley 13:18, 21 January 2006 (UTC)
There already is a review system,2 actually.You have Featured article canidate and featured article review.I don't think this would be anymore confusing for the reader than the rest of wikipedia to be honest (talk page/wiki concept/creat a page/categories/etc..).

I also doubt that everyone would jump to the "stable version" seeing as the editable version might be more up to date.But people who would actually want to use the information would be glad for a "stable version".My proposal also doesn't go against the spirit of wikipedia at all.People will still see the editable version first and just have an extra option.A good option might I add. I really don't see why you could be against this middle ground.

This has nothing to do with the media btw,this has more to do with the nature of wikipedia and although it's nice it also has it's pitfalls.What future btw?As a blob of text?Because without giving the reader at least some means of credibility that's all it will ever be,a blob of text. --Technosphere83 12:53, 20 December 2005 (UTC)

The only way I would support stable versions is if this structure becomes a notification and nothing else - i.e. pages which are stable would have a notice on them saying they are stable, have been extensively reviewed, etc. I think this would solve the problem of trust, since people would trust versions declared to be stable. However, stable versions should still be fully editable. I will never support anything that seeks to curtail the open editability of Wikipedia, since that goes against the encyclopedia's principles. Ronline ✉ 13:08, 20 December 2005 (UTC)


How can you call it a stable version,when a second later someone can change let's say the date of a battle?

I'm not even proposing something new here,anyone in theory can already look up the "stable version" with the history tab.The ONLY thing I'm proposing is having an extra tab that is an easy way for a user to ACCES the last stable version in the history of the page.Really it is already there,it's a bit hypocritical not to give a user an easy way to acces it.--Technosphere83 13:14, 20 December 2005 (UTC)

"Making" a stable version is easy,they only thing it has to abide to is that the facts are correct.It doesn't have to be FA or anything.Take a article check the facts,paste the link to the "stable version" tab and call it a day.As long as the fact's are good the "stable version" can shift daily.Not to mention the editable article is still the center piece.The only thing that this proposal hopes to accomplish is adding some credibility,which wikipedia frankly lacks and will always lack unless something is done.--Technosphere83 13:31, 20 December 2005 (UTC)

The difference is that it's open to misinterpretation. People might think that the "stable" version was approved by an expert. People already rely on Wikipedia more than they should. I think that your proposal would add a false sense of credibility, which is worse (especially from a legal viewpoint) than saying up front, "hey, we can be edited by a 4-year-old and no one will notice." Diphyllobothriasis went for 8 months before I noticed that vandalism made it through the cracks. Dave (talk) 03:26, 21 December 2005 (UTC)
Yes, that's a good point as well. I've said all along that Wikipedia needs to come to terms with the fact that vandalism will always occur, but we also need to understand that we can still build a damn great encyclopedia even if there's vandalism, and that we have an excellent series of principles and structures - such as openness - that are worth being kept despite the vandalism. And I don't know why people expect that more rigorous peer review will get rid of the problem. So far, a lot of people vote for featured articles by looking at them for two minutes, seeing if there are nice pictures, a comprehensive structure and references, and then vote for them. Ronline ✉ 07:46, 21 December 2005 (UTC)
Ronline, you are well intentioned, but misplaced. Vandalism doesn't need to always occur, and we don't need to come to terms with it. At least not in the way you think. No one ever claimed that being radically open was Wikipedia's most important principle. Building a free (libre) encyclopedia is. The Linux kernel is free and it, like anything else released under the GPL will always be free. Wikipedia would do well to emulate that. Having a stable version won't make the information any less free. What we need to see is is there a way to combine the best of both worlds? I think there is, and some type of stable version may be it. What you fail to take into account is how many qualified experts never become editors or don't stick around because of the crap we put up with on a regular basis here. We need more qualified experts, not just anyone. If there is a stable version that is shown by default to the public, but a freely editable version on the backend, Wikipedia is still free to contribute by all, but the public version doesn't have to put up with vandalism. Good diff functions would make integrating the improvements into the stable version relatively simple. If trusted users were identified to keep the stable versions updated, then many of the downsides of the current system are gone, with a few good upsides. The cost is likely much smaller than the gain. What you have to reallize is that what worked when Wikipedia was a mostly unknown site will not necessarily (and in fact probably will not) work forever. Not all processes scale, and we're seeing problems all over the place. We can have the best of both worlds, and it's going to require change. - Taxman Talk 19:52, 21 December 2005 (UTC)
Correct me if I'm wrong, but I have always thought openness is a core principle of Wikipedia. And intuitively, I dislike the idea of working with 'trusted users' and (at least implicitly) 'non-trusted users.' It sounds like hierarchy, and to me that's something Wikipedia certainly isn't about... Larix 09:26, 27 December 2005 (UTC)
See below. Free information is the goal, not free editing at all cost. - Taxman Talk 13:22, 27 December 2005 (UTC)

Oh well,I guess it's impossible to at least get a fact checked version (the single most important thing for an encyclopedia).I guess I'll give up since there seems to be this fobia against anything that offers some credibility.wikipedia will remean a great place for a lot of text,just not an encyclopedia.In essence this means the links below an article are more important than the article itself.So why bother writing aything anymore.Wikipedia the free link collection would be a better name.They have a name for thrue freedom in politics it's called anarchy even liberals know this --Technosphere83 10:41, 21 December 2005 (UTC)


Another thing,at one point all the good editors will learn this the hard way and will get tiered to contibute to something pointless,because their work will get reduced to crap in the end anyway.This "patrol" is like some real-lifeDon Quixote.Guarding 800.000 articles,give me a break.

To illustrate my point :

"I humbly suggest that this policy proposal be linked with the proposed Wikipedia:Stable versions. In my neck of the woods (mathematics), we've got maybe a thousand articles (out of 12,000) that could be marked as "good", but I am exhausted by the vandalism patrol needed to keep them good. For example, gravity: every science-punk high-school snot thinks they can "improve" this article, and the result is a horrid mix of genius and utter crap that no one wants to maintain. Slapping a GA label on it helps no one, as it will continue to be vandalised, and I'll still be exhausted trying to patrol it. I want a mechanism that will allow me to focus on writing and editing, instead of patrolling.linas 20:51, 15 December 2005 (UTC)"

http://en.wikipedia.org/wiki/Wikipedia_talk:Good_articles#Link_with_Wikipedia:stable_versions

It might also be a great idea to read signpost #50 because it seems a certain person argrees,that change is needed.

In the end no matter how "free" it is,if the goal of wikipedia in the long run is wasting time,bandwidth and money(contrubutions) than it is completely pointless. --Technosphere83 19:27, 21 December 2005 (UTC)

It's inevitable

It's clear to me that we must do something along these lines. No matter how we try to rationalize it (and it's been rationalized in various ways since day one), the central objection that people have to Wikipedia as a serious (that is, usable) reference remains, and has recently proven real. No matter what checks and balances we have, no matter how quickly vandalism, misinformation, and subtle POV-injection are reversed, the fact that they occur and that there is a finite possibility that a user will view or download that version of an article makes the current model unworkable.

I posit that we must take a cue, once again, from the software model: many shareware and freeware distributors do quite well with parallel "stable versions" and "beta versions" of a given program. That is, the creation of a stable version article need not preclude future edits -- the stable version isn't a lockout of work on the topic, just a well-vetted, consensus-built stopping point that can be used with confidence. The beta or "live" version of the same page exists in parallel -- I imagine simple cross-links and page-type descriptions would do the trick here -- and, when appropriate (that is, when significant improvements have been made and the resulting article re-checked by whatever process is put in place), the stable version can be updated with the live version. If you try to edit the stable version, you are simply re-directed to the edit page for the live version (with appropriate explanation).

This process maintains the spirit of Wikipedia while avoiding so many of the problems we currently face. In any event, all the whinging about "unwikiness" is a sign of another problem we have -- a focus on the supposed needs of the "community" rather than the needs of the Wikipedia user. An encyclopedia or other reference isn't anything without an audience, and making the process work to the benefit of the user, rather than ourselves and our wiki-feelings, ought to be the focus here. Jgm 01:53, 22 December 2005 (UTC)

Let me add, in response to someone above who worried that a "stable version" would be interpreted as having been fact-checked: in a system where we define "stable versions", they absolutely should be fact checked. A beautiful side effect of such a system is that it promotes a type of Wikipedia contribution that is almost impossible to do properly now and that remains a gaping chasm between Wikipedia and a "real" reference: the vetting and fact-checking process. Jgm 02:00, 22 December 2005 (UTC)

I just want to add that while I agree with these general ideas, I still think it's important to allow editing of both versions. In software, there are milestones, freezes, and increasingly strict requirements for changes over a lifecycle. We can't (or at least don't) enforce that here, and consequently some articles simply won't tend towards a stable version — corrections and additions of new content will be intermingled for all time. With the ability to edit both versions, we can apply relatively "safe" but important changes to the stable version without having to clean up all the new content in the working version first. Deco 02:22, 22 December 2005 (UTC)
When I have multiple versions of a paper for class, I invariably screw it up and get out-of-sync versions, which creates big headaches for me. And that's just one person editing one paper. Multiple parallel versions of nearly a million articles edited by ten thousand people (many of whom are unfamiliar with the project) would be impossible to keep track of. I don't know a whole lot about open-source software, but it seems to me that given the way our mission differs from Linux's, we don't want to end up with a "Red Hat Wikipedia" that is edited separately from the "Debian Wikipedia" and so on. Ask someone on the Spanish Wikipedia how well they keep their project synchronized with Encyclopedia Libre, and I think you'll see why this is a bad idea. Dave (talk) 02:31, 22 December 2005 (UTC)
Not if edits to the stable versions were strictly controlled and limited to a select group. When you write a paper you have rough drafts and final drafts, which are much the same idea - would you want your professor reading your rough drafts? This isn't about different "flavors" of Wikipedia, just a stable version and a working version for each article, with most edits being to the working version and only a few "emergency" edits to the stable version (or some of the proponents here prefer no edits to the stable version, but either way would be better than what we have). Deco 02:44, 22 December 2005 (UTC)
I was primarily responding to Deco, who said that "it's important to allow editing of both versions" and talked about software development. Dave (talk) 02:56, 22 December 2005 (UTC)
There would never need to be more than two clearly-distinguished versions of any given article - the most recent stable version and the live/beta version. The Wikipedians can still work to improve the live/beta version (and, when it is clearly an improvement and well-vetted it can supplant the current stable version) while the user has the choice of using the stable version with confidence and/or checking out the live/beta version with possibly more, better, or more recent information but also slightly more risk of inaccuracy. Everybody wins. Having two versions generally-editable makes the problem worse rather than better, and allowing editing by only super-users to edit rankles the wikilove crowd. I'd propose that changes to the stable article have to be done via the live version, with an expedited process to reset the stable version when required. Jgm 14:11, 22 December 2005 (UTC)
I'm ok with rankling the masses. Sometimes things need to get done even if they are unpopular. Having both versions editable, but the stable version only by trusted users offers huge advantages in timeliness and stability as elucidated in earlier sections. Having good diff functions between them should be able to make it easy to sync improvements. Besides, there's no downside to having an additional tab that someone can click on to choose the stable version. I believe that would quickly, and widely become the chosen one that people looking for information would go to. - Taxman Talk 15:35, 22 December 2005 (UTC)
I agree. Using the software analogy again, many version control programs have a specific feature for merging changes between branches. We already have diffing - just imagine a big button on the diff results page that says "Merge these changes into the stable version and preview" or "Merge these changes into the working version and preview", depending on which one you're looking at. Text merging tools work relatively well and any unsuccessful part of the merge can be cleaned up before hitting Submit. Deco 01:15, 23 December 2005 (UTC)

The current version was never workable or at least it doesn't scale well when wikipedia grows and it's already a big boy!Featured article review is in the same boat,it might still be workable today,but when you have 2000 FA's few will ever get a timely review.

The current model is one that is in flux at every time and the sad thing is once an article gets a certain quality it starts to lose that quality slowly.The new model you could compair to an arcade game.you can always play the game,but the game always tracks the high score.So a new low score wouldn't erase the amazing record.Even if an article degrates there is still a "good" version.An editor can at a later time step in and try to "outdo" the high-score.--Technosphere83 15:44, 22 December 2005 (UTC)

I like this analogy, by the way, thanks for adding it. It vividly demonstrates the mechanics to people unfamiliar with two-version setups like this. Deco 02:07, 6 January 2006 (UTC)

Coda proposal

I agree that we need a mechanism to maintain the quality of articles that have undergone review. At the same time I think one of the great strengths of Wikipedia is that articles are always subject to revision. I think there is a way to have both. I propose a Coda namespace, with entries that would be associated with every "released" article. The coda content would be displayed at the end of the article (perhaps a user-selectable preference). While the article would be frozen, the coda would be fully editable and subject to all the Wikipedia policies that apply to articles (as opposed to talk pages). The coda could share the talk page with the released article, but have it's own history.

The coda might include the following sections:

Errata

This would be a place to list clear errors in the released article: spelling, typos, incorrect dates, broken Wiki and reference links, etc.

Additional see also and Additional external links

New articles come along, old ones are merged or have their names changed, and, of course, external links are always breaking. The coda would be the place to fix things. An even better alternative might be to have each article's See also and External links be placed in the coda when the article is released, instead of in the frozen article body. There they could continue to be maintained and evolve.

Subsequent developments

Stuff like:

  • "The author died in a kiln explosion on March 4, 2007.
  • "The former president was convicted on drug trafficking charges in 2009 and will be eligible for parole in 2018."

Additional points of view or Controversy

Places where the debate can continue, again, subject to normal policy (limited space for crackpot views, NPOV presentation, etc.)

Other coda material might include new images from Wikicommon, pointers to Wikisource and, perhaps new sections amplifying point in the article.

Periodically the article might be revised to incorporate material from the coda. The incorporation of errata would require a simpler review, after which the errata section of the coda would be cleared, but the rest of the coda would remain intact. We might use software style numbering, e.g. Rev 1.02 might be the second update that just included errata. A full update (Rev 2.0) would be expected to deal with all material in the coda, at least as of some cutoff date. A template in the coda could announce that a revision was in the works and point people to the update under development.

I believe this coda proposal would require only modest Wikimedia changes and would go a long way toward letting us have our cake and eat it too. --agr 19:40, 23 December 2005 (UTC)

This is an interesting idea that of course is known to work quite well for static things, but to me it seems a bit silly that any article we post should contain known errors, when this is a web page and they should be easy to fix. I would say that things like additional see also/external links, subsequent developments, and additional POVs are quite reasonable to reserve for a new version, but simple errata and broken links should be fixed more quickly. Deco 19:51, 23 December 2005 (UTC)


The "published" article should still be open to edits by a select number of authors.The edits they may make should be very small like spelling and small structural improvement.

Any small factual chance(like a date or number) should be made very clearly in the edit summary and the talk-page.

Limiting it in this way should make it managable to patrol these "published" versions.

Bigger chances that are needed because of emergencies like grave errors that came to light or an large development concerning the topic should be dealt with something similar to speedy deletion.In this case it would be an emergency review + correction (somewhat like Featured article review,but a bit faster).A template in this case should placed on the article of course.--Technosphere83 13:36, 24 December 2005 (UTC)

Current open model

I don't think this policy would be a good idea, as it is incompatible with an idea I consider central to the Wikipedia project: the freedom of everyone to contribute. Sure there is a downside to that, but I'd prefer to accept it and stick with the open wiki model, which guarantees the freedom of everyone (accept blocked vandals) to improve an article. Larix 14:48, 26 December 2005 (UTC)

I don't think this changes that. The working version would still be freely editable. Only the release version is restricted, and this is necessary to create any kind of guarantee of quality (at all times). A more debatable question is whether the working or release version should be the "default" view. Deco 20:22, 26 December 2005 (UTC)
The working version would, yes. But the principle is that Wikipedia can be edited by everyone, and this idea gets lost if you start working with separate, ´definite´ versions. Even if they can be replaced by more up-to-date working versions. Also, it would give a signal that we don't really trust our own peer review system ourselves. Larix 09:16, 27 December 2005 (UTC)
Different circumstances require different methods. No one ever claimed radical openness is the most important thing. In fact Jimbo has said repeatedly that being a social experiment is not the primary aim and building an encyclopedia is. These romantic notions about being 100% free for everyone to contribute don't necessarily help us reach the most important goal of providing good information to everyone, in fact they can detract from it. The most important goal is free information of high quality, not free editing. - Taxman Talk 13:20, 27 December 2005 (UTC)
It's not the peer review system itself being the problem. Subsequent changes have not been through formal peer review prior to be declared usable again. Wikipedia is a wiki meaning its pages are all freely editable. Protecting pages is indeed anti-wiki and there are elements of it already in Wikipedia as necessary evil. Let's not forget Wikipedia is an encyclopedia meaning its content can't just be simply changed. So, no principle is broken. It needs published/stable/revised/frozen versions to be a genuine encyclopedia. -- Zondor 13:24, 27 December 2005 (UTC)
I am sorry to disagree with you, but I think Wikipedia owes its appeal for a large extent to the idealism of the users working on it, who feel they are in a collaborative project together with equals. Calling this idea a mere 'romantic notion' is in my opinion somewhat easy, as it's an important motivation for (I think) many users here. Larix 17:18, 27 December 2005 (UTC)
I'm just as idealistic about the freedom of information, and believe that is where the real appeal is. It's just clear that complete freedom of editing has greater and greater costs as Wikipedia gets larger. This and related proposals aim to offer the best of both worlds. Opposing the innevitable on the grounds that it is less free is unfortunate. Not only will the information remain free as in libre, even with this proposal implemented the current wiki stays exactly as free as it is, and perhaps something like this could help avoid further encroachments on freedom of editing such as the semi protection policy. You see there an overwhelming majority supported curtailing the ability of anonymous IP's and new editors to reduce the negative effects of free editing. - Taxman Talk 20:26, 27 December 2005 (UTC)
I think curtailing anonymous IP's is fundamentally different from distinguishing between 'trusted' and 'not-trusted' users, as everyone is able to create an account with a name. Therefore, curtailing IP's has no practical effect on the ability for everyone to add. Larix 20:51, 27 December 2005 (UTC)
We already have that. What do you think admins are? As an aside, I'm curious, do you just not see the major problems that wide opening editing causes, including scaring away highly qualified people, or do you just think it's all fine in the end or what? It seems you've not been around for long (with this account at least), so maybe you just haven't seen the problems or thought about the need for a fix enough yet. - Taxman Talk 22:28, 27 December 2005 (UTC)

Well this has been discussed untill faces turned blue,but other than it should be "free" no viable solution was brought up by those who don't like the new system. Let's face it "Anyone can edit" isn't always a good thing. Once a article reaches a high quality standard,contributions of people with less understanding of a topic can actually be counter productive.

The reasons why it should be completely open strikes me more like vanity of some people than actually a concern about wikipedia.This is the best compromise between open and a closed model.--Technosphere83 19:38, 27 December 2005 (UTC)

The reasons why it should be completely open strikes me more like vanity of some people than actually a concern about wikipedia. Right... I´m not sure who exactly you mean by this, but as you seem to react at my remark, I´ll assume you´re talking about me. And I don´t think I´ve given you any reason to doubt my motives. So please explain. You don't have to share this goal, but you can't expect others to support a proposal which would bring them further from there then we are now. Vanity has nothing to do with that. Larix 20:45, 27 December 2005 (UTC)


I wasn't targeting you at all.I just wonder why this is a huge problem.Anyone in the end would still have acces to editing the "stable verion" if the prove to be not of bad intend.It's not like it's new to wikipedia,not every one can move a page.I'll give an overview of the pro's and the one con.

Pro :

  • Gives viewers a version that that has been checked and can't be factually destroyed at any moment.

Even if errors remain (which is possible just look at brittanica) at least they aren't intentional or because someone will less knowledge on the topic made it NPOV or a fringe theory.

  • They are much more managable to watch and patrol.Making them only editable by trusted users,makes it possible to implement this policy :

-No major edits (only in cas of a major concern)

-Changes well documented (summary/talk page)

This will keep these pages up to date and as accurate as possible and keep the edit history from being a mess.

con :

An annon or a beginner can't edit these pages.To me this isn't a big concern,the pages in question will be already at a certain quality and people who would wan't to edit those are more likely going to be active wikipedians seeing how improving these would require major effort.Not to mention the editable version is still there,ready to be taken to new hights.If it was possible the talk page of a "stable verion" should be open for every one,so suggestions could still be made by everyone.--Technosphere83 15:10, 28 December 2005 (UTC)


The communal orientation is indeed a staple part of what makes Wikipedia successful. I would really like to make it even more successful by having Wikipedia recognised as a reputable source. Some private organisation could produce revised editions of Wikipedia for profit but is there anyone here interested in this proposal to do it ourselves? Requests for publication as what Stable Versions was originally called is very much community oriented. Letting pages be freely editable is an easy way to lure newcomers to feel special enough to contribute, but there is more to building Wikipedia than that. There are various ways everyone including anonymous users can build every bit of Wikipedia by editing, deletion, stubbing, categorising, discussing, uploading, reviewing and in particular, publishing as per this proposal. So making stable versions is something that everyone should participate, but frozen pages itself are not neccessarily less communal as the effort to achieve it is. Currently, everyone does have equal rights in influencing Wikipedia. Administrators and Bureaucrats should not be above everyone else but only given enough powers to trusted. -- Zondor 20:55, 27 December 2005 (UTC)

What version will users see first?

Will they see the stable version? The dynamic version? Both at once? How will the interface notify them that another version exists? Will logged-in users see the dynamic version while logged-out ones see the stable version?

Also, who's designing the new interface? It's really important that everything work well, be usability-tested first, etc. I'm sure a lot of top-flight designers would be willing to go pro-bono for the publicity. It would be cool if you could get Zeldman, for example. Tlogmer 17:29, 27 December 2005 (UTC)

Intuitively, it seems like we would want to show the stable version by default. The theory is that the stable version is more reliable and so better suited for public use. However, by making the working version less prominent to readers, we may discourage editors who are motivated by exposure and efficacy. It's a difficult balance. I'm not sure. Deco 19:12, 27 December 2005 (UTC)


I think the the working version should be shown first,with a template alerting people that a "stable" version is available.--Technosphere83 19:41, 27 December 2005 (UTC)

I like this for several reasons, but primarily that it's a no downside plan. Having a tab or some other brilliant idea for acsessing the stable version would allow those that want that to have it and those that don't to get the wiki. I think frozen version being accessible at something like http://en.wikipedia.org/Richard Feynman would be great. Having this frozen version available would allow quickly validating the worth of this idea. My belief is that you would very quickly see people going to that as the destination if they are wanting to actually use the information, and then going to the wiki if they want to fix something. Of course as I've said above also having an editable, though stable, branch has even more advantages. But having the wiki version the default for now is clearly the lower risk, and lower shock way to change. - Taxman Talk 20:20, 27 December 2005 (UTC)

Ronline argues that with stable versions, people will be less interested in Wikipedia as their edits won't take effect immediately for instant gratification. Still, stable versions is useful and should not be ruled out. How else can you easily get a vetted version? Therefore, the wiki version should be the most important, prominent and the most advertised for it to be displayed first. A stable version exists but only on the side where is can be easily accessible at "http://en.wikipedia.org/stable/" and from tabs. So for those who want a high quality one, they can access that rather than that from Britannica or Encarta. [1] -- Zondor 05:39, 29 December 2005 (UTC)

I'm compelled to agree for the reasons stated. But there should at least be a user preference to view stable versions by default. Deco 05:54, 29 December 2005 (UTC)

Stable versions solve the stub problem

It just occurred to me that one interesting aspect of stable versions is how they solve the long-divisive "stub problem": many wonderful articles start out as pitifully short, incomplete, uninformative articles, and it can be embarassing to Wikipedia for these to be published. In the stable versions model, a stub is simply any article which does not yet have a published stable version; the contributors are still working on the first stable version. (Stable version is maybe a bad term here; maybe "Published version" or something like that?) People who exclusively cite or rely on stable versions would be unable to use these articles, but they could still develop and be available for consumption to risk-taking readers. Deco 23:56, 27 December 2005 (UTC)

And that's supposed to be a good point? One of the many advantages of Wikipedia over other encyclopedias has been the fact that it's had such a broad range of articles, even if some of them were stubs. Secondly, I don't think that according to the current proposal there would be a way to browse through only stable versions. The default view would be the working version, while the stable version would be in a tab. So I don't see how stable versions would enable people to see a stub-free encyclopedia (if that's a good thing...)
What I mean to say most of all, however, is that it's not helpful that this proposal is being nicely clothed and made to seem as if it's not a significant change. This proposal does restrict the free nature of Wikipedia, it does erode one of our founding principles. The argument should therefore be - is it worth it? Is vandalism that bad that the Wikipedia model can't cope and therefore must be reformed? Can the Wikipedia model then be termed as a success, or not? These are the issues we should be coping with. Remember this - the big "selling point" of Wikipedia has been its openly-editable nature, not the fact that it's free to use. The Internet is a vast resource and most of it is free. Heck, even Britannica and Encarta now offer most of their articles for free. The "free as in libre for usage" also hasn't been that big an advantage - although they are copyright, Encarta and Britannica can still be used as research sources, and Wikipedia is mostly used by people for small-scale research or for informing themselves, things which are possible under copyright as well. No, what has been the amazing factor at Wikipedia - the reason why it's such a magnificent idea - is it's openly editable nature. The fact that I can go and update something as it comes about. The fact that I can write about a topic that interests me so the whole world can know as well. That is immensely rewarding. Restrict that, the reward goes away, and Wikipedia's rate of growth decelerates. Therefore, we must look at any attempt to restrict Wikipedia's freedom of editability as a major structural change, and one that would negatively undermine both the uniqueness and the success of the project. Ronline ✉ 09:04, 28 December 2005 (UTC)
Again and as pointed out below, the freely editable version will still be there. So that covers all of your objections. The rest of it you are missing the point. Freely licensed information is the real value. You can't access most of brittanica and even if you did you can't translate it to Spanish and publish it for use in South America. You're prioritizing freely editable over information quality. Who cares what the growth rate is or what information is available on the internet if it is all crap? What we need are methods to improve the information quality. I'm not sure where you got this idea that being freely editable is more important than building an accurate encyclopedia, but that is directly contradicted by Jimbo's statements. I believe that with quality mechanisms in place we'll actually be able to attract truly qualified people and the growth rate of useful information will increase. - Taxman Talk 18:03, 28 December 2005 (UTC)
I know the openly editable information will still be there! Everyone keeps on telling me this as an attempt to cover up stable versions. The point is that there will now be a stable version which will be prioritised for its quality, at least by some readers, and as time goes by, it may even become the main version. That turns Wikipedia from an entirely open encyclopedia to one only partly open. Is that so hard to understand? Freely-licensed information is of important value, sure. But more important has been open editability. Every single news report about Wikipedia doesn't mention the fact that "it's information can be copied freely" but that "it can be edited by anyone". That's what it says in the intro statement on the Main Page:
Welcome to Wikipedia, the free encyclopedia that anyone can edit.
If stable versions are implemented, only part of the encyclopedia will be there for anyone to edit. I know Jimbo believes otherwise to this, but I don't see why that's an argument. Ronline ✉ 02:00, 29 December 2005 (UTC)
Ronline, "the free encyclopedia that anyone can edit", still remains true after stable versions has implemented. What does it mean to edit? As a wiki, all pages are editable barring special ones. Stable versions are not wiki but a traditional element as part of what makes an encylopaedia. Stable versions are very much editable but not in the sense of a wiki. Anyone can edit it by supplanting it. Let Wikipedia be open and changeable as much as possible for time to come. -- Zondor 04:17, 29 December 2005 (UTC) In other words, stable versions are atomic and to edit it is to replace it. -- Zondor 04:25, 29 December 2005 (UTC) Plus, the word "edit" does absolutely not mean it should take effect immediately as that only applies to wikis. -- Zondor 04:45, 29 December 2005 (UTC)
Stable versions are not wiki-editable, and that's hence a big move away from our original principles. If stable versions become the main version of an article, or the one that's preferred by most users, that means that Wikipedia's instantly-editable nature disappears. Supplanting is of course possible, but only after a rigorous approval process. So far, it has been that instant editability - by anyone, on any article - that has made Wikipedia so unique and successful, and I, for one, don't see as major a threat that we would have to change that. Ronline ✉ 05:22, 29 December 2005 (UTC)
There is also some sort of hypocrisy in the principle that I have noticed since the very beginning when I was introduced to Wikipedia, saying that anyone can edit the articles because poor edits perceived or not are reverted and that some pages are protected. The loss/threat I see is the potential for Wikipedia to be more useful prior to implementation this proposal and many good contributers who have already turned away because of the unfriendly environment to produce accurate articles. As Deco suggests, the wiki will continue as it is where they can be bold but stable versions are to address all those problems critics have been complaining about. -- Zondor 07:40, 29 December 2005 (UTC)
Even if the stable version were to become the default view, which I don't foresee occurring, everyone still has the ability to contribute to the next version. We're simply delaying the appearance of their edits to the majority of readers for a few days, not taking away the ability to edit openly. If they do have an important stable version change, they would just need to suggest it on the talk page and somebody would verify and implement it. The efficacy of making immediately visible changes is enticing, but also intimidating: how many anons have hesitated to edit for fear of making an embarassing public mistake? Working versions encourage boldness. Deco 06:31, 29 December 2005 (UTC)

But there is still the open editable version,so infact you can still 'inform the world'.Minor chances should still be possible to make in the "stable" version by thrusted editors (which you would easely fall into with your track record).The authors of the editable version can at all times push their version as the new "stable version".Maybe we could even have an e-bay like feature were you could rate a user.If the rating reaches a certain point,he would be a "trusted user".It would be more like a reward.

You seem to be focused so much on this "free" concept that you forget one thing,that bad info not only misinforms but is actually misleading and damaging and that the world is filled with people who like to destoy others work for entertainment.

What good is a "free" source of info when you can't actually use it?You never seem to address this FUNDAMENTAL concern.Without a quality mechanism wikipedia doesn't have a purpose other than letting people type a lot of words.We don't even reach a stage were we have to be concerned about "free".

Vandalism is also pretty broad and not always intentional.When you have a great article and someone who is not much an expert on the topic as those who brought it were it is can be harmfull for the article and those who read it.

The other concern is that anyone can destroy a page the millisecond before someone loads the page.This is a deal breaker for wikipedia as a reference.

lastly,given that new articles won't get a stable version until the reach "good article" status,I think it's save to say that the majority of articles will still be as free as ever.--Technosphere83 14:49, 28 December 2005 (UTC)

Technosphere, you seem to have a very pessimistic view of Wikipedia. As far as I have been here, I have used it as an information source, both for research and for general reading. I don't think anyone can argue that it's "just a bunch of words" or that on the whole it is more inaccurate than accurate. Sure, there have been some high-profile inaccuracy cases recently, but on the whole, it is very accurate and all tests conducted on it by independent reviewers have shown that it is about as accurate as other encyclopedias. That's why I think the premise behind stable versions is wrong - vandalism has not reached a stage yet where it significantly harms the quality of the project. You asked "What good is a "free" source of info when you can't actually use it?". The point is that Wikipedia is being used by millions of people, who appreciate it and find it a suitable source. Even news articles quote it often for its information. Therefore, I think that this whole vandalism and inaccuracy problem has been overblown much too far. I hope this addresses your question. Ronline ✉ 02:09, 29 December 2005 (UTC)
For what it's worth, I don't view Stable versions as a way of protecting against vandalism and other inaccurate content, although it does that. The issue with the current system is that even if an article is trusted and reliable, it's simply impossible to expand and develop that article while keeping it completely trusted and reliable at each instant. All new content has to be refined and refactored, corrections have to be examined and accepted or reverted by interested parties, and so on. Stable versions isn't a simple defensive measure like protection; it's a relatively low-cost way of creating a second space of articles that, at all times, maintains an exceptionally high standard of quality. Currently, although all articles tend to improve in the long run, you can't reasonably expect that every article will be at least as good tomorrow at 9pm than it is today at 9pm. The ability to take high-quality snapshots is important, for one thing, for successfully moving toward a print version of Wikipedia, but also to create an additional resource for people who have a specific requirement for a high degree of quality, such as researchers. It also allows us to counter some of the oldest arguments against Wikipedia: any temporary problems manifested in the working versions can be attributed to the fact that they are "just a work in progress", and the critic should look at the stable version before they start complaining. Deco 06:16, 29 December 2005 (UTC)

What is Wikipedia, anyway?

I see this as the fundamental division here. If Wikipedia is a social construct, a community, then the idea of closing some pages to edits (even when there is a working version available) is a controversial, even disturbing one. If, on the other hand, Wikipedia is a reference, usable to even those outside the community, this idea is a no-brainer.

Of course, Wikipedia is both of the above. However, the key thing to think about is what differentiates Wikipedia from the many social websites (facebook etc.): that is, we are attempting to create something useful here. Given that, I think the guiding principle for decisions such as this has to be what is best for the user of our construct. Clearly having a Stable Version that is not subject to the most vexing vagaries of Wikipedia (subtle POV-injection, well-meaning wrongheadedness, transient vandalism) is a Very Good Thing from a user perspective and, with the availability of a Working Version, only a minor concession for the community.

Reading this entire discussion again, it seems to me we are very close to a consensus on this issue. So, what's next? Given that this would require changes to the Wiki software, we can't just Be Bold and do it; are any of TPTB watching this discussion? Jgm 23:22, 28 December 2005 (UTC)

Regarding what's next, I have solicited the opinion of a developer who will hopefully come look at this page and leave some comments. However, I'll note that we can effect a limited form of this already through the following process:
  • Look through an article's history. Grab the version you want to publish and copy-paste it into the same article prefixed with "Stable:".
  • Protect the stable article, stick a template at the top giving a timestamp, linking to the original page, and explaining the concept of stable versions.
  • Link to the stable version from the top of the original article.
It's not as nice as being able to fork the article with its history for real, and of course would require the participation of an admin for each publication or update to the stable version, but it is a viable proof of concept. Anybody want to take a crack at a good template for this? Deco 23:38, 28 December 2005 (UTC)
We can start infecting Wikipedia with this proposal by starting with small stub-like articles that are simple topics and easy to deal with like Bachelor party in the spirit of Wikipedia:Collaboration of the week. -- Zondor 01:16, 29 December 2005 (UTC)
The only issue with this is that it could take a while for a stub to reach its first stable version, since we shouldn't really be publishing woefully incomplete working versions. But it would be interesting to see how well it works over the complete "life cycle" of a growing article. Deco 02:01, 29 December 2005 (UTC)
What is the minimum standard for stable versions? As long as it has just enough information and is all factually accurate. It does not have to follow the full waterfall model but rapid development/prototyping. -- Zondor 03:50, 29 December 2005 (UTC) -- Zondor 03:52, 29 December 2005 (UTC)
I agree. Deco 03:56, 29 December 2005 (UTC)

Before we change any software, have we addressed and scrutinised every issue about editorial validation that people have come up with in the past? Meta:Article validation proposals, Meta:Article validation feature, Category:Editorial validation, Meta:Category:Article validation. -- Zondor 00:44, 29 December 2005 (UTC) -- Zondor 01:07, 29 December 2005 (UTC)

Firstly, I don't think we're close to reaching consensus here. From this page and the discussions on the Wikipedia-l mailing list, there seem to be two fairly discrete groups: one that supports stable versions and one that doesn't. We've got to recognise that. Secondly, I think a straw poll should be conducted to gauge broader community opinion (since until now, it seems about 30% of people are against, 70% are in favour, approximately - I don't think stable versions should be implemented unless a large majority - 85%+ - agrees with it, considering the structural changes it is making). Ronline ✉ 02:12, 29 December 2005 (UTC)
I agree, although I think it could be enlightening to give it a shot with a single article as a proof of concept prior to the final Great Big Vote. Deco 02:16, 29 December 2005 (UTC)
Yes, that would be a good idea. Ronline ✉ 02:18, 29 December 2005 (UTC)

There are patches more or less complete to implement essentially stable branches (see Magnus Manske's post to the mailing list), and parts of the article validation feature are ready that essentially implements the frozen or stable versions. It's more a case of see how it shakes out than getting it implemented in software. - Taxman Talk 04:06, 29 December 2005 (UTC)

Cool. Could you post archive URLs or quotes for everybody? Deco 06:33, 29 December 2005 (UTC)
Yeah, sorry, should have posted it before, but I had to find it again. http://mail.wikimedia.org/pipermail/wikien-l/2005-December/035668.html Look above for the various validation feature links. I know those are nearly complete too. - Taxman Talk 15:25, 29 December 2005 (UTC)

Doesn't quite solve the problem

I admit I haven't read all the discussion here so I apologize if other's have expressed some of these ideas.

I think that production-level articles will help wikipedia become more trusted as a resource, but this plan doesn't go far enough. It removes one of the best features of a wiki (articles can be updated rapidly as the subject matter changes) without really making the articles trustworthy. For all the average reader knows, the stable articles are written by the same people in their basements who wrote every other article and the reader has no reason to trust those people. What's needed is a change in the wikipedia culture to make users less anonymous. If stable articles are going to be successful they have to be signed off on by a committee of (if not experts) at least people with advanced knowledge in the field, say the equivalent of a master's degree. Lets say three per page. What's more, there will need to be transparency and accountability - each reviewer will have to put their real name and email address at the bottom of the page and agree to be publicly responsible for the contents of the page in the same way the author of an article in a scholarly journal is accountable for his work. What's more, the articles have to be easily editable in case something changes in the world, so I suggest that all changes be submitted to a member of the committee for his/her approval. I doubt there would be many attempts at vandalism, since potential vandals would know that their edits were going to a real person rather than just an anonymous server in cyberspace. Stable articles would have to be differentiated from regular articles in more than just the URL, they would have to appear in a completely different style or something to avoid any confusion. I think that we have the resources to do all this and that the reader base is large enough to accomplish it. An added benefit to editors is that they will be able to list their contributions in CVs because their name will be on the page and the page will be of very high quality.

This could change the way wikipedia is perceived. If, when browsing around wikipedia people start to come across articles that people with Ph.D's have signed-off on than their opinion of the average wikipedia editor will change. People will stop complaining about wikipedia not being reliable if they see that we are only claiming that SOME articles are to be considered highly reliable at the moment and that the rest should be considered in progress. It will be easier to convince people that our articles are trending towards high quality if they can see finished products. Also, if some of the most highly-vandalized articles (say Adolph Hitler for example), are put in stable release than users will be able to spend less time monitoring their watchlists and more time editing (or they'll be able to watch more articles).

GabrielF 07:10, 29 December 2005 (UTC)

Very good, whatever to increase credibility and hence the trustworthiness. It gives contributors incentive. -- Zondor 07:51, 29 December 2005 (UTC)
Gabriel, you proposal is very similar to what Nupedia planned to do. And it failed. I think Wikipedia trying to become more elitist won't do anything other than shift it away from its original goals and create an encyclopedia too tangled up in bureaucracy to achieve anything successful. I don't see the reason why we should try to emulate Britannica or Encarta, which have articles written by experts. And neither do we need time-delay mechanisms like stable versions or "review of anonymous edits by trusted users before those edits become live". It's draconian and it's anti-wiki. Ronline ✉ 08:06, 29 December 2005 (UTC)
It's necessarily harsher because creating a trusted source is something not to be taken lightly. It is anti-wiki because it isn't a wiki. I can also equally cry Wikipedia is anti-encyclopaedic as it goes against the very principle of being an encyclopaedia as a trusted source. Wikipedia has dual property - it's a wiki, yet it's an encyclopaedia. Can't the existing wiki system continue to run uninterrupted from the compliment of stable versions? -- Zondor 14:05, 29 December 2005 (UTC)
Nupedia failed not because it couldn't produce high quality articles, but because it couldn't produce them fast enough or cheaply enough. The open Wiki process has demonstrated that it can produce content of variable quality, but not that it can consistently create very many very high quality articles. In fact it's easy to demonstrate that there are many very bad articles and that many good articles degrade. Thus a new system is needed to truly lift the quality. - Taxman Talk 15:23, 29 December 2005 (UTC)
I would not, personally, create any requirement for expert review, simply because there aren't enough experts to go around, and because many "amateurs" not holding degrees, particularly graduate students, are actually quite knowledgable. I do think the stable version should have some differences in format, such as a warning that it may not be up to date and its date of publication. It may be useful to include a list of "owners" responsible for the article and changes to it, and a list of users who have reviewed the content for accuracy and believe themselves to be knowledgable in the area (self-selected). I think in time a dynamic relationship would develop between the reputations of the reviewers and the quality of the articles they review.
I would consider a graduate student or an amateur who has proven their expertise through a large number of edits on the non-stable wikipedia to be expert enough to serve as a reviewer. The important thing is that the review know something and be willing to be responsible for the article. Also, I think that if you could use a really good wikipedia article you were responsible for in a CV more expert-level editors would emerge. GabrielF 20:56, 29 December 2005 (UTC)
To Ronline: Stable versions are not a simple time-delay mechanism like anonymous edit review - especially if the working version remains the default view. They're simply an alternative version of the article which has undergone more thorough review and is protected better against introduction of inaccuracies and other problems. I expect both versions to be useful to readers, perhaps even the same readers, one for its reliability and quality and one for being cutting-edge and up-to-date with recent developments. The stable version is not intended to replace or hide the working version. Deco 19:22, 29 December 2005 (UTC)

I think its important to realise what is it that drives people to contribute to Wikipedia to do it for free. People like to edit because they like to learn. Or because you feel special that you can modify a page on a high-traffic website, but you get used to it after a while. Reviewing and fact checking is perhaps a little boring which is why they are not so prolific on Wikipedia. Its great that we have an abundance of new information, but lets focus on how to get people to do such things as reviewing and fact checking which is undeniably a critical part of what makes an encyclopaedia. Making stable versions has to have a drive. I believe only a handful of people like to do reviewing. The incentives suggested by GabrielF would help increase the number of reviewers and fact checkers. -- Zondor 04:08, 30 December 2005 (UTC)

***** The BIG QUESTION: Who decides what is "stable"/"acceptable"? *****

The unelected members listed at the m:Wikimedia Foundation organigram itself?

The unelected Developers and The Bureaucrats?

Who? This is a very important part of any proposal about "making permanant versions of all articles" (or "just the ones we like or think are suitable"). --Mistress Selina Kyle (Α⇔Ω ¦ ⇒✉) 09:12, 29 December 2005 (UTC)

Consensus, Experts and Administrators. Consensus would be a large enough number of Wikipedians that have fully fact checked the article. Experts would be great if they can identify themselves to contribute to the consensus. Administrators would ultimately make the decision based on consensus. The Administrator who publishes it has the responsibility and he or she is to blame if anything goes wrong. What do you think? Can this prevent a John Seigenthaler Sr. Wikipedia biography controversy? -- Zondor 11:29, 29 December 2005 (UTC)
Erm, Mistress, please read the page before entering into dramatics. Had you done so, you might have noticed that absolutely no one is suggesting that any of the foundation, the developers or the bureaucrats be responsible for deciding what versions are made stable. And for the record, both the board and the bureaucrats are elected. Please get your facts straight before launching into a rant. Ambi 11:36, 29 December 2005 (UTC)
Yes, I was wondering why in the world would a developer get involved in this? However, Bureaucrats have an indirect responsibility in deciding what is a stable version because they are or they should be responsible for Administrators they promote. In turn, a higher ranking Wikipedian has responsiblity of Bureaucrats for another level of indirect responsibility of stable versions and so on all they way up to Jimbo. -- Zondor 11:53, 29 December 2005 (UTC)

I think that this should be separate from adminship and that hierarchy, because the role of an editor and the role of an admin are fundamentally different. There are at least 25 people for whom admin powers and responsibilities are unappealing. I suspect that many of them, like me, would want to be able to select stable versions. I think that it would make sense for some people to specialize in stable versions the way Raul/Mark specializes in featured articles and other users specialize in RC patrol, etc., but that may have to develop organically. I don't really have a lot of firm opinions on this yet, but I thought getting ideas on the table might help. Dave (talk) 08:51, 30 December 2005 (UTC)

Publishing a stable version should be restrictive because it is susceptible to vandalism. Its almost like protection. Stable versions are still editable because someone like an Administrator acts on behalf of ordinary Wikipedians or consensus. Such requests won't be overwhelming anyway. Administrator is the lowest restrictive distinct software class of Wikipedians. Would a separte software class need to be created for publishing stable versions, protect/unprotect pages, delete/undelete pages, blocking/unblocking users and change the interface? -- Zondor 09:39, 30 December 2005 (UTC)
I have suggested the concept of article owners for this purpose, a group of users selected by an administrator based on substantial past contributions to the article who will have powers of stable version editing and publication over that article (individually, but by convention only used with consensus). This would require additional software support though and raises some social issues. Deco 10:29, 30 December 2005 (UTC)
Complicated social issues and software support indeed. I hope these article owners won't abuse their power. There is a reason why administrators go through a lengthy process to be trusted. Stable versions are not wikis and cannot be simply updated like that. Mandatory changes, not frivolous ones, can be added as errata or addendums, and/or with differing version numbers. Publishing of stable versions is not to be taken lightly - people rely on it, you know. -- Zondor 11:42, 30 December 2005 (UTC)
Well, if the errata/addendum is to be treated as "officially" part of the stable version, it's just as important to protect as the stable version itself. I wouldn't want article owners changing it around willy nilly, but there would be rules about the sort of changes they're supposed to admit and they could revert each other if one chooses to act without consensus and against policy. Such an owner would probably also be immediately recommended for de-ownership.
Regarding the sort of change that should be made to a stable version, I agree that the seriousness of the problem is one aspect, but one should also take into account the risk (spelling errors for example have very low risk to fix), and keep in mind that a stable version should ideally not make any claim of being up-to-date beyond its published date (a prominent notice supplying this information). In other words, we only fix things that would have been fixed before publication if they had been known. This will help keep it more stable. Deco 02:26, 31 December 2005 (UTC)
I can see where you are coming from with this. There is always some error that needs fixing that will always be overlooked - you can fix this quickly with a wiki. But, you need get out of this wiki-mindset. It does not have to come to the issue of reverting each other. Before paper newspapers decide to print, they doubly make sure that there are no errors. People need to realise publishing a stable version is a big deal and that there is a certain stopping point. Even if you have a publishing date, it would encourage too many changes making publishing seem trivial in which it should not. The social issues and the software support looks too complicated to have this when a speedy process that I mentioned earlier that can take care of glaring errors. This purpose would make Wikipedia high quality, but we will see how it goes if its practical. -- Zondor 04:18, 31 December 2005 (UTC) -- Zondor 04:31, 31 December 2005 (UTC)

Average End Quality Hypothesis

One of the assumptions of Wikipedia is that continual editing by multiple users will result in a continual increase in the quality of an article. This has proven true as a general trend. However, I do not believe adequate attention has been given to important exceptions, and, most significantly, to the rate of improvement in article quality.

I have done a bit of research and reflection, and I have reached a conclusion that I call the Average End Quality (AEQ) Hypothesis. It is based on the following observation:

As the quality of an article improves, the rate of improvement declines.

In other words, if Q(t) is the quality of an article at time t, then Q'(t) is positive but downward sloping, or Q"(t)<0. The graph of quality over time looks something like this:

Image:AEQ1.gif

Notice that the quality function appears to level off. This is not accidental. It is a well known fact that not all edits improve the quality of an article; some, in fact, detract from quality. Not all of these are simple vandalism that gets reverted as a matter of course. Some are subtle insertions of uncited speculation, POV, reorganizations of material that disrupt the flow of an article, bad grammar, and so on. They are not enough to have a visible effect on the upward trend of quality for new and short articles, but once an article gets very lengthy and detailed it becomes increasingly difficult to copyedit and remove errors buried deep inside the long text. As a result, bad edits are able to balance out good work and article quality levels off at a value I have termed the Average End Quality (AEQ).

Image:AEQ2.gif

Of course, editing never actually stops. The actual quality of a given article may spike above or dip below the AEQ for various periods of time. But whenever actual quality goes above the AEQ, bad editing gains an upper hand over good editing and drives it back down. Likewise, whenever actual quality goes below the AEQ, good editing gains an upper hand over bad editing and pushes it back up. In other words, if an article gets too good then most editors will declare "mission accomplished" and leave, allowing random bad edits to erode its quality; but if the article gets too bad, a large number of editors will be attracted in an attempt to fix it.

Thus, the quality of most detailed, lengthy articles oscillates around the Average End Quality:

Image:AEQ3.gif

Some might say that the AEQ is good enough, so there is really no problem. However, this property of Wikipedia results in a lot of wasted effort from editors who work hard to get the quality of an article above the AEQ, only to have it eroded down over the next few months. And, in some cases, articles that were once of a very high quality have been reduced to near incoherence. Given all this, I propose that the very best articles on Wikipedia be placed under permanent page protection. After all, the whole reason why people are free to edit articles on Wikipedia is because this policy results in an overall increase in article quality. But if we have good reason to believe that it will result in a decrease in quality for articles X, Y and Z, then it is only reasonable to place articles X, Y and Z under some sort of protection:

Image:AEQ4.gif

Such a protection policy should only apply to articles of exceptional quality, and it should not be a blanket ban on all edits; rather, there should be a requirement that any new edits must undergo some review process before being allowed. This could be the first step towards Wikipedia 1.0: At first, only a handful of articles would have the required quality to be protected, but more would accumulate over time.

I am sure this idea can spark endless controversy. Fortunately, however, it is not just a matter of opinion. There is, in fact, a very sure way to tell whether the Average End Quality Hypothesis is true or false. What articles are recognized as the very best on Wikipedia? Featured articles, of course. Let us do a survey of former featured articles and determine whether their quality has increased or decreased on average since the day they were featured. If it has decreased, then it is true that continual editing usually lowers the quality of our best articles, and therefore it is a good idea to implement some sort of protection policy on them.

Note that I am only arguing for stable versions in the case of the absolute best articles that wikipedia has produced. The ratio of featured articles per total articles is currently less than 0.001 - and since the number of total articles goes up much faster than the number of featured articles, this ratio will get ever smaller. Locking such a tiny fraction of articles will make no difference to the overall operation of wikipedia. -- Mihnea Tudoreanu 12:33, 29 December 2005 (UTC)

A couple of comments here: these are very interesting thoughts, but it's difficult for me to see "article quality" as a monotonic function; the injection of one bad fact (maliciously or inadvertently) can have a dramatic impact on the usefulness and trustworthiness of an article -- a drop of poison can spoil the well, so to speak. Also, my experience with certain articles does not actually match your graphs; for example Rock and Roll / Rock music has been a butchery after some well-meaning folks took a mostly-OK article and went overboard with sub-articles and a main article split. Finally, it's important to recognize that all the up-and-down fluctuations you picture (indeed, any change to the Wiki) represent effort expended by editors. We often find ourselves pushing the boulder halfway up the hill, and turning around only to have it roll most of the way back (I'm not talking about simple vandalism that can be easily reverted but big ugly dump-edits that require major effort to clean up, fact-check, and integrate). One side benefit of a Stable Versions process is that it puts chocks behind the boulder every so often. Jgm 15:11, 29 December 2005 (UTC)
Your analysis is similar to the sentiment of most of the experienced people invlolved in FAC and FARC. In fact it's one of Raul's laws. Featured articles tend not to improve once they are featured, in fact they generally degrade unless they have a particularly vigilant watcher or someone comes in to revamp them. It's clear then that a different system is needed to consistently bring articles above the AEQ. The current system works well to produce a mass of information, but on the whole is probably not able to take it higher. Many of the things mentioned here such as formal expert review may be able to lift the quality consistently above AEQ. - Taxman Talk 15:19, 29 December 2005 (UTC)
I don't really believe the AEQ is true in general; I believe any article can be substantially improved by the right editor, but just that it sometimes takes a while for that editor to show up. Additionally, any scheme which attempts to protect the working version will effectively prevent cooperative work on an article. If a Honduran scientist adds technical details to global warming with terrible grammar, and this is subsequently cleaned up by an American user, we have a net improvement that could not have been accomplished in one edit by either user. This is a fundamental advantage of Wikipedia. Stable versions allow these "refinement" stages to complete before publication while still giving access to the information to people who would rather deal with the temporary lower quality for more cutting-edge content. Deco 19:31, 29 December 2005 (UTC)
I think that it definitely takes work to keep articles at high quality, and I like the graphs as a way of expressing that. I agree with most of what's been said in this section, in fact. But I'm concerned that whoever the "guardians" of the stable version are will use their status and sense of self-importance to keep out legitimate edits because they overvalue their own ideas relative to other people's. Some editors have very firm ideas about their own writing styles, the needs of readers, NPOV, etc. that we might not all agree with. While the current system isn't perfect, since improvements can be reverted capriciously, at least those edits have a chance. I'm not sure what the solution is. After reading this section, I've become less opposed to stable versions. But I am concerned about this. I just thought I'd lay out my ideas and see if anything useful comes from them. Keep up the good discussion, Dave (talk) 04:25, 30 December 2005 (UTC)
Stable versions only entails protection of the stable version. It should only be necessary to edit the stable version (if at all) for small things that are clearly wrong like inaccuracies, misspellings, and broken links; anything contentious shouldn't be changed there anyway. Any other changes will be incorporated into the working version via the current process and subsequently published in the next stable version. And I stress again that the two versions should be viewed as just two different forms of the same article which a reader can freely choose between without emphasis on either. Deco 08:00, 30 December 2005 (UTC)
Right. I'm worried about the social implications of having an officially sanctioned version. People have accused me of ruling Libertarianism too tightly, because I felt like I had some kind of ownership of it after pushing it to FA status (that was six months ago... since then, I've let the article do its own thing until a few weeks ago). I'm concerned that such situations would become more common, not because of any technical limitations of stable versions, but instead because of what it will mean to the (human) editors involved. Dave (talk) 08:25, 30 December 2005 (UTC)
There will always be edit wars. If there is no consensus, then that article is not ready to be stable. If anything, it can help force the article to reach NPOV more quickly. -- Zondor 08:45, 30 December 2005 (UTC)
That's actually my concern. I've seen situations where users have used the drive for a stable version as a reason to reject good changes, and I'm worried about codifying that. Dave (talk) 08:53, 30 December 2005 (UTC)
Your concern is well founded. But however "good" it is, it could be POV. -- Zondor 09:58, 30 December 2005 (UTC)
This is an interesting point, and I've been guilty of possessiveness on occasion too, but I think the effect will be diminished compared to the drive for FA status, because there are two versions - during publication of a stable version there could be an opportunity to cut out incomplete or controversial parts, or to mix and match parts of working versions, so there's less temptation to view destabilizing edits aggressively. The way I imagine it is there could be a temporary freely editable "preprint version" that is assembled for publication and voted on. Of course one has to avoid the temptation of doing substantive editing in that version instead of the working version, but I think it could help.
As for the social implications of singling out some editors over others as owners, that is a concern. There could be a process for adding and removing owners, but considering that their "powers" would be limited to typically insubstantial stable version editing, maybe their role should be downplayed; we could call them "maintainers" or something boring like that. Deco 10:24, 30 December 2005 (UTC)
Without actual stats to demonstrate, AEQ seems like a convenient assumption: it will apply to some articles, but to how many, and for what underlying reasons? The statement above, any article can be substantially improved by the right editor, but just that it sometimes takes a while for that editor to show up, whether directly intended to or not, points to an aspect of "quality" that hasn't really been discussed here, writing quality. The fact that we are writing an encyclopedia, not simply collecting verifiable "facts" in a database (like IMDb), puts a lot of weight on how an article is written. The articles I've watched that have come up from stubs tend to be first an assembly of an increasing number of pieces of information, often with phases of discussion or debate between editors, and then things quiet down. What's left is a pretty much "everything's there" article that is readable, but is quite dry and cumbersome. At this point, I think we're "waiting for a writer". There are other, different skills and talents involved in copywriting, prose writing, journalistic writing, technical writing, encyclopedia writing than expertise in the topic. And writers tend to come along later, to reorganize, re-edit, rewrite, to produce a final, clear, readable product. (I can cite a number of recently celebrated WP articles that are simply not any fun to read, where your eyes do glaze over...) To put it broadly, IMO, the biggest difference between WP and Britannica at this stage is, in the end, their final product is written by skilled, professional writers. Stable versions must recognize this aspect of "encyclopedic" in whatever mechanism is considered to select and update stable articles, and it must allow revisions to be made freely made for writing quality, not just "verifiable information". --Tsavage 17:04, 21 January 2006 (UTC)
I think that is one of the most valid concerns I have heard.On the other hand,that's human nature and any work made by humans is vunerable to POV.I don't even think the other major encyclopedia's can work arround this.I don't think the current situation is any better now,they just fluctuate between POV's.

Like I stated before however there should be a mechanism to evaluate stable versions and change them in instances of emergencies (factual error that is too great, large amount of POV pushing,etc..)

Given that the number of edits on a stable version should be kept low,there changes should be pretty transparant. --213.224.194.71 13:25, 30 December 2005 (UTC)

I find these comments to be excellent, though I do disagree with protecting the article against further revisions and "gating" new edits on the article. That's what I think a stable revision would be good for: the stable revision would not be changable and then what you do is use that revision to try to gather just how good the previous articles were. A good example of this was Christmas, which was a very different revision on FAC than is currently. A revision marked as stable would have been a very good idea on this article, and we could have just done a diff to see what had changed substantially. - Ta bu shi da yu 09:18, 2 January 2006 (UTC)
That's a good idea. It was partially implemented a couple of weeks ago in the FA tag, but the "version" link only calls up the entire history page, it's not a direct link to the promoted version. Perhaps going throught the current 800+ FAs and putting a link to the promoted version (easily found in History) on the Talk page would provide some relatively quick and useful "data" relating to AEQ and the articles hit a peak and then slide downhill hypothesis... --Tsavage 17:35, 21 January 2006 (UTC)

Some brief comments from a developer

I got one of the devs to briefly comment on stable versions. He says:

I haven't worked on this myself but Tim Starling has, although I don't know the current status of his work. Last I knew he was only adding a boolean stable/unstable field to revision though as opposed to full branching support. I think the latter would be neat as it would allow for maintaining an arbitary number of branches for the same file like Subversion, CVS and most other version control systems support. —Ævar Arnfjörð Bjarmason 19:20, 29 December 2005 (UTC)

We may want to solicit additional comments from Tim Starling and/or from the guy on the mailing list who talked about a stable version feature he was working on. I'm a bit disappointed that the existing additions don't seem to include branching - maybe I should get personally involved. Deco 22:33, 29 December 2005 (UTC)

Maybe I'm misunderstanding Magnus' email I linked above, but it seems there's more to his work than what Ævar is aware of. You could ask him. In any case if you have the ability, please do get involved. - Taxman Talk 15:05, 30 December 2005 (UTC)

Freezing FAs is a silly idea

Sorry, but this has to be nipped in the bud. Freezing FAs removes one of WP's most valuable attributes: dynamism. Continual improvements in FAs are necessary because (1) most of them need improvement, and (2) the field continues to change after their promotion. The standards applied to the promotions procedure have risen significantly over the past six months; older FAs need to be revisited on that basis.

It's as simple as that. Tony 00:24, 30 December 2005 (UTC)

Agreed - freezing FAs is absolutely ridiculous, not only on those grounds but on the grounds that no article is perfect and new developments constantly emerge. I'm not sure whether you're implicitly asserting that the Stable versions proposal has anything to do with this, but I don't think it does. Deco 01:36, 30 December 2005 (UTC)
The point is that, on average, dynamism tends to reduce, not improve, the quality of FAs. That doesn't mean we should freeze former FAs months after they were featured. Rather, we should freeze any new FAs. -- Nikodemos 14:54, 30 December 2005 (UTC)
What? When KaDee Strickland made it to the front page it was clearly Wikipedia's finest hour. And you would deny the world the great FA that appeared that day. For shame, sir. For shame! --MisterHand 01:53, 30 December 2005 (UTC)
Are you so proud of dynamism by itself to solve everything? Why not add some extra helping hand of a stabilizer if things get too dynamic. Stability helps to direct dynamism towards the right direction. Some people prefer stability over dynamism. Simple, really. -- Zondor 04:43, 30 December 2005 (UTC) -- Zondor 05:08, 30 December 2005 (UTC)
Both are required, in good measure; that's my point. Tony 05:19, 30 December 2005 (UTC)

None of the proposals here involved freezing anything, so I'm not sure where you got that. It's more like taking stable snapshots (which come to think of it is a better name for what this proposal currently calls for) of the continually changing and hopefully improving article. The branching proposals also call for continual editing and improvment. - Taxman Talk 15:14, 30 December 2005 (UTC)

I have just made {{Editprotected}} which is similar to the process of requesting further corrections to stable articles once they have been published and protected. -- Zondor 06:39, 4 January 2006 (UTC)

I like this - as requests are addressed it can be removed so the category is always up to date with pending stuff. Deco 06:43, 4 January 2006 (UTC)

Revised version

You know, I'd like to say I have never really liked the name "stable version". I'd like to be bold and consider, for example, "revised version" or "reviewed version" or even "revised snapshot" to be better. Featured articles are considered stable articles, but this proposal is called stable version. The reason it was called stable because it was named after something in article validation (Meta:Article validation proposals#Wiki version and stable version). Its stable, meaning just unchanging as opposed to dynamic/wiki. Importantly, this proposal emphasises its more than just stable/static/frozen, its revised/reviewed/checked/1.0. -- Zondor 11:59, 31 December 2005 (UTC) Perhaps, the use of word "static" can make the MediaWiki software more general purpose for use outside of Wikipedia. -- Zondor 12:02, 31 December 2005 (UTC)

I don't like the words static/frozen/snapshot, because they imply it can't be changed (although some proposers think it shouldn't be, I think it should just be seldom and insubstantially changed, which makes "stable" more accurate). I don't like the word "stable" either though, because it overemphasizes the aspect of protection from malicious changes and underemphasizes the more important quality review process. I like "Published version", but "Reviewed version" is okay. Don't like "Revised". Deco 22:10, 31 December 2005 (UTC)
The problem with the term "published" is that it is a loaded term. The Mediawiki foundation are not publishers! This would open them to legal liability, something that would bring the whole project crashing down. I do think, however, that "snapshot" is a good term: it doesn't imply permanence, it implies that it is look at the article at a specific period of time. - Ta bu shi da yu 09:21, 2 January 2006 (UTC)

This single most important thing in this proposal is the endorsement from Wikipedia that the article is reliable, otherwise it is no different to the articles we already have. The name should at least reflect that. -- Zondor 16:21, 1 January 2006 (UTC)

The name and idea has been around for quite a while, at least since August. How does the name stable relate to the emphasis of quality? Stable means:

  • Consistently dependable; steadfast of purpose.
  • Not subject to mental illness or irrationality: a stable personality.
  • Enduring or permanent
  • Maintaining equilibrium; self-restoring
  • Not subject to sudden or extreme change or fluctuation
  • Resistant to change of position or condition; not easily moved or disturbed

-- Zondor 20:59, 2 January 2006 (UTC)

As I said above, stable isn't a bad term but it emphasizes protection from malicious changes over the quality review process used to choose and polish it. Deco 00:30, 4 January 2006 (UTC)

Making "featured articles" obselete

The following was recently added to the proposal by Zondor, who has been the main backer of this proposal: "Stable versions strongly intends to replace and supersede Featured Articles and obsolete its maintenance and removal processes." It is buried in a response to a possible objection and was added on this edit.

Laying aside the bad grammar ("versions…intends"? "obsolete" as a verb?), it makes me wonder: has this proposal been a Trojan horse all along? I completely disagree with this, and don't remember seeing it mentioned even once in the month or so we've been kicking this around. If that is, indeed the intent of this proposal, then I'm probably opposed to the proposal, and I apologize if my supportive remarks have been based on a misunderstanding. -- Jmabel | Talk 21:40, 31 December 2005 (UTC)

We sometimes refer to the stable versions proposal as "stable versions", which makes it a singular noun phrase, although it sounds odd.
Grammar aside, I agree that I don't think Stable versions would supplant Featured Articles in any way. They have entirely different purposes (FA exists primarily to select articles to display on the main page), and I assume FA would still have much higher standards than a stable version - otherwise stable versions would almost never be published. We have only a few hundred FAs. On the other hand, there is the question of whether we would feature the stable version or the working version of the featured article. Deco 22:04, 31 December 2005 (UTC)
Too strong of a statement retracted. The working versions should be shown first prominently, then stable versions. -- Zondor 01:52, 1 January 2006 (UTC)
Retraction gratefully appreciated. We're still on the same page, so to speak. -- Jmabel | Talk 02:07, 1 January 2006 (UTC)
You're welcome. Working version first because we don't want to lose that instant gratification. On the other hand, it should be stable version, because once the stable version is published, it is regarded as "complete" and is time to move on to other articles. -- Zondor 02:14, 1 January 2006 (UTC)
I also strongly disagree with this statement. There should always be a push for a new and better stable version - no article is ever "complete". Moreover, if the stable version is to be viewed as a "final" version, this would set a standard for publication that is very high, when really I would think it more useful to have early stable versions where the article is relatively short, maybe lacks diagrams and has minimal references, but still touches on all the most important areas of the topic. Deco 02:21, 1 January 2006 (UTC)
I don't think that is a point of general agreement. I think a lot of us are saying that it would be good to have both a stable and a working version of a lot of good articles, but that definitely would not carry an implication that these articles are finished. -- Jmabel | Talk 02:23, 1 January 2006 (UTC)
They strictly are not completed as there is a lot of room for improvement but they are just good enough. I consider it a good strategy to take to nudge users to other articles to distribute the load. Although improvements should for ever more be encouraged rather than discouraged, I imagine it would give editors the incentive, a goal to work towards achieving a stable version as a prize (rather than featured articles). In such a case, contributors would think twice before submitting it as a stable version, and finish off the contribution to the article to give other articles a chance. -- Zondor 13:33, 1 January 2006 (UTC) And when the article already has a stable version and its shown by default, it would give a contributor a greater sense of satisfaction if they achieve to supplant it. A newbie would feel good about the ability to edit a high-traffic page, whereas an experienced editor would feel good about supplanting a stable version that people rely upon. -- Zondor 20:03, 1 January 2006 (UTC)

It would be great if we could give the readers the option to browse the versions of the articles by default. -- nyenyec ☎ 03:16, 1 January 2006 (UTC)

Since Wikipedia is about being editable including wiki articles, stable versions themselves as well as the MediaWiki interface, let the default view be editable. Either the latest version or the stable version can be set to be the default as an editable functionality. This is a new privilege or right assigned to an access level, perhaps most suitable to registered users. -- Zondor 07:52, 2 January 2006 (UTC)

On a per-article basis? That could be rather confusing, going back and forth between stable and working versions as you click links. It would blur the distinction. I think a user preference is more appropriate.
An interesting issue just did occur to me though. I generally assume that links in working versions would take you to other working versions, and links in stable versions would take you to other stable versions. This allows the two to be published separately and prevents misleading the reader. But what if you want to link an article from a stable version that has no stable version yet? It'd be nice if the software could automatically link the working version with a suitable warning of some kind until the stable version becomes available. Deco 08:14, 2 January 2006 (UTC)
By default, I would only encourage the current version to be shown for anonymous editors (they can't set preferences!) with a prominent link to the latest stable revision. We must allow maximum chance that errors are corrected on the latest stable revision. I would hate to expand an article to a large degree (as I did witb Btrieve and Windows 2000) and not have my changes be seen immediately by people - this negates any effort I might put into the article! - Ta bu shi da yu 09:09, 2 January 2006 (UTC)
Of course, it has just occured to me that we could set a cookie for each visitor which allows them to set a preference no matter if they are logged in or not... - Ta bu shi da yu 09:10, 2 January 2006 (UTC)
On per article basis because each article has its own situation to deal with appropriate for its own context. The default view is regarded as the recommended view. For example, when a stable version has just been published, it is left on the stable version view to show off and to garner many eyes to find any mistakes. After, say a few weeks, it has been viewed enough already, and we then want to work on the next developmental version for its default view to be the same. In other words, the default view can help pronounce the state of the article. -- Zondor 21:55, 2 January 2006 (UTC)

Certification gang

If there are any well-educated and motivated individuals that are so inclined, I propose a sub page called /Stable (this is essentially Wikipedia:Baseline revision) and that the sub page is linked from the parent article page (eg. Mathematics → Mathematics/Stable). This sub page is protected and any changes must go via {{Editprotected}}. It doesn't matter if the /Stable page is much outdated by the latest version because as long as there is some sort of assurance that it is accurate. Make up a certification gang as per User:DavidLevinson/Future as suggested by User:Linas (see also [2]). It should be a fun activity. The credibility of this certification gang is probably low to begin with as well as the trustworthiness of the /Stable page but it should have a view for much improvement. {{Editprotected}} edits are passed by votes at least to begin with. They can be used for small changes or complete changes by quoting the oldid. What do you think? Feel free to criticise. -- Zondor 15:14, 4 January 2006 (UTC) Perhaps certain interest groups would like to certify articles of interest to them to create Wikipedia 1.0. -- Zondor 15:22, 4 January 2006 (UTC) How do you view the certification history of an individual? Comments on the individual in the certification project page is encouraged. This is useful for deciding on edit requests and removal of the individual from the certification gang. -- Zondor 15:36, 4 January 2006 (UTC) Or possibly that they are on a separate Certification namespace. -- Zondor 15:44, 4 January 2006 (UTC) Certification should be a separate and independent activity from editing. How useful and accurate is an article if it is not genuine? -- Zondor 16:13, 4 January 2006 (UTC)

I like the idea, it solves numerous problems. "Gang" is somewhat pejorative; David Levinson used the terms "team" and "league" (of teams). The major problem that this solves is that we don't have to agree on one single WP-wide uniform certification system (which may be impossible; its FA or nothing, as conversations above demonstrate). For starters, this allows different subject areas to be treated differently: the certification process for math articles can (and should) be different from those on pseudoscience, or those on TV stars. Next, different teams can experiment with different processes: some might try very lightweight "looks good to me" processes, and others can use highly formal, FA-like processes. Different teams can choose different ways of admitting team members, or getting rid of them. Through trial and error, various teams will discover the best way of certifying, and will build up a reputation of doing good work.
Thus, a team is sort of like the editorial staff of a journal (scientific or popular). They're self-selected, self-appointed, and, as long as they are able to function as a coherent unit, they can be called a team. Teams may come and go. Good ones will be stable.
The point of having "leagues" is to certify the certifiers. By analogy, any 12-year-old with a baseball bat can start a baseball team, but this team won't be admitted into Major League Baseball. This does not prevent this team from playing; they can have all the fun they want. However, there is an expectation that major-league-certified articles will be more trustworthy than the sandlot-league articles.
Please note that there already is one team/league operating within WP: the folks over at Wikipedia:Good articles. Some of us may think they have a silly process, but so what. It works for them. You and I can start our own team; lets call it Wikipedia:Better articles. We'll have a better process. And of course, WP:FA is the oldest and proudest "team/process" out there. Vive le difference!
I think this one has wheels. I think we can go. linas 17:42, 4 January 2006 (UTC)
I had been thinking a software change would be required (and the proposed method is a bit clunky, so software changes would be preferred), but it is much better to demonstrate with a proof of concept than to demand software changes without evidence that it would work. A bot can update this to an improved system later. I think team and league are better words than gang, but let us declare "Team Stable" and start creating stable and edit protected versions. Our standards should be those of a good encyclopedia article (of which there are many lists floating around), someone can write down criteria somewhere. Eventually maybe /Stable is what people see first, and then they can dig deeper for /Current or somesuch. We also need a Category:Stable to easily track these things. dml 01:06, 5 January 2006 (UTC)
very good. we are a gang initially looking forward to be a team prior to be a league. -- Zondor 03:47, 5 January 2006 (UTC)
Protection of the subpage seems overboard...why not just provide a permanent link to a stable version in the history? Would this be the same thing? --HappyCamper 05:11, 5 January 2006 (UTC)
Wikipedians are strongly aligned to the politics of the wiki way for it to willingly adopt protection of the published stable version. It is a certainty that there are errors that will be overlooked after it has been published. What if the current version becomes a fork of the published version (permanent link)? The permanent link would have to be turned into a fork (protected with history) unless such forks are not allowed. -- Zondor 06:15, 5 January 2006 (UTC)
I have created a sign up section on the project page for those who wish to express interest in participation of the certification process. -- Zondor 06:15, 5 January 2006 (UTC)

(unindent) Having local "teams" to take care of stable version standards is all well and good, but at the least we need standards for formatting and organizing stable versions that are consistent across Wikipedia. I propose the following:

  • The stable version is always located at Page/Stable and is always protected. Any suggested changes are discussed on the talk page where they are periodically reviewed and, if they have consensus, implemented by admins. It may be only semiprotected during preparation of a new stable version (or not - the new version could be prepared on a temporary page and copied to the stable page by an admin). This isn't ideal, but with our current technology I think it's the best we can do.
  • Stable versions are not limited to single past versions of the working version, or even small modifications of past versions; they can be prepared in any manner the team desires.
  • The stable version is always linked from a specific location on the article page using a specific template, say Template:StableLink. I'm thinking it would go at the top.
  • The stable version includes a template at the top discussing briefly saying it's a stable version, linking a longer description of stable versions, and giving the date on which it was published.
  • The stable version includes a section of "reviewers" near the bottom listing real names of users who have examined the article and believe it to be accurate, along with any relevant qualifications they might have. (Somewhat debatable).

What do you guys think? Deco 19:10, 5 January 2006 (UTC)

Permanent link

Is there a way to use the Permanent link from the link on the left side toolbox to do this without copying the article? i.e. #REDIRECT Permanent link from the /Stable ... /Stable would this be a redirect to permanent link? I tried this with Common Unix Printing System/Stable as #REDIRECT Common_Unix_Printing_System&oldid=32844867 ... but that doesn't work, i.e. there is a problem with the ampersand in the REDIRECT. dml 02:10, 5 January 2006 (UTC)

See also Common Unix Printing System/Stable2 for another solution, but the redirect is not automatic.

I added comments about this to Village_pump_(technical)#Ampersands_in_wikilinks

dml 02:46, 5 January 2006 (UTC)

yes, protection is anti-wiki! -- Zondor 03:47, 5 January 2006 (UTC)

Categories for Redirects

It would be good to track stable versions with categories e.g. Category:Stable, but categories can't seem to be added to redirects to URLs (see Common Unix Printing System/Stable2) though can be added to redirects with wikilinks (see [[Common Unix Printing System/Stable). dml 12:34, 5 January 2006 (UTC)

Mechanics

There are several options for the mechanism to denote Stable.

  • Copy the text of the stable version to /Stable
    • Protect
    • Don't Protect
  • Use /Stable to have a Wikipedia:permanent link to the stable version using
    • #Redirect to either the wikilink (if the ampersand problem can be fixed)
      • Protect
      • Don't Protect
    • #REDIRECT to the URL of the permanent link
      • Protect
      • Don't Protect
  • Others (add here)

dml 12:22, 5 January 2006 (UTC)

Please don't confuse software with mechanism. The gang/team does not need software to work, it can be informally organized. I envision the following:
  • A gang/team is formed at Wikipedia:WikiProject Sometopic/CertTeam or Wikipedia:WikiTeam Defenders of the Wacky Truth. There may/will be multiple teams.
  • A copy of article to /Stable is made.
  • The team uses talk page to reach consensus that this is the correct version to protect. (using whatever process that team uses, e.g. voting/consensus).
  • The /Stable page is protected (or not, depending on that team process).
Later, if this process is found too clunky, then software can be developed to automate it. In the meanwhile, we need to do the proof-of-concept that this kind of cultural process can work.
Note that two different teams, with possibly different editorial slants, may want to certify the same article. This will occur in pseudoscience topics, religious topics, etc. We have not yet discussed how to handle that case. linas 15:40, 5 January 2006 (UTC)
I am not confusing software with mechanism. The mechanism will be aided with software changes, but we can't wait for the programmers to get their act together on this, they have too much to do as it is and I don't think the voting mechanism that has been proposed by Magnus will do what we need. That said, do we copy the article to Article/Stable or refer (via a Wikpedia:permanent link to a particular version of the article (e.g. using a redirect at the location Article/Stable). I prefer the latter to avoid forking problems (but can't figure out how to make it work properly, but this seems trivially resolvable, see note on ampersands). The emergence of multiple teams certifying versions will create issues, perhaps resolvable through the use of Article/Stable-Team1 and Article/Stable-Team2 type of differentiation.

dml 19:22, 5 January 2006 (UTC)

I frankly can't imagine what conceivable utility a freely editable, or even semiprotected, stable version would have. If it can be edited at any time by anyone, it's not going to be any more reliable. Without some universal requirements for stable versions, they will not acquire trust from readers, and I think one of those should be limiting edits to trusted editors, and even among them to very narrow and low-risk types of edits. Vandalism is not the only issue; even well-meaning editors may wish to take precipitous action against a stable version that needs to be checked by their peers. Of course it's antiwiki - wiki is intended to be an effective, lightweight way of developing articles in progress, and the stable version is not intended to be substantially edited. You might argue that some areas are not as susceptible to vandalism as others, but we've all seen nontraditional targets like theorems and insects randomly vandalized on occasion.
I also object to the "redirect to a permalink" approach. As I've previously asserted, I think the ability to make small edits to the stable version with consensus is important for keeping it as reliable as possible. It might be alright as a temporary thing until such changes become necessary. I can't see how these concerns could vary from one encyclopedia area to another. Deco 22:58, 5 January 2006 (UTC)
The stable version is not freely editable, ideally it refers to a fixed version of the article. If minor changes are agreed to, those should be brought in through reference to a new version of the wikipedia article. There should not be a fork of articles, referring to specific versions achieves the non-forking principle via permanent link. If it is a single link, unapproved changes (whether the article is protected or not, it can be changed, protection limits those who can change it) will be easily noted and reverted. If the changes is agreed to by consensus on the talk page, and then committed to the main article, the new version of the main article can be used as the reference for the permanent link for the stable article. dml 23:11, 5 January 2006 (UTC)
I believe forking the article, although generally undesirable, is necessary for stable versions. You say:
If the changes is agreed to by consensus on the talk page, and then committed to the main article, the new version of the main article can be used as the reference for the permanent link for the stable article.
This simply doesn't work, because the working version may be in the process of undergoing other major changes at the time and may have significantly degraded since the time of the stable version publication. The person who wants changes to the stable version is left with two choices: either accept decreased quality in the stable version, or wait until the current changes are complete. Neither is enticing in the case of urgent inaccuracies that need repair. There are certainly cases where your plan does work, but I don't think the situation I describe is theoretical. Deco 01:12, 6 January 2006 (UTC)
I just realised, it is possible to make permalinks work by reverting any degrading changes to the working version, modifying it, linking that version, then reverting back to the current working version. It seems more disruptive and confusing to me than forking though. Deco 01:28, 6 January 2006 (UTC)
Yes, that is a good work around. I believe, eventually, a forking implementation is an ideal one particularly once stable versions becomes fully accepted into Wikipedia because of the strong demand. Permanent links are a crude solution but they can be used at this early stage. -- Zondor 01:36, 6 January 2006 (UTC)
Permanent links to older version may be more confusing than forking, but there is no reason the working version would not benefit from changes proposed to the stable version which should have higher standards. As long as we are not in the middle of a series of temporary and incomplete improvements to the working article, the two versions should at times be identical, then the working version continues to change, while /stable remains stable, and then they are rejoined. If something is POV, factually incorrect, or unreferenced, it should be eliminated from the working version as well.
At any rate, what do we do, put the URL of the permanent link for the agreed to stable version in the /Stable page? (which requires users to click twice). Or can anyone find a trick to #redirect to permanent links (developers have told me the software cannot do this). dml 13:51, 6 January 2006 (UTC)
I still don't like the permalink approach, because it may be desirable to annotate the stable version with templates and such explaining the purpose of stable versions, giving a link to the working version, and so on. It is entirely true that we will want to make some changes in both versions - considering that the stable version is expected to not change much, I don't think this would cause a significant amount of work (although a software feature to merge changes between versions would be nice). The current technical limitations of the permalink method are just the last nail in the coffin. Ordinary copy-paste forking from the working version to the stable version is sufficient for now in my opinion. Deco 21:58, 6 January 2006 (UTC)

Maybe not every article needs a stable version....

In order to allay the fears, concerns, and the anti-elitism slant of the broad wiki community, maybe there should be criteria established for which articles can be made "stable". Specifically, I want to see the "Stable versions" process applied only to those articles that cause wikistress, wikifatigue, and cause old-time, trusted editors to take excessively long wikivacations. Thus, a stable version is made (and shown as the default!!) if and only if:

  • Its been the subject of edit wars, or has been frozen in the past.
  • Its had NPOV stickers, "expert attention" stickers, etc. slapped on it in the past.
  • It attracts undue interest from newbies, who feel compelled to re-write from scratch or make other major (but usually detrimental) modifications.
  • Any article that on its own has a tendency to wiki-rot. i.e. get worse because of an endless stream of minor edits, none of which are objectionable, but the whole of which results in crud. (I suspect that not all subject areas have wiki-rot; for example, I suspect articles on movie stars wikirot a lot, as minor trivia are inserted in random locations, until the whole thing is an ugly mess.)

I suspect that every subject area has these kinds of "trouble" pages, and I think we all have a pretty damned good idea of what these are: these are the pages that we spend an extra-special amount of energy watching over. These are the ones where inane conversations on the talk page stress us out. These are the pages that should have certified, protected stable versions.

Again: the goal is to be able to re-certify monthly, instead of getting one's energies sucked dry daily. If the live version of the article wanders off into crap .. so what. At least the certified version is good. And if the live version evolves to something better .. certify that. linas 16:02, 5 January 2006 (UTC)

that's contrary to our ultimate goal of Wikipedia 1.0. an edition that contains a whole set of article versions, perferably core topics. ie. produce a print version of Wikipedia 1.0 at any given time, error free, vandalism free, guarantee of accuracy and reliability. the existing broad wiki community does not need to participate whatsoever. a new community of certifiers can work independently and parallel to certify articles. once a version is certified then move on; and then later, supplanted again. -- Zondor 01:25, 6 January 2006 (UTC)
I understand your perspective, but this overlooks the concept that the stable version is not just an anti-vandalism measure but also a way of driving for reliable, quality versions of everything we publish. We can't commit anything to print, or have anything cited in a serious paper, and so on, unless it has officially been reviewed and given the proper status for these kinds of uses. I use the term "working version" because, although the wiki version can often be stable and informative for decent stretches of time, it simply can't be relied upon. It's a draft, a work in progress, and should only be used with that in mind. Deco 01:31, 6 January 2006 (UTC)
Ahh, well, both of these responses make clear that the scope of articles to which "stable versions" applies is ill-defined. Zondor implies that stable versions are only for "core topics". Deco implies that we may have stable versions of all articles. So which is it? I don't much care, but the project page should make this clear. Perhaps I was too strong in my language; I meant only to suggest that maybe controversial articles are the ones that need to be certified first and foremost, but other ways of prioritizing are also possible. linas 02:18, 6 January 2006 (UTC)
I think that it's not really necessary to prioritize. The process should be made available, and it should be up to the ordinary editors who are closely associated with particular articles to publish stable versions of those articles. They can take as short or long a time as they want. If you want to help them out, I guess I'd go for the core articles, which are needed for print. Admittedly, it might need some initial effort by supporters before it "catches on" with Wikipedians at large, and I think I'd target core articles at this stage. In the long run, we want people who edit articles with no stable version to want to push for the first stable version. Deco 02:28, 6 January 2006 (UTC)
Only for core topics? Not so. Core, critical, complete, stable, good, standard, good enough, stub, featured, high interest, and Pokemon articles are all applicable - every article is suitable for stable versions. Its just that the core set would be the most ideal and useful for the end user. -- Zondor 02:43, 6 January 2006 (UTC) Since there is such a strong community in Pokemon, if we could make certified copies of all Pokemon articles, then we can distribute a Pokemon edition of Wikipedia 1.0. That would be a good goal. -- Zondor 02:59, 6 January 2006 (UTC)
Sure. We could publish all sorts of subsets in books. For example, Mathworld was published as a book - if we take a large set of well-referenced, stable mathematics articles, we could publish them as a similar work, but more comprehensive and without any of the copyright issues that frustrate that work. We could also publish small subsets, like just the articles on sorting algorithms, as a little booklet. Textbook organizations could include subsets of articles in their appendices for background. We could publish periodicals describing the latest TV shows and actors with fancy layout and extra media. And I'm sure we have enough on the Zelda series alone to fill a good booklet. The possibilities for print are endless. Deco 04:02, 6 January 2006 (UTC)

Nomination

To get this process going and test the proposed mechanism, I have nominated (in a fit of meta) Wikipedia ( oldid of 34314154) as an article for placement in the stable namespace Stable:Wikipedia. The article has already been considered a Featured article. Please consider this on the Talk:Wikipedia page. dml 14:16, 8 January 2006 (UTC)

As this is only a proposed process, I removed the stable nomination notice from the article. That is a high visibilty article, and this process is not in production. I support having a validated version of articles, but do not support putting a big self referencing sign on a popular article without the process being approved by the community. xaosflux Talk/CVU 03:35, 9 January 2006 (UTC)

Templates

Are both Template:Reqstable and Template:Nomstable required, can they be combined? dml 19:38, 8 January 2006 (UTC)

They both serve different purposes. It is natural to have multiple {{Nomstable}} version nominations per article nomination session because there are important errors (not trivial errors or new information) that will be overlooked. {{Reqstable}} is to announce an active nomination and when the nomination is done, {{Reqstable}} is removed but all the {{Nomstable}} template stays. There is yet another template for consideration as an article header template to tell the readers of the article about the nomination. -- Zondor 00:12, 9 January 2006 (UTC)

Alternative implementation

I really like the idea of stable versions. They would make Wikipedia a lot more usefull.

During the Nomination of Wikipedia as a stable version. I came up with the following alternative implementation.

Procedure for Nomination

  1. Choose a particular version of the article with an oldid that is considered to be ready for Wikipedia 1.0.
  2. The nominated version is copied to [[Stable:Article/Candidate]] (e.g. Stable:Wikipedia/Candidate). The oldid is quoted in the edit summary. Templates within this version are subst'ed.
  3. The nomination of the candidate is announced on [[Article]] (e.g. Wikipedia) and the talk page, [[Talk:Article]] (e.g. Talk:Wikipedia).
  4. A Template quoting the oldid and explaining the procedure is placed on top of the talk page [[Stable_talk:Article/Candidate]] (e.g. Stable_talk:Wikipedia/Candidate).
  5. On [[Stable_talk:Article/Candidate]], Individuals including the nominator sign their support or opposition with {{Certstabletrue|Username}} or {{Certstablefalse|Username}} with a signature and optionally with their reasons.
  6. Obvious indisputable errors of [[Stable:Article/Candidate]] are corrected. No new content is added, no rewording is done.
  7. After four days [[Stable:Article/Candidate]] becomes protected.
  8. Three more days are given for individuals to support or oppose the final version of the candidate.
  9. After that, Administrators check the nomination for validity and determine the outcome.
  10. If the nomination was successfull, Stable:Article/Candidate is moved to Stable:Article and Stable_talk:Article/Candidate is moved to Stable_talk:Article. The talk page remains active to comment on the stable article. A previous stable version and its talk page are archived.
  11. If the nomination failed, [[Stable:Article/Candidate]], which is mainly a copy of an old version, is deleted, [[Stable_talk:Article/Candidate]] is archived, it might be usefull for improving the article.
  12. The announcements on [[Article]] and [[Talk:Article]] are removed or modified accordingly.

Pro

The article is going to be forked anyway, doing it at a prior stage of the process allows to proofread the article and correct obvious errors without conflicting with the normal developement of the article.

In the experimental nomination two such errors ([3] and [4]) were discovered and fixed. This resulted in nominating a newer version of the article as stable.

If a spelling error is discovered only after another editor added new content to the article, under the current procedure it is only possible to correct this error and nominate the newest version, including the new content, as stable. This bears the risk, that the new content introduced new spelling errors.

Fixed deadlines counter the risk of neverending fixes to the candidate, turning it into a parallel version. Markus Schmaus 16:29, 10 January 2006 (UTC)

Support. If it were to republish the stable version, use of /Candidate is necessary, whereas its main stable article is always for production use. Perhaps Stable_talk:Article should be protected as well? For meta data about the protected stable article. -- Zondor 19:38, 10 January 2006 (UTC)
The general procedure is sound but I think /Candidate is better off to be in the Review namespace as per User:TidyCat/Achieving validation on Wikipedia. Stable is for production use only and so it can be confusing to have a /Candidate working version there. The result is everything in Stable only has articles for production use only for better information management. We might also have a Stable images namespace. -- Zondor 05:32, 12 January 2006 (UTC)
To avoid a proliferation of namespaces, I suggest Article/Stable candidate. Deco 05:37, 12 January 2006 (UTC)
I made a copy of the proposal below, please feel free to change it accordingly. 129.187.163.33 17:21, 12 January 2006 (UTC) (Markus Schmaus)
I think the use of a "Review" namespace prior to a "Stable" namespace is a good idea, it will help reviewers find articles in process. Wiki -> Review -> Stable seems a reasonable process, with the namespaces clearly designating and tracking status. A simple move command can be used to mv the Review article to the Stable namespace (thereby removing it from Review and keeping its history intact) dml 01:57, 15 January 2006 (UTC)
Support. An excellent and well-thought out proposal for the mechanics that preserves the important property that the stable version can always be counted upon and is relatively non-intrusive. The only thing I would change is the insertion of a brief template at the top of the stable version candidate (the article, not the talk page) linking to the working version, briefly explaining stable versions and linking to a reader-oriented description of them, and giving the date of publication. I realise it is not conventional to add metadata to the article, but I think it's important here so that readers know what's up with this stable version stuff and can navigate between versions. Deco 23:06, 10 January 2006 (UTC)
Please change the copy below accordingly. 129.187.163.33 17:21, 12 January 2006 (UTC) (Markus Schmaus)
Support. Tlogmer 21:31, 11 January 2006 (UTC)
Support - the method is too cumbersome, but will do for now. dml 22:31, 11 January 2006 (UTC)
Support - it's worth a shot Gerard Foley 22:46, 11 January 2006 (UTC)


Support - This should be the next step towards (stable) Wikipedia's acceptance by more. Ian Emerson 23:29, 14 January 2006 (UTC)

Con

May be too complex and bureaucratic an approach. —The preceding unsigned comment was added by Jmabel (talk • contribs) .

Procedure for Nomination

The following proposal is open for the wikiprocess. Please change it as you would change an article.

  1. Choose a particular version of the article with an oldid that is considered to be ready for Wikipedia 1.0.
  2. The nominated version is copied to Review:Article (e.g. Review:Wikipedia). The oldid is quoted in the edit summary. Templates within this version are subst'ed, and {{StableCandidate}} is placed at the top. This template contains a process-oriented category (Category:Stable candidate, or some such) so that articles undergoing this process may easily be found.
  3. The nomination of the candidate is announced on the talk page, [[Talk:Article]] (e.g. Talk:Wikipedia).
  4. A Template quoting the oldid and explaining the procedure is placed on top of the talk page Talk:Review:Article (e.g. Talk:Review:Wikipedia).
  5. On Talk:Review:Article, individuals including the nominator sign their support or opposition with {{Certstabletrue|Username}} or {{Certstablefalse|Username}} with a signature and optionally with their reasons.
  6. Obvious indisputable errors of Review:Article are corrected. Incomplete or problematic content may be removed provided that it is self-contained and inessential. No new content is added, no rewording is done. (Errors should also be corrected in the wiki version of the article).
  7. After four days Review:Article becomes protected.
  8. Three more days are given for individuals to support or oppose the final version of the candidate.
  9. After that, Administrators check the nomination for validity and determine the outcome.
  • If the nomination was successful,
  1. Any previous stable version and its talk page are archived.
  2. Review:Article is moved to [[Stable:Article]], and {{StableVersion}} is placed at the top, which expands to something like this:
    This is a stable version of the article Stable versions/archive2, a version that has been extensively reviewed and protected from malicious changes. It was published on 15 March 2006 and may contain out-of-date information. You can suggest changes or view the working version..
  1. Talk:Review:Article is moved to [[Stable_talk:Article]].
  2. The talk page remains active to comment on the stable article.
  3. The announcement on [[Talk:Article]] is removed.
  • If the nomination failed,
  1. Review:Article, which is mainly a copy of an old version, is deleted. (users can note any corrections and fix the Wiki version of the article.
  2. Talk:Review:Article is archived, as it might be useful for improving the article.
  3. The announcement on [[Talk:Article]] is replaced by a template linking to the archived discussion.


Talk

I copied the proposal to open it for the wikiprocess. In the end we could try to use the process itself to turn it into a final proposistion. Maybe this should be done on a separate page. 129.187.163.33 17:21, 12 January 2006 (UTC) (Markus Schmaus)

I made some changes to the proposal. Mostly I changed the name of the "nomination" pages and added the "StableVersion" template, but I also removed the requirement to place a nomination notice on the working version, which I think is unnecessary and too invasive. What do you guys think? Feel free to make additional changes. Deco 22:02, 12 January 2006 (UTC)
I think a nomination notice on the working page is useful to help editors find review-status articles. I may read the article and not the Talk page. dml 02:07, 15 January 2006 (UTC)
As long as the article hasn't been approved it should not claim to have been extensively reviewed. Markus Schmaus 01:58, 13 January 2006 (UTC)
Ah, good point. I support this change. Deco 03:37, 13 January 2006 (UTC)
As part of the review process I added: Incomplete or problematic content may be removed or replaced with a newer version of that content. Normally we'd pick an oldid without such issues, but I think this is important for articles which never quite reach a good state or where different sections develop at different times. Thoughts? Deco 03:37, 14 January 2006 (UTC)
We should avoid content forks. The | Math project once forked "Manifold" for rewriting. I worked on that project and for several reasons i concluded that parallel developement on two branches should be avoided.
By obvious indisputable errors, I meant errors which also have an obvious solution. So correcting them in both branches shouldn't be a problem.
Removing content is an option. A weblink, which no longer works, can definitly be removed. But if done cautiously also larger section can be removed, if they are not yet mature enough to be included in a stable version, they are not essential for the article and removing them does not unbalance the article.
Replacing it with a newer version is more problematic. If content forks should be avoided, the only source of such content can be the working version. Since this content was not included in the oldid picked as the candidate, it is pretty new itself. If this content is essential, it is probably better to wait until the problem is resolved in the working version and a better version can be nominated as stable. Markus Schmaus 15:51, 14 January 2006 (UTC)
I changed it to: Incomplete or problematic content may be removed provided that it is self-contained and inessential.. How's that? Deco 08:33, 15 January 2006 (UTC)
Used a "Review" namespace as suggested above to help track articles. dml 02:07, 15 January 2006 (UTC)
Weak oppose. I don't like the idea of using a whole new namespace just for ephemeral articles. We don't want to encourage a proliferation of unnecessary namespaces. Deco 23:45, 18 January 2006 (UTC)

User:TidyCat/Achieving validation on Wikipedia

See User:TidyCat/Achieving validation on Wikipedia, a well articulated summary and analysis. It has a more detailed proposal for a stable versions reviewing process. -- Zondor 19:10, 10 January 2006 (UTC)

Concurrent "Published" and "Manuscript" or "Draft" versions using the same engine?

The idea outlined below may already have been considered in part or whole, please forgive me if this is the case.

Whilst Wikipedia articles are being written they are actually "manuscripts". An encyclopedia that is a manuscript is a rather dubious source. I would like to propose the following policy for publishing articles within the existing Wikipedia:

1. "Published" articles would be a file in the ordinary "history" for the article.

The "publishing" would consist of making a member of the history non-editable and allowing search engines to access it.
The published article would have a link back to the current normal Wikipedia article which can be edited. Ordinary Wikipedia articles would be called "draft" articles.

2. Articles would be "published" after a review.

Published articles would be read, reviewed and checked by a final editorial board.
The editorial board for each article would be composed of those contributors who make themselves available for the board plus a subject area chairperson who is also an administrator to mediate and arbitrate.
All contributors to the article would be informed a month before it is intended to publish an article.
Articles would be published if the editorial board linked to that article were satisfied.

3. The existing editing framework would be used for article development in the normal way.

4. Published articles would be updated at a maximum rate of monthly but preferrably no more than twice a year. If the edition frequency is kept low the articles will be more stable and become more highly rated as reference sources. It would also limit the work load on the final editorial board. Each update would be given an "edition" number that can be used as a reference in other publications and the world at large. These controls might raise the status of the articles and make them into reliable sources for academic work.

5. Contributors to an article would ask their appropriate subject category administrator to start the publishing procedure. The administrator would ensure that the publishing is not too frequent and schedule a target date for publication.

6. The main page of Wikipedia links most prominently to published articles and Wikipedia search goes to published articles.

7. It would be reasonable for a small number of articles such as current news to be editable even though published. Perhaps an "editable" section of the published text could be used.

8. So that users know whether search results in google etc. are for current draft or published articles the current drafts should be marked "Draft - see published version" with a link to the published version.

9. The net result would be to allow users access to two "virtual wikipedias", one a draft version and the other a non-editable published version. If users preferred to use the draft version it would be better than the current draft version because every time an article is "published" it would be improved in both versions.

10. Initially all articles would be "published" but with a small note that says "not reviewed" or similar.

11. A __CURRENT__ flag could be placed on the latest edition and removed from the previous edition and a web spider no-indexing flag would be placed on non-current editions.

This suggestion could be implemented by simply marking the approved version of the article with something like a "__NOEDIT__" tag and allowing search engines access to that particular article as well as more recent manuscript copies. Manuscript copies could always contain the text DRAFT - SEE PUBLISHED VERSION on the first line with a link to the last published version. Published copies would contain the link EDIT THIS ARTICLE on the first line with a link back to the manuscript.

The suggestion would end edit disputes because the admin chairperson would hold the casting vote for what is to be included in the published version (they would arbitrate and mediate). This suggestion would also solve the problem of vandalism and the problem of anonymous IP's.

The suggestion is a very small change compared with what we have at present so should be acceptable to almost all users. There would be no need for nominating articles, just for admin time. loxley 15:20, 19 January 2006 (UTC)

forking considered harmful

Many of the above points seem to ignore pragmatic issues involved in forking - specifically, if there are two versions of most articles at wikipedia both will likely show up as google hits. How is a random web surfer to know which one to select? I think this means that http://en.wikipedia.org/wiki/Ludwig_van_Beethoven has to be the URL for the "stable" version. But once you visit this link, you should be offered the ability to modify it. Perhaps a pragmatic response is that the software displays, by default, the "stable" version and, if you click "edit" you're shown the current working version to modify. Another pragmatic issue is the sheer volume of articles and edits that need to be "vetted". Looking at these two issues simultaneously, perhaps a solution might be to have a "vetted" tag that can be set on any version of an article by some new class of users (vetters?). Here's how this might work.

  1. The software caches (and most casual visitors see) the last "vetted" version of an article. The "edit" tab exists on all articles, but if you click it you see the most up to date version whether it's vetted or not.
  2. When editing, there's a checkbox (like "this is a minor edit") displayed only to "vetters" that, when clicked, marks the result of this edit "vetted" (note that "vetters" might or might not click this, and any edit without this tag does NOT result in cache invalidation - my guess is that this would substantially improve the overall performance of wikipedia).

The net result is that only the last "vetted" version is displayed to most users (perhaps there should be a preference setting for logged in users to display the most current, rather than last vetted, version - but I think this is a nit), and there is a set of users able to tag new versions as "vetted".

The issue then beomes, who are the "vetters"?

We want a lot of them, because there are a lot of articles. I think the only absolutely necessary qualification is "well intentioned". Vetters don't have to click the "mark as vetted" box. Clicking this means "I agree the changes that have been made to this article since the last vetted version are reasonable". I suspect 90% of the active editors (as opposed to viewers) of wikipedia could be entrusted with this responsibility. Perhaps this is simply a new class of user that can be designated, or rescinded, (fairly freely) by any admin. Clearly you'd have to have a login to be a "vetter". But other than being able to convince any admin you're not a vandal (or POV pusher), I don't think there needs to be any process for selecting vetters. Most people are trustworthy. If you say "don't click this unless you've check that the edits are reasonable" they won't.

Oh yeah, "vetters" should clearly get "rollback".

-- Rick Block (talk) 03:28, 20 January 2006 (UTC)

Your proposal is functionally equivalent to the proposal that we make the stable version a fixed old version of the article with the stable version as the default, which others have suggested implementing with redirects to permalinks and other such things. I've given enough arguments about why I think making the stable version impossible to edit is a big problem.
Forking is clearly an issue, just as it is in software, due to the complications of merging changes between versions (not for the reasons you mention). As in software, however, it is justified for the gain that we get. I think only one of the versions should be listed in search engines (which one is debatable), which we can do with robot tags. Also, the two versions would be clearly differentiated by their title and the template at the top.
As for allowing all users to "vet" stable versions, you forget that intentionally malicious vandals will take advantage of any capability that we give them. This is the same reason Special:Unwatchedpages is unavailable to registered users, although it would be quite useful to them. Deco 04:30, 20 January 2006 (UTC)
I'm suggesting articles remain editable, but with a fairly easily updated marker indicating the version that should be generally shown and permission to change this marker available on request (not all users). It is indeed functionally equivalent to the stable version being a fixed old version, but with a far lighter weight mechanism for designating (and updating) the stable version than I've seen suggested. If you're a "vetter" (and I expect most users who regularly edit would become vetters) you could mark your own changes as "vetted" and your edits would be immediately visible. If you've become a vetter under false pretenses (you got a login, and made enough edits to convince an admin that you're responsible) and later revealed your true malicious self, your vetting permission could be revoked by any admin. The stable version I'm talking about would not be a fork reviewed and corrected by a select committee of experts, simply the latest version looked at by a vetter. -- Rick Block (talk) 14:54, 20 January 2006 (UTC)
Well, I don't think anyone's suggesting requiring a committee of experts to review each article - just a group of interested contributors, most likely the regular contributors to the article. There are articles in development which never quite manage to settle on a complete and accurate version. The review and publication process takes an already-good past version and creates an explicit emphasis on fact-checking and other necessary steps that need to happen before we get something we're prepared to put our stamp of quality on it. This is like Featured Articles, but with the critical difference that new and disruptive development to the current editable article can proceed in parallel, and the final published version is stable at all times, remaining unaffected by any vandalism, overhauling, or controversy that touches the working version. I don't think there is an issue with insufficient contributors, as long as instead of relying on experts and administrators to do the heavy lifting we rely on interested contributors, just as we do for ordinary article development. Deco 22:36, 20 January 2006 (UTC)
So, how are the users allowed to edit the stable version selected? Who grants them permission to edit the stable version? How are edits to the "open" version incorporated into the stable version (or are these permanently divergent versions)? Equally important, what is the incentive for folks who work on the stable branch to ever look at the "open" branch? If you fork a "stable" version, and allow it to be edited independently of the "open" version, I don't see how this can be anything other than a permanent fork. I repeat, I consider forking to be harmful. -- Rick Block (talk) 07:04, 21 January 2006 (UTC)
The problem of who makes the changes was tackled in my suggestion above for a final editorial board. Every article could have its own final editorial board composed of all interested contributors to the article plus a chairperson who is an administrator for that subject category. The publishing/final edit process would only be applied at intervals of six months or so for most articles and be physically executed by the admin chairperson. The admin chairperson would also have the role of mediator and arbitrator for the published/stable version.
The incentive for contributors to work on the stable version would be that, once agreed and fixed, this would become the next draft version. loxley 13:04, 21 January 2006 (UTC)
There are currently roughly 600 admins and over 900,000 articles. If each final editorial board is to include an admin, to cover all the articles each admin would need to be on 1500 boards. Even if articles are published only once a year, this would mean each admin would be involved in publishing about 4 articles every day. Perhaps the target might be to "publish" only some subset of the articles, but I think the numbers don't work unless the target is a relatively miniscule percentage (maybe 1% might work). The role of admin also currently includes no content oversight responsibility, and I suspect you'd only be able to get a fraction (optimistically perhaps 1/3) of the current admins to participate in such a scheme. There are other issues as well. For example, what happens during the month or so when a "published" version is being worked on? Is the draft version protected, or are edits to the draft during this time merged into the published version afterwards to make the new draft? I don't think the basic idea of a protected fork is wholely without merit, but I just don't see how it could practically be done within Wikipedia itself. -- Rick Block (talk) 20:53, 21 January 2006 (UTC)

Draft versus published article

I read the stable version concept, but I do not think the key problem is here. Many articles have reached high quality although they are being constantly edited and revised. But information contained in them have been checked by several editors. Plus those pages are in watchlists of several users and so vandal-proof. Reader can be sure that information privided are at least 90 % correct -- no major bugs.

On the other hand new articles are mere drafts. "I propose this being in the wikipedia" kind of thing. Even the original author sometimes is not sure whether it should be in wikipedia or whether all the facts are correct. But those articles can provide basis for futher revising and even basic information for the reader. But they must be taken as not final articles.

So I suggest mark every new article as a draft. When the editors come to the conclusion, that the article is good enough, they "publish it" by removimg the draft warning. Draft warnings removals should be monitored, but it is much more easy than check every edit in any article. I am looking forward to your comments --Jan Smolik 13:05, 21 January 2006 (UTC)

I agree, see above. loxley 13:08, 21 January 2006 (UTC)
I think that my sugestion is somehow different. I think there is no need to lock published version of the article. Small changes to the published article don't do any harm. You can be sure that Leonardo da Vinci is right although anyone can edit it. But "new" articles that did not received enough input can be wrong (and maybe must be wrong). Generaly I agree with distinguishing between drafts and published articles but I consider locking published articles to be useles. --Jan Smolik 13:22, 21 January 2006 (UTC)
The advantages of locking published versions are that they would be the product of a definite effort to publish and hence have a higher quality, they would be immune from vandalism, they would not be part of any edit wars that occur on the draft and they would be fixed points that can serve as a reference in other publications. Procedurally they would focus the editors to create drafts at intervals that would be a good foundation for further editing. loxley 13:27, 21 January 2006 (UTC)
I agree with this fact, but I think it is a big change in the wikipedia logic. I see it as a third level. First is general draft. Then it continualy improves and can be published. It is the second level. And third is an export of the stable version (locked published version). The second level only says, that the article is verified. It does not mean, it is complete. Even short verified stub can reach second level of being published, but locking it would create obstacle for its expansion. --Jan Smolik 16:34, 21 January 2006 (UTC)
Any contributor should be able to request a new edition of the locked, published member of the history. The admin chairperson would then schedule the article for production of the new edition - if there were no need for an emergency correction this scheduling might be for not more than 6 months time. If a majority of contributors requested an "immediate" update the new edition might be scheduled for 1 months time.
As you say, the current editions of the published articles could be extracted to produce an export of the whole encyclopedia (the third level). If some "vetting" committee or group of academics want to take the extract and award merit stars or similar to each article that would be their concern, it would be outside of Wikipedia itself. loxley 19:22, 21 January 2006 (UTC)

A couple of potential unintended consequences of dual WPs

If "stable versions" is implemented as a fundamental split (fork or otherwise) creating two distinct versions, two potential problems come to mind:

  • the drive to improve the live wiki version is diminished Fine tune this any which way—human nature, migration of talent, the downside of having to great a safety net, whatever—having a "better" version inevitably lowers the perceived value of the "other" version, likely making it less compelling to work on. This is apart from ideas of "un-wikiness" or "routine" vandalism, more like a simple "it's not that important" virus that infects the contributor base and beyond, contributing to a decline in productivity. There is less reason to improve, less motivation to patrol and maintain. Kind of what I've seen happen in forks in popular open source software projects, there is still much activity on both sides, but one side has that loss of vitality and hint of abandonment about it...
  • the stable version is critically panned and characterized as second rate Once a stable version exists, it is open to full-on criticism from all sides, something that the original WP is somewhat protected from by being such a radical, open project. If the stable version isn't at least as good, in number and scope of articles, article content and writing quality, as any other sources critics choose to compare it to, it runs the risk of being looked at as anything from a wannabe amateur attempt to a not-bad alternative. If we're concerned about perception, I'm sure there are many who'd like to trounce on WP, and this'd make it fair game. And if this happens, the live wiki side only gets placed somewhere below that.

This is on-the-fly thinking, devil's advocate POV, as you will. I'm interested in the issue, have followed it only since yesterday. Hope it adds something... --Tsavage 23:22, 21 January 2006 (UTC)

It is not intended to be a fork. Techinically, it is because you need to make corrections that are inevitable, but importantly, no new information is to be added. The drive to improve the wiki version would not be substantially diminised because the work on the stable version are only corrections - no more. It is essentially a carefully picked snapshot with minor revisions just for corrections. It would be good if this proposal was called something more practical like print versions or maybe published versions but stable versions is a good abstract name. -- Zondor 03:51, 22 January 2006 (UTC)
I think these are good points and Zondor is somewhat misinterpreting the comments. On the other hand, I think part of the point of stable versions is precisely to create a version stable and accurate enough to be compared - without any special advantage - to existing commercial encyclopedias. There is the concern of decreasing interest in editing the working versions of articles, and it is mainly for this reason that there was interest in making the wiki version the "default" version. Deco 04:59, 22 January 2006 (UTC)
Is this, like, good cop, bad cop? :) Really, I understand the point of stable versions, in principle I support the idea of being able to easily (magically!) retrieve better versions in cases where article quality has net declined over time. I just don't see 1) a hard description of the problem (like, actual numbers, how many articles have reached AEQ for a start); 2) a basic policy revision proposal addressing that well-described problem. My comments in this section have only to do with possible consequences of poor planning. It's like "world peace". Who's to argue with that, who won't rally round it? But, how are we going to do it if it's not even a quantified problem that's being "solved"? --Tsavage 06:27, 22 January 2006 (UTC)
Personally, the possibility of "stable versions" increases my motivation for contribution, because I'd want my writing to be good enough to be a part of the stable version. I've learned that it's potentially a waste of time to contribute to articles that I don't plan on keeping a close eye on. On a number of occassions, I've checked back in on an article I worked on, and entire sections have been lost due to vandalism. (Example one; example two) Had I not noticed that these articles were missing sections I contributed, that material would be missing still. This realization caused me to confine my efforts to fewer articles, because if stuff just disappears, what's the point? However, the possibility of having material show up on a "stable version" certainly makes me more likely to contribute more extensively. --Kevin Myers | (complaint dept.) 05:26, 22 January 2006 (UTC)
I should note that, while being able to contribute to a long-lived stable version is a motivation, the idea is that eventually a new stable version would supplant it. So you're not totally freed from the responsibility of keeping an eye on past articles (a single stable version would make substantial new development basically impossible). Deco 06:15, 22 January 2006 (UTC)
Kevin Myers: I looked at your examples. That happens, but you did fix them. Presumably (and probably), if it was someone else's stuff removed, they'd fix it as you did. Those are two examples with a high annoyance value, but do you have very many others, like, what's the ratio to all of your substantial edits? And imagine, in a poorly executed stable versions set-up, if you made solid additions to many articles, and they sat around for weeks or months out of stable, waiting for updates? Would, say, Creek people likely be high on the update stable version list?
Regarding the covering less articles, maybe that's more the reasonable way, anyhow. I started editing with an article I initially looked up in WP, and expand around that, plugging away over time. I've started and significantly added to maybe 30-50 related articles over two years. I have four quiet months a year where I'm more online, and the rest of the time, I might check once a week or even two-three weeks, so I'm not on my watchlist like a hawk. And there have occasionally been "examples", but overall, there is a clear and substantial net improvement all round. Out of curiosity I recently looked at the edits and aricles created by a couple of high volume Wikipedians, and in that (admittedly, tiny) sample, it's more stubs and tiny edits than anything. (I'm not saying that's bad, only relating it to your substantial edit examples, vs stub starting and maintenance work.) How many articles can one editor really handle? --Tsavage 06:27, 22 January 2006 (UTC)
These are all good questions. Regarding my blanking vandalism examples, it's relatively rare that such blanking lasts for as long as those examples did, and I could probably only dig up a couple more examples of that variety, as far as I know. I cited them as the most objective examples of what we've probably all encountered -- the disappointment when we revisit an article and realize it has gotten worse instead of better. (Usually the culprit is well-meaning but naive or awkwardly written edits rather than vandal-blanking.) I'm not sure how many articles an editor can handle, but I hope with some sort of stable version system, an editor could increase his or her range (or depth) of contributions with the confidence that such contributions will make a difference (by showing up in the next stable version). Sure, when stable versions are updated, you'll have to work to make sure that process is actually improving the article, but I'd like to think that the existence of stable versions might free up the time spent on repetitive watchlist "babysitting". For me, that's the appeal of stable versions. --Kevin Myers | (complaint dept.) 15:57, 22 January 2006 (UTC)
Thanks for the thoughtful reply. As I noted above, I too agree in principle with the general idea of "stable versions" (and "who wouldn't"), but, yes, the actual system is the question. As presented in the Stable versions proposal that this page is discussing, and in many of the suggestions here, a stable version system would be a form of gate, with gatekeepers who have much higher authority and WP power than you as an editor. You could wind up with substantial changes—improvements—to an article previously published as stable, and be waiting for weeks or months for it to get re-reviewed. In that case, you'd still have to patrol, and also work on presenting the nomination for updating, and at an arbitrary point when your turn (case) came up, argue for that update. A poorly conceived system could result in horrendous bureaucratic red tape and a very disappointing and demoralizing mess overall... IMO, hard information and a clear description of the problem would be a good and necessary start, before crafting radical changes in infrastructure and policy. (Thanks again for the reasonable and apparently open discussion!) --Tsavage 18:30, 22 January 2006 (UTC)
In fact, I'm hoping that stable versions will reduce gatekeeping. Gatekeeping is currently happening. Most often this happens when a knowledgeable editor contributed a lot to an article, maybe even pushing it to featured status. Those articles are good and this editor often spends a lot of time to preserve this state of the article. He developes a sense of ownership and reverts many edits and or adjusts them to his style. The German article de:Jesus von Nazaret is a perfect example for this, its "owner" is currently even trying to get it protected. I'm sure there are such articles in the English wikipedia, too.
I think, that preserving a stable version, removes the burden of such an editor to keep the article the way it currently is and allows the article to drift, probably getting worse at first, but maybe ending in a much better version than the current.
I probably should not have talked about forking (XFree86 - x.org), but rather about branching (linux 2.4 - 2.5). Please forgive any damage done by a bad use of words. If any, the stable branch is dead, any changes to it will be lost, when a new stable version is created out of the working version. There shouldn't be many changes to stable anyway, it is called stable. The only things which should get fixed are typos and the like. Markus Schmaus 23:44, 23 January 2006 (UTC)

Multiple Stable Versions?

The concept of a stable version is not necessarily correct, especially with controversial articles. There would certainly be debate, if not ongoing argument over who is qualified to determine which version is the 'stable' version.

I think a more workable approach is simply to tag articles in much the same way as categories work now, except that the tag is associated only with a particular version of the article in question. This approach also allows for multiple tags on a particular version.

The way in which I see this working is that editorial boards are formed, each of which can apply its own tag to articles it believes to be stable. The most recent version of each article would have a set of Wikilinks associated with it, one per tag, allowing the reader to click on the tag to go to the tagged version of the article - perhaps in the toolbox of the left-hand frame, or perhaps at the bottom of the article. If an article has not been reviewed by any editorial board, no tags will appear.

This allows different groups of people to have differing views over what is stable, allows the reader to ignore tags they disagree with, and also allows the reader the option of viewing articles that are tagged as stable by their choice of editorial board. An article that flip-flops between two competing boards could simply be split into two articles with appropriate differing titles, reflecting differences of opinion.

Note that this is a positive scheme - no versions of articles are hidden, all are accessible to all readers. Articles tagged as Wikipedia_1.0 are approved by the official Wikipedia edtors (whoever they are), and could be used for a print edition.

Obviously, the ability to tag articles would need to be controlled - for example, only giving the ability to people elected to editorial boards. I would expect there to be more than on such board, possibly reflecting different areas of expertise - e.g. a board of historians, a board of economists, a board of mathematicians.

A tagging scheme removes the need to agree on a single stable version, which would take the heat out of many disagreements.

WLD 10:27, 22 January 2006 (UTC)

I agree entirely. This suggestion is such a small change that it could be operated almost immediately. It will not create ructions in the Wikipedia community and allows us to test the idea of stable versions at little risk. It has been suggested in variants in at least two places above:
http://en.wikipedia.org/wiki/Wikipedia_talk:Stable_versions#Concurrent_.22Published.22_and_.22Manuscript.22_or_.22Draft.22_versions_using_the_same_engine.3F
http://en.wikipedia.org/wiki/Wikipedia_talk:Stable_versions#Different_proposal
My own preference is for an editorial board for each article composed of one admin and the contributors to the article. loxley 16:15, 22 January 2006 (UTC)
I disagree completely with this idea,this would lead to the acceptance of fringe theories,pseudoscience or racism seeping into wikipedia and making it the laughing stock of the rest of the reference world.At least now by these "POV battles" it appears these kind of things aren't accepted.
If there isn't concensus on an article it's stable state can wait as simple as that.Wikipedia isn't the first pulication with these problems,every reference faces these problems(POV,completeness,etc) yet britannica manages to put out ONE version even if it isn't completely complete or POVless.Besides I don't believe anything can be made completely without some POV,it's human nature.--Technosphere83 17:30, 22 January 2006 (UTC)
I entirely agree with the initial proposal AND loxley addition of editorial board criteria - Specifically, I don't know how this might scale, or about the technical feasibility, but it is the clearest and most thoughtful, thought-out and succinct suggestion/proposal/amendment I've read here so far. I'd like to add WLD's additional suggestion for a user implementation allowing a user preference filter that would allow tailoring of article selection. There may be holes in this overall approach, but I don't yet see them. The "letting in fringe theories" argument above can't apply until the precise nature of the editorial boards/certification gangs is further clarified. If certification is by a admin+interested parties consensus as in WP:FAC, then the idea would have to be field tested to see if it does indeed "work". --Tsavage 18:22, 22 January 2006 (UTC)
The problem this attempts to solve simply doesn't exist in any reasonable rendition of this proposal. "The" stable version is not just some version that some random dude decides to make the stable version. There are a series of stable versions over time, each one reviewed and agreed on by consensus by a group of interested contributors, including possibly accuracy fixes and removal of controversial or incomplete content. If consensus and compromise can solve an edit war, it can solve the problem of selecting and fixing up a suitable stable version. Consensus has always been the decision-making mechanism at Wikipedia and it seems eminently suitable here. Deco 18:38, 22 January 2006 (UTC)
I respectfully disagree with Deco's last point - consensus is certainly attempted at Wikipedia, but when this is not fast enough, or fails, then it seems to me that votes are used instead - hence the VfD process, for example. I believe there are topics where consensus is not possible to achieve in reasonable time, so I'm trying to suggest a process that accommodates differing views, but does not obstruct the development of Wikipedia - indeed, I would hope it would speed the production of 'Version 1.0'. Putting a tag on a specific version of an article is one possible way of indicating that it is the 'stable' version - all I really propose is that more than one type of tag is used - a simple extension of the principle - which increases the number of options open to the Wikipedia community. If you believe it is not a good suggestion, that's fine; and thank-you for your comments. WLD 20:34, 22 January 2006 (UTC)
Voting at Wikipedia is based on consensus, just with a time limit thrown in. We don't tally up votes like in an election, and we certainly don't get every Wikipedian to vote on every deletion candidate, just interested parties and anyone else who wanders by. The process proposed above that I agreed with incorporated this kind of time limit as well.
I do not oppose the placement of explanatory templates on stable versions (in fact I added this to an earlier proposal), but I oppose any proposal that attempts to make versions of the working version into stable versions, partly because it prevents parallel continuing development on the working version, partly because versions from the history are awkward to link, and partly because this makes it impossible to fix the stable version if any minor accuracy issues should arise (simply choosing a new stable version is not always possible, as I've already explained at some length). 05:56, 24 January 2006 (UTC)

A nomination for a stable version

I have nominated Early life of Joseph Smith, Jr. for a stable version, with OLDID 32743070] for a stable version. Please come over there to help get this Stable Version idea on track. I feel that this is as good an article as there could ever be to begin this long, arduous, even controversial journey.

Also, I think the templates need a little work - I had to make two or three edits to the page before I got it like I think it whould have looked like. --Trevdna 23:52, 23 January 2006 (UTC)

Where is this policy proposal at in the "process"?

Where is this Stable versions proposal at? I just realized how unclear I am about the overall process at work here.. Is a consensus vote going on somewhere else? Has this been sent to the WikiMeida BoD? Where is this at? Thanks in advance... :) --Tsavage 05:47, 24 January 2006 (UTC)

Well, we were settling on a process but then some new people entered, so I guess we're stabilizing on a process again. I don't think we're at a point where we can be experimenting yet until we're all agreed on the mechanics. Deco 05:59, 24 January 2006 (UTC)
Thanks! What I more mean is, what is the "whole" process and where is it all happening? Where would voting take place? Like, for example, what is that thing above, re nomination process, where I see Support and such? Is this and its project page the whole deal, or is related stuff going on elsewhere? Um, thanks! --Tsavage 06:13, 24 January 2006 (UTC)

Current discussion skewed?

For a more complete and representatively unbiased discussion, I think the current discussion page should consist of a rigorously and regularly refactored version of previous discussions, and not simply the latest chronological input. I just read the (one) archived page of this discussion. The overall sentiment, and the substance of the discussion there is IMO markedly different (and more skeptical and critical) than the discussions on this page. (This may be due to the fact that the most interested parties commented early...). Having discovered this topic only a couple of days ago, and only a while later read the initial discussion page, I think this is a little misleading to newcomers (despite the archive link at the top of this page). The full range of opinion should be represented to the most recent arrival... --Tsavage 05:58, 24 January 2006 (UTC)

If you feel strongly about this, please feel free to add a summary of past and current discussion and other events in the proposal's lifetime to the top of the page. Deco 05:59, 24 January 2006 (UTC)
Hmmm... yes, indeed! :) Wanna help? --Tsavage 06:14, 24 January 2006 (UTC)

A tiny bit of somewhat quantitative input: How FAs fare over time...

Maybe already done elsewhere, but from this discussion I was moved to start a simple tracking survey of Featured Articles, to see what indeed happens to them over time. I've only covered under a dozen, but I think it's already intereesting, and I don't suspect the trend will change much as the sample expands. It's here for now: Featured Article quality tracking. --Tsavage 06:24, 24 January 2006 (UTC)

Branchless Stable Versions

Heres a simplified proposal:

  • Each article has a stable marker, as well as metadata for each revision that shows if a revision was ever marked stable. Appropriately permissioned users can move the stable marker forward to a newer version.
  • Versions are referred to as "stable" and "proposed" - this reflects that the "proposed" versions are more likely to contain errors, POV, ommissions, and that they don't reflect final products.
  • Users without accounts default to seeing the stable version, and the software is set up so that search engines will only see the stable version.
  • A stable tab and a proposed tab are added to the interface to switch between the proposed and stable versions.
  • Because the stable version is just a marker, its not possible to edit the stable version directly - edits have to take place in the "proposed" version, therefore all edits stay on the trunk, and any rework to the stable version has to incorperate the changes of subsequent proposed versions.

Hopefully this will be workable - Stephanie Daugherty (Triona) - Talk - Comment - 15:49, 24 January 2006 (UTC)

Added - This could also be adopted to the current Wikipedia:Featured Article system, placing "Featured" tags at revisions that truely stand out as the best possible work our community can offer. - Stephanie Daugherty (Triona) - Talk - Comment - 15:52, 24 January 2006 (UTC)

Added more, still brainstorming For that matter, if we do tagging, multiple tags are possible, with different levels of access to update them - featured, reviewed, stable, draft, and proposed - the "revisionlevel" of any revision could be raised with the right access, but never lowered, the newest revision with a certian tag or a higher tag is considerd that version that represents that status - if you request a "stable" and theres a "featured" thats newer, the "featured" version is returned - could work like this:
  • Proposed Versions are the current work in progress.
  • Draft versions are tagged by any logged in user.
  • Stable versions are tagged by any logged in user that meets the appropriate criteria (probably total edits, time editing, community consensus or come combination of the three)
  • Reviewed versions have withstood a serious peer review and all signifigant deficiencies have been fixed.
  • Featured versions have survived each of the above processes and have met the criteria and consensus for Featured Article status.

Comments? - Stephanie Daugherty (Triona) - Talk - Comment - 16:03, 24 January 2006 (UTC)

Yes, that's pretty good. It's essentially very similar to multiple versions a couple comments above. Although you clarified a bit your thoughts on who does the certifying, that I think is still a central issue, along with the precise final implementation of such a system. You say, default to the stable. That splits WP into essentially two, the "one we're working on" and the "good one" AND puts gatekeepers in place that keep the two apart. I think working from the software solution backwards to the certification gangs and the general policy change is bad. We should be going the other way, FIRST figuring out who is doing what and why with stable versions, and THEN dealing with the how (when it should be much clearer what is required). --Tsavage 16:20, 24 January 2006 (UTC)

I'd like to call your attention to the editable code proposal I made much earlier in this thread. I think it addresses many of your concerns, but has the added benefit that everyone is looking at the same version of the article.--agr 16:23, 24 January 2006 (UTC)

I think that its a benefit to make random edits less visible than ones that have some level of review (even self-review by a logged in user) - it would discourage vandalism by making vandals less visible to casual viewers, and it would hopefully avoid bad PR when someone stumbles upon one of our relatively rare failures. It also encourages users to log in so that they can set preferences. - Stephanie Daugherty (Triona) - Talk - Comment - 16:49, 24 January 2006 (UTC)
There are so many different issues mixed up in this discussion (the whole proposal, not this thread only), without much sorting out, it's kinda scary. If you're talking about making locked versions the default, for one, you're tacitly starting to close the doors on new editors. Isn't part of WP the idea that the user can be the editor, that with anon edits, you can see a small, obvious error and wonder of wonders, just go in and change it? (For that matter, IMO, anons do a notable percentage of the vandalism reversion. From what I've seen, vandalism is always anons, minor corrections are often anons, and major disruptions—edit wars, etc—are more or less always logged in users.) Also, to repeat what I mentioned above, I think in the overwhelming majority of articles, the best version is the absolutely most current. If steady incremental improvements are being made, then the argument would be, as a stable version gets older by the week and month, is there a net gain from protection from vandalism that may've occurred versus loss of improvements made over that time? --Tsavage 17:16, 24 January 2006 (UTC)
You're raising very old arguments that have already been addressed multiple times. First of all your sweeping generalizations are all wrong. Logged in users vandalize all the time (especially now that anons can't create articles), anons do get involved in edit wars, and the current version is often not the best - articles are not only susceptible to vandalism at any instant, but they also go through stages in which they are unstable as new content is being added and fixed up. The purpose of stable versions is to have a version which is reliable and in a good state at every instant in time. In my proposal with branching, only minor changes are made to it to fix obvious accuracy issues. Also, importantly, it defuses many arguments against Wikipedia by making it clear that the freely editable version is just a work in progress that should not be expected to be 100% accurate at all times. Deco 19:38, 24 January 2006 (UTC)
Perhaps there should be subpages, dealing with the different proposal directions, and a page for discussing them in comparision/relation to eachother.
As regards the branchless proposal, I came to this discussion page because I was thinking the same thing. The problem with the featured article centers are that they are too far away from the article in review. I believe the only way stable-unstable versions can work is if a per-article mechanism is provided so that the local contributors, who are bound to be more active, interested, and knowledgable, have immediate awareness and access to this tool.
I also suggest semi-automation. "Stable" versions are generally just that: stable; they haven't been edited in a while. An automated mechanism could go through the history and mark revisions with a tentative measure:
k * e^(-c*age) * e^(d*[time before next edit])
where c is the decay rate (more recent versions should be prefered) and d is the stability unit. both c and d could be inferred statistically per article, since some article are edited a lot(high d) and others not-so-much(low d), and some articles are about current events(high c), and some are about dead events(low c).
Revisions with a high such measure are candidates for the next "stable" version, to be selected by community approval. Kevin baas 19:37, 24 January 2006 (UTC)

Ok... maybe we need to step back and define goals here:

  • Reduce the visability of vandalism edits therefore making them less valuable and easier to deal with.
  • Identify articles suitable for inclusion in static versions (such as a print Wikipedia)
  • Minimize or eliminate the need to perform merges of different article versions
  • Reduce the need for page protection on Wikipedia
  • Insure that the broadest possible group of users can edit anything, without undue burden, gated communities, or prickly hedges.


I think that a multiple tiered tagging scheme is one way to approach this:

  • Vandalism would still be possible, but because it wouldn't be visible to casual viewers for some time and RC patrol would still be functioning, so vandals would probably be reverted before the public had any idea of what took place.
  • Articles could be tagged at various "checkpoints" as having made progress towards completeness and suitability for static inclusion in print form.
  • Because all edits would continue to take place on the trunk, theres no need for merges between branches.
  • Because edits could be subject to varying degrees of delayed visibility mechinisms, there'd be less need to protect pages. Anyone could still see the current version, but the default for browsing would be a version tagged at least as a draft.
  • Providing delayed visibility means that we should have less problems with vandals and other problem users, therefore less need for restrictions and draconian measures aimed at stopping them.
Retrieved from "http://en.wikipedia.org../../../s/t/a/Wikipedia_talk%7EStable_versions_archive2_950e.html"