On Tue, Aug 19, 2014 at 2:18 PM, Andy Mabbett <a...@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


-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

_______________________________________________
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Reply via email to