Op 2013/08/05 19:35, MZMcBride schreef: I notice you used the phrase "seemingly heavy-handed" above. Do you truly believe that this was not *actually* heavy-handed?

That is, the arguments tend towards saying "you can't philosophically prove there aren't supporters!" This is unconvincing for a number of reasons.

I cannot and will not blame the Wikimedia Foundation for working on this project. It's an important project

This leaves us to consider the biggest question: opt-in vs. opt-out. Erik and James are both quite smart, they are true Wikimedians, and they make reasonable points about choosing opt-out over opt-in.

On Tue, Aug 6, 2013 at 4:51 PM, Kevin Wayne Williams < kwwilliams(a)kwwilliams.com&gt; wrote: Opt-out with a beta or experimental notice (as it is now when enabled on en.wiki) doesn't seem to have the problem of presenting it if it were mature software you present as the pivotal problem in this post.

Op 2013/08/05 23:44, MZMcBride schreef: This is the point on which we fundamentally disagree. Their argument for 'opt-out' is based solely upon the quality and quantity of testing that it affords to VE. VE is not a mission-critical feature: while we have concerns about Wikipedia's sustainability, there's no question that it has survived for years and will survive for years more. The stability of the site is much more important than testing this code, and the testing strategy of presenting it as if it was functioning software and seeing what people did with it wasn't a reasonable decision: it was completely and absolutely irresponsible. KWW _______________________________________________ Wikimedia-l mailing list Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

Op 2013/08/06 9:07, Peter Southwood schreef: What do you need? Evidence that Wikipedia has survived for years? Evidence that its decline is not so rapid as to indicate an emergency situation? Quotes from Erik where he states that he disrupted English Wikipedia in order to create a test bed? The first two are judgement calls, for the third there's an embarrassment of riches. Let me know what you need. KWW _______________________________________________ Wikimedia-l mailing list Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

I've made no claim about "most" long-term editors, but any perusal of the two RFCs and the Feedback page would demonstrate that there's a fairly large group. Or are you arguing that deploying bug-ridden software that corrupts articles, hangs browsers, crashes unexpectedly, and doesn't have sufficient features to edit basic articles is somehow OK as long the site survives the disruption? Even if it can be shown that development knew that was the case prior to deployment, and chose to deploy it anyway? KWW Op 2013/08/06 10:54, Peter Southwood schreef: _______________________________________________ Wikimedia-l mailing list Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

Op 2013/08/06 13:05, Peter Southwood schreef: I think that's part of the problem: any change hits a nerve *somewhere*, so even when it's a real problem, observers are likely to dismiss it as being just more of the same. KWW _______________________________________________ Wikimedia-l mailing list Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

This perspective is not a productive one for building and maintaining a community. You need to have a better way of granting legitimacy to people's concerns while being able to discern histrionics. Generally the optimal easy is to have there be a pathway by which the complainants have to fix the problem to the satisfaction of their strongest opposition. On Aug 6, 2013 1:04 PM, "Peter Southwood" &lt;peter.southwood(a)telkomsa.net&gt; wrote: _______________________________________________ Wikimedia-l mailing list Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

