An example screenshot from the Drafts extension as it looked when it was last featured in the Signpost back in January 2009
There was renewed interest among developers this week in the provision of automatic "Save as draft" functionality during editing, allowing users to either deliberately set aside part-finished changes to an article when interrupted, or to recover work lost if their workstation unexpectedly terminates their session (wikitech-l mailing list).
The feature was first discussed over three years ago, when a Drafts extension that provided the required functionality even made it as far as being enabled on a test wiki (see previous Signpost coverage from January 2009). Despite this, as regular editors will be aware, the feature never made it onto Wikimedia wikis and the extension languished until it was revived this week by developer Petr Bena. As of time of writing, the extension is deployed on a (different) test wiki, awaiting fixes both to bring elements of its design up to modern standards and to make it compatible with recent versions of the MediaWiki software that underpins Wikimedia wikis (not least visual changes to make it compatible with new default skin Vector, which had not yet been written back in January 2009).
Initial investigations show that the extension, which has been deployed on several external wikis, could well be salvageable, making it possible that it could theoretically be deployed on Wikimedia wikis soon if it were picked up by Foundation developers. Any work done on it, however, could yet be overtaken by the deployment of the new Visual Editor to its first WMF wiki (currently scheduled, very approximately, for later this year).
The issues surrounding the volunteer–staff divide – and the probable impact upon it of the change in review paradigm that accompanied the Git switchover – were crystallised this week in a post by WMF Director of Platform Engineering Rob Lanphier on the wikitech-l mailing list. The subject of the email was 20% time, a WMF protocol that makes provision for one day a week when staff developers will work on tasks more closely associated with the wider volunteer developer community than their usual development workflow.
Given the recent questions about code review times, Lanphier used the email to describe the protocol (which he was personally responsible for managing until recently) more fully. Before the Git migration, he wrote, code review was the primary task allotted to staff developers to fill the 20% of time set aside from their main development projects. This was done because "the consequences of falling behind there were more severe than letting other things slide". The point of the post, however, was to stress the new, more diverse set of topics that would be covered during this "20% time" now that the Git switchover had reduced the impact of code review backlogs – the primary aim being that no volunteer developer felt that their preferred area of development is neglected.
The new list of possible tasks during 20% time, which is most commonly taken by staff developers on Fridays, includes "merging reviewed code into the release or deployment branch and deploying it", code review, and "Updating public wiki pages, documenting/sharing data, and otherwise contributing to making WMF engineering work transparent". In addition to the obvious benefits to the success of volunteer development work, the policy is also intended to help staff developers maintain a sense of the "bigger picture" and hence to increase the bus factor of large sections of MediaWiki code.
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for many weeks.
First MediaWiki 1.20 deployment begins: As previewed in last week's "Technology report", the first deployments of MediaWiki 1.20 to Wikimedia wikis commenced this week, affecting MediaWiki.org and a test wiki (at time of publication, the deployment to Wikimedia Commons is underway, with the English Wikipedia scheduled to receive the update on 23 April). The most significant feature of MediaWiki 1.20wmf1 is its new set of diff colours; 1.20wmf2 will follow in approximately a fortnight, 1.20wmf3 approximately a fortnight after that, and so on until in a number of months MediaWiki 1.20 is officially released to external sites (Wikimedia blog, full roadmap).
Google grants WMF nine slots: Further to previous Signpost coverage, it was confirmed this week on the wikitech-l mailing list that Google will fund nine placements in its 2012 Summer of Code programme for students wishing to work under the auspices of the Wikimedia Foundation. The number Google are making provision for this year – with sums of up to $5000 set aside for each – represents a slight increase on last year's eight student total. It is now up to WMF and MediaWiki developers to select up to nine students to take part in this year's summer placements scheme; as reported last week, some 41 serious applications were made for those places, making it the numerically toughest year on record.
Two hires for WMF Engineering: Two new members of staff were announced this week by the Wikimedia Foundation's Engineering department. Greek contractor Faidon Liambotis joins the operations department to work on "enhancing and deploying more services on the new Wikimedia Labs platform" (wikitech-l mailing list), while Belgian developer Matthias Mullie joins as a features engineer. His initial remit will include "New Page Triage, the Article Creation Wizard, and the Article Feedback Tool" (also wikitech-l). The Foundation have traditionally had difficulty in hiring enough 'good people' fast enough to meet its rapidly-increasing workload, although there is evidence that (even without compromising the quality of new hiring) the problem has eased slightly in more recent months.
DippyBird improvements: Mobile Software Engineer Arthur Richards announced this week a series of improvements to his Gerrit "bulk change" script DippyBird (wikitech-l mailing list). For those with sufficient permissions, the script (written in PHP and – somewhat ironically – not yet migrated to Git) allows the users to comment on, approve, or decline multiple patchsets submitted to new code review tool Gerrit using a single command; a work in progress, the script is designed to make reviewers' lives easier, particularly when attempting bulk administrative changes.