As I understood it, the big gotchas for Phabricator adoption are that Phabricator doesn't manage repositories – it knows how to poll a Git repo, but it doesn't have per-repo access controls or even more than a shallow awareness of what a repository is ... [consequently], it would still need some work to efficiently deal with hundreds of repositories, long-lived remote branches, and some of the other fun characteristics of Wikimedia's repos.
—WMF Deputy Director Erik Möller addressing code review tool Phabricator
Three weeks into a month-long evaluation of code review tool Gerrit, a serious alternative has finally gained traction in the review process: Facebook-developed but now independently operated Phabricator and its sister command-line tool Arcanist.
Phabricator has long been considered a possible alternative to Gerrit, first appearing in discussions way back in February this year, prompting the Wikimedia Foundation to invite its lead developer to visit the WMF office in San Francisco and "sell" Phabricator to several key members of staff, including Deputy Director Erik Möller. That meeting occurred on August 6, reviving Phabricator as a contender for the role of Gerrit replacement.
A test project was quickly established; nevertheless, it is unclear whether lead platform architect Brion Vibber, who is heading the review, considers it a workable enough solution at present given concerns about its design paradigm (see quote box). Vibber this week suggested that despite the original cutoff date (August 10) having passed without Phabricator's credentials having been proven, the code review tool should continue to be reviewed and investigated on an ongoing basis for the immediate future.
Google Summer of Code: Watchlist improvements
Continuing our series profiling participants in this year's Google Summer of Code (GSoC) programme, whereby student developers are paid to contribute code to MediaWiki, the Signpost this week caught up with San Francisco–based student and amateur journalist Aaron Pramana, who took on the challenge of improving MediaWiki's watchlist feature.
One aspect of Pramana's project is allowing users to create watchlist "groups"
For my project, I've been working with Wikimedia developer Alex Emsenhuber to give watchlists a revamp, adding features and improving the workflow of the watchlist for current and potential power-users. For many wiki editors, the watchlist is one of the most important features that the MediaWiki software has to offer. Many top ranked websites, from e-commerce sites like eBay to media sites like YouTube, have comparable features that help users track pages that interest them. It was my view that the watchlist should continue to evolve so that the MediaWiki software remains a potent tool for the collaborative exchange of knowledge. This project was designed to be an amalgamation of several smaller feature improvements which will make the watchlist more useful.
Thus far, the project has added watchlist grouping, permissions to make watchlists publicly viewable by other users, and a new raw watchlist page. Although these features are still at an early experimental phase, I would like to solidify the progress I've made up to this point and then solicit ideas from the greater Wikimedia community for a more detailed plan towards a possible Wikimedia deployment.
The greatest challenge of the project has been assuming a scope of responsibility that is greater than a "typical" programming job. Every programming project I've participated in previously has emphasized specialization in one niche (e.g. one person does database work, another does UI design). However, GSoC teaches student developers to persevere independently and actively seek out help when needed, which are useful skills to have in the field.
Pramana added that after the GSoC project ends later this month, he'd love to solicit help from other interested developers, especially UI designers. Code for his project can be found on Gerrit; more human-readable updates also regularly find their way onto his blog.
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.
translatewiki.net to drop SVN extension support: Starting October 1, translatewiki.net will drop support for all MediaWiki extensions it currently supports that still remain in the Subversion repository, Community Manager Siebrand Mazeland explained this week (wikitech-l mailing list). The site, which assists a large community of volunteer translators in their efforts to improve language coverage for various open source projects, did not want to burden its translators with work on extensions that are not "well maintained". All extension developers are invited to transfer over to the current version control system Git to continue to receive updates. A maximum of 273 extensions are affected, Mazeland said. In related news, a translatewiki.net translation rally is ongoing. Funded by Wikimedia Nederland, the Dutch Wikimedia chapter, €1000 will be split between contributors who add 500 or more translations across 11 named Wikimedia-related projects before 18 August.
Redesigning Wikipedia: discussion continues: Continuing on from WMF Senior Designer Brandon Harris' opinion piece in last week's Signpost, things design-related have received attention on the Wikimedia-l mailing list this week, when it considered a redesign proposed by brand consultancy NewIsNew. Many of the visuals received at least a degree of praise, whilst there was criticism of the consultancy's ignorance of internationalisation and multilingual issues, which factor heavily into current MediaWiki thinking. The Signpost will carry an alternative to Harris' analysis of the correct future direction of MediaWiki design in the near future.
Introducing Phalanx: Development work has started on porting the Phalanx extension from its Wikia-specific beginnings into something suitable for deployment on WMF wikis. The extension represents the merging of existing "ad hoc anti-spam tools into one powerful tool" and is part of a wider WMF initiative to both improve and centralise MediaWiki's anti-spam (and anti-mass vandalism) provisions; smaller and non-WMF wikis are likely to benefit most from the work, which will also include the introduction of global abuse filter rules and the "rethinking" of MediaWiki captchas, which are easy for bots to break but still present difficulties for human users, according to a WMF-led investigation.