Jump to content

Wikipedia:Wikipedia Signpost/2012-10-22/Technology report

From Wikipedia, the free encyclopedia
Technology report

Wikivoyage migration: technical strategy announced

Möller sets out Wikivoyage migration plan

One potential logo for Wikivoyage, selected solely because it has already been uploaded to Wikimedia Commons; many others are available for your comment

Planning for Wikivoyage's migration into the WMF fold built up steam this week following a statement by WMF Deputy Director Erik Möller about what the technical side of the migration will involve. Wikivoyage, which split from sister site Wikitravel in 2006 (see previous Signpost coverage), is hoping to migrate its own not-inconsiderable user base to Wikimedia, as well as much of its content, presenting novel challenges for Wikimedia developers

Firstly, there is the physical creation of a new "wikifamily" populated with at least six language-specific wikis (one each in German, Italian, English, French, Dutch and Swedish) to consider. As long as a new logo is in place to complement the recently chosen name (Wikivoyage), that part of the migration is unlikely to cause many difficulties per se. Once the wikis are established, developers will use a process tested on a Wikimedia Labs instance to import content from Wikivoyage whilst ensuring that all legal requirements are met.

User migration is likely to be far more difficult, and yet, given the need to preserve legal attribution, just as necessary. By default, imported content retains its history, replete with links to the user pages of the editors mentioned therein. If not adjusted properly, this could lead to the contributions of two different users being merged, or the contributions of the same user being split.

Also likely to be tricky is getting Wikivoyage's full array of extensions (of which a dozen are tagged as high priority) reviewed for performance, functionality and security, and then deploying them to Wikimedia's newest wikis, a process which may go on for weeks after content and users have migrated, Möller suggested. Only then will original Wikitravel users find out if the WMF can provide them with a superior level of technical support to the for-profit they left behind earlier this year.

Interested users can track Wikivoyage-import-related bugs via a special tracking bug. The aforementioned migration of content and users is planned for the coming fortnight.

In brief

Signpost poll
Non-WMF-deployed extensions
Staff shouldn't use company time to work on extensions that aren't in use on WMF-run wikis (22%) / Staff should be able to use 20% time to work on non-WMF-deployed extensions (54%) / All extensions are indirectly useful to Wikimedia's mission and should be supported (16%) / Other (8%)
You can now give your opinion on next week's poll: The Wikivoyage migration: the priority is that...?

Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for several weeks.

  • Your edit was saved: A new post-edit notification went live on Thursday October 18, ensuring that users know their edit has been saved. The small box, which is both dismissable and permanently hideable using user CSS is based on an idea originally trialled with new users and found to increase the chance of repeat edits. It was developed by the Foundation's Editor Engagement Experiments (E3) team.
  • action=info: With MediaWiki 1.21wmf2 being deployed on an increasing number of wikis, attention has been drawn to a new "Page information" item in the toolbox (wikitech-ambassadors mailing list). The feature, developed by several volunteer developers working in collaboration, is an attempt to bring back a page that had been briefly enabled some time ago (but then almost immediately disabled). It gives basic metadata about a page, selecting what it shows based on relevance and the viewer's permissions level (only administrators, for example, can use it to see how many watchers a page has). It is intended to replace a series of ad-hoc tools (many of them based on the Toolserver) which provide similar functionality less efficiently; suggestions for new data points are welcomed on Bugzilla.
  • Expanded +2 access: The Foundation is deliberately giving more developers the ability to approve and merge core MediaWiki code, WMF Deputy Director Erik Möller clarified this week (wikitech-l mailing list). The beneficiaries of the change are full-time engineering staff (all of whom can now merge core code) and an increasing number of volunteers. With great power comes great responsibility, however, and the new reviewers are expected to only merge code in their own area of expertise (for example, JavaScript work). Developers found merging large chunks of their own unreviewed code should also expect to have the right taken away from them, Möller said.
  • Google Code-In: Following the Wikimedia Foundation's successful participation in Google Summer of Code (GSoC) this year, WMF Engineering Community Manager Sumana Harihareswara raised the possibility of the WMF also participating in sister project Google Code-In (wikitech-l). The latter, which focusses on 13- to 17-year-olds (compared to GSoC's 18–25 age bracket) assigns participants smaller tasks, the completion of which is checked by experienced developers (mentors). The cost-benefit analysis of participation is complicated by the fact that its existing processes do not age discriminate, suggesting that applicants may be better off as general contributors rather than working within a more rigid framework.