Proposal:Stable Release Tab
Every proposal should be tied to one of the strategic priorities below.
Edit this page to help identify the priorities related to this proposal!
- Achieve continued growth in readership
- Focus on quality content
- Increase Participation
- Stabilize and improve the infrastructure
- Encourage Innovation
|
Share this:
|
Summary
Wikipedia articles should have a mechanism of stable release, where editing takes place in a sandbox mode similar to the current wiki model, but is occasionally reviewed and transfered to a non-user-editable stable tab.
Proposal
The lifecycle of a Wikipedia article should flow as such. Phrases in italics are borrowed from free software development, and may need replacement for the wiki metaphor.
- A editor (anonymous or registered) creates an article.
- More editors join in to work on the article. The quality and depth of the article improves.
- Editors decide that the article is sufficiently complete to be useful. An editor with branching rights copies the current unstable article into a beta tab. Here editors perform non-content edits such as proofreading, fact-checking, and stylistic changes. Content development and traditional wiki editing continues in the unstable tab.
- The editor with branching rights categorizes the beta tab article as a release candidate. An editor with commiting rights--who is strictly forbidden from denying a commit for content reasons beyond blatant vandalism--ensures that there is consensus to stabilize and then commits the tab as a stable version. This stable tab becomes the default view for unregistered users.
- Unrestricted development continues in the unstable tab. When a revision of higher quality than the current stable version is produced, the unstable version is copied into a beta tab, which will in turn replace the current stable version through the process described above.
- Between such releases, important changes to the stable version (such as, for example, the subject of an article dying) can be queued and added by an editor with commiting rights.
Motivation
The content of Wikipedia, while excellent, is untrustworthy by the very nature of its creation. While stable releases do not ensure correctness or quality--any human system has failures--they decrease the amount of static noise (vandalism, misinformation) that average users are exposed to. The need for a new stable version to (by consensus) exceed the quality of the last decreases the chance of insidious threats such as POV-pushing and entropic decay. It also encourages editors to make a thorough review of article content from time to time.
Key Questions
- How wide should access to branching and commit rights be? Would this greatly increase bureaucracy?
- How would decreased update-frequency affect the timeliness of articles?
- Will the increased complexity/red tape in article development scare away new editors or alienate old ones?
Potential Costs
None forseen.
References
Community Discussion
Do you have a thought about this proposal? A suggestion? Discuss this proposal by going to Proposal talk:Stable Release Tab.
Want to work on this proposal?
- .. Sign your name here!