On 8/27/07, Brion Vibber <brion(a)wikimedia.org> wrote:
sure that putting all of that into MediaWiki makes sense.
lot of it works best asynchronously.
A lot of it works best as part of
a workflow where software and people work as peers, and we don't
really have good ways for the mediawiki software to participate in
A wiki is inherently an asynchronous people-oriented bit of software. ;)
Certainly we'd like even more support for this.
On this subject, if you say it's true it is... but is there a parallel
to what I'm discussing someplace on our sites?
I've always seen a wiki as facilitating asynchronous collaboration
between people, but not people and software, except in cases where
software pretends to be a person (bots).
There are a LOT of people+software workflows on our projects. People
have built tools to facilitate those workflows using templates, bots,
and instructions for people. So far on our wikis, MediaWiki fits in by
helping collaboration by acting as a version control system and data
store, offering some reporting tools, and mostly staying out of the
So how should this work?
There have been a number of workflow enabling extensions built by people in
the past. For example
, but I'm not
aware of any of them being used on the Wikimedia Wikis.
We have conditions, sometimes they are automatically detectable
(duplicate images), or not (suspected copyvios). That detection
happens, and something the related page needs to appear in a list as
a result. Other things might happen which resolve the condition, or
they don't, and software needs to move the object along through a
series of steps until the issue is resolved. Today this is
accomplished by a mixture of templates, bots, and obsessive humans
(sometimes with userscript cybernetic augmentation ;) ). The
procedures change a lot, and are sometimes invented then replaced in a
few days time. Some are long standing and deal with thousands of
pages or files per week.
How should this be better done?
My view has long been that having this stuff external to mediawiki is
good for flexibility, good for development scaling, good for site
performance (bots can't break caching), but bad for reliability (some
bot author vanishes and the process dies). As a result I've
considered it better for us to provide more robust APIs, facilities
for running these tasks (toolserver), and standards for development
and documentation so the tools can outlive the attention spans of
their authors (which is where we suck the most). ... So this is what
I've long thought, but I'm prepared to have my eyes opened.