English Wikipedians discuss editor–developer divide
A minor change—tweaks to the default heading used at the top of diff pages—provoked a long debate on the English Wikipedia when it went live this week. The discussion focussed on an issue that has bubbled to the surface intermittently for the past few years: as the MediaWiki developer base professionalises, are developers becoming less responsive to English Wikipedian demands?
Most developers would agree that editors of the English Wikipedia are given less priority than they used to be. There are overtly more projects than there used to be and more languages to support on each of them. Staff development projects are far more likely to target "newbie" editors than existing stalwart editors (a decision that seems to have significant support given this week's poll results, below); design choices are increasingly being made in the name of helping the former, potentially at the expense of upsetting the latter. Needless to say, decisions that fit such a paradigm (including the recent diff colours switchover) have not proved universally popular.
The horrific technological inertia that is developing within the community is only going to lead to two possible outcomes ... Either the developers abandon any hope of satisfying the community and stop bothering to even try to engage with it, or they stop trying to develop beneficial features at all.
Ultimately, a number of viewpoints emerged from the resulting discussion. They centre on two questions: firstly, whether developers are targetting the "wrong" things, and secondly whether they should be expected to communicate the changes they have made better. Both have proved to be contentious issues. Equazcion, in proposing the former, talked of developers implementing their "own whims regarding what is best for the community"; but such a critique relies on a certain view of the community as being a superior judge of what is best for itself and its future members, rather than as an insider group keen to resist any kind of novelty. Moreover, volunteer developers, much like Wikimedians who work in an idiosyncratically narrow area, are likely to resist any attempt to tell them what new features they can and cannot work on, especially since virtually all will have been proposed by some community or other at some point.
The issue on which a consensus is more likely to form revolves around the need for better communication between developers (who frequent the wikitech-l mailing list, MediaWiki.org, and Bugzilla, which, in unrelated news, was down for considerable periods this week) and editors who frequent their home wikis. When pushed for comment on the thread, WMF developer Ryan Kaldari was the first to admit that despite the amount of time WMF developers were putting in to communicating with communities, more could still be done. "Right now", he wrote "there are so many different venues for discussion it's rather unmanagable [and] we have a very hard time getting people to beta test things for us. ... It seems no matter where we advertise it, we generally only get significant community feedback after the features are deployed".
The issue is not restricted to the English Wikipedia, although it is certainly the place that the issue is invoked most frequently. By contrast, members of smaller wikis are more likely to complain not that too many changes are being forced on them, but that rather too few are made—that their many feature requests are simply never acted on because they are neither WMF strategic priorities nor aligned with the personal interests of volunteer developers. The difficulty for WMF development coordinators undoubtedly lies in addressing all of these multifarious complaints simultaneously and without trade-off.
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.
MediaWiki 1.20wmf4 begins deployment: The fourth Wikimedia deployment from the MediaWiki 1.20 branch began today, with an additional two weeks' worth of bugfixes and other incremental improvements going live to MediaWiki.org and two test wikis. Among the 230 changes included in the deployment, two are of the small, visible change type that has caused so much controversy in the past couple of weeks: the first excludes immovable namespaces from Special:MovePage's namespace selector; the second broadens Special:Shortpages to include pages from all content (non-talk) namespaces, rather than just article space. All non-Wikipedia sites will be next to receive the changes on or around May 30; the English Wikipedia will receive them on June 4 and other Wikipedias on June 6, major problems notwithstanding.
UploadWizard updated: A series of updates went live to Wikimedia Commons' Upload Wizard this week, including "disabling multiple-file selection in browsers where it didn't work", tweaking the configuration such that the "'skip tutorial' step ... won't come back every time you switch computers any more", and ensuring that "files now start uploading immediately when selected" (wikitech-l mailing list). The changes, which include background support for so-called "upload campaigns" such as Wiki Loves Monuments, have largely been welcomed by the Commons community. It was noted that very large uploads (those greater than the previous limit of 100 MB) continue to fail on a regular basis, a major disappointment for those seeking to take advantage of the new, much greater upload limit of 500 MB.
Character support interview: Localisation team member Gerard Meijssen has used a post on his personal blog to publish an interview with Unicode specialist Michael Everson. In it, Meijssen and Everson discuss the possibilities with regard to improved web-font support (particularly the eradication of the ☐☐☐☐☐☐ ☐☐☐☐☐-phenomenon) for Wikimedia wikis. Everson noted, however, that it could be necessary to establish, either unilaterally or multilaterally, a body concerned with the creation of freely licensed web-friendly typefaces. "Right now", Everson wrote, "anyone viewing any Wikipedia in any language may encounter text in Ol Chiki, or in Runic, or in the simple International Phonetic Alphabet, and pages have to apologize to the reader because their computer may not display the material correctly".
Wikipedia Zero launches in Malaysia: Malaysia has become the first Asian country, and the third country in the world, to have a national mobile provider offer Wikipedia free of charge. According to a post on the Wikimedia blog, "Digi’s 10 million customers can read as many Wikipedia articles as they like (provided they have an internet-capable phone), in any language, through the Opera Mini browser data; WebKitFormBoufree access applies to the lightweight, text-only mobile version of Wikipedia, which Digi customers can now access by going to zero.wikipedia.org". Support for Tunisia and Uganda was brought in earlier this year; further networks will be added later in the year, should negotiations go well; at the very least, Digi is part of the already signed-up Telenor group, suggesting that Telenor's other 115 million customers will soon be enjoying the same service.
Wikimedia wikis to take part in World IPv6 Day: The foundation will attempt to take part in this year's World IPv6 Day, it was revealed this week. Deputy Director Erik Möller, answering a question from the community about the event (scheduled for June 6), outlined how the WMF was "planning to do some limited production testing at the Berlin Hackathon (June 1–3) and on IPv6 Day, but we'll only keep it enabled if the issues are manageable". Last year the foundation was forced to back out at the last minute due to problems with the database schemas of several extensions (see previous Signpost coverage). These have now been updated in readiness for the day, which last year was supported by a long list of major websites including Facebook and Google. Realistically, it has been pointed out that any proper addition of IPv6 support to Wikimedia wikis would require large scale "reeducation" of admins and the rewriting of a considerable number of user scripts, though such a move is regarded as inevitable in the longer term.
Joe's Null Bot, once-daily application of WP:NULLEDITs special purges with the "forcelinkupdate" option set to each of the articles within Category:BLP articles proposed for deletion by days left.
At the time of writing, 17 BRFAs are active. As usual, community input is encouraged.