Last modified: 2011-03-13 18:05:33 UTC
This is not a bug. This is a suggestion for enhancement. Current version (1.5) has the following tab on top of normal article: [article] [discussion] [edit] [history] I propose: [stable article] [article] [discussion] [edit] [history] What is [stable article]? It's the automatic display, by the software, of the "most recent stable version" in the history of an article. "Most recent stable version" is defined as the version that is most recent among the "stable version". "Stable version" is the version that "exist" for a time T > T0. T0 is chosen the "bureaucrat", after a concensus of the community, for example "1 month". The "existence time" of a version is the different between it's "creation time" and it's next version's "creation time". Most recent stable version can be extended to not include "stub" pages (pages in category stub). How may it function? *External link to Wikipedia article can be set to stable version. *Un-registered user can be, by default, direct to stable version when searching/browsing Wikipedia. If he/she is interested in newest version (possibly unstable) and in editting it, click the appropiate link. *For registered user, everything behave normally, except extra tab of stable version. *This new feature can be an option for the entire Wikipedia site. Bureaucrat can turn it on or off at will. Why is it interesting? *External website can create link to stable Wikipedia article whithout warrying about unstability (vandalism, ...). *Wikipedia becomes closer to a directly linkable source of stable information (therefore of some degree of ensured quality), hence be more useful for the community. Probabaly people have thought about this, though I have not seen it here. If it's not here yet, hope people will comment and refine this idea. If it gains interest in the community, hope people would develope this into reality. I regret that currently, I don't have time to hack and create a patch for this.
*** Bug 3070 has been marked as a duplicate of this bug. ***
Is this a duplicate of bug 476, or separate?
(In reply to comment #2) > Is this a duplicate of bug 476, or separate? This is not entirely duplicate of bug 476. It is a sub-problem of bug 476. Stablility is one simple and objective way to evaluate quality, however there may be other ways to set "trust level" in bug 476. Probably, bug 476 related to a much more complicated way of getting "trust level" out for each article. This bug suggest only one simple way. This bug can be resolved independently with bug 476. However, if bug 476 take into account stability and resolve this, the two bugs can be merged.
One month is far too long. Many articles are under constant editing, and would not ever have a stable version under this definition. In addition, if the article is vandalised and this was not spotted for a month, there would be no easy way to correct it- it would take a month for the correction to become stable. So you would need a stable article indication for use by admins or whatever as well; so this bug is incomplete.
(In reply to comment #4) > One month is far too long. Many articles are under constant editing, and would > not ever have a stable version under this definition. In addition, if the > article is vandalised and this was not spotted for a month, there would be no > easy way to correct it- it would take a month for the correction to become > stable. So you would need a stable article indication for use by admins or > whatever as well; so this bug is incomplete. > This bug suggests the one simple way to get some sort of quality indication out of just statistics (no human intervention, except for the T0 chosen after a concensus of the community; where 1 month is just an example, not a fixed value). Certainty, you can study problem a little bit harder and add more complicated caculations for "quality indication" that fail less. So far I have not seen a "complete" solution though. Do you know one?
The existing user accounts and articles history offers a way, through some automagic analysis, to detect existing 'Wikipedia experts'. The analysis will calculate, for each existing user, an 'efficiency score' on each category based on the volume, age, audience and stability of his writings. Classic statistics. On each category 'some' (one-per-thousand?) best writers, who produce good-and-stable articles, will be immediately promoted into some 'Wikipedia expert' status. Those experts will form the category's "council", able to 'promote' an article into the 'stable' status, and also to promote other users into the 'Wikipedia expert' status. There is a proposal at http://www.makarevitch.org/webdsign/#wikipedia
See also: * bug 3040 * bug 3303
can we fold this into 4288?
(In reply to comment #8) can we fold this into bug 4288?
This is FlaggedRevs, I'm CCing Aaron so he can dupe it or close it or adjust it appropriately.
This should stay as it's own bug. FlaggedRevs does not have arbitrary tagging, the tags are just metadata for stable versions. Also some of the stuff at 4288 is done by SMW.
This bug isn't about arbitrary tagging, it's specifically about tagging stable articles. It seems to ask for an automated procedure, though. Bug 476 is closer to actual stable versions. Regardless, I don't think either of these should/will be in core any time soon. These are extension features. I'll WONTFIX them on that basis, to keep things tidy (people might think they're actually being worked on, otherwise).
(In reply to comment #12) > This bug isn't about arbitrary tagging, it's specifically about tagging stable > articles. It seems to ask for an automated procedure, though. Bug 476 is > closer to actual stable versions. > > Regardless, I don't think either of these should/will be in core any time soon. > These are extension features. I'll WONTFIX them on that basis, to keep things > tidy (people might think they're actually being worked on, otherwise). > Right, I was talking about bug 4288, since someone suggest duping do that.
