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(a)gmail.com> wrote:
On Mon, Aug 5, 2013 at 8:35 PM, MZMcBride
<z(a)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(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@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(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>