The Jackal Rants

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.

Well, it looks like I won’t be participating in Google Summer of Code 2007, which is a bit of a shame, but there it is.

I haven’t had the time this week to decide upon a project, and although Google have extended the deadline for applications to the 26th, I won’t have time now to take the ideas put forward so far and prepare a decent proposal for consideration.

Furthermore, I’m somewhat disinclined to participate in heavy development at the moment owing to the machinations of the development team – there’s quite a lot of hassle coming from certain new committers, and the recent attitude coming off some sponsored developers makes me not want to join their ranks.