Wikipedia:Wikipedia Signpost/2012-09-03/Technology report

Creation of a MediaWiki Foundation proposed
Developers are currently discussing the possibility of a MediaWiki Foundation to oversee those aspects of MediaWiki development that relate to non-Wikimedia wikis. The proposal was generated after a discussion on the wikitech-l mailing list about generalising Wikimedia's CentralAuth system.

Proponents are clear that they do not intend any new creation to compete directly with the Wikimedia Foundation, which has historically considered MediaWiki development within its remit. Indeed, the initial proposal has shied away from even critiquing the WMF's software priorities, focussing instead on filling in the gaps by providing funding to projects that were of benefit to the wider MediaWiki ecosystem but not necessary to Wikimedia wikis. How a "MWF" would generate its own funding is unknown; the problem has historically dogged proposals to overhaul MediaWiki governance.

More realistically in the short term, the new body (if it materialised) could take over responsibility for generating so-called "tarballs" – snapshots of MediaWiki software for external wikis. As the desire for a MediaWiki 1.20 release grows, this aspect of the WMF remit has come under increasing scrutiny, especially because the complete detachment of Wikimedia deployments (now fortnightly) from external releases (six-monthly) means that the WMF has no clear incentive to ensure tarballs are released on time.

One possible complicating factor with this proposal would be the presence of security releases – code changes that are then "backported" to previous versions in a process increasingly reliant on the WMF's security expertise. Indeed, this week saw just such a release, with six fixes being backported to MediaWikis 1.17, 1.18 and 1.19 (wikitech-l mailing list).

Google Summer of Code: Incubator improvements
Continuing our series looking at this year's Google Summer of Code students, this week the Signpost caught up with Belgian student of public administration Robin Pepermans, who spent his summer working on an element of the Wikimedia universe few large-wiki editors ever encounter: the Wikimedia Incubator. The Incubator provides a space for new language versions of Wikimedia projects to prove their sustainability before a wiki is created for them. Pepermans explained to the Signpost what he had been doing: Incubator-infopage-wn-sk.png I have been working for quite some time to make it as easy as possible for anyone to start a new language version of Wikipedia or another Wikimedia project on the Wikimedia Incubator. For this broad project, I had in particular created a MediaWiki extension which improves the usability of the Incubator and makes maintenance of the wiki easier. Being also active as a volunteer MediaWiki developer in general, I had considered working on another topic for MediaWiki in Google Summer of Code 2012, but I chose to focus on the Incubator extension and language support in MediaWiki.

On the Incubator, all existing or possible language versions have an automatic "info page"; see for example the Slovak Wikinews page, which invites anyone to start on Incubator this particular language edition which does not exist yet. I had already coded this function before GSoC, but improved it during the project. One of the new features that integrates with these info pages is a special page called IncubatorFirstSteps which guides new interested contributors through creating an account and getting started working on a test project. A core aspect of my GSoC project was to include all ISO 639 language names, which would display the correct language name "Bagri" on Wp/bgq instead of not recognizing the language code (at present a more restrictive list of language names is used); this has however not been deployed yet as opposed to my other work.

During the project, I have also continued working on improving MediaWiki's "page content language" feature, which does not only benefit Incubator, but MediaWiki in general by allowing pages to be marked as being in a certain language and making MediaWiki language features behave differently depending on that language. The most visible outcome of this is the writing direction, e.g. Pashto pages on Incubator are right-to-left without any extra HTML in the page content; during the GSoC period specifically I converted and dates in sortable tables to the page content language.

