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.

The answer is already given ... When it is done. You have been informed with the latest developments.. so you know the existing issues.

Instead, I think the right approach is to put new software out there frequently, so people can try it out for themselves and form their own opinions of how close we are. Eventually, both the builders and the community will agree that there's something worth shipping. And in the meantime, the discussion that goes on will improve the product in ways that no mere look at the calendar ever could.

William has mentioned there are software checkins, etc. in progress. Even a list of those would be excellent stuff.

William Pietri wrote: What does this paragraph say about the 20 or so Wikimedia wikis that are already using FlaggedRevs?

Also, David Gerard made a suggestion about weekly updates that concretely list the progress that's being made with regard to FlaggedRevs development. What can be done to see that idea implemented as soon as possible?

Purely as a point of fact it is simply inaccurate that the 20 implementations of flagged revs and patrolled edits across the other wikies than English Wikipedia are monolithically identical. I know this firsthand.

we think there are some interface changes are going to improve both the user experience and the value of the enwiki trial.

2010/3/1 Austin Hair <adhair(a)gmail.com>om>: 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-answ… [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 -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate _______________________________________________ foundation-l mailing list foundation-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

I'm curious as to whether there's anything official behind this poll[1] on en.wikipedia to "simply turn on flagged revs in the form that the Germans use it" until the proposed enwiki changes are ready.