The Jackal Rants

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?

There’s a hell of a lot of bureaucratic babbling going on on foundation-l at the moment with regards to the flaming hoops contributors are having to jump through to have a project started in their language.

I can’t begin to detail what these are, because I haven’t got time to read all the stupid little pages and criteria and so forth, but from what I can gather, it’s not a process which has been improved by the creation of the Languages Committee.

Of course, I have my own opinion on it; and my opinion is that it should be really trivial to have an existing project set up in your language. As an example, let’s track the progress of some users wishing to set up the “XYZ Wikipedia”, where XYZ is a placeholder for language.

A few speakers of XYZ get together on the Wikimedia Incubator and start creating a few content pages. These aren’t perfect, but show a willingness to contribute to the project.

The users request the creation of the new language on a page on Meta. Assuming they demonstrate sufficient interest so as to have the project edited on a regular enough basis that it doesn’t die out, and that vandalism doesn’t become a major problem, the request is accepted.

There are a few pages which are essential to new Wikimedia wikis. As a bare minimum, I would suggest the group needs to prepare a translation of the Wikimedia copyright policies, and some page describing the five pillars of Wikimedia projects. The group is also free to continue creating articles on the Incubator.

Once the essential pages have been translated, a bug is opened and the system administrators are asked to create the new wiki. A list of pages to be imported is provided. This will typically not take very long.

One of the original requesters is elected as the first administrator and bureaucrat; this is important for the project to be able to establish its own infrastructure without having to call on stewards for assistance.

That’s it.

Some users are advocating the position that new language versions of project should not be accepted until we have an internationalisation file for that language in MediaWiki; this is a position I reject, as I really don’t see why it’s a big deal. The project can translate the user interface via the MediaWiki namespace, and we can slurp the translations from there into a new messages file.

I should point out here that the “call to arms” for translators I made on foundation-l was asking for people to help maintain translations independently, and there was certainly no intention to imply that I endorsed the above position. Getting new projects going as quickly as possible is essential if we’re to avoid losing eager contributors.

Just to summarise, then, the procedure I would endorse is:

1. Create some initial content to show interest and good faith
2. Translate two or three “essential policies”
3. Ask for the actual creation of the wiki
4. Elect initial administrator/bureaucrat

Well, it’s that time of year again; in a few hours, Slashdot will be pink, Uncyclopedia will be out of a job for 24 hours, and countless English Wikipedia users and administrators will be systematically introducing nonsense, destroying (even temporarily) the user interface and existing content, and the whole project will be a mess.

Now, anyone knows that I like my share of nonsense, but the kind of stuff I witnessed last year was going too far…this stupid little culture of “let’s trash the ‘pedia for a few hours” needs to stop.

April 1st is also the date we switched to using Subversion as our version control solution for MediaWiki, and I don’t think we’ve looked back. Having a decent, modern SCM to support a relatively tough challenge really makes things a lot easier, and Subversion is arguably easier to use in areas which really count, meaning that newer developers are branching, developing complex features, and having them merged in faster, which is great.

One thing I’d love to see in Subversion is something akin to “shelving“, which some solutions have – shelving is the ability to quickly save and revert your uncommitted changes in the current working copy until you opt to have them brought back. This is great for quickly abandoning a slightly more involved change in order to make a smaller one. While it’s possible to do emulate this in Subversion using multiple checkouts or a patch creation/revert/patch application model, it’s a bit more cumbersome than being able to select a “Shelve…” option, give a name, and then go back to that at leisure.