Cross-wiki watchlist controversy; and is "go file a bug" really a useful response?

At 16:47 on May 10, the $wgShowUpdatedMarker 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.

Signpost poll

Internal search

You can now give your opinion on next week's poll: Which of the following best describes your thoughts on Wikimedia's bugzilla installation?

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 #wikimedia-office ^connect 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 https: 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:
  1. Hazard-Bot's 8th BRFA, updating links to userboxes in userspace because of the Userbox Migration;
  2. 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.

← Previous "Technology report"

Next "Technology report" →

In this issue

14 May 2012 (all comments)

Special report

News and notes

WikiProject report

Featured content

Arbitration report

Technology report

+ Add a comment

Discuss this story

These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.

• I actually liked the "bold unread watchlist items" idea, for the short time it was around. I looked through preferences, but I couldn't find an option to enable it. I read the village pump discussion, and is there any way to add it back on without adding code directly to a user page of mine? Also, were there other options besides bolding items (like italics, green stars, etc.)? David1217 (talk) 00:37, 15 May 2012 (UTC)[reply]
  • WP:CUSTOMWATCH, the talkpage and an ongoing survive should be mentioned (linked at the talkpage)
  • Oh and by the way: "May 16 at 21:00" - in which time zone? UTC? ^^ mabdul 00:41, 15 May 2012 (UTC)[reply]
    • Good question, and not one I think I know the answer to. I would also assume UTC though. - Jarry1250 ^{[Deliberation needed]} 10:04, 15 May 2012 (UTC)[reply]
  • I am a big fan of the bold unread watchlist feature and continuing to use it - copy my common.css into yours to re-enable it. Dcoetzee 06:44, 15 May 2012 (UTC)[reply]

• When you write something like "users are now able to 'opt in' to show the changes in bold, italics or other styling by way of personal preference", please indicate where in the preferences the setting may be found. --Guy Macon (talk) 07:27, 15 May 2012 (UTC)[reply]

I wasn't using "preference" there in the technical sense, only to mean "choice". So basically, yeah, WP:CUSTOMWATCH. - Jarry1250 ^{[Deliberation needed]} 10:04, 15 May 2012 (UTC)[reply]

• Re AFT5 - this all appears to be old news. It's been deployed on articles since last year. Okeyes (WMF) (talk) 12:48, 15 May 2012 (UTC)[reply]
  • Come to think of it, yes, I probably should have noticed that. Presumably I merely misunderstood what Mathew wrote, so until he can say for sure what angle he was going for, I'll remove the IB, which is posted below for transparency. - Jarry1250 ^{[Deliberation needed]} 13:57, 15 May 2012 (UTC)[reply]

• Version 5 of Article Feedback tool goes live to trial articles: Wikipedia:Article Feedback Tool/Version 5 has now been deployed selectively on certain pages (for example, Eduardo Saverin). This is for experimentation only, and the developers ask that editors not disable the tool from pages on which it is deployed. A special help page has also been recently created. Feedback collected by the latest version of the tool will then undergo analysis; metrics generated (such as signal-to-noise ratio and what aspects of a page users actually comment on, etc.) will then influence future design decisions ahead of a yet-to-be-scheduled broader rollout of the version.

• "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." — Yet another failure of clique decision-making under the blanket of "consensus" made in a political climate where "canvassing" is prohibited. The answer to such periodic failures is the implementation of democracy, which would involve vesting trusted editors to gain voting rights, centralization and publicity of decision-making, and actual counting of actual votes. Since Wikipedia's governance model is highly conservative and an almost textbook definition of inertia, the chances of such changes being made approach zero. But, just so y'all know, that is what needs to be done if such problems are to be fixed. Carrite (talk) 18:56, 15 May 2012 (UTC)[reply]

• No licensing problem with CSS Janus - MediaWiki is "GPLv2 or later," allowing licensees to comply with either GPL v2 or v3. So someone who wants to distribute the code (like Fedora) can comply by conforming to the terms of the Apache-compatible GPL v3. This means we don't have to explicitly move to GPLv3 only. Alternately, anyone who wants to comply only with GPL v2 can retain the option of excising the ASL code. We may explore the possibility of explicitly moving to the GPLv3 (or later) as a means of creating a little less confusing situation, but there's no license violation in our current use. See T38747 -- RobLa-WMF (talk) 21:22, 16 May 2012 (UTC)[reply]
  • Well yes, but the fact that MediaWiki is GPLv2+ (rather than simply GPLv2) is not widely advertised, and indeed the current MediaWiki download page describes how "MediaWiki is free software licensed under version 2 of the GNU General Public License" / the content of COPYING is the GPLv2. Clearly, if code within MediaWiki is not compatible with version 2, that needs to be widely advertised or reusers are naturally going to wander into the licensing trap here, which't isn't altogether fair on them. - Jarry1250 ^{[Deliberation needed]} 02:00, 17 May 2012 (UTC)[reply]
    • If people have to remove CSSJanus to in order to distribute MediaWiki as GPL v2, perhaps we could provide instructions on how to do so without breaking anything? I might try this myself and write something on MediaWiki.org. Reach Out to the Truth 14:06, 17 May 2012 (UTC)[reply]