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).
Wikipedia:Wikipedia Signpost/Templates/What is 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.
.png)
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.
Discuss this story