The Signpost

Technological roadmap

2011's technological achievements in review, and what 2012 may hold

Contribute  —  
Share this
By Jarry1250

Jarry1250 is the regular writer of The Signpost's weekly "Technology report", which covers technological developments as they happen. Here, he gives his roundup of the past year as a whole, and what might happen in the year ahead. The usual "Technology report", focussing on the events of the past 7 days, is available separately.


With 2012 now in full swing, it becomes possible to review the year gone in terms of its technological developments, particularly when compared with the predictions The Signpost made in January 2011. Of course, it is also possible to look ahead and make fresh predictions about 2012 and what it might have in store.

2011 in review

The new mobile site, released in September 2011 (as viewed on a phone running Google Android)

After the Vector rollout, and with the Usability Initiative coming up for renewal, further usability improvements to the main (desktop) interface of MediaWiki seemed to be in the pipeline. Although improvements to the editing interface never made it into the 2011 programme of deployments, the ease with which files could be uploaded to Wikimedia Commons took a major step forward in May 2011 with the rollout of a new UploadWizard. Arriving in late June, Extension:WikiLove was more controversial but is now in use on an increasing number of wikis. The Moodbar extension, deployed in July, was also a notable development in the field of new user integration; perhaps as a result of it and projects like it, the overall downward trend in the number of active editors on projects such as the English Wikipedia seemingly slowed during 2011. Taken as a whole, Wikimedia wikis received 2.2 page views for every human on the planet during 2011.

The mobile site took a greater than expected role, with the deployment of a new mobile site in September, allowing developers familiar with the main site to start transferring over functionality. Elsewhere, the creation of a "Localisation team" at the WMF helped to contribute to an internationalisation boom that included the deployment of the WebFonts and Narayam extensions to help the display and input of non-Latin characters, and the deployment and release of MediaWiki 1.18 (the second of two MediaWiki releases in 2011), which helped resolve directionality-related display issues on right-to-left wikis. Other headline issues fixed by MediaWikis 1.17 and 1.18 included the ease of installing MediaWiki, the rollout of a new "Resource Loader", improvements to category sorting, gender-specific page headings, and protocol-relative URLs.

Existing extensions also saw considerable development time; for example, the ArticleFeedback extension is now in its fifth version and has a full plan of action prepared for 2012. On the other hand, the LiquidThreads extension, which had been experiencing a lack of developer attention in late 2010, did not resurface in 2011, although a large amount of work was done behind the scenes to make it more deployable. The staff–volunteer divide that was highlighted last year continued to be a source of tension in during 2011, and long times for code review (which had been blamed for exacerbating matters) remained firmly on the agenda (surfacing separately in March, July, and even as recently as three weeks ago).

In sum, the "core" MediaWiki codebase received 7344 revisions in the 12-month period to December 2011, up 30 per cent year-on-year. Similarly, the official SVN repository, which includes both core code and a large number of extensions, was updated some 30 thousand times in 2011, compared with fewer than 20 thousand similar revisions in 2010. Although the figures alone do not capture the value of the programming work done during 2011, they do suggest that more developer hours were devoted to improving the software behind Wikimedia wikis in 2011 than in 2010, a finding supported by the leap in the number of bugs fixed during the year, up from from 2183 in 2010 to 3584 last year. In this area, hopes are high for Wikimedia Labs and the move to Git, to allow new developers to more easily integrate into the community.

Plans for 2012

Mockup of what a "New Page Triage" system, of the sort scheduled for development in 2012, might look like in practice

With the aid of the current MediaWiki roadmap (as of time of writing) it is possible to sketch out details of the year ahead, although the dates will inevitably change.

As reported in this week's "Technology report", the cutoff for features development (and other major work) for inclusion in MediaWiki 1.19 has now passed. About 350 revisions are scheduled for review before the end of January, when a release branch will be "cut" from the main development version. A deployment to Wikimedia wikis is expected in February. Although this will be from the MediaWiki Subversion repository, it is likely to be the last of its kind, with 1.20 pencilled in as a release from competitor system Git. The move to Git will naturally need to be accompanied by discussion over how code review processes will work under it, which could prove to be a contentious issue if the new policy is seen to formalise existing differences in the way developer and volunteer code tends to be treated.

