The Jackal Rants

Just a quick heads-up for anyone who cares, but I have no futher intention to continue working on the (uncommitted) Slideshow extension I wrote for MediaWiki back in the summer, nor do I intend to commit the work I was doing on log formatting methods. I don’t see myself committing any further code to the mainline, nor any extensions for the foreseeable future.

In idle browsing of MeatballWiki, which is something I never do often, I came across an interesting statement on http://www.usemod.com/cgi-bin/mb.pl?WikiCreole:

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. 

Just thought I’d take a minute or two to showcase Mayflower, an excellent search engine specifically for the Wikimedia Commons, developed on the toolserver by Tangotango.

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.

Dubious innuendo from Little Britain aside, the results of the Board vote are in, and I’m disappointed, in part.

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.

Well, well, well, Wikimedia have new general counsel, in the form of Mike Godwin. Allow me to extend the warm welcome Mike’s getting, and to throw in the obligatory pun about Wikimedia wanting to invoke Godwin’s law more often from now on.

“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.

Well, just to make it official; I’m no longer a toolserver root, having resigned from those duties as of early this month for various reasons. Don’t come running to me with requests to have users, processes or queries killed, or packages or other things installed or compiled, ’cause it ain’t going to happen.

While a lot of people know what Wikipedia is, or at least, know it exists, a lot less people know that behind the Wikimedia projects (Wikipedia, Wikinews, Wikibooks, etc.) sits the Wikimedia Commons, which aims to become a repository of free media, including all manner of graphical goodies, audio and video. Commons is driving much of the need to develop better media support in MediaWiki, as referenced in a previous post.

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.

Right, well, this’ll be brief, but succinct. I doubt any volunteer working with the Wikimedia Foundation can have failed to notice the recent debacle over the new Board resolution mandating confirmation of identity and imposing a minimum age on volunteers working with “sensitive data”, which is poorly defined as “developers with access to sensitive data”, as well as CheckUsers (which makes sense) and OTRS volunteers, which makes less sense.

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.

I breezed over the “next generation MediaWiki” issues in the last post, but at least one person saw fit to comment on a particular part of it, so I feel obliged to post a bit more about it, with a clarification.

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…