.png)
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.
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. | ” |
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.
Discuss this story