Hi Erik, I understand you reasoning, but you couldn't have communicated and timed this in a worse way. You might be doing the right thing, but because of this ill communication and timing, this will be completely overshadowed. That saddens me. Good luck with the shit storm........ :-( Maarten Erik Moeller schreef op 10-8-2014 14:27:

On 10 August 2014 15:51, MZMcBride <z(a)mzmcbride.com> wrote: I thought this was a response to someone hamfistedly editing en:wp's JS and *actually breaking it*. When Erik reverted this change and said "don't break the damn wiki", the response was "but we can so we should be able to!" and an attempt to take the Foundation to en:wp arbitration. The obvious response is to make it so that such blithering stupidity can't be enacted again. - d.

On 10 August 2014 16:08, MZMcBride <z(a)mzmcbride.com> wrote: That's *definitely* a claim needing actual evidence, considering he didn't bring it. I assume you can produce something. - d.

On Sun, Aug 10, 2014 at 6:29 PM, John Mark Vandenberg <jayvdb(a)gmail.com> wrote: With that done, I'd like to ask that discussion on this topic be continued there. Not that this isn't an appropriate forum for the issue to be raised, because it obviously is, but a public, transparent, and permanently documented RfC seems like a better place for it than the inboxes of this select few. Austin

The people who were actually responsible were the community. Erik was acting in a preventative role to prevent further disruption not punish administrators. The community. couldn't take no for an answer and what has happened? * Wheel/edit wars * A new user right to prevent disruption * A priviledge has been revoked on dewiki * A user has been desysoped by the community for no reason on dewiki And who are we blaming? Erik. Why? Because we are a bunch of stubborn children. We don't get what we want so we are kicking and screaming to get it but in the end; we don't and we then accuse our parent (WMF) of being too harsh, mean and taking away something we like but do not deserve. To be honest - until we as a community learn we are not the overlords, the masters, god of Wikimedia, we can work to building a real encyclopedia with awesome feature where are all work in a good environment and get on as a community and Foundation. I am not saying the WMF is perfect and is not in the wrong; they certainly have some blame to take and I will come onto that shortly, but we can not blame the Foundation for revoking something we clearly do not deserve. Erik, While I will say you have not been communicating stuff the best you can and this new user right was proxy deployed by Tim and an advocate and not your self - you mean well and I see this. I agree with everything you have done so far as a matter of fact. Fabrice, Have you attempted to start any discussions with communities in exactly why they don't want Media Viewer and how exactly it causes so much dispute that it requires Erik to proxy intervene? It not, please do so. In a short conclusion - I feel both parties have acted inappropriately and our bitching at each other does far than solve it. The WMF had to implement a new right and revoke dewiki's access to their site wide js page because of their refusal to accept what the WMF said and want to create a performance killer hack to 'fix it' at the cost of performance. Why did dewiki have to do this? The WMF refusing to disable Media Viewer. From what I see, the WMF have backed up by they refused to do this for Wikipedias and their compromise for Commons is acceptable. I have yet to see a valid reason why Media Viewer exactly makes Wikipedia go into a 'OMG UNUSABLE DISABLE IT FUCKING NOW OR I WILL' state. Media Viewer allows you to view and images without leaving the page - reducing load time for both users and the WMF. It is hardly the beginning if the end for images. If we take a quick look at the statistics - 64 voted against Media Viewer on the English Wikipedia while 6kish users enabled it, this shows 1.1% consensus for disabling the extension in a whole. I will not ramble on any more. I just ask the community to stop bitching at the WMF and accept their decision. Until then - I fully support Erik super protecting every single js and CSS page on every wiki as most Sysop I feel are technically incompetent. John Lewis -- John Lewis

MF-Warburg, that came across as a bit rude... On 11 Aug 2014 00:29, "MF-Warburg" <mfwarburg(a)googlemail.com> wrote:

As long as we all stay friends! On 11 Aug 2014 00:57, "MF-Warburg" <mfwarburg(a)googlemail.com> wrote:

