Wikipedia talk:Stable versions proposal/Archive 3

Selecting

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)

Just to update this section - I talked w/Sinan Taifour of stablepedia about this, and in doing so realized that the formula can be simplied. Firstly, since e^a * e^b = e^(a+b) and k = e^(lnk):

k * e^(-c*age) * e^(d*[time before next edit]) = e^(lnk - c*age + d*[time before next edit])

Since only the ordering is important, any function that's a monotonic function of this will do. Thus, we can take the natural log, drop the constant, and divide by a constant, and get a much simpler function that increases when the original does, and also decreases when the original does, thus preserving ordering:

~= - age + (d/c)*[time before next edit]

And we get, finally:

Stability score = [time before next edit] - age * c

• The "[time before next edit]" term (noise rejection) represents the approximate amount of correct (non-erroneous) information in the revision.
• The "age" term in the final equation (signal sensitivity) represents the approximate amount of omitted/no longer relevant information in the revision.

The two terms together approximate the quality and completeness of a revision (respectively). The weight ratio between them ('c' in the simplified formula) represents the relative importance between the two.

For some context, the original formula was deduced from taking an information theory perspective. It assumes that:

• New information is produced, on average, at a constant (bit) rate per unit time. The term e^(-c*age) directly follows from this assumption as "approximately how much of the information in the article is current/up-to-date".
• The probability that an error will be spotted and fixed at any given time is proportional to the quantity and severity of errors on a page. The term e^(d*[time before next edit]) directly follows from this assumption as "approximately how much of the information in the article is accurate/non-vandalized".

This is why I say that this formula is the most "natural": because it directly follows from only two, very reasonable assumptions.

(However, Sinan's modifications of the formula (which he uses for stablepedia) make it no longer optimal for the two assumptions.) Kevin Baas^talk 15:49, 7 April 2008 (UTC)

Automation: Commonality in last 10 days

One automated option to create a stable version would look at all versions created in the last 10 days, and automatically retain all common sentences. (in some cases, the article could have changed so much that the program would not be able to handle it). The software could be enhanced to exclude sentences tagged for POV and other content issues.

This would provide a "consensus" article, helping reduce vandalism and POV statements.

Because of the processing power required, this may not be suitable for on-line display, but well for a printed version of wikipedia. Pcarbonn 21:30, 5 March 2006 (UTC)

Automation: Common version (majority of time over a 3 day period)

Vandalism fortunately is usually caught quickly due to the watchlists. The result is that there are often extended periods where a version is stable, but with that stability punctuated by vandalizing edits which are quickly reverted. None-the-less, there is a text that is present the vast majority of the time in those cases. That text is obviously the desired stable version.

Here is a simple automation: If the last edit is more than 2 days ago, the current version is tagged as the "stable" version (if it is not already tagged as such). Otherwise, when an edit is saved, a process will be run looking for a stable version for that article. This will be the most recent version created in the last 60 days whose text existed as the current revision for at least a majority of the time over a 3 day (72 hour) period.

For the purposes of this calculation, two versions are considered to be the same is their text totally matches. Even one spelling correction would destroy the match in this case. However, I do not see this as a problem as minor edits which are retained will after two days have become the text present a majority of the time in a 3 day period. Also note that it is possible that an article may lack a stable version due to constant changes over the last 60 days, but if an article is in that much of a state of flux (or just plain new), is it justified for any version to be called "stable"? --EMS | Talk 18:45, 29 August 2006 (UTC)

Automation: relative "lifespan" of revisions (implemented)

The time needed for a vandalized page to be caught and reverted varies strongly from article to article. I have seen articles in which the current revision stayed vandalized for days, while others get reverted in a matter of seconds. Thus the process of selecting the stable revision is relative, and no WP-wide constants should be used IMHO.

I have implemented an algorithm based on the "lifespan" of revisions, that being: the time between the revision and the next revision. The basic operation of the algorithm is to check the lifespan of the a bulk of recent revisions, calculate the lifespan of each of them. Now the algorithm roughly knows how often the revisions occur. It chooses the most recent revision with a lifespan crossing a threshold, based on previous calculations. You can test the implementation here (stablepedia.org).

I am currently working on refining the algorithm (and of course any feedback is appreciated). One problem with my current implementation is that articles that suddenly become popular (like, articles about celebrities when something dramatic happens in their lives) might not give perfect result with my algorithm. Automatically assigning a "relative activity index" to the page at different points in time seems like a good way to overcome the problem. --Sinan Taifour 09:38, 27 March 2007 (UTC)

My "recent stable version detector" above has a formula that I believe is theoretically a perfect match. Though it doesn't go into dynamically calculating the constants c (how much the recent-ness of the revision affects revision choice; a "half-life", so to speak) and d (how much the lifespan of a revision affects revisions choice). perhaps d could be normalized such that e^(d*average lifespan of revisions over past x edits)=1, and c, likewise, such that e^(-c*average age of revisions over past x edits)=1. Thus giving "better than average" age the same weight as "better than average" lifespan. With this method, when there is higher activity on the page, c and d will adjust accordingly. Likewise, with lower activity. Kevin Baas^talk 14:38, 28 March 2007 (UTC)

And I think your site is great. :-) You deserve major props. My only suggestion would be to add a search box on the sidebar. Kevin Baas^talk 14:43, 28 March 2007 (UTC)

I can't see Wikipedians trusting a fully automatic stable version detection system as a way to flag Wikipedia articles. Semi-automation seems the way to go.

These proposals for automated stable version detection offer the promise of assisting whatever manual procedure is established for flagging stable versions. I can envision a tool that displays a modified history page that would also display a number of stability scores for each recent edit. People wishing to flag recent stable versions, could then ignore those edits with low scores and concentrate their attention on those edits likely to be stable.

BTW, if you haven't tried it yet, Stablepedia does work. Nice job, Sinan. SteveMcCluskey 19:58, 9 April 2007 (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)

• Idea! approve/dissapprove not versions, but diffs. at the simplest level, this reduces to approving/disapproving versions, but in the future this can be used to approve/disapprove changes at the section level rather than article level, with no extra effort on the part of the user. (in fact, this is exactly where the user would want to approve/disapprove: "i don't like that change" they say.) an approve/disapprove on a diff that spans multiple edits gives each edit 1 approve/disapprove vote. Kevin Baas^talk 21:51, 27 August 2006 (UTC)

Members of appropriate Wiki-Projects

There is a tendency for evaluations on Wikipedia to focus to a great extent on matters of form; anyone can judge if an article is clearly written, well formatted, uses proper references, and has appropriate illustrations. It is more difficult, however, to judge the content of an article, for this generally requires specialized knowledge

Since Wiki-Projects are places where people with specialized knowledge register themselves, it seems reasonable that voting be limited to people who were members of the Wiki-Project (or projects) dealing with the article at the time it was nominated. This will mean that those voting are more familiar than the average Wikipedian with the topic of the article and are therefore better able to evaluate the quality of its content. --SteveMcCluskey 17:55, 29 August 2006 (UTC)

Sounds like an excellent suggestion to me! You could still add in a 150 edit restriction or similar. Walkerma 18:14, 29 August 2006 (UTC)

Certification gang

If there are any well-educated and motivated individuals that are so inclined, I propose a sub page called /Stable (this is essentially Wikipedia:Baseline revision) and that the sub page is linked from the parent article page (eg. Mathematics → Mathematics/Stable). This sub page is protected and any changes must go via {{Editprotected}}. It doesn't matter if the /Stable page is much outdated by the latest version because as long as there is some sort of assurance that it is accurate. Make up a certification gang as per User:DavidLevinson/Future as suggested by User:Linas (see also [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)

Wikipedia:WikiProject Fact and Reference Check -- Zondor 05:38, 10 February 2006 (UTC)

A 90% majority of editors with over 3 months presence on wikipedia and over 1000 edits in article space at a rate of at least 150 edits per month, voting over a 1 month period, and listed in a "votes for stability" category

The above requirements should also be hard coded into the software. Just to make certain.

To make sure it is the clear consensus of a large majority of non-sockpuppets and non-meatpuppets, avoiding "sleeper" sockpuppets and meatpuppets. --Victim of signature fascism | Do people who don't think Jesus existed exist? 00:30, 2 March 2006 (UTC)

Editing stable versions: a panel process

I propose that a panel of three or five admins, knowledgeable in the subject matter, be elected for each stable article to serve as "keepers," once the working version is also fairly stable. "Fairly stable" means subject to no more than one edit per week, excluding minor spelling/grammar/markup edits, graffiti and spam, and reverts thereof. It also means no cleanup/expansion/maintenance tags, and that the underlying knowledge is not expected to change too rapidly (i.e. no current/scheduled events tags).

One keeper at a time would edit-patrol the working version, and respond to each edit within 24 hours according to the following rules:

• If it were graffiti or spam, s/he would revert it.
• If it only affected spelling or grammar, added a reference or external link, or affected the markup but not the text, s/he would choose one of three options unilaterally (but would still be expected to follow all policies and guidelines):
  • Revert it.
  • Carry the improvement further, then add it to the stable version.
  • Add the edit to the stable version without further changes.
• If it were larger, s/he would contact the other admins, and they would by consensus choose one of the above three options, within 72 hours of the original edit.

The end result would be no persistent differences between the stable and working versions, and a recognition that even stabilized articles can become a little closer to perfect. Seahen 15:07, 29 April 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.

Branchless stable version - Kevin's mods

Click where a thumb would be to flip to thumbs up(approve), click again to flip to thumbs down(disapprove). overall rating is shown in horizontal bar. Current stable version (highest rated) is highlighted. (sorry about the bad image editing)

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)

Same as above before "Added...."., with the following modifications:

• Each article has a stable marker, said marker cannot be moved explicitly, but is calculated by wiki software, as the version with the most approve minus disapprove votes:
  • Votes are approve/disapprove (or no vote)
  • Votes are made & shown in edit history and diffs.
  • All logged-in users can vote on any article.
  • Only the most recent few (say, 5) (approve or disapprove) votes per user per article are active, older votes are expired to "no vote".
  • Votes older than the xth (say, 3rd) most recent stable version, where the voter has not voted since said stable version, are expired (set to no vote), to prevent people not participating from causing stick.

Semi-automation. Also, there will be a software aid: "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.

Furthermore, on the history page, one could filter versions to see only the top handful (say,8) of stability scorers (and the current stable version), with current vote counts, and then look at the diffs, and vote. Kevin Baas^talk 22:27, 24 January 2006 (UTC)

And admins could set pages to automatic instead of semi-automatic. In automatic, the software will determine stable version based on the stability score, rather than community vote. This would be usefull on pages such as "current events". Kevin Baas^talk 23:06, 24 January 2006 (UTC)

Oh, and on the history page, little graphic bars showing the stability measure and approve-disapprove. (different colors). This is trivial to do. It's just a 1-pixel image given a certain height, and whatever width you want. Kevin Baas^talk 18:25, 26 January 2006 (UTC)

Oh, and you can't vote on your own edits (revisions) Kevin Baas^talk 17:36, 8 April 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)

Storing and reading

Proposals

Simple and (nearly) complete proposal

First some thoughts

I think we have to see the clear advantages of stable versions (not editable) and wiki-versions (editable) compared to each other:

• the stable version guarantees a very high quality of an article at a set point of time. (the point of time it was set as 'stable')
• the editable wiki-version is always up to date.

Each one has an advantage that the other one hasn't. To build the best encyclopedia ever, we have to provide the user both versions of an article. Stable versions for high quality and trustworthiness, wiki-versions for up to date information, the working extern links, etc. The user should choose self which version he or she wants to use - every time the user looks at an article he or she should be able to choose again, maybe the versions have changed or the users needs are different this visit.

For the wikipedia editor the stable version is mainly uninteresting as he/she cannot edit the stable version. But as still much of the information in the stable version and the wiki-version will be often the same (especially on articles about history or biographies), the editor can use the stable version to undo vandalism on the wiki-version much quicker and easier by simply comparing the stable version with the recent wiki-version.

When we'll finally add this stable version-feature, it will be a major change - or at least a major expansion to the Wikipedia. Therefore I think we should also make this feature as simple and easy to use as possible. Otherwise users and editors will get confused about too many different versions of one and the same article or concerns may arise whether the wikipedia is still a wiki or not. For the beginning, the wiki-mechanism should stay exactly as it is with an added stable-version-feature. And the stable version should be consequently stable - means not editable at all. I think this simplifies the stable-version-thing very much and we can see how really not editable versions work practically.

Concrete implementation of stable versions

Keeping all these things in mind, I think the stable-version-feature should be implemented at first more or less in the following way. There is one article which has its history of many, many versions (every time someone edits the article a new version is created an the old one is archived in the "history"-tab) - the wikipedia works already today like that. When we now decide that the article has right now a high quality we pick the version it has right now and mark it as 'stable'. Until we pick the next stable version (maybe a few months later) the version we picked is the stable version. I think it could be that simple and it would work. One article, one history, a specific version marked as 'stable' which is easy accessible.

The details: Everybody should be able to use the Wikipedia in exactly the same way he or she did it until now, so nobody gets confused. One article exists on one page and is available for example under the URL "http://en.wikipedia.org/wiki/Mathematics". As default is the wiki-version displayed (as now). On top of the page are the tabs "article (wiki-version)", "discussion", "edit" and "history". Every time someone edits the article there'll be created a new 'version' which is listed together with all the previous ones in the "History"-tab. So far everything is as it already is.

With the stable-version-feature there come the following expansions to the current system: There is an additional tab called "article (stable-version)".

Article (wiki-version) - URL:"http://en.wikipedia.org/wiki/Mathematics"

The "article (stable-version)"-tab leads to the URL "http://en.wikipedia.org/wiki/Mathematics/stable" where the latest stable version is displayed. On this page are only the tabs "article (stable-version)", "article (wiki-version)" and "history" as this version cannot be edited and the discussion page is about the recent (wiki-version) article. On top of the stable-version page is a box which says: "This is the latest stable version of this article which is from 28.09.2004" (for example).

Article (stable-version) - URL:"http://en.wikipedia.org/wiki/Mathematics/stable"

If you go to the "history"-tab everything looks as usual, except that the specific version of the article which is now the stable version is marked as "latest stable version" (below the older versions, on top of it the more recent versions up to the current wiki-version). As time passes on there will be a second stable version which replaces the first one. And there will be a third stable version... The old stable versions are marked in the history tab as 'former stable version' and on top of the whole history-edit-list would all stable versions be listed again, to find them quicker. It might be interesting to look how a good (stable) article about computer looked like 10 years ago.

History - URL:"http://en.wikipedia.org/w/index.php?title=Mathematics&action=history"