January is expected to be a busy month for Wikimedia mobile development, with the imminent market release of a general-use Android app, the testing of Wikipedia Zero on the Orange Tunisia mobile network (and "maybe others"), and potentially the deployment of a "mobile web upload" facility (a full "mobile upload" is planned for later in the year). Mobile-friendly editing is scheduled to follow in March, while work will continue throughout the year to allow thousands of users in Asia and Africa without full web access to browse via SMS and USSD.

Other things to look out for in 2012 include a "new page triage" special page (to replace Special:NewPages), the launch of the much-hyped Visual Editor (tentatively slated for April; see previous Signpost coverage for context), and the deployment of a series of video playback enhancements currently bundled as the TimedMediaHandler extension. Once again, a resurgence in the LiquidThreads projects is on the cards, although given its long, complex and difficult development history, exactly how and when this might happen is very difficult to pin down. Indeed, there is still time for the whole LT project to rise and fall in 2012, and hence still time for communities to shape how the software behind a top-ten website develops over the course of the next 12 months.

+ Add a comment

Discuss this story

These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.

From the article:

"Although these are not necessarily indicative of more programming work, they do suggest that more developer hours were devoted to improving the software behind Wikimedia wikis this year than in 2010..."

Let me rephrase that for you:

"Although these are not necessarily indicative of more programming work, they are indicative of more programming work."

Smyth\talk 12:27, 10 January 2012 (UTC)[reply]

Actually, what I meant was closer to:
"Although these are not necessarily indicative of more programming work, they are suggestive of it."
There was also originally a sense from the first clause that the figures cannot be used to make a value judgement with regard to 2011 vs 2010, but that didn't make the final cut. I shall adjust that now. - Jarry1250 [Deliberation needed] 12:41, 10 January 2012 (UTC)[reply]

  • The staff–volunteer divide that was highlighted last year continued to be a source of tension in during 2011 [clarification needed] Orange Mike | Talk 15:24, 10 January 2012 (UTC)[reply]
    • To clarify by example, I recall that the differences between staff-written code and user-written code was treated were raised several times in different contexts (mostly from the perspective of disgruntled volunteers); there were also questions over the whether staff had the authority to take decisions unilaterally and, if so, in what areas; and I'm sure a whole host of other things I can't quite put my finger on at the moment. - Jarry1250 [Deliberation needed] 16:03, 10 January 2012 (UTC)[reply]
  • "The Moodbar extension, deployed in July, was also a notable development in the field of new user integration; perhaps as a result of it and projects like it, the overall downward trend in the number of active editors on projects such as the English Wikipedia seemingly slowed during 2011." Giggle. Does anyone actually believe this? Ntsimp (talk) 15:47, 10 January 2012 (UTC)[reply]
    • Projects like it seems more likely than specifically the MoodBar, but, even so, it doesn't take much to suggest that every little helps in these matters. - Jarry1250 [Deliberation needed] 16:03, 10 January 2012 (UTC)[reply]
      • We have a mood bar - seriously? And that is supposed to help ... How? When psychology undergrads can't even register an account, perhaps we are looking through the wrong end of the telescope. Rich Farmbrough, 21:03, 11 January 2012 (UTC).[reply]
        • Oh the Dashboard... why is it called a mood bar? Rich Farmbrough, 21:07, 11 January 2012 (UTC).[reply]
          • The MoodBar is a producer of data for the Feedback Dashboard. The Dashboard is envisioned as being a larger and more comprehensive tool for interaction with new users. The MoodBar feedback is just the first producer of content for it. For example, there are thoughts to have feedback about the mobile beta site flow into the Feedback Dashboard, too. In the future, we could have general "help me" requests go there as well. "MoodBar" is not a user-facing term, by the way, but it accurately describes how the feature works.--Jorm (WMF) (talk) 21:15, 11 January 2012 (UTC)[reply]



       

The Signpost · written by many · served by Sinepost V0.9 · 🄯 CC-BY-SA 4.0