Lila, I hope you are aware of the issues being described in this thread. Would you please state your views on this situation? Pine On Aug 10, 2014 6:09 PM, "Tomasz W. Kozłowski" <twkozlowski(a)gmail.com> wrote:

On Sun, Aug 10, 2014 at 11:42 PM, Tomasz W. Kozłowski <twkozlowski(a)gmail.com> wrote: Tomasz, While I appreciate your indignation, this is absolutely not the tone appropriate for the list, nor is it one likely to effect your desired outcome. Please be civil, and consider commenting on the RfC rather than making personal attacks and veiled threats on this mailing list. Austin

Erik, I wonder, did you have discussion with other staff and moreso, the technical staff before you went ahead and implemented this and also something most of us are wondering, just because dewiki did not accept your "enforcement" of MediaViewer, did you abuse your authority and force the technical staff to create this new permission (superprotect) so that you can override a community's decision..a permission which currently only the staff have access to? Seems a bit dictator-like... your comments above is just not reasonable enough.. On 8/11/14, svetlana <svetlana(a)fastmail.com.au> wrote: -- Cometstyles

This is, by far, the most disgusting and disrespectful action undertaken by the Foundation that I have ever witnessed. The 2012 mass desysopping of volunteer administrators on the WMF wiki and the past threats of desysopping users re: VisualEditor and MediaViewer do not even come close to this. It is clear to me that the Foundation has agreed on this sneaky change behind closed doors while some of the most outspoken Wikimedia volunteers were (and still are) gathered in London. This is not the first time that we're seeing this happpen, and it is clear to me that the Foundation has lost all remaining moral authority to talk about transparency and involving volunteers in the decision-making process. Erik has forced his employees, including a so-called community advocacy liaison, to use this opportunity to actively fight the volunteer community of the German Wikipedia. He himself has engaged in a wheel war over this, and continues to shove MediaViewer down the German Wikipedia's community throat. I'm not sure what was the purpose of this change, but if its aim was to escalate the already tense situation between the WMF and its volunteer communities regarding MediaViewer, protecting the MediaWiki:Common.js page so that no one can edit it was the perfect choice. This action will cause a huge shitstorm, and Erik deserves every bit of shit and mud that will be thrown his way. You can force anything you like on your employees, but you cannot force the volunteer community to do what you want, not in a manner like this. Remember that in the end, the community can exist without the WMF, but there is no WMF without the community. -- Tomasz

Erik, I'll be writing a longer post on the Meta RFC later, but can you confirm whether the idea is to "superprotect" key interface pages like [[Mediawiki:common.js]] on a permanent basis, or will this feature only be used to lock pages temporarily in the case of wheel warring or other circumstances like what happened on de.wp? Thanks, Craig Franklin On 10 August 2014 23:27, Erik Moeller <erik(a)wikimedia.org> wrote:

Has it ever come to the mind that something is going wrong on how the community is approached? Has it ever come to the mind that some software implementations have gone to hastily with negative effects? That the community reacts the way it does now, is because they care very much about the site and they notice something is terrible going wrong on WMF side and too less is done to fix those problems/issues! Apparently nothing (or not enough) has been learned from the VE 2013 fiasco. Romaine 2014-08-10 15:27 GMT+02:00 Erik Moeller <erik(a)wikimedia.org>rg>:

On Wed, 13 Aug 2014, at 10:46, svetlana wrote: sysops aren't even held accountable they are elected once for an infinite term nobody reviews their contribution in position in power ever this would surely be solved by making them elected on a 2-year term then re-elect svetlana

On 13.08.2014 02:48, svetlana wrote: Sounds exactly like an indeffed former contributor to the Russian Wikipedia. I do not think we should discuss the administrator elections on this list. Anyway, there are projects where administrators only get elected for a finite period. Cheers Yaroslav

On Wed, 13 Aug 2014, at 10:53, Pete Forsyth wrote: Surely this issue can be solved by talking without force: if you don't think so, you get force applied to YOU; you started a fight, and lost it. Because you went and did something contradicting user preferences; WMF did not. You'd think it's "better" because it's "unchanged compared to what it was X months ago", and that justifies your thing? No, it does not.

