Wikipedia:Wikipedia Signpost/2012-03-12/Technology report
Git learning curve steep but not insurmountable, plus a diff style we can all agree on?
Developers bracing themselves for steep learning curve after Git move
| “ | There are alternative solutions, but none of them are viable without development work. Gerrit is viable right now, in its current state. Its downside is that its interface is slightly painful.
Every tool we use is going to have something we dislike about it interface-wise. |
” |
—Operations Engineer Ryan Lane describing new code review tool Gerrit | ||
Discussion of the move to Git took on a more serious tone this week, focusing on ways in which the (particularly volunteer) developer community might be unprepared for the sheer scale of the change that lies ahead (wikitech-l mailing list). The long and detailed thread provided developers with a useful opportunity to ask detailed questions about the system coming into operation later in the month.
The difficulty, it seems, is that there is no easy option for developers: even casual contributors will have to get used to a completely different development workflow (incorporating a new process for committing and a new process for reviewing and commenting on other developers' code), not to mention a whole new vocabulary. Unpicking that steep learning curve and presenting it in "bitesize chunks" has proved tricky for the WMF team overseeing the move, given the amount of interdependence between a developer's command-line Git instance and the Wikimedia-side Gerrit review system with its much-critiqued user interface. On the plus side, numerous websites exist to help users unfamiliar with Git pick up not just the basics but also the more tricky syntax that developers will need to master if they are to contribute fully to MediaWiki after the March 28 transition.
Ultimately, few seem worried that developers will not be able to master the new system in good time, although, in the words of Diederik van Liere (currently a consultant at the WMF), "a new workflow requires new habits and that might take more time to develop". Among those effects with the potential to linger, the front-runner seems to be the (not yet fully understood) implications of the move on the historically pertinent volunteer-staff divide. Only time, it seems, will tell.
February Engineering Report published
The Wikimedia Foundation's engineering report for February 2012 was published this week on the Wikimedia Techblog and on the MediaWiki wiki, giving an overview of all Foundation-sponsored technical operations in that month. Ultimately, it was a month dominated by a handful of big projects, each of which have already been covered in the Signpost: the problematic Swift deployment, preparations for the move to Git, the 1.19 deployments (see release notes) and, to a lesser extent, progress with the Wikimedia Android app, which is now providing the foundation for a new Wikimedia iPhone app. As ever, however, the report provided details of many smaller projects that had received less of a spotlight.
One such project is the creation of a Wiktionary app by a team of Canadian students under the guidance of WMF staff developers. According to the report, the team is currently focusing on "targeting bugs, cleaning things up and improving usability in the v0.1 Alpha release". In similar news, there was also an update on efforts to make the MobileFrontend extension (which powers m.enbaike.710302.xyz and family) less WMF-centric, following a sharp critique of its shortcomings in January, as well as news that good progress is being made on a project to provide Wikipedia content via SMS/USSD, a major boost for mobile-only visitors on 2G connections (such as those found in parts of the developing world).
Elsewhere, the report noted the steps being taken to improve the number and depth of full site backups; two WMF locations now host copies of all Wikimedia dumps and two external mirrors are currently in the final stages of preparation. Finally, there was confirmation that a short period of slowness experienced on February 27 was in fact the result of a distributed denial-of-service (DDoS) attack of unknown origin and motivation. The attack, which lasted only ten minutes, was brought to an end by the quick work of system administrators.
In brief
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.
- WMF confirms GoDaddy departure: WMF legal counsel Michelle Paulson blogged on behalf of the Foundation this week to confirm the transfer of Wikimedia's many domain names from previous registrar GoDaddy to competitor MarkMonitor. Although the move is of little technical importance, Paulson said she was hopeful "the company will help the Foundation consolidate and centralize management of all of its domains, will provide services needed to manage a global domain portfolio and will better protect our domains with additional security features", with the latter-most thought to refer to mostly trademark infringement and phishing attempts.
- Wikimedians, meet Wikidata: Wikimedia Deutschland's new community communications manager for its Wikidata project, KDE board member Lydia Pintscher, has announced an introductory communications road map for the project, with which regular readers of the "Technology report" will be relatively familiar. The project's current focus is on collecting input, creating resources "to explain the project better", setting up infrastructure, and working on a structured input collection system; the heavy development work is expected to begin next month. (Those excited by the potential of the project will be interested to know that the Signpost will be running a special report in April in order to address the topic in more detail.)
- ProofreadPage in need of TLC: Localisation team member and prolific blogger Gerard Meijssen used a post on his personal blog to highlight the plight of ProofreadPage, an OCR-based extension that provides the backbone of the Wikisource projects. Like many extensions, it has suffered from the semi-retirement of one of its key maintainers, prompting others to make ad hoc edits to keep it functioning. The good news, Meijssen reported, was that (unlike many other such extensions) a new lead maintainer for ProofreadPage had now emerged from the developer community.
- Better mathematics rendering coming soon to a wiki near you: WMF lead software architect Brion Vibber wrote this week about his efforts to implement MathJax, a JavaScript-based system for rendering mathematical notation (JavaScript-only example) that boasts a considerable number of advantages over the existing server-side system, including better zooming of text and better inline display. In his post, Vibber said that he was hopeful that the feature-rich, actively maintained framework would make it into the user preferences selection list "soon", before becoming the default at a later point in time.
- Approvals at Bots/Requests for Approvals. Six BRfAs were recently approved:
- BG19bot's 2nd BRfA, for the automatic removal of {{WikiProject Sports}} from biography talk pages
- BattyBot's 8th BRfA, to change {{Unreferenced}} to {{BLP unsourced}} on articles in Category:Living people
- EnzaiBot, operation of another interwiki.py interwiki bot
- Thehelpfulbot's 11th BrFA, to send newsletters or other talk page messages to the User talk: and Talk: when requested to by users or WikiProjects
- TPBot, picking up several tasks previously performed by User:X!'s bots (running the exact same code; one of the reasons bot authors are encouraged to publish their source code). It will update the RfX Report, update the RfX Tally, update CratStats for each bureaucrat, and update Adminstats for each admin.
- ListManBot, which will maintain MediaWiki:Bad image list
- 15 BRfAs are open at the time of writing. Community input is encouraged.
- Landing page project introduced: WMF community liaison for product development Oliver Keyes used a post on the Foundation-l mailing list this week to announce an early-stages project to improve the experience of new users bewildered by the page that resulted from clicking on a red link. While the neatness of the prototype landing page could not be denied, there was earlier skepticism about the scope of the problem, at least on established wikis where article creation tends to be a premeditated rather than impulse action.
- Differing diff colours remain on agenda: The process to formulate new diff colours for MediaWiki continued this week; the latest version (pictured below) replaces the current system of paragraph-level background colouring (plus sentence-level text colouring) with a heavy border in either blue (for lines added) or yellow (lines removed) at the paragraph level, and soft background colouring at the sentence level. The move is intended to make diffs more accessible, particularly to those with red-green colour blindness.
Discuss this story