
cunctator at gmail
Aug 7, 2013, 9:48 AM
Post #23 of 25
(85 views)
Permalink
|
|
Re: [Wikimedia-l] Visual Editor "temporary" opt-out
[In reply to]
|
|
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> wrote: > On Mon, Aug 5, 2013 at 8:35 PM, MZMcBride <z [at] mzmcbride> 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 > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > > <mailto:wikimedia-l-request [at] lists?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 > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-request [at] lists?subject=unsubscribe> _______________________________________________ Wikimedia-l mailing list Wikimedia-l [at] lists Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>
|