The stable version from 28.09.2004 would always be accessible trough the URL "http://en.wikipedia.org/wiki/Mathematics/stable/28_09_2004" while the latest stable version always would have the URL "http://en.wikipedia.org/wiki/Mathematics/stable". (Instead of the URL "http://en.wikipedia.org/wiki/Mathematics/stable" I could also imagine "http://en.wikipedia.org/wiki/Stable:Mathematics". I don't know which one is better.)

If somebody wants to improve the quality of an article so that the current version can become the next (or the first) stable version, he/she could put a mark on the page (with a small symbol similar to the 'featured article' star). Now everybody knows that this article is heading to a stable version and can help bringing it to that level. When the involved people think the article is ready one of them chooses the current version and puts the article with the current oldid (number which identifies a specific version of an article) on the 'stable version candidate page'. Now it goes like with the 'featured article candidates'. Maybe some rules have to be added or created. While it's being debated if the proposed version is good enough for a stable version the article itself can be further edited and by doing so new versions are created. However, the stable version of the article would still be the proposed (now already a bit older) version.

Who decides? - I don't know

I haven't answered the question on how the decision on the 'stable version candidate page' is made. It might be some kind of consensus approved by a final vote of the administrators or bureucrats or whatever. I have to say I don't know too much about these evaluation processes in the wikipedia. Let's discuss that on a separate place. Here is the 'justice system' - who the 'judges' are has to be decided somewhere else.

So what? let's try it?!

I think this (or a very similar way) of implementing the stable-version-feature does serve us for the beginning very good. It provides all the important functions of stable versions, is simple and easy to use while still not interfering the wikipedia as it works today. When we see how this all works out we can still add more features as for example the Coda proposal (see above) to solve smaller problems with the stable version. But until then a stable version should be what it is - not editable, in no way - just replaceable, by the next stable version.

Or maybe when stable versions have proven very, very useful we can display them by default. But for now I think to display the wiki-version at first is saver. (Of course every user should be able to set that in his/her account preferences - but most of the visitors have no account) So what? I hope on your comments and improvements to this suggestion! And at some point we should get started! As already said: I think it's a quite good model to get successfully started with stable versions!

Mauro Bieg 22:26, 3 February 2006 (UTC)

• Brilliant! To answer the question of who chooses... well, to start, we can simply use featured articles (the version accepted as the feature article) as the very first batch of stable articals. Perhaps, from then on administrators could "stabilise" articles, with some kind of restrictive criteria to adhere to. ---J.Smith 20:06, 15 February 2006 (UTC)

• • But the 'experimental process' is proceding on the basis that FAs are merely a starting point, and need to be further reviewed before being declared to be "stable". I think it's very important to be clear about the different objectives here: determining stabilisable quality, on the one hand (which will involve deciding what that's to be); and setting up mechanisms to support stable-version-prefered or stable-version-only browsing of some kind. And then either a) ideally, just pick one, or b) at least, be explicit about which one is considering at a given point in time. Alai 23:20, 15 February 2006 (UTC)
    • I agree with most of the proposal. I proposed a similar idea months ago. The one difference is that my proposal accepts more certified versions than just one called "stable." There could be one called "accredited" for the version last accredited by an academic society. That would allow a good weight for schools to use Wikipedia as a reference. Other than that, I also proposed that we use the word "Production:" or "Article:" for the namespace name instead of "Stable:" if its uses a namespace.

Different namespace

Coda proposal

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

The coda might include the following sections:

Errata

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

Additional see also and Additional external links

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

Subsequent developments

Stuff like:

• "The author died in a kiln explosion on March 4, 2007.

• "The 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)

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

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

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

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

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

Different modes

User flips a binary switch on the wiki, between development mode (unstable) and release mode (stable).

What version will users see first?

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

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

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

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

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

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

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

I like the idea of having a tab to see the stable version, and a user preference to view stable versions by default. Kevin baas 20:59, 24 January 2006 (UTC)

I like the idea of having a tab to see the working version, and a user preference to see the working version by default. Having the stable version not be shown by default somewhat defeats the purpose -- the average user will use whatever "comes up on his screen" first (e.g. whatever page he sees first). It can be made quite obvious that the current page is a stable version -- so I don't think the delay in editting will turn off new users: in fact, I think it would do quite the opposite, instead making them more feel more secure with the information they get. Most of the people I know who aren't very interested in computers distrust wikipedia for numerous reasons. Seeing the stable version first would give them more faith in the accuracy of wikipedia. michaelb 16:22, 8 February 2006 (UTC)

I, as mostly a reader, would favor to see stable version first (default). Here is my reasoning: Either I am interested in topic of the page or not. If I am not so much interested, I will go through the page quickly, so if there is any mistake, I won't probably study if it is correct on the stable (other) version, or if there is some radical new development. Also, I will have much bigger chance to spot vandalism (which I am not interested in), if the page is unstable. On the other hand, if I am interested, I may take time to read through the page, so one click to unstable (new) version isn't so much burden. And if I would decide to cite Wikipedia, I would probably used stable version, but still checked the other version, talk page, etc. If I find a bug, and I am willing to fix it, I may be interested to see other version too (either stable or unstable). It still takes much more time (except trivial typos, which would be usually fixed before new stable version) to do a bugfix than to click on the other version. So, from the general user POV (not active Wikipedian), I think it's obvious to want to see stable version first. Samohyl Jan 19:44, 30 January 2006 (UTC)

Software mechanisms

News

Article validation feature "going live soon"

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

This looks like a really great tool for fighting vandalism and other bad changes, which is also a motivation for stable versions, but in my opinion stable versions (as I imagine them) still solve an important problem that article validation does not: in the stable version of an article, new and unpolished "rough draft" content which has not been edited for style and fact-checked is never present. In a working article, it's necessary to have changes that in the short term detract from an article until they're "cleaned up". Any change to a stable version not only undergoes great scrutiny, but changes with substantial "risk" of detracting from the article even in the short term would be disallowed entirely (such changes would only come in with the next "release" from the working version). Deco 02:17, 16 December 2005 (UTC)

Yes, but how does one "pick" which version shall be the "stable version", and isn't "article validation" just another name for "picking the stable version"? linas 17:45, 16 December 2005 (UTC)

Hrm, maybe I'm confused about exactly what article validation does. I have to look at this some more. Deco 21:34, 16 December 2005 (UTC)

Okay, after looking further at this I better understand article validation. Article validation allows users to rate a particular version of an article. New versions which have not received a sufficient number of positive ratings are not displayed by default. Users have the choice of seeing the latest positively-rated version or the most recent version. This seems to be very similar indeed to the original proposal discussed here (without branching). Deco 23:26, 16 December 2005 (UTC)

an email

Selection automation

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). D is much greater than c (d >> 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)

What about obscure articles that someone has vandalised/added spurious claims into, but no-one has noticed for a year? --Victim of signature fascism | Do people who don't think Jesus existed exist? 00:36, 2 March 2006 (UTC)

good point. I would suggest to remedy this, one, some, or all of:

• a minumum raw approval vote threshold for a version to become the new "stable" or what-have-you version.
• a minumum article volatily threshold for using semi-automation - the article has to be frequently edited for semi-automation to be turned on, otherwise it turns off.
• semi-automation calculations are at each edit rather than on each view.

Kevin Baas^talk 02:40, 8 April 2006 (UTC)

No, not-recently-edited is not what "Stable Versions" are about. The word stable is misleading. The aim is to provide reliable, informative articles, not just mark articles that haven't changed for a while. "Stable" is a term coming from experienced wiki editors, whose perspective (currently) is that articles are usually in flux. From the point of view of a reader of an encyclopedia, the stable article should be more like a "quality assured" article , or a "reliable" article , or a "published" article , or "vetted", or "approved", or "released", or... The interface for general readers very much needs to distinguish stable articles from wiki-draft articles, but not through the use of the term "stable". -R. S. Shaw 03:39, 2 March 2006 (UTC)

The c and d parameters can be set at extremes to make the semi-automation almost non-existant. The main purpose of the semi-automation is so that people don't have to "de-nominate" the formerly "released" version in order to nominate the "new" released version. With the c and d parameters at the proper extremes, the system will work as you have suggested.

General

Goals

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

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

(moved from post-archival post in archive Kevin Baas^talk 18:17, 26 January 2006 (UTC))

I'd like to have vandalism free and fact checked articles. Markus Schmaus 03:08, 1 February 2006 (UTC)

Reduction of vandalism, pov, and for inclusion in WP:1.0. Gflores ^Talk 20:04, 10 February 2006 (UTC)

Sub pages

I personally don't like the organisation in subpages. Ongoing discussions came to a halt and it is very hard to find any new contributions.

I would prefer if all the topics were aranged on a single page. (Markus Schmaus too lazy to log in) 129.187.163.33 18:38, 31 January 2006 (UTC)

Well given that I made the subpages and share your dismay over the recent drizzle, go for it. Kevin Baas^talk 19:05, 31 January 2006 (UTC)

After the subpages, you had to go back and add those pages individually to your watchlist. People who were watching this page may not have noticed... --Tsavage 19:17, 31 January 2006 (UTC)

I'm sure people watching this page noticed, insofar as they were watching this page. Kevin Baas^talk 19:28, 31 January 2006 (UTC)

There, how's that? Kevin Baas^talk 22:52, 31 January 2006 (UTC)

I also like all the topics on a single page. Fragmentation of a page stymies discussion and interpollination of related discussion areas. Deco 08:17, 1 February 2006 (UTC)

Reliablity

I think that this is a brilliant idea. The most important think that makes this beeter then just FA status is that when I reader comes to read a stable version they can be secure in the knowledge that the page they are reading has been thoughly cheacked. With the wiki-articles even if editors pick up vandalism very quickly at any moment a reader can not know for sure that s/he is not reading a a version that has just been vandalised/had unreliable information inserted into it.
However, I do not think that the stable version should become the version the reader sees first as this would discorrage editing.--JK the unwise 09:39, 10 February 2006 (UTC)

Research / Relevant stats

Average End Quality Hypothesis

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

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

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

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

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

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

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

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

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

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

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

A couple of comments here: these are very interesting thoughts, but it's difficult for me to see "article quality" as a monotonic function; the injection of one bad fact (maliciously or inadvertently) can have a dramatic impact on the usefulness and trustworthiness of an article -- a drop of poison can spoil the well, so to speak. Also, my experience with certain articles does not actually match your graphs; for example Rock and Roll / Rock music has been a butchery after some well-meaning folks took a mostly-OK article and went overboard with sub-articles and a main article split. Finally, it's important to recognize that all the up-and-down fluctuations you picture (indeed, any change to the Wiki) represent effort expended by editors. We often find ourselves pushing the boulder halfway up the hill, and turning around only to have it roll most of the way back (I'm not talking about simple vandalism that can be easily reverted but big ugly dump-edits that require major effort to clean up, fact-check, and integrate). One side benefit of a Stable Versions process is that it puts chocks behind the boulder every so often. Jgm 15:11, 29 December 2005 (UTC)

Your analysis is similar to the sentiment of most of the experienced people invlolved in FAC and FARC. In fact it's one of Raul's laws. Featured articles tend not to improve once they are featured, in fact they generally degrade unless they have a particularly vigilant watcher or someone comes in to revamp them. It's clear then that a different system is needed to consistently bring articles above the AEQ. The current system works well to produce a mass of information, but on the whole is probably not able to take it higher. Many of the things mentioned here such as formal expert review may be able to lift the quality consistently above AEQ. - Taxman ^Talk 15:19, 29 December 2005 (UTC)

I don't really believe the AEQ is true in general; I believe any article can be substantially improved by the right editor, but just that it sometimes takes a while for that editor to show up. Additionally, any scheme which attempts to protect the working version will effectively prevent cooperative work on an article. If a Honduran scientist adds technical details to global warming with terrible grammar, and this is subsequently cleaned up by an American user, we have a net improvement that could not have been accomplished in one edit by either user. This is a fundamental advantage of Wikipedia. Stable versions allow these "refinement" stages to complete before publication while still giving access to the information to people who would rather deal with the temporary lower quality for more cutting-edge content. Deco 19:31, 29 December 2005 (UTC)

I think that it definitely takes work to keep articles at high quality, and I like the graphs as a way of expressing that. I agree with most of what's been said in this section, in fact. But I'm concerned that whoever the "guardians" of the stable version are will use their status and sense of self-importance to keep out legitimate edits because they overvalue their own ideas relative to other people's. Some editors have very firm ideas about their own writing styles, the needs of readers, NPOV, etc. that we might not all agree with. While the current system isn't perfect, since improvements can be reverted capriciously, at least those edits have a chance. I'm not sure what the solution is. After reading this section, I've become less opposed to stable versions. But I am concerned about this. I just thought I'd lay out my ideas and see if anything useful comes from them. Keep up the good discussion, Dave (talk) 04:25, 30 December 2005 (UTC)

Stable versions only entails protection of the stable version. It should only be necessary to edit the stable version (if at all) for small things that are clearly wrong like inaccuracies, misspellings, and broken links; anything contentious shouldn't be changed there anyway. Any other changes will be incorporated into the working version via the current process and subsequently published in the next stable version. And I stress again that the two versions should be viewed as just two different forms of the same article which a reader can freely choose between without emphasis on either. Deco 08:00, 30 December 2005 (UTC)

Right. I'm worried about the social implications of having an officially sanctioned version. People have accused me of ruling Libertarianism too tightly, because I felt like I had some kind of ownership of it after pushing it to FA status (that was six months ago... since then, I've let the article do its own thing until a few weeks ago). I'm concerned that such situations would become more common, not because of any technical limitations of stable versions, but instead because of what it will mean to the (human) editors involved. Dave (talk) 08:25, 30 December 2005 (UTC)

There will always be edit wars. If there is no consensus, then that article is not ready to be stable. If anything, it can help force the article to reach NPOV more quickly. -- Zondor 08:45, 30 December 2005 (UTC)

That's actually my concern. I've seen situations where users have used the drive for a stable version as a reason to reject good changes, and I'm worried about codifying that. Dave (talk) 08:53, 30 December 2005 (UTC)

Your concern is well founded. But however "good" it is, it could be POV. -- Zondor 09:58, 30 December 2005 (UTC)

This is an interesting point, and I've been guilty of possessiveness on occasion too, but I think the effect will be diminished compared to the drive for FA status, because there are two versions - during publication of a stable version there could be an opportunity to cut out incomplete or controversial parts, or to mix and match parts of working versions, so there's less temptation to view destabilizing edits aggressively. The way I imagine it is there could be a temporary freely editable "preprint version" that is assembled for publication and voted on. Of course one has to avoid the temptation of doing substantive editing in that version instead of the working version, but I think it could help.

As for the social implications of singling out some editors over others as owners, that is a concern. There could be a process for adding and removing owners, but considering that their "powers" would be limited to typically insubstantial stable version editing, maybe their role should be downplayed; we could call them "maintainers" or something boring like that. Deco 10:24, 30 December 2005 (UTC)

Without actual stats to demonstrate, AEQ seems like a convenient assumption: it will apply to some articles, but to how many, and for what underlying reasons? The statement above, any article can be substantially improved by the right editor, but just that it sometimes takes a while for that editor to show up, whether directly intended to or not, points to an aspect of "quality" that hasn't really been discussed here, writing quality. The fact that we are writing an encyclopedia, not simply collecting verifiable "facts" in a database (like IMDb), puts a lot of weight on how an article is written. The articles I've watched that have come up from stubs tend to be first an assembly of an increasing number of pieces of information, often with phases of discussion or debate between editors, and then things quiet down. What's left is a pretty much "everything's there" article that is readable, but is quite dry and cumbersome. At this point, I think we're "waiting for a writer". There are other, different skills and talents involved in copywriting, prose writing, journalistic writing, technical writing, encyclopedia writing than expertise in the topic. And writers tend to come along later, to reorganize, re-edit, rewrite, to produce a final, clear, readable product. (I can cite a number of recently celebrated WP articles that are simply not any fun to read, where your eyes do glaze over...) To put it broadly, IMO, the biggest difference between WP and Britannica at this stage is, in the end, their final product is written by skilled, professional writers. Stable versions must recognize this aspect of "encyclopedic" in whatever mechanism is considered to select and update stable articles, and it must allow revisions to be made freely made for writing quality, not just "verifiable information". --Tsavage 17:04, 21 January 2006 (UTC)

