[Wikimedia-l] Visual Editor "temporary" opt-out

Wed Aug 7 16:48:33 UTC 2013

Yes, it should be made clear that opt out will always be an acceptable user
preference.
On Aug 6, 2013 7:26 AM, "Todd Allen" <toddmallen at gmail.com> wrote:

> On Mon, Aug 5, 2013 at 8:35 PM, MZMcBride <z at mzmcbride.com> wrote:
>
> > Todd Allen wrote:
> > >[comments about VisualEditor]
> >
> > Hi Todd.
> >
> > Thank you for writing this e-mail. Unfortunately I don't have a
> > particularly unified reply to write here, but I can offer five thoughts.
> >
> > Regarding the specific issue you mention (the labeling of the user
> > preference), I think there should be at least a little recognition that
> > much more than half of the battle was getting this user preference
> > re-added, supported for future VisualEditor releases, and appropriately
> > positioned under the "Editing" user preferences tab rather than the
> > "Gadgets" user preferences tab. Now that we've made forward progress on
> > those fronts, re-labeling the user preference is a simple matter of
> > editing the page "MediaWiki:Visualeditor-preference-betatempdisable".
> >
> > Broadly, looking at your e-mail, I wonder what your thoughts are on the
> > extent to which one wiki, even the golden goose, can dictate Wikimedia
> > Foundation product engineering and development. While the English
> > Wikipedia is certainly a formidable force, do you think it should be
> > capable, through an on-wiki discussion, of setting or changing high-level
> > priorities and their implementation strategies? If so, why and how?
> >
> > I started
> > <https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Improvements> to
> > discuss actionable improvements that can be made right now related to
> > VisualEditor and its deployment. Please participate. :-)
> >
> > And I started <https://meta.wikimedia.org/wiki/VisualEditor/Complaints>
> to
> > examine the pattern of complaints related to VisualEditor.
> >
> > Finally, and somewhat related to the complaints page, I've been thinking
> > lately about the British and the Irish and the nature of insurgencies. I
> > believe the VisualEditor team is now viewed by many on the English
> > Wikipedia (and other wikis) as an occupying force. Consequently, this has
> > created an insurgency composed of long-time editors. This isn't meant to
> > be hyperbolic: nobody is rioting in the streets or planning warfare
> (yet).
> > However, the anger felt by many in the editing community toward the
> > VisualEditor team is very real and very worrying, as is the seemingly
> > heavy-handed way in which VisualEditor has been deployed. Just a few
> weeks
> > ago, VisualEditor was receiving accolades for the way in which it had
> been
> > slowly and thoughtfully developed and deployed. However, seemingly
> > arbitrary deadlines and a few key bad decisions have greatly hurt it. The
> > wounds are deep, but it remains to be seen whether they will be fatal.
> >
> > MZMcBride
> >
> >
> >
> > _______________________________________________
> > Wikimedia-l mailing list
> > Wikimedia-l at lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request at lists.wikimedia.org?subject=unsubscribe>
> >
>
> 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 at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request at lists.wikimedia.org?subject=unsubscribe>