Wikipedia talk:Stable versions proposal/selecting

• Wikipedia talk:Stable versions/selecting
• Wikipedia talk:Stable versions/storing
• Wikipedia talk:Stable versions/reading
• Wikipedia talk:Stable versions/software mechanisms

• Wikipedia talk:Stable versions/relation to other projects
• Wikipedia talk:Stable versions/research
• Wikipedia talk:Stable versions/miscellaneous

Software tools

Semi-automation - recent stable version detector

...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)

Furthermore, on the history page, one could filter versions to see only the top handful of stability scorers (and the current unstable version and current stable version), and then look at the diffs. they could check their approval/neutral/disapproval on the diffs page or the history page. (by default they are neutral, and only approve/dissapprove votes are stored) Each user has a fixed amount of approve+disapprove votes per article (say, 5), so that as they vote on newer versions, their old votes are dropped (and thus the old stable version is eventually dropped in favor of the new, without having to explicitly drop it). The article with the most approve-disapprove votes is the stable versions. Kevin baas 21:26, 24 January 2006 (UTC)

Votes older than a couple of past stable versions (say, the 3rd most recent stable version), whose owners haven't voted since said stable version, are automatically expired, so that users who aren't participating anymore don't cause stick. Kevin baas 21:37, 24 January 2006 (UTC)

Who decides?

***** 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)

All logged in users can vote

• approve/dissapprove (multiple votes per user)
• vote to progress to version x (one vote per user)

Specially elected body

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 [1]). 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)

Branchless

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)

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. Kevin baas 20:31, 24 January 2006 (UTC)

Branching

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)

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)

Vote weighing

Hmmm...some kind of meritocracy.

• proportional to total number of edits?
• barnstars increase vote weight?
• community approve/disapprove votes on user page affects weight of user's vote? could increase anomosity - maybe just approve, and each user has a limit on how many users they can approve. i don't know, this is tough.
• community vote on vote weigh increase/decrease? (this would make it rare).

Kevin Baas^talk 18:33, 28 January 2006 (UTC)