Robin, who has stated his intention to continue his development work outside of the programme, runs a blog documenting his progress. He added that if you speak a language that lacks one or more Wikimedia projects, you are encouraged to start or contribute to the wiki and that anyone is welcome to contact him or the Incubator community for ideas, problems or suggestions.

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 several weeks.
 * MediaWiki 1.20wmf11 begins deployment cycle: 1.20wmf11 – the eleventh release to Wikimedia wikis from the 1.20 branch – was deployed to its first wikis on September 3 and will be deployed to all wikis by September 12. The release incorporates about 250 changes to the MediaWiki software that powers Wikipedia, comprising 118 "core" changes plus a similar number of patches for WMF-deployed extensions. Among the changes (the product of some 14 days of development time) are fixes for bugs #39431 ("That an SVG is animated is shown to user in ugly fashion", #39284 ("Improve the tablesorter for currency") and #39297 ("Show a warning if thumbnails won't be animated").
 * Gerrit to receive professional improvements: Current MediaWiki code review system Gerrit, barely out of the news in recent weeks, will receive WMF-funded development in the form of a specialised contractor, it was announced this week (wikitech-l mailing list). Development will initially be focussed on GitHub-compatibility and comes after the conclusion of a long debate over the selection of Gerrit as MediaWiki's official code review tool. In related news, WMF Git guru Chad Horohoe started a discussion addressing developers bypassing review even on the "master" branch of certain extensions, while a series of new Gerrit tables were also published, marking a return of the "wall of shame", listing developers by the number of changesets they have contributed code later shown to be bad but without a later patch (also wikitech-l).
 * Double-counting causes overestimate of "active editors": There are approximately 4.4% fewer Wikimedians than previously thought, according to a statistical update detailed on the Wikimedia blog. The difference surrounds the need to avoid counting users editing on multiple projects more than once, which was previously done by excluding Wikimedia Commons from the aggregation. This method has been replaced by a new aggregation that includes Commons but counts each username only once: by no means a perfect measure (despite improvements proposed in February this year, global account convergence is still patchy), but almost certainly an improvement. The result was approximately a drop of 4.4% in the headline number of active Wikimedians, although the impact on the "fall from peak" figure was less significant.
 * Protection for @wikimedia.org spoofing: An obviously fraudulent email apparently sent from a @wikimedia.org address prompted concern on the wikitech-l mailing list on Thursday. Despite the content of the message being of a spam rather than a phishing variety, Wikimedians were concerned that more dedicated spammers could exploit the same vulnerability. It was revealed in the discussion that the WMF does not take advantage of the Sender Policy Framework, a system that allows domain name owners to block others from spoofing their email addresses by tying the domain to a specific IP address. When asked why such a system had not yet been implemented, WMF Operations Engineer Jeff Green cited the difficulties inherent in getting the outgoing mail of the many different @wikimedia.org email address users routed through the same IP address, though he suggested that process might now begin in earnest.
 * Google and WMF tips for good development: Two of this week's developer mailing list threads centred on good working practices. One, based on advice from a Google "Insider", resulted in the advice that "participating in code review, even as a peripheral commenter rather than a key reviewer, gives a participant much greater understanding", among other things, while the other, started by WMF Engineering Community manager Sumana Harihareswara, focussed on 5 tips to get your code reviewed faster. The tips included "write smaller commits" and "Add reviewers", as well as "Respond to test failures and feedback", "Don't mix rebases with changes" and "Review more".
 * Translatewiki.net in developer plea: After at least 84 open bugs were found to have a substantive internationalisation component, administrators of translatewiki.net (which facilitate the translation of MediaWiki's interface messages) appealed to developers for help, both fixing those bugs and preventing the need for new ones (wikitech-l mailing list). All developers were advised to consult what is currently considered best practice and to check back regularly.
 * English Wikipedia considers Memento deployment: The English Wikipedia is considering the deployment of the externally developed Memento extension, which exposes the content of an article's history page in a specific machine-readable format, ready for use by the Memento project. The project, funded by the U.S. Library of Congress, aims to better and more completely expose the history of pages across the web. As of time of writing, the proposal looked to have gathered enough support, subject to approval by WMF Engineering, who will need to ensure that the extension scales and will not pose maintenance issues further down the line.