Last modified: 2011-03-13 18:05:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T5044, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 3044 - Stable page beside Normal page
Stable page beside Normal page
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Lowest enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 3070 (view as bug list)
Depends on:
Blocks: 3741
  Show dependency treegraph
 
Reported: 2005-08-04 14:56 UTC by Trần Thế Trung
Modified: 2011-03-13 18:05 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Trần Thế Trung 2005-08-04 14:56:00 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.
Comment 1 Brion Vibber 2005-08-08 15:16:31 UTC
*** Bug 3070 has been marked as a duplicate of this bug. ***
Comment 2 Brion Vibber 2005-08-08 15:18:18 UTC
Is this a duplicate of bug 476, or separate?
Comment 3 Trần Thế Trung 2005-08-09 09:29:32 UTC
(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.
Comment 4 Ian Woollard 2005-12-27 13:59:58 UTC
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.
Comment 5 Trần Thế Trung 2005-12-30 10:32:37 UTC
(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?
Comment 6 Nat Makarevitch 2005-12-30 10:41:58 UTC
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
Comment 7 Melancholie 2006-02-07 23:19:25 UTC
See also:
* bug 3040
* bug 3303
Comment 8 Jeff Martin 2006-07-12 20:56:54 UTC
can we fold this into 4288?
Comment 9 Jeff Martin 2006-07-12 20:57:35 UTC
(In reply to comment #8)
can we fold this into bug 4288?

Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-13 16:17:36 UTC
This is FlaggedRevs, I'm CCing Aaron so he can dupe it or close it or adjust it appropriately.
Comment 11 Aaron Schulz 2008-01-13 18:44:28 UTC
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.
Comment 12 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-13 18:54:12 UTC
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).
Comment 13 Aaron Schulz 2008-01-13 18:55:58 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links