On Mon, Aug 5, 2013 at 8:35 PM, MZMcBride &lt;z(a)mzmcbride.com&gt; wrote: to (yet). weeks been MzMcBride, Thanks for the response, and the thoughtful questions. Since they're rather different, I'll answer them in turn. My concern on the user preference is not what we call it. Rather, it's on what we intend to do with it; namely, remove it after the VE beta is "done" (and for many of us, WMF's project managers have shown remarkably poor judgment in properly determining what's "done" or "ready"). Even if VE worked well, I'm the type of person who uses a bash command shell in preference to a GUI most of the time (and go nuts when I'm required to use Windows for work), and I'm just not interested in the visual editor. For me personally, it's nothing I'll ever use. By all means, offer the GUI to whoever will find it useful, but I want a way to make sure it's not sucking up resources every time I edit. But despite this, once they say it's "ready", we're getting it crammed down our throats, like it or not. Even the name of the page, "betatempdisable", indicates that once again, the ability to disable this thing will be taken out of where it belongs, and once again volunteers will have to use their time to develop and maintain a gadget because WMF just can't resist saying "We say it's READY, and you will have it there whether or not you ever plan to use it!" As to "dictat(ing)" to WMF, well, in the most technical sense, no one has any say at all. WMF pays the bills and the devs, so WMF can, whenever it wants, override what en.wikipedia or any other project tells it. So we know WMF -can- override en.wikipedia, or any other project. The question, then, is whether they should. This is a volunteer project, where comparable to the user base, a relatively small group of volunteer users does the bulk of the work on creating and maintaining the site's content. Anonymous and drive-by editors are allowed to help, they often do, and that's appreciated. We should do what we can to make it easier for them to, but not at the expense of our long-term volunteers. What happens now is that those dedicated volunteers are called "power users", treated dismissively and sometimes flat rudely, and told they don't really know anything about how to run the project many of them have volunteered thousands of hours and in many cases their own money to. When even one of those volunteers reacts by packing up and leaving in response to such treatment, the project suffers a tremendous loss. Also keep in mind we're not just talking about en.wikipedia here. The second-largest project, de.wikipedia, also overwhelmingly chose to reject VE in its current state. So this isn't "en.wikipedia vs. all others", it's "WMF vs. all others". When your existing user base is telling you in large numbers "There's a problem here", you take them seriously, you presume you really do have a problem, and you genuinely listen to how they want to go forward on fixing it. And right now, anonymous and new editors are overwhelmingly rejecting VE, too, even when it was deceptively labeled. So, nutshell on that one: en.wikipedia shouldn't always "dictate" priorities or strategies, but if en.wikipedia and several other projects are saying "You screwed up" or "We badly need this", you don't just dismiss it as "power users" asking and handwave them away. Those "power users" are the core of your project. Overruling a genuine consensus of existing users, especially cross-project, should be vanishingly rare, yet I can recall three times just in the past year. WMF can do that, but it doesn't mean they should. Let me ask you a question in turn, then. If WMF decides to do something, or not to do something, that heavily impacts en (or de, or any other reasonably sized project), and the community overwhelmingly, through an on-wiki discussion, tells WMF "No, we don't want to go that way, we'd rather do this", what should WMF's reaction to that be? Thanks for the pointers to those additional pages, I didn't know about them. I think it would be a good idea for us to create a central page with links to all the VE-related stuff (unless such exists and I don't know of that one either :) ), because they seem to be spreading all over the place. That also might help prevent duplication of purpose. As far as your last paragraph, I don't see rioting in the streets (even on the metaphorical level) yet, but these overrides do cause a great degree of ill will. I actually saw people after the refusal of ACTRIAL suggest we use the edit filter to go ahead and implement it over WMF's objection, and they meant it. They were talked down from it, but they were every bit ready to get desysopped. At least a couple of them left over it anyway, making the point rather moot in their cases, and I'm kind of surprised one of them didn't "flip the finger on the way out". That would've been an awfully ugly showdown, and I'm glad it didn't happen that way, but it should show how seriously most people feel that no one at WMF is listening to what existing users want. Everything is "New users, new users, new users!", but then data doesn't even materialize to show these things -are- attracting new users. Yet we keep hearing about "silent majorities" that only the WMF knows the will of, and that the existing community is too dumb to comprehend. Yet when we ask "How do YOU know?", we either get data that's been heavily extrapolated, or anecdotes, or just told "Oh hush, you'll see". Was this tested in prototype with a group of non-editors, AND a group of editors? Were alternatives provided? Where are these tests' methodologies and their results? If the answer is "nowhere", how on earth does WMF claim to speak for this "silent majority" any more than the community can, many of whom deal with new editors day in and day out? The reason editors see this as invasive is because, well, every time WMF gets involved, they're doing whatever they already intended to do anyway, and not listening to existing editors at all. It's not just because new software or features were introduced--many Wikipedians, including myself, work in software or technology, and are quite used to and comfortable with new version releases. It's because WMF just plows ahead, and doesn't really make any effort to consult the community before developing its roadmap, nor are they willing to change course upon strong objection. On a project based on the ideals of collaboration and consensus, the biggest decisions are being made in a very dictatorial style. If you're asking why that doesn't go over well, I really don't know what to tell you other than "Well, of course it doesn't". Todd Allen -- Freedom is the right to say that 2+2=4. From this all else follows. _______________________________________________ Wikimedia-l mailing list Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>