On 6/21/06, Ian Woollard ian.woollard@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