[WikiEN-l] "the experiment" - did it work?

Erik Moeller eloquence at gmail.com
Wed Jun 21 19:04:56 UTC 2006


On 6/21/06, Ian Woollard <ian.woollard at gmail.com> wrote:
> The more complicated you make it, the more unintended consequences there
> are likely to be, the more failure modes there are and the more unwieldy it gets
> to edit the Wikipedia.

*cough*
parametrized templates
mathematical expressions
embedded LaTeX
advanced image thumbnail syntax
magic words
EasyTimeline
wiki table syntax
commons integration
watchlists
categories
localization (to the point of pluralization algorithms for particular languages)
...

MediaWiki is a far cry from being a simple wiki engine like the little
Perl script that Wikipedia used to run on in 2001. Over the years, we
have added capabilities to give users more and more power, and to let
machines take over routine tasks. Some of the above solutions are
mature, others have a lot of room for optimization and simplification.

But do not confuse a simple user experience with a simple
implementation. Making things nice and smooth for the user is often a
lot of work for the developer.

I distinguish the problem of quality review from the problem of
patrolling and anti-vandalism measures. I agree with you that
patrolling and anti-vandalism tools (of which some delayed page
protection mechanism may be one) need not be particularly complex to
work well. The goal of quality review, for me, is to say that a
revision of an article
- has been thoroughly fact-checked
- is deemed to be neutral by the community
- has been checked for copyright violations or other legal issues
- meets stylistic and other formal criteria
- etc.

In essence, I am talking about _positive_ assertions about the
article's quality, rather than the _negative_ assertions for which we
use tagging. While individual tagging works well to make a negative
assertion (if you are wrong, it doesn't do much harm), for a positive
assertion, you need to have community verification and consensus.
Vandalism patrolling, meanwhile, is not about _assertions_ at all --
it is about intervention. It's a different class of problem
altogether.

WP:FAC is a good process in the quality review category, if I may say
so myself, but its scalability is very poor. This is in part because
it expects every editor to know everything. It does not accommodate me
going into a nomination and saying, for instance: "I've done a
copyright check on this article." "This article meets the MoS
criteria." There is no reward in doing so -- the article may still
fail the full review. The process of discussion is lengthy, the
procedure complex, and the standards of quality are very high.

WP:FAC also does not do changeset-specific review. It reviews on the
basis of the whole article only. This works well for the initial
nomination, but by the time the article has passed, it has often
changed significantly already. In other words, the quality of the
assertions we make about articles is dubious, and our ability to cope
with the rapid rate of changes limited.

I am interested in giving users power tools to enable them to review
articles rapidly and bring their skills to the fore. Furthermore, I
would like us to provide machine-readable metadata that allows
external re-users of our content, as well as scripts we use to develop
distributable versions thereof, to make use of the assertions that
have been made through these tools.

This is, I repeat, a complex problem. However, the solution needs not
interfere at all with the regular editing process. We can experiment
with different models alongside normal editing -- those users who do
not click the relevant buttons will never be bothered by any
review-related functionality (except, perhaps, for some visible
metadata on the article itself). I do not believe in models where
anonymous users are only shown reviewed content, for instance. The
content that is shown when you visit a particular URL should always be
the same for all users.

You are right that, if we succeed, the solution will be very neat and
simple from a user's point of view. But it will be the result of a
very long process of debating, thinking, and experimenting, and the
implementation itself may well be very complex.

Erik



More information about the WikiEN-l mailing list