Last modified: 2005-08-08 15:16:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3070 - stable versions
stable versions
Status: RESOLVED DUPLICATE of bug 3044
Product: MediaWiki
Classification: Unclassified
History/Diffs (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
http://www.makarevitch.org/webdsign/#...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-07 21:29 UTC by Nat Makarevitch
Modified: 2005-08-08 15:16 UTC (History)
0 users

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


Attachments

Description Nat Makarevitch 2005-08-07 21:29:52 UTC
according to a Yahoo newsline (dated 20050805,
http://news.yahoo.com/s/nm/20050805/wl_nm/media_wikipedia_dc) J. Wales (of
Wikipedia fame) said
"There may soon be so-called stable contents. In this case, we'd freeze the
pages whose quality is undisputed"

afaik the 'stable content' status is implemented into Mediawiki 1.5

I have an idea which may lead to the same 'antipolluting' result with less
stress for contributors who like the 'anybody-edits-any-article' approach
while satisfying those who like expertized articles. imho it may be useful for
all Wikis, including Wikipedia. it is based upon a more general approach

the basic idea is that various groups 'seal' the articles in order to
express their various status (raw, unpolluted, validated, expertised). I wrote a
proposal describing the techniques. it shows that it will not harm anyone
who likes the existing Wikis ('anyone-can-edit-anything-anytime')

you may find the description at
http://www.makarevitch.org/webdsign/#wikipedia

it describes the application to Wikipedia of a more general approach of
document sealing, described in the same document
(http://makarevitch.org/webdsign/)

I thought that Wikipedia may be interested and the Help Desk indirectly
suggested that it may be of interest for you. I'm ready to add to this ticket a
complete description in order to let your archives store the entire topic. feel
free to contact me if I can be of any help.

here is a brief description:

for the sake of simplicity this text discusses the Wikipedia case but the
approach may be applied to any Wiki.

our objectives are:
<ul>
<li>avoid annoying anyone who likes the way Wikipedia now works
<li>give to anyone who prefers reviewed documents to obtain it
</ul>

in order to do so each Wikipedia article may have more than one status:
<ul>

<li>'raw', meaning 'last standard content' (any existing article has this
'raw' status)

<li>'unpolluted', meaning 'free from any vandalism'

<li>'validated', meaning that 'a Wikipedia commission of people knowing the
field validated it'

<li>'expertised', meaning that 'a world-known expert of the field checked
it ok'

</ul>

any Wikimedia visitor will be able to state in his profile that, upon
reading, [s]he wants to obtain the last version of any article which
reached a given status. if there is no such checked version the immediate
'lower' status will be published (this is recursive)

this will <em>not in any way annoy the reader who does not care about all
those darn article status :-)</em> because the personal profile
(preferences) of each registered user will state 'raw' by default and (for
registered and anonymous visitors) upon each article display a new tab will
offer access to the various other 'statused' version when such versions
exists

those various articles status will be expressed by cryptographic seals. it
is not mandatory as most functions proposed here can be implemented using
standard version-tracking tricks (taging, branching...) but some people may
want to have their screwed articles published with a forged status and try
to tamper the servers or network connection. let's integrate security
concerns as soon as possible

the [[http://www.makarevitch.org/webdsign/ WebDSign protocol]]
may be the technical foundation of such seals.

===Usage===

all the processes (requestiin-delivering-managing certificates, sealing,
obtaining information about a seal...) will be done using a Web navigator.

in order to produce a seal one needs a digital certificate (X.509 or
OpenPGP (PGP-GPG)), delivered (X.509) or signed (PGP) by a
[[Certification_Authority]] (CA), which will be Wikipedia organization. anyone
can check
that a given certificate (and all informations it stores) was issued by a
given CA.

any Wikipedia contributor will carry only one Wikipedia certificate, which
will store many attributes stating various useful parameters

====Giving the 'unpolluted' status====

any administrator will obtain a certificate in order to let him/her give
the status 'unpolluted' to any article.

====Giving the 'validated' status====

using the existing set of articles an automagic analysis of the volume of
informations produced and its relative stability ('unpolluted' status, age
and amount of readers) can establish a 'confidence score' for each
author. the administrators will use those scores and deliver certificates
to the best authors. those certificates will be qualified by an attribute
(named 'wpexpert') listing the name of the categories of expertise of their
carrier (themes, for example 'mathematics' or 'geography').

====Giving the 'expertised' status====

in each category this first college of 'wpexperts' will be enabled to form
a college in order to elect world-known 'experts' of the field. the CA will
produce certificates for them, with an 'expert' attribute storing the
pertinent categories names. at first they may be not very interested in
participatinf but as more and more will somewhat do emulation will raise
their involvement

====Future version====

as each article contains segments (chunks) of informations further
developments may enable the underlying software (Mediawiki) to dynamically
build every article by using the last version of every segment
corresponding to the visitor's preferred status. this will prolly imply
some way to state segments interdependancies
Comment 1 Brion Vibber 2005-08-08 15:16:30 UTC

*** This bug has been marked as a duplicate of 3044 ***

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


Navigation
Links