I think that is one of the most valid concerns I have heard.On the other hand,that's human nature and any work made by humans is vunerable to POV.I don't even think the other major encyclopedia's can work arround this.I don't think the current situation is any better now,they just fluctuate between POV's.

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

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

I find these comments to be excellent, though I do disagree with protecting the article against further revisions and "gating" new edits on the article. That's what I think a stable revision would be good for: the stable revision would not be changable and then what you do is use that revision to try to gather just how good the previous articles were. A good example of this was Christmas, which was a very different revision on FAC than is currently. A revision marked as stable would have been a very good idea on this article, and we could have just done a diff to see what had changed substantially. - Ta bu shi da yu 09:18, 2 January 2006 (UTC)

That's a good idea. It was partially implemented a couple of weeks ago in the FA tag, but the "version" link only calls up the entire history page, it's not a direct link to the promoted version. Perhaps going throught the current 800+ FAs and putting a link to the promoted version (easily found in History) on the Talk page would provide some relatively quick and useful "data" relating to AEQ and the articles hit a peak and then slide downhill hypothesis... --Tsavage 17:35, 21 January 2006 (UTC)

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

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

Basic Wikipedia editorial stats

Having some general figures available to inform the discussion seems like a good thing. I don't know if these are readily available somewhere already, but here's a starter list.

Basic stats

Number of articles: 946,207 (30-Jan-2006)

Number of stubs: 366,102 (as tagged, approx as of 08-Feb-2006)

Number of Featured Articles: 878 (30-Jan-2006)

Number tagged for editorial dispute: (POV, merge, etc)

Number tagged for administrative action: (in process for delete, merge/redirect; a short-term average most useful?)

Number of unstable (highly active) articles: (perhaps a function of number of edits over a period)

Graph of article creation and deletion over time (would probably include merges as deletions)

Number of registered users: 898,618 (as of around 08-Feb-2006)

Number of registered users who have edited: approx. 120,000 with 5 edits (from newspaper interview with the Founder, Mar 2006)

Number of active editors: (registered only or all editors, based on something like X article edits over Y period of time)

Other stats

These may be useful and/or harder to derive.

Number of articles by size: 368,570 <1K (stub); 554,711 1K-8K; 60,256 8-32K; 5,483 >32K (see table below for breakdown)

Number of articles by number of editors: (in ranges: 1 editor, 2-5, etc)

Number of IP editors: (article edits attributed to IP numbers)

Number of articles locked: (protection by article not instances of locking, average over a short period?)

Number of Featured Articles per editor: (successful nominations by nominator; this would probably be manual slogging through the archives, but could be useful to "statistically" refine the idea of "who does what")

A current snapshot would be good, but also, having daily or weekly or monthly updates somewhere on an ongoing basis would be a useful tool as well. --Tsavage 22:59, 30 January 2006 (UTC)

I agree, we need some numbers here. Maybe some of these stats can be obtained from Wikisign.org? Gflores ^Talk 20:33, 11 February 2006 (UTC)

Yes, that's great, thanks! (I really wonder why "no one" seems concerned with basic numbers, i.e. a reasonably accurate description of the situation being discussed...) --Tsavage 02:04, 15 February 2006 (UTC)

As it happens, I've been working with a recent dump, and can give you guestimates for at least one of the above: the total number of stubs (well, articles tagged as stubs) is somewhere in the neighbourhood of 366102. I'll probably have a more accurate number, plus be able to take a stab at the above articles-by-size stats, once I correlate the "page" data with the "categorylinks". Alai 02:43, 15 February 2006 (UTC)

That's cool, I added It above. Stubs could also be estimated based on article size as well. Maybe two separate numbers, by stub tag and by size...? I don't query databases as a usual thing, so I'll figure that out and see what I can get. If you have stuff, please fill 'em in! --Tsavage 03:43, 15 February 2006 (UTC)

That's all for now, but I should have more as and when I deal with my "current technical limitations", hopefully relatively soon. Off the top of my head, anything less than 100 bytes is likely "not even a stub" (redirects, etc), and one could take some equally arbitary upper cutoff, perhaps 500 bytes or thereabouts, for "presumed to be a stub". I know the 'official count' of the number of articles uses some criteria similar to the former, and various untagged stubs/short pages listing something along the lines of the latter, but off the top I don't know any particular numbers. Alai 04:34, 15 February 2006 (UTC)

Here's a breakdown of size of non-redirects in the main article space, using a binary-order-of-magnitude progression. As the rows before 127 probably aren't very interesting, I've collapsed those to one.

Article sizes

size >= (bytes)	num articles
0	8419
127	46691
255	116130
511	197330
1023	235352
2047	216682
4095	102677
8191	43792
16383	16464
32767	4646
65535	743
131071	85
262143	8
2097151	1

Note that the total is 989020, which seems to be somewhat at variance from other "numbers of articles" stats. Alai 21:22, 15 February 2006 (UTC)

This is interesting, as it's consistent with about 300k entries being stubs. Another interesting statistic would be to bin the articles based on number of distinct users editing them, to see how many single-person essay articles there are. Is this a statistic that it's feasible to extract? --Christopher Thomas 21:54, 15 February 2006 (UTC)

I suppose it indicates that the de facto stub threshold is somewhat > 500B, but certainly < 1K. (I may do a separate size breakdown of the tagged, and the untagged so's to clarify this.) I don't currently have access to any page-history (or indeed, current page text) information; those are in separate db dump files, and are sufficiently large as to deter me from tackling them in the immediate future. In fact, I think the history may only be in XML format, and so may be less straightforward to run queries on directly. To throw some more numbers into the mix, according to the "site_stats" table, there are 960172 "good articles", 3318865 "total pages", and 898618 "editors". Doubtless there are definitions kicking around someplace for how these are are determined. Alai 22:37, 15 February 2006 (UTC)

Incidentally, I in particular don't know if that's registered users: a cursory check doesn't find any documentation that makes this clear. OTOH, that interpretation does seem to roughly reality check; I assume the total number of IP addresses ever used would be much higher, and I don't think it tallies with the number of user pages (only 358438), so that seems the most likely. These are all based on the most recent db dump, btw; I'll indicate the date above. Alai 04:26, 16 February 2006 (UTC)

On the "Number tagged" stats: these would be relatively do-able, given an exhaustive list of all applicable categories (the roots of a forest of categories would probably suffice). Likewise, number protected (and semi-protected), though in this case depending on on their having been properly tagged, not just "silently protected". (Not that that ever happens, of course.) Alai 05:45, 16 February 2006 (UTC)

I still have to get with the querying... In any case, I hope this doesn't get forgotten! :) --Tsavage 23:55, 22 February 2006 (UTC)

Well, if someone wants to volunteer to compile said exhaustive list... Alai 06:05, 23 February 2006 (UTC)

Sorry, I'm confused... what is the purpose of these statistics in relation to stable versioning? Maybe you can shed some light. Thanks. :) Westfall 05:16, 25 February 2006 (UTC)

The idea is to figure out how many "real" articles Wikipedia has, which will give some idea of the scope of the task if the goal is to make stable versions of most useful articles. That, and these statistics are neat.--Christopher Thomas 07:14, 25 February 2006 (UTC)

Sounds like it's mostly the latter, the stats are "neat". The thing facing us is getting the stable versions mechanism implemented, not worrying about the size of the job that follows. (It's not like everyone is going to call it off just because there are 900,000 articles instead of 700,000.) -R. S. Shaw 08:09, 25 February 2006 (UTC)

I'm not sure what you mean by mechanism. Most of the discussion here is about ways to protect stable versions, with little ongoing talk about the selection process. Without a clear idea of how articles are going to be selected, which critically includes the SIZE of the project (it's not difficult to vet 10 or 50 or 100 articles, but 4,000? 10,000?), all of this is at best futile, at worst, a real mess, if by chance we start protecting versions that aren't very good, just because we could. Making plans without having a clear description of the objective doesn't seem...prudent, or effective... Every article isn't going to be an overnight stable version, but having a better idea of how many "real" articles they are, what size they are, how many editors are "active", and so forth, seems to be better context than, "one million articles, let's do it..." These stats aren't a five year study proposal, they're basic information about WP... --Tsavage 08:06, 27 February 2006 (UTC)

developmental, alpha, beta, stable

The current nomination process is not so good because it rushes into the final stage when its not ready. The stable versions process should be like this:

Developmental → Alpha → Beta → Stable.

Developmental is the wiki. Alpha is when the article looks reasonably complete. Beta is when the article is declared complete but not released officially and waits for a set period to pick out the last remaining minor errors. Then its stable - ready to the printed to be given to millions and millions and of people to read on paper. -- Zondor 07:48, 6 February 2006 (UTC)

• Developmental - no status
• Alpha - Wikipedia:Good articles
• Beta - Wikipedia:Featured articles
• Stable - Wikipedia:Stable versions

There should be a prominent header templates for good articles, featured articles and stable versions to proclaim their status to progress along towards the goal of 1.0. -- Zondor 08:00, 6 February 2006 (UTC)

Supposing you're implying an analogy with the software terms here, I think this is a false analogy. A stable version of an article is not quite like a release version of software - it's more like a release of any type. In other words, I imagine it more like this: there are 3 versions of each article, one the developmental version, one the most recent beta release, and one the most recent release version. The developmental version is wiki editable, and both the beta and the release version are stable versions.

An article in a good state can publish an alpha version, which is just a temporary copy reviewed by interested contributors for any big problems. Once this is done a "public beta" version is published, a stable version with a big warning at the top saying something like this: "This is a beta version of this article. We believe it is high quality, but we're hoping readers like you can help us find any small issues we might have missed. Please add feedback at blah, blah, blah."

After we receive and incorporate feedback from the beta version, and modify either the beta version or development version accordingly, we can publish a release version. I think "featured articles" may be too high a standard - this might be the target of a version 2.0 or 3.0 release version.

On a less relevant note, I think we should steer clear of software terms and use terms from books like "draft", "published", "preprint", whatever. Deco 11:00, 6 February 2006 (UTC)

--- stub ---- good article ----------------------------- better article ----------------------------------------->
                  |                                            |
                  |                --------------------------  |                --------------------------
                  --- review ----->| published 1.0 (stable) |  --- review ----->| published 2.0 (stable) |
                                   --------------------------                   --------------------------

129.187.163.33 18:16, 7 February 2006 (UTC) (Markus Schmaus)

Sorry, I was in a hurry and still am. The above illustrates how I imagine stable versions. I think branching and review is neccessary for orthography and fact checking. Markus Schmaus 22:03, 7 February 2006 (UTC)

I concur. I wonder if we will be conveying these "version numbers" to readers in any way, as an indicator of maturity, or if that's considered internal to the process. Nice ASCII art. :-) Deco 22:21, 7 February 2006 (UTC)

If there is a version 1.0 and a version 2.0 (and 3.0, 4.0, 5.0, etc.), all of them would be valid, I believe. Unless, a version is deprecated. Having a version 2.0 stills allows a working and useful version 1.0 which can be updated as version 1.1. They are all useful in parallel. -- Zondor 10:06, 9 February 2006 (UTC)

I think we should always work on the development-(wiki)-version to avoid forking. And every time we think the wiki-version has achieved a better level of quality, we can publish a new stable version. The question is for me more, how often that happens and at what qualities. I wrote some days ago a proposal for a simple stable version mechanism and published it on the logical right place on this discussion site: "4-Storing and Reading" -> "4.2-Proposals" -> "4.2.1-Simple and (nearly) complete proposal". I guess nobody noticed it because it wasn't at the end. Should I move it to the end of this page or keep it up there under '4.2 Proposals'? I'm waiting for your comments and suggestions up there! Mauro Bieg 10:34, 8 February 2006 (UTC)

Those conceptual pictures are great. -- Zondor 13:20, 8 February 2006 (UTC)

I've stressed at least a dozen times why the benefits of forking exceed the negative effects in this case. It's the only way we can achieve high quality while continuing to develop the article. Deco 16:47, 8 February 2006 (UTC)

I am going to put the nominated versions in Talk:Early life of Joseph Smith, Jr.#Stable versions and Talk:Wikipedia#Nomination for Wikipedia:Stable versions as Stable Review Versions in /Stable subpage for each article; prior to being Stable Release Versions. These names are subject to change to be more appropriate. I need to protect these subpages for that but it may come in conflict with the protection policy (Wikipedia talk:Protection policy#Stable versions). I call upon any administrators who can help us do this. The important idea behind this is that there needs to be a phase where the nominated article can undergo "beta testing". Thus, the criteria for nomination is that the article is considered "alpha": complete. Nominating a "pre-alpha" isn't worthwhile, perhaps. Thus, we have two purposes and roles for the wiki and stable article. Wiki is for editing and stable is for "testing". -- Zondor 15:23, 8 February 2006 (UTC)

Early life of Joseph Smith, Jr./Stable is now protected (by me). The template looks perfect, except that it doesn't provide a link to a place for nonadmins to put corrections. I assume we'll just use the talk page of the stable version for this. Deco 10:20, 9 February 2006 (UTC)

Perhaps, a quick makeshift way to make the stable version the default view is to put the wiki version on the /Wiki subpage and redirect the main article page to the /Stable subpage. The stable sub page would need to link to the wiki sub page. -- Zondor 11:11, 9 February 2006 (UTC)

I don't believe we have enough consensus to make the stable view the default, especially at this stage. Deco 05:14, 10 February 2006 (UTC)

I'd like to suggest everyone take a read through the stable page above and look for any potential problems. If you see them, even if you're an admin, post them on the talk page. This will help bootstrap the process. Deco 08:11, 10 February 2006 (UTC)

There is the notion that having stable versions shown by default will discourage "improvements". However, there is a different sort of improvement for stable versions. You can't improve the Stable Review Version by any more open editing, but by "testing" or reviewing in a protected environment. Wikis are excellent for development but static pages are appropriate for the final stage of the article. So showing the Stable Review Version by default improves the article by checking for errors. Once it is published as a Stable Release Version, the default view can then go back to the wiki version. -- Zondor 09:02, 12 February 2006 (UTC) Instead of "You can edit this page right now!", you have "You can review this page right now!". -- Zondor 09:10, 12 February 2006 (UTC)

Failure

Stable versions is a failure. Although, it's a nice in theory but it's too expensive to have. People like the dynamism and instant editability of the current system which is why it has been successful. Stable versions is backward like how Nupedia failed. -- Zondor 02:56, 13 February 2006 (UTC)

Hang on, when and where and by whom was it decided that it was a failure and that the "historical" template should be added? I for one agree with the idea: I really think that the benefits of having stable pages - users always know that they are viewing an approved, reliable version of an article - outweigh complaints such as that "it goes against the wiki philosophy". I reckon TidyCat's proposal is a great way to go about it. --Nick R^Talk 13:16, 14 February 2006 (UTC)

