The Signpost

Technology report

Tech talks at Wikimania amid news of a mixed June

Contribute  —  
Share this
By Jarry1250

Tech talks at Wikimania

Panorama shot from the pre-Wikimania Hackathon
A controversial mockup from the Athena project shown off in one Wikimania talk

As Wikimania, the annual conference targeted at Wikimedians and often well attended by those with a technical slant, draws to a close, comments have already begun to come in from attendees regarding the many tech-related features of the conference.

The Foundation will be pleased with the reception of many of their major projects on show during Wikimania, including Page Triage, a more feature-heavy version of Special:NewPages, and the landmark Visual Editor project (see previous Signpost coverage). The latter, attendees were told, should be live on its first wikis by December, confirming the expected six month delay after a design u-turn earlier this year. Developers also confirmed that the tool would continue to support manual mode for the foreseeable future, much to the relief of several hardened editors in the crowd. It is unclear whether the projects will retain support as they near fruition in the months to come.

Perhaps the most thought provoking of the talks, however, proved to be that of WMF Senior Designer Brandon Harris, whose proposed "Wikipedia in 2015" designs raised numerous eyebrows among the Wikimania attendees. The four-pronged suggestions incorporate not only a drastic new skin for Wikipedia pages (Athena, mockup illustrated right) but also possible designs for the Echo notifications project, Agora (a centralised design and icon repository), and Flow, an eventual replacement for user talk pages. All are marked as being of a strictly "future" nature: but their dramatic difference from current systems and designs no doubt took many in the crowd by surprise. Whether the Foundation has the willpower and legitimacy to push through such large scale design changes remains an open question, but they are aware of the issues that may arise: as Harris stated, "Athena is supposed to be a kick in the head. It's a process, not a final design. It's a conversation about what we need to do; not what we are doing." In the interim, some of the suggestions could find their way into the front pages of WikiProjects – or so a well-received talk by WMF Deputy Director Erik Möller suggested.

Slides for some talks are already available, while many more, plus videos of each of the talks, will be made available over the coming weeks.

June engineering report published

In June 2012:
  • 92 unique committers (up 15 from April) contributed 1401 patchsets of code to MediaWiki.
  • The total number of unreviewed commits [reached] 320 (up 70).
  • About 53 shell requests were processed (up 17).
  • 45 developers received developer access to Git and Wikimedia Labs (down 63).
  • Wikimedia Labs now hosts 100 projects (up 3), 182 (up 5) instances and 468 users (up 37).

Engineering metrics, Wikimedia blog

The Wikimedia Foundation's engineering report for June 2012 was published this week on the Wikimedia Techblog and on the MediaWiki wiki, giving an overview of all Foundation-sponsored technical operations in that month (as well as brief coverage of progress on Wikimedia Deutschland's Wikidata project). Of the four headlines in the report, three have already been covered in the Signpost: the Berlin hackathon, described as "the largest gathering of Wikimedia technologists to-date"; the deployment of a second Visual Editor prototype backed by new parser Parsoid; and the launch of IPv6 support during IPv6 World Launch day. Finally, a fourth headline focussed on the commencement of development work on a new Wiki Loves Monuments mobile app, which is to be built by the Foundation's inhouse mobile team.

The monthly report also included news of a "distributed spam attack on [the Wikimedia] mail system involving what appeared to be a few thousand malicious hosts"; having blocked the attack, it "took a day for the mail system to catch up". Elsewhere, on the mobile platform there was a significant release for both the iOS and Android apps (bringing a "dramatic speed improvement" to both apps); testing conducted to allow telecommunications provider Orange to roll out free Wikipedia access to users in six countries and other providers to roll it out in Bangladesh and Montenegro; and "significant progress" on getting Wikipedia available cheaply over the SMS protocol. Just as significant was work on improving sister projects' mobile sites, and then setting up redirection to those mobile sites for users of mobile devices – a project that upgraded Wiktionary, Wikinews, and Wikisource wikis during June and has since been expanded to include Wikiquote, Wikibooks and Wikiversity wikis.

On the negative side, for the umpteenth month in a row, volunteer developers seem to be struggling to get timely code review, contributing to fears that now that unreviewed code does not block deployment, code could be sitting around for months without a review. In addition to publishing a headline figure of approximately 350 unreviewed revisions, the monthly report also contained the first fruits of the Foundation's attempt to generate proper statistics on the composition of the backlog, showing that just 76 were overtly waiting for the original submitter to take action, 49 were overtly awaiting reviewer action and 203 were in a grey area normally indicative of awaiting a reviewer. There was also little progress on the long-running TimedMediaHandler project (now in its 26th month of active development) but nevertheless good news: a final push is expected in late July to prepare the extension, which dramatically improves MediaWiki's support for video display, for a full Wikimedia deployment.

