Page MenuHomePhabricator

Stable page beside Normal page
Closed, DeclinedPublic

Description

Author: tttrung

Description:
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.


Version: unspecified
Severity: enhancement

Details

Reference
bz3044

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 8:45 PM
bzimport set Reference to bz3044.
bzimport added a subscriber: Unknown Object (MLST).
  • Bug 3070 has been marked as a duplicate of this bug. ***

Is this a duplicate of bug 476, or separate?

tttrung wrote:

(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.

ian.woollard wrote:

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.

tttrung wrote:

(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?

nat wrote:

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

Wiki.Melancholie wrote:

See also:

  • bug 3040
  • bug 3303

dogshed wrote:

can we fold this into 4288?

dogshed wrote:

(In reply to comment #8)
can we fold this into bug 4288?

ayg wrote:

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.

ayg wrote:

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.