How is it a failure? And there is still instant editability, there is just also a stable version. Chris M. 13:18, 14 February 2006 (UTC)

Not. Hasn't been tried; can't be a failure. "Too expensive"–how? "People like the dynamism"–sure, and they can still have it. Just because there are two versions available for some articles, only one of which is dynamic, does not take this aspect away. For wiki-adicts, they can live in the cutting-edge world of the current drafts, and it still looks just like today. For the online reader, more reliable, less vandalized info is available. "Like Nupedia"–No, this is quite different. Danger of too much bureaucracy and contention? Yes, but it can be minimized. Maybe the stable versions idea is just {{historical}} for Zondor; he needn't hang around contributing to it, but the pages here are clearly too active to be considered historical for Wikipedia generally. -R. S. Shaw 22:39, 14 February 2006 (UTC)

It isn't so expensive considering the investment that is put into it. The effort put into version 1.0 can very well be used not only by and guide the wiki version to be easily developed, but also used by version 2.0, 3.0, etc. The effort is cumulative. Expect version 1.0 and such to last for hundreds of years or even more. -- Zondor 06:27, 16 February 2006 (UTC)

I think what you mean by expensive is that people are uncomfortable with the idea of a separate stable version page to the wiki page as it makes it more complicated to deal with two separate things at the same time. I propose we should have the following instead. Given a wiki article that is ready to become a Stable Review Version, users have a vote or consensus to slap on the {{stable review version header}} on the article and protect it (or not?) to enter the Review phase of the article development. This effectively means that the Stable Review Version, as we have now, becomes the default view. Users can also have the option to go back to the developmental phase at this point if they change their mind. When the review is completed, we now have a Stable Release Version on the same protected wiki article. This stable version is stored by marking the current (stable) version of the wiki article as stable (suggested by User:Mauro Bieg). Then we can unprotect the article and return to the developmental wiki. I suppose this would be simple to implement as a simple boolean meta data about whether a particular version is a stable version or not. The disadvantage would be that all improvement by new content would effectively be paused while under review since both the wiki and stable article are on the same page. The advantage would be that you can avoid two separate "forks" making it less complicated. The makeshift solution for the marking feature now is once the Stable Release Version is determined, it is put in /Stable and protected. This solution allows the stable version page and the developmental wiki page to be merged into one at the expense of having different phases which can also make things easier. In the end, we don't need a complicated "fork". All that is really needed, all the stable versioning, can just be consolidated into this simple marker feature. All the reviewing work would be located in the talk page or moved to a subpage if appropriate. This idea would be the least intrusive way to easily integrate into the existing wiki system and mind-set instead of having a separate stable "fork". -- Zondor 09:23, 16 February 2006 (UTC)

Here is an extra proposed solution that involves no page protection. A to be modified {{stable review version header}} is placed on the wiki page. This header references a base oldid with a link to view the difference to the current. It asks users to validate the article but not to add extra content starting from the version of the base oldid. Its openly editable but you have to behave (Wikipedia:Assume good faith) according to this stage of the phase. If you do any thing else, it would be vandalism and you go through the normal process to request for page protection. This way, stable versions would not be anti-wiki. -- Zondor 07:03, 17 February 2006 (UTC)

Sounds good to me. Also avoids messing up the naming conventions and category inclusion. Template might instead go on the article talk page, which can then also host the stable review discussion, rather than splitting it, as per the protect-and-fork version. Alai 05:14, 20 February 2006 (UTC)

Success

I am reformatting Stable versions from an essay about why we should do it to a mechanism showing how to do it (modeling after featured articles and good articles). The Philosophy and Rationale has been moved. Let's use Early life of Joseph Smith, Jr./Stable to make this go. dml 00:11, 15 February 2006 (UTC)

Moved from Project Page

Articles

• Wikipedia:WikiReader
  • Wikipedia:WikiReader/Frankfurt
  • Wikipedia:WikiReader/Decade Volcanoes
  • Wikipedia:WikiReader/Free Software and Free Contents
  • User:Worldtraveller/Solar System WikiReader
  • Wikipedia:WikiReader/Spoiler Warning
  • Wikipedia:WikiReader/A History of the 20th Century
  • Wikipedia:WikiReader/Cetacea
  • Wikipedia:WikiReader/Cryptography
  • Wikipedia:WikiReader Methods of Molecular Biology
  • Wikipedia:WikiReader/Poetries National and International
  • Wikipedia:WikiReader/Best of Wikipedia Feb-March 2004
  • Wikipedia:WikiReader/Twentieth Century Hollywood
  • Wikipedia:WikiReader/William Shakespeare
  • Wikipedia:World War II wikireader
  • Wikipedia:WikiReader/Encyclopaedia of the unusual

Wikipedia:Version 1.0 Editorial Team/FAs first has a list of featured articles quoting the oldid of their promoted versions

Status of this as a process?

Is this a policy proposal? Shouldn't it be marked as such? If it's going to be used, even on an experimental basis, there are issues to be addressed as regards how this interacts with existing policy on article forks, naming conventions, and page protection, all of which it's in at least procedural conflict with. Alai 01:56, 15 February 2006 (UTC)

I thought it was marked as a proposal on Wikipedia:Stable versions (if it was removed, that was inadvertant). The reason we are using subpages is discussed above, and is due to the lack of a namespace or the ability to do wikilinks to specific versions,, so it can be considered temporary while the mechanism is tested until something better comes along. Similarly since this is not a wiki version, but a stable version, protection is required. But I agree that those issues do need to be resolved with a consensus, which I hope you can help fashion. dml 19:49, 15 February 2006 (UTC)

If the process is to be modelled on, or even to be at all similar to, GA/FA, forking and protection is unnecessary, and indeed counterproductive. Certainly so in cases like actually "stable" articles like "Early life..."; there might be a case for forking on a temporary basis if it were being attempted to "stabilise" a controversial, vandalism-prone, or otherwise very heavily edited article.

That's as regarding "determining a stable version", which is fair enough. What you seem to be arguing on the basis of here, though, is setting up not simply a separate namespace, but of a entirely separate "parallel wiki that's not a wiki", that merely happens to be hosted on WP. That's an entirely different matter, and is something you should really get a consensus for before setting it up, and I'm inclined to think might be better done as an explicitly separate Wikimedia project. Alai 22:57, 15 February 2006 (UTC)

I do not consider stable versions modelled on or similar to GA/FA. Its purpose is to create a separate version of an article based on a version of the wiki article which can be relied upon at any instant in time; it need not be complete or detailed as long as it is accurate and verifiable. There are also important technical limitations to approaches based on oldids alone, such as the inability to add anything to it explaining what a stable version is and what kind of promises it's making. Deco 23:17, 15 February 2006 (UTC)

I was referring to whether the process was similar, not to whether the articles were. Several comments on this page have suggested this, so I don't think you can claim even a "local consensus" for something dramatically different. If you're looking to produce versions that are deliberately different from any version of the "wiki version", then I think what you want is definitely a project fork. Alai 00:46, 16 February 2006 (UTC)

Going forward with a subpage and protect method seems a little strange when there are technical methods that are being worked on to accomplish similar aims in a much more integrated way. - Taxman ^Talk 23:07, 15 February 2006 (UTC)

This has been discussed for *years* without any actual technical methods deployed. The voting and rating methods that have been discussed are separate from stable versions. If developers are cooking up helpful tools, it would be nice if they let us know what they were. dml 01:01, 16 February 2006 (UTC)

How this will look

Could we get delopers to change mediawiki so that article's have a stable version tag on them like the "new message bar", in the sense that a vandal could not delete it, since it would not actually be part of the article. It would have a pre-designed message for cases where there was no stable version yet. The stable article itself should have the same title, though not locations, as the non-stable one (another dev trick...).

Anyway, this seems like a good idea, though the process is a bit tedious, especially for 1,000,000 articles.Voice-of-All^T|@|ESP 21:57, 13 March 2006 (UTC)

New-message-style bar would be excessive, but if there is general support for doing this, we might get a tab added (like "Discussion", "Edit this page", etc.) - Jmabel | Talk 18:33, 19 March 2006 (UTC)

I think it should be the current version which should be specially flagged; it should have an indication like Draft on it, perhaps right on the title line next to the wikiGlobe. After all, the user needs to be warned when reading the potentially vandalized version, not when reading the good version. -R. S. Shaw 23:04, 19 March 2006 (UTC)

Such test version can be done with Greasemonkey, which modifies the webpage on the client side. Actual software on the server side does not need to be changed. — Dzonatas 01:14, 20 March 2006 (UTC)

I like the idea of a tab if it can be named in a non strange way. I would prefer a small tag in the corner, like the "Your continued donations keep Wikipedia running!" in the right upper corner. It would just be a small light-green or light-purple bar that mentions the stable version (if the article has one). A protected list can have the articles and their stable versions, so that the bar is added automatically, even if the article is vandalized (blanking). Both would requres devs though.Voice-of-All^T|@|ESP 19:09, 14 April 2006 (UTC)

KISS - how this can work

I've read through bits of this proposal and you guys are making this waaay too complicated. The stable version should track the current version in the same way that stable versions track testing versions in software respositories.

For each article, depending on how much attention it gets and how important it is to the encyclopedia, a number should be set that is the number of editors that need to agree that a version is stable. For instance, for an article like frog, that I've done some work on and am hence familiar with, I would suggest three is a reasonable numbers. The editors must be regular bona fide contributors to the article (we had four regular editors with no conflicts whatever). Whether or not the article is Good or Featured is irrelevant; any article can have stable versions. The requirement for nominating new stable versions may be increased, e.g. from three to five editors, if the article grows considerably or begins to attract more attention. Any stable version must be identified with a date to show how current it is. Very old stable versions may have an additional template applied to them.

An advisory page could suggest to use a word processing package to perform a spelling and grammar check before nominating a stable version. No big deal.

The following benefits arise:

• Little bureaucracy - editors can manage their articles themselves
• Stable versions remain up to date
• There is no fork/branch; stable versions are always nominated directly from the trunk

Samsara (talk • contribs) 20:52, 7 April 2006 (UTC)

That sounds' very similiar to my suggestion: #Branchless_stable_version_-_Kevin.27s_mods, except that:

• mine doesn't have templates.
• mine goes into detail about how people would actually see the stable version, rather than just voting for it.
• mine goes into detail about where the votes would show up and where one would vote
• mine insures that each user can apply the same amount of their opinion on any article as any other, because there is a maximum number of approval/disapproval votes per user per article.
• mine deals with the good but old version problem by the above method and by removing old votes.
• mine suggests (as optional) a semi-automation feature that would keep the stable version more up to date with less work from the users.
• mine suggests (as optional) a filter feature on the history page that would let you see just the "good" versions (which can be used as a "hide vandalism edits" feature, or find versions worth considering for approval/disapproval, etc.)

Those seem to me to be the only differences. There are bullet points there, yes, but that doesn't mean it's effectively that much more complicated.

• 1 bullet point is about a way in which your suggestion is more complicated, and therefore counts negative.
• 2 of the bullet points are simply things that need to be addressed that you left out; are functional requirements, and as such don't count.
• 2 do not make the user interface more complicated, though it may make the program logic a little more complicated, i contend it's well worth it.
• 2 are optional, and thus don't count.

In sum, my proposal is just as easy to use: on an article version, click "approve" or "dissapprove". done. nothing could be more simple. Kevin Baas^talk 01:31, 8 April 2006 (UTC)

Sure, except if I understand everything correctly, you're waiting for a mediawiki implementation. My method works now. - Samsara (talk • contribs) 13:21, 8 April 2006 (UTC)

I don't see how your method could work in practice w/out software implementation. Kevin Baas^talk 16:28, 8 April 2006 (UTC)

This suggestion seems like a bad idea to me, in that it would result in stable versions which were low quality crap articles. There are plenty of bad articles on wikipedia which are bad because they're of passionate interest to a small number of people, and of little interest to much of anyone else. These articles tend to end up being highly POV, and have a number of other things wrong with them. If an article's regular editors are all dullwitted or propagandists, I can't see why we should allow these people to take their terrible article and make a stable version of it. --Xyzzyplugh 14:19, 11 April 2006 (UTC)

I don't see what the problem with this would be. Why shouldn't we allow these people to take their terrible article and make a stable version of it? What does it harm? They have a crappy article anyways, which people will see just as easily. If ppl are going to see a crappy article, wouldn't you rather have ppl see a less crappy, crappy article? What's wrong with that? I don't see what the problem is. Kevin Baas^talk 21:39, 11 April 2006 (UTC)

The whole point of having stable versions is that the stable versions of articles will be reliable and accurate. If stable versions are going to be unreliable and unencylopedic and inaccurate, then there is no point in having them at all. --Xyzzyplugh 13:46, 12 April 2006 (UTC)

No, I think you are getting stable versions confused with reviewed versions (like featured articles.) Kevin Baas^talk 17:33, 12 April 2006 (UTC)

Read the first sentence of the introduction on Wikipedia:Stable_versions. --Xyzzyplugh 13:07, 13 April 2006 (UTC)

None of what that article says matters anymore, because a single user took the liberty of completely redoing it to express only his view. Kevin Baas^talk 17:41, 13 April 2006 (UTC)

Xyzzyplugh, I think there are two aspects that we should keep separate in the discussion. The question of what the consensus stable version of each article is, and various criteria for selecting articles for particular purposes. The latter is already covered by WP:FA, WP:GA, Wikipedia:Version 1.0 Editorial Team, amongst others. - Samsara (talk • contribs) 18:45, 26 May 2006 (UTC)

What I think

I've had an idea I've been turning around in my head for a good while, and I don't know that anybody else has ever proposed anything quite like it before, so I guess I'll put it forward here. I'd like to see something like a content committee/project, or better yet many of these to cover different areas of the site, which would serve the purpose of A) identifying articles as "focus" projects (sort of like how we have group projects to improve articles already) and B) concentrating efforts on turning the article(s) into a perfect example of neutrality and verifiability (content expansion would be a low priority here—the idea would be to target articles that are already fairly nicely developed), so as to C) create a stable version which we could then mark (and update occasionally, but only after the changes since the last stable version have been rigorously reviewed). This would basically be a project to produce large numbers of articles of optimal quality (in the accuracy/verifiability department, not necessarily in terms of length or style) so as to take WP to the "next level" of having a growing base of stable, completely reliable content in addition to the existing freely editable encyclopedia. To me, what I'm suggesting seems like a good way to get us moving toward that next level. Everyking 04:50, 10 April 2006 (UTC)

There seem to be two types of proposals, I've opened up that topic here, which seems to me to be the propoer "center" of discussion. Everyking, I believe i mentioned the jist of your idea there. Kevin Baas^talk 21:47, 11 April 2006 (UTC)

Print versions

[3]: Let us make a print edition of Wikipedia, please. Stable versions is idealistic and doesn't have any incentive and perhaps print versions have a better success. Print versions is a sub project or sub proposal or alternative or fork proposal of stable versions. -- Zondor 10:10, 18 April 2006 (UTC)

How would that work? Well, in one of two ways:

• Publish a complete version. This would be in hundreds of volumes and almost no-one would buy it because it would cost a fortune and by the time it was delivered the free internet version would be better.
• Publish a short version. But the articles on many topics are far too long for this purpose, so they would need to be completely rewritten.