On Thu, 14 Aug 2014, at 00:50, Pete Forsyth wrote: I am being generic. The "you" refers to whoever made the edit which was reverted by WMF and super-protected.

2014-08-13 2:46 GMT+02:00 svetlana <svetlana(a)fastmail.com.au>au>: You miss a very important thing here: the community does not want to use such measure at all, but is forced to this by the inappropriate behaviour of some WMF staff. The community gets the feeling that it isn't listened to, while it has serious points and considerations which are stepped over too lightly. And as I said before, we are all on the same ship. Sure a captain must make decisions, but if parts have serious comments, issues, and critics, such should not be ignored. I do not think the community thinks that way. Members of the community can make mistake and staff members of WMF can make mistakes, I think that both that community and WMF are grown up enough to correct mistakes if they arise. Certainly inside the community are many critical people who watch these kind of things carefully and do correct those things when a mistake is made. The German community did collaborate, did communicate. Having a voting is a desperate way of getting the attention of the big problems WMF has too little insight in apparently. The community does not think in power structures, WMF does. Just as in 2013, again the problems start inside WMF and not in the community, and the community reacts on it. Romaine

On 13.08.2014 05:57, Pine W wrote: Point 2 is essentially impossible to confirm. People are coming, leaving and sometimes coming back (when I left the Russian Wikipedia in 2011, most of my opponents just said they are sure I was playing games and would be back soon). You never know why they leave, and even if they have left a clear message you never know how serious it is. It is quite unlikely that on a short term a significant share of active users will leave or has left - the German Wikipedia is not the Acehnese Wikipedia, and even if a dozen of users would leave at the same time, it can not be detected by the editing statistics. The long-time consequences and trends can of course be detected but then you would need to reach the active users who really have left and asked them why they left - it is unlikely anybody would successfully perform such study. Cheers Yaroslav

On Wed, 13 Aug 2014, at 20:36, svetlana wrote: I started drafting some thoughts on what /not to do/ in an RFC. These thoughts can be found here: https://meta.wikimedia.org/wiki/Requests_for_comment#Guidelines

On 08/13/2014 01:31 PM, Trillium Corsage wrote: I've spent no small amount of years involved in the various layers of administrative/governance/meta aspects of the English Wikipedia and from this I learned one lesson: "Whenever someone says 'the community' without qualifying this to an enumerable set of users means the assertion is definitely false." There is no such thing as "the community"; we have a huge collection of communities joined loosely over a number of ambigously shared principles that often - but not always - move in more or less the same direction. Anyone who claims to speak for "the community" is - put simply - full of shit. -- Marc

On 13 Aug 2014, at 21:12, Pete Forsyth <peteforsyth(a)gmail.com> wrote: {{citation needed}} There are some community members who spend a lot of time thinking about what "the community" and "the readers" may want, who actually have a good understanding of what is needed to support those stakeholders. There are others that say that their views represent the community/readers when they don't. A distinction needs to be made there - don't confuse the former with the latter. Additionally: there is no guarantee that what has worked well in the past will continue to work well in the future. The internet is always changing and improving, and a lot of organisations that dominated a decade ago now only exist in historical record. Wikimedia really needs to match the current state of the art, otherwise it will likely also cease to exist. I'd like to see the Wikimedia community leading the way with the internet's development, but right now it feels like it's lagging by about a decade, and the WMF is having to play a leading role to keep it relevant. If the Wikimedia community can catch up with the current state of the internet, that would be great, but if it can't then supporting the WMF while it does so would make a lot of sense. Thanks, Mike

