MediaWiki 1.18 deployment begins, the alleged "injustice" of WMF engineering policy, and Wikimedians warned of imminent fix to magic word
MediaWiki 1.18 deployment begins
On September 16, WMF director of platform engineering Rob Lanphier announced the deployment schedule of the latest version of MediaWiki, version 1.18, approximately seven months after the deployment of version 1.17. Due to the completion of the heterogeneous deployment project, software engineers at the Foundation have the chance for the first time to deploy to some Wikimedia wikis before others; developers reason that a staged deployment, when combined with a smaller release, will avoid many of the difficulties experienced in previous deployments when millions of visitors experienced small defects that only came to light at deployment time. With this in mind, Lanphier outlined the schedule as:
| “ |
|
” |
As of time of writing, only four revisions (out of many hundreds) still need to be reviewed before deployment can commence. Lanphier encouraged users to test the wikis immediately after deployment and report any issues through the #wikimedia-tech connect IRC channel. Theoretically, MediaWiki 1.18 introduces several major new features, including support for gender-specific user pages, better directionality support for RTL languages, and protocol-relative URLs. Although Wikimedia wikis already benefit from a selection of the most major new features (priority changes are rapidly merged into production code), a myriad of smaller changes not yet debuted will indeed go live in the forthcoming rolling program of deployments. A full list of these is also available.
After the deployments, there will be a lag before the software is marked as stable enough for external sites to use and MediaWiki 1.18 is officially released. For version 1.17, the lag was four months, but the absence of under-the-hood changes in 1.18 means that an official release is scheduled for "shortly after" the internal deployment is complete on October 4.
Wikimedia "injustice" over lack of support for smaller projects
To say that only the English Wikipedia exclusively receives technical support is a misunderstanding. Instead, I would characterise the WMF's prioritisation as an "A rising tide lifts all boats" policy. Even if a first deployment is to Wikipedia, they will generally benefit other projects as well.
Projects like Wikinews and Wiktionary almost certainly require more specialized product development and devotion in addition to the general development work that benefits all projects. However, it's my own view that this kind of specialized development is best served by ensuring that we give the global community great spaces to innovate and create new things. Recently we've been working on improved support for gadgets, and we're also working to create Wikimedia Labs, which we hope will make it possible to test and develop software under conditions that are very close to the WMF production environment. This means that, provided you're willing to invest sufficient resources, you should be able to get a project much closer to "WMF readiness" than you are today with far less WMF help.
The WMF's role for specialised improvements is chiefly in reviewing and deploying the code that volunteers have taken the time to write. Where we don't do so in a timely and reasonable fashion, we must strive to do better.Following the news on Monday that members of the English Wikinews community are to break away, a spotlight was cast on the Foundation's policy towards its smaller projects, particularly when it came to technical support. "They couldn't get essential components deployed for 2 years or so," opined Kim Bruning, whilst Jon explained the problems in the technical assistance the Wikinews project received in more detail. His words seem to conflict with those of OpenGlobe founder Tempodivalse, who did not cite conflict with the Foundation as among his motivations for starting the project:
| “ | I can't speak for the entire Wikinews community, but a lot of it was the lack of technical assistance. Wikinews really need[ed the GoogleNewsSitemap extension] to be even remotely useful and it was very difficult to get any help at all. Eventually the community wrote the extension themselves but couldn't get the dev's to review it appropriately. This was drawn out over several years [until] the Foundation really started to turn around and give much better support starting about 1 year ago. ... There is also a host of other backend and support style related issues ... Simply put, the Wikinews concept needs a much more specific set of assistance than the general "Here's a wiki, have fun". | ” |
WereSpielChequers, meanwhile, suggested an overhaul of the mechanism for deciding which projects should receive paid developer attention:
| “ | I think it would be great if we could ringfence some IT budget for bottom up initiatives ... What I'd like to see is a prioritisation page on Meta comparing the priority of multiple potential developments, - much like the way Wikimania chooses presentations. That way projects and editors could make a pitch for IT investments that their communities actually had consensus for - currently even the English Wikipedia can get consensus for change but not get IT resourced for it to happen. | ” |
Among the most damning public criticism of current Foundation policy was that from MZMcBride:
| “ | From Wikimedia's perspective, I think this is "one down, several hundred to go." Wikimedia has made it clear that its singular focus is the English Wikipedia. All other Wikipedias are peripheral; all other project types are abandoned. Perhaps with the exception of Wikimedia Commons, which is able to pull in grant money, so it continues to receive some level of technical support. ... It's a great injustice to countless contributors that they receive support in name only ... I sincerely hope whoever administers your new site will treat you better than Wikimedia has. | ” |
In brief
Not all updates may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for many weeks.
With all page requests from those browsing Wikipedia on their handheld devices now being routed via the new MobileFrontend extension, administrators are being asked to update the HTML of the main pages of their home wikis to embed extra metadata. The metadata is then used to build up an improved mobile homepage.
{{REVISIONUSER}}to be "fixed": A commonly used magic word's functionality will change significantly as developers plan to fix a bug. The{{REVISIONUSER}}tag currently returns the username of the user who last edited the page, except when someone is editing that page, when it instead displays that editor's name. Developers plan to fix this soon (bug #19006), fundamentally changing the nature of the magic word. As a result, edit notices and templates used to preload or customise content that rely on the magic word will become non-functional; there are currently no firm plans to create another magic word with the existing functionality.
The logo of the DBpedia project, a machine-readable version of Wikipedia that was updated this week - DBpedia 3.7 released: DBpedia, the RDF-based Semantic Web/Linked Data version of Wikipedia, was updated to version 3.7 this week. It now uses the July 2011 Wikipedia dumps and has 3.64 million entries with data derived from 97 language versions of Wikipedia (the previous edition used data from late 2010). The latest release now contains information derived from articles that exist only in non-English editions of Wikipedia as part of a long-term project to make DBpedia better reflect the multilingual nature of Wikipedia. In total, the database, which aims to provide a machine-understandable version of Wikipedia, now contains approximately a billion "triples" (essentially individual statements of fact derived from articles, of the form "Elvis Presley was born on January 8, 1935"); as many as two-thirds of these came from non-English Wikipedias.
- Wikimania presentations now online: As reported by WMF Deputy Director Erik Möller on the wikitech-l mailing list, the videos of a number of technical-related Wikimania presentations have been uploaded to YouTube by Wikimania Israel. These include a presentation by Roan Kattouw and Timo Tijhof about the ResourceLoader that shipped with MediaWiki 1.17 ([1]) and Markus Glaser's presentation about testing ([2]). A full list of videos is also available.
- I18N bug triage: This week's bug triage focussed on internationalisation-related bugs, and was attended by 9 developers online. Of those, two were new to MediaWiki, impressing bugmeister Mark Hershberger (wikitech-l mailing list).
- Special:PrefixIndex made more usable: with the resolution of bug #18424, the visual look of the Special:PrefixIndex page will be tweaked to allow the navigation text to be more easily read and the pages to be more easily navigated between.
- History of MediaWiki explored: There was a discussion on the wikitech-l mailing list about a recent call to developers to recount their memories of the early days of the MediaWiki software and the design decisions taken since. Some were enthusiastic about the project, which has been commissioned by a book writer, whilst others found it a waste of time.
- English Wikipedia Bots: this week, a bot was approved on the English Wikipedia for removing flag icons from infoboxes, whilst a bot task relating to the handling of requested move tags on pages in userspace is still open for discussion.
- Pageview statistics released in "dump" form: After the issue of page view statistics was examined, and it was found that http://stats.grok.se was one of only a very small number of sites actually processing the raw page logs into numerical form, the Foundation have released the full processed dataset to the public (wikitech-l mailing list). The figures stretch back to December 2007, although the statistics for a large period at the end of 2009 were found to be unreliable due to server overload (see previous Signpost coverage).
Discuss this story