In brief

Signpost poll
Performance
You can now give your opinion on next week's poll: "Excessively long lines have made it harder for me, or someone I know, to read Wikipedia"

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.

At the time of writing, 11 BRFAs are active. As usual, community input is encouraged.
+ 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.
  • "On the negative side, for the umpteenth month in a row, volunteer developers seem to be struggling to get timely code review, contributing to fears that now unreviewed code does not block deployment". I suppose one could say that changing to gerrit shifted getting volunteer code reviewed from a wmf problem to a volunteer problem, since in svn world, the foundation needed to review volunteer code to update the site, now there is less of a "push" so to speak. Bawolff (talk) 13:36, 17 July 2012 (UTC)[reply]
  • "critics are far more likely to point to describe Gerrit as an unfortunate fait accompli: the costs of moving, even from imperfect software, have already been cited as a reason for sticking with Gerrit, almost certainly to the dismay of those who wanted Gerrit's shortcomings to block the Git switchover." -- I don't know if it's just me, but I would prefer less editorializing and more pure reporting on such divisive issues, since perceived existing tendencies can affect the opinion of the undecided. --Waldir talk 15:56, 17 July 2012‎ (UTC)[reply]
    • The understanding I had was that Jarry is reporting on the 'self-admitted afterthought', not editorializing. Ed [talk] [majestic titan] 20:46, 17 July 2012 (UTC)[reply]
    • There were a number of things I wanted to convey here: (a) that Gerrit was an afterthought (b) that it was a concern for some at the time that its being an afterthought (i.e. not having a pre-switchover discussion) would later bias the eventual outcome in favour of Gerrit (c) that their concerns have proved to be corrected but (d) regardless, there are now switching costs, and they are a reason for sticking with Gerrit. I don't see anything wrong with my presentation given that -- but if you could suggest an alternative, maybe that would crystallise the point of contention. In any case, we'll no doubt run a full story on the topic further down the line. Regards, - Jarry1250 [Deliberation needed] 21:41, 17 July 2012 (UTC)[reply]
      • I didn't mean to imply there is anything wrong with the text, and perhaps "editorializing" was the incorrect word to describe what I perceived (I'm not a native English speaker). I think the expression "an unfortunate fait accompli" (which somehow conveys a feeling of collective resignation) was the key element that led me to read that sentence as a little biased towards a view of us staying with Gerrit as a nearly inevitable outcome; furthermore, the whole sentence (and your comment "would later bias the eventual outcome in favour of Gerrit") seems to imply that the developer community is largely tending to the Gerrit side, when I see quite a bit of support for a switch where I've looked (for instance in mw:Git/Gerrit evaluation), in a manner that seems quite balanced towards each side. I do admit that I am not thoroughly involved in developer communications (wikitech-l and IRC seem to be the main discussion venues), so what I see could be an incomplete picture, which led me to feel the text didn't represent the general feeling I've perceived so far regarding this issue. --Waldir talk 09:31, 18 July 2012 (UTC)[reply]
  • As reported last week, 1.20wmf7 hit enwiki at around 18:30, 16 July 2012 (UTC). But there was no simultaneous post at WP:VPT, exacerbating a flurry of confusion/drama over the (unintended?) override of the Watchlist bolding suppression. Also, mw:MediaWiki 1.20 and mw:MediaWiki 1.20/Roadmap are starting to get out of date and there's no mention there yet of 1.20wmf8 (or 1.21). Has the communications plan been overlooked? — Richardguk (talk) 23:16, 17 July 2012 (UTC)[reply]
  • I really don't understand next week's poll question. Why would long lines prevent me from reading Wikipedia? I'm imagining some town in rural Australia with only 1 computer and everyone is lined up waiting to read Wikipedia on it. Fortunately, we don't have this problem in San Francisco :) Kaldari (talk) 06:55, 18 July 2012 (UTC)[reply]
I assumed it was referring to http://ultimategerardm.blogspot.ca/2012/07/can-everybody-read-wikipedia.html Bawolff (talk) 17:30, 18 July 2012 (UTC)[reply]
There's actually research that indicates that excessively long lines are harder to read and strain the eyes.--Jorm (WMF) (talk) 20:35, 18 July 2012 (UTC)[reply]



       

The Signpost · written by many · served by Sinepost V0.9 · 🄯 CC-BY-SA 4.0