Wikipedia talk:Stable versions proposal/Archive 2

message: 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)
replies: text: 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)
replies: text: 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)
replies: text:  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)
replies: text: 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)

text: 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)
thread_title:  Good idea, but what we really need is branching 

message: 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)
thread_title: Certification

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
thread_title:  Article validation feature "going live soon" 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Related discussions on article validation 

message: 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)
thread_title:  A thought re voting 

message: 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)
replies: text: 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)

text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text: 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)
thread_title:  A very anti-wiki policy 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
thread_title: It's inevitable

message: 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 play was made into a full length motion picture starring Dustin Hoffman and Angelina Jolie"
*"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)
replies: text: 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)

text: 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)
thread_title:  Coda proposal 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text:  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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text: 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)

text:  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)
thread_title:  Current open model 

message: 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)
replies: text: 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)

text: 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)

text: 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)
thread_title: What version will users see first?

message: 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)
replies: text: 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)
thread_title:  Some brief comments from a developer 

message: 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)
replies: text: 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)
replies: text: 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)

text: 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)

text: 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)
replies: text: Both are required, in good measure; that's my point. Tony 05:19, 30 December 2005 (UTC)

text: 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)
thread_title:  Freezing FAs is a silly idea 

message: 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)
replies: text: 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)
replies: text: 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)

text: 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)
thread_title:  Revised version 

message: 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)
replies: text: yes, protection is anti-wiki! -- Zondor 03:47, 5 January 2006 (UTC)
thread_title:  Permanent link 

message: 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)
thread_title:  Categories for Redirects 

message: 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)
replies: text: 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)

text: 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)
replies: text: 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)
replies: text: 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)

text:  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)
replies: text:  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)
thread_title:  Maybe not every article needs a stable version.... 

message: 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)
replies: text: 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)
thread_title:  Nomination 

message: Are both Template:Reqstable and Template:Nomstable required, can they be combined? dml 19:38, 8 January 2006 (UTC)
replies: text: They both serve different purposes. It is natural to have multiple  version nominations per article nomination session because there are important errors (not trivial errors or new information) that will be overlooked.  is to announce an active nomination and when the nomination is done,  is removed but all the  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)
thread_title:  Templates 

message: 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 ( and  )
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)
replies: text: 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)
replies: text:  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)
replies: text: To avoid a proliferation of namespaces, I suggest Article/Stable candidate. Deco 05:37, 12 January 2006 (UTC)
replies: text: 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)
replies: text:  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)

text: 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)
replies: text: Please change the copy below accordingly. 129.187.163.33 17:21, 12 January 2006 (UTC)

text: Support. Tlogmer 21:31, 11 January 2006 (UTC)

text: Support - the method is too cumbersome, but will do for now. dml 22:31, 11 January 2006 (UTC)

text: Support - it's worth a shot Gerard Foley 22:46, 11 January 2006 (UTC)

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

message: 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)
thread_title:  [[User:TidyCat/Achieving validation on Wikipedia]] 

message: 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)
thread_title:  Concurrent "Published" and "Manuscript" or "Draft" versions using the same engine?

message: 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)
thread_title:  A nomination for a stable version 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title: Where is this policy proposal at in the "process"? 

message: 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)
replies: text: 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)
replies: text: Hmmm... yes, indeed! :) Wanna help? --Tsavage 06:14, 24 January 2006 (UTC)
thread_title: Current discussion skewed?

message: 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)
thread_title:  A tiny bit of somewhat quantitative input: How FAs fare over time...