On Wed, Aug 13, 2014 at 10:12 PM, Pete Forsyth <peteforsyth(a)gmail.com> wrote: Dear Pete, You speak as if there is no cost to disabling and re-enabling an interface. That is not the case. As you say, millions of readers use the site. And just like editors, introducing a new, very different viewing experience - like MV - takes some time to adjust to. We saw this in survey responses improving over time where they were initially negative, and we also saw it in some comments of the type "I am getting used to it now and I like it". (We also got plenty of "I love this, this is great" type comments.) To the extent that there are discoverability issues in the current UI, they are just that: discoverability issues. That doesn't mean if the same user keeps using the same inteface, they will never click a button - it means it's harder to figure out than it needs to be. Some of this was already fixed in production. For example, adding a label to the "Use this file" button more than doubled its usage. This is how this stuff works: You instrument, you change, you learn. Other changes are underway. Turning off the UI completely means readers who have gotten used to it or who have always enjoyed it will have to re-learn the old UI, then re-learn the new UI when some (undetermined) set of conditions are met. That's jarring, confusing, and avoidable. This is why on all major sites, you see a gradual ramp-up of a new feature, and continued improvement once it's widely used. Often there's an opt-in and then an opt-out to ease users into the change. But once a change is launched, it very rarely gets rolled back unless it's just clearly not doing what it's supposed to. Yes, we can all agree that we need to continually raise the bar for how we build software (without getting into analysis paralysis) -- but that doesn't mean that reverting (here or in other cases) once there's an ad hoc vote (or two, or three) is the right thing to do. No other significantly sized organization follows the development methodology you're proposing WMF should follow. Certainly, WMF is an unusual organization, and we have every desire to take concerns seriously, engage with people, scrutinize data honestly, and work iteratively to make things better for everyone. What we can't and won't accept is the idea that admin-reverts of features are an OK way to try to enforce the outcome of an ad hoc poll or vote. We can - and should, and do - talk to figure things out. We can - and should, and do - work out compromises. (And we did indeed agree to implement a compromise solution for Commons.) But the idea that WMF always must slavishly execute the result of a poll or vote is neither rational nor sustainable, nor has it ever been practice --- much less controversially so in situations where WMF's decisions cannot be overriden by admins employing JavaScript hacks. If we're being honest, at the end of the day, a lot of this is about establishing clear governing principles for the MediaWiki: namespace. The fact that WMF doesn't implement every vote and indeed has in the past even been somewhat capricious at times when it did not (especially when such decisions were made just by a single dev applying their own best judgment) is not in question. From a communications perspective, we handled WP:ACTRIAL much more poorly than we did this (we responded way too late), for example. But you can't implement WP:ACTRIAL in JavaScript. But there is no governing principle - documented clearly - that says you can't disable a feature using the MW: namespace. WMF is saying it now, and people perceive that (understandably) as a power grab. Fair enough - it is the explicit extension of existing authority into a novel domain. Such a change is always contentious and controversial, but I don't think it was avoidable. If we are to work together effectively, we need to define areas of competency and responsibility clearly. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

On Thu, 14 Aug 2014, at 07:32, Erik Moeller wrote: This is indeed true. Why does a global.js or whatever edit override user preference in the first place? I would expect user preferences to run after global.js, and set the onClick event back to what it should be (such as, something meaningful where a user has MV enabled). svetlana

On Thu, Aug 14, 2014 at 1:41 PM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote: Out of interest, when was the last time that a common.js change brought down the servers? -- John Vandenberg

Erik Moeller 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.) I'm curious what it would take for you to change course here. We should note that your behavior on the German Wikipedia has resulted in you being blocked there for a month. I get the sense that many people on the German Wikipedia feel as though there's no way you'll ever be convinced to disable MediaViewer. And from the comments I've been reading, this incident, along with others, has done significant damage to both your reputation and the reputation of the Wikimedia Foundation. You've not established an overriding interest here. If this issue related to online harassment or child protection or biographies of living people or the ability of users to edit or copyright or something else that matters, it might make sense for you to step in. But we're discussing an entirely supplementary feature. A few wikis (three by my count) have tried MediaViewer and have decided that they'd rather not have it be opt-out on their wiki. Instead they'd prefer that MediaViewer be opt-in for now. These communities have politely requested a configuration change, which should be within the purview of Wikimedia stewards, but MediaWiki doesn't yet have a graphical configuration user interface. Why deny these seemingly reasonable requests? MZMcBride

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 <erik(a)wikimedia.org> wrote: -- Etiamsi omnes, ego non

