2010/3/1 Austin Hair adhair@gmail.com:
I think it would be great if someone on the project could put the initial tone aside, turn the other cheek, and let everyone interested (and I know there are several) know what's going on.
Hi Austin et al.,
William has already posted extensively on this topic, so I'll keep it simple. Since our last update in January [1], Aaron has continued to work [2] through the list of issues [3] specific to the enwiki feature request called "Flagged Protection". The current version of FlaggedRevs has dependencies on MediaWiki core that haven't been deployed yet, and the labs sites run on the same code tree, so Aaron is now backporting the extension to work with the currently deployed MediaWiki version, so he can pull the update to labs. Rob has also separately re-purposed one of the servers from our main cluster, which Aaron and Rob will set up as a separate testing environment that can run any code, but which will need to resemble a roughly production-equivalent system setup so that any observed behavior matches what we will observe in a full production deployment.
William will post a more detailed update once the new code is available for public testing. We'll need to test both the enwiki setup and common existing configurations to ensure that we're not breaking any pre-existing configurations, as we're not intending to fork the extension.
Looking forward, our UX team has recently contracted Ryan Lane to develop a new QA pipeline that supports easy spin-up of prototype sites, as well as automated interaction testing using Selenium. [4] So far, they've been using Linode VMs for prototype.wikimedia.org, but their performance characteristics haven't been consistent with our needs.
We're very thankful for Aaron's hard work on the FlaggedRevs extension over the years; it's really almost entirely due to him that the extension is now in active use in more than 20 wikis, with more than 1M pages patrolled in dewiki alone. That's an amazing achievement for one young, talented engineer. And we're also grateful to William and Howie for helping to guide the process, especially after Brion's departure.
With that said, the concepts of FlaggedRevs pre-date even WMF itself, and first development work began when the organization just had a tiny number of employees. As a result, the process has involved almost every single stakeholder in the Wikimedia movement (having an opinion, not writing actual code), and as a product development process, been entirely broken. We'll see it to further deployment, but of course it's not the panacea that some people think it is; everyone means something different when they talk about it, and there's a lot more work to be done in the problem-space.
Through investments like the UX team, WMF is now building its capacity for team-based product development, and ultimately, the tools we develop to deal with quality assessment, moderation and labeling (and IMO labeling is just as much a component of the BLP problem as edit moderation) will need to be part of our overall product roadmap and be tackled by the team as a whole. But, there are no shortcuts: new hires take time to get productive, legacy projects need to be carefully transitioned, and operations capacity (both staffing and resources) needs to grow commensurate with new challenges. WMF is doing more than ever before to serve its mission, but aspirations typically grow more quickly than foundations.
All best, Erik
[1] http://techblog.wikimedia.org/2010/01/flagged-revisions-your-questions-answe... [2] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/aaron [3] http://www.pivotaltracker.com/projects/46157 [4] http://usability.wikimedia.org/wiki/Resources#Interaction_testing_automation