On 8/27/07, Brion Vibber brion@wikimedia.org wrote:
I'm not sure that putting all of that into MediaWiki makes sense.
It does.
A lot of it works best asynchronously.
Yep!
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 workflows today.
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 way.
So how should this work?
There have been a number of workflow enabling extensions built by people in the past. For example http://www.mediawiki.org/wiki/Extension:Tasks_Extension, but I'm not aware of any of them being used on the Wikimedia Wikis.
So... 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.