On Thu, Aug 14, 2014 at 3:35 PM, David Gerard <dgerard(a)gmail.com> wrote: Talking in several venues about what one is doing cannot be considered consensus building. Actually it is the opposite, because it is an extrinsic change and as such it cannot be appropriated by any ad-hoc community. Even worse, it gives developers the wrong impression that they are working under general approval, when actually they might be communicating only with the people that normally would accept their project, but not the ones that normally would reject it. It is of course impossible to involve everyone, but the more voices are included the better represented will be the interests of the ones that are not present. Cheers, Micru

On Thu, Aug 14, 2014 at 11:30 PM, Chris Keating <chriskeatingwiki(a)gmail.com> wrote: A first step would be to abide to the principles of Open Process http://meatballwiki.org/wiki/OpenProcess Namely: - Transparency - all communications and decisions are public and archived, so anyone interested may get all information - No time constraints - all decisions (democratic or not) are suggested or announced a reasonable timespan before they become effective. So there is still time for discussion and even last minute intervention. - Participation - in principle (this opens the chance for restrictions in case of problems) anyone is welcome to participate (discussions, decisions *and* work) - * Reflection and reversibility - any decision may be reversed if the results are not as expected. * - Tolerance - any system or process should have the flexibility in the application of its - necessary - rules - Sharing and collaborating on visible and accessible goals and resources Then a second step would be to engage the community, not only as something that has to be "managed", but as an equal partner that has to take up responsibilities and who is able to affect decisions. This of course means a paradigm shift moving away from "community liaisons" and into the realm of helping contributors to constitute themselves enabling them to take up a shared ownership role without the need of a formal organization. I don't think the wmf is entirely responsible for making this happen, there is also have to be a general will to embody such a spirit without resorting to staff, hierarchies, or votes. The problem is that most of us live in a world that doesn't work this way, and the attached structural flaws are imported, when there is no need to. Anyhow, that should be something to speak about when the tensions have been defused. Cheers, Micru

