Erik Möller --
You're the second-in-command at the Wikimedia Foundation and one of the people most directly responsible for Wikimedia's technology.
FlaggedRevisions has been promised on the English Wikipedia for months and months and months. What's the hold-up?
MZMcBride
On Mon, Mar 1, 2010 at 7:17 PM, MZMcBride z@mzmcbride.com wrote:
Erik Möller --
You're the second-in-command at the Wikimedia Foundation and one of the people most directly responsible for Wikimedia's technology.
FlaggedRevisions has been promised on the English Wikipedia for months and months and months. What's the hold-up?
I just want to point out that, although I moderated MZMcBride for his behavior and still find this post teeming with anger, I'd personally like to see the issue addressed. 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.
Austin, speaking only for himself
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
Erik Moeller wrote:
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.
So we can expect to see FlaggedRevs enabled on the English Wikipedia when?
MZMcBride
Hoi, The answer is already given ... When it is done. You have been informed with the latest developments.. so you know the existing issues. Thanks, GerardM
2010/3/4 MZMcBride z@mzmcbride.com
Erik Moeller wrote:
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.
So we can expect to see FlaggedRevs enabled on the English Wikipedia when?
MZMcBride
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Fri, Mar 5, 2010 at 12:51 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
The answer is already given ... When it is done. You have been informed with the latest developments.. so you know the existing issues.
That's normally the perfect answer, but the point of this discussion is that it's not unreasonable to expect something more concrete when there are people getting paid to do the work.
Hi, Stephen. Thanks for making your point in a polite, low-drama way.
On 03/04/2010 05:58 AM, Stephen Bain wrote:
The answer is already given ... When it is done. You have been informed with
the latest developments.. so you know the existing issues.
That's normally the perfect answer, but the point of this discussion is that it's not unreasonable to expect something more concrete when there are people getting paid to do the work.
I think the real problem here is not the lack of a date for when it will be done. It's that progress isn't sufficiently transparent -- something that also frustrates me and something we are actively working on solving.
Right now people can see code being committed, and they can see items being checked off. But for most people, that's effectively meaningless; it gives them no familiar, intuitive way to judge progress. So they fall back to dates, which they do have experience in judging, and deadlines, which give the comforting illusion of surety. [1]
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.
So yes, all parties are in favor of something more concrete, and as soon as possible. We're working on it. We would already have it, except that I underestimated both the issues involved in releasing to labs and the difficulty of quickly setting up new production-equivalent test environments. That's hard for the same reasons of historical underinvestment that until recently held Wikipedia's UI back.
And to address an occasional theme in both the on- and off-list mail I've received: I believe there are no bad actors or sinister plans keeping this from happening. If I did, I'd raise a ruckus, quit, or both: I've got better things to do than go-nowhere projects. This is happening. We are making good progress, progress that we want to show to you, and we will do that as soon as we can.
William
[1] There are a lot of reasons I think the deadline model is pathological for software projects. Having spent a decade understanding why and learning more effective approaches, I have a lot to say on the topic -- too much for this list, I think. But if people want to discuss that off-list, please do drop me a line. In the world of print, McConnell's "Rapid Development" ch. 8 and 9 has a very readable explanation of the problems. Poppendieck's "Lean Software Development" and Cohn's "Agile Estimating and Planning" are good places to start for the modern solutions. Caspers Jones also has some great material on deadline failure rates, but I don't have refs handy.
William Pietri wrote:
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.
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?
MZMcBride
On 4 March 2010 17:20, MZMcBride z@mzmcbride.com wrote:
Also, David Gerard made a suggestion about weekly updates that concretely list the progress that's being made with regard to FlaggedRevs development.
William has mentioned there are software checkins, etc. in progress. Even a list of those would be excellent stuff.
- d.
On 03/04/2010 09:59 AM, David Gerard wrote:
William has mentioned there are software checkins, etc. in progress. Even a list of those would be excellent stuff.
This appears to be the best source:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/aaron
William
Even better is [1], since it includes commits to FlaggedRevs other than Aaron's.
-Chad
[1] http://mediawiki.org/wiki/Special:Code/MediaWiki?path=/trunk/extensions/Flag...
On Mar 4, 2010 1:20 PM, "William Pietri" william@scissor.com wrote:
On 03/04/2010 09:59 AM, David Gerard wrote:
William has mentioned there are software checkins, etc...
This appears to be the best source:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/aaron William
_______________________________________________ foundation-l mailing list foundation-l@lists.wikime...
On 03/04/2010 09:20 AM, MZMcBride wrote:
William Pietri wrote:
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.
What does this paragraph say about the 20 or so Wikimedia wikis that are already using FlaggedRevs?
Nothing, really. But what I'd say in response to the question I imagine you're really asking: the English Wikipedia community has asked for something different than the other 20 wikis. And even for the areas the software is the same, we think there are some interface changes are going to improve both the user experience and the value of the enwiki trial.
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?
I'm going to take that as an endorsement of the suggestion. I like the idea of it myself, but I haven't answered yet because there's a problem I'm struggling with. Maybe folks here can come up with a solution that has so far escaped me.
Part of my role as a project manager is maximizing long-term productivity, which requires me to protect the people actually doing the work from external disruption. My fear is that if I give any sort of detailed report, that will expose any named person to needless drama, abusive language, hostile tone, and accusations of malfeasance, corruption, incompetence, and/or low morals -- all problems amply demonstrated on this very list. That would have a terrible, terrible impact on productivity, team morale, and the ability to attract more people to get involved.
So my current thinking is that I should focus all my energy now on getting us to where we can release publicly every couple of weeks, and do most of the regular communication as release notes. That would put the focus on the software, where I think it belongs. But if somebody has a plan they think better, I'm glad to discuss it.
William
William Pietri wrote:
On 03/04/2010 09:20 AM, MZMcBride wrote:
William Pietri wrote:
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.
What does this paragraph say about the 20 or so Wikimedia wikis that are already using FlaggedRevs?
Nothing, really. But what I'd say in response to the question I imagine you're really asking: the English Wikipedia community has asked for something different than the other 20 wikis. And even for the areas the software is the same, we think there are some interface changes are going to improve both the user experience and the value of the enwiki trial.
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.
If there is something about the implementation at English Wikipedia that is at the root cause of what we are discussing here, it is certainly not that English wikipedia is "different". It is genuinely tempting to state that there *has* to be something _unique_, perhaps even "transcendentally unique" about the goals set for the English Wikipedia implementation or the environment of that Wikipedia. I too could write a lot more about my feelings on this, but prefer not to.
The one thing that I do agree with most on, as regards to what the motivations of people are, is that I to refuse to believe there is anything sinister. Which is definitely not to say there is nothing wrong just because people are acting out of impeccable motives. As a simple logical inference, that is not supportable.
Yours,
Jussi-Ville Heiskanen
On 03/04/2010 10:57 AM, Jussi-Ville Heiskanen wrote:
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.
Sorry if I gave that impression. Indeed, I have direct evidence otherwise. When I run low on things to worry about, I pull up the spreadsheet I built showing the wide config variations in uses of FlaggedRevs. Not that it's worrying on its own; it's nice to see people using it and adapting it locally. It just means that potential bugs are harder to spot.
All I was trying to say is that the requested approach for the English Wikipedia, called Flagged Protection, differs from the existing uses.
For those unfamiliar, Flagged Protection is described here:
http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_revi...
William
William Pietri wrote:
On 03/04/2010 10:57 AM, Jussi-Ville Heiskanen wrote:
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.
Sorry if I gave that impression. Indeed, I have direct evidence otherwise. When I run low on things to worry about, I pull up the spreadsheet I built showing the wide config variations in uses of FlaggedRevs. Not that it's worrying on its own; it's nice to see people using it and adapting it locally. It just means that potential bugs are harder to spot.
All I was trying to say is that the requested approach for the English Wikipedia, called Flagged Protection, differs from the existing uses.
And as such, follows the pattern of all the other existing implementations; in so much as they differ from each others. So throwing this conformance with established implementations nature into the conversation is not too significant.
For there to be a significant divergence from the pattern of adapting as we go, there really needs to be a qualitative difference to the divergence, not just a noting down that the English Wikipedia like all others, diverges.
Yours,
Jussi-Ville Heiskanen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 37-01--10 03:59 PM, William Pietri wrote:
we think there are some interface changes are going to improve both the user experience and the value of the enwiki trial.
Why did it take this request from enwiki to have the UX aspect of flagged revisions taken seriously?
This has been one of the main complaints about the implementation since day zero. All other complaints I've heard have been regarding the idea, not the implementation. The UX problems are real, yet were unaddressed until very recently. Why? Will the Foundation be expending effort on this using the now-permanent UX team?
- -Mike
On 03/04/2010 01:45 PM, Mike.lifeguard wrote:
Why did it take this request from enwiki to have the UX aspect of flagged revisions taken seriously?
This has been one of the main complaints about the implementation since day zero. All other complaints I've heard have been regarding the idea, not the implementation. The UX problems are real, yet were unaddressed until very recently. Why? Will the Foundation be expending effort on this using the now-permanent UX team?
This is history of which I'm partly ignorant, but I don't think there's anything specific about the enwiki request that triggered the user experience improvements.
I think MediaWiki coders -- like developers everywhere -- have consistently built things with the best interfaces they knew how to make. The difference is that now there are people with strong UX backgrounds on staff and available to help, which means better results.
So I'd say that the UX improvements underway for Flagged Revisions are already a sign of what you're looking for: the Foundation's desire to use the UX team more broadly to make everything better.
William
On Thu, Mar 4, 2010 at 12:44 AM, Erik Moeller erik@wikimedia.org wrote:
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 -- Erik Möller Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
foundation-l mailing list foundation-l@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.
-Chad
On Thu, Mar 4, 2010 at 11:33 PM, Chad innocentkiller@gmail.com wrote:
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.
-Chad
Either way, shit will hit the fan on wiki if that happens, because the locals have never really liked foundation interference in things and they actually managed to consensus on what they wanted to be implemented (and getting that on en.wiki is not easy).
On Thu, Mar 4, 2010 at 8:33 AM, Chad innocentkiller@gmail.com wrote:
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.
Is it even technically feasible? Turn on flagged revs in the form that the Germans use it, add a rule that the *first* sight of any article must be done by an admin, and you've basically got the proposal agreed to by "a consensus" on en.wikipedia.
On Thu, Mar 4, 2010 at 7:43 PM, Anthony wikimail@inbox.org wrote:
On Thu, Mar 4, 2010 at 8:33 AM, Chad innocentkiller@gmail.com wrote:
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.
Is it even technically feasible? Turn on flagged revs in the form that the Germans use it, add a rule that the *first* sight of any article must be done by an admin (*), and you've basically got the proposal agreed to by "a consensus" on en.wikipedia.
(*) Or, I suppose, anyone with the "surveyor" right. In any case, not a whole lot of code involved.
wikimedia-l@lists.wikimedia.org