I can't see either of the above actually happening. Twittenham 16:24, 9 May 2006 (UTC)

Simplified stable versions

This doesn't have to be all that complicated. We could solve most, but not all, article churn problems with something simple, like this:

• Articles have a "stable" revision, which is the current or a past revision; there is no forking.
• Edits by a logged-in user able to create articles (account several days old, at least) and with a verified e-mail address advance the stable revision immediately.
• Edits by others do not advance the stable version immediately.
• If an article is not edited for 24 to 48 hours, the stable version advances to the latest version.
• Admins can set the stable version explicitly, and if necessary, lock it.
• Anyone can view either the "stable" or the "latest" version of any article; the default is settable for logged-in users and "stable" for non-logged-in users.
• If you edit a page where you're looking at a version other than the latest, you get a warning similar to the "not editing the current version" one.

Thus, anons can still edit, but their edits don't have immediate visibility. Everyone whose edits have immediate visibility is non-anonymous, and can be held responsible for their edits.

This is simple to understand, and not too tough to implement. It could even be implemented external to Wikipedia, as a separate web site that looks like Wikipedia but modfifies URLs to obtain the effect described above.

--John Nagle 22:09, 9 July 2006 (UTC)

This sounds very similar to Wikipedia talk:Stable versions/archive2#forking considered harmful, which I (just today) asked Brion about. His reply was "that's been the basic idea for years. It's being worked on." -- Rick Block (talk) 22:54, 9 July 2006 (UTC)

It seems that we actually have fairly widespread support for this idea and should go ahead with it. I made a suggestion that works without any modification of the mediawiki system, so we probably ought to be bold and make the future happen. - Samsara (talk • contribs) 14:17, 10 July 2006 (UTC)

Reading the #KISS - how this can work thread above, I'm not sure exactly how this works with the existing mediawiki system. Guessing a bit, are you suggesting:

1. On an article's talk page, editors agree how many "regulars" have to agree on a new stable version and the number is recorded on the talk page.
2. To select the first "stable" version, on the article's talk page there's a discussion about some specific invariant version (which may or may not be the current version).
3. Once a stable version is selected, the "regulars" ensure the current version remains the stable version by reverting any further changes to it, and new changes are directed to <where, exactly?>. Or, alternatively, is the stable version identified with a link from the current working version? Or, alternatively, is the stable version copied someplace separate from the current working version? Note that if two versions of the article exist, google will likely index both, so presenting just the "stable" version to casual editors isn't really possible (unless, of course, there are mediawiki changes :) ).
4. A newer, stable version can be proposed anytime from the "working" version. Exactly how this is done depends on how stable versions and working versions are kept separate.

The main point is that before implementing any proposal, we will need to work out exactly how it will function. I don't think I've seen one that satisfies what I'd consider my critical requirements (which includes casual browsers see only the most recent stable version) that does not require mediawiki changes. -- Rick Block (talk) 18:35, 10 July 2006 (UTC)

No, I'm proposing a much more automated system. All that happens is that the version casual users see is the latest revision marked as stable, and that revision advances automatically according to the rules given. This requires software support, but little user interaction. This won't solve all problems, but it will cut down on churn. One minor addition is that the privilege of advancing the stable edit could be revoked from users who abuse it, a way to reduce the influence of editors who misbehave. That basically would put a logged in user back to the privileges of an anon. --John Nagle 05:53, 11 July 2006 (UTC)

No, it's much easier than that. The stable version for frog would be frog/stable and would be protected. Having to go that little extra length (typing "/stable" in the address bar) creates the incentive for people to keep editing the unstable version. If Wikipedia is to keep growing and improving in quality, the first version presented to the user must be the work in progress copy. - Samsara (talk • contribs) 16:30, 11 July 2006 (UTC)

That requires an admin to advance the stable version, and takes too much manual effort to be practical. --John Nagle 17:30, 11 July 2006 (UTC)

The way to determine this would be to try it. The beauty of the proposal is that everything else remains unaffected. - Samsara (talk • contribs) 17:36, 11 July 2006 (UTC)

If the stable version is frog/stable, what URL does a google search return? My guess is frog since frog/stable probably wouldn't have any links to it (except, perhaps, from frog). If a forked article is all you want, you can do that today without even making it protected (just have the regulars agree that the only legitimate way to update /stable is to copy a version into it and revert any other change). I'd say go ahead and try it, but since google likely won't return it as a hit and no internal links will point to it I suspect you might as well copy the stable version to /dev/null. -- Rick Block (talk) 18:56, 11 July 2006 (UTC)

Well, the placement of the internal link would be the next thing to discuss. Presumably somewhere near the bottom of the article, otherwise the "current" version may receive significantly less attention. - Samsara (talk • contribs) 22:57, 11 July 2006 (UTC)

A simple question

This is a question I've asked previously when stable versions where proposed and it went unanswered: How do people become Wikipedia editors if articles they read are not the articles they will edit? If a casual reader spots a typo in a long article and tries to correct it, what happens? They're sent to another versions where the typo is already corrected or maybe the whole sentence has been removed or moved elsewhere? Isn't that rather confusing? Zocky | picture popups 00:02, 11 July 2006 (UTC)

I don't think anyone is claiming there aren't some downsides, just that the benefits far outweigh the costs. If updates to the stable version are not too cumbersome, then likely they won't be far from the currently editable version. Yes, they're sent to another version, hopefully it will have diffs either presented automatically, or easily available with edit summaries of why changes were made. A little confusion is not a big enough cost not to move forward. We no longer need just any editors, we need talented ones that are currently turned away by all the vandalism, etc. Much of that can be solved with a good stable version system. But why talk in abstract before the code is ready? - Taxman ^Talk 00:29, 11 July 2006 (UTC)

The talented editors have been turned away by all the vandalism, etc. for years. Yet in the meantime, the encyclopedia has gotten bigger and better. In fact, the effect of vandalism has probably been reduced all in all - we get more vandals, but we also have more eyes and more tools. Zocky | picture popups 00:52, 11 July 2006 (UTC)

Exactly my point, and maybe we'd be in a much better place if they hadn't. Even if not I believe it's clear these are different times and we need different solutions to really raise average quality and quality by many other measures. All options should be explored. This just happens to be one with lots up upside, and little downside. - Taxman ^Talk 02:37, 11 July 2006 (UTC)

And maybe if we didn't have the system where anonymous people can edit live versions of articles, the whole thing would never have worked. We don't know that. What we know is that the current system works remarkably well, and changing it for unknown benefits doesn't seem like a prudent choice. There are ways to have stable versions of articles which wouldn't mess with the way wiki works. There could be a separate wiki where stable articles are moved and worked on, or we could have a template which identifies a stable version in the history so people who want to read it can simply click on a link.

If we abolish live editing, the impression of Wikipedia the website will change from a project to write an encyclopedia into Wikipedia the encyclopedia itself, with the editing process going on in the background to tidy up the loose ends, raising the expectations of readers yet further. Considering that we still don't have nearly as many good articles as Britannica (and that we should have many many more than Britannica), that seems rather premature. Zocky | picture popups 11:41, 11 July 2006 (UTC)

That's exactly what we're talking about. "ways to have stable versions of articles which wouldn't mess with the way wiki works." If you think we're talking about anything different, that's where the problem is coming in. We're talking about ways to have articles freely updatable, but still have a stable version to present. No one is talking about abolishing live editing. - Taxman ^Talk 15:34, 11 July 2006 (UTC)

I beg to differ. Presenting a user who followed a link with a version of an article which is not the same one that they can immediately edit, not to mention the proposed 48h delay between an article being edited and the version being published, does constitute an end of live editing. It would be more akin to the editing that Encarta provides than the one we have so far. Zocky | picture popups 17:37, 11 July 2006 (UTC)

Actually by definition it does not. the 48hr delay proposal is different, but if there still is a version that can be edited and anyone can see it, then we still have live editing. Articles will still be able to be updated just as fast. Only difference is people have a choice, they can see the stable version or the live one. The only choice they have now is to see a potentially vandalized version and learn how to go into the history and decide for themselves whether any of the recent edits improved the article or not. And if you don't see the cost to having vandalized versions being the default version that is shown to readers, then you're failing to see the perspective of a reader. The cost of potential confusion from stable versions is so much less. I fail to see what the reasons are behind your constant objections to stable versions. The fact that the live edited version is freely available to be seen by anyone makes the comparison to Encarta's system strained at best. - Taxman ^Talk 18:01, 12 July 2006 (UTC)

That only makes sense if you see the live editing version by default. Otherwise the easiness of participation disappears. Zocky | picture popups 17:08, 13 July 2006 (UTC)

No it doesn't dissapear. There can still be an edit button on every page. At most it could take you to a page that shows the diffs and still allows you to edit. And I'm not opposed to having the live editing by default as a way to ease a step forward as long as we reallize the real power is in having the stable version be the default. - Taxman ^Talk 20:26, 13 July 2006 (UTC)

So, where exactly, is the description of the version that is being worked on? m:Article_validation_proposals contains about a dozen various proposals. There is mention at meta that m:Article_validation_feature is in the 1.5 code base. Is this what's coming? Where is the discussion about this? Meta (discussions there seem to have stopped about a year ago)? Mailing list? IRC? Enquiring minds want to know. -- Rick Block (talk) 03:24, 11 July 2006 (UTC)

No idea, I don't really follow the bug reports or mediawiki development. Someone that did may be able to answer. What I do know is development is volunteer too and works like editing. They code up what they feel like and take into account what people want as much as they want to or happen to know about to varying degrees. I've seen an email over a year ago IIRC on a partially finished stable branch extension that may or may not have been polished up. - Taxman ^Talk 04:16, 11 July 2006 (UTC)

I think it's just thoroughly wrong-headed to even want to have anything like "stable versions" of articles. The one big advantage Wikipedia has over "conventional" encyclopedias like Britannica is that it can be updated quickly and easily and unbureaucratically. No field of science is ever "done"; there are always more questions to ask, and new answers to old questions, and so on. It's bad enough that Wikipedia has "featured articles", many of which are almost impossible to correct or update no matter how badly they need it, but now to want to promote some of those even further to "stable versions" that will literally be impossible to correct or update no matter how badly they need it just runs completely counter to all Wikipedia principles. This is frankly as stupid an idea as having a paper and/or CD version of Wikipedia. User:Angr 12:00, 11 July 2006 (UTC)

It's interesting you brought up some of the drawbacks of "feature articles", because "stable versions" fixes a lot of these drawbacks, such as a featured article being almost impossible to correct. "stable versions" will solve this problem by having a "featured revision". w/"featured revision"s, unlike, "featured article"s, editors can edit the article unimpeded. There will just be a small delay before the new revision becoming the featured revision. That is, instead of slowing down the speed of article development, it puts a lag between the publicly viewed version and the developing version. Thus, you have improved article quality w/out the disadvantage of impeded development. Kevin Baas^talk 14:06, 11 July 2006 (UTC)

I'm not finding any discussion of "featured revisions". Where are they discussed? As far as I can tell, the only instance of the word "featured" on this page is in the sentence "Making stable versions is part of the maturation of an article through its lifecycle, preceded by others such as creation, stub, expansion, through to attention, verification, peer review, good article, and finally featured article status", which makes the preposterous implication that featured articles are somehow to be considered "finished". User:Angr 15:30, 11 July 2006 (UTC)

Same as above, if you think this is about making it impossible to correct or update articles, that is where the disconnect is, not a problem with having stable versions. Clearly you're just overlaying your worries over not having read what this is about. - Taxman ^Talk 15:36, 11 July 2006 (UTC)

No, I have read what it's about. I know perfectly well that there will still be editable versions of stable articles. My concern is that having stable versions of articles--just like having Wikipedia 1.0 and having Featured Articles--is a Bad Thing because it conveys the false illusion of an article being finished. Regardless of the fact that there will still be editable versions of stable articles, if stable articles are available, people will see them and be misled into thinking those articles are all that needs to be said about the topic. User:Angr 16:29, 11 July 2006 (UTC)

It's a Good Thing to have the usual version be a good one. "if stable articles are available, people will see them and be misled..." – no, there should be (almost) nothing to see. A stable version should look pretty close to what you see now, and pretty close to what the unstable version looks like. There should be nothing there to discourage editing.

The average reader surfs (however) to an article, gets the stable version (since not logged in). If he spots an error and wants to fix it, he clicks "edit this page" just like now. At this point is the only likely glitch, since the unstable version may be different. So big deal, if the version he clicks from is the older stable version, the software adds a message at the top, like "This article has recent changes from the version you were reading. Please make your changes to this draft version." If the error is present in that version, he fixes it, just like today. The redisplay would probably have some text like "This is the draft version. This version will not appear as the main version until after community review." -R. S. Shaw 03:08, 12 July 2006 (UTC)

I'm afraid that a substantial number of perfectly good newbies will give up at that glitch. Remember, we have enough people who know about computers and the internet. We need more people who know about other stuff, and that kind of people might have problems learning how to edit if it's non-obvious.

Another serious concern is how to practically decide which versions are stable for a million, or even a few thousand articles. If "stable" versions are chosen by the software, or semiautmatically by RC patrol, we'll be giving a false impression that "stable" versions are better reviewed than normal articles. OTOH, if this is meant to be done in a more deliberative way, we have the problem that we don't have the workforce to sift through tens of thousands of edits and check each reference in real time. If we try that, current versions will soon be very much different from the stable version, turning the above mentioned "glitch" into a serious issue. 17:20, 13 July 2006 (UTC)

"Featured versions"

From the preceeding topic:

..."stable versions" will solve this problem by having a "featured revision"... -Kevin Baas

I'm not finding any discussion of "featured revisions". Where are they discussed?... -User:Angr

This shows a big problem with the current name, "Stable Versions". It puts entirely the wrong emphasis on what the mechanism will (or should) do. It makes that version sound hard to change and out-of-date.

Following Kevin's direction, I think this mechanism should instead be called "Featured Versions".

The "stable" version will be the featured one. It is the one the normal reader will want to read. It is one without vandalism. It is one without some just-inserted incorrect statement. It is the latest one that has been checked by someone to be reasonable. It is the one which should be featured by being the one normally presented.

For wiki-addicts like us, we'll live on the bleeding edge, seeing the latest raw, corrupt version. The default for non-logged-in users should be the featured version ("featured revision"). --R. S. Shaw 02:40, 12 July 2006 (UTC)