Gerard, Citizenship in the digital world is more flexible than in the real world, but that doesn't mean that it doesn't exist or that it cannot be characterized. It is just a matter of providing a conceptual framework for defining rights, obligations, etc. and it avoids precisely that a person, or a group of people, or part or the community, or a sub-community, or any of the several communities, overtakes a decision-making process that belongs to the whole. The terms of use can be considered a first approach to this tough problem, and it has many interesting keywords: "Part of our mission is to", "You are free to", "Under the following conditions", "With the understanding that". Unfortunately it just a "terms of use", not a "terms of community". If such a thing came into being, there you could state: "Part of our mission is to promote a healthy collaboration between ourselves, you are free to represent yourself and others in our community, under the condition that they have provided you explicit consent and that you respect the interests of non-represented users, with the understanding that we work for the benefit of all humanity and not only for our own." Cheers, Micru On Fri, Aug 15, 2014 at 12:27 PM, Gerard Meijssen &lt;gerard.meijssen(a)gmail.com > Hoi, > David, who is the community and how do you get members of the community > recognise and respect the decisions it does not like that are taken on > their behalf by "its" representatives. We do not have one community, we > have many. The interests people aim for are diverse and all too often > contradictory.. > > Really, in the past one part of the community insisted that it ALWAYS > requires to be able to have the deciding influence for "its" project.. That > clearly pains the picture for me. > Thanks, > GerardM > > > On 15 August 2014 10:17, David Cuenca &lt;dacuetu(a)gmail.com> > > On Thu, Aug 14, 2014 at 11:30 PM, Chris Keating < > > chriskeatingwiki(a)gmail.com&gt; > > > > > > how should this be solved? > > > > > > To me it's saying that no matter who is informed, the WMF can never > > expect > > > that their work won't be overruled. > > > > > > That is problematic (regardless of who has the final authority) > > > > > > A first step would be to abide to the principles of Open Process > > http://meatballwiki.org/wiki/OpenProcess > > > > Namely: > > > > - Transparency - all communications and decisions are public and > > archived, so anyone interested may get all information > > - No time constraints - all decisions (democratic or not) are > suggested > > or announced a reasonable timespan before they become effective. So > > there > > is still time for discussion and even last minute intervention. > > - Participation - in principle (this opens the chance for restrictions > > in case of problems) anyone is welcome to participate (discussions, > > decisions *and* work) > > - * Reflection and reversibility - any decision may be reversed if the > > results are not as expected. * > > - Tolerance - any system or process should have the flexibility in the > > application of its - necessary - rules > > - Sharing and collaborating on visible and accessible goals and > > resources > > > > Then a second step would be to engage the community, not only as > something > > that has to be "managed", but as an equal partner that has to take up > > responsibilities and who is able to affect decisions. This of course > means > > a paradigm shift moving away from "community liaisons" and into the realm > > of helping contributors to constitute themselves enabling them to take > up a > > shared ownership role without the need of a formal organization. > > > > I don't think the wmf is entirely responsible for making this happen, > there > > is also have to be a general will to embody such a spirit without > resorting > > to staff, hierarchies, or votes. The problem is that most of us live in a > > world that doesn't work this way, and the attached structural flaws are > > imported, when there is no need to. > > > > Anyhow, that should be something to speak about when the tensions have > been > > defused. > > > > Cheers, > > Micru > > _______________________________________________ > > Wikimedia-l mailing list, guidelines at: > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > > Wikimedia-l(a)lists.wikimedia.org > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> > > > _______________________________________________ > Wikimedia-l mailing list, guidelines at: > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> > -- Etiamsi omnes, ego non

On 14 August 2014 16:27, Richard Farmbrough &lt;richard(a)farmbrough.co.uk&gt; wrote: Although I concur with Erik's and WMF's actions in this particular case (and I really don't see how it could have worked out any other way), it's worth noting for the general case that local communities *do* need to be able to add local enhancements to MediaWiki - because the developers, WMF and volunteer, simply don't scale. This has been observable even for simple administrative actions that happen to require shell use, let alone adding new functionality. So locally-editable site JavaScript, for locally-important gadgets and so forth, is in fact something that's needed. This particularly applies to non-Wikipedia wikis that get no paid developer attention from WMF. Of course, in an ideal world this would be later reviewed and possibly centralised. But blocking it in general will immediately make Wikimedia sites worse, not better, in important ways. - d.

On 14 August 2014 20:27, Marc A. Pelletier &lt;marc(a)uberbox.org&gt; wrote: This is true, but prerequisite to what? What I'm saying is that switching off local scripting in general until [unspecified condition] is met is going to be an immediately bad thing for every WMF wiki that doesn't get lots of WMF attention, which is most of them. So that's a thing that shouldn't be done just because admins on two wikis are acting like my daughter just before I withdraw her computer access. - d.

On 14/08/14 16:07, Yaroslav M. Blanter wrote: It may be that specific teams, not just legal and whatnot but also including within engineering itself, are better at handling this sort of thing than others. Have there been any patterns with how well things go depending on who is involved? If so, perhaps the others could learn from them... -I

On Fri, 15 Aug 2014, at 09:47, svetlana wrote: confusing wording; i mean: they still coded it to go fullscreen nomatter what i wanted them to have a dialog of sorts instead

On Aug 14, 2014 3:58 AM, "Erik Moeller" &lt;erik(a)wikimedia.org&gt; wrote: Provided they're what you would have done anyway. Otherwise, they're "welcomed" with WONTFIX and superprotection. http://multimedia-metrics.wmflabs.org/dashboards/mmv_dewiki#opt_in_opt_out-… 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? 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?" 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. 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. 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 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. 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. 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". 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