On Tue, Aug 19, 2014 at 2:18 PM, Andy Mabbett andy@pigsonthewing.org.uk wrote:
Nonetheless, I'm having difficulty understanding how these two statements:
the Wikimedia Foundation reserves the right to determine the final configuration of the MediaViewer feature,
We’re absolutely not saying that WMF simply wants to be able to enforce its decisions
can be reconciled.
Hi Andy,
I think it's clear that we need to develop a social contract that works for both parties. It doesn't work for communities if WMF simply declares an independent decision after a vote or RFC takes place (and yes, we have done so in this instance, and in others in the past). And from WMF's point of view (for reasons we have already articulated several times), it doesn't work to expect that WMF will implement every vote or RFC as-is without negotiation or discussion, and without room to take other factors into account.
When we talk about WMF's role, we need to distinguish between technical processes and outcomes.
In order to ensure consistency (including on issues like release planning, communications, bug reporting, etc.), WMF needs to manage the configuration and deployment _process_ (e.g. we flip the switches). In order to be able to exercise its leadership role in technology, it needs to have a say in the _outcome_, even if/when there are RFCs/votes asking us to disable a feature.
That to me is what the "shared power" guiding principle means -- we have clear roles and responsibilities, and we share in the decision-making.
When we disagree, we need to figure things out together, hear each other, and reason constructively. We don't have good conventions to do that right now. The "community vote -> WMF responds yes/no" or "community vote -> WMF responds with compromise" process is deeply insufficient and one-sided. It's a win/lose process rather than a process for working together.
We need to avoid getting to this place to begin with, but we also need to have better answers when we do, as I'm sure we inevitably will again from time to time.
This is what we're kicking around on the process ideas page: https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas
Specifically, for something like Media Viewer, a lot of the issues we've had to work through relate to community-created technology (!) like custom templates used for certain purposes.
In these situations, sometimes the answer may be "Actually, what you did here with a template is a horrible idea and you probably shouldn't be doing it that way" -- and it's very hard for us to have these conversations honestly if it's in an oppositional context with a group of 200 people. And sometimes we need to support use cases that the community cares very much about, even if our initial reaction is "Do we _really_ have to do this?".
I think it needs to be much more tightly coupled, co-dependent working relationship through the product's lifecycle so we can work together honestly and with shared expertise.
That's true for VE, Flow, etc. as well -- we've tried the "light touch" community liaison model but I think we need something that brings us even closer together in day to day working practice. And my experience with Wikimedia volunteers is that there are almost always people willing to give their time if they feel it's actually valued in the process. Not tens of hours a week of course (that's why we have paid staff), but enough to stay informed and participate.
I could imagine having a process where, for any given project, there's a nomination and lightweight election process that lets people participate in associated communtiy task forces, which have weekly check-ins with the product team and actually meaningfully influence the roadmap. Is this something that people think could work? Has it worked well in other contexts?
I think the inter-dependent relationship on technology is really important to appreciate here -- it's something that's very unique to us (because of the countless templates, tools, customizations, etc. created by community members that interact with software we build). You can't have it both ways -- a crazy amount of customizability by the users themselves _and_ a very traditional relationship with software development ("ship a finished product to us and then we'll talk -- meanwhile let me add some parameters to this custom template that I expect your product will support from day 1").
Erik
[1] http://strategy.wikimedia.org/wiki/Task_force