Wikipedia:Wikipedia Signpost/2012-04-30/Technology report
Git: the state of play
Recently "Technology reports" have abounded with different stories arising from the Git switchover on March 21; it can be easy to miss the wood for the trees when negotiating one of the largest changes to their workflows developers have experienced in years. To assist in establishing the current "state of play" when it comes to the switchover, the Signpost caught up with Chad Horohoe, the WMF developer responsible for managing the switchover.
Chad, are you happy with how things have gone so far? Would you have done anything differently, and if so what?
- So far, I think the migration has gone well. There's still a learning curve that people are trying to get past. As far as what I'd do differently if I had to do this whole process again, I would have been much more aggressive in recruiting guinea pigs to help me test our new system. The biggest complaint I have seen from users so far have been related to learning Gerrit and overcoming the Git learning curve I mentioned. Getting people involved in testing the process at an earlier point would've made this easier. Also, given some of the reservations with Gerrit, I think having people involved earlier would've helped us discover these issues sooner.
The move to Git has probably sounded rather abstract to many Wikimedians. What can they expect in the way of tangible differences?
- The most important part of this process has been changing our commit workflow to a "pre-commit review" model. The MediaWiki codebase and its extensions have to be runnable at all times—we shouldn't break things when we can avoid it. So by changing our review model, we are trying to accomplish two big things:
- We're trying to lower the bar to contribution. Since the review process now keeps the codebase clean of things that aren't quite ready for production, we're trying to encourage a lot more casual contributors who maybe didn't have the level of skill that we'd look for when granting commit access (the ability to modify core MediaWiki code). As of this week, everyone's code is reviewed beforehand, so we're trying to level the playing field for everyone who wants to write code (whether it's a one-line fix or a huge new feature).
- By keeping the code more stable, we're trying to reduce the time it takes to release MediaWiki to our primary users—WMF wikis. Our targeted goal is currently deploying the latest reviewed code every 2 weeks. This encourages contributors who like seeing their work live on the sites, as well as gets fixes and new features in the users' hands much faster.
Technology Reports since "Git day" have included coverage of some of the issues that have arisen since the switchover. How confident are you that once developers get used to the new way of working, those concerns will be resolved?
- I think there's two types of issues that have arisen from the changes. The first are "Git issues". These are all problems stemming from the fact that we're trying to teach people how to use a radically different tool from the past. Git has a learning curve, but I think we're starting to get more people over that hump and used to some of the day-to-day work. The second set of issues people are having are "Gerrit issues". Gerrit is not a perfect tool and there are some rough edges to work out. While I will be looking at the work Daniel Friesen and others put into alternative code review tools, I must say that I disagree with the assertion that Gerrit is fundamentally flawed. I've found the Gerrit development community to be active and responsive so I believe some of the more pressing bugs we've uncovered will be fixed for us. Overall, I think that these concerns will resolve over time as people get used to the new system and some of the more glaring issues are fixed.
Is it possible to avoid controversy when changing a design?
In 1957, C. Northcote Parkinson bemoaned the fact that getting agreement on the design for a new bikeshed is uniformly more difficult than getting agreement on the design of a nuclear reactor; though fewer people are affected, the entire community (in Parkinson's case a committee) are willing and able to give their opinion on the matter. MediaWiki tries to avoid this problem by allowing logged-in users to choose how they wish the proverbial bikeshed to appear to them, but it is often not enough: participants still argue over how interface elements should appear to the overwhelming majority of users who are not logged in.
Such was the situation this week as the English Wikipedia's Technical Village Pump became a forum for discussing the changes to MediaWiki's default diff colouration and formatting schema, brought in last week with the local deployment of 1.20wmf1. Predictably (see previous Signpost coverage), the result was much consternation and fierce debate (as of time of writing, it seems as though the new global default will remain the default on the English Wikipedia, albeit with possible tweaks).
Design controversy is nothing new to Wikimedia wikis, however. In May 2010, for example, an update to the famous Wikipedia "puzzle globe" logo caused pages of on- and off-wiki debate. Indeed, it was an episode that bore all the hallmarks of the present diff colour discussion: the change was primarily aimed at fixing an objective problem (incorrect characters) but also incorporated purely aesthetic changes, and hence sparked disagreement. In the end, the logo was adjusted slightly to respond to the criticism of it by Wikipedians, but the update was not reverted. It was around the same time that the Vector skin was rolled out – first optionally and then as the default for all users – prompting a similar number of complaints. These complaints included those of one user, still an active Wikimedia Commons editor, who wrote that "the kind of morons with no place whatsoever in Wikipedia ... I expect donations to plummet in reply to this change".
Not all central changes have stuck, either: the furore over a change to the colouring using in the new messages bar prompted it to be widely reverted. Of course, the correct analysis of this historical record is itself a controversial issue; commentators seem split between those who feel that controversy is a part of the design process that can't be eliminated and those who feel that it can be, but that developers and designers have never tried hard enough to eliminate it. One thing is certain, though: with design changes of some sort or another occurring on an increasingly rapid basis, it's rarely been a more topical issue.
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.
- Loss of session data still an issue: The tentative close of bug #35900 ("Odd session bugs") reported in last week's "Technology report" unfortunately had to be reversed this week after editors on the English Wikipedia continued to have problems remaining logged in. Although a recurring issue, the causes of this bout of session data loss have baffled developers, causing the bug to be escalated to WMF Lead Platform Architect Tim Starling in the hope of resolution. Pertinently, this week's poll results (shown right) suggest that approximately one-third of users would favour significantly greater WMF emphasis on performance versus feature development.
- Three MediaWiki releases: The first release candidate for MediaWiki 1.19 was announced on April 26, two months after the MediaWiki version was deployed to Wikimedia wikis (the intervening months being taken up with the Git switchover and moving to a new release cycle). It was accompanied at the same time by so-called "point releases" for both MediaWiki 1.17 (1.17.4) and MediaWiki 1.18 (1.18.3); these were targeted at fixing a small number of significant bugs in their applicable version. The releases prompted bugmeister Mark Hershberger (about to start his final month at the WMF) to investigate the upgrade state of external wikis. He found that only 15% of non-WMF wikis were updating regularly, with 4% not having updated since MediaWiki 1.10 (for a similar study conducted in August 2010 with not entirely dissimilar results, see previous Signpost coverage).
- Watchlist email notifications enabled on all wikis: With the resolution of bug #28026 (performance impact notwithstanding), users on all wikis are now able to receive email updates when an item on their watchlist is changed. Discussion on the wikitech-l mailing list focussed on what form default notifications should take, if the feature is to be enabled by default at all. Elsewhere, there was extended discussion about Wikimedia's readiness for the introduction of widespread IPv6 use among internet surfers (a subject which also gets its own page on meta); an RFC has also been opened on the subject.
- Wikipedia Zero: There was a significant uptick in attention this week for Wikipedia Zero, a WMF-led initiative aimed at negotiating free 2G Wikipedia access in regions where other forms of internet access are severely limited. The scheme, which is achieved through a combination of negotiation with network providers and WMF technical support in order to ensure it is not abused, will (for example) be launching with mobile provider Digi Malaysia shortly. Blogger Gerard Meijssen pointed out that the same technology could be used to provide free access to specialised wikis, including those used to share free agricultural knowledge.
- New Engineering Community Group established: The creation of a new Engineering Community Group has been announced on the wikitech-l mailing list. The group, which will be led by former Volunteer Development Coordinator Sumana Harihareswara, will take on the responsibilities of the "Technical Liaison; Developer Relations" group, which is being disbanded. Its responsibilities will include "facilitating collaboration and communication between the Wikimedia Foundation, its employees and the larger Wikimedia developer community, and facilitating collaboration and communication between the Wikimedia developer community and other Wikimedia communities". The news was met positively by the Wikimedia community. Harihareswara's specific remit will continue to include many of her previous responsibilities, including overseeing this year's Google Summer of Code projects (details of which, contrary to last week's story, will in fact be covered in detail in next week's issue).
Highly preliminary sketch for the feedback page - NewPageTriage to go live: The development of Special:PageTriage, a dashboard-style special page aimed at providing a more useful alternative to Special:NewPages, will take a step forward on Wednesday when an early prototype – little more than a redesign of the old page in many respects – is deployed by private URL this week to test its compatibility with the production environment. However New Page Triage (WP:NPT) missed its April date for the first level demonstration of its new interface. Okeyes (WMF), community liaison, said there were very minor delays due to last minute attempts to accommodate community requests and do further testing to identify "any and all rare bugs". Okeyes (WMF) has scheduled and booked May 2 for the deployment date.
- Article Feedback Tool/Version 5. Wikipedia:Article Feedback Tool/Version 5 has scheduled May 2 to deploy the test alternative versions of Option 1 feedback form. Feedback continues at Article Feedback Tool/Version 5. Interested users can also test a version of the tool hosted on Wikimedia Labs. It should be noted that the tool is eventually intended to have a variety of important features not yet present on the prototype. Elsewhere, there will be an Office Hours session at 18:00 UTC on May 4 in #wikimedia-office connect to discuss progress on the development of version 5 of the Article Feedback tool. WMF community liaison Oliver Keyes suggested that the office hours would be used as an opportunity to "show off the almost-finished feedback page and prep it for a more public release".
- One bot approved: 1 BRfA was recently approved for use on the English Wikipedia:
- MadmanBot's 13th BRfA, generating Wikipedia:Inactive administrators reports; delivering messages and e-mails to inactive administrators as appropriate.
- At the time of this writing, 11 BRfAs are active. As always, community input is encouraged.
Discuss this story