On Thu, Aug 21, 2014 at 10:54 PM, rupert THURNER rupert.thurner@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 tab.

- 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 addressed.

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 viewer.

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.

Cheers, Erik

[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