On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride <z(a)mzmcbride.com> wrote:
Is there anything that the German Wikipedia could do
to convince you to
disable MediaViewer there? Some percentage of active users showing up to
say so? Some percentage of users (logged-in or otherwise) disabling the
feature? (Presumably we can get stats of some kind.)
We are very open to continuing the discussion about how the feature
should be configured, how it should be improved, and how it should be
integrated in the site experience. Ideally we'd like to minimize
inconsistencies between wikis (because for readers who speak more than
one language, it's just a single site), so changes that help alleviate
conflict or disagreement should ideally also be of the kind that in
general are welcomed and wanted.
On the subject of opt-out numbers, you can see them here:
http://multimedia-metrics.wmflabs.org/dashboards/mmv_dewiki#opt_in_opt_out-…
As you can see, the recent drama has contributed to a significant
increase in opt-out events. Pre-vote, about 17% of very active (>100
edit/month) users had disabled MMV. This is about the same number of
people who ultimately voted no, BTW, about 200. Post-vote it was 20%.
Since then it has climbed to 23%. In contrast, about 30% of that same
user group still use Monobook.
I think those numbers can and should reasonably inform the default for
logged in users, for sure. I don't think they should be used to
determine the default for readers.
In general, though, let's talk. The overarching principle we're not
going to budge on is that this process is really not acceptable:
1) The UI changes
2) A subset of users is upset and organizes a poll/vote
3) The poll/vote closes with a request to undo said UI Change and a
request is filed
4) WMF offers compromise or says no
5) A local hack is used to undo said UI change
That's no way to develop software, and that's no way to work together.
If you want a WMF that slavishly implements RFCs or votes to disable
features upon request, you'll need to petition to replace more than
just one person. In fact, you should petition to reduce the staff
dramatically, find an administrative ED who has no opinion on what to
do, and exclusively focus on platform-level improvements and requests
that clearly have community backing.
This is not the org we want to be. I am hopeful and optimistic that
there are enough admins and regular editors who believe in a vision of
improving the user experience iteratively, and working together
through conflict, that we can in future entirely rely on local admins
to prevent the kind of JS hacks we've seen here, working towards a
proper code review and deployment mechanism that further alleviates
the risk of escalations. Mind you, we made it very clear in this case
ahead of time that JS hacks were unacceptable, we attempted a revert
and a very explicit warning.
None of us love drama. We've been punting on this issue for a long
time, living with ambiguity that we knew was going to bite us sooner
or later. When DaB. removed the link to Beta Features on de.wp in
November, calling it "clutter", we ignored it and hoped that another
sensible admin would step in and restore it, because we didn't want to
trigger precisely this kind of conflict over minutiae. (It was only
restored a couple of days ago.) In other cases we've made simple
reverts to MediaWiki: edits and hoped they would stick. Can you
imagine how frustrating this is for developers and UX designers who
are paid using donor funds to improve the user experience?
We need rules of engagement for these types of changes, and they need
to acknowlege that WMF is a partner in them. The problem with the
sequence above is that there's no venue for negotiating compromises,
evaluating options, and establishing final agreements about what
should happen. That puts WMF in a position where we get to say "yes",
"WONTFIX" or "here's a random compromise, hope you like it". We
need
better ways to discuss and negotiate when we disagree.
Please give us some time to outline some compromise options consistent
with the above. However, please don't expect us to endorse the idea of
"If WMF doesn't do what we want, we'll just enforce it by means of a
local hack". That is simply not workable, and no Wikimedia Foundation
that at all resembles the one we have today will accept it.
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation