On Aug 14, 2014 3:58 AM, "Erik Moeller" erik@wikimedia.org wrote:
On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride z@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.
Provided they're what you would have done anyway. Otherwise, they're "welcomed" with WONTFIX and superprotection.
On the subject of opt-out numbers, you can see them here:
http://multimedia-metrics.wmflabs.org/dashboards/mmv_dewiki#opt_in_opt_out-g...
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'm glad you know why people choose to opt out. I don't see that in the data you cited, how was that data gathered?
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.
What should inform the default for "readers" are the communities who care enough about those readers to volunteer millions of hours per month generating, curating, and protecting the world's largest ever educational work for the benefit of those very same readers. Yet WMF dismisses and belittles those volunteers as "power users" who couldn't care less, but hey, WE know best, now get out of our way or else!
Then, of all things, the next question is "Gee, why can't we retain good editors and attract new ones?"
In general, though, let's talk. The overarching principle we're not going to budge on is that this process is really not acceptable:
- The UI changes
- A subset of users is upset and organizes a poll/vote
- 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
Nor is this:
1) The UI changes 2) A given project rejects or requests modification to the change 3) WMF crams it right down their throat regardless. 4) Local admins do what they can to implement the consensus, as they are selected by the community to do. 5) WMF throws a fit and threatens those admins or gives itself "super" authority.
In your scenario, it's unacceptable that we ever reach step 5. The community, not the WMF, must be the final authority on each project.
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.
If there were a mechanism for a vote of no confidence, I think you'd see exactly that take place right now. But yes, if the current WMF will not back down from this position, we need a better one, and one with far less power to provide a temptation for abuse. That is not a desirable outcome, but it seems a necessary one more each day.
Except in cases where legal issues are at play, WMF must not overrule local communities.
This is not the org we want to be.
That's unfortunate. We have always operated as a community centered and consensus driven project, and that has worked not only well but stunningly well.
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.
And we made it clear ignoring the results was unacceptable. If you want to stop escalations, don't handwave away the people who day to day run the projects. There isn't a way you can overrule them and have that be okay; there isn't a magic word to speak. You must stop doing it.
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?
Then imagine how frustrating this situation is to people who aren't getting paid and donate their time. I get frustrated at my job, too, but that's why they pay people to do it. While I care deeply about Wikipedia and its mission, I will still eat and pay the rent tomorrow if I leave it today.
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.
A partner, yes, exactly. Not an authority, not a boss. If you want to be treated like a partner, ask, do not demand, and accept "no" as "no".
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.
Do a lot better than you have been. Thus far, the options on offer are only a "compromise" in that they will badly compromise local autonomy. Those will not be accepted, no matter how often they are floated.
Todd Allen