[Foundation-l] moving forward on article validation

[Erik Moeller]

On 6/14/06, Delirium <delirium at hackish.org> wrote:
> (Mainly concerning wikipedia, but cross-posting to foundation-l because
> of some discussion of committees; see the end.)
>
> 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.

I'm working on a set of consolidated specifications for this, please
give me a few days until I finalize it (it's a fairly large document).
Allow me to quote from the set of requirements I start with:

* revision-specific tagging rather than article-specific tagging
* changeset-oriented: when possible, only review the changes from the
last reviewed revision to the next unreviewed one
* scalability in the overall quantity of articles reviewed per time unit
* distinction between different types of review, such as vandalism,
accuracy, neutrality, copyright status, etc.
** acknowledge that different people have different abilities to
review these different aspects of an article
* systematically involving editors who are self-selected as being
qualified in the particular disciplines
* universal applicability to Wikipedia, Wikinews, Wikisource,
Wikiquote, Wiktionary, and any other open wiki project using MediaWiki
* facilitate fixing problems over tagging them
* discoverability. All aspects of the user interface should be
discovered by the average wiki editor during normal use of the system.
* fun. Any review process must be addictive and simple in order to
motivate long term interest.

I've been mulling over this problem since 2002 and I think that all
proposed processes fail in several of these criteria. That is not to
say that I believe I have the "one answer", but I hope the specs I'm
working on will become a basis for further renewed discussion, and
lead directly towards a realistic implementation path.

Erik