[Foundation-l] moving forward on article validation

[SJ]

Note that the "Wikipedia 0.5" WikiProject on en:wp is tackling this
issue with some energy, and could use more input and nominations:

http://en.wikipedia.org/wiki/Wikipedia:Version_0.5_Nominations

On 6/13/06, Michael Snow <wikipedia at earthlink.net> wrote:
> Delirium wrote:
>
> > We've discussed on and off that it'd be nice to vet specific revisions
> > of Wikipedia articles so readers can either choose to read only
> > quality articles, or at least have an indication of how good an
> > article is.  This is an obvious prerequisite for a Wikipedia 1.0 print
> > edition, and would be nice on the website as well.
> >
> > There is a lengthy list of proposals here:
> > http://meta.wikimedia.org/wiki/Article_validation_proposals
> >
> > I wanted to try to rekindle the process by summarizing some of the
> > proposals, which I think can be grouped into three main types, and
> > then suggest some ideas on where to go from there.
>
> Thank you for taking the time to address this.

Ditto.

> > Proposal #1: Fork or freeze, then bring up to our quality standards.
<
> > Some cons: Either disrupts normal editing through a freeze, or results
> > in duplicated effort with a fork.  Also is likely to result in a
> > fairly slow process, so the reviewed version of each article may be
> > replaced with an updated version quite infrequently; most articles
> > will have no reviewed version, so doesn't do much for increasing the
> > typical quality of presentation on the website.

Duplication of effort is bad.  Branching, rather than forking, for a
very limited time duration, makes sense for various end uses.  For
instance, a single good revision of an article might support a dozen
branches each of which pared it down to a different length.  We will
need a better notion of 'article revision history' that supports
branching, or non-linear revisions, to properly allow for this.  I
believe there is some theoretical work being done on distributed
version control for text...

Michael Snow writes:
> This option would work well, I think, for two possible uses. One is for
> offline distribution, since there's less point in creating a fork that
> will just be another online variation on the same theme.

It will be helpful to distinguish between branching (which ends after
a point and either remerges with the main trunk or is at least never
modified again) and forking (starting a separate revision history with
different end goals, to continue indefinitely).

Each offline copy gets modified slightly for format reasons, anyway.
The question is whether to provide for such branching within a central
wikipedia database.

< The second possibility I think we would benefit from is the "freeze" option of
> presenting stable, reviewed versions by default to users who do not log in.

This seems a poor and less-scalable way to present stable versions to
users; see other methods below.


Delirium:
> > Proposal #2: Institute a rating and trust-metric system
> > ---
> > Wikipedians rate revisions, perhaps on some scale from "complete crap"
> > to "I'm an expert in this field and am confident of its accuracy and

Naive, single-scale ratings have many problems that I don't see being
overcome.  (The advogato suggestions are no panacaea.)  Allowing
groups of editors (self-selecting, auto-selected by user properties)
to provide revision metadata that others can choose to see or not see
as they please would be more scalable and less gameable.  Some of
these groups could provide metadata of the form 'decent and not
vandalized content'.

> > Proposal #3: Extend a feature-article-like process

I'm not sure what you meant by your example -- for instance by 'work
on revisions rather than articles', as the goal is still a better
article (you can't change a historical revision) -- but this is
effectively what the en:wp validation effort is attempting.  This
scales in that it can be split up among topic-centered WikiProjects.
See for instance this list:

http://en.wikipedia.org/wiki/Wikipedia:Version_1.0_Editorial_Team/WikiProject_full_article_list

Avoiding hard-coded metrics for quality, and encouraging editors
active within a topic to work together to reach quality decisions,
seems in line with how editing has evolved.  This is like peer review
and FAC review that already takes place, but can be applied to a wider
spectrum of quality.

--SJ