This is a failed proposal. Consensus for its implementation was not established within a reasonable period of time. If you want to revive discussion, please use the talk page or initiate a thread at the village pump.

For the latest developments on similar features, please see Meta:Article validation feature and Meta:Reviewed article version.

A stabilised article is an article which displays an older, consensus approved, stable version to readers. A separate development version is maintained for editing. Not all articles can be stabilised. A stabilised article should be demoted to a non-stabilised article if any of the criteria are broken, and may be demoted at any time on the judgement of any administrator.

Care is taken to avoid creating forks by discouraging edits to the stable version and prohibiting edits to the stable version which are not matched in the development version. The encouragement for new users to edit is preserved with a visible but tasteful notice, and attribution is preserved by referencing the new history location.

This policy explains the rationale for stabilisation, describes which articles may be stabilised, and defines the procedure for stabilising and destabilising articles.

Some day Wikipedia will have a sophisticated set of processes for article review and quality assurance. [1] It is believed that sophisticated processes will be required because for some subject areas correctly vetting content is a complicated set of problems. Because Wikipedia's practice of permitting promiscuous editing is relatively unprecedented in the world of reference works it is very difficult to determine which of the infinite possible review solutions will best fit our needs. It would be unrealistic to expect any of these solutions to get all the details right in the first pass, and since practically all pre-existing proposed solutions are tightly connected to software changes, we can expect the development of these review processes to be fairly slow.

This is unfortunate because the low stability of our articles reduces the usefulness of Wikipedia to our readers, and creates an undue burden on our editors because it creates urgency behind every repair.

The majority of articles are not controversial and do not require a sophisticated process. In these cases it is often easy to achieve true consensus on a version which is acceptable to all. As a result it is possible for Wikipedia to achieve a substantial stability improvement for some articles while at the same time gaining experience with this important aspect of article validation. This is possible without any changes to the software and without any major behavioural changes.

• Only articles of a reasonable quality level, per the judgement of the involved Wikipedians, may become stabilised articles. It is not necessary that the article have featured article, or even good article level quality. However, the article must contain no obvious factual, grammatical, or typographical errors and must contain at least some level of referencing.
• Only articles which are actively edited may become stabilised. Articles which pass months without edits are not eligible.
• The primary targets for stabilisation should be articles that provide a comprehensive coverage of the subject matter, such that it becomes highly unlikely for any large expansion of the article to take place in the foreseeable future.

If stabilisation is desired and an article meets the criteria:

• Place the ((stablenotice)) template on the talk page and begin a discussion. The template will invite outside editors to participate in the discussion with the goal of selecting a single acceptable recent revision to become the stable version. At a minimum the decision must include at least three editors, one of whom must be an administrator who is largely uninvolved in the article otherwise. The discussion should be allowed to run for a week, although the wait can be reduced if justified by the level of interest.
• Once consensus is reached move the article to [[ArticleName/development]] and add ((development)) to the top. Do not move the talk page.
• Create a redirect from [[Talk:ArticleName/development]] to [[Talk:ArticleName]].
• Then copy the Wikitext of the selected stable version to [[ArticleName]] and add ((stableversion)) to the top. Use the exact edit summary:

To view the complete history of this article and its list of editors see [[ArticleName/development]] (Based on revision Insert the revision number here).

• Protect the stable version and remove the ((stablenotice)) from the talk page.

The stable version should be synchronised to a recent development version at intervals which fit the natural pace of editing on the article, but no stabilised article should go more than three months without a synchronisation. The new stable version should be selected by 'suggestion and lack of objection' or other similar lightweight consensus processes, but must include a single largely uninvolved administrator at a minimum.

Direct editing of the stabilised version is highly discouraged. If there is any pressing requirement for a change it is recommended to destabilise the article, but if the change is sufficiently trivial any editing admin may make the change to both versions at his or her discretion. If there is complaint over such changes the article should be destabilised. If the stable version has been edited without the changes being reflected in the development version it has become a fork and should be deleted, and the article should be destabilised.

If consensus can not be achieved to select future stable versions after a reasonable complaint about the current stable version, or if there is any other cause to destabilise, an article may easily be destabilised. When in doubt, destabilise.

• Delete the current stable article (ArticleName).
• Move the development page to ArticleName and remove the ((development)) template.
• Add a note on the talk page and leave the page unprotected.

Development page