Article marker feature
This page is to propose a simple Wikipedia feature - the addition of an article marker in the edit history designating a particular "last-agreed-upon version". It would be chosen in completely wiki fashion - no voting, no ratings, no metrics.
There have been earlier attempts for a reviewed or stable version done by voting, spearheaded by User:Schewek (See Reviewed article version). The problem - most anything done with binding votes in Wikipedia is discouraged (see Polls_are_evil), and the thought of runnning votes for every single article in Wikipedia space is quite daunting.
In May 2005, David Gerard and Magnus Manske worked on defining an article rating and validation feature and implementation for MediaWiki 1.5. (See Article_validation and Article_validation_possible_problems). It was not made live because of concerns about the impact on the database and overall Wikipedia health. It also lacks a clear definitive plan, as the "possible problems" page states: "The plan at this stage is to gather raw data and not use it for anything except analysis afterwards to see what needs to go into place for 1.6, so we need not do anything at all as yet." Questionnaire design and the scale used is crucial, and something that will need lots of work and testing cycles.
These are the basics of the proposal:
- Every article in Wikipedia can have a marker indicating the last-agreed-upon version (LAUV).
- Anyone can change the marker to point to a particular version in the edit history, in wiki fashion. It would be, in effect, the version that "the crowd" considers the most acceptable one, while editing, sparring, major revisions are happening on the 'current' one.
- When there is widespread agreement, the marker can be moved upon every edit to be the current one.
- When there are controversial additions, large scale changes, or major reorganizations, the LAUV can stay back at an older version.
- Optional - in cases where it makes sense, a marker need not be designated. This is useful for stubs, short, young or about to be deleted articles.
Advantages of the system:
- Allowing the article to progress while users could reliably refer to a 'stable' version.
- Easy to understand
- Consistent with the simple, wiki operation of consensus.
- Straightforward implementation with minimal impact on technical resources
- Marking articles (and also having no markers) can help the sifting towards v1.0.
- Issues of how to integrate this into the user interface
- Edit wars over the marker (but likely no worse than any others in Wikipedia)
- Blunt tool, not as complete as a rating feature to capture what is good/bad
- "But there is an elegant solution somewhere between protecting an article (too rigid) and article rating (too complex) - every article can have a marker indicating the last-agreed-upon version. Anyone can change the marker to point to a particular version in the edit history, in wiki fashion. In effect, it would be the version that "the crowd" considers the most acceptable one, while editing, sparring, major revisions are happening on the 'current' one. If there is consensus that it is generally good, the marker can be moved upon every edit to be the current one. Or if overhauling is being done, the marker can be kept back to an older rev while issues are ironed out. (It removes the angst of having your edits "winning" and being in the current version, and removes much of the 3RR angst.)
- The marker system is easy to understand, straightforward to implement, minimally impacts current working methods, does not require agreed upon metric values, and is inherently wiki.
Michael Turley :
- How is a moving a marker to designate a preferred version functionally *better* than simply reverting to a chosen edit in the article's history?"
Anthony DiPierro :
- Sometimes it's useful to have additional "in progress" information in an article. That new information might not be completely fleshed out and presented in the perfect way, or maybe it is well presented but just hasn't been fact-checked by anyone other than the original author. It still is useful, though.
- Think of it like software development, with a stable and a current branch. There's bleeding-edge-not-quite-fact-checked Wikipedia and there's stable-fact-checked Wikipedia. All without forking or protection of pages.
- The trick I think is making "marker movement" a slower process than article development. That's where I think a process like the FAC process comes into play."
As a professional software developer I agree that the advantages and disadvantages of this "feature" have been laid out accurately and fairly. I also believe that there is a way to make this work, even if I'm not prepared to make any specific suggestion at the moment (when I'm supposed to be taking a wiki-vacation!).
I suggest we just go ahead and try it. It won't hurt anything, and we can always tweak it as we go along. Ed Poor 13:36, 12 October 2005 (UTC)
This would add nothing, and would just be a further point of contention in any edit wars.--Poetlister 14:16, 25 May 2007 (UTC)