I think this is a fine proposal otherwise, except that I wouldn't (at least for now) want it on www.wikipedia.org. The current model has proven itself to work well, is easy to understand and reasonably well known. This is why I'd want such a stable version (or whatever you'd call it) to be shown somewhere else, e.g. at stable.wikipedia.org, regardless of what Google thinks of it. It should also be shown on www.wikipedia.org in an easily accessible way (but not by default - this is the big difference), particularly allowing for easy diffs between all combinations of stable and unstable versions.

On stable.wikipedia.org there should be no confusing edit buttons that edit a different article than the one shown (ie. no edit buttons at all), but links to the development version at www.wikipedia.org. The difference between these two sites should be made as clear as humanly possible: one is for for consumers, one is for participants. Transition from the former group to the latter should gently be encouraged, but only in a clear fashion that evokes curiosity instead of in-your-face advertising or anything potentially confusing. In particular, no voting for article versions on the stable site.

Zocky wrote this earlier on the page: "If we abolish live editing, the impression of Wikipedia the website will change from a project to write an encyclopedia into Wikipedia the encyclopedia itself". This is aptly put, and I agree with it even without the "abolish live editing" part. Any stable version is a preview -- perhaps very preliminary and quickly changing, but a preview nonetheless -- of "Wikipedia the encyclopedia", which should be meant for consumers. The development version (the current system) is Wikipedia the collaborative project website. The best way to make the difference clear to everyone is to have different URLs for the sites and make them look slightly different. It would let the stable version stand on its own merits and keep the collaborative site going intact, as well as keep old references to Wikipedia as relevant as possible. This includes media references, all of which are not flattering: consider how often it is mentioned that anyone can vandalize Wikipedia, which wouldn't be true on the stable site. Making the difference clear might also enable the media to understand some parts of the new functionality correctly, instead of making the usual total mess of it. -- Coffee2theorems | Talk 20:54, 17 September 2006 (UTC)

I think there's a pretty reasonable argument that enabling some sort of stable version feature at www.wikipedia.org will help the project in its goal to write an encyclopedia. As it stands, a large amount of what might otherwise be productive effort invested in this site goes to vandalism control. If vandals can't immediately see their work, I strongly suspect they won't bother. Interpreting "stable versions" only as a mechanism to control the content of "close to perfect" articles misses a huge opportunity to use such a feature to help reduce the incidence of vandalism. -- Rick Block (talk) 22:46, 17 September 2006 (UTC)

Dictator needed

This whole discussion supports my opinion that nothing of this sort will ever happen without Jimbo's direct involvement. The problem I see is that if you ask 5 people how it should work, you get 5 different answers. There are roughly a dozen different mechanisms discussed at m:Article validation proposals, with no clear consensus that I can see. I think Jimbo needs to say "here's how I want it to work". Without that sort of direction, I think there are just too many differing opinions to make any progress. -- Rick Block (talk) 04:03, 12 July 2006 (UTC)

I prefer having a (good) developer just implement.

The general problem in all these pages is that casual wiki approach to design doesn't work well at all. People come; people go. Days and weeks pass. People plug in blurbs about aspects of their own vision. The mass of verbiage gets deeper. Common understanding (much less agreement) is never reached. -R. S. Shaw 04:59, 12 July 2006 (UTC)

Wait, there's a bunch of people who say we shouldn't have this at all. How about just leaving the current process, which obviosly works (I'm tempted to say look at http://en.wikipedia.org to see what it acomplished) as it is now, until somebody comes up with the brilliant idea that gets overwhelming support. Zocky | picture popups 14:02, 12 July 2006 (UTC)

No. This just needs someone who does something. - Samsara (talk • contribs) 14:20, 12 July 2006 (UTC)

Here's a first test: frog/Stable. - Samsara (talk • contribs) 14:33, 12 July 2006 (UTC)

And here's a first draft of a template to go with it:

<div style="position: absolute; top:0px; left: 700px; text-decoration:none; font-size: 12px; overflow: hidden; line-height:20px; z-index: 3">[[/Stable|<span title="Click here to access this article's stable version.">stable</span>]]</div>

I'm sure someone who knows more about how the css on this site works could considerably improve the template. I don't believe that use of this template constitutes any more of a self-reference than the "Featured Article" icon. - Samsara (talk • contribs) 10:23, 2 August 2006 (UTC)

Compromise?

I understand the problem with the current state of Wikipedia. I am absolutely opposed to having the stable version be the default version. If we were to have a link at the top of the pages to a "stable version" that would be fine. Good idea, buut way to early. Try this again in a few years. Wikipedia's False Prophet holla at me 01:58, 13 July 2006 (UTC)

I think there are a reasonable number of folks who think making the "stable" version (whatever it may be) the default version would accelerate the progress (less vandalism, fewer folks spending time reverting, so more time available for net productive work). The opportunities for vandalism are so vast at this point (with over 1.2M articles) that it takes a virtual army to keep up with it. I'm not sure where the tradeoff point is, but I think it might be worth doing some sort of controlled experiment to see what the effect is. I'd agree with a sentiment that we absolutely shouldn't do anything without some plan in place to measure the impact. -- Rick Block (talk) 02:06, 13 July 2006 (UTC)

I think we should build this up slowly, and I think the resources we have are sufficient. Make a stable version for each Featured Articles first, then once that is working well, move onto the Good Articles, etc. But we have to make a start, otherwise this will all be wasted typing. - Samsara (talk • contribs) 09:31, 13 July 2006 (UTC)

Umm... how about the principle of not breaking stuff? You can't make major changes to the basics of the project unilaterally without breaking a lot of stuff. Unless a really overwhelming consensus is shown for a large number of article to be forked into background development versions and protected public versions, nobody should attempt such a drastic move unilaterally.

The most that can be done without messing with how wikipedia works is having a template that links to a "stable" version in the article's history. We could try that, and see if it produces anything useful. Zocky | picture popups 15:07, 13 July 2006 (UTC)

Such a template won't be very friendly to Wikipedia:Mirrors and forks (since it's a self-reference, which are generally to be avoided - see Wikipedia:Avoid self-references), although I like it better than "/stable". -- Rick Block (talk) 15:48, 13 July 2006 (UTC)

I'm not quite sure what the problem is here. The page you referenced is a style guide, but the statement you're making is presumably about caching? - Samsara (talk • contribs) 16:00, 13 July 2006 (UTC)

I am really surprised at the all out offensive against change. If some people weren't willing to completely change the way reference works were written we wouldn't have Wikipedia. It takes being willing to innovate to create something remarkable. We need to keep trying new things. The arguments against this seem to be just arguments against change. - Taxman ^Talk 20:09, 13 July 2006 (UTC)

For anyone to see it, the message pretty much has to be on the article rather than on the talk page, and it presumably will say something like If you'd prefer to view the latest stable version of this article rather than this version (which might contain the ravings of any random lunatic on the planet), please see link to stable version. This statement refers to the process by which Wikipedia is being created (is a self-reference). Such statements are generally to be avoided, since Wikipedia's content is explicitly made available to forks and mirrors which may use entirely different processes and procedures (may be printed, for example). Not only is the self-reference a problem, but when some other organization gets the current copy of the database (for mirroring or forking) I don't think they get all the historical versions so I suspect that although they may really want the latest stable version there won't be any particular way for them to get it (if it's a version from the history). What I like about making the stable version a version from the history rather than a copy in "/stable" is there is no copying involved - it's just a version selected from the history (no worries about duplicate google indexing, etc.). -- Rick Block (talk) 18:54, 13 July 2006 (UTC)

Okay, thanks for explaining. So essentially, we want the link to stable to be something like an extra tab on the top navigation, so that it's not part of the wikitext or rendered html; and the history in admin view needs a button next to the revision that says "make this stable", and there has to be a log for such actions. (BTW, I'm not claiming any of this is original; it has probably been mentioned somewhere in the various lengthy discussions that have gone before, on this page and elsewhere.) Did I miss any required features? Is any of this technically difficult to do (again, I'm just asking, don't shoot the pianist)? - Samsara (talk • contribs) 19:16, 13 July 2006 (UTC)

Assuming we want the "working view" to be the default view (which I think is the wrong default), and we want only admins to be able to update the stable version (I think a new class of user is needed, and that we need lots and lots of them), then I think you've got at least most of the required features. I think providing the most recent "stable" version with the download available for mirroring should be part of this as well. If we go this route, google indexes the working copy (which is one reason I think the "stable version" should be the default view). As to how difficult, I don't really know but I don't think any of this is tremendously difficult. Also note that if we go this route, any time anyone views the stable version they presumably have to first see the "working copy" and then the stable version won't be cached by the squid front ends but will be regenerated (per view). This is yet another reason to make the stable version the default view.

If we twist this around and show the last designated stable version as the default (so edits invisibly pile up until someone updates the stable version marker), the google index problem goes away (google indexes the last stable version), the fork/mirror problem mostly goes away (the download for mirroring/forking still has to be changed to retrieve the most current stable version), the caching problem goes away (casual visitors see the stable version which would be the one in the squid cache, no extra clicking required), and we tremendously reduce the incentive to vandalize (nearly all vandalism would be invisible to the general public, and would never show up to anyone except an editor). And, I think implementation-wise it's basically the same amount of effort. -- Rick Block (talk) 20:49, 13 July 2006 (UTC)

I don't think we need to worry about Google et al. Wikipedia is a sufficiently important site that they will figure out how to make exceptions for it. Failing that, there's always robots.txt and similar mechanisms (not sure if they're used on Wikipedia). - Samsara (talk • contribs) 21:15, 13 July 2006 (UTC)

But the point is in the value in having google cache only the stable version instead of the current situation where they cache vandalized versions and worse. Also the value in increased Wikimedia server cache percentage can't be overlooked. - Taxman ^Talk 21:31, 13 July 2006 (UTC)

Putting this a little stronger, I've seen numbers (which I should really reference :) ), putting the number of Wikipedia fetches served from the squid caches as something like 80% of the total. If a significant number of articles had a stable version that a significant number of viewers retrieved, and the stable versions were not in the squid caches, I believe we could not handle the traffic without far more hardware. I think the plain fact is that most users are not editors, which I believe means hiding the "stable version" behind a click available from the "working version" resolves this issue the wrong way for most people. Perhaps if you're not logged in, the "edit this page" link shows you the current working version (and has another "edit this page" link), and only after you see the working version if you click "edit this page" you get to the edit window. -- Rick Block (talk) 22:18, 13 July 2006 (UTC)

Option to load the development page first

I don't think this should be implemented without an option on "my preferences" for users to load the development page first. Alan Pascoe 19:48, 13 July 2006 (UTC)

I think the consensus at the moment is that giving people the option to see the stable version first is a bad idea because if people want to change something, they have to first find the development version, check that their change has not been implemented, and then add that change. This has the potential to put people off editing. However, others might put their trust in natural curiosity! My experience is that it is impossible for projects such as Wikipedia to avoid accumulating bureaucratic crud (otherwise known as complexity). - Samsara (talk • contribs) 20:06, 13 July 2006 (UTC)

I think the consensus is actually the reverse, and that most folks agree this is only workable if the "stable" verison is what is generally viewed. And, presumably you mean impossible to avoid accumulating bureaucratic crud. -- Rick Block (talk) 20:56, 13 July 2006 (UTC)

Fixed. Thanks. - Samsara (talk • contribs) 21:12, 13 July 2006 (UTC)

While I wish that was the case for the good reasons you've outlined above, I don't think there's a consensus either way yet, and calling consensus in one instance does happen to be one of my roles. I do really wish people would be more open minded and less stuck on past methods, but the diversity of opinion can be a strength. But also as I said above I'm fine with the pragmatic approach of starting out with the live version being the default shown as a way to ease making a positive step forward even though it's not nearly as good. That could be good as long as it is easy to switch to the stable version being the default, again for all the reasons you outlined. A user preference option is also a good idea. - Taxman ^Talk 21:29, 13 July 2006 (UTC)

People are not necessarily afraid of all change, it's just that many people think this is a wrong direction. To my mind, this is like fighting arson by removing oxygen from the atmosphere. Zocky | picture popups 18:13, 15 July 2006 (UTC)

And this is where your position is out of proportion to the situation. Stable versions still allow for live editing and improvements by anyone and don't take anything significant away and have clear advantages. You haven't given any solid reasons why you think this is equivalent to removing oxygen. You just feel it's different, so therefore the sky is falling. Further, if you think this is so horrible, what's your solution to vandalism and it's effect on readers that don't know how the wiki works? - Taxman ^Talk 14:12, 17 July 2006 (UTC)

We don't need a solid reason to retain the system that helped us write the largest encycloepdia in the world in 5 and a half years. It's the changes to this system that need solid reasons. Wikipedia may be an encyclopedia, but it is also a project to write the encyclopedia, and the latter must not be made to suffer for the former.

I don't have a solution for vandalism, and I don't think there is one. Vandalism has been with us all along and there is no evidence that it has been growing or becoming worse on average. There is no solid reason to change the system because of vandalism. And about the effect on readers who don't know how the wiki works? Nobody who's not hopelessly naive considers anything written by a bunch of volunteers to be 100% correct. If they're ignorant of that fact, educate them. Maybe we need "This is a work in progress created by volunteers" on every page?

The idea to have a stable version seen by anonymous readers to ensure that they're not misinformed is not just potentially harmful to the writing of the encyclopedia, but also sure to backfire on itself: having some pages more "stable" than others will give the appearance that those pages are reviewed, edited, and aproved by Wikipedia administration, grossly misonfming the reader. Zocky | picture popups 15:41, 19 July 2006 (UTC)

I disagree entirely. I understand that some editors are in love with Wikipedia because it is a fun wiki playground, and think that aspect is most important above all others. However, many editors believe that there are two leading principles: that Wikipedia should be an encyclopedia, and that it should be built by open editing. In that view, beside having open editing, it is important that Wikipedia have the qualities expected of an encyclopedia: general reliability and lack of graffiti.

If Wikipedia as it exists on the web is to become an encyclopedia, it has to grow in those encyclopedic characteristics, since that is where it is currently clearly deficient. Thus removing vandalism (and other poor edits) from the initially-visible article pages is a solid reason, an extremely important reason for making changes to some aspects of how wiki editing works on Wikipedia. -R. S. Shaw 19:56, 19 July 2006 (UTC)

Wikipedia is now a much less deficient encyclopedia than a year ago. It's also infinitely less deficient than 6 years ago. At the same time, the probability of a particular user seeing a vandalized page is smaller than it was in the past. The current system works, quit trying to mess with it. Zocky | picture popups 23:45, 19 July 2006 (UTC)

Again, lots of gloom and doom with nothing to back it up. You have no solutions to vandalism, but don't reallize that stable versions being presented to readers by default is an excellent one. It allows the best of both worlds: free and open editing and no vandalism presented to unaware readers. Readers shouldn't have to be educated. They should simply be able to actually use the project for it's purpose without seeing the latest result of the penis vandal. The rest is easy enough to respond to but I'm not sure why I keep doing so. Stable versions is an idea so obvious it's going to happen anyway, it's just a question of time. Clear and hugely advantageous reasons have been put forth for moving ahead with no major problems brought up. Hopefully it's sooner rather than later so we can move ahead faster. - Taxman ^Talk 05:34, 22 July 2006 (UTC)

There should be no argument about presenting the stable version to a reader by default first. If you don't, then having stable versions is useless. Also, I do not see any great harm in having people go to another tab to see what the current edit version is and to make changes. The real danger is that if it is difficult to "promote" a version, then reasonable changes will go for some time without being incorporated. (That the editor will not see the changes in the stable version immediately does not bother me. However, the changes need to either be promoted or discarded promptly in this is to work.) Perhaps having a means for the editors who are watching a page to "accept" an edit, with a threshhold requirement (say 60% approval) for moving the "stable version" pointer would work. --EMS | Talk 17:19, 25 July 2006 (UTC)

It's time to do something

We can discuss, and discuss, and discuss that all over the place. However, until something is tried, you cannot for certain ascertain if or how well it works. So we need to step back, settle on the parameters of the scheme, then try out a way of achieving the set goals to see what happens.

First of all, there is the automation possibility. Here I suggest that anyone with an idea for an algortihm please try it out. (I assume that tools for accessing past versions of an article are available.) What is needed in that case is actual samples of how various articles come out under an algorithm. There is no need to evaluate algorithms in a talk page. Instead, we should be evaluating results!

For the more manual based tasks, there seem to be these issues:

• Which version should a visitor to Wikipedia see by default? The current stable version, or the current edited version?
  • Showing the stable version will diminish vandalism since the change is not immediately visible.
  • Showing the current edited version will make editing easier, thereby encouraginf edits.
  • The ability of a user or an editor to choose whether to see the stable or the edited version by default is desirable.
• Where should the stable version reside?
  • As a protected main page? (This permits current mirrors to pickup the stable version without changes to their software.)
  • As a proteted subpage? (This allows mirrors to seek the protected version first, but is flawed in that it will be "out of view" of most Wikipedians. The dedicated subpage name would need to automatically protected to prevent abuse also.)
  • As an identified version of the article? (Wikipedia softare could then identify the "stable" version, first by explicit identification, then perhaps by software, otherwise uses the current version.)
• How should the stable version be decided or changed?
  • Most likely by a consensus of the article editors in concert with an unbiased administrator.
• How should the stable version be set?
  • Most likely by the unbiased administrator mentioned above.
• How should navigation between the stable and the editable version occur?
  • By tabs on the top of the page? (probably the most desirable option)
  • Via a selection on a side bar?

I say lets get these issues settled first! Once the settings for these parameters are agreed to, the implementation will follow much more easily. --EMS | Talk 05:15, 15 July 2006 (UTC)

I've been considering a "version endorsed by the WikiProject Physics Cabal" flagging scheme for some time outside of this project. If I ever get off my tail and build the tools for it, it would be straightforward to generate statistics for what version-selection algorithms would do when applied to larger subsets of the database. Some combination of an automated scheme plus heavier weighting for a manually-determined cabal of reviewers would probably work best, though in practice you'd probably try to build "karma"-style scores for editors in an automated manner to generate at least the outer circle of reviewers. Don't hold your breath waiting for me to implement this, though. --Christopher Thomas 05:46, 15 July 2006 (UTC)

Time to do something? Some are trying, over at Wikipedia:Stable versions now. You want to settle the issues first? It seems like there is a very large separation between those favoring the two answers to "Which version should a visitor to Wikipedia see by default?". I doubt anything looking like consensus can be reached. -R. S. Shaw 06:16, 15 July 2006 (UTC)

---

First of all, I have added the business of navigation between version to the list of issues to be considered. (Perhaps what is first needed is agreement on what the issues area here.)

I liked the idea at Wikipedia:Stable versions now, but it is wearing on me. It is going to be a lot more work to change protections and copy articles then to have an admin move the "current version" flag to a new version. However, as a short term solution, espeically for pages like gravitation which are regularly vandalized it is a reasonable idea.

As for the "which version should be seen by default" question: I personally think that the stable version should be shown to unregistered viewers by default, while for registered users the mode is a setting in "my preferences" which is the wiki version by default. For the anonymous users, navigating to the wiki version should be easily done, such as in Kevin's tab scheme. --EMS | Talk 15:13, 15 July 2006 (UTC)

elephant a stable version?

Is there consensus to start rolling this out? --badlydrawnjeff talk 02:18, 2 August 2006 (UTC)

I want to invite those who wish to discuss that change to Talk:Elephant. I don't really care if Wikipedia becomes read-only, but the moving of the article history to a sub-page is a deep violation of the understanding that readers have had for years: that they can click on "history" and see every edit made to the page. We've taken great pains to prevent the loss of history where we can, and were we can't long discussions have taken place before taking those steps. Nothing of the sort happened here. -Harmil 03:14, 2 August 2006 (UTC)

I have looked at that talk page. As an experiment this is good, and leaves us with a useful parameter: The main page (be it protected or not) should "hold" the history. This suggests that the development subpage should be a dedicated copy, yet even that results problems with the history. The "out" is to have a version set as the "stable" one, either by a consensus of the editors or by a automated algorithm. Yet how will that be set up, and how can it be tested? --EMS | Talk 03:43, 2 August 2006 (UTC)

Wikimania discussion on validation - please comment

I'm involved with a discussion session at Wikimania on Friday concerning article validation. I am going to begin with some options for achieving this, and these will typically require stable versions of articles. I hope we will have the critical mass of people (including Wikimedia code-writers) in the room that we can get the needed infrastructure (such as a "Validated version" tab) agreed upon. Please come if you can, and if not I'd love to hear comments from people on this. More details and links can be found at here. Thanks, Walkerma 23:47, 2 August 2006 (UTC)

Graphic demonstration

I thought it might be helpful to use a visual aid to how some basic operations might appear and operate under stable versions. It need not be complicated, and need not differ very much from the way unstable articles work today.

After it has been decided to put an article under the mechanism and a stable version has been assigned, readers who have not signed in will see that stable version when they surf to that article (whether it be by inter-article link, search engine, or URL). (A signed-in user will go to the current draft or the stable version, depending on the option set in their preferences.)

The stable version article presentation might appear nearly the same as today:

There's one extra tab, to allow the latest raw draft to be viewed. The edit tab will still be directly available (probably with a different name, not necessarily the one shown).

If the article reader decides to edit something in the article, clicking the edit tab will take him or her to the edit page for the current draft version:

Since the editing is done on the current draft version instead of the stable article version, the wikitext presented by clicking edit on the article page may differ from the wikitext associated with the stable version. Most often it should be quite similar, and making the intended change should be just about as easy as today. If desired, it is easy to see the display appearance of the draft version, either by clicking the Preview button under the edit box, or by clicking the draft tab to go to the current draft version display.

After the editor presses the Submit button, the next page that comes up should probably be the draft version of the article:

The draft version is displayed at this point because it matches what was just edited. While viewing it, the user might become aware of corrections or additional changes needed in the new draft. The page headline begins with "[Draft]" in order to make clear to the reader/editor that there are really two versions of the article that can be viewed, and that this one is the one that is in flux. (Of course there are a wide variety of ways to mark the page; I chose this one for the example because it is explicit and simple.)

-R. S. Shaw 21:12, 6 August 2006 (UTC)

I think that this is basically the right way of doing the user intereface for stable versions. There is still the issue of how to set up stable versions. One problem is how to identify a stable version. My preference is to do this through automation. For example, most articles which are in a stable mode have long stretches without being changed punctuated by occasional and quickly reverted vandalism. The rule that I would propose for a stable version is the one which has been the current version for the most time over the last 10 days, and where that time is at least 4 days long. Note in this definition that two or more "versions" in the history which are identical are treated as being the same version. I also suggest that administrators be permitted to designate pages as being unstablizable (such as the 2006 Atlantic hurricane season article) so that new revisions can be reflected promptly. --EMS | Talk 02:45, 11 August 2006 (UTC)

I agree that this is the right UI and that the issue is how to set up stable versions. I think the right answer is "it depends". An algorithmic approach, as suggested above, means breaking news (a celebrity's death, a planet no longer classified as a planet) cannot be accommodated, and this is bad. I believe the solution is to have a multi-level review mechanism, much like the way we currently have a multi-level "change allowed" mechanism (regular vs. semi-protected vs. protected). If "stable" means "someone must pick (approve) the stable version" and we separate "ability to change" from "ability to approve", then we can have "stable versions" corresponding to:

• the current default ("ability to change" = anyone, "ability to approve" = anyone)
• the current "semi-protected ("ability to change" = logged in user, "ability to approve" = logged in user)
• the current "protected" ("ability to change" = admin, "ability to approve" = admin)

as well as new variants (and I'd introduce "approver" as a new level of logged in user), like:

• anyone can change, but a logged in user must approve ("semi-protected", but random edits aren't shown until someone approves them)
• anyone can change, but an "approver" must approve (new, not like anything we currently have)
• anyone can change, but an admin must approve (I think this matches most of the "stable" version proposals I've seen)
• only logged in users can change, but an "approver" must approve (much stronger than than current "semi-proteccted")

I think any "admin' approves mechanism doesn't scale to a project the size of en.wikipedia, but might be useful for some installations of MediaWiki. Here, I'd think "anyone can change, but an approver approves" is the right mechanism for pretty much any "stable" article. For a "stable" article, changes should be allowed by anyone, but they shouldn't be displayed (to non-logged in users, who haven't selected to see the "draft" version) until someone (and, specifically, this shouldn't take an admin) "approves" them. The new class of user, "approver", should be relatively freely doled out to anyone who is not an obvious vandal or POV pusher, and equally easily rescinded if errant approvals have been observed. I'd let admins designate and rescind this "approval" privilege. -- Rick Block (talk) 02:37, 26 August 2006 (UTC)

On the topic of stability automation, there is an intuitively accurate mathematical formula for it, based on probability:

[stability] = [constant1] * e^(-[constant2]*[time before current time]) * e^([constant3]*[time before next edit])

where constant2 is the decay rate (more recent versions should be prefered) and constant3 is the stability unit. both constants could be inferred statistically per article, since some article are edited a lot(high constant3) and others not-so-much(low constant3), and some articles are about current events(high constant2), and some are about dead events(low constant2).

The method for automation suggested above by EMS is a discrete version of this formula with constants fixed at certain values. 65.26.249.235 03:29, 27 August 2006 (UTC) (65.26.249.235 was me and that was my comment. Kevin Baas^talk 21:27, 27 August 2006 (UTC))

Testing

After hearing Jimbo's Wikimania 2006 plenary speech ([4] [5]) I'm taking a stab at this. I know this system isn't "ready", but the thrust of what Jimbo said about it seemed to me: let's get going. If we don't try it out we'll never know. --Francis Schonken 10:55, 8 August 2006 (UTC)

That's all well and good (I'm hoping to see a transcript at some point, as I don't know when I'll have time to listen), but unless the problems and concerns that folks have put up here and at Wikipedia:Stable_versions_now are addressed, I'm not sure this will ever get off the ground, nor should it. The slowly-becoming-constant "trial balloons" while those of us with issues concerning stable versions are ignored is going to be frustrating to a lot of people, myself included. --badlydrawnjeff talk 12:05, 8 August 2006 (UTC)

Wikipedia:Stable versions now is {{rejected}}. No need to wait for anything there any more. That trial balloon has popped. Are there any issues you couldn't make clear with the test case I proposed below as example? --Francis Schonken 12:16, 8 August 2006 (UTC)

Yes, it was rejected because people are not ready for stable versions. Are you ignoring what other editors have to say on the matter of stable versions in this case? --badlydrawnjeff talk 12:20, 8 August 2006 (UTC)

The article is not very clear about this, but I gather from the templates that the difference between this proposal and Wikipedia:Stable versions now is that under this proposal, readers get by default the unstable version, which contains a box with a link to the stable version, while with Wikipedia:Stable versions now, readers would get the stable version with a link to the unstable version. In fact, this proposal seems to be very similar to Wikipedia:Stabilizing featured articles which looks set to be accepted. -- Jitse Niesen (talk) 13:38, 8 August 2006 (UTC)

Except much of the problem had to do with the actual idea of stability, and what the issues with that will be. Is this an improvement in terms of ability to edit? Absolutely. Does that mean that it's worth trying for stability? I certainly can't say. --badlydrawnjeff talk 13:58, 8 August 2006 (UTC)

I was at Wikimania - I missed Jimbo's talk but led a discussion on validation which included stable versions. I also had many one on one discussions with people at the conference. What I gathered is (a) It has been agreed that the German Wikipedia will go ahead testing stable versions as soon as Brion can adjust the code (end of the month?) - this was also announced on American National Public Radio so it's pretty definite. (b) Assuming tests there go well, it will come to the English Wikipedia and other languages as well. I had some reservations about this going in, but I heard many very powerful arguments that meant I came away convinced we have to deal with this. I don't understand any testing here (Brion hasn't set up software yet!), but I think stable versions are coming. Have no fear, the editable versions are not going to disappear! In fact, Jimbo and others have argued that stable versions should allow us to deprotect almost all pages, because if the George Bush page gets vandalised most users will not even see it. The best thing to do is to discuss how we should implement them most effectively, and to watch what the Germans find on their site. If it's a disaster there, then I guess we won't see it, if it works well we will see it. Walkerma 18:30, 8 August 2006 (UTC)

That's all well and good, but I'm merely pointing out that there is a significant segment of editors who need to be convinced of this as a worthwhile endeavor. Whether "stable versions are coming" is largely going to rely on the cooperation of the editors as much as the desires of the higher-ups. --badlydrawnjeff talk 19:05, 8 August 2006 (UTC)

One thing I meant to mention - someone from German Wikipedia referred to stable versions as unvandalized versions - a great way of describing the idea! Walkerma 19:23, 8 August 2006 (UTC)

Stable versions can be used to tackle other things than vandalism, but when used as a replacement for semi-protection (eg. it deals only strictly with vandalism, and is used only when there's an ongoing pattern of vandalism, and editors who have been around for any period at all can merge back to the stable version), then I think that's really a no-brainer because it's more open than semi-protection.

Once stable versions replaces semi-protection, and people get comfortable with how it works in practice to deal with cases of busts of vandalism, then we run other experiments to see whether stable versions work in other cases too (eg. whether it's okay to leave articles stablized for longer periods of time, whether it is suitable for things like featured articles). But, it would be good to only use it as a replacement for sprotection at the beginning, because that's a no-brainer. --Interiot 04:56, 12 August 2006 (UTC)

Test case 1: Gnossienne

I'm going to apply the procedures described at Wikipedia:Stable versions#Procedure for nomination to Talk:Gnossienne ... and see what happens. --Francis Schonken 10:55, 8 August 2006 (UTC)

One immediate comment: identifying the stable version by date and time would be better than version number; it's more intuitive, and it makes obvious how long it has been the stable version was updated. Septentrionalis 16:06, 9 August 2006 (UTC)

The Focus of this version should be on discussion. A static wikipedia is an oxymoron

I think it's important to recognise that discussion of protected articles is the main basis for the creation of a 'static' version of wikipedia.

Discussion of protected articles is what 'Wikipedia static' should primarily be about, rather than a 'static' version of wikipedia. We should not fool ourselves by ever calling wikipedia 'static', or any other encyplopedia for that matter.

An encyclopedia is never static, the suggested title is an oxymoron. For that matter, neither are they ever really stable, as the world changes daily, although the degree of stability of fields of knowlege vary and perhaps, degree of content stability is something that should be a feature of each article, perhaps as a rating?

Also I think this proposal is an opportunity to refine the process for mediation of POV disputes. Perhaps POV disputes should be its focus?

So, let me get this straight...

The proposal works like this: In order to stabilize an article, a group of editors will hold an AfD-style vote over an unspecified timeframe. An admin looks at their votes, determines consensus, and stablizes the article. After that, any change at all to the article requires another complete vote. If current events break out related to the article's subject, or if a glaringly wrong, paragraph-length error is discovered that leads to a serious content dispute on the talk page when people try and decide how to fix it, there is absolutely no way to revoke an article's stable status (or at least none listed here; the proposal doesn't technically say that it modifies Wikipedia:Protection policy and preempts requests for unprotection on Wikipedia:Requests for page protection, but that can probably taken as a given.) Aside from the uncouth use of 'vote' to describe the AfD procedure we all know and love, is my description of this proposal basically correct? Because, um. I'm not sure that the AfD procedures have done so well that we'd want to copy them to someplace where we'll have to go through one every time we want to update an article. --Aquillion 16:51, 10 August 2006 (UTC)

No. There remains a wiki version of the article that is dynamic. The stable version of the article only changes after consensus, and will not keep up with current events. Stable versions (like paper) should not change with the vagaries of the news. I agree AFD is not to be emulated. dml 21:32, 10 August 2006 (UTC)

Unless you're saying that the dynamic version will be the first one presented to people when they navigate to the page, I fail to see the distinction. Plainly a system that would have us wait for five days or so just to fix a serious error in the displayed version of a 'stable' page is simply unworkable... we cannot rely on admins to fix such errors, since allowing non-trivial admin edits to protected pages amounts to asking them to make and enforce content decisions. Likewise, if the subject of an article is killed in a car accident, we need to have that on the displayed page now, not several days from now; chances are most of the people coming to the article at that point will be people coming to read about that event. Additionally, does this mean that the main page's "in the news" feature will be eliminated? With stable versions taking several days to update their displayed version, we won't be able to track current events effectively. Wikipedia isn't a wire news service, certainly, but one of our chief advantages is the ability to keep articles up to date with current events; requiring a lengthy vote-and-determine-consensus system just to update the displayed version of a stable article would undermine this. I don't like the idea at all, but I can at least think up a solution to that problem: The proposal needs an 'emergency update' process that allows the dev version to be copied over quickly when necessary; possibly there could be some sort of special page to post to in order to attract the necessary attention to an emergency update? After an hour on the emergency update list, if nobody objects and a certain number of people support, the page is updated. --Aquillion 01:05, 11 August 2006 (UTC)

If you can have an emergency, then the page should not have been "stablized". --EMS | Talk 02:27, 11 August 2006 (UTC)

So you're saying that articles about living people, existing governments or organizations, and other things subject to sudden and drastic change should never be candidates for stable versions under this proposal? That makes up a fairly large percentage of our articles. --Aquillion 22:15, 11 August 2006 (UTC)

The two areas that I dabble in primarily are physics and meteorology. In physics, stability is certainly attainable for its articles. In meteorology, and espcecially in the current hurricane season page, you absolutely do not want it. Overall, I think that the real issue is how to handle anonymous vandals. Stability means that their change is not immediately available, and most like gets removed before it can be made "stable". However, I wonder if there are not other ways of achieving the same thing. For example, you could set up a scheme where the logged in editors can validate proposed anonymous edits. If one editor approves the change in a 24-hour period, then it will "take", for example. (You could also have the edit expire if three editors reject it.) Another idea is to use automation to detect a current stable version, perhaps with the ability to have an administrator disable the detection in an "emergency". (I will support emergency destablization, but not emergency updating of the stable version. The latter gives too much power to one person.) --EMS | Talk 01:41, 12 August 2006 (UTC)

From User:Jimbo Wales

3."You can edit this page right now" is a core guiding check on everything that we do. We must respect this principle as sacred."

Wouldn't this proposal go against this? Also, wouldn't this proposal go against the Slogan "The Free encyclopedia that anyone can edit"? Don't give me the defense "well technicaly anyone still can edit it..." because you know as well as I do that that isn't fully truthfull. If you want a stable version, make it a link on the top, but leave the wiki as the main setting. --Wikipedia's False Prophet holla at me Improve Me 02:14, 25 August 2006 (UTC)

As Jimbo pointed out at Wikimania, this should allow MORE pages open for editing, as it would allow pages like George W. Bush to be deprotected. As I understand it, Wikipedia will look very much the same except when you click on EDIT you will get the latest version which will differ a little from the stable version. As someone from German Wikipedia reminded me at Wikimania, Wikipedia is an encyclopedia that happens to use a wiki as a tool, not a wiki that happens to be an encyclopedia. We have to remember that the vast majority of readers want the information, and stable versions offer them a more reliable information source. Remember - the stable version is just a version from the history, which even now can't be edited! Walkerma 03:00, 25 August 2006 (UTC)

Testing stable versions on German Wikipedia

People might easily miss this, and yet it transforms this project completely, so I'm copying it verbatim from the meta site m:2006 proposed approval for anonymous edits to make sure people are aware of the tidal wave about to hit! I added a comments section below.

TEXT BELOW COPIED FROM META PAGE

The 2006 proposed approval for anonymous edits was mentioned in passing at Wikimania 2006, and the press grabbed it and ran with it. This page is intended to set the record straight on what is intended.

It is currently planned to test the feature on de: Wikipedia. If it works well there it may be tried on other wikis.

"Approved" versions on Wikipedia FAQ

On 30 August, after much ComCom discussion, David Gerard wrote a FAQ for the press and for Wikipedia editors. Original version.

If editing this text, please leave the URLs as-is, so this text can be cut-and-pasted to plain text email as needed.

Overview

The Wikipedia community has discussed potential methods of displaying "approved" versions of articles since shortly after the project began in 2001. (Wikipedia was originally put forward as a possible source of raw material for approval by the Nupedia project.)

From these discussions, the German language Wikipedia is currently developing an implementation to be tested in the near future.

What is changing?

The default view for casual (not logged in) readers visiting the German Wikipedia (http://de.wikipedia.org/) will be slightly modified. Some articles will display the latest version that has been flagged as "non-vandalised" or "confirmed", with a link to the current working version. For logged-in readers and editors, nothing will change.

This change will only be on the German Wikipedia and only for the testing period. If the feature works well there, it may be made available for other Wikimedia wikis if their community approves it.

Why?

We want to open up editing without damaging the reader's experience.

We want to be more wiki and let editors edit freely, which is where all the good things come from. At present a small percentage of articles are locked or partially locked from editing. We want to open these up. But Wikipedia is a top 20 website (Alexa ratings, no. 17 on 3 month average; no. 15 on 30 August 2006 — http://www.alexa.com/), so we must maintain or improve the readers' experience.

How does it work?

The details are very vague at present as the feature is still being written, and most of the details below are speculative.

All edits to Wikipedia articles are available in the article's history. The new system will allow an experienced editor to mark a version as "not-vandalised." The marker is called a "version flag." When a casual reader loads an article, the Wikipedia software will display the most recent flagged version.

Under the current proposal, almost all editors will automatically have the ability to mark an article version as non-vandalised. Furthermore, when an experienced user edits an article, that version will automatically be marked not-vandalised, so very recent versions will always be available.

A second version flag, a "confirmed" flag, is also being considered. The community is still discussing how this flag will work. It has not yet been decided who will be able to mark a confirmed version, but the most recent article version marked with either flag is the one which will be displayed by default.

When there are more recent versions than the flagged one, the 'edit' tab will be replaced by a link to the most current version, allowing anyone to view or edit the current working version.

When was this proposed?

The first specific proposal to develop a "fixed" version of Wikipedia articles came in August of 2001[6]. Many variations have been discussed since then.

The current proposal grew out of such discussions within the German Wikipedia community. In June 2006, they asked the Board of the Wikimedia Foundation to run the experiment. The software and policy implementations are still being discussed.

Press coverage

• Not as wiki as it used to be (Bill Thompson, BBC) - note link to correction.
• Wikipedia to close doors on approvals (Platinax.co.uk) - largely based on Bill Thompson article

Comments

I would like to replace the procedure currently listed on the main Stable Versions page with this procedure, since this is the current system being tested. Is this OK? Walkerma 15:37, 31 August 2006 (UTC)

Well the current article corresponding to this talk page is garbage (it only represents one person's ideal), anyways, so it really doesn't matter. i personally think we can do much better than the model being tested on the german wikipedia, but oh well. Kevin Baas^talk 17:48, 31 August 2006 (UTC)

If we can do better, we should decide how, and then raise this on meta. The German Wikipedia has a different culture from this site, so we may elect to run things differently, but I think we should use their method as a starting point for discussion. Brion (who is writing the code for this) has said things are still fairly vague at the moment. He also confirmed today "the latest versions on any reviewed/approved/time-delayed/whatever page will *ALWAYS* be available to everyone, at most one click away." Walkerma 20:46, 31 August 2006 (UTC)

German version details

I've been following the German implementation discussions (see de:Wikipedia:Gesichtete_Versionen and de:Wikipedia:Geprüfte Versionen if you can read German) and generally like what they have come up with. They are talking about having two types of flags... one to indicate a particular edit has been 'reviewed' to verify that there is no obvious vandalism and another to indicate that it has been 'proofread' to verify that all facts are backed up by valid references. Logged in users would have the option of defining which version they want to see by default while anons would get the 'reviewed' (no vandalism) version by default. If no edits are flagged as 'proofread' then you'd get the most recent 'reviewed' and if none are flagged as 'reviewed' you would get the current version. All users will be able to click to see any version. When viewing 'reviewed' and 'proofread' there would normally be a 'view current version' option instead of an 'edit' link... thus changes would normally be made to the current rather than to older copies. Images and templates called by a particular page would always show the current version of the image/template, though there has been discussion about that changing in the future... which I think would be needed to 'unprotect the Main Page' as Jimbo has dreamed of doing. The part of the plan which I think makes it viable is that the 'reviewed' tag will update automatically in alot of cases... if a 'trusted user' (which is defined as a registered account with X days and/or Y edits) creates an article then it is automatically marked 'reviewed'. Likewise, if a 'trusted user' makes an update to a version of the article which WAS 'reviewed' then the new version will also automatically be 'reviewed'. Finally, any trusted user will be able to mark an article 'reviewed' with any edit by clicking a box. They are talking about 30 days and 30 edits to be a 'trusted user', but it can vary by project. The 'proofread' status would be restricted to a smaller group which has not been defined yet... I'd think it should be an individual flag like 'bot' or 'checkuser' as there are non-admins who would excel at this and admins who have nothing to do with it. Note that 'proofread' indicates a higher level of verification than anything we have currently... not just that references are listed, but that they have actually been checked to verify that they support every fact in the article. Thus, the 'reviewed' level would be intended to indicate that there is no obvious vandalism and the 'proofread' level that an article contains only accurate / verified information... though either could still be applied to a stub with spelling and/or grammar errors. Which leads me to think that a third flag for 'well written' or an all encompassing 'publication ready' (aka 'featured') status may be needed. --CBD 16:43, 10 October 2006 (UTC)

Current status?

Now that some month have passed - what is the current status of the stable version project? Is there a site or article for this? --Bernd-vdb 14:07, 26 March 2007 (UTC)

Hmm, it seems the Roadmap could be the right place to look: http://www.mediawiki.org/wiki/MediaWiki_roadmap

Which tells us the point is handled under the name "revision tagging". Classified as "Priority: highest" and "assigned: contractor". Any more info on that? --Bernd-vdb 14:26, 26 March 2007 (UTC)

There was a blip of this mentioned on the signpost. What's going to implemented first is CentralAuth (the single-user login). After that's complete, expect to see some kind of stable versions soon. That's from what I've read. Also, on the Roadmap talk page: "That was vaguely targeting end of 2006, but it's ended up sliding. There's a new programmer on it, we're hoping to see it ready for demoing and public testing in a month or two from what I heard." --brion 22:16, 17 February 2007 (UTC)

Mahanga^{Talk to me} 14:55, 26 March 2007 (UTC)

FYI - People interested in this should see stablepedia.org. This is a site which locates what it considers to be the most recent stable (or at least unvandalized) version of an article. This is at the least acting as a testbed for automated stable versioning, and is worth a look-see and some testing to see what it turns up. Obviously some good feedback will help the creator. Similarly, the experiences of the stablepedia can be used to refine the Wikipedia stable versioning. --EMS | Talk 20:27, 26 March 2007 (UTC)

All work on this is ongoing here. Voice-of-All 04:35, 4 April 2007 (UTC)

Thanks Voice of All for keeping us informed. For this interested, here are the specs and a test wiki for the extension. Mahanga^Talk 14:47, 4 April 2007 (UTC)

It's no voting system or stable version detector. Looks to me like just another arena for edit wars. The edit boxes at the bottom might as well be merged with the standard edit box, and the traditional {{ }} templates used to "tag" revisions.

I.e. it's purely cosmetic, with the only novelty being that some people can change which revision is displayed. Kind of like having a group of users who can protect articles (currently called "administrators"), and put in their own favorite versions (currently against policy), while the peons discuss on the talk page how they want the protected article to change - only difference being that the "protected article" is now the "stable revision", and the "talk page" is now the other revisions. The group of users who can select the stable ("protected") version can war over which article is the "protected" revision.

Please forgive any offense from my skepticism. I just don't think the article tagging feature is really adequate. Functionally, it doesn't really provide anything new. It's the same thing in different clothes.

Something new would be: people voting on which is the best revision, and the software automatically enforcing that vote. This would be functionally different from the way wikipedia currently works. and that's what is needed, not another edit box or set of templates; not something easily reproducable from existing wikipedia features. we already tried that (by having the features that it's easily reproducable from). it didn't work. that's why we're here.

how about a new database table with five fields: article, revision, user, rating,timestamp. 1 rating variable. Not 3. Keep it simple, stupid. The talk page is there to discuss the specifics of what people (not anonymously!) like or don't like. The rating is to select the stable version, and that's it. you only need 1 rating variable to do that. And please don't confuse this process with CD selection. (A-class, B-class tagging, etc.)

any (logged in) user can vote on any revision of any article. rating can be up or down, or a point scale. The article with the best average rating is the stable version. simple. effective. Kevin Baas^talk 18:21, 5 May 2007 (UTC)

If there was actually debate over which version was 'stable', it wouldn't be stable at all, and the debate would cease to exist. A stable version would only be made when there was no controversy, and a large number of articles are not controversial in any way. 130.216.191.182 07:16, 22 May 2007 (UTC)

No, a stable version would be made when the net number of vote flips between the version with the plurality and another version is smaller than the vote difference between the version with the plurality and the version w/the next highest vote count(/score). And when there is a controversy, the number of vote flips is usually pretty close to zero, resulting in a stable version. The only way to change the stable version is for someone to post a new version that more people approve of (and less disapprove of) than the current version, i.e. only when a controversy is resolved does the article become unstable. Kevin Baas^talk 14:55, 7 April 2008 (UTC)

No, it seems like a very reasonable system; but we just need to figure out the appropriate processes of using this. Are we prepared for this? I think we should establish a very quick system for when people are given the Editor privilege (I hope this class isn't just the same as those that can edit semi-protected pages). This would be easy, similar to RfA, but with a far lower standard, things like being civil and good editor doesn't matter, the only question is: do we trust he isn't a blatant vandal. The more important quality reviews is a far more difficult issue, in my opinion, these should only be set by admins according to well-defined QA processes. We would probably need some regular review process, and maybe WikiProjects need to take a role in this... Anyway, I really hope we can implement this stuff as soon as possible. --Merzul 16:54, 31 May 2007 (UTC)

Flagged revisions

I want to start a proposal for a guideline/policy called Wikipedia:Flagged revisions about how the new software capabilities should be implemented. I think this page should be kept for historical reasons. --Merzul 17:02, 31 May 2007 (UTC)

For convenience, I just added links to that page to the See also section. --SteveMcCluskey (talk) 02:49, 5 April 2008 (UTC)