Wikipedia:Wikipedia Signpost/2010-10-18/Technology report

Universal Subtitles editor comes to Commons


For some time, visitors to Wikimedia Commons have been able to access "timed text" (a system of time references and accompanying text, better known by its applications as subtitles and closed captions) via the mwEmbed gadget. The subtitling effort has been hampered, however, by the lack of a useful editor for the timed text. "Universal Subtitles", a Mozilla Drumbeat project, aims to fill the void for all websites, but Wikimedia had not been able to integrate it. That changed this week, when developer Michael Dale announced that (Wikimedia Techblog):

Today, I am happy to share our first pass at integrating our open subtitle efforts. Please keep in mind this integration is still very early on in development, but the basic milestone of being able to use the tool on commons to create and sync up subtitle tracks is an important first step. Even without helpful tools in place, the Wikimedia community has been creating subtitles and translations. We hope this new subtitle edit tool will broaden the number of participants and enable the Wikimedia community to set a new standard for high quality multilingual accessibility in online video content.

An example is available, and it is also possible to leave feedback.

Staff, paid developers and volunteers: discussions continue
This week saw a revitalised drive towards reaching an understanding between WMF staff decision-makers, WMF paid developers, and the volunteer development community. For a long time the creation of the MediaWiki software, which Wikimedia, Wikia and a number of other sites rely on, had a development cycle that operated like a wiki, for better or worse. It included a large number of volunteer developers and only a handful of paid employees (for example, Brion Vibber); their contributions were checked and deployed in sequential order. With its budget expanding in recent years, the Foundation has been able to hire more developers, who are now involved in a large number of projects some would perceive as being nearly impossible for a volunteer to complete in their spare time. Likewise, the review system has been updated to allow important fixes to be deployed out-of-cycle without first reviewing other more minor edits. Staff and developers, both paid and volunteer, are now concerned that a tension is growing between the various parts of the jigsaw, an "us vs. them dynamic" (Erik Möller, Deputy Director), similar to the conflict that had flared up earlier this year between the User Experience team and volunteer developers over a seemingly minor issue (the display of interwiki links, see Signpost coverage), where Möller had likewise observed "a widening gap between staff and volunteer contributions". Paid developer Roan Kattouw put his thoughts down (Wikitech-l mailing list): Since the discussion about staff collaboration with volunteers started a few weeks ago, actions and statements by staff members have undergone an increasing amount of scrutiny and criticism. That in itself is not a bad thing... in recent weeks, however, posts on this mailing list [i.e. from volunteers] have gone way beyond 'some' scrutiny and criticism, instead suggesting something closer to distrust and paranoia. Volunteer Aryeh Gregor responded: This is a symptom of the tension between staff and volunteers. Naturally, volunteers are more likely to express their frustration here, because they don't have to act professional and because they're the ones who feel wronged in this case. More optimistically, the discussion turned to possible solutions. There was general agreement that getting back to more regular updates was the solution (Roan Kattouw): I whole-heartedly agree with the analysis that deploy backlog is at the hear[t] of this. I have some gut feelings I can't word very well right now that say the "solely because they're not WMF" isn't completely fair, but what you've stated multiple times in various guises is true: what matters is perception, fair or not. If volunteers *feel* ignored, that's bad. ... We need to come up with a plan that takes us back to regular (weekly?) deployments. I think cleaning up the CR [Code Review] backlog is an uncontroversial first step. This sentiment was mirrored by Aryeh Gregor: To reiterate, I think most of the problem will disappear when we have regular code deployment again. At this point, it's best to focus solely on that and forget about all other complaints. If problems linger for long after everyone's code is getting deployed on a regular basis, we can talk about that then, and I think everyone will be talking on much more amicable basis. There was continuing disagreement, however, about whether or not the Foundation was doing enough to achieve this goal, and how quickly it needed to be achieved. Discussion included the expansion of the code review base - including the rehiring of Brion Vibber, for example - which unfortunately coincided with the paternity leave of head code reviewer Tim Starling.

In brief
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.
 * Google Summer of Code participant Peter Potrowl appealed for someone to take over the development of his "reasonably efficient interwiki transclusion" project (Wikitech-l mailing list). See also Signpost coverage of the project
 * The Brooklyn Museum built its first open source software release, BklynFlow. BklynFlow is a MooTools class for creating Coverflow-like user interfaces for the web. It was designed for accessing Wikipedia content on iPad Kiosks placed for a recent exhibition.
 * Microsoft Research has released a tool to assist people in translating Wikipedia articles. The tool makes machine translations of articles and has a simple integrated editor to make improvements upon that translation. The new product is called WikiBhasha and as Wikimedia CTO, Danese Cooper announced, it is an open-source project.