Wikipedia:Wikipedia Signpost/2012-05-14/Technology report

$wgShowUpdatedMarker causes cross-wiki controversy
At 16:47 on May 10, the  configuration variable was set to true for the English Wikipedia (server admin log). Over the next 48 hours, the wiki's Technical Village Pump doubled in size as users discussed whether or not using bold type for "unread" watchlist changes was a desirable addition to what is often an editor's single most visited page on the site.

Although the configuration variable merely allows for the styling of "unread" changes rather than forcing it, the default bold styling quickly proved unpopular among editors with large watchlists. (There was far less opposition to new users enjoying the styling, by comparison, and indeed many English Wikipedians already use the feature while visiting other Wikimedia wikis where they keep shorter watchlists.) The discomfort was mirrored by several users on the German Wikipedia, which experienced the same configuration change. Other groups of users on both sites posted to show their support for the change nonetheless.

Unlike many previous controversies, the watchlist formatting change was the result of a real local consensus, although questions are now being asked as to whether or not two dozen editors should be considered to have surpassed a requisite quorum for such changes. Other participants in this week's discussions have drawn attention to the divergence between the original community request (closed as in support of the change, despite no consensus on the correct formatting being reached) and the result (bold formatting for all). Consequently, no firm plan had been agreed among English Wikipedians as to how to respond when the configuration change was finally made, causing it to go bold by default, and then flick through alternative styles as editors tried to change the default to something more universally acceptable.

As of time of writing, the English Wikipedia had reverted to include styling for "unread" changes by default, though unlike before users are now able to "opt in" to show the changes in bold, italics or other styling by way of personal preference. As with other recent preference change debacles, it is unclear if there yet exist the technical means to set "what new editors will see" without affecting existing users, an issue at the heart of the current strife.

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.
 * Bugzilla: in need of replacement? Yet another thread detailing the problems with – and suggesting alternatives to – Wikimedia's installation of bug reporting and feature request system Bugzilla was opened this week on the wikitech-l mailing list. The thread, a response to a detailed, overwhelmingly critical post by WMF Community Liaison Oliver Keyes, has not yet managed to get past the overwhelming inertia that has kept Wikimedia and MediaWiki using Bugzilla for the last eight years; despite the fact that few consider Bugzilla ideal software, proposals to replace it, which tend to surface every few months, have historically failed to provide sufficient evidence to outweigh considerations in favour of retaining the existing system (switching costs, concerns about using proprietary software and a "better the devil you know" consideration, for example). In related news, WMF developer Timo Tijhof announced this week the creation of a new portal, aimed at more efficiently directing both staff and volunteer developers to high priority bugs (wikitech-l mailing list).
 * Wikimedia MediaWiki configuration files Gerrit-ified: Future updates to Wikimedia's own MediaWiki configuration files – that is to say, the files which govern the specific setup of each of the Wikimedia Foundation's hundreds of individual wikis – will now be processed via code review tool Gerrit, bringing them into the same code review framework as any changes to the underlying MediaWiki software which the wikis run on top of (wikitech-l mailing list). Previously, community-oriented developers could only suggest alterations to various settings (including namespace names and user rights groups), having to then wait for one of a small number of staff developers to effect those changes at a later date; now, all developers will be able to submit patchsets that can be reviewed and quickly and transparently pushed live by staff.
 * MediaWiki library in possible license violation: MediaWiki developers are facing the possibility of having to write their own CSS "flipping" code from scratch after the licensing requirements of the standard "Janus" library they have relied on for the last 18 months had been found to be (potentially) incompatible with those of MediaWiki as a whole (wikitech-l mailing list). Janus, used for CSS flipping (the automated conversion of styles written by Western developers and optimised for left-to-right writing systems into their right-to-left equivalents), has been included with MediaWiki since August 2009 without legal challenge; consequently, developers such as Director of Platform Engineering Rob Lanphier have said they are confident that a mutually acceptable solution can be found. Such a solution is needed if MediaWiki developers are to avoid having to reimplement from the ground up the functionality currently provided by Janus under version 2 of the Apache License – an open source licence thought to be incompatible with MediaWiki's GPLv2 because of its more stringent "patent termination and indemnification provisions". The discussion mirrors a problem MediaWiki encountered early last year when another library was found upon belated review to include the extra licensing condition that it "be used for Good, not Evil", rendering it also legally incompatible with the GPL.
 * translatewiki.net considering allowing OpenID logins: translatewiki.net, an externally-run MediaWiki-based wiki, is considering accepting logins not just via local registration and/or via Wikimedia SUL, but via OpenID, a mature system of centralised authentication designed to merge a user's many different website registrations into a single account authentication process. The result of the discussion will be of considerable interest to Wikimedians, and not only because translatewiki.net provides translations for the MediaWiki interface: the wiki has something of a trendsetting reputation, often being the first major wiki to try out so-called "bleeding edge" code before it hits Wikimedia wikis. As such, a successful implementation of OpenID on translatewiki.net could well be taken as an important sign that the technology is mature enough for consideration by Wikimedia developers.
 * New Pages Feed tested on English Wikipedia: The prototype for a new New Pages Feed (formerly "New Page Triage"), designed as an alternative to Special:NewPages, has now been deployed on the English Wikipedia; currently semi-private, the feed will be tested for bugs ahead a full deployment some time before Wednesday, Oliver Keyes reported this week. He will be holding an office hours session on May 16 at 21:00 in to show it off, get feedback and plot future developments and he welcomes all those interested to attend, according to his regular newsletter. The successful deployment followed two unsuccessful attempts reported last week. Any questions can be directed to the talkpage for the project.
 * DigiCert take on Wikimedia SSL certificate responsibility: Utah-based DigiCert has been hired "to secure [Wikimedia's] web and mobile properties": or in plainer English, to manage and maintain Wikimedia's portfolio of SSL certificates and to conduct related business. Such certificates form the backbone of secure online transactions (denoted to the user by the protocol  and an accompanying padlock, tick, or other graphic); crucially, DigiCert offered to manage SSL coverage of Wikimedia's many domains and subdomains in a more flexible manner than most other providers, allowing for new wikis to be created and enabled without prompting the appearance of security-related error messages. The exact cost of DigiCert management is unknown and apparently contractually prohibited from being disclosed; Director of Technical Operations CT Woo did however describe the arrangement (which replaces the procurement of SSL certificates on a more ad-hoc basis) as a "good deal".
 * Two bots approved: 2 BRFAs were recently approved for use on the English Wikipedia:
 * Hazard-Bot's 8th BRFA, updating links to userboxes in userspace because of the Userbox Migration;
 * TPBot's 2nd BRFA, adding a "title" to format=inline on the coords template if it does not already exist on the page;
 * At the time of writing, 14 BRFAs are active. As usual, community input is encouraged.