The Jackal Rants

Yesterday, I was pleased to have the opportunity to discuss a company’s internal use of MediaWiki in some depth. Although no longer actively involved, I do still take an interest in how people proceed with developing things – once they wipe the introductory text off the main page, where a wiki goes is completely up to them. It’s becoming pretty clear that a lot of companies see the benefits of using a wiki for internal documentation/communications – the ease of contribution and the freedom to structure as you please are, I think, two major factors in play here.

It seems to me that this particular organisation is generally very pleased with what MediaWiki offers them, and with the concept in general. Interestingly, they’ve managed to get pretty much 100% buy-in from all employees, which some companies would probably think of as a holy grail – getting people to work with the wiki is often a major problem in setting one up.

Better people than I have written extensively on the subject of enterprise wiki deployment. Nevertheless, I figured I’d share this. There’s also something pretty weird about seeing, first hand, a commercial enterprise using a piece of software you’ve contributed to.

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.

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.

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…

We’ve got a lot of big features planned or being implemented which will add to the MediaWiki user experience, although some of them seem to have stalled, which is a shame.

Flagged Revisions

Also known as stable versions, this is being worked on under a contractor, with some volunteer aid, and is coming on quite well, from what I can gather. With a bit of luck, it can undergo the review process and perhaps be tested on a Wikipedia soon; I imagine the Germans are going to want the first pilot.

Single User Login

Not a lot mentioned on this front in a while; last I heard, Brion had completed some initial tests and estimated the number of conflicts, etc. that might occur when migrating user accounts across to the central authentication database. I’ve had a few users asking me about things like cross-wiki blocking, and cross-wiki permissions, and while these aren’t in the plans for square one, central authentication will make them easier, as well as opening up other possibilities.

LiquidThreads

Some sterling work from Dave McCabe during last year’s Summer of Code, which unfortunately appears to have been suspended, although he has been hired by Wikia, and there was talk of it being picked up again, which would be great. If that’s not the case, then I would suggest it would be well worth Wikimedia thinking about contracting someone to finish off development, as improve discussion features in MediaWiki would be damn useful.

Update: I’ve heard that there are talks in place between Wikia staff to have this work continued, and with luck, Dave’ll be the one finishing it.

Media Improvements

Tim Starling has done a huge chunk of work on the new image backend, in the form of a nice piece of storage middleware which handles requests to view, thumbnail, publish and remove media, etc. There’s also a lot of discussion over changes to the various media namespaces in preparation for a big overhaul to MediaWiki’s media handling, which, coupled with the work being done by this year’s Summer of Code student, ought to mean we have some nifty inline players and so forth within a year’s time.

Search Improvements

I’ve spotted some interesting-looking activities in the repository which look suspiciously like somebody’s about to make a whole bunch of improvements to MediaWiki’s Lucene Search extension and the backend daemon. Apache Lucene is a Java-based search engine, and we use it on the live sites, but searches could still do with some improvement, so perhaps we’re about to see some drastic new changes in that direction.

Next Generation

(Section removed in favour of later post)

Wikimania

Who knows what will be requested at Wikimania, where the development team can’t escape the hordes of users demanding autographs and bug fixes in equal measure? Who knows what next big thing might emerge from a five minute catch-up session?