On Thu, Aug 21, 2014 at 10:54 PM, rupert THURNER
<rupert.thur...@gmail.com> wrote:

> is the conflict not only triggered by a deliverable which was not good
> enough? it did not include the authors in its use cases. the deliverable
> e.g. did include one click more for the authors workflow. which make
> hundreds of million clicks more if you sum it up.


> erik, please can you tell me one good reason what hinders you to tackle the
> source of all this, and rework the mediaviewer use case(s)?

Rupert, I always like a good devil's advocate, especially when it
doesn't sound devil-ish at all. ;-)

Let's start with some facts:

- The MediaViewer rollout was very smooth until the deployments to
German Wikipedia, English Wikipedia and Wikimedia Commons. There could
be many reasons for that -- but it's a fact nonetheless. I do see
little evidence that users in other communities are especially unhappy
about the feature (leaving aside the politics of it now). I would be
very curious what reason people do attribute that difference to,
however (understanding that Commons is very different from the
Wikipedia use case).

- As a user, it's trivial to disable Media Viewer. Not quite as easy
as we want it to be, but literally a scroll-down and click away, which
is more than you can say about most MediaWiki preferences. It's also
trivial to skip on a case-by-case basis -- just open an image in a new

- Even on de.wp, if you read the comments from people supporting the
feature, in the poll leading up to Wikimania (a minority, but not a
tiny one - 72 voters in the poll [1]), you'll notice that the
reader/editor distinction isn't such a clear one. While many users
voted "on behalf of" readers, others pointed out that they themselves
like the fast access to the picture and switch back and forth as
needed (opening images in the background when they want to skip the
viewer). That was also what we heard from folks at Wikimania, for
example, and the generally low opt-out rates support it.

- The criticism isn't just about that -- it's about a large number of
mostly individually small issues. Generally, the idea that we
effectively "munge" some of the metadata by displaying a
machine-readable subset below the fold is viewed very negatively,
because 1) it doesn't reflect all the available information, 2) it
makes it harder for users to discover the File: page, and potentially
edit it.

Users who oppose the feature do not always do so strictly for personal
reasons, or many of them would probably be fine to disable it for
themselves; they often have criticisms that go beyond their own needs
and extend into areas like re-use, licensing information, and creating
an environment that draws people into contributing. Editors are not
blind to the needs of readers, they just have a low tolerance for
imperfections and would prefer to see a product that already addresses
all these concerns at the time of release.

We understand all that. We've read virtually every comment (surveys,
feedback page, votes/RFCs, etc.). I'm not normally as familiar with
every product WMF works on but by now I know many of the internals of
the damn thing (though Mark probably thanks the GNU deities daily that
I've not submitted any patches yet).

Change aversion is often [[loss aversion]] - people prefer avoiding
losses to making gains, which is why the positive benefits of a new
feature tend to be overshadowed quickly by any shortcomings, even if
they are (objectively speaking) comparatively small and easily

It's true that we (WMF) should have done more early on to specifically
help with template cleanup -- we made some efforts to add
machine-readable data to key templates and rally community help, but
they were insufficient. This is not strictly an engineering problem -
the CommonsMetadata extension works just fine, the documentation is
clear, etc. It's an outreach effort that should have accompanied the
rollout more systematically. With that said, the needed fixes to
templates are fairly trivial (we just worked with de.wp to implement
one), while immediately resolving issues with license display for
large numbers of files, and help many other applications beyond the

In addition, as previously noted [2], we're testing some pretty
significant changes of the UI, including a much more prominent
integration of the File: page link, identifying it clearly as the
canonical source of metadata.

We're not saying "You're wrong, we're right" - just that we understand
the issues pretty well, and we think the main concerns can likely be
addressed fairly quickly (and some already have been). In general, we
believe that there needs to be at least some allowance for iterating
on a release, rather than forcing an immediate revert. If we reason
things through together, try things out, look at the results, and
we're wrong, well, let's just turn the thing off completely rather
than making half-assed config changes in one wiki.

Mind you, in responding to the poll on de.wp, we didn't say "Thanks,
but no thanks" - we gave a detailed rationale, and we felt
(internally) that we were being reasonable in doing so, not that we
were being jerks, which explains at least partially why we then felt
maintaing that decision was appropriate. But I understand that even
the simple dynamic of "valid community process" -> "decision by WMF
that's not entirely consistent with it" leads to escalation, which is
why we're arguing for better process when we disagree.


[1] As a side note, in these conflicts, one of the things I'm most
frustrated by is that those voices of proponents tend to get lost.
Once it becomes about the power dynamic, the rational, supportive
arguments _by community members_ appear to carry no weight whatsoever,
and if anything, they risk being portrayed as stooges supporting the
Evil Bureaucracy. That doesn't strike me as consistent with the idea
of "consensus" either.

[2] https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073861.html
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at: 
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Reply via email to