Erik, I'm impartial about the mediaviewer, but I have the feeling that this is a recurring a pattern: 1) contributors ask for some change to improve their experience or the reader's experience 2) their request is ignored because either it doesn't fit in the big picture, or there is no mechanism for them to voice a request other than to fill a bugzilla or start a rfc that will be gathering dust till the end of the days 3) the changes are implemented anyhow in a hackish way, or not implemented at all 4) technical debt builds up until there is the need to find a stable solution 5) the wmf steps in with a good technical solution, or comes up with some unrequested neat feature, but without gathering grassroots support 6) some editors are presented the tool, nobody complains because it is a feature still in development 7) the feature is rolled out hoping it will be accepted -> if it is not -> conflict
It would be more sensible to let contributors participate in the tech roadmap in more formal and empowered way than now, because without that early participation there is no possibility for later consensus. After the experience with the Wikisource Community User Group, I can say that with some effort promoting dialogue at international level, it is possible for the community to come up with a set of priorities and that builds up legitimacy. However that is all for nothing if that consensus has no impact in the development plan. Besides there seems to be a communication barrier between the contributors and the wmf that shouldn't be there, and I don't think the best way to remove it is to add more privileges or constraints, because that makes the barrier higher, not lower. TBH, I hope that the compromise options that you are drafting stop this drama, but it is also important to learn from how it came to be, so it doesn't repeat again. Cheers, Micru On Thu, Aug 14, 2014 at 11:57 AM, Erik Moeller <[email protected]> wrote: > On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride <[email protected]> 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-graphs-tab > > 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 > > _______________________________________________ > Wikimedia-l mailing list, guidelines at: > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > [email protected] > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:[email protected]?subject=unsubscribe> > -- Etiamsi omnes, ego non _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines [email protected] Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[email protected]?subject=unsubscribe>
