Several wiki engines have agreed to jump on board (including MediaWiki and the Ward’s original WikiWikiWeb).

This is news to me, I have to admit; from what I can recall, in a mailing list thread sparked off with an announcement that WikiCreole was ready, I’m pretty sure several developers expressed doubt as to whether or not it was worthwhile implementing.

WikiCreole is dumbed-down and doesn’t support quite a lot of what MediaWiki’s native parser does. The WikiCreole people have so far failed to see the light in defining the parser behaviour, which is one of the biggest mistakes made in the history of MediaWiki development.

It’d be interesting to know whether or not I’m on crack, and if it has been agreed that we’ll implement this, why we felt it was appropriate, and who’s doing it.

Update: Following some comments from Brion, it seems that someone got the wrong impression after he expressed some initial support and made a tentative offer to experiment with an “alternative editing mode” supporting WikiCreole. On the whole, it’s not something we have a roadmap to support. 

I don’t think I can praise this enough, to be honest. The interface is clean and professional, the engine itself is quite fast, and effective, and the whole experience left me quite satisfied as a user. This is a fantastic piece of work, and I wholeheartedly congratulate the developer for putting in some obvious hard work.

This is exactly what the toolserver was for, and I’m thoroughly pleased that our community is producing such innovations.

The top three, in order, were Erik Möller (Eloquence, 1671 votes), Kat Walsh (Mindspillage, 1427 votes) and Frieda Brioschi (Frieda, 1254 votes). Oscar van Dillen (Oscar, 1234 votes) came fourth, losing his seat. The Board of Trustees has endorsed the result, and offered the position to Frieda.

There were a lot of prospective voters demanding some explanation from Erik as to how he felt he kept his promises from the previous election campaign, although on the whole, I didn’t expect him to lose a seat in this election. I was quite confident of Kat’s continued position on the Board, but the final result is something of a disappointment.

I’m not concerned that Oscar lost his seat, although I do sympathise with him for a brief moment; no doubt Wikimedia will begin treating him as “old hat” – rather, I’m disappointed that the final opportunity has been wasted. I have no doubt that Frieda is a wonderful person and will do her best, but I’m not at all convinced she brings sufficient qualifications to the table at a fairly crucial time, and would much rather have seen Michael Snow or Danny Wool in her position.

It’s interesting to look at those who fell towards the shallow end of the voting pool; perhaps Kelly Martin was right in her estimation of some of them as “popularity contest entrants”, and River Tarnell’s platform of closing non-Wikipedias apparently did her no favours with those projects.

“You’re trying to stir up trouble with practically every single e-mail you send.”

This little gem was on the English Wikipedia mailing list. The hypocrisy of some of their users is simultaneously hilarious and atrocious.

The administrators on the Commons work damn hard to ensure that the content uploaded is free, and for the most part, do a good job. The main problem that seems to be developing right now is the deletion of images on Commons, and the reason that’s a problem is because when Commons sneezes, Wikimedia gets a cold, or less metaphorically, if Commons deletes an image, that image stops being available to all the Wikimedia projects, and a bunch of pages including that image breaks.

Of course, some of this deletion is needed, but there’s also a lot of carelessness going on. While I appreciate that we do need some sort of tracking mechanism to keep tabs on pages using those images, I think it’s important to note that applications such as InstantCommons, which is under development, and aims to allow third parties to use the Commons repository, depend on that project not deleting a ton of images.

One example that sparked this little rant is http://upload.wikimedia.org/wikipedia/commons/7/7d/Bug.png – it’s a little cartoon bug, and we use it on the MediaWiki BugZilla. We’ve been asked to change this, although we haven’t been given a good reason. I rather suspect that, sooner or later, the image is going to be deleted, although as of writing, it isn’t tagged for deletion. All this does is break a bunch of links to the image and causes some inconvenience.

Now, if InstantCommons starts being used (and I gather an alpha or beta of some sort is not far off), then it’s going to be useless if stuff gets deleted. If wiki operators notice that images can’t be relied upon to be in one place, then they’ll just stop using the Commons.

The Commons, as a project, needs to wake up and realise that it’s responsible for providing images to more than just Wikimedia now, and as far as I can tell, this was always the case. If they start breaking stuff, then we might as well abandon the idea altogether.

Daniel Kinzler put together a +1 insightful post for his blog, which summarises a lot of the major concerns I’ve seen over this proposal, including the lack of research beforehand, the lack of thinking regarding an effective implementation and the lack of communication to the people it affects.

For some months, there have been discussions on the wikitech-l and mediawiki-l mailing lists regarding the next version of MediaWiki after 1.9. Brion Vibber, our lead developer and release manager, has stated that this would be 1.10, due for release this month or early next, and this sparked off a whole discussion about “MediaWiki 2.0″.

The problem (I feel, and it seems, so do some others) with labels such as “MediaWiki 2.0″ is that it encourages people to start planning for a big rewrite with a whole raft of new features, and we had some mailing list posts discussing this. Now, I’m not going to defend the entire code base and state that parts of it don’t suck, and I’m not going to get into a language war, either, but I don’t feel (and again, others actually working on the software agree) that a full-blown rewrite from scratch is at all the approach we need to take; our existing model of continuous development and integration works for us, and it works well.

There’s been a lot of time and effort invested by many people in developing techniques and experience for all aspects of running the Wikimedia cluster, including actual application development, optimisation (including SQL optimisation, etc. and a lot of trial and error) and the entire server operations side of things. A major rewrite of MediaWiki would discard much of this hard work, and would discard something that a lot of people have worked on since 2003.

Therefore, I was skeptical, as were a lot of developers, over the claims of some people that we needed to rewrite MediaWiki for version 2.0. This seems to have been the general consensus at a recent conference in Vancouver, and while I didn’t attend it, I’d like to think some of the comments I made on the general issue prior to that did something to help convince people. (Satisfied, Erik?)

So, as I mentioned before, the outcome of that was that the mediawiki-ng-l mailing list was set up. It’s on moderated subscriptions at the moment, but as explained in the introduction post, membership is not a difficult hurdle, although I am concerned that it seems to be adopting a secretive attitude.
With a bit of luck, we have a think tank established that will begin churning out useful ideas soon. With even more luck, that think tank will remain open to all of us…