Wikipedia talk:VisualEditor/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

→

Archive 8

Are there two feedback pages? That would be nice (1) new reader usage (2) experienced VisualEditor testers and bug report w/fixes.

I put the following section into the 'Feedback' article by following the top of the main page of Wikipedia— but I see this is another page of feedback.

It would be convenient to have everything organized, but people seem to put their views wherever they feel like. Whatamidoing (WMF) (talk) 13:08, 5 July 2013 (UTC)

Template

How do you remove or add templates with visual editor? Pass a Method talk 10:01, 3 July 2013 (UTC)

I've learned the answer is "You can't". It's so cumbersome and complex that it's best if you use "edit source", and continue the old ways of doing things. VE is not "template friendly" at all. doktorb _words^deeds 10:04, 3 July 2013 (UTC)

This is going to get a lot better; I've made clear the importance of it. But for the moment, I'd probably rely on source editing, yes. Okeyes (WMF) (talk) 10:15, 3 July 2013 (UTC)

Prepare yourself, User:Okeyes (WMF), prepare yourself.... doktorb _words^deeds 10:50, 3 July 2013 (UTC)

I've actually found templates not to be that difficult. Mind you, functionality still needs improvement and some of it is non-intuitive, like susbtitution. But see Wikipedia:VisualEditor/User guide for some screencaps. Apologies for the low value of some of those - I have very basic tech for image work. :) --Maggie Dennis (WMF) (talk) 13:23, 3 July 2013 (UTC)

The problem I have found (look in my contribs. at the Ynys Mon by-election), is the intuitive thing to do is click on the template and start editing. VE doesn't allow that. It calls on users to effectively memorise each and every line of template text, and that's hard enough with Windows 7 never mind without it. If you follow the second link in my note above, you'll see an even more complex template which VE simply can't handle. I'm not here raising pitchforks, User:Mdennis (WMF), just noting that at the moment you finding templates not that difficult is very much the exception! doktorb _words^deeds 15:43, 3 July 2013 (UTC)

It's possibly because I haven't used them for anything really complex yet - not more than a couple of parameters. --Maggie Dennis (WMF) (talk) 16:17, 3 July 2013 (UTC)

Ah ha! Then I fear you may make like Enya and sail away, sail away, sail away when you see what we Brits have coming up in a few months time.... doktorb _words^deeds 16:26, 3 July 2013 (UTC)

Yikes! I suspect I'd sail right away to the "edit source" tab. :D (I'd enjoy the soundtrack, though.) --Maggie Dennis (WMF) (talk) 16:33, 3 July 2013 (UTC)

Templates are edited with that puzzle-shaped icon. If/when someone has put the TemplateData in for your template, then you won't need to remember everything. Instead, it will give you a list of all the options. Whatamidoing (WMF) (talk) 13:07, 5 July 2013 (UTC)

Invisible comments

Tracked in Phabricator
Task T51603

Another bug or limitation: I have found that invisible comments are not visible when using the new editor. I suppose that was inevitable, since it is WYSIWYG, but are we simply abandoning that functionality? --MelanieN (talk) 14:31, 3 July 2013 (UTC)

Hi. :) According to this, no, but it's something they plan to work on after this wider beta release. --Maggie Dennis (WMF) (talk) 14:35, 3 July 2013 (UTC)

Is the plan is to switch all IP editors to VE before this functionality is added to VE? Because if that's the sequence, then a huge amount of the value of hidden comments (telling editors what they should or should not do, in specific circumstances) is gone. I really, really hope that this - and other problematical functionality - gets fixed before IP editors start using VE; IP editors are not needed to help identify problems (the stated reason for making VE the default for logged-in editors. (In other words, I hope "wider beta release" isn't another way of saying "full production implementation".) -- John Broughton (♫♫) 03:02, 6 July 2013 (UTC)

To my knowledge, it's not. We've delayed the IP release by a week, and one of the bugs I surfaced in the conversation of "are there any blockers" was "releasing to IPs without being able to note that one shouldn't change the lines in the article on Kashmir relating to ownership is asking for trouble". Okeyes (WMF) (talk) 03:39, 6 July 2013 (UTC)

RTL and BiDi

The deployment table at Wikipedia:VisualEditor#Timetable says 15 July is a maybe for RTL Wikipedias such as Arabic & Hebrew, and definitely deployed by 29 July. bugzilla:33126 currently indicates this core RTL functionality isnt fully developed yet, and a quick test on ar.wp indicates it's not quite polished yet. There are only a few VE edits per day on arwp. There does seem to be a bit more community testing happening on hewp, and the developer is active there with 46 edits: Special:CentralAuth/Mooeypoo. FWIW, we can test BiDi here on English Wikipedia, by adding RTL text in English pages where appropriate, and testing the VE on pages where RTL text already exists. See mw:VisualEditor/Bidirectional text requirements for some testing scenarios. John Vandenberg ^(chat) 02:55, 4 July 2013 (UTC)

Thanks for the suggestion.

(For those who are wondering, RTL means "right to left" and BiDi is "bidirectional".) Whatamidoing (WMF) (talk) 13:24, 5 July 2013 (UTC)

Wikipedia is slow

It is slower than usual. I think it could be the new applications in visual editor that slow it down. Pass a Method talk 05:16, 4 July 2013 (UTC)

Not to try and discredit you, but the new Universal Language Selector was enabled a couple of days ago as well, and that's what's causing most of the lag for me. Unlike the new VE, the ULS cannot be disabled or hidden at all. But I do understand your pain. Jguy _Talk^Done 05:30, 4 July 2013 (UTC)

We've done our best to speed up the VE; it now loads, instead of ~110KiB, 4KiB. Okeyes (WMF) (talk) 11:22, 4 July 2013 (UTC)

To put those numbers in context, VisualEditor's existence is responsible for about 2% (two percent) of the time that it takes to load a page (so that you can read it). Whatamidoing (WMF) (talk) 13:26, 5 July 2013 (UTC)

Keyboard shortcut changed and no longer works

Several times today I have been attempting to use the keyboard shortcut (Alt+Shift+E) to begin editting a page only to discover that since VisualEditor was introduced it was changed to Alt+Shift+V. However, this does not seem to be working at all in Firefox, and it is instead opening up Firefox's View menu.—Ryulong (琉竜) 07:30, 4 July 2013 (UTC)

As a note, every keyboard shortcut but the one for edit this page works, and I've turned off VisualEditor.—Ryulong (琉竜) 07:33, 4 July 2013 (UTC)

@Ryulong:: what version of the browser are you using? Okeyes (WMF) (talk) 11:23, 4 July 2013 (UTC)

22.0. However the shortcut seems to be working today, when it was not yesterday.—Ryulong (琉竜) 05:49, 5 July 2013 (UTC)

Other laptop in use. Now the tooltip for editing says accesskey-ca-editsource.—Ryulong (琉竜) 10:16, 5 July 2013 (UTC)

Tracked in Phabricator
Task T52725

I've got the same problem in both Firefox 22.0 and Safari 6.0.5. It shouldn't be saying <accesskey-ca-editsource>. It should be saying [ctrl-option-e] (with square brackets). It should also actually work when you press the right keys. It looks like the fix has been written. The devs don't like to put up new code just before the weekend, so perhaps it will appear for us on Monday. Whatamidoing (WMF) (talk) 13:32, 5 July 2013 (UTC)

HTML editor?

From the project page, "We currently struggle with making the HTML we produce look like what you are used to seeing, "

So what are we editing here? A wiki, or a HTML web page? The point about wikis is that they separate content and presentation (far more than even HTML 4.01 ever did). Presentation is not an issue for wiki editing (in general), for MediaWiki, or for editing at WP. Just leave the default formatting alone, and let MediaWiki deal with it. We do not (in over 99% of cases) need to mess with the default rendering, presentation and skinning. In those rare and complex cases when it is needed, then it's (by its nature) both complex to achieve and rare to need. Is this HTML focus in the new Visual Editor an indication that WMF are also trying to move away from default MediaWiki behaviour, towards some sort of Frontpage clone where any editor can trot along and start playing with the presentation, just for the hell of it? How can that possibly be a good direction to go in? A "Visual Editor" needs to make competent wikitext, same as any other editor, and it should not go beyond this. If someone really does need formatting control beyond this, then that's expert territory (and WP editors, including template editors, have historically been bad at this) and needs expert CSS knowledge. Anything less than expert, and MediaWiki probably does it just as well all on its own. Andy Dingley (talk) 15:13, 4 July 2013 (UTC)

I'm not entirly sure but I think this refers to the HTML that is produced vor the live preview. I just edited a Infobox via the Visual Editor and the live preview didn't render the image inside the infobox after that. I highly doubt that it would be possible for the editor to mess with the underlying HTML/CSS. Hobofan (talk) 18:10, 4 July 2013 (UTC)

What you see on your screen is actually HTML. In the old system, you write in wikicode, and Mediawiki turns it into HTML for readers (including for previews when you're editing). In the new system, you make changes in a rich text environment, and it still eventually ends up in wikicode and then HTML.

What I'm overhearing is that getting some of the less common details of this "translation" to work perfectly is gong to require re-writing the Monobook and Vector skins. In the meantime, what you see in VisualEditor mode is almost, but not quite, what you'll see when you save the page. Whatamidoing (WMF) (talk) 13:38, 5 July 2013 (UTC)

Two Related Problems with Roll-Out

I have stated my concerns about the roll-out of the Visual Editor at Wikipedia:Village pump (technical)#Unsound Testing Approach with Visual Editor. I have two related but separate concerns. First, the decision to deploy Visual Editor first in article space rather than in user space was well-meaning, but it was a blunder. In article space, "test edits" are forbidden, and there is even a template to warn users who make test edits. Since test editing in user space is not permitted, every edit is an unwitting test. It is true that the need for a user-friendly editor was greatest in article space, but for the same reason, the need for a reliable editor is greatest in article space. Rather than initially deploying it to article space, where it and its bugs are highly visible, it should have been deployed to the sandbox of user space. Second, unless I am mistaken, there was no managed test organization as a branch of the development unit. Should this discussion be conducted here, or moved to Village pump (technical), or continued in both? Robert McClenon (talk) 18:06, 4 July 2013 (UTC)

There's generally not good reason to duplicate a discussion, but certainly it would seem appropriate in either. --Maggie Dennis (WMF) (talk) 19:54, 4 July 2013 (UTC)

In the development organization who put together this tool, is there a separate unit for testing the software, before it is turned over to regular editors? Robert McClenon (talk) 20:12, 4 July 2013 (UTC)

The decision to turn the tool over for use in article space without extensive testing in user space was an unsound decision. There wasn't a deadline. The turnover has alienated some experienced users whom we should want to retain. At this point, I can't see that the tool has reached the intended quality where it will enable us to keep new editors who were put off by the Wiki interface. Robert McClenon (talk) 20:12, 4 July 2013 (UTC)

It might not be good enough—yet—but I think we'll get there. New editors are also able to use the old editing system if they want. From the look of the RecentChanges page, many of them are doing so. Whatamidoing (WMF) (talk) 19:31, 5 July 2013 (UTC)

Where is the FAQ or manual?

Is there an FAQ or manual for Visual Editor? I am trying to test it using Firefox (since it doesn't support IE9 for now). If I click on Edit This Page, it changes the appearance of the page, but then if I try to position the cursor to insert a comma, I don't see a focus cursor, and inserting a comma doesn't do anything. Maybe the explanation is crystal clear in the manual, but it isn't intuitive to an experienced IT engineer if the screen doesn't look editable. I am skeptical that a user interface that is unobvious to engineers should be intuitive to the non-tech-savvy users who appear to be the target audience for this "feature". Robert McClenon (talk) 19:49, 4 July 2013 (UTC)

Hi. :) There are both - the FAQ is reproduced at the top of the Feedback page and linked from the top of this one. The user guide is linked from both. I don't think, however, that you're going to find an answer to that question in either - that doesn't sound to me like something that should be happening. Can you tell me what operating system you are using and what article you're editing? --Maggie Dennis (WMF) (talk) 19:53, 4 July 2013 (UTC)

What doesn't sound like something that should be happening? I was trying to insert a comma. Is that something that isn't supported? I am using Firefox and Windows 7. Robert McClenon (talk) 20:00, 4 July 2013 (UTC)

I see what the problem is, now that I look at the User Guide. First, it isn't intuitive anyway. Second, it is too slow. It takes too long to enable a non-trivial page for visual editing. Its performance is unsatisfactory, at least for engineers who are accustomed to the current Wiki interface. Robert McClenon (talk) 20:05, 4 July 2013 (UTC)

Also, although there is a lot of help on specialized edits, such as to links and references, I don't see help on general edits to add, replace, or delete text. Robert McClenon (talk) 20:08, 4 July 2013 (UTC)

More on slowness

I was using Firefox and Windows 7. When I click the Edit This Page tab for any substantial article, it takes a very long time to enable editing, long enough so that, if one isn't paying attention, one thinks that nothing is happening. Only in the upper right corner does the rolling progress bar indicate that something is happening that accomplishes nothing anyway. In particular, for several articles, it took more than 30 seconds, which is unsatisfactory. For the article on Atlanta, I clocked that it did not enable editing after four minutes. I have a few questions. First, is it really taking an excessive length of time to enable editing, or does editing never enable with Firefox and Windows 7? (I realize that the answer to this question may be formally undecidable as the Halting Problem.) Second, is there a mechanism for reporting this issue, which clearly is a problem? Is it already in Bugzilla? Do I report it to you to enter in Bugzilla? Can I enter it in Bugzilla? Robert McClenon (talk) 20:29, 4 July 2013 (UTC)

I then tried to edit Republic of Texas, and gave up after one minute. I then tried to edit Interplanetary contamination, a small article. I gave up after two minutes. Has it been verified that editing is actually possible with Firefox and Windows 7, or is that only thought to be a supported feature? Robert McClenon (talk) 20:37, 4 July 2013 (UTC)

Long articles can definitely be somewhat slow to edit, but a four minute wait sounds like a different kind of performance issue. By way of comparison, the same article takes about 14 seconds to switch into edit mode for me on Google Chrome / Ubuntu (6-year-old 2Ghz desktop) and about 20 seconds in Firefox 20 on the same machine.

Can you give some more background on browser version and the hardware you're using? Also, does the performance issue persist if you try editing the same page repeatedly?--Eloquence* 20:37, 4 July 2013 (UTC)

I am using Windows 7 on a four-core Dell, and am using Firefox 12. I don't have the exact speed, but it is between 3 Ghz and 4 Ghz. Robert McClenon (talk) 21:39, 4 July 2013 (UTC)

Repeatedly clicking Edit This Page has no effect. That is, the progress bar continues to cycle. I have a question. Has anyone successfully used the Visual Editor with Firefox 12? Maybe a version list of versions of Firefox is needed. Robert McClenon (talk) 21:45, 4 July 2013 (UTC)

Firefox 22 works. It takes up to 15 seconds to enable editing of a large article, which is not unreasonable. It takes a few seconds to enable editing of a small article, from which I was able to delete a stray comma. A bug should be entered concerning Firefox 12. If it takes more than two minutes on a small article, then the most likely explanation is that it is failing to timeout. (The Halting Problem cannot be solved analytically, but closed loops or failure to detect timeouts can be observed.) Robert McClenon (talk) 22:04, 4 July 2013 (UTC)

Please also inform Firefox users that they need to update to the most recent version of Firefox, which is currently 22. Robert McClenon (talk) 22:04, 4 July 2013 (UTC)

Tracked in Phabricator
Task T52780

@Robert McClenon: Thanks for the report! I've confirmed that Firefox 11-12 should be added to the blacklist for the time being. Once that is done, those versions of the browser will only offer markup-based editing.--Eloquence* 01:24, 5 July 2013 (UTC)

I would suggest that users with back-level versions of other supported browsers, such as Chrome and Safari, be asked to see whether their back-level browsers are unsupported, and should be blacklisted. Robert McClenon (talk) 17:10, 5 July 2013 (UTC)

Doing a null edit to the Infobox of Republic of Texas resulted in this #dataloss bug. Reopened bugzilla:bug 50102. John Vandenberg ^(chat) 13:11, 5 July 2013 (UTC)

Template:Answered on Feedback page

Hello. :) I'm busy adding {{answered}} to the feedback page. The point here is to help identify material that is still being discussed or that has not been fully responded to. If you happen to notice a section that has been properly processed, your help doing this would be most welcome. This is easily done - you put {{answered | text = in front of the section and }} behind it. One caveat: this template hates [edit | edit source], so I just have to drop <nowiki> tags around it.

Some of the open sections may still archive for staleness, but my goal here is not to inadvertently close something prematurely. If I do, please feel free to just remove the code. You can add new notes below the colored box as the template advises, but I would in that case probably add {{unresolved}} to the top. We may overlook those notes in scanning for unresolved sections. :)

Thanks! --Maggie Dennis (WMF) (talk) 19:51, 4 July 2013 (UTC)

Any pipe or equals sign irritates pretty much every template. You can use {{!}} to replace pipes and {{[[Template:{{{1}}}|{{{1}}}]]}} to replace equals signs if you want, or the nowiki approach will also work. Whatamidoing (WMF) (talk) 13:46, 5 July 2013 (UTC)

Tables

First off, I am a highly experienced Wikipedia editor and I love the new editor. It is far from perfect, but honestly, the fewer barriers of entry for editors to add their knowledge the better.

That being said, I personally find tables difficult to work with even as an experienced editor. That should definitely be in version 2.0. Thanks. Oldag07 (talk) 11:16, 5 July 2013 (UTC)

As far as I know, the tables are in the schedule. Don't know for when but, they are working on them. TeamGale (talk) 11:29, 5 July 2013 (UTC)

Thanks for the lovely note, Oldag07 :). I definitely agree tables need to be worked on, and they are; I'm really looking forward to it. I've been here since 2005 and I don't think I've ever understood tables fully (the help page is terrible, to boot). Okeyes (WMF) (talk) 13:34, 5 July 2013 (UTC)

No wiki bug?

Dunno if it has been reported and am not look through all the posts above, see here for example. Am now off to fix that. Darkness Shines (talk) 16:08, 5 July 2013 (UTC)

Thanks, Darkness Shines :). Looks like someone attempting to insert markup; we have a bug around for warning users when they do that. Okeyes (WMF) (talk) 16:12, 5 July 2013 (UTC)

Nondescriptive error codes

The VisualEditor extension currently gives very cryptic error messages. In fact, they are so cryptic that I can't even tell what they are referring to. See the two examples below:

Error: The modification you tried to make was aborted by an extension hook

Error: Invalid error code

The first is caused by triggering the edit filter, while the second is caused by hitting the spam blacklist. A new editor will not have a clue what is going on—he will assume the editing software is buggy. The visual editor needs to display the warnings associated with the edit filters and the spam blacklist. Thanks. Reaper Eternal (talk) 19:43, 5 July 2013 (UTC)

The new editor will assume that the edit software is buggy because the edit software is buggy. (Even with your explanations, I still don't really understand, and I'm an IT engineer.) Robert McClenon (talk) 19:51, 5 July 2013 (UTC)

Tracked in Phabricator
Task T52826

Tracked in Phabricator
Task T52828

Thanks for the helpful note, Reaper. (If VisualEditor is giving such a useless error message on the spam blacklist, then it is buggy, so the editor's assumption would be valid.) Whatamidoing (WMF) (talk) 19:53, 5 July 2013 (UTC)

Although VE seems to have been turned off for me, before most of my edits were getting the second error, even though I didn't add any external links. Why?--Gilderien Chat|List of good deeds 19:57, 5 July 2013 (UTC)

It looks to me (a non-technical person) like this is a generic "Oops, something went wrong, but I don't know what" error message. There could be any number of problems that trigger it. If you can remember any specific edits that produced this, I'd love to hear about them (a diff, maybe?). Whatamidoing (WMF) (talk) 19:59, 5 July 2013 (UTC)

Most recently, this and this.--Gilderien Chat|List of good deeds 20:05, 5 July 2013 (UTC)

Double tags?

Hey, just a quick question, what is the significance of the two VisualEditor tags (the normal one and a separate "Check" one) in this edit? Did I miss something? Or is this just for debugging and the like? Theopolisme (talk) 17:39, 1 July 2013 (UTC)

That looks like....some kind of bug I've never seen before. How weird :/. I'll look into it; thanks for bringing it up! :). Okeyes (WMF) (talk) 18:56, 1 July 2013 (UTC)

Very late to the answer: it's feature, not bug. That's a system generated tag that says that VE believes there's something unbalanced in the wikimarkup. Philippe Beaudette, Wikimedia Foundation (talk) 15:54, 6 July 2013 (UTC)

"Switch off" option

Can someone check the Gadgets menu? I am trying to switch it off, and I've discovered that in the latest Firefox, the option to switch off Visual Editor doesn't even appear, as with Internet Explorer, but it appears in Chrome and Maxthon3. Weird. Orderinchaos 06:17, 3 July 2013 (UTC)

Ookay, that's strange :/. When you say latest - 22.0, or are you using nightly? Okeyes (WMF) (talk) 06:40, 3 July 2013 (UTC)

I'm not having that problem. Are you sure it's missing? Preferences-->Gadgets-->Editing Section and it should be the first selection there.--Mjs1991 (talk) 07:06, 3 July 2013 (UTC)

Strangely, it is now! I even crossreferenced when I found it in Maxthon 3 to make sure I was looking at the right section and the menu was the same other than that option being missing. Wish I'd screenshotted it. Orderinchaos 15:21, 4 July 2013 (UTC)

I have firefox and it did turn off (thank universal consciousness). I hope new editors are finding it useful but it drove me insane the first few times tried to use it. Of course, if I want to do another new editor workshop I'll have to break down and learn it. (Getting a headache already.) 'CarolMooreDC - talk to me🗽14:50, 6 July 2013 (UTC)

Not learning

After the notifications issue, we now get another piece of software that hasn't been tested. I've only got a middling amount of pages on my watchlist, but I can count a pretty good amount whose last edit was "fix Visual Editor fault" or similar. If my company had released stuff this bug-ridden, the people responsible would have been fired. Please sort it out, preferably by turning of VE until it actually works. Black Kite (talk) 19:50, 3 July 2013 (UTC)

Hi, Black Kite. VisualEdit has been being tested for over six months now, including fairly intensely on English Wikipedia for weeks before rollout. WMF is relying on the community to help with VE as an integral part of this process - Linus's Law. This is particularly important given the complexity of our project, our user base, and the relatively small number of staff. Google has over 7,000 engineers who have profiles on LinkedIn alone. I think we have just a bit over 170 employees in all departments. Pretty massive difference. :) Beyond the invaluable help of the community in locating and fixing bugs, it's also been extremely helpful having them suggest enhancements and changes to the way VE works. But the WMF recognizes, of course, that not everyone wants to take part of this, and use of VE is optional. --Maggie Dennis (WMF) (talk) 20:30, 3 July 2013 (UTC)

So now that the foundation has lots of bugs / issues to work on we can now allow people to turn it off completely if they so wish? And we will stop rolling it out any further until these are address, yes? Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:50, 4 July 2013 (UTC)

The options there are the same - people are free to ignore it completely or to use the gadget to hide it. I think the developers are continuing the break-neck bug-repairing spree. --Maggie Dennis (WMF) (talk) 00:58, 4 July 2013 (UTC)

James, you've said that you've already turned it off, so why are you asking whether doing so is "allowed" now? Of course it's allowed: you already did it. What's not allowed is for you to take the option to use VisualEditor away from other people. Each user gets to make his (or her) own choice, even if their choice is different from yours. Whatamidoing (WMF) (talk) 13:21, 5 July 2013 (UTC)

I think he's suggesting it should be opt-in rather than opt-out. In general, that is a very good philosophy as it takes the sense of compulsion and "you will respect my authoritah!" out of it. Orderinchaos 08:51, 6 July 2013 (UTC)

Change is rough

I am a little puzzled by the tone of some of the comments here and elsewhere on the project regarding VE. By its nature, change is disruptive, but this one isn't that hard to manage for experienced users. This change was declared and had a pilot, but the heterogeneity of the community (and the tools they use) made roll-out likely to be problematic. We're all working on the same project, let's work like a team with no deadline. -- Scray (talk) 16:24, 2 July 2013 (UTC)

I got a bit of a shock just now when I hit the edit button and something completely unexpected happened. I hadn't heard about it at all :) Let's see how it goes anyway. Could make life easier, you never know... Thanks  — Amakuru (talk) 16:53, 2 July 2013 (UTC)

My solution was to disable Visual Editor as soon as I could figure out how to do it. I also don't believe in making it easier for neophytes to edit Wikipedia without the need to learn Wiki Markup Language; all it is likely to do is allow articles to be messed up more efficiently than ever before by people who don't know what they're doing. — Quicksilver^{T @} 17:46, 2 July 2013 (UTC)

Good observation, Scray. Well put. Keegan (WMF) (talk) 17:58, 2 July 2013 (UTC)

The problem is the WMF isn't working as a team with us. They want us to say what a great tool VE is and pat them on the back. We have been telling them for weeks/months the software wasn't ready but they refuse to listen and rushed out this half assed broken code anyway. I like the idea of VE and I think its coming along and has a lot of potential. But it is a long way from being ready for release. Kumioko (talk) 18:15, 2 July 2013 (UTC)

I promise, that's not at all what they're looking for. They wouldn't have employed 24 hour coverage for that. You can receive kudos at any time. :) They are relying on the community to help as an integral part of this process - Linus's Law. This is particularly important given the complexity of our project, our user base, and the relatively small number of staff. Google has over 7,000 engineers who have profiles on LinkedIn in the US alone. I think we have just a bit over 170 employees in all departments. Pretty massive difference. :) --Maggie Dennis (WMF) (talk) 18:33, 2 July 2013 (UTC)

And I don't think most people are saying there can never be a VE, at least I'm not. But we need one that doesn't mysteriously delete content or perform changes that were't expected, Only works in 2 namespaces, encourages users to not add citations, etc. We have waited this long for it, a couple more months to make sure more of the bugs were fixed would not have been a bad thing. The WMF made it optional from December 2012 - June, most people didn't know about it until May and some didn't find out till today. Plus the WMF just rushed out and hired a bunch of people to support the rollout at the last minute because they knew they were going to get a hailstorm. I cannot even begin to go over all of the areas were the WMF failed in this development cycle. Kumioko (talk) 19:14, 2 July 2013 (UTC)

This could have been handled better. Way better. Yes, you want testers, beta periods are nice. But never in my 10+ years of software/hardware/product development and support have I ever forced a beta version to everyone and told people to just "deal with it". You release the beta to a handful of people, especially with something that is breaking content left and right. This does not improve Wikipedia. This does not help Wikipedia. Don't get me wrong. I'm all for a new editor! Bring it on! It sounds great! I'd love a new way to edit pages. But to force a clearly broken editor onto people is wrong. If it was working better and didn't include over 300 bugs then people might have been a little more excited about it, and a bit more accepting of the change. But as it is, you have crippled what we're here to do. It may recover, but the trust is honestly lost here. Kumioko is right here, this is great, but it's a long way away from a site-wide release. Jguy _Talk^Done 20:12, 2 July 2013 (UTC)

"Crippled", really? Click "Edit source" or just disable as has been outlined above. No one is being forced to use VE. It'll get better. I know it could've been implemented better, but I don't see much value in hyperbole. -- Scray (talk) 20:50, 2 July 2013 (UTC)

I wonder how many editors who don't deal with wiki-politics know that there is a way to use the old editor. SL93 (talk) 22:17, 2 July 2013 (UTC)

I just looked at Special:RecentChanges for logged-in users, and less than 5% of edits were made with VisualEditor. So I'd say that at least 95% of registered editors have figured it out, which is a lot more people than follow wiki-politics. Whatamidoing (WMF) (talk) 05:32, 5 July 2013 (UTC)

I would call it crippled. I see many many many talented editors that have been here far longer than I have just up and leave. While it might not be forced on us right now, for a short time it was. Only until people complained and started quitting did the WMF finally add an option to hide the editor from the interface (if I recall, it was at least 2-3 hours after the switch was pulled). I don't really think people have a problem with the VisualEditor itself (besides the bugs), I think the problem is the way it was presented and then implemented (at least that's what I have a problem with). A lot of editors stated that they did not see any notices about it, including me, and it was later confirmed that a cookie issue might have been to blame. I understand that technical issues/changes from the WMF don't have to have consensus, but in this case, that rule should have been ignored as it directly disrupts the improvement of the encyclopedia (the editor having 300+ bugs is pretty related to the improvement of the encyclopedia). While the disruption might not be long term, there is (still) no clear indication anywhere of how to hide the VE for those that can't or don't want to use it. People still have issues hiding it or finding where to hide it. Also keep in mind that it only hides the button. All the code, javascript and backend stuff is still loaded, so the interface slows down even more. I understand that it will get better. With the amount of feedback that WMF is getting it's a given. I, as well as seemingly countless other editors, feel that it would have been best to wait for a massive rollout such as this, given the amount of criticism that the WMF has been taking. Jguy _Talk^Done 23:24, 2 July 2013 (UTC)

Could you point me to those editors who are upping and leaving, please? I'm happy to talk to them. As it happens, I agree with you; I would have been more comfortable waiting before we rolled out on such a large scale. But ultimately, as Maggie says above, Linus's Law is the goal; yes, we have 300 bugs, but a lot of those simply wouldn't exist if we didn't have a ton of practical feedback from Wikimedians such as yourself, and a lot of that feedback wouldn't exist without a wider rollout. Now, would I choose to use it as the default editor? Well, no, but then I'm still on monobook. Can it be used as the default editor? Yes, already; we have editors who have written entire articles just with the VE. Now our job is to make it better. Okeyes (WMF) (talk) 06:12, 3 July 2013 (UTC)

Actually, no, those bugs would exist. They just wouldn't have been identified. :) The thing about Linus' Law is that it applies to a combination of two factors - many beta testers + many people with access to source code. The beta testers spot the bugs, it is true, but the many people with access to the source code is what makes them disappear. What we have here is a small team of developers desperately trying to fix in real time on a live product a large number of bugs. Many eyes, in this case, does not make bugs shallow - it just makes a lot of anger and a very long list of problems. - Bilby (talk) 15:44, 8 July 2013 (UTC)

Avoiding confusion about the "edit" and "edit source" tabs

I wanted to edit an article the "OLD" way.

At first I thought (based on something I had read, quickly) that, in order to (ever!) allow myself to do so, (in order to edit the "OLD" way -- even ONE TIME), I had to edit my "Editing" preferences under "Gadgets" on some "Preferences" page.

I later found out that that was wrong, but meanwhile I had already done so, and it took me a lot of reading, to figure out that, instead, I could have clicked on "edit source" instead of "edit" -- for a ONE-TIME (temporary) decision to edit the "OLD" way. One of the reasons it took me so long, was because I did find some mention of "edit source", but -- Aha! -- when I looked at the top of the page, there WAS NO "edit source" link!

Even after I put my Preferences/Gadgets/Editing BACK to normal, there was still no "edit source" link at the top of the page. (on certain pages). This (it turns out) was due to some good reason, but it took me a while to figure out what was going on. Eventually, I figured out that now I still would not ALWAYS see BOTH the "edit source" AND the "edit" links at the top of the page -- due to some reasons which (IMHO!) are confusing.

For example, apparently things work differently on "Talk:" pages, and I think also on pages like http://wiki.riteme.site/wiki/Wikipedia:VisualEditor which are part of some different name space or something.

It took me a while (and a lot of reading) to figure that out (and maybe I still don't understand it right.)

Meanwhile, I kept RE-trying to change my Preferences/Gadgets/Editing BACK to normal, because it seemed like it was not working, because there was still no "edit source" link at the top of the page. (on certain pages).

I still do not understand it well enough to be the one to edit the "intro" page to explain things so as to help others avoid this strange type of episode.

IMHO the links at the top of the page are confusing. Maybe (?) things would be less confusing, if the "edit source" link, (or is it the "edit" link?) when it's disabled, were to still appear, but to appear "grayed out" -- indicating that it's disabled. Maybe (?) it would also help, (to be less confusing), if the "edit source" link were to be displayed as "edit source", when appropriate, (that is, when it means "edit the OLD way"), -- EVEN when on one of those pages (mentioned above) where the new type of editing (visual editing) does not exist [yet] -- "at all".

Now, I think it [the "edit" link] is still displayed as "edit" (which some users / editors, might assume means something different from "edit source") on those pages. (But, I could be wrong. I might still be sorta confused...)

Any advice would be welcome. --Mike Schwartz (talk) 16:30, 5 July 2013 (UTC)

That makes a lot of sense. We were also thinking of changing it to read "edit source" instead of "edit" in all namespaces, to avoid problems with muscle memory. Thoughts? Okeyes (WMF) (talk) 16:33, 5 July 2013 (UTC)

I think that would be an improvement, yeah. --j⚛e decker^talk 16:35, 5 July 2013 (UTC)

Thanks -- for that very prompt response. Also, I recommend for someone (not me) to "consider" modifying the page that talks about changing your "Preferences/Gadgets/Editing" to disable visual editing. I think that page should make it clear (umm, even "more" clear?) that it's NOT the only way to enjoy the possibility of EVER editing the "OLD" way ("maybe just this once"). (Or, was I the only one who read it too quickly and got the wrong idea?) --Mike Schwartz (talk) 16:42, 5 July 2013 (UTC)

Hi Mike, you're probably not the only one who got the wrong impression. Would you take a look at it now, and tell me if that makes more sense? Whatamidoing (WMF) (talk) 16:53, 5 July 2013 (UTC)

• I personally think it should say "Edit" and "Edit with VisualEditor". Also, I object to this being called a beta - betas are supposed to be mostly feature-complete, and this isn't; thus, this is an alpha. But that's another story. Lukeno94 (tell Luke off here) 18:54, 5 July 2013 (UTC)

Reply from Mike Schwartz (in general, "and" to Whatamidoing (WMF) (talk) 16:53, 5 July 2013 (UTC)):

If you mean (edits such as) WAID_edit_1 and WAID_edit_2 then I agree that those are a step in the right direction.

However, IMHO it would be appropriate to go even further. The millisecond we mention the word "all", (as in [the second-to-last word of] "Both VisualEditor and the older wikitext editor are automatically available for all registered users on all articles."), the specter of the possibility of misunderstanding begins to flourish.

IMHO the wording should be (something more like)

"Both VisualEditor and the older wikitext editor are automatically available for all registered users on certain pages -- currently not including "Talk:" pages, but including any article -- (that is, any web page that is in so-called "article" space)." See below (under) "* Articles and User pages only" for more details about that.

Also, IMHO we need more explaining, some place (maybe right near the above?) about the fact that, on some pages (certain pages, such as [currently] "Talk:" pages), the "edit" tab does [means] what is now associated with [that is, what is done by/"meant" by) the "edit source" tab on other pages. Since when is that so obvious that the reader should already know it? (Sorry! no insult intended -- to anyone. I just hope to spare some future "wannabee editors" from, umm, some of the confusion and misunderstanding which I know [by my own first hand knowledge] is possible.) (Plus, maybe it does say that somewhere -- either some place that I missed, or some place that has been added "recently").

I realize that, with future improvements, we may live to see the day when someone can look at a tab near the top of the page, and have some easy way to [be able to] tell whether it means "edit by editing the wikitext (also known as, the 'OLD' way)", or whether it means "edit by using the visual editor (a 'NEW' way -- which might be a bit of a 'rude awakening', for 'some' veteran editors)". However, until then, I think we need to do more to make it clear that, -- for now -- one has to sorta determine which "KIND" of page one is on, and then [know to] translate from the name of the tab to the meaning, in a context-dependent way.

Whoa, I just realized, that this -- (determining which "KIND" of page one is on, for puposes of this discussion) -- can be done [now!] pretty easily -- just by just checking whether [A] the page has only an "edit" tab, or [B] the page has both an "edit" tab, and an "edit source" tab) (!) (We probably should SAY that... :-) ).

But IMHO, the reader still needs to be told that [T1] something like this (determining which "KIND" of page one is on) needs to be done, and that [T2] if there *is* no "edit source" tab, on a given page, then -- for now at least -- on that page, "edit" means "edit source".

Sorry this was so long. It probably could be made shorter, but I was putting more priority on careful use of language, and I don't have more time right now, to improve it.

Thanks to everyone for their patience and kindness. --Mike Schwartz (talk) 20:42, 7 July 2013 (UTC)

That makes sense. I think the next thing to do is to find out the status of a related proposal, which is to change all of the 'edit the old way' tabs to say "Edit source", even if there is no VisualEditor on that page. It would be so much simpler to just say "if it says just plain "Edit", then it's the new thing, and if it says "Edit source", then it's the old thing." Whatamidoing (WMF) (talk) 22:35, 7 July 2013 (UTC)

Beautiful!

I've not been a very active Wikipedia editor for the last few years, but used to be. I just noticed the stumbled upon this by noticing the new "edit source" links, and just had to stop by and congratulate the project! I've only tested it briefly, and I'm sure there are lots of things left to fix, but the basic functionality seems just right to me and I'm very happy to see that a lot of consideration seems to have been put in making references editing simple. Regards, /skagedal^talk 06:43, 8 July 2013 (UTC)

@Skagedal: thanks for the lovely note! We've still got a lot of things to improve with it, as you note; I'm glad to hear it's already been of benefit to you, though :). If anything breaks or goes all Apocalypse Now on you, please do feel free to drop a note here or on my talkpage - we love finding new bugs to bother the developers with ;). Okeyes (WMF) (talk) 10:57, 8 July 2013 (UTC)

VisualEditor deployment patterns

@David Gerard: asked this question initially, but I thought I'd post the answer here, since a wider pool might be interested in the answer. The question was "what sort of schedule does the VisualEditor team deploy on? How often, and when?" or words to that effect. The answer, via James F:

Quick answer is "as often as possible"; in general, this means we're hoping to keep up daily deployments if/when we get fixes made and can push them. In practice, WMF isn't set up for really proper rapid deployments (yet), so instead we're limited to four days a week (no weekends, no Fridays), normally towards the end of the day SF-time, unless there's a critical emergency. Note that "critical emergency" status is not something I get to decide. :-)

Hopefully this answers David's question (and is of interest to others, too :)). Okeyes (WMF) (talk) 10:56, 8 July 2013 (UTC)

Yes, thank you! - David Gerard (talk) 12:19, 8 July 2013 (UTC)

Visual Editor turned off links to references in an article I edited

Tracked in Phabricator
Task T51396

In the most recent edits I made to another article (today, July 8, 2013), it didn't keep the html links to the references at the bottom of the article. Will someone with more Visual Editor knowledge than me please fix this? Thanks. Damon Killian (talk) 17:30, 8 July 2013 (UTC)

Hi Damon,

Are you talking about this change to Nik Richie? Did you happen to use cut-and-paste to move this text? Whatamidoing (WMF) (talk) 18:50, 8 July 2013 (UTC)

Yes and yes. Damon Killian (talk) 19:03, 8 July 2013 (UTC)

Thanks for your quick reply. That happened to me yesterday when I tried to rearrange a page.

I believe that it's T51396. The bug report says that it only causes a problem if the ref is at the end of what you're copying. Of course, since most refs are at the end of a sentence, that's a real problem, and that's why it's a high-priority bug. Here's hoping that it will get fixed soon! Whatamidoing (WMF) (talk) 22:11, 8 July 2013 (UTC)

VisualEditor error. Adding brackets around something to turn it into a wikilink blocked

When I used it to simply add double brackets around something to create a link to that article, it automatically added nowiki tags around a chunk of text, so the link didn't appear [[1] Dream Focus 03:47, 9 July 2013 (UTC)

For better or worse, this is "working as intended" (for now, at least). VisualEditor does not support the addition of wikimarkup. You cannot add double brackets to make a link. If you want to add a link (internal wikilink or external URL), you have to use the built-in link tool (ctrl-k in most PCs and command-k on Macs). Whatamidoing (WMF) (talk) 04:10, 9 July 2013 (UTC)

A Very Big Issue

No! Don't remove the old editor! The new one can't edit equations, or templates!.Dimension10 (talk) 07:35, 29 June 2013 (UTC)

Not aware of any plans to do that. Click "edit source". Apteva (talk) 22:14, 1 July 2013 (UTC)

@Apteva: template editing is present, and has been for quite some time; maths editing (as has been said on this page) is coming. Okeyes (WMF) (talk) 07:17, 9 July 2013 (UTC)

I'm sorry but I prefer the old editor then this new one. Matt294069 (talk) 09:21, 3 July 2013 (UTC)

You can still use the old editor, then; see Apteva's advice. What do you dislike about the new interface? Okeyes (WMF) (talk) 09:34, 3 July 2013 (UTC)

My first go-round with Visual Editor featured difficulty with creating a reflist (one of the articles I was editing had none at all) and embedding references. I fiddled with the task for an hour or so, hoping I'd just committed a stunningly simple oversight, then went to a less needy article to try out the functions I KNEW how to use in VE. I'm using the old editor for now till VE's more mature. louYambarampgarous (talk) 22:39, 8 July 2013 (UTC)

@Vfrickey: that's fair enough :). I'm hoping that improvements to template editing will be on their way soon. Okeyes (WMF) (talk) 07:17, 9 July 2013 (UTC)

VisualEditor seems to have really messed up this one

I couldn't begin to figure out how to repair this version of Stuart Fielden – so all I could do is revert. Wbm1058 (talk) 03:49, 9 July 2013 (UTC)

@Wbm1058: thanks for surfacing this problem :). I've reached out to the user, and hopefully they'll know whether it was a VE bug or a user bug. Okeyes (WMF) (talk) 07:38, 9 July 2013 (UTC)

Citation templates

For me, the main problem with VE in the medium term is the manner in which references are handled. The current approach with the selection of the citation templates through the transclusion button is not ideal, and means that new editors will find it very difficult to add formatted references. On the plus side, they can add bare URLs ok, but I think we'd prefer to see editors format the references accurately as they add them in.

As I understand the problem, the issue is that the different projects use different approaches to citation templates, making it impossible to write the sort of simple form that we currently have with the old editor (which I assume to be en.WP specific). Thinking about it, it seems that the developers have three choices:

1. Continue with the current model
2. Develop VE forks for different projects
3. Modify how cite templates are specified within the projects

I'd like to ask if it is possible to consider the third option. There aren't that many citation templates, so it should be possible to make the citation template format better for machine reading. In particular, I'd suggest:

• Using a unique tag on citation templates (perhaps a hidden comment or category). Templates with the tag could be dropped into a specific menu in the create new reference dialog, rather than relying on the user to type "cite" in the transclusion dialoge and choose between citation templates, citation documentation and the occasional non-citation template.
• Recognise or tag the data type of common cite fields, so as to identify date and numeric formats.
• Identify the display order of fields, so as to have author first, etc, for data entry.
• Identify the core vs optional fields, allowing VE to simplify the form.

Where citation templates don't have the required metadata, the transclusion button would be the only option. But if the project has suitably tagged citations, both options could be available. If the metadata can't be kept in the citation template, (which is tricky with the CS1 structure here) it could potentially be kept in a related area, such as Template:Cite/metadata, or even at the other end, such as WP:Visual Editor/Citation metadata

The whole idea may not be viable, and I know this would make it a bit harder to create and maintain citation templates, but I'd really like to see VE have a more intuitive method of adding citations in an accurate format. - Bilby (talk) 05:10, 9 July 2013 (UTC)

We're currently working on VE improvements around referencing - specifically called out is "local wiki-specific workflows" - for example, calling out the "cite" suite of templates :). That sounds like a good plan, but around the tag I worry that frankly we'd end up presenting users with 50 different options :/. Okeyes (WMF) (talk) 07:20, 9 July 2013 (UTC)

Legitimate use of <nowiki> ...and VE screws it up

Tracked in Phabricator
Task T53054

I've said before that <nowiki> tags should be extremely rarely used in mainspace. Searching articles for these tags, I found an article where there is a legitimate need for them:

Death 'n' roll (portmanteau of death metal and rock 'n' roll) ([[portmanteau]] of [[death metal|''death'' metal]] and [[rock and roll|rock ''<nowiki/>'n' roll'']])

The single <nowiki/> tag is required to keep 'n' from being boldfaced rather than italicized.

I tested VE's handling of this legitimate use of nowiki by doing a null edit (to do a null edit in VE, hit the spacebar once, followed by a single backspace—this will "trick it" into activating the save button). Now, VE did recognize that there seemed to be a problem, and tagged my edit with:

Tag: VisualEditor: Check [visualeditor-needcheck] : Edit made using the VisualEditor where the system detected the wikitext possibly having unintended changes.

But, I had to revert its change to (portmanteau of death metal and rock 'n' roll). Note the separate links to rock and 'n' roll. – Wbm1058 (talk) 11:41, 9 July 2013 (UTC)

Actually, there's two ways to get the desired result, as VE demonstrated when I used it to create the link to rock 'n' roll – which it managed to do without resorting to nowiki tags by italicizing the space before the 'n' : [[Rock and roll|rock'' 'n' roll'']]. Wbm1058 (talk) 12:30, 9 July 2013 (UTC)

I can create the link death metal successfully with VE – but only if I create the link first, then italicize death. If I try to italicize death first, then link, it messes it up. Wbm1058 (talk) 12:56, 9 July 2013 (UTC)

Hmn. What did it do that screwed it up, exactly? I just tested it in my sandbox and it appears to have worked (italicising first, then linking). Okeyes (WMF) (talk) 16:22, 9 July 2013 (UTC)

Look again at your test edit. Rather than a single link to death metal, there are two links: on both death and metal. Wbm1058 (talk) 16:42, 9 July 2013 (UTC)

Oh, guh. Thanks :). Okeyes (WMF) (talk) 17:54, 9 July 2013 (UTC)

Now tracked. Excellent catch! Okeyes (WMF) (talk) 17:55, 9 July 2013 (UTC)

Great!

I think this is a great new feature! I've been wondering for a while why Wikipedia didn't have anything like this. I think this will encourage more people to contribute to Wikipedia. Benimation (talk) 21:15, 9 July 2013 (UTC)

features

Where's the best place to request new features for the VE? -- phoebe / (talk to me) 22:22, 9 July 2013 (UTC)

Here you can leave your feedback about VE and also suggest new features TeamGale (talk) 22:30, 9 July 2013 (UTC)

Please don't turn this on for IPs for at least a month

While I think there was still more work that needed to be done before this went live across the project to all logged-in editors, I think as a group we can cope with it. However, it's blaringly obvious that there are a lot of very significant bugs that need to be fixed, particularly referencing, to the point that I'd say rework the whole "references" section. Even for an experienced user is very difficult to handle, unless they've memorized the names of all the templates and their parameters.

This is so not ready for inexperienced users that I'm still gobsmacked that you're doing A/B testing on newbies. Please don't compound the error by adding IP editors too. The software just isn't good enough yet. You've still got "blocking" bugs that aren't fixed yet. Risker (talk) 14:49, 3 July 2013 (UTC)

Someone has suggested to me that I be more clear on my reasoning here. The fact of the matter is that the majority of the current community is just now starting to figure this out, and we're reporting a lot of significant bugs. While it's lovely that there are a few "community liaisons" around, and that there are a few Wikipedians who are helping out new editors, it's going to be the community that has to explain this process to IP and new editors, and most of us don't understand it well enough yet to do so. On the other hand, even those of us who are learning the new process can explain the old process and know where to find links and information to help someone who is trying to edit source. Risker (talk) 01:37, 4 July 2013 (UTC)

• Support Until the ability to simply add references has been added this software should definitely not be rolled out further.Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:44, 4 July 2013 (UTC)

  Doc James, can you clarify whether "simply add references" means "autofill a citation template" in your mind? There is an option to simply add references right now, but only if you're typing out the citation manually. Right now, anyone can click the ref button, click "Create new source", type the citation into the next screen under "Reference content", and then click "Apply changes" to have it added to the article. That's pretty simple, but it does require you to type out the author, date, title, etc., yourself. Whatamidoing (WMF) (talk) 13:15, 5 July 2013 (UTC)

• Support I wasn't aware that references were still being worked on, but I'd kinda think that at least the ability to easily and reliably place references (that is, with something that even the Illuminati-fighting grandpas and third-world nationalists will be able to figure out with little to no instruction), and the ability to read invisible comments at all would be considered necessary before testing on anons. Ian.thomson (talk) 00:48, 4 July 2013 (UTC)
• Support It needs more time to fix the bugs, of which there are many, which have been stated many times earlier. Johnny Au _{(talk/contributions)} 16:49, 5 July 2013 (UTC)
• Support I agree with any measure that prevents the roll-out of this utility until it is ready.--Paul McDonald (talk) 15:25, 10 July 2013 (UTC)

Dafuq?

Why is this crap of beta software set as default editor for everyone? Really? If you need, ask for betatesters, but don't chase me to use this crap...took me 5 minutes to disable this damn tool and fix what it had done...next time, NOT as deault for everyone! thanks. --Shadak (talk) 08:46, 9 July 2013 (UTC)

@Shadak: you can just use 'edit source'; you don't need to disable it to edit without it. We've been testing it here with a wide pool of beta-testers since December 2012, and asking for them, too. Okeyes (WMF) (talk) 08:48, 9 July 2013 (UTC)

Let me get this clear: I do NOT want VisualEditor. I had the "honor" to test it (Nobody asked me nor I choosed to test it. Someone just forced me...) just 5 minutes ago. Really, I need 1 Minute to choose to disable it. Is no improvement about the old editor, it even slows down: cklick "edit"..oh not what i want --> click "source edit" ah, thats what I want. really? --Shadak (talk) 08:53, 9 July 2013 (UTC)

Then disable it, but again, nobody forced you to test it. Markup editing still exists, even with the VE enabled. Okeyes (WMF) (talk) 09:08, 9 July 2013 (UTC)

"nobody forced you to test it" - this is disingenuous. You are trying extremely hard to steer people to it, and obscuring methods not to use it. Of course people are being forced into it, and arguing that philosophically they can get out of it doesn't change what you're doing here - David Gerard (talk) 09:16, 9 July 2013 (UTC)

Yes and no. We would certainly like people to use it, both as an editor and as a test editor, but I'm confused as to how we're obscuring methods; the project page directs people to how to disable it, as does the page notice on the VE feedback page. If you think there's more we could be doing that wouldn't bring us down too far on the other side, let me know. Okeyes (WMF) (talk) 09:19, 9 July 2013 (UTC)

aehm...You set it as default editor for logged-in editors. Why not ask em if they want to use it instead of force em to use it? Even a information that you rolled out that editor would help to raise the acceptance. Of in information what it is, what i can, what are the benefits? If i get something new without ordering it, at least I should be informed... --Shadak (talk) 09:22, 9 July 2013 (UTC)

oh...sry, I just see, this is an alpha(!) version. really? everyone gets a alpha(!!!) version? everyone have to use alpha version (!^n)? what about the Opera users (like me, your luck i "accidentally" used FF). really...I don't want to offend anyone, but this is just bad marketing. you cannot set it as default, when it not run on everyones browser. Fix at frist the bugs and problems, THEN think about relaesing it to everyone and THEN decide that at least old user should have the decision...oh and by the way. alpha versions are not made for public. alpha means testing, like beta. This maybe volunteer project, but i'm not your test rabbit...also no one else. --Shadak (talk) 09:39, 9 July 2013 (UTC)

No, this is a beta version. If you had used opera, you would have found it went straight into markup mode; when it doesn't work on a browser, we blacklist that browser, we don't throw a broken version at the user. We did send out rollout information; there have been announcements since December last year, including CentralNotices covering most of the last 2-3 weeks and a watchlist notice since early June. Okeyes (WMF) (talk) 09:44, 9 July 2013 (UTC)

Beta version? Still not release, so no rollout to all users. beta is still unfinished software. take a look here. So, why I'm a betatester?

Information: I missed all these. i'm not so often en.wp. Maybe they got overlapped by election messages. also, I got not messages about this at the July 5, when I was the last time here. Why not display them NOW? Everyone has this editor now, so now would be a good point to inform people (who missed the information of the last weeks for some $reason) what they have now. --Shadak (talk) 09:59, 9 July 2013 (UTC)

They came out after the election messages, and I can confirm they were around on 5 July. There will always be people who miss the notices due to absence, and we can't extend the banner every time, but I'll talk to people about throwing it out for an extra week. Okeyes (WMF) (talk) 10:39, 9 July 2013 (UTC)

I just happened to read your conversation guys. Okeyes, you've explained everything properly and your patience here was extraordinary. Shadak, you need to understand something: whether you like the new Visual Editor or not, there's a way to criticize it. In the English Wikipedia there's no place for words like "defuq", "crap", "damn" and such. I don't know if you're doing it as a way to show off or act cool. Look at things in perspective, what are you so mad about? You call yourself a "test rabbit"? The 5 minutes it took you to remove it were "horor" for you? Wow, calm down please. This kind of talking may be acceptable in your Dutch Wikipedia, so keep it there. And next time kindly improve your English before writing something here again. Thanks and goodbye. Yambaram (talk) 02:48, 10 July 2013 (UTC)

Shadak, please consider this message to be your personal notice that VisualEditor is also scheduled to be turned on for the German Wikipedia in less than two weeks. Whatamidoing (WMF) (talk) 03:15, 10 July 2013 (UTC)

I already noticed it yesterday. the dates on the project page are good placed. But I'm not happy with the fact releasing betasoftware to the users...but nobody cares here.

@Yambaram: If my bad english insults you, I'm sorry for that, but thats the way it is. I try as good as I can, but I'm not a native english speaker. If you say I have to be silence because of it...not sure how should I call it to be polite. My choose of words was maybe drastically and borderline, I'm sorry. But iIf my company would release such software, my ceo would "kill" some people (mening they would need a new employer) and we would have a big image problem. Its maybe outdated thinking, but realease software should be free of major bugs and the software should be relaese and not beta. if you "relaese" beta software, then it is just crap, sry for calling it this way. And if you complain that angry customers complaining about this "crap software" because they had trouble with crap software they didin't wanted (sry again for my choice of words), then you should ask you why they are complaining. Maybe because you did something wrong or because they are to..."stupid" (sry , if I insult someone). Oh...just to get it right: I used ""defuq"[sic!], "crap", "damn"" because they described the situation, not to be cool or something else... --Shadak (talk) 08:19, 10 July 2013 (UTC)

Yambaram's comment was pretty much entirely inappropriate - David Gerard (talk) 10:59, 10 July 2013 (UTC)

Wikipedia is not WP:CENSORED. And he's right. If anyone in my software development teams released software like this in this manner, I'd fire them too. This rollout has been handled very poorly.--Paul McDonald (talk) 15:14, 10 July 2013 (UTC)

Thanks for all of your responses. First, to user:david gerard, I entirely disagree that my comment was inappropriate. I wrote it from a very neutral perspective and with good will - in fact I don't even see how your comments here were helpful in any way. To user:shadak, I didn't mean to be too harsh and apologize for criticizing your English proficiency (I'm not a native english speaker either) it's just that some of your slangs and minor errors could have been easily fixed or avoided here in wikipedia. I do agree with you and with user:paul mcdonald that the new Visual Editor has all kinds of different issues, and therefore I also removed it, but there's a better way to say this. Thankfully no one has been hurt my this "poorly handled" project and I hope justice will come upon those employers who you think need to be fired, that's all. Yambaram (talk) 02:17, 11 July 2013 (UTC)

Let's talk templates!

Those of us in the UK politics corner of Wikipedia (though not exclusively) have one or two difficult things coming up soon, if you see what I mean. I *know* that we could press "Edit Source" and copy everything, which is what I intend to do, and what I intend to suggest to editors who ask in the future.

But this is just a workaround, and one I fear might be ditched if VE is rolled out in full at a point in the the short- to medium-term. I have tried, and tried, and tried, to teach myself how to use VE with a template as complex as those on the link above, and it simply does not (or will not, or cannot) work. It's too complicated for someone like me, who doesn't know computer programming, to understand. (And yes, I consider the template builder on VE to be computer programming, for that's what it is.)

I support VE for text editing, it clearly works well and will get better. But templates such as the one above test the service to its very limits.

What say the forum? Template-specific instruction manuals? Easier instructions at the point of editing? AN Other?

doktorb _words^deeds 09:28, 10 July 2013 (UTC)

I think that this is a case of needing both/and, rather than either/or: both template-specific instructions and simply an easier process overall. The devs are working on the latter bit; improved instructions could be written by anyone.

Getting the WP:TemplateData into those (many) {{Election box}}-related templates would probably simplify some of it. Even with that, though, it looks to me like it would be easier to change information already on the page than to add new information. Whatamidoing (WMF) (talk) 19:54, 10 July 2013 (UTC)

Proposal to rename the template editing features in VE

See: Wikipedia:Village pump (proposals)#Replace the term .22transclusion.22 in the Visual_Editor. Dragons flight (talk) 16:45, 10 July 2013 (UTC)

What are the success metrics for this deployment?

It's pretty clear from various plans (including the 2013-14 WMF Annual plan) that a key success metric for VisualEditor is a July deployment. However, I'd like to see what other success metrics the VE team is measuring for. Ones that I would expect to see, at minimum:

• Uptake by existing users (probably measured by % of edits by users with +100 edits as of the time of deployment, higher number indicating greater success)
• New users started on VE who convert to source editing (probably measured as a % of edits done using source editing by these new users, low number indicating greater success). These editors were identified during your A/B testing, which as best I can figure is still happening.
• Percentage of non-bot/non-script article space edits completed using VE
• De-activation by existing highly active users using gadgets or scripts (measuring at 1 month)

What I personally would consider success in the four points above would be somewhere around

• 25% uptake by existing editors within 3 months of deployment
• <5% conversion of new editors who started on VE moving primarily to source editing within 1 month
• 25-30% of non-bot/non-script article space edits completed using VE within 3 months
• <25% of existing highly active users disabling VE at 1 month post deployment

The one metric I'm certain is being measured, but which is entirely meaningless is new editors who (a) register an account and (b) create one edit. Nobody should care about these one-edit wonders; we have a million of them already, and they're not building the encyclopedia. Yes, I know nobody gets more than one edit until they get one edit. But they're unlikely to be doing anything useful until they hit autoconfirmation, so that's when you should count them as "new editors". Risker (talk) 22:17, 10 July 2013 (UTC)

Er. Where are we measuring that? Okeyes (WMF) (talk) 22:29, 10 July 2013 (UTC)

I have no idea. I'm asking what success metrics are, suggesting a few, and suggesting that the one standard success metric attached to just about every Wikimedia activity is not actually all that useful. So what *is* being measured, and how will the VE team know when it has had a success? This is standard for any project in any industry. Risker (talk) 22:33, 10 July 2013 (UTC)

I meant the "register an account and create one edit". I'm one of the people working on the analytics setup, and I've never heard of us using that metric. Okeyes (WMF) (talk) 22:34, 10 July 2013 (UTC)

That metric is not being used by the VE team, Risker is confusing it with other experiments. If anyone is interested in why we use 1+ article edits in 24 hours as a metric (among others) in other contexts, feel free to ping me. It's not relevant here. Also if you're interested in when WMF generally counts someone as a "new" or "active" editor, I can explain that as well. Steven Walling (WMF) • talk 22:35, 10 July 2013 (UTC)

It's used elsewhere as well, or in a slightly varied form. (So is characters added, and I'm sure hoping that's not being used here either.) It is odd, though, that the deployment of a product that is ostensibly supposed to encourage new editors isn't measuring new editors. Risker (talk) 22:54, 10 July 2013 (UTC)

Getting back to the subject header, what success metrics are attached to this project, and how are they being measured? Risker (talk) 22:54, 10 July 2013 (UTC)

This answer is, I'm disconcerted to say, evasive. What, without evasion, are the metrics for the Visual Editor? If any - David Gerard (talk) 22:55, 10 July 2013 (UTC)

David, it wasn't intended to be evasive, I was just making sure I understood the scope of the problem. I don't think Steven has any interest in being evasive given that he's not actually working on the VE.

The metrics we're studying are (broadly speaking) that we want a statistically significant increase in the probability of a user editing, and ideally the probability of a user staying around, without a statistically significant (or a substantial) increase in things like revert likelihood. Looking at your metrics above, I'm not sure that they entirely make sense. That is: if, for example, 25 percent of power users disabled the VE, that would call into question the type of deployment (opt-out, for existing users, rather than opt-in) but not the viability of the actual software - people like familiarity. Heck, I'm posting this from monobook.

I'm also not sure about the conversion rate, just because I'm not sure what the conversion rate currently is. Maybe 5 percent of people who come in to edit just plain prefer markup; maybe they're technically minded. We don't have data on user preference, all we have is data on what users are willing to tolerate. I'm going to ask James to poke his head in and comment. Okeyes (WMF) (talk) 23:06, 10 July 2013 (UTC)

This might sound a bit snarky (and isn't meant as criticism of the devs who worked on this), but careful testing is only necessary when one actually expects to have a decision to make. As best I can tell, all the major decisions have already been made (VE is the way of the future!). I don't think there is any scenario that would lead to disabling this, hence deciding whether it is a success isn't actually very important. That said, I'm sure the WMF would like to be able to tell donors that they have accomplished X, Y, and Z during 2013. Those accomplishments could be phrased in terms of performance benchmarks (especially if they do get good numbers), but they could just as well be explained in terms of products created. Personally, I do hope that the WMF follows-up and studies the impact of this change, but I doubt there are any specific goals that they feel must be met. Dragons flight (talk) 05:16, 11 July 2013 (UTC)

RFC: VisualEditor launch issues

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

This section is transcluded from Wikipedia:VisualEditor/RFC

This is an RFC regarding the issues surrounding the deployment of VisualEditor. Gigs (talk) 17:03, 16 July 2013 (UTC)

0: Original non-neutral RFC summary

VisualEditor is a clever idea for the Wikimedia, but the software is buggy, slow, and not likely to be fixed anytime soon.

As such, it would seem that we, as a community, should discuss how to move forwards. Now, according to Wikipedia:VisualEditor/FAQ, we do not have the right to force them to turn VisualEditor off, but I think that they would be insane, should the community show strong reaction against it, to not at least take the concerns on board.

So, below, are several points to vote on. Please Support or Oppose each point. Feel free to add new points at the bottom. Adam Cuerden ^(talk) 23:04, 10 July 2013 (UTC)

As a point of order, the instructions at WP:RFC include: "Include a brief, neutral statement of the issue in the talk page section...." Do you think that "the software is buggy, slow, and not likely to be fixed anytime soon" is neutral? In fact, I daresay not only is it not neutral, it's blatantly untrue - bug fixes are pushing out almost every day. I understand your frustration, but proceeding with this RFC, launched under this condition, will not end well for anyone. There is no way that a process which is poisoned by a lack of the fundamental desire for neutrality and fair dealing will result in a neutral, fair outcome. Through your language on this RFC, you have contaminated it and prevented it from doing the good that it could have done. Philippe Beaudette, Wikimedia Foundation (talk) 02:55, 11 July 2013 (UTC)

May I point out that "slow" is listed as known problems on Wikipedia:VisualEditor#About_the_VisualEditor; VisualEditor changing markup has its own tag, which is still catching edits, such as [2], and if you really believe all the bugs are going to be sorted out soon, why didn't you beta it with a set of volunteers, sort out the bugs, then launch it? It frankly seems you're trying to preemptively make excuses to ignore user feedback. Adam Cuerden ^(talk) 03:13, 11 July 2013 (UTC)

Why didn't we beta it with a set of volunteers, sort the bugs, and then launch it? Adam, we had a 6 month test that included hundreds of volunteers. We sorted the bugs that we knew about. I note that you didn't make any edits using VE during that period - fair enough, nobody's required to - but please don't suggest that we didn't listen to input then or now. (In fact, it appears that you STILL haven't made any edits using VisualEditor?) Our engineering team has squashed 155 bugs since the beginning of the A/B test. That sounds pretty feedback receptive to me. I'm not making excuses, because absolutely we wish things had run differently, but c'mon... Philippe Beaudette, Wikimedia Foundation (talk) 03:54, 11 July 2013 (UTC)

I was one of those volunteers back in May, but I gave up testing after my bug reports were being auto archived without comment. We are not in this mess because the volunteers failed to spot bugs that subsequently came up in the rollout. We are here because someone decided to stick to a schedule rather than first sort the bugs that were reported in user testing. If it was true that fault lay with us testers for not finding problems then the community would be responding very differently. If the bugs that came up when I was just typo fixing had been fixed then I would have gone on to test VE with more complex edits like adding a reference or an image. But when I saw at least four of my bug reports going into the archive without comment there didn't seem much point testing it further - I was shocked and disappointed that this was deployed despite not sorting the bugs that they knew about if they were paying attention to the feedback from the testing. ϢereSpielChequers 06:15, 11 July 2013 (UTC)

I looked into the given link. At least one of them does seem to have a response. And if you look at the current state of the VE, you might find a refreshing change. To my way of thinking, a great deal of fixing has been done since deployment and is vastly improved within a few days. First impressions are difficult to get rid of, but I would urge you to give it a fresh look. As I have stated below, the way things are going, I see no need for this RFC.OrangesRyellow (talk) 14:54, 14 July 2013 (UTC)

Yes one of them had a response - though I think from a fellow tester rather than a developer, but that's why I said I saw "at least four of my bug reports going into the archive without comment". If that hadn't had a response I'd have said "all" rather than "at least four of". But tonight I've taken up your suggestion to test it again and see if it has improved since May. It is still much slower, it still shows the edit summary box in an excessively small font, it still randomly removes bits of code that I didn't want it to remove and the edit summary box still doesn't have predictive text using your previous edit summaries. Now I appreciate that one of those is a planned degrade in functionality rather than a bug per se. But at least two of those problems have now been known for at least 8 weeks. OK I'm willing to accept for the sake of argument that there have probably been other bugs fixed in the last 8 weeks. But it still doesn't look to me like it is ready to move beyond beta testing, let alone be deployed live on our largest wiki. As it is at the moment, how are we supposed to differentiate between a vandal deliberately removing random bits of the article and goodfaith newbies trying to edit with the visual editor? ϢereSpielChequers 22:48, 16 July 2013 (UTC)

Talk about leading question... -- KTC (talk) 09:22, 11 July 2013 (UTC)

My view of VE is that it is a superior platform. To be fair, most people, including yourself seem to agree on that. It think of the present state of VE to be like a superior engine which needs some tuning and polishing out of some rough edges. Most of the rough edges seem to have been polished out or are being polished out as we speak. For example, the random removal of stub template code [3] bug seems to have been fixed now [4]. It does not seem buggy anymore. My main gripe with the VE is that the referencing technique still seems to be comparatively cumbersome. It was much worse 2-3 days ago; is still not up to my liking. But that would be merely a "tuning" problem, and tuning it to the community's tastes, polishing out of rough edges cannot be done without deployment. So, I think the deployment decision was correct. The referencing, even in its current form, is superior in some ways. For example, while reusing a ref, there is a search box which makes it very easy to find and reuse a ref. I expect the overall referencing experience to become superior to source editor in a few days. That done, I think it should be ideal for mid level users like me, and more importantly, for new users, for whom it is primarily intended. Best.OrangesRyellow (talk) 05:29, 20 July 2013 (UTC) Somehow, the small font in edit summary box did not seem like a problem to me. Maybe we have different screen resolutions. The edit summary box looked superior to me because it shows the whole of the summary, and also shows the number of remaining allowed characters. I guess, with most bugs getting fixed, sorting out test results from newbies and vandalisms would be less of a problem. Overall, I think our falling ed numbers is a critical problem, and with a bit more tuning in the referencing sector, the VE will be a great help in turning that decline.OrangesRyellow (talk) 06:06, 20 July 2013 (UTC)

1. VisualEditor is a good idea in theory

Having a working VisualEditor will greatly improve Wikipedia's usability. Adam Cuerden ^(talk) 23:04, 10 July 2013 (UTC)

Support (good)

1. Adam Cuerden ^(talk) 23:04, 10 July 2013 (UTC)
2. ϢereSpielChequers 23:28, 10 July 2013 (UTC)
3. Diannaa (talk) 23:32, 10 July 2013 (UTC)
4. doktorb _words^deeds 23:52, 10 July 2013 (UTC)
5. Vegaswikian (talk) 23:54, 10 July 2013 (UTC)
6. Thryduulf (talk) 23:57, 10 July 2013 (UTC)
7. Patrick87 (talk) 00:06, 11 July 2013 (UTC)
8. Carrite (talk) 00:10, 11 July 2013 (UTC)
9. Kevin Rutherford (talk) 00:18, 11 July 2013 (UTC)
10. Kumioko (talk) 00:23, 11 July 2013 (UTC)
11. Mega dittoes.  ;-) TCO (talk) 01:04, 11 July 2013 (UTC)
12. — ΛΧΣ²¹ 01:06, 11 July 2013 (UTC)
13. MER-C 01:21, 11 July 2013 (UTC)
14. --Jayron32 01:41, 11 July 2013 (UTC)
15. - MrX 02:13, 11 July 2013 (UTC)
16. - Robert McClenon (talk) 02:14, 11 July 2013 (UTC)
17. - Anything providing a path for Wiki newbies to become functional long-term editors that will help break up too many overbearing existing editing cabals is defined as double-plus good in principle. Scarletsmith (talk) 06:49, 11 July 2013 (UTC)
18. Support PantherLeapord (talk) 07:36, 11 July 2013 (UTC)
19. GiantSnowman 08:10, 11 July 2013 (UTC)
20. I've always dreamed about a transparent editor for MediaWiki. Even though I probably wouldn't use it myself it's clear it would lower the barrier to participation for less technically minded folks. —Psychonaut (talk) 08:22, 11 July 2013 (UTC)
21. Of vast importance. - David Gerard (talk) 11:27, 11 July 2013 (UTC)
22. May as well state the obvious here. — This, that and the other (talk) 12:15, 11 July 2013 (UTC)
23. Bidgee (talk) 13:57, 11 July 2013 (UTC)
24. Insulam Simia (^talk/_contribs) 14:16, 11 July 2013 (UTC)
25. We are just used to the arcane code interface that we have now. It's a good thing to have when doing complex things. It's terrible for a lot of simple tasks. Simple tasks should be easy and hard tasks should be possible. VE gives us an opportunity to work toward that ideal. Gigs (talk) 14:18, 11 July 2013 (UTC)
26. Reaper Eternal (talk) 14:51, 11 July 2013 (UTC)
27.  Sandstein  14:52, 11 July 2013 (UTC)
28. Strong Support per Gigs. Double sharp (talk) 15:18, 11 July 2013 (UTC)
29. -- John Broughton (♫♫) 16:28, 11 July 2013 (UTC)
30. • • • Peter (Southwood) ^(talk): 19:26, 11 July 2013 (UTC)
31. I don't know about "greatly", but it seems like it could help some new people get into editing. Everyking (talk) 22:18, 11 July 2013 (UTC)
32. Yes. We need new editors, and it's pretty well established the markup is a barrier. --LukeSurl ^{t c} 00:23, 12 July 2013 (UTC)
33. Materialscientist (talk) 08:14, 12 July 2013 (UTC)
34. Important point to emphasize. NW (Talk) 16:40, 12 July 2013 (UTC)
35. It's likely that a good editor could be written, provided that it had local escapes. Almost all TeX WYSIWYG editors have "show code" buttons within the editor. However, this one doesn't seem to be on the right track. — Arthur Rubin (talk) 21:21, 12 July 2013 (UTC)
36. —Love, Kelvinsong talk 23:15, 12 July 2013 (UTC)
37. Chase me ladies, I'm the Cavalry (Message me) 11:53, 13 July 2013 (UTC)
38. In principle, a great idea that should make it easier for new editors. Not there yet, by any means. Anaxial (talk) 18:00, 13 July 2013 (UTC)
39. Yes but needs work before it launches fully Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:15, 14 July 2013 (UTC)
40. A good idea in theory, like most political ideologies and other paving stones on the road to Hell. Hullaballoo Wolfowitz (talk) 13:03, 14 July 2013 (UTC)
41. Jguy _Talk^Done 13:35, 14 July 2013 (UTC)
42. A brilliant idea, a shame that I can't edit this page with VE! LiquidWater 18:21, 15 July 2013 (UTC)
43. Having a complete (and completely optional) VisualEditor would be an amazing boost in efforts to recruit new editors. 18:47, 15 July 2013 (UTC)
44. Lankiveil ^{(speak to me)} 11:36, 16 July 2013 (UTC)
45. ¿3family6 _contribs 13:03, 16 July 2013 (UTC) Once the Visual Editor can accommodate tables and templates, I plan to use it almost exclusively.
46. I love this editor. I need to use it for a while to see what I think could be improved, but definitely in the right direction. I'm sad to hear all the negative reaction. I have thought for many years that a simple input like this would encourage me (and many other people) to contribute to wikipedia far more often. Chogg (talk) 20:02, 16 July 2013 (UTC)
47. This is a requirement for new users given the complex that wikicode has become. I would prefer a semantic rather than a visual editor, thoug; but this tool has the potential to become exactly that. Diego (talk) 17:11, 18 July 2013 (UTC)
48. — Scott • talk 20:47, 19 July 2013 (UTC)
49. Support, if we are discussing new editors. Even what I consider simple basic coding can be observed to be a barrier for many people, and that most very active people now here prefer to edit html-like material in html is not a basis for saying otherwise--if we weren't comfortable with the editing environment we wouldn't have become the very active users. For doing anything even moderately complicated, it remains a good idea -- the current implementation is impossibly slow, and cannot be counted on to produce code that does not need manual fixing. DGG ( talk ) 21:19, 19 July 2013 (UTC)
50. Support—but IMO "working" means fast, safe and with great support for adding citations. - Pointillist (talk) 21:42, 19 July 2013 (UTC)
51. Absolutely a good idea in theory. Potential editors who haven't already figured out how to edit source probably never will. --Cryptic C62 · Talk 00:33, 20 July 2013 (UTC)
52. No doubt on that. But the practical/technical side is the hardest one. Honestly, I think Mediawiki should change its core rather than try to add alpha tools. --Lucas (talk) 00:49, 20 July 2013 (UTC)
53. ·addshore· ^{talk to me!} 12:04, 21 July 2013 (UTC)
54. Of course it is! But everything needs its own time to grow. --Roberto Segnali all'Indiano 12:55, 22 July 2013 (UTC)
55. Cander0000 (talk) 07:51, 24 July 2013 (UTC) you could actually leave off the 'in theory'. pretty much every major market general purpose computing product has followed this vector to some degree.
56. PhnomPencil (talk) 10:02, 24 July 2013 (UTC) Yes, it's key to increasing editors.
57. Doh. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 21:33, 26 July 2013 (UTC)
58. If it were done well, it would be an immensely important step forward for our project. It is the premature implementation and aggressive failure to listen from the project management, not the concept itself, that's the problem. Seraphimblade ^{Talk to me} 04:28, 29 July 2013 (UTC)
59. Obviously. Though, it'll be incremental. The real reason behind the 2007 crash is the hideous reception new editors get here. --Anthonyhcole (talk · contribs · email) 00:16, 31 July 2013 (UTC)
60. Document editing without a WYSIWYG editor cuts out an enormous number of potential contributors, particularly occasional ones. There's a reason every modern system has one. LaTeX is still used, as a matter of tradition, but is over four decades old now. Dcoetzee 02:22, 2 August 2013 (UTC)
61. Sure, why not. Gryllida 08:09, 6 August 2013 (UTC)
62. – Quadell ^(talk) 15:41, 9 August 2013 (UTC)

Oppose (good)

1. It will make it more usable for some users. Wiki markup is pretty simple, so I don't think anything at the markup level can "greatly" improve usability.—Kww(talk) 01:06, 11 July 2013 (UTC)
2. Oppose as expensive extravagance: It would be great, when VE is debugged during the next 3 years, for editing "vertical Chinese" but the world has shifted to linear text, where Chinese hanzi (kanji) characters can be mixed horizontally with Latin-alphabet words (see: zh:AAA). However, the danger of edit-conflict in VE, to lose all the tedious keystrokes is too great a psychological scar for new users. Meanwhile, WP is maintained by a core group of 9,000 power-users who rewrite articles, because "crowd sourcing" of text is called a blog. Instead of burning resources on VE for 3 years, we need auto-merging of wp:Edit_conflict insertions such as multiple replies stacked in LIFO order (last-in, first-out), where a 2nd insertion at the same line number would be above any new "===Section===" inserted by a prior editor. We need quick revisions which read-lock the page, so that 2 quick edits do not overwrite each other. We need to expand the wikitext-editor screen to list other recent revisions being stored (by other users) while someone edit-previews the same page. We need web-links "[http:__]" to not auto-append "/" after the URL. We need templates to set parameters, {{#set:x|45}} to store values which could make templates run 10x-40x times faster. We need to raise the wp:Expansion depth limit from 41/40 to 50 or 80 levels of nested template if-elses. The fact that those important changes have not happened after 10 years(!), shows that wp:Bugzilla discussions are ineffective at sorting priorities, and we need a major organizational change, such as a wp:PROPS#User Council to emphasize important software changes, not extravagance which helps rare users point-and-click one time. Focus on the 9,000 power users, not forcing buggy software on the 100,000 60,000 who scribble in one edit per month. -Wikid77 (talk) 11:39/16:01, 11 July 2013 (UTC)

   That's actually not true. Power users make around 40 percent of contributions. Okeyes (WMF) (talk) 12:17, 11 July 2013 (UTC)

   See note below: "Beware myth of WP written by passing strangers who never returned". Power users (8%) make 87% of edits. -Wikid77 16:08, 11 July 2013 (UTC)

   It's been years since I looked at this, but my recollection is that very active contributors are responsible for a substantially larger fraction of article space content (measured in character counts) than would be suggested even by the fraction of article space edits they create. Dragons flight (talk) 14:46, 11 July 2013 (UTC)

3. I like the old system. Easy to move a page to your text editor (e.g. vi ;-)  Klaas|Z4␟V:  14:05, 14 July 2013 (UTC)
4. It is not a "good" idea, just an average one. If it was implemented flawlessly, it could have some use - for example, it could be somewhat easier to position and size images... Or to edit individual infobox fields... But its importance is so low that I don't think calling it a "good" idea is correct... And, of course, flawless implementation would use the visual editor to supplement source code editing, not replace it... Also, all the talk about visual editor attracting many new editors looks rather suspiciously unsupported... --Martynas Patasius (talk) 19:40, 15 July 2013 (UTC)
5. I still think that the traditional technique of editing Wiki markup is superior even for newbies. The reason for this is that you can see how others are formatting the text. Using the Visual Editor, you see only the results but not how others achieved that. In case of Wiki markup, you can learn by reading other people's Wiki markup. Every beginner adding his voice in a list like this, will, for example, grasp immediately the meaning of the hash at the beginning of a line. --AFBorchert (talk) 07:59, 20 July 2013 (UTC)
6. Oppose. WYSIWYG are deprecated in many areas of technical writing, particularly in the mathematical sciences, where most editors use LaTeX (although some use a visual interface). The current markup language supports abstraction through templates, which can be nested, etc.; WYSIWYG editors with point-and-click interfaces overwhelm editors with too many choices and are terrible at nesting structures. Most users need very basic editing, and anybody who cannot fix a typo with the current editor likely should not be editing an encyclopedia. Kiefer.Wolfowitz 22:29, 25 July 2013 (UTC)
7. --Shadak (talk) 14:16, 29 July 2013 (UTC)

Extended content

---- Beware myth of WP written by passing strangers who never returned: It has been a pervasive, misleading myth that Wikipedia was somehow written by passing strangers who added massive content and never returned to edit again. Some can be attributed to people who often change usernames or use rotating dynamic IP addresses. However, such myths of strangers writing polished articles are alluring, such as saying, "Einstein flunked out of math class" (not true), when the reality is that Einstein quit secondary school to enter college, directly, but at first failed the entrance exam, until tutored, to pass the re-test. Then Einstein worked with major leaders in theoretical physics, when developing the Special Theory of Relativity. As for WP editing, many articles have been created, in coordinated sets, by wp:WikiProjects, such as 12,500 articles from the Catholic Encyclopedia or 22,272 articles from the 1911 Encyclopaedia Britannica, and over 210,000 articles (5% of WP pages) have been created by just 10 users (see "50 recently active wikipedians" in stats-EN). The overall monthly editor-activity statistics follow the typical patterns for a large population of users, such as the 80/20 Rule, but more like 90/10 (meaning 90% of edits are made by 10% of users), where statistics for May 2013 (stats-EN) confirm 8% of users (9,491) made ~87% of edits (2.8 million of 3.2M), which includes Bot edits (because strangers are not running Bots). Likewise, the top 17% made 93% of edits. Then, consider how the 87% of edits, by power users, also include clever edits to run templates and match style guidelines, which most strangers would be unlikely to do. Hence, note the power users make ~87% of edits and most of the rewrites to match format guidelines and template features. The idea of a WP written mainly by one-edit users is just a misleading myth, which ignores the real difficulties of writing sourced, formatted text. The power users are the ones who would most use better software, in 87% of all edits each month. -Wikid77 (talk) 16:01, 11 July 2013 (UTC) "Contribution" and "edit" are not the same. In my volunteer capacity, I've made thousands of edits in articles that didn't contribute a single character. Undoing someone else's good-faith contribution is "an edit", but it does not result in articles getting written. Ditto for formatting fixes, minor edits, spelling changes, adding categories, spam removal, creating redirects, and all of the other things that wikignomes and other high-volume editors do. For example, your most recent mainspace contribution was yesterday, and, as seems fairly typical for your edits, it is "an edit" but it did not create any new content. I suggest that you start reading here with some of the research done by Aaron Swartz. It might help you understand the difference between "writing an article" and "making edits". Whatamidoing (WMF) (talk) 21:09, 11 July 2013 (UTC) Indeed. @Wikid77:, aaronsw's numbers are old, but they have the virtue of actually being numbers, rather than conjecture from first principles. It would be interesting to see his numbers run again for 2013, then we would have something new on the matter of considerable importance - David Gerard (talk) 21:16, 11 July 2013 (UTC) No, Aaron's numbers are wrong (or at least they stopped being true). By the time I did similar analysis around 2009 or 2010, the balance of characters contributed to articles was definitely in favor of the highly active contributors rather than drive-by editors. My recollection is that around 20% of retained content was created by drive-bys (anons and users who edited briefly and disappeared), around 30% came from infrequent contributors (i.e. users with a slow pattern of edits over an extended time), and about 50% of article content had been contributed by highly active editors (i.e. users contributing many edits per month for many months). I don't think any of these groups should be highly favored over the others, but the volume of content added by the highly active editors was definitely larger than by the drive-by group. Depending on how one draws the lines and how one describes the infrequent but persistent contributors, I suppose one might choose to describe the patterns somewhat differently, but if the thesis is that Wikipedia's article content comes primarily from users that edit only in passing, then I believe that is simply false. Dragons flight (talk) 21:36, 11 July 2013 (UTC) I'd love to see current numbers, because Aaron's work is old. I think, however, that Wikid's thesis is essentially that Cydebot is writing articles when it does category maintenance, and that is clearly wrong. Was your methodology similar to Aaron's, or were you just counting the number of edits made? (Perhaps you'll follow up with me elsewhere; User talk:WhatamIdoing is a good place to find me.) Whatamidoing (WMF) (talk) 22:39, 11 July 2013 (UTC) Beware undersized samples of a 4.2-million-page website: As part of my extensive analysis of article content, I quickly realized that many thousands of articles are needed to judge content contributions, and his numbers reflected smaller samples, too small at the time. Jimbo has emphasized similar needs to check very large samples, in his years of discussing thousands of articles. I have decades of experience in this area: as a college senior, I wrote a computer simulation of automobiles queued at gas/petrol pumps, and used the recommended large sample size. However, when my stochastic modelling run finished (which passed a "test for randomness"), I concluded, "Random numbers prefer unleaded gasoline" and my college professor promptly smiled and corrected that if I had time (as a busy student in 5 courses) to run more large samples, then I would see the preference for unleaded gas as an artefact of the particular run of random numbers tied to the seed (calculated by: multiplicative congruential generator, MCG), and common sense applies. For WP contributions, the sanity test is to consider the impact of power-users making 90% of edits every month, as most likely to influence the contents of articles, compared to the 10% other edits. As for my personal edits, my major contributions have been in creating hundreds of articles, but also a *thousand* carefully crafted templates (hundreds deleted now), including Template:Convert/spell to display a measurement conversion in words, or Template:Autocol to auto-number items in dynamic multiple columns, or Template:Tracklist/custom to add the total runtimes of album songs, etc. However, I also understand the impact of veteran editors who create no templates but many thousands of articles, which others rarely expand much, and also consider hundreds of deleted articles as part of those contributions. Instead, it might be true that newcomers provide more photos than regular editors, but most article text originates from veteran editors. All the factors confirm those findings, as a web of knowledge mutually supporting the same conclusions. Many IP authors are not 2-day newcomers, but rather the same people re-editing similar articles with different IP addresses. The appearance as newcomers was a strong illusion, which bolstered the myth. -Wikid77 (talk) 22:53, 11 July 2013 (UTC)

1. Oppose. I wish I'd known about the proposal for VE earlier, but I'm not a "power editor", just an occasional contributor and fixer of the odd typo. VE is a bad idea precisely because it makes it easier to edit Wikipedia regularly. My own view is that useful edits are more likely to be made by people who are at least smart enough to learn how to use the existing tools. The lower the hurdle, the more likely you are to get unhelpful edits. RomanSpa (talk) 20:59, 10 August 2013 (UTC)

Neutral (good)

1. I've never been a fan of wisiwig editors, they never have the full power needed. Does any profesional actually use them for HTML/CSS? Why would we expect wikitext to be different?--Salix (talk): 00:40, 11 July 2013 (UTC)

   We're not needing to create something for professionals, we're needing something for average folks who don't want to have to screw with WP markup language. The problem is, WMF has botched the job. Carrite (talk) 05:32, 12 July 2013 (UTC)

   One thing you tend to get with visual editors is that then end up making verbose and messy html code which is hard to see in source. VE is better than most at producing clean source code, with a few exceptions. Messing with subscripts and italics niggles me as VE turns ''x''^''n'' in to ''xⁿ'', worse is compressing template parameters all onto one line which makes it hard to read in source. VE has a particular problem is that the code produced needs to be read by power users so needs to try harder unlike the auto generated html which normally never reaches human eyes.--Salix (talk): 19:05, 12 July 2013 (UTC)

   I don't object to that VE change, although the semantics of italicizing as indicating a variable gets lost. What I do object to is the change of ''x''_''i''0 to ''x_i''₀, which is syntactically wrong. I don't even want to think about what it would do with ''x''_''i''₀. — Arthur Rubin (talk) 19:16, 15 July 2013 (UTC)

   Of course "professionals" use WYSIWYG HTML editors. Sales of Adobe Dreamweaver depend on this fact. WhatamIdoing (talk) 16:25, 14 July 2013 (UTC)

   But WYSIWYG is only part of what Dreamweaver does: Is it possible that its less-experienced users take more advantage of its WYSIWYG features, while experienced professionals depend more on its hand-coding features? Dementia13 (talk) 12:16, 30 July 2013 (UTC)

2. To me, there's a lot to be said about a "technological barrier" to editing. If a good visual-type editor can be created, I don't oppose selected editors having access to it and that access be monitored (mabye after a certain number of edits, or an application process like WP:ADMIN). But to make it available to everyone can lead to a lot more problems than it can solve.--Paul McDonald (talk) 11:15, 11 July 2013 (UTC)
3. Per Salix. Also, if you want to contribute something badly enough, you will learn how to do it. Consider people who we want to deter by making it harder for them to make their edits (e.g. by (semi-)protection, non-instant granting of autoconfirm, etc.) Are they not vandals? And why do those deterrents work? Because most of them lose interest when it isn't super-easy to do something. Most people who don't lose interest genuinely want to contribute productively, with only a few WoWs. Double sharp (talk) 15:26, 11 July 2013 (UTC)
4. I think in theory it is a good idea. The first time it loaded for me I was impressed at how easy and intuitive it seemed. (I haven't used it much so I dunno about bugs.) But good golly, it's awfully slow! It's so slow that I'd rather stick with regular editing at the moment. I couldn't really figure out where the best place to put this comment was so I added it here. AgnosticAphid talk 18:50, 11 July 2013 (UTC)
5. Per Salix. (Maybe. For some low-tier values of "professional". Some of whom I've even collaborated with.) Per Aphid. (Inversely. The first time I saw it, gorge rose in my throat, seeking a release that I barely suppressed. But on second thought, VE still seems like a nice idea.). Per everyone and no one, I do like the idea of a friendly, organic editor that can instantly turn ones intentions into finished prose. But have never met one I felt was up to the task.--R.S. Peale (talk) 04:56, 12 July 2013 (UTC)
6. Mixed feelings about it being a good thing, waiting for true statistics analysis when VE will be fixed for many of its bugs and the many enhancements suggested by volunteers here are taken into account. Current statistics seem bad for VE, but difficult to say if it's because VE is far from being ready for production, or if it's the concept that is bad. --NicoV ^{(Talk on frwiki)} 04:09, 23 July 2013 (UTC)
7. My attitude about the Visual Editor in general was sort of "Meh", as I really didn't care one way or another if it was developed, nor did I see the strong need for it to be developed in the first place. If somebody wants to knock themselves out and develop something like this, they have the freedom to do so but I really don't care. It becomes far more annoying when I'm forced into using that as the only editor though (see some discussions below). I strongly disagree that this was needed to make Wikipedia seem "professional" as that is a game which will never be won and has been the topic of debates on Wikipedia from day one (arguably even earlier with the Nupedia debates on the topic). I don't think a WYSIWYG editor is any better, it is just different. I've used plenty of both kinds of editors for decades now, and I find that the learning curve for both is just as steep if not steeper for a WYSIWYG editor as it is for a markup-language editor. --Robert Horning (talk) 14:13, 25 July 2013 (UTC)
8. I edit the way I do because I've taken the time and effort to learn the ins and outs of the editor. That's not because I'm "older" or "have been here longer", it's because I want to be effective. I learn the editor, consult WP:MOS, etc. You can make editing easier and more convenient, but that's not going to attract the people who care enough to make meaningful edits. It's going to attract the careless, drive-by sort of editing. A good editor has their references lined up and takes care to format them. This is a level of effort and commitment, and that's the kind of editor you need. That sort of editor will not likely be swayed by the presence or absence of a VE. It's not a bad thing to have, but it's not The Answer, as seems (desperately?) to be assumed. Dementia13 (talk) 12:16, 30 July 2013 (UTC)
9. I guess I'm just someone who finds it easier to comment on specifics than "in theory". I'm about mid-point between the views here in the neutral section, and the views that support "good in theory". I certainly accept that the idea of introducing VE came about entirely in good faith. --Tryptofish (talk) 23:07, 31 July 2013 (UTC)
10. In theory, yes; in practise, no. Such a tool would benefit many users, as long as it is developed and deployed with full input from the community and is truly optional at all stages of the process - something with the WMF seems unwilling to accommodate. Once it is 99% bug-free it can be rolled out to new users as default, but since a WYSIWIG editor can never be as fast and efficient as source code for someone who is fluent with the source code, it must never be the only option. Users should also be able to partially disable VE - making source the default for shortcuts and the like without hiding VE completely. I'd actually find that useful for some edits but I can't use it because the disable tool is a sledgehammer and I refuse to have it as my default - no matter how good a WYSIWIG tool gets, anything beyond simple text is still a lot easier to do in code. If source is ever disabled, I'd sooner edit through the API than VE. --W. D. Graham 13:59, 4 September 2013 (UTC)

Comments (good)

• VE was too confusing, slow, limited and fragile, almost a lemon product: Due to the danger of VisualEditor cratering on any wp:edit_conflict (even an erstwhile one-word change), it was too fragile and risky for open release to an unsuspecting public, many of whom edit high-traffic articles where edit-conflict is more likely. It was implicitly limited to pages where only one user would be likely to edit at a time, without a warning that usage in high-traffic pages could easily result in total loss of all changes, dropping all tedious keystrokes when anyone else changed the same page. Then, the slow speed (unwarned) would lure people into tedious edits, where a common reaction would be to think, "system is slow just now" and continue to burn time in the slow interface hoping for a "faster tomorrow" which never comes. As others have noted, most markup directives are not hard to learn, and for users who understand finding text on a page, then a typical Ctrl-F search for a word/number to change, using the wikitext editor, would be more likely to fix any text inside any template or table or image caption. Think objectively here: VE gives a slow update, where some/many items cannot be changed, and then risks almost certain edit-failure when editing high-traffic articles. VE is undoubtedly slower, limited, confusing and frustrating, and that is why I Oppose the WYSIWYG-editor concept for newcomers, because people who cannot handle simple markup '''bold''' are unlikely to easily learn click-icons to insert cite templates. I would predict that VE would be a net turn-off to newcomers, as too confusing, slow, limited and fragile, but response will be difficult to measure, due to monthly editor-activity swings of +/-6% in various months. Some jurisdictions have "lemon laws" to protect consumers from inherently faulty products, and perhaps more people understand why now. -Wikid77 (talk) 13:28, 12 July 2013 (UTC)
• I do note that VE screws up what I'm sure many have done at some point: copying and pasting the wikitext of an article into a text editor, then working on it offline. This is OK as long as wikitext is kept (and frankly, given the WMF's recent actions, I don't take their word for it that will be kept indefinitely.) Double sharp (talk) 13:59, 30 July 2013 (UTC)

2. Buggy software should not become the default until it reaches a certain level of development.

Rushing forwards with a launch when critical bugs are still unfixed is not acceptable. Not undoing changes when severe bugs, such as the VisualEditor mangling the text of pages with <nowiki> tags, malformed links, and the like, are discovered is unacceptable. If this passes, the WMF is censured, and will be asked never to launch new features in this manner again. Adam Cuerden ^(talk) 23:04, 10 July 2013 (UTC)

Support (buggy)

1.  A m i t  ❤  04:50, 12 July 2013 (UTC)
2. Adam Cuerden ^(talk) 23:04, 10 July 2013 (UTC)
3. If you're going to cram a shitty add-on down our throats, make sure the shitty add-on works at the least. Don't phone it in. —Jeremy v^_^v ^Bori! 23:39, 10 July 2013 (UTC)
4. Vegaswikian (talk) 23:54, 10 July 2013 (UTC)
5. I agree that there were too many large bugs and missing features at the roll out, I'm not sure I support the tone of this question and I certainly don't support Jeremey's tone. Thryduulf (talk) 00:00, 11 July 2013 (UTC)
6. Patrick87 (talk) 00:06, 11 July 2013 (UTC)
7. Carrite (talk) 00:11, 11 July 2013 (UTC)
8. Kumioko (talk) 00:23, 11 July 2013 (UTC)
9. I agree that this should have been deployed first on test wiki, test, and then, when ready, bring here. — ΛΧΣ²¹ 01:07, 11 July 2013 (UTC)
10. It's too buggy to turn amateur editors loose with.—Kww(talk) 01:08, 11 July 2013 (UTC)
11. Pointless, though, because this is a recurring problem (remember Echo?). MER-C 01:23, 11 July 2013 (UTC)
12. Yeah, usually you opt in to betas, and don't just have buggy software shoved into your face. This almost feels like how Microsoft thought forcing a touch-oriented UI on everyone was a good idea. Or Gnome 3. ViperSnake151  Talk  01:40, 11 July 2013 (UTC)
13. Developers were allowed to dictate development. They mean well, but there was no defined test role. Robert McClenon (talk) 02:15, 11 July 2013 (UTC)
14. Rollout to IP editors must halt immediately; if experienced Wiki Editors are having problems, do we really need to give non-experienced and/or non-registered Wiki editors opportunities to stumble over yet more bugs, create yet more bad Wiki content, etc.? Scarletsmith (talk) 06:43, 11 July 2013 (UTC)
15. Support PantherLeapord (talk) 07:36, 11 July 2013 (UTC)
16. GiantSnowman 08:10, 11 July 2013 (UTC)
17. Lukeno94 (tell Luke off here) 10:52, 11 July 2013 (UTC)
18. I can't even understand why anyone would oppose this, and I've read the comments of people who say "oppose"--Paul McDonald (talk) 11:17, 11 July 2013 (UTC)
19. David Gerard (talk) 11:27, 11 July 2013 (UTC)
20. Bidgee (talk) 13:57, 11 July 2013 (UTC)
21. Insulam Simia (^talk/_contribs) 14:16, 11 July 2013 (UTC)
22. Obviously. Reaper Eternal (talk) 14:53, 11 July 2013 (UTC)
23. Minus all the anger and censuring part, but this software should not have been turned on as default in this state.  Sandstein  14:54, 11 July 2013 (UTC)
24. Support I can tolerate some minor bugs, but major bugs mangling basic things like these (which can be inserted from the source editor toolbar!!) just about pushes it over the line for me. Also, it is not even able to do harder tasks like math or table markup. Imagine how the new editors will be confused when they see them and can't figure out how it works, simply because it doesn't in VE. Still: agree completely with MER-C. Double sharp (talk) 15:12, 11 July 2013 (UTC)

    Er. The nowiki bug is nothing to do with not letting a user insert nowiki tags. Okeyes (WMF) (talk) 15:34, 11 July 2013 (UTC)

    What nowiki bug? There are officially no corruptions happening, so it must not be a bug - it's just the users not being clever enough to use the VE - David Gerard (talk) 21:15, 11 July 2013 (UTC)

    I need a new irony meter. — Arthur Rubin (talk) 21:27, 12 July 2013 (UTC)

    Misreading my statement completely. If wikitext can easily do nowiki-ing without corruption, and VE can't, then I fail to see how VE is an improvement at the moment, pure and simple. And all this has forced every edit that inserts nowiki tags to need confirmation (I just got that message today). What an utterly unnecessary waste of time, that could have been prevented simply by ensuring that the product was actually beta-worthy before it entered beta. Double sharp (talk) 11:24, 29 July 2013 (UTC)

25. Needless to say. Everyking (talk) 22:16, 11 July 2013 (UTC)
26. Yes. We had the notifications farce and now this; enwiki should not be used as a test. The software should work. Minor bugs can be coped with - software that is simply not fit for purpose is not acceptable. Black Kite (talk) 23:33, 11 July 2013 (UTC)
27. Obviously. Many potentially valid edits are reverted and constructive editors tagged only because of horrific markup. As a result, VE works against its goals. Materialscientist (talk) 08:18, 12 July 2013 (UTC)
28. Such an obvious no-brainer that it's astounding this even has to be said. - The Bushranger _{One ping only} 11:22, 12 July 2013 (UTC)
29. "Free encyclopedia anyone can edit" if only they knew not to click "Edit" to change a table or a math formula. Plus the "vote of no confidence" by experienced users judging the competence of wiki software or WMF plans. -Wikid77 13:43, 12 July 2013 (UTC)
30. --Akhilan (talk) 14:48, 12 July 2013 (UTC)
31.  TUXLIE  17:10, 12 July 2013 (UTC)
32. Seems obvious that it doesn't work, yet, and that experienced editors are spending more time fixing the buggy edits than the value of the edits made. I'm not sure I agree with the "never again", but this editor needs to be unreleased until the hundreds of bugs which actively damage articles without (apparently by design) notifying the editor of potential problems are fixed. — Arthur Rubin (talk) 21:26, 12 July 2013 (UTC)

    Obviously, only "never again" should things be released in this way - a poorly planned, poorly tested, unfinished, and known-to-be-buggy release is forced onto everyone, without an opt-out at launch, and followed by stonewalling when faced with criticism. Adam Cuerden ^(talk) 21:53, 12 July 2013 (UTC)

33. I wonder if the Visual Editor people see the same software we see.—Love, Kelvinsong talk 23:15, 12 July 2013 (UTC)
34. I agree and understand "reaches a certain level of development" to mean "is more of a benefit than a detriment". Pseudonymous Rex (talk) 00:34, 13 July 2013 (UTC)
35. Pretty please. Red Slash 09:18, 13 July 2013 (UTC)
36. Even the most yearned for new feature needs proper testing, and live implementation on some of our smaller wikis first. ϢereSpielChequers 14:52, 13 July 2013 (UTC)
37. Weak support I'd go for a milder phrasing, but yes, this does seem to have been rushed through before it was ready. Anaxial (talk) 18:04, 13 July 2013 (UTC)
38. Too many strange explosions. The Banner talk 23:11, 13 July 2013 (UTC)
39. Yes, buggy software can be op in, it should not be op out. Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:16, 14 July 2013 (UTC)
40. Ought to go without saying. Hullaballoo Wolfowitz (talk) 13:05, 14 July 2013 (UTC)
41. My boss would have my hide and I would likely be promptly given the path to the door if we released something like this to our users. Jguy _Talk^Done 13:35, 14 July 2013 (UTC)
42. The Foundation has clearly messed up here. Modest Genius ^talk 21:48, 14 July 2013 (UTC)
43. The way this has been handled is insane by any software development standars, let alone for a software on the 5th most visited page of the Internet. -- cyclopia^speak! 10:16, 15 July 2013 (UTC)
44. The current iteration of VisualEditor is practically broken; it is the Windows ME of editing programs. Like ME it has some good ideas, but it is buggy as heck and not useful to anyone who uses Wikipedia for serious editing. Toa Nidhiki05 18:49, 15 July 2013 (UTC)
45. Is it a governmental project that must be finished on a set deadline no matter what? Whatever one thinks about Wikipedia's interface, it is certainly not so hopeless that we would have to replace it instantly and with just anything... It might be acceptable to try out a new and potentially buggy feature for a day, but one should be ready to roll the change back and listen to the feedback. Although, hopefully, WMF will understand that without a "censure". --Martynas Patasius (talk) 20:04, 15 July 2013 (UTC)
46. postdlf (talk) 21:33, 15 July 2013 (UTC)
47. As a general principle, not specifically making any call with regard to VE. Lankiveil ^{(speak to me)} 11:37, 16 July 2013 (UTC).
48. ¿3family6 _contribs 13:10, 16 July 2013 (UTC) I am certainly willing to tolerate some bugginess, and I understand the idea of having ordinary users test the software. However, seeing the level of major bugs in VE, and the lack of support for wikitables and many templates, I think the launch of this software was premature.
49. Crap should not be activated. Matthiasb (talk) 15:53, 19 July 2013 (UTC)
50. --Ilya (talk) 18:49, 19 July 2013 (UTC)
51. — Scott • talk 20:43, 19 July 2013 (UTC)
52. I can understand the rush to meet an announced deadline because of the missed deadlines in the past, but in that case it should not have been opt-out but opt-in. DGG ( talk ) 21:24, 19 July 2013 (UTC)
53. I concur with User:Lankiveil's remarks a few lines up. When a working option and a buggy beta exist, buggy beta ≠ default, regardless of the environment. --Cryptic C62 · Talk 00:35, 20 July 2013 (UTC)
54. Of course. It seems a rhetorical question but in this case is necessary. I strongly agree: buggy softwares should stay out the main wikis until they have reached a good stability/compatibility level. --Lucas (talk) 00:51, 20 July 2013 (UTC)
55. A rushed introduction of new software shifts the workload from testing engineers to unpaid volunteers who came here to contribute content, not to fix the mess caused by the early software release. --AFBorchert (talk) 08:08, 20 July 2013 (UTC)
56. I agree. Never use a buggy software for productive use. --Roberto Segnali all'Indiano 12:55, 22 July 2013 (UTC)
57. Strong agreement, even more now that we see that WMF is sticking to a schedule to roll out to as many people as possible before fixing the bugs and taking into account (so-called) enhancements. --NicoV ^{(Talk on frwiki)} 04:09, 23 July 2013 (UTC)
58. Its time will come. PhnomPencil (talk) 10:04, 24 July 2013 (UTC)
59. --wdwd (talk) 15:37, 24 July 2013 (UTC)
60. Fully support this conclusion. WMF needs to work a whole lot better at making sure that the usability of the site is not compromised for many users as badly as it has been with the visual editor. What works great in your little lab with brand-new computers and super high-speed connections can be completely unworkable out in the real world. VanIsaac_{WS Vex}^contribs 21:58, 25 July 2013 (UTC)
61. Support. An obvious principle, which this project seems to have lost sight of in a tangle of wishful thinking. Gandalf61 (talk) 09:46, 26 July 2013 (UTC)
62. Unfortunately, it is not ready, and I can't see it being stable within a few weeks. The number of bugs being identified is increasing fast. As a bare minimum, the parser must be approaching perfect - problems causing dirty diffs must be fixed within a few days, which means having developers that are not on a death march. In addition, many of the UI components have not been properly designed to be fit for purpose, which means we're going to see more rapid deploys of betas and lots more bugs as a result. Also, if the VE is the default, we have to update all the help pages, but the software is a moving target now. The Help pages will be regularly showing old screenshots. Very unprofessional. I will opt-in only if I can switch editors mid-edit; I beg the product managers and devs to build this functionality into core (user:John Vandenberg/switch editor.js) if you want the majority of the community to help you beta testing this beast. John Vandenberg ^(chat) 12:26, 27 July 2013 (UTC)
63. Gengis Gat (talk) 12:38, 27 July 2013 (UTC)
64. Especially in terms of speed. If the goal is to attract new users, a slow, buggy interface will do exactly the opposite. If I were a new user coming to Wikipedia today, and got slapped across the face with VE, I might have the technical skill to figure out that a better interface is available, but many who don't will walk away in frustration. Having it "opt-in", even if it were to ask at random "Would you like to try our new editor interface that's in development? It may still have some problems, but your feedback will help us to solve them.", would warn those editors what they're in for, and allow those who aren't interested to say no thank you. Having it as the default for the "edit" link before it's completely production-ready is not the way to go. Seraphimblade ^{Talk to me} 05:00, 29 July 2013 (UTC)
65. --Shadak (talk) 14:14, 29 July 2013 (UTC)
66. --Rushton2010 (talk) 18:45, 29 July 2013 (UTC)
67. Obviously. --Anthonyhcole (talk · contribs · email) 00:18, 31 July 2013 (UTC)
68. Yes, this really is just obvious common sense. --Tryptofish (talk) 23:08, 31 July 2013 (UTC)
69. Obviously software which has major defects that prevent normal use should not be widely deployed. Fortunately, Visual Editor is not in that position, and is more than adequate for a variety of day-to-day editing tasks; and we still have the option to use the old version when it's occasionally necessary due to limitations. In short, it has reached a "certain level of development." Dcoetzee 02:36, 2 August 2013 (UTC)
70. VE is still mangling pages. A quick look at WP:VE/F should convince anyone that VE is not ready for deployment in any form. —Wasell^(T) 11:17, 2 August 2013 (UTC)
71. Never ever default to VE. It should be now and forever an OPT-IN. –Wine Guy~Talk 14:41, 2 August 2013 (UTC)
72. Agreed. Gryllida 08:10, 6 August 2013 (UTC)

Oppose (buggy)

1. I think a lot of the sturm and drang (e.g. people wanting to turn off the tab itself for themselves!) is overdone complaining about a change, like people who get upset when a forum changes background color. The issue of "high number of bad edits" is a bigger concern, but I haven't encountered a single one personally, so it must not be that ubiquitous. (Sometimes people are a little sophistic...like those who complaint about fixing image sizes because of those who have a default...this was tracked down and like 300 people out of several million readers actually had a set preference.) Also, to be honest, the thing has been talked about for years and never gotten anywhere. Plus the Community is very over conservative and insular (and doesn't think of current non-editors). So throwing it over the fence and fixing later is a legitimate approach. Sorry, but "ship it". TCO (talk) 01:09, 11 July 2013 (UTC)
2. I strongly object to the statement being made here. While it had many bugs of various degrees of severity, VE did not have "severe bugs" that "mangled the text of pages" at the time when it was enabled for logged-in users. I also object to "censuring" the WMF's wonderful development team in such a way. — This, that and the other (talk) 01:21, 11 July 2013 (UTC)

   I need yet another new irony meter. VE did (and still does) have "severe bugs" that "mangled the text of pages." — Arthur Rubin (talk) 19:32, 4 August 2013 (UTC)

   Perhaps you have different ideas of what counts as "severe". That's okay: you don't have to agree on that point. Whatamidoing (WMF) (talk) 20:12, 5 August 2013 (UTC)

   I'm pretty sure the VE breaking Wikilinks counted as a hugely major bug. Lukeno94 (tell Luke off here) 20:21, 5 August 2013 (UTC)

   Silently deleting (visible) infoboxes seems severe to me. (Invisible infoboxes are another matter; I don't see how VE could avoid deleting them.) — Arthur Rubin (talk) 01:23, 6 August 2013 (UTC)

   And TTO's definition might set the bar a little higher. I'm pretty sure it includes this one, which was fixed immediately before release, but he's not "wrong" just because he doesn't agree with you. You're free to call deleting an infobox by pressing the backspace key one time too many a "severe bug" if you want, but you can't force other people to accept your personal judgment.
   BTW, the latest word on the nowiki bugs is that they have dropped considerably and should halve again at the next update. Whatamidoing (WMF) (talk) 23:08, 6 August 2013 (UTC)

   This is querulous logic-chopping, and your team has been called on this sort of logic-chopping before. An interface that encourages such errors is a bad interface, and this counts as a serious problem - David Gerard (talk) 10:55, 7 August 2013 (UTC)

   David, I know that you count this as a serious problem. I happen to have spent a lot of time this last month making sure that my boss believes that the addition of nowiki tags around misplaced wikitext markup, which Luke mentioned, was the most significant problem affecting the English Wikipedia (although, oddly, not other places. I've never yet seen it at the Japanese Wikipedia, for example). But TTO is expressing his personal opinion here. In his opinion, TTO believes that there were no "severe" bugs. TTO is entitled to his opinion, and TTO is entitled to express it here without having people make sarcastic remarks about his opinion. Nobody has any business telling TTO that TTO's personal subjective opinion is wrong. This is not some sort of totalitarian state that requires everyone to have the same opinion about what "counts as a serious bug". It is not "querulous logic-chopping" to defend TTO's right to his personal opinion in a discussion that specifically requested people's personal opinions. I'd do the same for you, too: I want to know what you think, not what you think some other editor would approve of you saying. Whatamidoing (WMF) (talk) 17:41, 7 August 2013 (UTC)

   If it was really that hard to convince your boss that the nowiki bug was a serious bug... no wonder the VE is a pile of shit. Lukeno94 (tell Luke off here) 18:20, 7 August 2013 (UTC)

   The challenge was not convincing him that it was "a" serious bug, but convincing him that it was the most significant problem. There were splashier bugs, but there were none so frequent in the first week of July. It's improved a lot since then; this only appears in about 1 out of 400 edits at the moment (down from a high of ~11% or so in some hours). Whatamidoing (WMF) (talk) 19:00, 7 August 2013 (UTC)

3. Oppose based on the wording of this. I support the principle broadly, but I think this goes way too far in demonizing people who are working hard. --Jayron32 01:42, 11 July 2013 (UTC)
4. The principle stated in the heading of this section makes sense, but there are degrees of bugginess, which I think may be somewhat exaggerated here. One of the best way to identify bugs and useability issues is to roll software out to a large user base. - MrX 02:23, 11 July 2013 (UTC)
5. The statement is so vaguely worded as to be meaningless (or alternately, to be interpreted to mean pretty much anything you want). What counts as "buggy"? What counts as "a certain level of development"? There are bugs—including "severe" ones—in pretty much all complex, production-quality software. —Psychonaut (talk) 08:25, 11 July 2013 (UTC)
6. • • • Peter (Southwood) ^(talk): 19:29, 11 July 2013 (UTC)
7. Too vaguely worded to be meaningful. Also I strongly dislike the idea of a bunch of the old guard reprimanding the WMF for what is probably the most newbie-focussed development of Wikipedia for years. --LukeSurl ^{t c} 00:30, 12 July 2013 (UTC)
8. Per Jayen. I think they had to take the plunge. Let's refine it as quickly as possible, though. Tony (talk) 08:57, 12 July 2013 (UTC)
9. Chase me ladies, I'm the Cavalry (Message me) 11:54, 13 July 2013 (UTC)
10. Legoktm (talk) 02:34, 22 July 2013 (UTC)
11. Oppose, in that case we should stop using Mediawiki! ·addshore· ^{talk to me!} 08:09, 2 August 2013 (UTC)
12. Oppose, people are impatient and unappreciative of how valuable a change this is. They'd rather kick the can forward and forward. To be honest, I think many people here are just angry that the general public will now be able to play in what they formerly liked to think of as their sandbox. No amount of bugfixing and delays would satisfy them and make them call it not "buggy software" - and if it was delayed to fix those bugs, these same people would be saying the project was a boondoggle and waste of resources and should be scrapped. Many are saying that right now out of one side of their mouth, while the other side says it should be drawn back for "bug fixes."

They simply hate VE, but if they do not like it, they do not have to use it. As someone who loves tech and works in the tech industry: there are a lot of people outside tech who are very smart. Even though they don't make a hobby of learning technical matters like markup. Wikipedia is missing out on their knowledge, a vast knowledge of body, because we insist on using markup as a bar of entry and hazing maneuver. Again - you do not have to use it. Enough of this politicking and power plays - of trying to shove VE on the backburner or make new users dig through an unfamiliar options menu to realize there even is a visual editor. --Monk of the highest order^(t) 04:03, 12 August 2013 (UTC)

Comments (buggy)

What does "the default" mean? WhatamIdoing (talk) 23:28, 10 July 2013 (UTC)

It's now part of everyone's editing of Wikipedia, and cannot be completely turned off in any way. This was neither opt-in, and even providing information on a user-created method to opt out was actively discouraged by the WMF team behind it, e.g. statements such as "I feel it would totally undermine the software proper to fire everyone at an instant switch to permanently disable the VE". It's buggy code, it's going to remain buggy code for some time, and to insist that thousands (or is it millions?) of users have to have it active is ridiculous. Adam Cuerden ^(talk) 23:34, 10 July 2013 (UTC)

So Javascript is "part of everyone's editing of Wikipedia, and cannot be completely turned off", so do you consider that "the default"? It also frequently has critical bugs open. Shall we remove Javascript? Or is it only software that feels like a change to you that should be bug-free before normal users get automatic access to it? WhatamIdoing (talk) 23:41, 10 July 2013 (UTC)

I think what's meant here is software the developers have control over, thus not Javascript. —Jeremy v^_^v ^Bori! 23:42, 10 July 2013 (UTC)

The devs do have control over whether Wikipedia uses Javascript. WhatamIdoing (talk) 02:06, 12 July 2013 (UTC)

Your point? Does it cause edits which were meant to be constructive to get malformed? The last time I checked, JS didn't do that. The aim of VE is to encourage new editors to edit. So, if their edits get messed up by the critical bugs, then isn't this a serious problem (currently-and-will-be-for-some-time buggy VE shooting itself?)? No matter what the proportion of messed-up edits is, the fact that this can happen at all for a released-to-everyone-and-impossible-to-turn-off-properly tool is worrying. Double sharp (talk) 15:17, 11 July 2013 (UTC)

• IDEA: "Buggy software should not become the default". Full stop. --R.S. Peale (talk) 05:05, 12 July 2013 (UTC)
• I agree with the spirit of this (that the launch was done badly, and that the current version has enough bugs that it should not have been launched), but I disagree with the harshness of the tone, and so cannot support. – Quadell ^(talk) 15:44, 9 August 2013 (UTC)

3. VisualEditor should have a way to be turned off fully, easily, and without continuing to leech resources

At the moment, the VisualEditor can be hidden by way of a gadget found in user preferences, but in a location most users will not look, and code for the VisualEditor will continue to be loaded, as it cannot be disabled. According to WP:VisualEditor/FAQ, this is by design, in an attempt to force users to use it, despite the editing section of User Preferences being fairly well-hidden already. The code to allow it to be disabled exists; it was active in the Editing preferences up until the launch. If this motion passes, the Wikimedia Foundation is requested to restore this code immediately. Adam Cuerden ^(talk) 23:04, 10 July 2013 (UTC)

Support (off)

1. Adam Cuerden ^(talk) 23:04, 10 July 2013 (UTC)
2. Andy Dingley (talk) 23:26, 10 July 2013 (UTC)
3. Diannaa (talk) 23:32, 10 July 2013 (UTC)
4. —Jeremy v^_^v ^Bori! 23:36, 10 July 2013 (UTC)
5. doktorb _words^deeds 23:53, 10 July 2013 (UTC)
6. Vegaswikian (talk) 23:54, 10 July 2013 (UTC)
7. Regardless of how many resources something consumes, disabling something should disable it not hide it. Thryduulf (talk) 00:01, 11 July 2013 (UTC)
8. Patrick87 (talk) 00:07, 11 July 2013 (UTC)
9. Carrite (talk) 00:12, 11 July 2013 (UTC)
10. As much as I like having this option, it still is a bit buggy, so for now this should be an option. Kevin Rutherford (talk) 00:18, 11 July 2013 (UTC)
11. The current method is a workaround only and still launches all the code in the background, wasting resources and increasing loading times. We need a proper off switch, not a hack. Kumioko (talk) 00:24, 11 July 2013 (UTC)
12. Yes a obvious off switch is essential. I'm also concerned about IP's who won't be able to use the gadget, won't know what the difference between Edit and Edit Source is and won't be able to do many editing tasks like mathematics.--Salix (talk): 00:40, 11 July 2013 (UTC)
13. Indeed. — ΛΧΣ²¹ 01:07, 11 July 2013 (UTC)
14. Beyond this, it should be disabled in this manner until it works, available only to editors that are committed to repairing any damage that it causes.—Kww(talk) 01:09, 11 July 2013 (UTC)
15. Not sure why this was not provided, really. — This, that and the other (talk) 01:22, 11 July 2013 (UTC)
16. MER-C 01:24, 11 July 2013 (UTC)
17. Choice is always a good thing. I also endorse Salix' comment.- MrX 02:27, 11 July 2013 (UTC)
18. Yeah --Vigyani_talk^{ਯੋਗਦਾਨ} 05:04, 11 July 2013 (UTC)
19. Support PantherLeapord (talk) 07:36, 11 July 2013 (UTC)
20. GiantSnowman 08:11, 11 July 2013 (UTC)
21. Lukeno94 (tell Luke off here) 10:52, 11 July 2013 (UTC)
22. Support hiding the "off switch" is a bad idea and has been very frustrating to me. I've noticed that frustration to others as well.--Paul McDonald (talk) 11:19, 11 July 2013 (UTC)
23. It has been made unnecessarily difficult and obscure to disable it, they keep breaking the off switch and saying "not in scope" when called on it, and it appears deliberate to try to make it as default as possible even for people who really seriously don't want it. This is profoundly obnoxious, however good the claimed intentions - David Gerard (talk) 11:27, 11 July 2013 (UTC)
24. Bidgee (talk) 13:59, 11 July 2013 (UTC)
25. Insulam Simia (^talk/_contribs) 14:16, 11 July 2013 (UTC)
26. Is this seriously in doubt?  Sandstein  14:55, 11 July 2013 (UTC)
27. Yes, please. I'm not interested in yet more javascript conflicts. Reaper Eternal (talk) 15:06, 11 July 2013 (UTC)
28. If someone wants something disabled, then disable it for real, not just hide it in the corner and block it from view, let it carry on running and pretend it was disabled. @TCO: The big deal is that even for people who don't want it, it does not get turned off, just hidden, and see David Gerard's comment. This, to me, is a big problem. (Oh, and orange-bar whining? That was also very useful because it was very visible. Was that text not very easy to notice? That's how the OBOD worked: it jumps out at you. Does the little red number jump out at you? It does not.) Double sharp (talk) 15:20, 11 July 2013 (UTC)
29. →Davey2010→→Talk to me!→ 15:38, 11 July 2013 (UTC)
30. Indeed. Wasting resources and increasing loading times. Did you also consider those who already have internet speed problem when you making this, that's not fair. If someone wants something disabled, then disable it. We need a proper off switch, Obvious off switch is essential. Not sure why this was not provided, really. So low speed internet now I really cant even edit my user page, very frustrating KhabarNegar ^Talk 16:39, 11 July 2013 (UTC)
31. The most user-friendly interface is that one which will be friendly to the most hardware/bandwidth-compromised user. There is still a world majority of population who are just getting into internet through their primitive dial-up/GPRS connections and cheap terminals. If Wikipedia is anything for the massive good and common prosperity of world, this should be the priority. So, keep that fundamental editor option always and give any experience luxuries to those who can afford. ViswaPrabhaവിശ്വപ്രഭ^talk 19:43, 11 July 2013 (UTC)
32. Absolutely. It's just ridiculous that you can't properly and easily disable it. Everyking (talk) 22:19, 11 July 2013 (UTC)
33. Yes, obviously; the current method is simply a hack. Black Kite (talk) 23:32, 11 July 2013 (UTC)
34. Yes, the additional VE Java code is not as light as it was (and is) supposed to be. Performance slowdown is significant and should be avoided by all means. Materialscientist (talk) 08:24, 12 July 2013 (UTC)
35. Forcing editors to use something that they don't want to use is a sure way to run editors off of the project, not to recruit or retain them. - The Bushranger _{One ping only} 11:24, 12 July 2013 (UTC)
36. I didn't mind before, but if it's slowing down pages for people who don't want it, then yes.—Love, Kelvinsong talk 23:16, 12 July 2013 (UTC)
37. Red Slash 09:18, 13 July 2013 (UTC)
38. Yes, should be much easier to properly disable it. Anaxial (talk) 18:05, 13 July 2013 (UTC)
39. Yes, please. When I want to get rid of it, it should be possible. The Banner talk 23:12, 13 July 2013 (UTC)
40. Support, the gadgets are not working today which means the VE is back. Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:13, 14 July 2013 (UTC)
41. Yes, and once an editor turns it off, it should stay off! Hullaballoo Wolfowitz (talk) 13:07, 14 July 2013 (UTC)
42. Fully Support - no matter how many times I turn it off in the gadgets section in the Preferences (to the extent of removing the Gadgets tabs from Preferences), it keeps turning itself on and now it has killed my other gadgets including twinkle, Purge Clock and navigation popups.... TURN IT OFF NOW!..this useless feature belong in some small wiki which hardly gets edited, NOT WIKIPEDIA.--Stemoc (talk) 13:20, 14 July 2013 (UTC)

    That isn't a problem caused by VE, as I don't have VE disabled and I'm having the same problem as you, so I'll assume the gadget system isn't currently working (it did this the other day). Insulam Simia (^talk/_contribs) 13:24, 14 July 2013 (UTC)

    Never had any problem with gadgets for years and all of a sudden VE gets introduced and i keep having problems with my gadgets, its definitely a problem with VE scripts and some of the gadgets...the worst part is that instead of trialling VE as a script/gadget, they made it into a FORCED FEATURE.....--Stemoc (talk) 14:27, 14 July 2013 (UTC)

    No - see WP:VPT#Where is Gadgets ? Insulam Simia (^talk/_contribs) 14:28, 14 July 2013 (UTC)

43. Obvious Support. Even though it was recently "reduced to 4KB", it STILL loads crap that I don't want to load. I don't want to hide it, I want to remove it until such a time where it is a viable non-buggy editor. Jguy _Talk^Done 13:35, 14 July 2013 (UTC)
44. Wikiklaas (talk) 14:05, 14 July 2013 (UTC)
45. If you're going to provide an opt-out (which you should), then it should really be an opt-out, and users should be presented with the options, not required to go hunting in obscure areas of the site. Modest Genius ^talk 21:50, 14 July 2013 (UTC)
46. cyclopia^speak! 10:17, 15 July 2013 (UTC)
47. —WLM / ? Come on. Only the IDEA to give no option to turn off. 17:28, 15 July 2013 (UTC)
48. Users who don't want to use VisualEditor (and there are a great deal of us) should not be required to use it, period. The WMF needs to respect the wishes of its established editing base. Toa Nidhiki05 18:51, 15 July 2013 (UTC)
49. postdlf (talk) 21:34, 15 July 2013 (UTC)
50. ¿3family6 _contribs 13:20, 16 July 2013 (UTC) I understand releasing the software to a massive user base in order to find bugs and needed features, but there should have been an off-switch built in.--¿3family6 _contribs 13:20, 16 July 2013 (UTC)
51. --Ilya (talk) 18:50, 19 July 2013 (UTC)
52. — Scott • talk 20:44, 19 July 2013 (UTC)
53. --Cryptic C62 · Talk 00:38, 20 July 2013 (UTC)
54. no doubts. --Lucas (talk) 00:53, 20 July 2013 (UTC)
55. This is essential. People contribute content using slow Internet links with low bandwidth, using aged computers and software configurations. If extended JavaScript bloat is enforced to all of them, you force them to switch JavaScript off even where a bit of JavaScript would have been desirable. Please allow the editors to tailor the amount of to be loaded JavaScript code exactly to their needs. --AFBorchert (talk) 08:12, 20 July 2013 (UTC)
56. I don't even want to participate with the usage of the Visual Editor. My largest fear is trying to clean up from messes made by a buggy editor, but that is minor compared to constantly being reminded of the thing and having it get in the way. It definitely needs an off-switch. No, the "Edit Source" is insufficient and IMHO a hack of a hack at best. If it is just a matter of making a simple change in the configuration file of en.wikipedia, why was that not enabled in the first place? --Robert Horning (talk) 04:26, 22 July 2013 (UTC)
57. Without any doubt! --Roberto Segnali all'Indiano 12:55, 22 July 2013 (UTC)
58. Strong support. This is a reasonable request, that isn't even technically difficult to implement and that won't add to the technical debt because the wikitext editor is anyway supposed to be kept available. --NicoV ^{(Talk on frwiki)} 04:09, 23 July 2013 (UTC)
59. This is the statement I agree most with. PhnomPencil (talk) 10:05, 24 July 2013 (UTC)
60. --wdwd (talk) 15:30, 24 July 2013 (UTC)
61. Absolutely support. It is unconscionable that they failed to do so from the beginning. The link to opt out should have been advertised on banners weeks before the rollout, so that experienced editors never had to deal with this abomination. VanIsaac_{WS Vex}^contribs 22:03, 25 July 2013 (UTC)
62. Support. A waste of time and irritant to most users. But all of this was known by WMF based on the limited "testing". There should be a firewall with Wikia, which is a for-profit corporation with too many ties to WMF insiders (some of whom have financial interests in Wikia. Investing WMF funds and stafftime and forcing WP editors to surve as guinea pigs for Wikia's R&D may be illegal, violating WMF's not for profit status and perhaps anti-trust laws. Kiefer.Wolfowitz 22:39, 25 July 2013 (UTC)
63. Yes. If I don't want to use VE I shouldn't have to see it or be affected by it in any way. Gandalf61 (talk) 09:49, 26 July 2013 (UTC)
64. Why not allow oldhands to keep editing the code like in the old days? --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 21:34, 26 July 2013 (UTC)
65. John Vandenberg ^(chat) 12:33, 27 July 2013 (UTC)
66. Giving more options to editors is positive, but only if users are given a free (a really free) choice about whether using them or not. Gengis Gat (talk) 12:43, 27 July 2013 (UTC)
67. I know IP editors don't carry much weight around here but that's how I prefer to edit, and I'm quite productive if I must say so myself. I'd just like to say that I hate this visual editor thing and support any proposition that would cause it to be turned off by default. I haven't edited anything for a few months, I come back to read about the Occupation of the Channel Islands and find a name spelled wrong. I click edit section to fix it and I'm faced with a monstrosity of slow-loading javascript that I don't want to figure out just to change a single letter and have to click through to "edit source," which for some reason also now takes an eternity to load. Please think about IP editors when you're figuring out what to do and either disable this horror without requiring an account or put edit source links on the sections too at least. 198.72.143.40 (talk) 22:01, 27 July 2013 (UTC)
68. "Disabled" should mean "disabled". And any features to disable VE should be available as long as VE exists, not just during its "beta" phase (quotes intentional, I don't think one could really even call it alpha-ready yet). Seraphimblade ^{Talk to me} 04:42, 29 July 2013 (UTC)
69. !!! --Shadak (talk) 15:59, 29 July 2013 (UTC)
70. --Rushton2010 (talk) 18:47, 29 July 2013 (UTC)
71. Implementing the thing was a good idea. Mandating its use is a very bad one. Dementia13 (talk) 12:37, 30 July 2013 (UTC)
72. 00:20, 31 July 2013 (UTC)
73. Per the opening statement for this section. (And I find the now-you-see-it-now-you-don't "edit source" link rather tedious.) --Tryptofish (talk) 23:11, 31 July 2013 (UTC)
74. I thought we have it already! Isn't the gadget to disable VE working properly? -- ɑηsuмaη ^{« ৳ᶏ ɭϞ »} 15:21, 1 August 2013 (UTC)
75. Of course there should be a way... ·addshore· ^{talk to me!} 08:08, 2 August 2013 (UTC)
76. Make this thing go way completely and forever. –Wine Guy~Talk 14:43, 2 August 2013 (UTC)
77. Agreed, should not be on by default for new users. Gryllida 08:11, 6 August 2013 (UTC)
78. – Quadell ^(talk) 15:46, 9 August 2013 (UTC)

Oppose (off)

1. Silly, for the reasons as above. You have a little tab on your screen, so freaking what! This is like orange bar whining or edit button on side of page moving whining. You still have very easy access to the way you edited before.TCO (talk) 01:11, 11 July 2013 (UTC)
2. Oppose, because no one ever has to use it or install any gadget or flip any preference switch to avoid using it. Just click the "edit source" link which is available on every single page. I would support changing the phrasing of the edit links (for example, making the "edit" link read "Visual Editor" and making the "edit source" link read merely "edit", but that's not what this is proposing). --Jayron32 01:45, 11 July 2013 (UTC)

   That's a good idea, I second that. Can you make it happened? -- ɑηsuмaη ^{« ৳ᶏ ɭϞ »} 15:34, 1 August 2013 (UTC)

3. It can be turned off or ignored. VE has problems, but this is not the problem. Robert McClenon (talk) 02:17, 11 July 2013 (UTC)
4. Just click on "Edit source" instead. Tony (talk) 08:58, 12 July 2013 (UTC)
5. Chase me ladies, I'm the Cavalry (Message me) 11:55, 13 July 2013 (UTC)
6. Per Arthur Rubin below. If no significant amount of resources are being consumed, and it's not interfering with anything else, then "hiding" is functionally equivalent to "disabling". —Psychonaut (talk) 08:00, 15 July 2013 (UTC)

   It's that sort of sloppy analogy that is the entire reason this thing is broken. Rule 1 of coding/programming: don't waste resources when it is easy to avoid doing so! Lukeno94 (tell Luke off here) 11:59, 15 July 2013 (UTC)

   Rule #1 of programming is to do the most straightforward thing that works, and worry about performance if that's not sufficient. Premature optimization is the root of all evil. Dcoetzee 02:58, 2 August 2013 (UTC)

7. I'm sympathetic to people with limited bandwidth, but VE is a drop in the bucket, particularly when disabled (the main part of the JS is loaded on demand when the feature is used, according to my debug console). The graphics on the site (even just the logo) use an order of magnitude more bandwidth. People complaining about its bandwidth usage are looking for excuses. Mobile Wikipedia is already available for people who are really bandwidth constrained, and does not have VE. Dcoetzee 02:58, 2 August 2013 (UTC)

Neutral (off)

1. The damage done when hidden is not significant, in comparison to all the other tabs which also can only be hidden, rather than removed. On the other hand, if there are cases where the presence of VE prevents edits from working properly (and, can anyone swear it cannot happen), there should be a way to turn it off entirely. — Arthur Rubin (talk) 21:31, 12 July 2013 (UTC)

Comments (off)

For those who like numbers, VisualEditor is responsible for about 4 KiB of what your computer receives when you load (click on/read/view) an article or userpage. That's about 2% of the page (or less: the estimated percentage is pre-Universal Language Selector). WhatamIdoing (talk) 23:32, 10 July 2013 (UTC)

I both support this and at the same time agree completely with WhatamIdoing. For those who haven't looked recently, WP sends you reams of JS lately on every page load, most of which is of questionable value. Gigs (talk) 14:21, 11 July 2013 (UTC)

I don't see a need to turn it off if the (edit|edit source) options were permanently visible, but activating the edit source on mouseover remains annoying. That said I don't see why it should not be easily disabled by those who don't like it. I don't need it, and mostly don't use it, and if I turn it off it will be because I don't like the flickering edit source links. Then I won't use it at all. • • • Peter (Southwood) ^(talk): 19:42, 11 July 2013 (UTC)

There is in fact a proper off switch, it just hasn't been enabled on en:wp - David Gerard (talk) 22:37, 11 July 2013 (UTC)

For what its worth @Jdforrester (WMF): closed the bug as WONTFIX but it then got reverted.--Salix (talk): 18:14, 22 July 2013 (UTC)

• Well, closing that as WONTFIX shows just how out of touch the WMF are, but I'm glad it was reverted. Rule number one of programming: don't waste any resources that are easily conserved! Lukeno94 (tell Luke off here) 18:53, 22 July 2013 (UTC)

4. The manner of the launch was unduly aggressive

The sections on WP:VisualEditor/FAQ entitled "Can the editors here order the developers to turn this off?" and "Why does no standard user preference to disable VisualEditor exist?", as well as similar behaviour elsewhere, are little more than attempts to bully the community into accepting the VisualEditor, whether they want to or not. This goes against a basic foundation of Wikipedia, as laid out in the Five pillars: Civility. The launch should have attempted to be responsive to the attitudes of the Wikipedia community. Adam Cuerden ^(talk) 23:04, 10 July 2013 (UTC)

Support (manner)

1. Adam Cuerden ^(talk) 23:04, 10 July 2013 (UTC)
2. See also WP:Flagged revisions. —Jeremy v^_^v ^Bori! 23:38, 10 July 2013 (UTC)
3. Vegaswikian (talk) 23:54, 10 July 2013 (UTC)
4. Patrick87 (talk) 00:07, 11 July 2013 (UTC)
5. Kumioko (talk) 00:25, 11 July 2013 (UTC)
6. It appears rollout is governed by by a roadmap specifying when things must happen. There is little option to say, wait a moment we are just not ready yet to move out of alpha yet. Concerns of users are nothing compared to the roadmap.--Salix (talk): 00:40, 11 July 2013 (UTC)
7. Support, because the deployment was driven by the developers, and not by interaction between developers and testers.
8. Support PantherLeapord (talk) 07:36, 11 July 2013 (UTC)
9. Support I don't think it was aggressive in a hostile nature, but it was definitely aggressive in a "hurried" or "rushed" nature.--Paul McDonald (talk) 11:21, 11 July 2013 (UTC)
10. Way too aggressive, and I'm a big fan of the VE project in general - David Gerard (talk) 11:27, 11 July 2013 (UTC)
11. Insulam Simia (^talk/_contribs) 14:16, 11 July 2013 (UTC)
12. A little ... I think that paragraph was worded poorly. Developers of any software are obligated to work with the stakeholders to get a product that works. I can understand the desire to avoid "editor consensus" which has become a tarpit where things go to die from endless filibustering. At the same time, paragraphs like the one cited, along with a lack of prompt, real communication (as in, "hey, that is indeed a lot of major bugs you've found, we are delaying the deployment schedule right away"), did lead to a widespread perception of arrogance or aggressiveness. All that said, I can definitely understand where the development team is coming from. So, mostly a PR problem rather than an actual problem. Users needed to be assured that things weren't recklessly plowing forward and there was nothing that could be done about it. Gigs (talk) 14:27, 11 July 2013 (UTC)
13. Support per Salix. (@TCO: the discussions are actually productive. One of the main problems we have with these roll-outs is that the WMF seems to first not seek our viewpoints and then try to ignore them. Discussing the issues would no doubt lead to us having a more positive view and such RFCs not happening, because we would be able to work together for a better compromise solution.) Double sharp (talk) 15:33, 11 July 2013 (UTC)
14. →Davey2010→→Talk to me!→ 15:37, 11 July 2013 (UTC)
15. I feel, this was unprecedentedly hurried in such a way as to cause shock and awe. Typically, people hate changes. But they would certainly start appreciating changes for the better if they were brought gently and patiently. ViswaPrabhaവിശ്വപ്രഭ^talk 19:49, 11 July 2013 (UTC)
16. Everyking (talk) 22:20, 11 July 2013 (UTC)
17. I'm not sure "aggressive" is the right word, but the responses to people saying they didn't want to use VE when it was rolled out weren't optimal at all - instead of "we're sorry to hear that you don't like it and hope you'll try it again in the future", they were almost universally "you'll like it if you try it". While it may or may not be true, that's something for an editor to decide in due time, not to have pushed at them. - The Bushranger _{One ping only} 11:26, 12 July 2013 (UTC)
18. See my comments at Wikipedia talk:VisualEditor/A/B test—Love, Kelvinsong talk 23:18, 12 July 2013 (UTC)
19. Same as 2 - Launch was dictated by development without a QA role. Robert McClenon (talk) 16:22, 13 July 2013 (UTC)
20. The Banner talk 23:13, 13 July 2013 (UTC)
21. Consensus should have been gained beforehand, and a suitable testing and deployment schedule (~a few months) developed. Instead, we had no announcement, a sudden imposition with only a couple of weeks notice, and help pages that basically told us to sod off if we didn't like it. That's not a good way to run a collaborative project. Modest Genius ^talk 21:53, 14 July 2013 (UTC)
22. Agree that I felt somewhat force-fed on this thing. -- cyclopia^speak! 10:18, 15 July 2013 (UTC)
23. postdlf (talk) 21:43, 15 July 2013 (UTC)
24. Looks like that... The roadmap (with other evidence) does create an impression that WMF considered their own plans and schedules to be extremely important and everything else (lack of bugs, acceptance of existing users etc.) to be just minor details... For example, the results of A/B test, that should have been used to decide if the deployment was a good idea, doesn't seem to be processed until now. The result is predictable: they achieved the "major" goal and failed with everything else... Also, the statements from representatives of WMF (like [5]) now create an impression (true or false) that the attitude there is and was "They will hate it, but, eh, who cares about them!". I don't think that's a good way to win many friends... Just as all good Wikipedians (perhaps more, since WMF is at least partially responsible to the community and exists to help and serve it), WMF should listen to all criticism - yes, including harsh criticism saying that they did a hopelessly terrible job - with enthusiasm (of the kind they have shown for "VisualEditor"), seeing in it an opportunity for improvement. And, of course, such criticism is not an assumption of bad faith - I am certain that no one believes WMF is trying to cause trouble on purpose. --Martynas Patasius (talk) 19:06, 16 July 2013 (UTC)
25. Matthiasb (talk) 15:54, 19 July 2013 (UTC)
26. --Ilya (talk) 18:52, 19 July 2013 (UTC)
27. — xaosflux ^Talk 20:08, 19 July 2013 (UTC)
28. — Scott • talk 20:44, 19 July 2013 (UTC)
29. Sometimes nothing short of full deployment will find out what people really feel; this time, the full deployment confirmed what almost everyone outside the WMF thought would be the case. DGG ( talk ) 21:55, 19 July 2013 (UTC)
30. Instinctively this is my feeling. The introduction was a bit "rude" and too fast. --Lucas (talk) 00:55, 20 July 2013 (UTC)
31. It was surely rushed. --AFBorchert (talk) 08:17, 20 July 2013 (UTC)
32. Secret ^account 23:40, 20 July 2013 (UTC)
33. I'm a sort of Johnny come lately to this whole controversy, but I am seriously annoyed at what I perceive as a complete disregard to the community that this is supposed to be helping out. I remember when Wikia introduced something similar to this, and turned it off at every chance I got in terms of user preferences and whenever I was a bureaucrat on a wikia wiki for the whole site. I hate it even more on Wikipedia, and I see some absolutely condescending replies coming from WMF personnel involved. It is also going to be a major public relations nightmare for the WMF, and certainly is a "customer relations" nightmare in terms of at least listening to the ordinary users in a substantive manner. Things of this nature are best done from the ground up rather than a top-down approach as has happened here. --Robert Horning (talk) 04:08, 22 July 2013 (UTC)
34. WMF responses to criticisms have been obnoxious and further alienated the editors. Kiefer.Wolfowitz 22:40, 25 July 2013 (UTC)
35. Overly aggressive not only in schedule and determination to move forward no matter how many problems are caused, but in the tone taken to requests even so simple as "I'm not interested in using this. Please let me turn it off for myself." WMF's tone toward existing, long-term volunteers (dismissive referencing as "power users" who don't care about new editors and would never accept any change at all) has also been dismissive and quite hostile in and of itself. Seraphimblade ^{Talk to me} 05:05, 29 July 2013 (UTC)
36. --Shadak (talk) 16:00, 29 July 2013 (UTC)
37. -Rushton2010 (talk) 18:47, 29 July 2013 (UTC)
38. Anthonyhcole (talk · contribs · email) 00:22, 31 July 2013 (UTC)
39. This is probably the part of this whole kerfuffle that annoys me the most. I wouldn't necessarily call it "aggressive", but it's bloody well arrogant. —Wasell^(T) 11:09, 2 August 2013 (UTC)
40. We have now reached a point where the developers are actively spitting in the face of community consensus, and it has to stop. –Wine Guy~Talk 14:48, 2 August 2013 (UTC)
41. Yes. Gryllida 08:14, 6 August 2013 (UTC)
42. Strong support. The foundation and developers should support the editor base, not the other way around. Recent actions on several issues, particularly VE, show a degree of contempt for the community. If the current trend continues it is only a matter of time before many of the project's core editors are driven away. The foundation needs to have a long, hard think about how the projects are managed, and give editors a say in the running of the site. --W. D. Graham 13:40, 4 September 2013 (UTC)

Oppose (manner)

1. High-handed or insensitive I could agree with, "aggressive" I don't. Thryduulf (talk) 00:02, 11 July 2013 (UTC)
2. "Irresponsible" is the adjective I would choose. Once it became apparent that it was corrupting articles, it needed to be disabled until those bugs were fixed.—Kww(talk) 01:11, 11 July 2013 (UTC)
3. This is their ONE AVENUE to improve the site and in the end the encyclopedia. They control the codey stuff. They can't really fix admins/arbs/editors and all the rest of that drama (to include the content itself). Also, Facebook or other sites have gone through many more changes over the last several years. Wiki is stuck in the dark ages. WMF should change, meddle, experiment. Just apologize afterwards...but God NO! don't ask the Communitai for permission.TCO (talk) 01:15, 11 July 2013 (UTC)
4. I don't find it agressive at all. I have been aware of the Visual Editor deployment schedule since long ago. Maybe because I talk too much to the WMF guys or whatever, but "aggressive" is not a correct word to define what happened. I'd prefer "inappropriate" in some sorts, but not "aggresive". — ΛΧΣ²¹ 01:19, 11 July 2013 (UTC)
5. Agree with the others. Besides, most of those FAQ entries were written by community members, not by WMF staffers. — This, that and the other (talk) 01:24, 11 July 2013 (UTC)
6. Oppose. Getting 100% buy-in prior to launch is not reasonable. The community has needed a WYSIWYG editor for years, and once one exists, it should not take years of bureaucracy and RFCs to get it installed. --Jayron32 01:47, 11 July 2013 (UTC)
7. Not really. Somewhat aggressive, perhaps, but I don't view that as a negative. - MrX 02:29, 11 July 2013 (UTC)
8. At best naive and at worst incompetent - but not aggressive. GiantSnowman 08:12, 11 July 2013 (UTC)
9. Everyone here was given years of notice that Visual Editor was coming, and invited to participate in discussions, development, and testing. Conspicuous notices were posted on various Wikimedia websites, and there was extensive coverage in the press, blogs, and social media. When the system went live WMF representatives responded to questions and complaints swiftly and courteously. (Given the vitriol that has been poured upon them, I am amazed they were able to stay so calm!) There was absolutely nothing "aggressive" about the process. —Psychonaut (talk) 08:20, 11 July 2013 (UTC)

   "Everyone" -- not true. My first notice was when I logged in to make an edit and there it was.--Paul McDonald (talk) 14:09, 11 July 2013 (UTC)

   Yes, we did not notify IPs of a release to registered users - it seemed extraneous, and like it would complicate things. Okeyes (WMF) (talk) 14:19, 11 July 2013 (UTC)

   The other issue with notification is that we have been constantly told about vaporware editing features i.e. LiquidThreads, that never materialize into a deployment. People stop paying attention to announcements in about "great new features" when so far basically none of them have made it to deployment. Gigs (talk) 14:31, 11 July 2013 (UTC)

   I was certainly never aware of VE until the past few months. GiantSnowman 14:35, 11 July 2013 (UTC)

   Gigs, can you think of examples other than LQT? GiantSnowman; to be fair, when we're talking several months of notice I'd still say that's pretty good going. Okeyes (WMF) (talk) 14:40, 11 July 2013 (UTC)

   Maybe he means Flagged revisions which works fine on DE wiki, we just need to get consensus here before we can implement it on EN. Can't blame the devs for that not happening here. ϢereSpielChequers 19:11, 11 July 2013 (UTC)

10. Premature would be more diplomatic than saying aggressive. It would have been better to wait until Beta testing was no longer finding bugs, and maybe even drop a note to past testers "thanks for all the testing - we plan to go live in two weeks, but please just do a few more test edits to make sure all the previously reported bugs have been resolved." OK in an ideal world we'd then be implementing this live in one of the smaller wikis first before going live in our busiest wiki, but hopefully that's the sort of thing that will come with "professionalisation". ϢereSpielChequers 19:11, 11 July 2013 (UTC)
11. I knew it was coming for months. When it arrived I was startled slightly for a few seconds because I had forgotten the planned date. No big deal. I can understand that lots of people ignore the messages and notification and were surprised in a big way, but it is hard to see what more was available to shout in their ears without going to the extreme of personal email to everyone who has e-mail activated. How does one speak to the hard of listening? • • • Peter (Southwood) ^(talk): 19:52, 11 July 2013 (UTC)
12. Per Kww. THe issue isn't the "aggressive" rollout; it's the fact that it should have been disabled once it was apparent that is was so bug-ridden it was a negative to the encyclopedia. Black Kite (talk) 23:38, 11 July 2013 (UTC)
13. Nope. Making me move my mouse a few pixels to the right to click "edit source" is hardly aggression. --LukeSurl ^{t c} 00:18, 12 July 2013 (UTC)
14. I don't think it was aggressive. It was clearly a mistake, but it wouldn't have been so much of one if it were suspended once enough serious bugs were discovered, until they are fixed. — Arthur Rubin (talk) 21:33, 12 July 2013 (UTC)
15. Chase me ladies, I'm the Cavalry (Message me) 11:55, 13 July 2013 (UTC)
16. If it's good enough (this is the best new feature on WP ever in my view), then why shouldn't it be introduced rapidly? LiquidWater 18:27, 15 July 2013 (UTC)
17. I also don't think "aggressive" was the right word. I don't think you could say that it was handled well, and you might even describe some aspects as "clumsy", while still acknowledging the good faith of everyone involved. Lankiveil ^{(speak to me)} 11:38, 16 July 2013 (UTC).
18. I needed the editor to be thrust on me so that I noticed it. I never came across the earlier discussion, but I'm very pleased that I came across the new editor when trying to edit a page. Chogg (talk) 20:06, 16 July 2013 (UTC)
19. ·addshore· ^{talk to me!} 12:06, 21 July 2013 (UTC)
20. Legoktm (talk) 02:35, 22 July 2013 (UTC)
21. I see a big failure of AGF in the formulation of this question: throw the first stone, yadda yadda. I see no fault here. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 21:54, 26 July 2013 (UTC)
22. Adam is reading a tone that doesn't exist. WMF may have consciously overrided community protocols, but I don't believe they did so without reason, or with an intent to bully us. I believe their sincere intention was just to improve the project, and viewed the usual requisite processes as obstructive to that. Dcoetzee 03:13, 2 August 2013 (UTC)
23. More attempts to derail VE and keep wikipedia a playpen for tech types and long-term editors. This time it's "VE rollout to a public (which wants a WYSIWYG editor) is too fast should be hindered because... this guy wasn't polite enough in a FAQ." Hm. --Monk of the highest order^(t) 04:10, 12 August 2013 (UTC)

Neutral (manner)

1. This was no more aggressive than the New Coke launch. It's problematic it was shoved out so early and there were not immediate options to turn it off, but aggressiveness is not the problem here - the problem is the software itself. Toa Nidhiki05 18:52, 15 July 2013 (UTC)
2. Agree with ToaNidhiki05, the problem is the software as it is now. --Roberto Segnali all'Indiano 12:55, 22 July 2013 (UTC)
3. Aggressive is too strong, but clearly "irresponsible", and the way it is still handled by WMF is still irresponsible. --NicoV ^{(Talk on frwiki)} 04:09, 23 July 2013 (UTC)
4. I agree with the statements above; "aggressive" is too strong a word. PhnomPencil (talk) 10:06, 24 July 2013 (UTC)
5. I agree that this has been an aggressive rollout, especially with the decision to continue with non-English deployment when the data corruptions on English Wikipedia had not been fixed, but I dont like the formulation of this particular comment about the FAQ. As others have said, there are better ways to describe the problems with the rollout. John Vandenberg ^(chat) 12:43, 27 July 2013 (UTC)
6. Per the comments above. As I see it, the spirit that both the WMF and editors here should join in is one of we are all in this together; see also Wikipedia:Petition to the WMF on handling of interface changes. --Tryptofish (talk) 23:15, 31 July 2013 (UTC)

Comments (manner)

As the volunteer editor who originally wrote "Can the editors here order the developers to turn this off?", I'd like to say that I thought this question was very responsive to the noisy minority of editors who believe that they ought to have veto power over "their" website's software. "Responsive" does not mean "agree with whatever someone else says" or even "be unfailingly polite to people who feel entitled to be extremely rude to you". And if you look at the number of people who have asked that question in one form or another, I think that its presence in the FAQ is well justified. WhatamIdoing (talk) 23:39, 10 July 2013 (UTC)

I don't. I also doubt the section is really correct. The WMF tends to listen to the community, so long as it's not in an annoyed burst of anger over change in general. --Yair rand (talk) 06:28, 11 July 2013 (UTC)

WhatamIdoing, as I posted above, I think that paragraph was poorly written, and contributed to the perception that this was just a freight train and there was nothing anyone could do about it. It may have seemed like the correct thing to write at the time, but it's really not a good idea to make users feel helpless about software they are being forced to use. Gigs (talk) 14:33, 11 July 2013 (UTC)

Nobody is being "forced to use it". If you don't want to use VisualEditor, you can reliably avoid using it by clicking on the other button. If you have trouble remembering to click on the other button, then you can even cover up the VisualEditor button in your prefs.

We need to get away from this myth that unwilling people are being "forced" to use VisualEditor. Clicks on [Edit source] are not being redirected to VisualEditor against the user's wishes. The devs are not grabbing your mouse and forcing it on to the VisualEditor link. Nobody is being forced to use VisualEditor. The most you can claim is that you are "forced" to permit other users to make their own choices about which editing environment to use. Whatamidoing (WMF) (talk) 21:19, 11 July 2013 (UTC)

Then explain this, Whatamidoing. Looks to me like people are going to end up forced to use it. —Jeremy v^_^v ^Bori! 23:56, 14 July 2013 (UTC)

Novice editors are being presented with a button that says "edit" when that button leads them to a tool with an unacceptable incidence of bugs. It may not be "force", but "attractive nuisance" might apply. Right now, VE is an editor that needs to have its output checked very carefully. It shouldn't be positioned as the normal editor for a population of editors that is incapable of making those checks.—Kww(talk) 21:48, 11 July 2013 (UTC)

This claim is being repeated by many WMF staff, and it's disingenuous in the extreme - the VE and its trappings steer people to use it in every way they can, and you keep breaking the "off" switch and saying "not in scope" when called on having done so. That you do this to people who really seriously don't want to be using it is deeply obnoxious behaviour, however good the intentions behind it - David Gerard (talk) 21:54, 11 July 2013 (UTC)

Whatamidoing, regardless of technicalities, users do have to deal with VE in some way, either by disabling it (if they are even aware they can), or by breaking the force of habit of clicking "edit". If VE had been added as an additional thing that popped out on hover, there'd be a lot less perception of "being forced". Keep in mind my comments are all framed around perceptions. I'm actually excited about VE and what it has the potential to become, but I understand 100% why people are upset, and it's not all simple reluctance to change. Gigs (talk) 14:00, 12 July 2013 (UTC)

• Not really 'aggressive', I would say just...insensitive. It has felt like the WMF has not addressed any concerns, and continues to hide behind the excerpt in WP:CONSENSUS that said they don't have to consult the userbase for massive "technical" changes such as these, when it affects so much. Jguy _Talk^Done 13:35, 14 July 2013 (UTC)

• While I think that VE should have an off-switch, and that its launch was premature, the method of the launch itself I didn't find particularly overbearing.--¿3family6 _contribs 13:22, 16 July 2013 (UTC)

5. This survey should have been begun by the VisualEditor team

To not launch a wide-scale survey on the VisualEditor experience shortly after its launch, and before the scheduled rollout to other Wikipedias, shows a lack of interest in the views of users that should be censured. Adam Cuerden ^(talk) 23:04, 10 July 2013 (UTC)

Support (survey)

1. Adam Cuerden ^(talk) 23:04, 10 July 2013 (UTC)
2. Vegaswikian (talk) 23:54, 10 July 2013 (UTC)
3. Support PantherLeapord (talk) 07:36, 11 July 2013 (UTC)
4. Perhaps not a full-blown RFC, but certainly something in greater detail than what was actually carried out. GiantSnowman 08:14, 11 July 2013 (UTC)
5. Support maybe not this particular survey, but surveys have long been a tool for gaining user feedback and improving systems. To ignore them is really exposing a lack of professional experience and measures.--Paul McDonald (talk) 11:22, 11 July 2013 (UTC)
6. Everyking (talk) 22:22, 11 July 2013 (UTC)
7. It would have been nice to see something organized along the lines of "hey, we just launched something massive, what do you guys think". Something might have been done, but I don't think all the opinions have been taken into account. Only the comments which praise the editor or rollout have really been acknowledged fully by the WMF. Jguy _Talk^Done 13:35, 14 July 2013 (UTC)
8. Weak support: I think that the software should have been deployed to a group of volunteer editors (a group I would be willing to participate in) before deploying VE across all of wiki.--¿3family6 _contribs 13:29, 16 July 2013 (UTC)

   It was "deployed to a group of volunteer editors" from December 2012 to June 2013, and you did not participate. Whatamidoing (WMF) (talk) 17:57, 16 July 2013 (UTC)

   Oh, I'm sorry. I'm not subscribed to Signpost, so I didn't know anything about VE until it was deployed. The blame lies on me. I usually have no idea what is going on unless I get an invite on my talk. I guess this means I should subscribe to Signpost.--¿3family6 _contribs 12:57, 17 July 2013 (UTC)

   Was there a watchlist notice? Not everyone subscribes to the Signpost... Double sharp (talk) 15:17, 19 July 2013 (UTC)

9. Maybe, yes. I would say weak support. Someone should have done this, not necessary the VE team (although it is the most obvious subject; that's why I support the claim) --Lucas (talk) 00:58, 20 July 2013 (UTC)
10. Weak Support Certainly. And the VE team, having developed this in the first place, should have been the ones to do it, IMHO. Yet I wonder if their results will not simply be biased to fit what they want (i.e. VE is good! Everyone likes it and wants it!) which would completely defeat the purpose of the survey, so I think that in addition to them, there should be some other WMF-independent guy conducting a separate survey... Double sharp (talk) 03:38, 20 July 2013 (UTC)
11. --Roberto Segnali all'Indiano 12:55, 22 July 2013 (UTC)
12. --Shadak (talk) 16:01, 29 July 2013 (UTC)
13. The VE team should have been actively seeking community consensus from day one. Instead, they have chosen to ignore the voice of the community; someone needs to rein them in (yes, Jimbo, I'm talking about you). –Wine Guy~Talk 14:56, 2 August 2013 (UTC)
14. Support need in a proper survey and beta testing before launch. Gryllida 08:13, 6 August 2013 (UTC)

Oppose (survey)

1. It shouldn't have been necessary at all if users opinion was correctly accounted for. Patrick87 (talk) 00:08, 11 July 2013 (UTC)
2. If by "do this particular RFC", hell no. If by "think about usability and patterns and the objective-design-code trade-offs", yeah probably. For instance, I urged them to really understand what and HOW things are bad now. And got brushed of with a "we know it is bad" remark. I think case studies and something a little more ethnography or even industrial engineering based (looking at what goes on) would have given them insights. There was a little bit of "we want to code". I think for instance, this approach would have allowed them to do something a little simpler and quicker wrt table/template/ref callouts (i.e. just display the wikicode itself when someone goes to edit rather than trying to WYSIWYG parallel the functionality.)TCO (talk) 01:22, 11 July 2013 (UTC)
3. Mostly agree with TCO here. I'm not sure what a "survey" is supposed to be, but per Oliver below, surveys are not generally a very useful form of feedback. — This, that and the other (talk) 01:27, 11 July 2013 (UTC)
4. Deployment was too aggressive because the developers wanted a large community of users. A small one was in order. Robert McClenon (talk) 02:19, 11 July 2013 (UTC)
5. You can't really fix software with surveys. It's sounds like a nice idea, but it really lacks any practical value. - MrX 15:07, 11 July 2013 (UTC)
6. If the Visual editor people didn't listen to the many complaints filed at the dedicated feedback pages (which require people to actively seek them out and manually add comments), I doubt they would listen to the results of a survey.—Love, Kelvinsong talk 23:20, 12 July 2013 (UTC)
7. Chase me ladies, I'm the Cavalry (Message me) 11:56, 13 July 2013 (UTC)
8. There was plenty of feedback solicitation, both before and after the deployment. The only "users that should be censured" are the ones who write such awfully worded RFCs. —Psychonaut (talk) 08:04, 15 July 2013 (UTC)
9. I doubt the WMF team can do an accurate evaluation of what people actually on WP think--their results seem to match their desires, and all too often turn out to be grossly erroneous. DGG ( talk ) 21:59, 19 July 2013 (UTC)
10. It's near impossible to propose anything here because the majority will oppose it. All I ask is that we have the option to turn it off. There are enough meta troubles pulling people away from editing already. PhnomPencil (talk) 10:10, 24 July 2013 (UTC)
11. The "team" is incompetent at software engineering, so it obviously cannot handle any additional duties. Kiefer.Wolfowitz 22:42, 25 July 2013 (UTC)
12. Oppose: Who assembled the Visual Editor team? That's who should have initiated this survey. Dementia13 (talk) 12:29, 30 July 2013 (UTC)
13. Oppose: This is a survey of wikipedians with time for RFCs. That will tend to be wikipedians who like the status quo because many of those who don't have left. There were plenty of earlier surveys which tried to engage the wikipedia userbase on their values regarding a WYSIWYG editor and it's importance. The need for a post-rollout survey only exists in the heads of many of the same wikipedians with time for RFCs who hate VE and are trying to scuttle VE by painting the rollout as a problem. --Monk of the highest order^(t) 04:13, 12 August 2013 (UTC)

Comments (survey)

• We're talking about a survey now. Personally, I don't think a survey is a very good way of measuring things. Okeyes (WMF) (talk) 23:11, 10 July 2013 (UTC)
• There isn't a section for comments about the position generally, so I'll ask; why do you not think the bugs and slowness are likely to be fixed within a reasonable timeframe? (I say that as the team deploys a set of new patches). Okeyes (WMF) (talk) 23:13, 10 July 2013 (UTC)
  • A week is a long time in a very active website, and if the bugs were that easy to fix, there is no way that VE should have been launched unpatched. Adam Cuerden ^(talk) 23:25, 10 July 2013 (UTC)
    • Sure, but by that standard we'd never be able to launch any software. Wikipedia will always be active; software will always, to some degree, be flawed. Actually we're doing deployments pretty much daily. Okeyes (WMF) (talk) 23:27, 10 July 2013 (UTC)
      • Few of those actively damage the source of pages on the site, but remain in place. Adam Cuerden ^(talk) 23:38, 10 July 2013 (UTC)
        • The same is true of the VE; we've got, off the top of my head, 10 bugs that do that: or did. Three fixes were deployed ~5 minutes ago. Okeyes (WMF) (talk) 23:47, 10 July 2013 (UTC)
          • I'm going to have to echo Oliver here in that if we didn't ram it though, a lot of these bugs wouldn't have been spotted. The fact that so many people were able to edit with it and experience the interface is a great thing for developers from the standpoint of bug fixing, even if many people did not like it. Kevin Rutherford (talk) 23:56, 10 July 2013 (UTC)
            • Yet it is also the case that at some critical mass of bugs, you stop worrying about how fast they are getting fixed by user reports, but whether it's actually a useful and working product at that stage of development and whether it should really be released to the public yet. (Or at least, that's what should happen.) Double sharp (talk) 03:36, 20 July 2013 (UTC)
          • (ec)Too little too late? Look, I worked on releasing software for a number of years. But this was simply not ready for prime time. I would have fired anyone who proposed releasing this in the business world as pure incompetence. Beta testing is fine, but this would fail most everyone's beta! Why did the testing not reveal bugs? Simply put the software was too buggy to use. Vegaswikian (talk) 23:59, 10 July 2013 (UTC)
            • Because there are a vast number of permutations of user actions. We had a lot of beta testing - starting in December 2012, the VE was opt-in here. At one point we had 1,000 users using it. But that doesn't account for every possible use case in a highly editable environment. Okeyes (WMF) (talk) 00:14, 11 July 2013 (UTC)
              • Your right, we did have a long beta test, at the end of which several editors including me told you and the WMF that the product wasn;t ready for launch. We already knew there were problems and they were actively being discovered. So the innocent school boy act is disingenuous. No one was surprised this blew up in the WMF's face. We told them it was going to happen and we were ignored. Kumioko (talk) 00:29, 11 July 2013 (UTC)
                • Actually, that's an interesting question. Oliver, are WMF people actually surprised at the negative reaction? I'd like to note that I've been hugely advocating the VE project for years now and I'm seriously dismayed by way too much of what's happening. (And if you ask "what in particular are you dismayed at?" then I'm not really sure what to say.) - David Gerard (talk) 15:49, 11 July 2013 (UTC)
                  • Not massively; frankly if we thought it would be easy we wouldn't have eight people doing it. I can't speak for anyone but myself, but personally I've found myself (a) pretty impressed by the community and (b) hoping that we do a lot more to fix the issues. Okeyes (WMF) (talk) 17:13, 11 July 2013 (UTC)

                    There is a variety of viewpoints within the WMF, but from what I've overheard, most of the WMF regular staff seem to believe that the overall reaction from the English Wikipedia is less negative than they had expected when they contemplated this project. A major, highly visible change like this immediately results in a huge number of complaints, no matter how perfect it is (and this isn't!), simply because it's a big change and big changes are always disruptive to people who are used to the old system. Therefore, the fact that there have been a lot of complaints during the first eleven days is normal and expected. It was even expected that a handful of editors would publicly refuse to use it, and yet still spend hours and hours complaining about it, rather than writing articles or whatever it was that they normally did (which, looking at a few names, I guess isn't usually writing articles anyway).
                    I may be wrong, but I think that if there are still this many complaints in two or three months, then they'll be extremely concerned. But right now, it's easy to understand how disruptive this huge change is for experienced editors, and one of the predictable, wonderful things about this community is that when experienced editors encounter even a small disruption, they make sure that you know about it. Whatamidoing (WMF) (talk) 22:30, 11 July 2013 (UTC)

                    • Whatamidoing, do you really have to resort to this kind of dismissive thought and ad hominems? If people stop "complaining" (i.e. giving feedback) in two or three months, that probably means they have given up on trying to use VE, which should be your worst case scenario to be concerned about. The fraction of non-constructive complaints has been very small compared to the number of absolutely valid bug reports and constructive criticism, that should be taken seriously, not dismissed as "expected noise". Your comment does give insight into how the WMF has become so out of touch, at least. It's exactly this kind of thinking that leads to it. Gigs (talk) 14:15, 12 July 2013 (UTC)

                      I don't know, Gigs. If the WMF staff were truly out of touch, then I don't think that they could have accurately predicted the community's response so far.
                      There are certainly some major issues with this product. They have already fixed over 150 bugs, and they have hundreds to go. Fixing bugs and adding editor-requested enhancements as fast as you can is pretty much the opposite of being dismissive. But there are also a few persistent people whose comments here and elsewhere don't look like "constructive criticism", and instead look a lot like the normal, temporary reaction against any disruptive change at any website that users care about. Neither Wikipedia nor VisualEditor are unique in this regard. Major changes are disruptive to the people who were best served by the old system. Even if the end result is eventually accepted as being the most amazing feature in the history of computing (and I'm not nominating VisualEditor for that prize), the fact is that there will inevitably be short-term pain until people get used to the change. Some of what we're seeing now is just the expression of that pain. WhatamIdoing (talk) 00:06, 13 July 2013 (UTC)

                      • How much of it is the expression of said pain (i.e. "They changed it, it sucks") as opposed to the expression of anger at being used as guinea pigs for something that needs serious technical work? (i.e. "I'd love to use this, but it's buggier than a Roach Motel behind a greasy kitchen's fridge") —Jeremy v^_^v ^Bori! 05:39, 13 July 2013 (UTC)

• If they thought they would get USEFUL feedback from a survey they would probably have started one, if they had the time. Feedback is pouring in on the feedback page, some of it useful (from a developer's point of view) and a lot of it noise. So what's new? • • • Peter (Southwood) ^(talk): 20:00, 11 July 2013 (UTC)
• I'm with you Okeyes... I don't think a normal type aggregate survey would be valuable. When it comes to software specifications and usability, people often don't even know what they really want, until they try something and find the pain points. After the users have tried the interface, that post-use feedback from them is extremely important and should be taken very seriously, no matter how trivial it seems. As an example, it may not seem like a big deal to a developer (or even to the user, when presented in the abstract) to take an extra mouse click for a certain action, but if a user does that action all day, it's a big deal for them. They might not realize that until they actually use the interface though.
  • "Normal type aggregate surveys" are typically poorly written and of little value, yes. However, a valuable survey--one that does probe to find the needs and desires of the user base--would have been very valuable. A bad survey does little good, a good survey does very good. I think we can do better here.--Paul McDonald (talk) 00:08, 15 July 2013 (UTC)
• If there is a need to do surveying, it should be framed as the collaborative development of a bunch of use-case outlines. We have a wiki here to do collaborative document development, lets use it! Gigs (talk) 14:08, 12 July 2013 (UTC)

6. Wikimedia should disable this software by default

Enabling buggy software for the editors least able to recognize that they are dealing with a software bug or that they have corrupted an article is irresponsible. The English Wikipedia community does not have the bandwidth, inclination, or responsibility to check every edit made by the Visual Editor and repair it. Until the Visual Editor is far more stable and the majority of identified bugs have been corrected, it should be disabled except for editors that are consciously intending to test it.

Support (disable)

1. —Kww(talk) 01:16, 11 July 2013 (UTC)
2. For now, its too buggy, missing too many feature to be more than at a test state. I've been building a state of play document at Wikipedia:VisualEditor/Known problems which makes it clear how incomplete it is. Revert back to an opt-in, fix the bugs, implement the features, and then when it works to a better level resume the roadmap.--Salix (talk): 01:35, 11 July 2013 (UTC)
3. New users are deleting references due to VE, when trying to insert some new text.--Vigyani_talk^{ਯੋਗਦਾਨ} 05:01, 11 July 2013 (UTC)
4. Support PantherLeapord (talk) 07:36, 11 July 2013 (UTC)
5. Support Suppose you're in the Indianapolis 500. You're on lap #15 and everybody is whizzing past you. And you take a good look at your car and realize you're in a Yugo. How many more laps do you take before you pull into the pit and get into the proper car? The Visual Editor, as it stands now, is the wrong editor. It should be rolled back immediately. It is embarrassing to Wikipedia and highly disruptive to the process of editing articles.--Paul McDonald (talk) 11:25, 11 July 2013 (UTC)
6. Support, and I suggest the Oppose !voters read Kww's comment below. This should be an opt-in tool, as opposed to opt-out. —Jeremy v^_^v ^Bori! 02:09, 12 July 2013 (UTC)
7. Support, in its present state VE does some good and some harm. Should be disabled for now, until it can be stabilized and behave better. I assume Good Faith in the developers, but that AGF doesn't automatically extend to their progeny. Maybe VE2.0 will offer more "bang for the bug" as it were. Also "opt-in" sounds real nice.--R.S. Peale (talk) 05:17, 12 July 2013 (UTC)
8. Support...sort-of. When somebody logs in for the first time, there should be an option saying 'you can use this plaintext editor or the source editor'. - The Bushranger _{One ping only} 11:27, 12 July 2013 (UTC)
9. Support Just as we should let those who don't want to use it not use it, we should let those who do want to test it and make it usable test it. But we should not force buggy source text-corrupting products on everyone to use and then actively encourage them to use it by making it ever more difficult not to. Double sharp (talk) 13:23, 12 July 2013 (UTC) changed from Oppose, see below Double sharp (talk) 13:24, 12 July 2013 (UTC)
10. Support with caveats: I presume an "opt-in" is what's intended here. Do we really need millions of users before the basic problems are sorted? Probably not. This is undertested software, and, now that everyone knows about it, I'm sure many would choose to opt-in for further testing and development. The precipitous rush to foist unfinished software on everyone, without even having an opt-out at launch, instead making people create a gadget hack to get around it, then attempting to hide the existence of the gadget, was a public relations disaster on the WMF's fault, which only served to screw up the chances of a successful test. Adam Cuerden ^(talk) 20:09, 12 July 2013 (UTC)
11. Support Highly disruptive to the process of editing articles, it should be disabled except for editors that are consciously intending to test it. KhabarNegar ^Talk 20:11, 12 July 2013 (UTC)
12. Support It's probably tested better than most Microsoft software, but it's not ready for release. Personally, I think it should be unreleased now, rather than just changing to opt-in, because of the number of known, but unreported (to the editor) serious errors. — Arthur Rubin (talk) 21:37, 12 July 2013 (UTC)
13. I agree. Pseudonymous Rex (talk) 00:28, 13 July 2013 (UTC)
14. If we have to have it on enwiki in a buggy, incomplete state, best that it be off by default. Once it's working properly, it will be an entirely different matter. Anaxial (talk) 18:08, 13 July 2013 (UTC)
15. As Anaxial. But even in good condition it should at least have an opt-out to completely disabling it. The Banner talk 23:15, 13 July 2013 (UTC)
16. Support - If it does get added in the future, there should be an OPT-OUT option in our preferences...no one minds editing articles whilst taking their time so i really do not see how this tool will be any useful and it will also make it a bit hard to add refs, edit templates etc..--Stemoc (talk) 12:21, 14 July 2013 (UTC)
17. Support. It doesn't work correctly, and editors who are most likely to make damaging edits because of its faults are also most likely to be unable to disable it themselves. Hullaballoo Wolfowitz (talk) 13:09, 14 July 2013 (UTC)
18. Until it reaches a state where it is fully usable in the namespaces without bugs. Jguy _Talk^Done 13:35, 14 July 2013 (UTC)
19. Like Bushranger said, it should be given as a choice at user registration. -- cyclopia^speak! 10:19, 15 July 2013 (UTC)
20. Support per User:The Bushranger & User:KhabarNegar!! - →Davey2010→→Talk to me!→ 19:12, 15 July 2013 (UTC)
21. Matthiasb (talk) 15:56, 19 July 2013 (UTC) who needs it can activate it but if this is going to get the default for IPs then we will get chaos in many, many articles.
22. --Ilya (talk) 18:55, 19 July 2013 (UTC)
23. It continues to break articles and waste my time.  Sandstein  22:25, 19 July 2013 (UTC)
24. When a stable version will be ready, I'll be its first user. --Lucas (talk) 00:59, 20 July 2013 (UTC)
25. Support It unfortunately just isn't ready. I wish it were, because I need it for planned instruction of non-computer savvy prospective users. DGG ( talk ) 02:52, 20 July 2013 (UTC)
26. Make it optional like other gadgets. --AFBorchert (talk) 08:20, 20 July 2013 (UTC)
27. Per AFBorchert, Sandstein, and others above and below, we don't need a new gadget that completely changes how Wikipedia had worked for the previous 10 or so years, this tool is just going to attract a certain crowd of editors who we don't need in this project. Secret ^account 23:45, 20 July 2013 (UTC)
28. Don't even think about making any alternative the default until it can handle each and every content that the traditional editor can. Currently, the VE cannot handle (incomplete list): talk pages, the introduction of an article, math, non-roman characters, image galeries.
29. Make it optional, because at the moment it is just annoying due to the lack of features. Thine Antique Pen (talk) 11:48, 21 July 2013 (UTC)
30. --Roberto Segnali all'Indiano 12:55, 22 July 2013 (UTC)
31. Strong support, at least until bugs are fixed, enhancements are implemented, and evidence is shown that enabling it results in more/better edits by newcomers (current statistics seem to demonstrate quite the opposite). --NicoV ^{(Talk on frwiki)} 04:09, 23 July 2013 (UTC)
32. Since the tool is not exactly useful at the moment, the reasonable thing to do is to disable it for anyone who does not volunteer to test it. --Martynas Patasius (talk) 00:06, 24 July 2013 (UTC)
33. Not ready for prime time. EllenCT (talk) 21:45, 25 July 2013 (UTC)
34. This software seems to have been designed by the anti-Wikipedians who want to see the project fail. Kiefer.Wolfowitz 22:44, 25 July 2013 (UTC)
35. Support - VE is clearly not yet stable enough to be used by inexperienced editors. Go back to volunteer beta testing mode ASAP. Gandalf61 (talk) 09:53, 26 July 2013 (UTC)
36. Support for the reasons I gave above. This editor is a horrible idea. I often make small corrections (one single letter in the case that led me to comment here) and was sandbagged by this bullshit visual editor thing today after being away for a few months. I prefer to edit as an IP and am worried that when this thing is disabled it'll require logging in to take advantage. Please nuke it. I will think twice about fixing spelling after my experience today. 198.72.143.40 (talk) 22:04, 27 July 2013 (UTC)

    And thus, we see a case study where the editor is rejected by the group it's intended to work for...

    @198.72.143.40: given that this VE was intended to make the editing experience for new editors and IP editors easier, I suspect your comment here will be taken with more weight than you might think! Double sharp (talk) 10:54, 28 July 2013 (UTC)

37. Support VE is annoyingly slow, causes strange issues like this, and actually seems to make new users less inclined to edit, per the statistics. ^King Jakob _C2 12:17, 29 July 2013 (UTC)
38. --Shadak (talk) 16:01, 29 July 2013 (UTC)
39. -Rushton2010 (talk) 18:48, 29 July 2013 (UTC)
40. It's not even a question of whether or not it's buggy: It's a feature that's added to one of the world's highest-trafficked web sites, its going to have unpredictable side effects, and it's not going to be useful for all readers. This has to be an "opt-in" feature, not an "opt-out". Dementia13 (talk) 12:22, 30 July 2013 (UTC)
41. Maybe for now, temporarily, or maybe better just as an opt-in instead of an opt-out. I'm not saying that VE couldn't become a real good thing in the future. --Tryptofish (talk) 23:19, 31 July 2013 (UTC)
42. —Wasell^(T) 11:22, 2 August 2013 (UTC)
43. This should be off by default now and forever. Allow registered editors to opt-in when and if it ever works. –Wine Guy~Talk 15:00, 2 August 2013 (UTC)
44. Yes, please, turn off, but not forever. :) Gryllida 08:13, 6 August 2013 (UTC)

Oppose (disable)

1. What's done is done. — This, that and the other (talk) 01:28, 11 July 2013 (UTC)
2. Onwards and upwards! You haven't presented the case for the volume of bad edits and I'm not experiencing it in my edits around the 'pedia. Also, a fair case needs to also show the positive effects (whatever they are, show the trade off, be two-sided). Also, your statement of action is a little disconnected from the smaller text below which is "platitudey". But that's a nit, man. Don't get mad and please keep fixing my pictures and sounds please.  ;-) (I can't produce good content on my own...hmmm...maybe there is a tiny thing to the idea of Wiki collaboration). TCO (talk) 01:33, 11 July 2013 (UTC)

   Filter 550 monitors only one class of common problem with VE: its inability to cope with editors that directly insert wikimarkup in visual mode. That volume of problems alone would justify my opinion.—Kww(talk) 01:38, 11 July 2013 (UTC)

3. Oppose: As noted above, no user has to use it at all, and only has to move their mouse a few millimeters to the right before clicking to avoid using it forever. No one is being forced to use it, despite the false impression given by the tone of many of these questions, and while it has faults and problems, none of these questions does any good in resolving these faults, but seems to merely be a means for some community members to vent about not being personally consulted at every step along the way for their singular approval before roll-out. I wouldn't mind seeing many improvements to the Visual Editor, but there's no way this questionnaire is a useful medium to achieve those needed changes. --Jayron32 01:50, 11 July 2013 (UTC)
4. VE being 'on' by default is not a real issue, but being unable to turn it completely off easily is. GiantSnowman 08:15, 11 July 2013 (UTC)
5. No, but it does need a proper, supported off switch - David Gerard (talk) 11:27, 11 July 2013 (UTC)
6. What David Gerard said. —Tom Morris (talk) 11:57, 11 July 2013 (UTC)
7. Oppose for the moment, but I agree it really needs an obvious off switch. It took me a while to find it and I'm fairly experienced. Dougweller (talk) 14:24, 11 July 2013 (UTC)
8. I think the sorftware, even in it's current state, is a net positive, especially for new editors. I'm confident that the developers will take our feedback to heart and continue making improvements. - MrX 15:05, 11 July 2013 (UTC)
9. No, leave it default for new editors who won't know about "gadgets". Just don't turn it on until it works. Reaper Eternal (talk) 15:21, 11 July 2013 (UTC)

   Oppose per David Gerard and Reaper Eternal. I would not advocate such an extreme choice – I feel that if someone wants to use it, let's not stop them. But by the same token, if someone doesn't want to use it, we should not stop them either, and that is not what is happening: they are practically being stopped. Double sharp (talk) 15:37, 11 July 2013 (UTC) changed to Support – misread Kww's statement; see his below comment Double sharp (talk) 13:23, 12 July 2013 (UTC)

10. The strategy has achieved much of its intended objective - to get feedback on unknown bugs. Lots of bugs, lots of feedback, some even useful. If you don't like it just don't use it. I find it almost entirely ignorable. It wouldn't bother me at all except for the flashing edit links. • • • Peter (Southwood) ^(talk): 20:05, 11 July 2013 (UTC)
11. No. It's really not that disruptive. --LukeSurl ^{t c} 00:21, 12 July 2013 (UTC)
12. If VE is useful at all it's mainly for newbies (everybody else should have got known to Wikitext by now). Disabling it by default will make it essentially inaccessible for newbies (who opens preferences and activates a feature he/she doesn't even know of yet?). Therefore it should be opt-out. --Patrick87 (talk) 09:14, 12 July 2013 (UTC)

    If the new users we get at #wikipedia-en-help on IRC are any indication, it's no less confusing than the plaintext editor, in part because of the tag corruption issues. —Jeremy v^_^v ^Bori! 19:07, 12 July 2013 (UTC)

13. Chase me ladies, I'm the Cavalry (Message me) 11:56, 13 July 2013 (UTC)
14. The real problem has nothing to do with whether this feature is turned on or turned off, but that it was released to general users too soon. Robert McClenon (talk) 16:24, 13 July 2013 (UTC)
15. As much as I want core users to be able to permanently disable VE, I think VE is only valuable for newbies if it is the default editor. So, no, it should not be disabled by default. --Cryptic C62 · Talk 00:42, 20 July 2013 (UTC)
16. Visual editor is a step in the right direction, if it is disabled all of that will likely be lost! ·addshore· ^{talk to me!} 12:06, 21 July 2013 (UTC)
17. Per TTO. Legoktm (talk) 02:36, 22 July 2013 (UTC)
18. Of course not. It's good for the newbies who won't even realize they can turn something on (or off) for quite a while. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 21:55, 26 July 2013 (UTC)

    Yet, in its current state, I'm wondering if it is even good for the newbies... Double sharp (talk) 10:55, 28 July 2013 (UTC)

19. Without being on by default, VE will overwhelmingly remain unused and have no large-scale benefit for the project. Although fixing outstanding issues is important, it is already more than adequate today for the large majority of simple prose edits made by occasional editors. Dcoetzee 03:39, 2 August 2013 (UTC)
20. I continue to believe VisualEditor should be the default way of editing Wikipedia for most users. Robofish (talk) 00:39, 4 August 2013 (UTC)
21. It should be default for the very same reason we have Visual Editor. Because everyone can use a visual editor to edit text but only a few people want to use the text version or have time or want to learn how to edit templates in wikitext. The option that more people want to use (a statistic not represented in a survey of wikipedia's savvy enough to use an RFC) should be the default. Unlike most people here, the general public is not familiar with wikitext and (demonstrably from wikipedia's decreasing editor numbers and survey results) does not have the inclination to learn it and that is causing a problem. It is not acceptable to simply throw out the body of knowledge provided by such a large swath of the public (by hiding away the VE in unfamiliar options where they might not realize it even exists) just because they are not as comfortable with technical things like markup languages, and because you (people familiar with wikipedia, who will already know about wikitext and that VE can be opted out-of) can't be bothered to go into options. --Monk of the highest order^(t) 04:21, 12 August 2013 (UTC)

Neutral (disable)

1. The software should not be turned on or off automatically. New users should have been presented the choice to either turn it on or not, while current users should have been given notification upon login that the new software was available and asked if they want to use it. Toa Nidhiki05 18:55, 15 July 2013 (UTC)
2. I think this egg is well and truly scrambled by now. It's been deployed, and I don't think it's helpful or realistic to talk about rolling it back entirely at this stage. Lankiveil ^{(speak to me)} 11:40, 16 July 2013 (UTC).
3. I think it would have been better as an opt-in initially. At this point, there's no use crying over spilt milk, I just think that it shouldn't be implemented as default for anons until all features are built.--¿3family6 _contribs 13:33, 16 July 2013 (UTC)

Comments (disable)

1. I read over the opposes, and it's clear to me that people are reading something that I didn't write. I didn't say to blow this up. I said to make it so that it was only available to people that consciously know that they are testing it. An editor that has never edited before and doesn't know how to check that his edit was successful shouldn't be presented with an "edit" button that leads to buggy software. This needs to be software that experienced editors consciously turn on if they want to, not software that you have to learn how to avoid. I don't see how this is an "extreme choice" at all.—Kww(talk) 16:24, 11 July 2013 (UTC)

7. VisualEditor, as currently deployed, is a useful feature

Support (useful)

1. Ypnypn (talk) 20:56, 11 July 2013 (UTC)
2. It's nice for copyediting, which is what I have mostly been using it for. — This, that and the other (talk) 01:10, 12 July 2013 (UTC)
3. Weak support I find it useful, although this is purely anecdotal and likely not worth a lot. The opposes likely do raise valid points but I have not encountered any bugs or misedits to actually rescind the feature (again anecdotal on my part, your mileage may vary), IRWolfie- (talk) 10:39, 12 July 2013 (UTC)
4. Whole-hearted support The VE has improved fast since its deployment and the way it is going, I have no doubt that it will quickly obsoletize the source editor interface. Sorry, I do not see much use for this RFC. The future, including the near future, belongs to the VE.OrangesRyellow (talk) 16:38, 13 July 2013 (UTC)
5. ¿3family6 _contribs 13:36, 16 July 2013 (UTC) It certainly comes in handy a lot of times, and is quicker then wading through massive wiki-code, especially when there are a lot of references. The only thing preventing me from using it all the time is the problem of lost content in edit conflicts, timing out issues, and the lack of support for wikitables and a lot of templates.
6. Support It has no problem with simple prose additions and corrections, which constitute a lot of edits both for me and for occasional editors - for this type of edit it presents the advantage that you don't have to locate the corresponding point in the wikitext. I think it will become more useful for other types of edits as it's improved. Dcoetzee 09:29, 3 August 2013 (UTC)
7. Well, I certainly find it useful, even if other users don't. For certain edits, it's quicker and simpler to use VisualEditor than the wikimarkup interface. Being able to see changes immediately rather than having to click 'show preview' is a particular advantage. Robofish (talk) 00:42, 4 August 2013 (UTC)
8. Support There are many smart people, even academics who live and breath citations and research, who simply get scared off by a wall of technical markup for a variety of reasons. For this reasons Visual Editor is a godsend. Even if it is a little buggy right now, that will be fixed, but even until then: For them, the ability to edit and feel basically comfortable that they can edit a paragraph is better than them not editing at all. Getting more people involved is always useful. --Monk of the highest order^(t) 04:24, 12 August 2013 (UTC)

Oppose (useful)

1. No, not as currently deployed. It definately has the potential to be. But not yet. Right now its more trouble than its worth. Kumioko (talk) 20:59, 11 July 2013 (UTC)
2. Oppose as currently deployed, Visual Editor has multiple bugs that are preventing quality edits that are disruptive to Wikipedia. If you want to use it in your sandbox, go right ahead but it should not be used to edit articles in mainspace. Further, it is disruptive to the process of editing as there was no pre-deployment training and what notification steps that were taken were woefully inadequate. This is preventing good quality edits from taking place and requires follow-up with articles that have been editied with VE to make sure that layouts are good, tables are proper, templates are in place, etc. Any of the bugs that have been found to still be open in VE require an additional "cleansing edit" to fix it. So experienced editors are having to follow VE editors to fix the trail left behind instead of working on improving the article itself.--Paul McDonald (talk) 21:05, 11 July 2013 (UTC)
   1. For example this edit shows how easy it is to vandalize wikipedia with Visiual Editor. (As I understand it, this edit was made with VE. If I'm wrong, please correct me).--Paul McDonald (talk) 18:56, 12 July 2013 (UTC)
3. - While it has potential the numerous bugs prevent it from being useful. At the moment it is doing more hindering and breaking of stuff than helping. PantherLeapord (talk) 01:39, 12 July 2013 (UTC)
4. Not at present. Lots of bugs, confusing to new editors (based on visitors to #wikipedia-en-help), and chasing good edits with bad. —Jeremy v^_^v ^Bori! 02:18, 12 July 2013 (UTC)
5. Nope, not as "currently deployed". GiantSnowman 10:44, 12 July 2013 (UTC)
6. Oppose per Paul McDonald and PantherLeapord. The extra work created by the bugs negate any slight usefulness to a segment of the users through its opportunity cost: Every moment someone's fixing VisualEditor disasters is a moment not being spent on a myriad of other problems and improvements. Adam Cuerden ^(talk) 20:01, 12 July 2013 (UTC)
7. No, not as "currently deployed". I said more about it in my comment to another one of the polls, but I think, like certain good-faith disruptive editors, it causes more problems than it solves. — Arthur Rubin (talk) 21:40, 12 July 2013 (UTC)
8. It is less than useful—making substantial edits with it is at best inefficient and at worst impossible. Plus the new buttons get in the way of stuff.—Love, Kelvinsong talk 23:22, 12 July 2013 (UTC)
9. Strong Oppose whoever came up with this needs their/his head(s) checked. Normal editing is faster than this...anything that is javascripted will crash 99% of browsers, it was better the way it was before, There is a good saying in the internet world Never change something not broken, everytime I make an edit with visual editor by "mistake" because I have a habit of clicking the [edit] link, I have to GO BACK and fix it the normal way... it has more bugs in its system than Pumba..--Stemoc (talk) 00:32, 13 July 2013 (UTC)
10. No. It introduces too many errors for me to call it useful overall. Pseudonymous Rex (talk) 00:41, 13 July 2013 (UTC)
11. It would be a useful feature if it was "largely bug-free". Robert McClenon (talk) 16:26, 13 July 2013 (UTC)
12. Not yet fit for purpose, and creates too many problems to be a genuine improvement. Anaxial (talk) 18:10, 13 July 2013 (UTC)
13. No f*****g way! The Banner talk 23:17, 13 July 2013 (UTC)
14. As it does not support auto filling of PMIDs and ISBNs I do not find it useful. Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:19, 14 July 2013 (UTC)
15. Not as "currently deployed"! Hullaballoo Wolfowitz (talk) 13:11, 14 July 2013 (UTC)
16. Jguy _Talk^Done 13:35, 14 July 2013 (UTC)
17. Insulam Simia (^talk/_contribs) 13:42, 14 July 2013 (UTC)
18. Too buggy and clunky to trust it, so no, it is not. -- cyclopia^speak! 10:20, 15 July 2013 (UTC)
19. Something that is mostly broken cannot be useful, period. Lukeno94 (tell Luke off here) 11:54, 15 July 2013 (UTC)
20. For me, the Visual Editor as installed here on Wikipedia doesn't even load. That's regardless of what browser I use (Safari, Chrome 28.0, Firefox 22.0). On Wikia (which I don't edit), at least the thing loads in Firefox, but here in Wikipedia clicking Edit has no effect whatsoever (except on the odd occasion when it brings up blue bars that then continue flashing forever without ever getting to the point where it would be possible to edit the text.) Andreas JN466 12:03, 15 July 2013 (UTC)
21. It's not useful to me, and it doesn't appear to be useful to other serious editors. Toa Nidhiki05 18:56, 15 July 2013 (UTC)
22. Useful my arse! - →Davey2010→→Talk to me!→ 19:16, 15 July 2013 (UTC)
23. I have tried to move and resize an image and to add and edit an infobox... That was not exactly a great success... For example, the interface indicated that the image should be moved by "drag and drop", but I have failed to achieve much... Did anyone actually find the "VisualEditor" easier to use than "wikitext"..? Or just "newer", "cooler", "nicer" etc.? I guess that if I was a newbie I would be very confused by this interface - and I do not remember having any problems learning the "wikitext" back when I started... Thus "VisualEditor" seems to be useless to everyone... --Martynas Patasius (talk) 20:42, 15 July 2013 (UTC)
24. For anything but very minor copyediting, it is either incredibly awkward or simply does not work. postdlf (talk) 21:38, 15 July 2013 (UTC)
25. I've turned it off because it's simply not useful in its current state to me, and it actively inhibits my productivity. I'll be giving it another try in a few weeks probably after some bugs have been squished and its stabilised a bit, and my opinion on this question may change. Lankiveil ^{(speak to me)} 11:41, 16 July 2013 (UTC).
26. Too slow and too buggy. Best thing now would be to remove it from EN wiki, fix the known bugs and then try a new round of Beta testing on a wiki that volunteers to be guinea pig - I'm sure if you ask on meta someone will volunteer. ϢereSpielChequers 23:28, 16 July 2013 (UTC)
27. Try again when you have fixed the annoying, known bugs. MER-C 04:03, 19 July 2013 (UTC)
28. No, never. Matthiasb (talk) 15:57, 19 July 2013 (UTC)
29. — Scott • talk 20:45, 19 July 2013 (UTC)
30. Useful for vandals to creatively wreck article formatting?  Sandstein  22:28, 19 July 2013 (UTC)
31. For the tasks that I perform, I usually end up adding both content and wiki markup at the same time. In that capacity, VE is not yet a useful feature. --Cryptic C62 · Talk 00:44, 20 July 2013 (UTC)
32. Let me quote Kumioko. "No, not as currently deployed. It definately has the potential to be. But not yet. Right now its more trouble than its worth." --Lucas (talk) 01:04, 20 July 2013 (UTC)
33. As it is, it isn't even usable for copyediting: there's too much chance of messing up the format, and it slows everything down. Copyediting and making small changes to needs to be quick to be efficient. At first I tried just letting it run and then closing it, but I found I had to wait and check the edit every time. Yes, it';s improving--at first, it messed up 3/4 of the edits, now it's only 1/4, but that's too many. DGG ( talk ) 02:54, 20 July 2013 (UTC)
34. Strong Oppose Certainly not now (though it could be). Double sharp (talk) 03:33, 20 July 2013 (UTC)
35. Per Sandstein. --AFBorchert (talk) 08:21, 20 July 2013 (UTC)
36. The VE is not useful to me until it can handle math in a decent way.-----<)kmk(>--- (talk) 11:46, 21 July 2013 (UTC)
37. Really not so far. --Roberto Segnali all'Indiano 12:55, 22 July 2013 (UTC)
38. No, it is an annoyance that does not even respond to standard to browser commands, ie "back" does not work like it does absolutely everywhere else in the known universe. VanIsaac_{WS Vex}^contribs 22:07, 25 July 2013 (UTC)
39. Useful for pissing off editors so they quit or rise in protest against WMF arrogance and incompetence? Kiefer.Wolfowitz 22:45, 25 July 2013 (UTC)
40. Oppose Not useful right now - needs a lot more testing and improvement. Gandalf61 (talk) 09:55, 26 July 2013 (UTC)
41. --Shadak (talk) 16:01, 29 July 2013 (UTC)
42. -Rushton2010 (talk) 18:49, 29 July 2013 (UTC)
43. Maybe it will be, later, but for now it's a little like a not-now RfA. --Tryptofish (talk) 23:20, 31 July 2013 (UTC)
44. This is useful only to the developers who are still trying to figure out how to make it work. This is a long way from being useful to anyone else. –Wine Guy~Talk 15:05, 2 August 2013 (UTC)
45. Not useful. Confusing, and creates many edits with markup errors, adding overheads of fixing these errors or incompetencies by other experienced editors. Gryllida 08:12, 6 August 2013 (UTC)
46. That's a fair assessment. – Quadell ^(talk) 15:48, 9 August 2013 (UTC)
47. Too buggy, clunky, slow (both technically and procedurally) and patronising for experienced users. --W. D. Graham 13:43, 4 September 2013 (UTC)

Comments (useful)

• At this present moment, it is both slightly useful (I find copyedits on a complex article easier with it) and has some serious problems - David Gerard (talk) 21:12, 11 July 2013 (UTC)
• My personal "§usage scenario" would be using it on discussion pages, so I can directly answer a comment I just read without the need to search the correct position in the Wikitext Editor again. Since VE is not deployed on any discussion pages, it's currently useless for me. --Patrick87 (talk) 09:10, 12 July 2013 (UTC)

Given that the A/B test results (m:Research:VisualEditor's effect on newly registered editors/Results - [6]) say "Newcomers with VE enabled performed less wiki-work and spent less time editing overall. They were also less likely than users with the wikitext editor to eventually save an edit.", I guess that we have an answer that the "VisualEditor" is not useful even where it was advertised as being "especially useful"... I guess now the question is "Shall we look for ways to roll the change back that allow WMF to 'save face'..?"...

In connection with that I wonder: what does WMF generally do with the results of their "research"..? Through some links I have found m:Research:Notifications/Experiment 1 ([7]) that says: "Our results also show that newcomers with Notifications enabled are more burdensome. They made more edits that were reverted by others and they were more likely to be blocked.". Is anything being done about that..? Or are WMF simply trying to use the English Wikipedia to advertise features of MediaWiki..? --Martynas Patasius (talk) 18:24, 20 July 2013 (UTC)

To be fair to the WMF, the data are for a version even buggier than the one used now. VE was prematurely entered into testing, launched before that testing, and the tragedy is that, by the time it is a good product, everyone will have given up on it. Adam Cuerden ^(talk) 19:24, 20 July 2013 (UTC)

Yes, that was an older version. But that is the data that we have. Sure, it is always better to have newer, more complete, simply better data, but in the end we still have to use the data we actually have. So, of course, after getting such results WMF should have repeated this test with a less buggy version - but they didn't, and I am not sure that it is unfair to them to use the last data they provided... They can always repeat the test it they feel the data ends up being outdated and misleading. --Martynas Patasius (talk) 22:28, 20 July 2013 (UTC)

• Biased population that is taking part in this survey (experienced editors) makes this question pointless. Of course it is not useful for us, we don't need it. Ask the newbies, and see what they think. I bet their answers would be a bit different. Sigh. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 21:56, 26 July 2013 (UTC)

  The WMF usage logs suggest that it's not useful for newcomers. — Arthur Rubin (talk) 22:00, 26 July 2013 (UTC)

  • As do the users visiting #wikipedia-en-help. They're just as confused by VE as they are by Wikimarkup. —Jeremy v^_^v ^Bori! 22:16, 26 July 2013 (UTC)

    • Just take a very long wikibreak (like when I disappeared for 9 months or so in 2010) and you'll be surprised how much of a newbie you'll have become! :-) More seriously, out of all the vandalism you've seen (before VE entered beta), what percentage of them would have been good edits but for screwing up the wikimarkup? (I don't think there's very many.) Double sharp (talk) 11:30, 29 July 2013 (UTC)

  Statistics for the last 168 hours are that 5.7% of edits by experienced accounts were made with VE, 36% of edits made by new accounts were made with VE, and 17% of IP edits are made using VE. So, in its intended group, it is being rejected by roughly a 2:1 margin. It bounces around those percentages without any strong trend upwards or downwards in any group.—Kww(talk) 22:51, 26 July 2013 (UTC)

• It is useful, but for limited purposes, but the WMF product managers still believe its perfect for all purposes. We need a blacklist of pages it doesnt work on; we need a way to switch between VE and SE; and .. we .. the community .. need to building gadgets that address some of the problems/gaps with VE. It is extensible; perhaps a bit brittle at the moment, but that is nothing new - it is a wiki. John Vandenberg ^(chat) 12:56, 27 July 2013 (UTC)

8. Flow should support markup editing

“ "You should strive to achieve Zen acceptance that the only editor for Flow will be the VisualEditor. If, by the time Flow is released, the VisualEditor supports a native code editor, it will likely be there. But nothing is promised - nor can it be." - Jorm (WMF) ”

This is completely unacceptable, and violates even the promises made at launch. Even the FAQ for VisualEditor has been changed on account of this.

Bots cannot edit VisualEditor, amongst other things. The things this will kill functionalities of include:

1. Good articles - the easy promotion of good articles is dependant on bots being able to edit talk pages. Should this functionality disappear, we're screwed.
2. Discussion of specific article text: There are no plans to allow direct copy-paste with markup included from the VisualEditor.
3. Usage by the visually challenged. Has the WMF even thought about making the VisualEditor work well with screenreaders?

Jorm went on to add "It is entirely possible that the data for each post will not be saved as wikitext because there are considerable performance issues that arise when doing so. If this is the case, things like templates will simply be unable to be supported." and "I would dearly love to kill off Wikitext."

Is Jorm acting in a rogue manner? Possibly. Nonetheless, the (WMF) after his name means that his statements should be taken with all due alarm.

Update

Jorm has answered some questions here.

Downsides: When asked if various talk page tmeplates will break, including FA, GA, Wikiproject, etc. his response was, "Flow will not prevent those from breaking. Flow will provide different, better ways of managing these workflows. That is what this project is about entirely." He also says it's "not likely" that communities will get to decide whether or not Flow is turned on for them. Which means they learned nothing.

That's not very reassuring. However, many of his other responses are somewhat reassuring, though... questionable whether he's thought them through, perhaps: He claims Flow will be opt-in, for instance, though how that'll work if it doesn't support Wikimarkup, he claims copy-paste will be fine, when you can't copy-paste in VE without losing all markup, up to and including carriage returns, he claims that giving notice for people to convert will solve all problems, he claims there will be a method to turn off flow on collaborative pages, such as drafts but given all the things we were promised for VE that didn't happen... Adam Cuerden ^(talk) 01:33, 15 July 2013 (UTC)

Support (talk)

1. Adam Cuerden ^(talk) 23:11, 14 July 2013 (UTC)
2. It's not just insane, it is a slap in the face to the many editors of Wikipedia who are not interested in the VisualEditor. Rolling out a a buggy, bad beta version of a new editing system is one thing, but making that same version mandatory for talk pages shows that the WMF does not care what established editors think, and is not really interested in their opinions or the time and hard work they spent on talk page bots - which will presumably become useless if VE is required on talk pages. Toa Nidhiki05 23:49, 14 July 2013 (UTC)
3. There needs to be some people getting fired over this, starting with Jorn (WMF). This is entirely unacceptable. —Jeremy v^_^v ^Bori! 23:54, 14 July 2013 (UTC)

   Wtf? Legoktm (talk) 02:37, 22 July 2013 (UTC)

4. I dislike the tone of the heading, but support the underlying message: disabling VE should disable VE, and it's not acceptable to block editors that aren't using VE for discussion.—Kww(talk) 00:11, 15 July 2013 (UTC)
5. Support conditionally striking the word "insane" and substituting "not the right move" (hey, just trying to be WP:CIVIL). It's a bad idea to go that direction. Unless, of course, the goal of the foundation is to anger experienced editors so much that they leave and never come back.--Paul McDonald (talk) 00:12, 15 July 2013 (UTC)

   Very well. Changed the header. Adam Cuerden ^(talk) 00:29, 15 July 2013 (UTC)

6. Support, since Brandon seems totally unteachable regarding the issue. If we have learned one thing from the VE deployment, then that it will never ever be able to completely replace a Wikitext editor. Therefore denying the need for a markup editor for Flow is just ridiculous. --Patrick87 (talk) 00:39, 15 July 2013 (UTC)
7. This is nonsense, and it's getting in the way of the goal of building an encyclopedia. Something needs to change at the foundation if it believes this kind of behavior is acceptable. Everyking (talk) 00:41, 15 July 2013 (UTC)
8. No. Reaper Eternal (talk) 01:11, 15 July 2013 (UTC)
9. VE's deployment reminds me of New Coke. Replace a tried-and-true formula with a new one that its developers are convinced with be better than the original formula, but turns to be much worse. If VE is to be permanently part of Wikipedia, keep source editing so bots still function correctly and editing are not forced into using VE. Wikipedia is about consensus, not coercion. SMP0328. (talk) 01:38, 15 July 2013 (UTC)
10. Flow seems to be a shift from the bazaar model of development where any editor on this wiki could develop a template for a specific feature, to a cathedral model of development when its only going to be a small group of external priest with source code access who can determine how talk pages function. It seems to be missing the essential feature of being able to discuss the wikitext used in an article, give examples of its use and see how it will appear. --Salix (talk): 04:46, 15 July 2013 (UTC)

    Nope, that was Pending Changes. Remember that PC was enabled in part because the developers refused to do any work (needed or otherwise) on it unless it was activated on en.wp, and told the closers of that RfC such. —Jeremy v^_^v ^Bori! 19:52, 15 July 2013 (UTC)

    This really needs to change IMHO. If it affects the editors, they should have a say (and a real one, for that matter). The developers really have too much power, by what you stated. WP:CONEXCEPT may be policy, but I'm starting to wonder how many actually agree with it. Double sharp (talk) 03:29, 20 July 2013 (UTC)

11. This removes the "wiki" from Wikipedia. Agree that whoever in WMF is thinking about this should either do a full 180-degrees turn, or quit the Foundation. -- cyclopia^speak! 10:23, 15 July 2013 (UTC)
12. Jorm is simply not listening to the community on this issue. He needs to take a cold shower. (I'm not sure that this question really belongs here, but I'll respond to it while it is here.) — This, that and the other (talk) 11:00, 15 July 2013 (UTC)

    Lukeno94 (tell Luke off here) 11:53, 15 July 2013 (UTC)

    Indenting duplicate !vote. —Soap— 01:43, 21 July 2013 (UTC)

    I'm a fucking idiot, thanks Soap :) I need to pay more attention! Lukeno94 (tell Luke off here) 21:03, 23 July 2013 (UTC)

13. Insulam Simia (^talk/_contribs) 19:10, 15 July 2013 (UTC)
14. Absolutely. postdlf (talk) 21:39, 15 July 2013 (UTC)
15. ¿3family6 _contribs 13:39, 16 July 2013 (UTC) Absolute, unequivocal support. I can't believe that turning of wikitext entirely is actually being considered.
16. Support FLOW as markup editing, for admins: The admins would revolt without user-templates to post repetitive messages to new users, and WP would soon drown in vandalism with no control of new users. Contributions to support those hacked articles would vanish. Within a few weeks, FLOW would be canned, and news reports of the debacle would embarrass WMF managers to fire key people, to prove they were not hopelessly incompetent managers. It would take a while, but WMF people would lose jobs and reputations if FLOW did not support wikitext. No fear of that. -Wikid77 (talk) 14:48, 16 July 2013 (UTC)
17. Support of markup editing in discussion pages is vital. That is the way to achieve the flexibility of current system, instead of mere ability to do something that the developers have thought about. For example, many types of refactoring are necessary on talk pages once in a while. However, "Flow" itself is not vital at all and should be cancelled if such goals are not going to be achieved (or is it already too late to cancel and we should have complained with even more haste?). As far, as I understand, most of its features can be "emulated" using existing markup with relatively minor additions. For example, if we had a way to generate a globally unique number, we could add them as anchors to the posts - and links to those anchors, showing the post being replied to. Now, since it has been claimed that those UI changes cannot affect bots - unfortunately, WMF does not seem to be willing to promise we will have "wikitext" that we know at all (or did anyone make a real binding promise by now?). And while it might be made easy for a bot to edit the "wikitext" without special UI support, it will be much harder without having any "wikitext" to edit... --Martynas Patasius (talk) 23:29, 17 July 2013 (UTC)
18. Obviously. However, I think FLOW should be canned - it looks like some low-rent forum, or like it was designed in the 1980s, and just isn't an improvement. Lukeno94 (tell Luke off here) 07:52, 18 July 2013 (UTC)
19. Flow belongs on the garbage tip. MER-C 04:02, 19 July 2013 (UTC)
20. Rubbish. Start again from the crap. Matthiasb (talk) 20:32, 19 July 2013 (UTC)
21. — Scott • talk 20:46, 19 July 2013 (UTC)
22. Strong Support We absolutely do not need another recurrence of WP:IDIDNTHEARTHAT from the WMF. Double sharp (talk) 03:31, 20 July 2013 (UTC)
23. Please don't as this breaks established collaborative working procedures on project pages etc. --AFBorchert (talk) 08:29, 20 July 2013 (UTC)
24. Support, at least if the use of Flow will be standard on talk pages. There must be the capability of markup editing. Robert McClenon (talk) 22:07, 20 July 2013 (UTC)
25. --Roberto Segnali all'Indiano 12:55, 22 July 2013 (UTC)
26. Strong support. It is unacceptable to remove the ability to edit wikitext. VanIsaac_{WS Vex}^contribs 22:10, 25 July 2013 (UTC)
27. I can't believe we are even discussing this support Utterly unacceptable. In a project like this relying on volunteers, many of whom (including me) have invested a good amount of time into learning the working of the current system, such a radical change is only acceptable if explicitly requested by the community. I don't see that this is the case here. And the benefit (if any) this would have is probably exceeded by the amount of stuff this might break. -- Toshio Yamaguchi 12:23, 27 July 2013 (UTC)
28. Gengis Gat (talk) 12:38, 27 July 2013 (UTC)
29. I've commented a lot at the Flow talk page, but I intend my comment here to be constructive encouragement to work on making it happen. --Tryptofish (talk) 23:22, 31 July 2013 (UTC)
30. STRONG SUPPORT - →Davey2010→→Talk to me!→ 14:54, 2 August 2013 (UTC)
31. If people like Jorm are allowed to have their way over the strong objections of the community, it will be the end of wikipedia as we know it. That's just sad. –Wine Guy~Talk 15:18, 2 August 2013 (UTC)
32. I didn't know about this! Not fair. It should Support. -- ɑηsuмaη ^{« ৳ᶏ ɭϞ »} 11:15, 3 August 2013 (UTC)
33. Sure, why not. Gryllida 08:12, 6 August 2013 (UTC)
34. Support. If you're used to editing markup it is quicker and easier to continue doing so than learn the new, complex and patronising ways to do so. In addition to that, VE will never be accessible to all users - some can't use JavaScript, or use browsers that don't support it, so they would be unable to discuss edits - either driving them away or staring unresolvable edit wars. --W. D. Graham 13:48, 4 September 2013 (UTC)

Oppose (talk)

1. As worded this statement rests on a number of assumptions ranging from unfounded to almost certainly incorrect. (For example, how can changing the editor UI break bots when bots don't use the UI in the first place? What evidence is there that the developers are ignoring the needs of the visually impaired?) —Psychonaut (talk) 07:42, 15 July 2013 (UTC)

   Indeed. It's been long known that if your bot is screenscraping, it will break. Legoktm (talk) 02:39, 22 July 2013 (UTC)

2. This is not the time and place to talk about Flow. Wait until the Flow product manager provides a design document for comment. John Vandenberg ^(chat) 12:47, 27 July 2013 (UTC)

   Sorry John, but I disagree. The earlier we can make our (near-unanimous) preferences known about these changes, the less likely we are to have inefficient, broken interfaces thrusted upon us without consent or warning. Discussing Flow here and now is an attempt to move away from the bizarre Implement, Inform model and towards the more sensible Discuss, Inform, Implement model that changes of this magnitude deserve. So, yes, this is the time and place to talk about Flow. --Cryptic C62 · Talk 16:59, 27 July 2013 (UTC)

Comments (talk)

Adam, I know that you're panicked about this. I know you're very worried because one (1) developer told you his current thinking on a future product, and those particular plans don't match your preference.

But I think you need to learn a bit more about it before you declare that none of these things can be done. For example, if you'll (please!) go over to mw:Flow Portal/Use cases#Talk_namespace, and look around for the word "metadata", you will see that the ability to edit the top of talk pages is something that is already planned for Flow. There's nothing about Flow that will prevent GA articles from being properly recognized. In fact, Flow will make it possible to have a built-in workflow specific for the entire GA process, with no need for bots that eventually (except all the times they don't work) update the data.

While you're reading, let me suggest that you look at WT:Flow#What Flow actually is. That might help you understand the concepts that Jorm is working with. WhatamIdoing (talk) 01:07, 15 July 2013 (UTC)

About #3: Yes, Jorm has already told you that he's making plans for visually impaired users. WhatamIdoing (talk) 01:22, 15 July 2013 (UTC)

And I'm supposed to be constantly monitoring a Liquidthreads page on another wiki, which is already very hard to use, just in case a response happened in the time I was composing things for here? Adam Cuerden ^(talk) 01:27, 15 July 2013 (UTC)

Check out the whole of mw:Flow Portal/Use cases. See in particular all the references to bots, and the API that will be developed to support the tasks that they'll still perform. Bots will be able to contribute to Flow. Please read more of the documentation! The other pages are insightful, too.

(I do agree with your concerns about VisualEditor (in its current state - it'll be a lot better in 6 months...) being the primary editing-method in Flow, but we can't have a good discussion about that if you're spreading incorrect information (misassumptions) about bots and talkpage-banner-templates in the same thread (and multiple other locations).) –Quiddity (talk) 02:15, 15 July 2013 (UTC)

All current bots will break. Further, Jorm has said that talk page templates would. Adam Cuerden ^(talk) 02:17, 15 July 2013 (UTC)

All current bots will have many months of time (between now, and the opt-in period, and then still more until the larger roll-out) to update their code. That's the nature of updates. And why lead-time is given. –Quiddity (talk) 02:21, 15 July 2013 (UTC)

Tell me. How bot-editable is VisualEditor at this time? Adam Cuerden ^(talk) 02:23, 15 July 2013 (UTC)

Bots don't use the old editing environment either, so why would they use the VisualEditor environment? Bots don't click an edit button: they change the database more directly. And why do you believe that all the current bots will break? WhatamIdoing (talk) 04:43, 15 July 2013 (UTC)

Bots do, however, operate by directly manipulating wikitext. If bots can continue to edit using wikitext, there's no good reason to deny editors the same ability. If they cannot continue to edit using wikitext, they are, indeed, rendered broken by Flow.—Kww(talk) 18:57, 15 July 2013 (UTC)

@WhatamIdoing:, why don't you ever respond to the direct complaint? WMF swore up and down that wikitext editing was not going to go away and that editors were not going to be forced to use the Visual Editor, yet, the only editor that is being supported by Flow is the Visual Editor. Why did they make such promises only to turn around and renege on them? Why should people be required to use the Visual Editor in order to communicate with other editors?

I draw your attention to this post, where you were adamant that no one was being "forced" to use VE.—Kww(talk) 02:56, 15 July 2013 (UTC)

Sure, I can respond directly to that complaint: It's based on a false assumption. Jorm publicly said months ago that VisualEditor would not be "the only editor that is being supported by Flow". It might be the only editor that offers full functionality, but it's not going to be the only editor that is supported. It can't be the only editor, because VisualEditor requires Javascript, and not all users have Javascript. Jorm's current lack of interest in supporting the 2002 editing environment is not the same thing as requiring 100% of users to use VisualEditor. WhatamIdoing (talk) 04:43, 15 July 2013 (UTC)

2002 perhaps, and also 2013. Double sharp (talk) 07:25, 15 July 2013 (UTC)

@WhatamIdoing:,Jorm has publicly stated here that VisualEditor is the only editor being supported by Flow. If he said something different months ago, he has publicly changed his mind. The comment you have pointed at appears to be referring to some kind of reduced-functionality version of Visual Editor, not retaining our current capability. Hopefully, you wouldn't consider offering a reduced functionality version of Visual Editor to be way of honoring the assurances that we won't be forced to use Visual Editor.—Kww(talk) 04:55, 15 July 2013 (UTC)

Jorm's comment is about a reduced-functionality version of Flow, not of VisualEditor. He stated there that some features in Flow are unlikely to work for people without Javascript. Whatamidoing (WMF) (talk) 17:22, 15 July 2013 (UTC)

I feel like you must be reading a completely different discussion from the rest of us, @Whatamidoing (WMF):. Can you point to any discussion, anywhere, where Jorm commits to supporting any editor inside of Flow but the Visual Editor?—Kww(talk) 17:33, 15 July 2013 (UTC)

"We definitely want to make sure that you can continue to post to Flow boards with older browsers, and since VisualEditor doesn't support them, we'll likely have to provide a fallback mode."[8]. and "Obviously there will be a fallback version."[9]. –Quiddity (talk) 18:18, 15 July 2013 (UTC)

You failed to include important parts of those quotes, Quiddity. Parts like "That doesn't mean that some kind of source or markup mode is necessarily impossible, but it may be different 'under the hood' than wikitext as we know it" is not a commitment to continue to support our current editor. He's certainly committing to a fallback, but he's not committing to support our current wikitext.—Kww(talk) 18:50, 15 July 2013 (UTC)

As I said above, I do agree with the concerns about VisualEditor being the primary-planned method, given its current state, and its non-majority usage in article-editing (particularly by the regulars/powerusers). However, your question was "Can you point to any discussion, anywhere, where Jorm commits to supporting any editor inside of Flow but the Visual Editor?" which I answered. –Quiddity (talk) 19:03, 15 July 2013 (UTC)

• Okay, let me break this down for you, Adam. I'm picking here to reply given that the other threads you started seem...somewhat poorly placed:

1. Good articles - the easy promotion of good articles is dependant on bots being able to edit talk pages. Should this functionality disappear, we're screwed.

   The bots are not and never have been dependent on the human-readable interface to Wikipedia.

2. Discussion of specific article text: How is one expected to copy-paste from the VisualEditor? Is that even a thing?

   It's going to be; if we're talking about Flow having a VE, we're not taling about copy-pasting from, we're talking about copypasting between.

3. Usage by the visually challenged. Has the WMF even thought about making the VisualEditor work well with screenreaders?

   Yes; accessibility is a pretty big deal, and thankfully we have a lot of good editors who use screenreaders and are willing to turn up when we get it wrong.

• I want to restate that you are holding an RfC question over one staffer's statement, and started it before offering him the opportunity to clarify or rebut. Adam, that comes off as coming with a pretty substantial helping of bad faith, particularly given the overall bias of this RfC. I'm not asking you to like us, I'm asking you to remember that we're both on the same side here and trying to do what we think is best for Wikipedia. For us to do that, we need to have someone questioning us and playing devil's advocate, because we can and will screw up. But the most efficient way to do that is not to try and get the entire community worked up about an issue. If something is a big deal, just tell us. You don't need to do more than that, and I worry that we're going to get a lot of miscommunication and fog around here if everyone is always broadcasting on the widest band. Okeyes (WMF) (talk) 05:21, 15 July 2013 (UTC)

• I can understand your objections to Adam's style, but I hope that it doesn't get in the way of the fact that there is a quite legitimate concern here. If we can't take Jorm's word for it, who's word can we take? How should we communicate that Flow cannot use Visual Editor (or stripped-down versions of Visual Editor) as its only interface, and it needs to support the raw entry of wikitext as a medium?—Kww(talk) 05:30, 15 July 2013 (UTC)

• I agree, there is a legitimate issue here, and I'm sad to see it get distracted-from or buried - but distracting from the issue is precisely what happens when people intentionally drop the issue in a highly disruptive way. It gets our backs up, it worries people, and we have to spend our time rapidly responding to a hundred different queries instead of coming up with one comprehensive answer. So, from my perspective, I'd suggest approaching things with the attitude of: it's not set in stone until either (a) code has been deployed for it, (b) senior management has made a statement on it or (c) someone else has made a statement on it that encompasses management's opinion. I've been here for two years, and in my experience a lot of things are very variable until stuff is actually built, and people tend to intercede and make changes at every step of the process. As an example: the first version of Page Curation we came up with was based around the idea that we'd have a list of inappropriate things a page could have, and users would mark or tick off a number of those points. The article would then be moved into secondary queues, and users could mix-and-match what issues they wanted to look at: you could say "show me only those articles that haven't been checked for [deadlinks/copyvios/delete-as-applicable]" or something. This view lasted up until (and actually slightly after) we started writing code.
• In regards to the issue at the heart of the matter, here, the need to have a backup to the VE, I think the community's expectations on that front have been pretty well communicated already. I can only speak for myself, but I'm fully aware that this will be a user expectation, and one with some pretty strong "for" arguments. That doesn't mean I can promise "it will happen", because as said, the conversation ends up happening over a lot of levels - but we'll be going into those conversations with this issue in mind. Ultimately that's the main thing that users surfacing problems achieves, and it's been achieved. Okeyes (WMF) (talk) 05:46, 15 July 2013 (UTC)

• I too, agree that there is a legitimate concern, but I also believe that a reasonable person would have gotten his facts straight before spamming this misinformation across not just multiple pages here, but across a remarkable number of wikis. For example, Jorm has directly told Adam that using VisualEditor is his current thinking and the most likely outcome, but that it is not set in stone. I hope that Adam will be equally aggressive about correcting the misinformation he's spread as he was in impulsively putting it out there in the first place. Whatamidoing (WMF) (talk) 17:22, 15 July 2013 (UTC)

• What people are trying to tell Jorm is that his plan is unacceptable. I don't see any signs that he is listening to that feedback. It's the adamant refusal to listen that has gotten Adam so excited. If Jorm had simply said "whoops, I'll go fix my mistake" instead of telling us all that the only editor he was going to support was the Visual Editor, this whole flareup would not have occurred.—Kww(talk) 19:01, 15 July 2013 (UTC)

Quite. I actually questioned him on WT:Flow, and he told me point blank that GA, FA, and Wikiproject templates would probably break, but Flow would have new ways to handle it that would have to be recoded from scratch. There are over five million Wikiproject template transclusions on English Wikipedia. That's a lot of recoding.

It's now becoming clear that Jorm has spent much of the last week saying things as being definitely true that the WMF wouldn't support at all. Look at some of the things Jorm said that I quoted, and ask yourself whether you'd be alarmed if you saw them, in a situation where a rollout of controversial software had just happened.

Hell, I've said it before and will say it again. I think VE is a good idea. I think that there should be an easy way to turn it off, so you don't have to retrain your muscle memory, and think Wikimedia did it a huge disservice by the manner of its launch - it's buggy and largely unusable as it is now. I can't even scroll down to the bit of text I want to edit in it because it slows to a crawl when I slow. It damages the code of the site. It's not ready. But it's a good idea, and, were, for instance, the WMF to switch it out of default to "opt-in" for now, and stop the frankly hugely counterproductive pushing forwards with the schedule, I'd look forwards to a relaunch in a few months, and would likely give it another try then. (Hell, another wiki I'm on already has a working Visual Editor, and I think that one's pretty great.) But you can't launch buggy software, make it the default, ignore it's causing damage to the code of articles, try to prevent people from turning it off, when misclicking - a.k.a. clicking exactly where you used to click - means a 15-second loadtime and an unusable interface. - and expect happy users.

But Jorm's statements took the problems to a whole new level. Adam Cuerden ^(talk) 07:21, 16 July 2013 (UTC)

Not really. Jorm made some statements, yes. Instead of reaching out to any other staffer for clarification, you immediately spammed your interpretation of those statements to around a dozen wikis and noticeboards (I note you've been scolded or hatnoted in a chunk of those). If what you're looking for is to resolve a problem, you might want to actually talk to us about it instead of trying to rile everyone up. We are capable of understanding something is a problem without an RfC. Okeyes (WMF) (talk) 13:33, 16 July 2013 (UTC)

Also, in terms of "recoding", it's the same amount of work no matter how many pages are affected. Re-writing a bot is re-writing a bot, no matter whether the bot affects five pages or five million pages. WikiProject banners and the like will probably need to be re-located (off a page that starts with Talk: and onto a page that start with whatever the namespace is used for metadata about an article), but if that's the only functional change, then that's about ten seconds work for "recoding". Bots don't normally touch the WikiProject banners, so there should be no "recoding" needed for them. Other functions will be built-in to Flow and therefore simply obsolete. The amount of time needed to "recode" the talk-page archiving bots, for example, will be the amount of time needed to turn them off. Whatamidoing (WMF) (talk) 17:51, 16 July 2013 (UTC)

I'm the engineering director responsible for both Flow and VisualEditor, so thus the cause of a lot of vitriol on this RFC :-(. Please note though, I am not the product manager of either products, and don't want to put words in @Jorm's mouth. (Feel free to correct me, Jorm). My understanding of the statement above, from an engineering perspective is that the default data format for Flow is going to be HTML+RDFa not Wikitext. Which has a number of implications being alluded to, but not in the manner that this item is implying.

To explain. Traditionally this is the model:

Reading: (Wikitext) -(mediawiki parser)-> HTML

Editing: (Wikitext)-(editing)-> Wikitext modified -> SAVED

The big thing to note is that this is one way, there is no way to go from HTML back to Wikitext using the current stuff, so Wikitext remains the canonical.

This is the model for Visual Editor

Reading: (Wikitext) -(mediawiki parser)-> HTML

Source Editing: (Wikitext) -(editing)-> Wikitext modified -> SAVED

Visual Editing: (WIkitext) <-(parsoid)-> HTML+RDFa -(editing in VE)-> HTML+RDFa modified <-(parsoid)->Wikitext modified -> SAVED

The thing to note here is parsoid allows bidirectional conversion for HTML and Wikitext by embedding data needed to handle the many->one relationship between wikitext and HTML through embedded RDFa markup. [see this blog post]

The proposal (as I read it) for VE being the "only" editor for Flow is this:

Reading: (HTML+RDFa)

Visual Editing: HTML+RDFa-(editing in VE)->HTML+RDFa modified->SAVED

The important thing to note in this discussion is that this does not preclude these examples:

• Any source level editing: In theory anything that can deal with HTML markup can do this. However some features of Flow might need the RDFa metadata to function properly, so while it might render properly, it might not function proerly unless it writes the proper HTML
• Any wikitext editing: Parsoid is a two way street. Therefore, via an API (or in special cases like non-visual or unsupportable browsers/javascript-less editing), it would be possible to allow the client (user/bot) to receive Flow content in the form of wikitext via this flow:

HTML+RDFa<-(parsoid)->Wikitext -(editing by non visual client/javascriptless/bot)->modified Wikitext<-(parsoid)->HTML+RDFa modified->SAVED

• If there is a need of diffing in source mode and an HTML-diff is not available/adequate, some form of the above workflow might be needed in order to render changes (though I think product would plan to make sure that the Flow spec covers all those history needs visually within Flow, as opposed to needing this outlet).

However, this does imply that:

• Metadata (like categories in wikitext or "subscriptions" or "tagging" in Flow) would no longer be accessible from Wikitext or HTML+RDFa since Flow has no need to store metadata the way that wikitext does, which itself is an artifact of our early days that has created huge technical-debt related to wiki software integration throughout the development of MediaWiki. This does, however, imply that direct access to that metadata will be applied without the need of a visual editor or bot via API with no wikitext processing ;-)
• "In theory" Flow could support all forms of Wikitext, in practice Flow might be limited to the subset of Wikitext related to Flow discussion needs so some stuff may get munged the same way that some stuff gets munged by the VE currently. (For instance, arbitrary templates and transclusions is unlikely to be supported inside Flow. This would imply that Flow cannot replace all discussions and is unlikely to replace complex discussions like ANI until all the ANI-related workflows are described in WDM, which I imagine won't be for a long, long time :-)
• There may be features inside Flow's VE description that might be difficult to access/impossible from within Wikitext. Since the default storage format for the content is not Wikitext and won't be built with Wikitext in mind.

The above is no different that the way say a user gadget is stored. There isn't wikitext there, but the same storage engine is storing content that is Javascript, instead of content that is Wikitext. I hope that helps allay some of your concerns. - tychay (tchay@wikimedia) (talk) 20:12, 19 July 2013 (UTC)

I appreciate your comments. A serious problem, however, is that article talk pages are intended to discuss problems with articles, and hence should be able to reproduce sections of articles, with the markup remaining the same. (In fact, user talk pages also sometimes discuss problems with that user's edits of articles, and so also needs to reproduce sections of articles.) As an example now, if VE is still munging articles (changing the display, as well as the Wikitext) when Flow is implemented, there won't be any way to discuss VE problems in Flow messages; the copy in the discussion page will look exactly as it does after VE handles it, and we won't be able to see the way it was before VE handled it.

If I read your comment "For instance, arbitrary templates and transclusions is unlikely to be supported inside Flow" correctly, it means that Flow cannot replace article talk pages at all; it can supplement the existing article talk pages, but we cannot discuss article formatting from within Flow, unless all the formats are identical to those which can be generated within VE.

Actually, I can think of one way some such discussions could be implemented: Have Flow messages have the capability of including (not exactly transcluding) articles which live in the flow space (Thread:Talk:article_name/thread/index/figure_number?), but are treated as general Wikicode. However, the hooks for this need to be in place by the time Flow is first rolled out. In other words, each Flow message would have a free-format section, with the capability of editing them using the "raw" Wikimarkup editor. — Arthur Rubin (talk) 22:00, 19 July 2013 (UTC)

@Arthur Rubin First, let me say you make some great points. Right now, the primary focus for Flow, as I've gathered from Product, is to focus on user talk. This is, already, a big chunk of work right now because it also covers: welcome templates, and warnings, etc. I don't think Article Talk has been considered yet, so I'm engaging in speculation of a theoretical Flow board centered around an article without a firm deadline, adequate research, or an understanding of it as a complete replacement for something as flexible for Article Talk.

(The "Big Assumption" here that I'm implying is that all Flow pages, boards, description modules are to some extent "on rails" and make certain assumptions as to the use case being served. For instance one sort of description module might cover the equivalent served by a particular subset of user warnings on the user's talk page, a completely different description module of general user-user chatting, etc. The aggregate of all of these may serve to obsolete the need for user-talk, but no single description could completely replace User Talk's use, nor could the aggregate completely replace every theoretical possibility for User Talk. To use a poor analogy: think of Wiki markup as a completely blank piece of paper, and the Flow as a set of specialized post-its "While you were out…" Even if you do make a version to support it as a better canvas for doodling, it probably won't replace it adequately folded as a paper airplane.)

As such, when Flow extends its umbrella to cover Article Talk, the current methodology of discussions centered around Talk pages, needs to be broken down in a manner similar to user talk, and we're talking about a different set of modules. Prima facia, it seems that the current convention of quoting blocks of texts to kick off discussions in article talks is an artifact of a limitation of the software's inability to provide transclusion and direct referencing to arbitrary wikitext. When parsed by parsoid into HTML+RDFa, that is no longer a limitation. Arbitrary blocks of wikitext can be referenced and rendered for discussion with even the possibility of entire discussion blocks related to talk to be embedded within the a HTML discussion, allowing for specific parts of wikitext in specific versions to be annotated in line of the article talk (probably rendered back as a wikitext comment), instead of quoted. A pure transclusion of arbitrary templates could be allowed within the context of a "quoting module" or "annotation module" or whatever. This is one set of possibilities and pure speculation of a Flow Discussion Module that doesn't exist, but it would preclude the need for arbitrary transclusion being made available everywhere in the Flow Documents related to article talk for this one purpose.

Having said that, I don't want to imply that this theoretical would begin to cover all needs. I could see, for instance, the desire to collaborative edit and iterate on drafts of said information within the context of this theoretical Flow document. It would be my hope, at that time, that better collaborative editing could be done within the flexible framework of HTML editing, HTML diffing, historical session playback, and HTML-based real-time collaborative editing (a la Etherpad), than iterating using the save-diff review model of the current past.

I think when discussing Flow, it's important not to dwell too much on "how is Flow going to support foo feature in wikitext" and ask ourselves, "What was trying to be done when someone engages in bar action, and can I adapt a Flow module to service bar action better (by making its function evident by design) rather than by something, while free-form, is opaque to most people outside of policy and convention built by experience in this context."

Again, I want to emphasize that I'm the engineering director, and we're talking product and design so I'm least qualified to having discussed this without having put my foot-in-mouth. I deal with limits due to engineering choice, but I hope some of what I said is right. :-) - tychay (tchay@wikimedia) (talk) 00:38, 20 July 2013 (UTC)

In general, discussion of Wikitext/Wikimarkup is unnecessary, except that if Flow is to replace article talk pages, it must allow discussion of article format, including the ability to incorporate sections of articles rendered exactly the same way as they would in the article. I agree that many features of User talk pages could be done better in Flow, and, overall, Flow (with minor differences from what is presently proposed) would be an overall improvement, once bots and users were trained to use Workflows instead of substituted templates. There is still a need for a user message page with full Wikiformat, but that could be in a new namespace; perhaps, "User Discussion" rather than "User talk", but its use could eventually be rare.

As for article talk pages, there needs to be a "fallback" position if exclusive use of Flow is found to damage Wikipedia; for the moment, a feasible approach would be if Flow is run in a separate namespace ("Flow"?); the Talk namespace is left intact, and "watching" an article automatically watches both it's "talk" page and "flow" board. — Arthur Rubin (talk) 01:11, 20 July 2013 (UTC)

No need for corrections, Terry. That's exactly what's going on.--Jorm (WMF) (talk) 22:36, 19 July 2013 (UTC)

What this discussion misses is that many of us talk in Wikitext. I don't even use the little buttons that are available in the standard wikitext editor: I directly type in markup. If I want to illustrate a point that is best suited with a table, I will insert a table, and I only know how to build tables in wikitext. Common templates for things like calling up article histories, contribution lists, and block logs for editors come out of my fingers without thought. When I create a message in Flow, I don't want to have to do something special to support wikitext, I want to just set an option that says that I type in wikitext and proceed to type in wikitext.—Kww(talk) 08:29, 20 July 2013 (UTC)

I find Tychay's response to Arthur Rubin hard to follow in parts, but one thing I get from it is that he is trying to deflect Arthur's challenge about how to deal with cited, feature-rich article content on talk pages by saying that Flow is currently only being planned for "user" talk. This seems to be based on the misunderstanding that people discuss cited article content only on article talk pages. Tychay, let me make this crystal clear: I need to be able to discuss cited article content on my user talk too. I also need to be able to use tables, ref footnotes, ref templates and inline templates in my user talk. In fact, the set of things I need to be able to do in my user talk page is exactly the same as the set of things I need to be able on article talk. Anything that restricts me in doing all these things is simply unacceptable. Fut.Perf. ☼ 10:32, 20 July 2013 (UTC)

FP is correct here for the reasons they gave.--in addition, we need full editing capacities in WP talk space also: articles for creation are currently submitted in WP talk space. I don;t see it discussed, but we need these capacities in User space and WP space also, because editors sometimes submit articles there, (the user sandbox is in user space, I think, and though they shouldn't be using WP space for new submissions, some do.) I can't imagine that the tech people aren't clever enough to find a workflow that will handle all of these, though it might be complicated. All of these, especially the situations at the sandbox and WT for AfC, must be in place immediately that flow is enabled, as we get over 100 new articles a day by those routes. We've in the recent past had backlogs in the AfC process of >1 month,and there were complaints from hundreds of new editors about our slowness. This is not an optional feature. (I know it sounds absurd to have AfC in WT space as subpages of the AfC talk page, as I understand it, the reason is so the submissions can be NOINDEX--which is essential. If someone can figure out a better way of handling that, everyone involved at AfC will be very grateful), DGG ( talk ) 16:54, 20 July 2013 (UTC)

AfC is in WTalk space, because IPs and new-accounts can only create New pages in talk namespaces.

Relatedly, according to WT:AFC#Visual editor in AfC space, at least one new-account user was using VE whilst editing in their sandbox, and missed it when the article was moved to WT-space.

So any change to the AfC system needs to incorporate those 2 aspects. (But Flow isn't arriving in non-user-talk space for many many months, so the latter has more urgency). Hopefully someone who knows the details well, will start a request at VPT asking for technical options/assistance.

Regarding Fut.Perf's comments, which echo/summarize many threads above and elsewhere, I do agree, and will post additional notes tomorrow. –Quiddity (talk) 00:47, 21 July 2013 (UTC)

DGG, you made exactly the mental slip that Tychay was talking about: "it's important not to dwell too much on "how is Flow going to support foo feature in wikitext" and ask ourselves, "What was trying to be done when someone engages in bar action"." You don't need IPs to write articles in the WT namespace; instead, you need a way for IPs to be able to write articles and submit them to AFC. If that goal can be accomplished without IPs technically creating WT pages, then that's great.

I know this is not how we're used to thinking. We're used to copying whatever was done before, from wikicode to templates to whole processes. But for designing software, we need to think specifically about the goals, not just about whatever system we've been using, especially if that system is a kludge that exists solely to get around old limitations like who is and isn't allowed to create pages. WhatamIdoing (talk) 03:33, 26 July 2013 (UTC)

@Fut.Perf.: I've tried to summarize this issue, over at the end of the Wikipedia talk:Flow#Supported Wikitext thread, with a handful of clear examples. –Quiddity (talk) 17:25, 28 July 2013 (UTC)

Great work

• Great work MediaWiki/Wikipedia team on the new editor. This will allow Wikipedia to remain relevant in the current 'state of the web' where editing experiences like this are expected. I was very impressed to see the implementation of the Reference editor and 'Transclusion' editor. Features like those would have been easy to set aside for a Version 2.0, but a more comprehensive release really may start a positive trend. No doubt technical issues like browser compatibility or differences of opinion on exact layout will arise and be resolved as part of the development as they have always been. Please keep up the great work!Cander0000 (talk) 08:52, 11 July 2013 (UTC)
• Given the scope of the problem (and just how horribly messed-up wikitext really is), it is actually very good, and easier for quick copyedits on complicated articles. And I know how damn hard everyone involved is working on it - David Gerard (talk) 16:32, 11 July 2013 (UTC)

• Despite the fact that I'm not entirely happy with the way this has been deployed (frankly, it went far too early, before it was ready), I think we also need to acknowledge that putting together a Visual Editor is both the single most important technical thing that can be done to attract and retain new editors, and also one of the most difficult software engineering challenges possible. Building something as functional as what we have on top of the years of adhoccery and legacy code that makes up Mediawiki and the English Wikipedia is an extremely impressive feat. Lankiveil ^{(speak to me)} 11:44, 16 July 2013 (UTC).
  • +1 --¿3family6 _contribs 13:44, 16 July 2013 (UTC)
  • I completely agree. I'm glad this new editor has been rolled out. Chogg (talk) 20:08, 16 July 2013 (UTC)
• I agree. It's a very good alpha, but it should never have been launched outside of a test deployment. Adam Cuerden ^(talk) 12:04, 16 July 2013 (UTC)

  I don't think it's up to alpha yet, as some of the critical enhancements have been marked WONTFIX. — Arthur Rubin (talk) 19:25, 4 August 2013 (UTC)

• This is something Wikipedia has needed for a long time, and I'm happy it's already available on every article. I'm amazed at how complete it is. — Omegatron (talk) 03:08, 3 August 2013 (UTC)

Comment about this RfC

This RfC was designed with many weasel words, false choices, and questionable assumptions. This needs to be redone in a proper way to claim any sort of true consensus. -- Ypnypn (talk) 19:16, 11 July 2013 (UTC)

• Disagree I don't believe it comes across that way. I suppose it could be re-written to have a better effect, but there is no harm in it now. But unlike the Visual Editor, this RFC can be improved as we go along just like any article or essay. If you have better wording, mention them. I believe this RFC was brought forward in good faith.--Paul McDonald (talk) 19:31, 11 July 2013 (UTC)
• So add a section more to your liking - David Gerard (talk) 19:51, 11 July 2013 (UTC)

So I have. -- Ypnypn (talk) 20:56, 11 July 2013 (UTC)

• I think Ypnypn has a point, it looks seriously biased to me, (not necessarily in bad faith though) but I think it is in any case a storm in a teacup, so to mix my metaphors, I will not fan the flames. • • • Peter (Southwood) ^(talk): 20:14, 11 July 2013 (UTC)
• Must say I didn't like the language used, which has detracted from its intended purpose.--Salix (talk): 21:57, 11 July 2013 (UTC)
• Agree but also support this RfC. VE is not a bad idea, but it is not a sufficiently good implementation of that idea. The RfC is another poor implementation of a good idea (re-evaluating the implementation of VE). --R.S. Peale (talk) 05:24, 12 July 2013 (UTC)
• I have not commented in the RFC although I have already added several comments in the main discussion. As one of the MANY editors who are currently unable to use VE because our browsers (Opera in my case) are unsupported I do not feel I am in a position to do so. I can see the point in VE for new editors if it is done properly, but at the moment it clearly has not been. That all versions of IE are currently unsupported really means it is not fit for release in its current state, are they really serious about it..? Dsergeant (talk) 06:19, 12 July 2013 (UTC)

  Browser support is somewhat irrelevant in relation to breakage simply because "unsupported" means "blacklisted". An IE user is not given the VE, just as you're not given the VE; pushing a version out makes absolutely no impact on them, positive or negative. Okeyes (WMF) (talk) 14:36, 12 July 2013 (UTC)

  "Many" is less than 20%, and that will be less than 10% soon, when IE 9, 10, and 11 are working properly. WhatamIdoing (talk) 00:10, 13 July 2013 (UTC)

  80% of visitors to wikimedia sites use a browser other than IE, I think that editors are somewhere around 90% using something other than IE. [10] also, many other features online do not initially support IE, and some never do, possibly due to the difference in programming and function. -- Aunva6^{talk - contribs} 21:11, 13 July 2013 (UTC)

  I use IE primarily because of AWB. — Arthur Rubin (talk) 22:46, 13 July 2013 (UTC)

  When I do training, we often rely on the participants bringing their own equipment. I'm a big fan of Firefox, but "you'll have to install Firefox in order to participate in this workshop" is unprofessional, and "you'll have to upgrade to a newer version of IE" is even worse because it will likely cause all sorts of unexpected changes to their computer. In many cases, their laptop is their work machine, and is locked down so they cant f&^k it up. VE should work on most normal configurations, and IE users are slow upgraders. 20% is a very high risk factor. And I can assure you that even when it is 10%, it will cause problems often, especially with outreach to GLAMs and government and even universities in first world countries, and will be very frequently a problem in developing countries that cant afford to regularly upgrade. John Vandenberg ^(chat) 08:40, 18 July 2013 (UTC)

• The opening statement is terrible, and Philippe is absolutely right. The rest of the RFC is OK because we can at least oppose the statements we disagree with, but the opening statement really needs to be made more neutral and level-headed. — This, that and the other (talk) 07:10, 12 July 2013 (UTC)
• I don't think this RFC really needs to come to any kind of definitive consensus. The feedback here is not conducive to coming to some sort of "grand conclusion", or closure. It's clear that the general consensus of the community is that the rollout could have been handled a little better, but that's done and over with, so kind of moot. As I like to say, RFC is not a code word for polling, and the RFC still has value in the individual comments, even if there can be no "result". Gigs (talk) 14:27, 12 July 2013 (UTC)
  • I think that is only one of the points. There are editors in favor of rolling back the project, making VE not be the "default" editor at this time, and pulling VE completely from Wikipedia. It's more than just "the rollout could have been handled a little better" as you say, it's a whole lot more. "Sweep it under the rug" is not an option.--Paul McDonald (talk) 18:07, 12 July 2013 (UTC)
• But it's still better planned/designed than the Visual Editor rollout was. Hullaballoo Wolfowitz (talk) 13:40, 14 July 2013 (UTC)
  • +1 - David Gerard (talk) 14:15, 14 July 2013 (UTC)
  • +2 - Double sharp (talk) 11:57, 15 July 2013 (UTC)
• Agree: The RFC summary was not at all neutral, and Adam certainly seems to have tried to steer the discussion in a particular direction.--¿3family6 _contribs 13:43, 16 July 2013 (UTC)
  • I changed it, not that it matters much at this point. Gigs (talk) 17:03, 16 July 2013 (UTC)
• Indeed it may come across as biased. But how many would have voted differently if it had been more neutral? How many seem to have been influenced by the tone of the initial statements (i.e. they had no reasons of their own)? I'm guessing very few. Double sharp (talk) 11:37, 19 July 2013 (UTC)

Exactly. The questions just format and divide up the discussion. He hardly had to steer. Everyone here knows what we are talking about by experience, without relying on them to tell us what's going on. I can think no way of asking the question that would give a significantly different response. The great majority except those connected with the WMF dislike it and think it unready, the only variation being the degree of dislike; everyone from the WMF thinks it's useful, though some also think it wasn't ready. For example, I'm more willing to tolerate editing systems I don't like than Adam is, perhaps because I've managed to work with most of what's come out in the last 40 years or so (even earlier--I think I remember having to work with text in FortranIV). If I had to edit everything twice to make sure it worked, I would edit it twice, but that doesn't mean I want to. DGG ( talk ) 03:12, 20 July 2013 (UTC)

RfCs have become the way the enWP decides things. What I think we need to think about is how long to give the developers until we have one on the simple question of having it permanently removed until we say otherwise. My goodwill was exhausted at the previous interface change: I was assured the foundation had learned something, and I see that is not the case. And to supplement it, I see below they're intent on a similar change without approval. It's like a returning sockpuppet, who posts that after we throw him out he's going to come back again. DGG ( talk ) 03:19, 20 July 2013 (UTC)

• Agree. Adam Cuerden's original summary is not the only problem. With bullet points like "it's a good idea in theory" and "Buggy software should not become the default until it reaches a certain level of development", Adam is basically asking us all whether we've stopped beating our wives. Points like "VisualEditor should have a way to be turned off fully, easily, and without continuing to leech resources" are based on presumptions (that VE imposes a burden even when turned off) that are simply not backed up by the facts. Where do those of us who think that the VE is at an acceptable level of quality, and should be deployed to all editors, put their opinions in this mess? Dcoetzee 02:27, 2 August 2013 (UTC)
  • Agree I'm only posting beneath Dcoetzee because they said it better than I ever could. The whole thing seems designed as a politicking power-play by a vocal minority of long term users. --Monk of the highest order^(t) 04:28, 12 August 2013 (UTC)
• Disagree. The RFC looks properly presented to me. Gryllida 09:17, 6 August 2013 (UTC)

Visual Editor and Flow

It's official - [11] - you won't be able to use talk pages without it. This appears to put the lie to claims it will remain optional - David Gerard (talk) 22:26, 14 July 2013 (UTC)

Someone at the WMF needs to seriously take on board all the complaints they're getting and stop everything related with VE until they can fix the most egregious bugs it has. As it is, the way this is going on is a joke, and I won't be surprised if we see a few people getting fired over this fiasco. —Jeremy v^_^v ^Bori! 23:59, 14 July 2013 (UTC)

Agreed.--Paul McDonald (talk) 00:14, 15 July 2013 (UTC)

That thread does not say that VE will be the only way to use talk pages. In fact, if you read mw:Thread:Talk:Flow Portal/Interactive Prototype/Markup-mode *needed* in editor/reply (12), it specifically says that there will be a fallback, i.e., for users who cannot use VE due to not supporting Javascript. WhatamIdoing (talk) 01:19, 15 July 2013 (UTC)

Does not help. If equations are not rendered properly we'll be left with talking weather. --93.75.134.116 (talk) 01:32, 15 July 2013 (UTC)

Why wouldn't you be able to render equations properly? We are going to support math. See mw:Thread:Talk:Flow Portal/Maths/reply (2) for the latest word on math equations in VisualEditor. WhatamIdoing (talk) 04:47, 15 July 2013 (UTC)

Looks like there is some basic support for maths coming. [12], demo at [13].--Salix (talk): 04:53, 15 July 2013 (UTC)

Appears to me, that VE will be the least of our problems, when WP:Flow is ultimately implemented upon us all.--R.S. Peale (talk) 07:19, 15 July 2013 (UTC)

I was concerned about VE, but unaware of Flow. I'll be needing to recalibrate the paranoia filters, now.--R.S. Peale (talk) 07:19, 15 July 2013 (UTC)

Yech. I don't have the time right now to rebut every single point listed on its main page in its favour (which I could do though). If the WMF persists in not listening, I may just create User:Double sharp/talk to get away from this madness. (And learn how to hack the OBOD script for that – don't get me started on that.) Assuming I won't have to use VE on that, too. Double sharp (talk) 11:16, 15 July 2013 (UTC)

That's a genius idea, Double Sharp, assuming that is not made impossible as well. Toa Nidhiki05 18:59, 15 July 2013 (UTC)

I have a feeling this sort of thing might have been used for a time in WP's early days... Double sharp (talk) 10:57, 28 July 2013 (UTC)

Flow is replacing talk pages, and the only editor for talk pages will be Flow, so anyone saying that talk pages won't become VE-only is either ignorant or lying. Jorm (WMF) can't be arsed to find out if VE will support wiki mark up, but will force it on editors who will never have use for Visual editor.

If the people behind Flow aren't going to be the least bit helpful to the people who are actually helping the encyclopedia (instead of just trying to make things easier for vandals and POV pushers), then the VE folks need to grow a pair (of ears), actually listen to the complaints instead of advertising other features as red herrings, and implement an "edit source" button in VE to let users who aren't senile or delinquent demi-literates actually get something done around here. Ian.thomson (talk) 19:52, 15 July 2013 (UTC)

I pointed out at WP:VisualEditor that Flow will force all editors to use VE on talk pages, and I was reverted and accused of making bad-faith false edits. WMF has no idea what they're doing, and we need to make it known to them. Ian.thomson (talk) 21:25, 15 July 2013 (UTC)

You've already made it clear you hold that opinion, Ian. I'm happy to engage with you more if you cease assuming bad faith of fellow contributors and staffers. Okeyes (WMF) (talk) 03:15, 16 July 2013 (UTC)

As a developer and admin (off-wiki) I've learned that assuming good faith in users and devs is nearly always warranted, and far more efficacious than assumption of bad. However, I most emphatically decline to extend AGF toward code or parsers, until/unless it has proven itself non-faulty. VE hasn't done this for me, yet, and I'm skeptical that it ever will. WMF on the other hand, is not a script or a bot, but made of people. And I'm sure you're trying harder than I to build an encyclopedia. Even if I sometimes can't see it.--R.S. Peale (talk) 07:47, 17 July 2013 (UTC)

I resent the assertion that we're made of people - we employ lawyers! I mean, they are made of people, but only in the same way that a hamburger is made of cows.

So, yeah, I appreciate the VE proper still needs a heck of a lot of work. It's not got the full featureset, and it's got a lot of bugs - but those are issues that can and will be fixed in time, hopefully (I can't say "certainly", because I don't make that decision, but "almost certainly") before any kind of Flow rollout. At the same time, as has been said by Erik and a few others (and he does make that decision) there will be an editor as part of flow that is an alternative to the VE. I don't personally know what that looks like yet, but I'm in the office from Thursday and hope to chase it up in meatspace, where people can't run away ;). Okeyes (WMF) (talk) 08:42, 17 July 2013 (UTC)

That is good news! Please make sure to also chase up that we actually need two things: A fall-back for VE for people without JavaScript for whatever reasons (Brandon stated that this will be available) but we also need a real Wikitext alternative to VE, or at least a Wikitext editor inside Flow (and Brandon didn't make any commitments regarding this one). Not that we end up with a very limited fall-back solution that stands far beyond the full featured Flow implementation of VE but "supports Wikitext". --Patrick87 (talk) 09:17, 17 July 2013 (UTC)

• Pointing to the new FAQ question about this. There is, still, no plan to remove wiki text editing. Obviously, like all new tools, not all features will be available if you don't adopt it but we still plan to have it as a fall back (as certainly users will likely need it for years to come). Jalexander--WMF 03:32, 16 July 2013 (UTC)

"Eventually, we'll probably get more aggressive about asking people to upgrade, and finally (at some nebulous time in the future), we'll auto-upgrade everyone." ...LOL. "Unduly aggressive", indeed! Double sharp (talk) 11:26, 16 July 2013 (UTC)

Interesting that nobody has replied to this...interesting... Double sharp (talk) 10:40, 27 July 2013 (UTC)

Check out these comments, which you might find reassuring. See also the FAQ link that Jalexander added, directly before your comment. HTH. –Quiddity (talk) 17:17, 28 July 2013 (UTC)

And [14] (a couple of edits further) does show that Flow is meant to become incompatible with "normal" editing. So do [15], [16]... Sorry, but trying to deflect well-deserved criticism from WMF like [17] does not look well. I would recommend you to self-revert. --Martynas Patasius (talk) 18:09, 28 July 2013 (UTC)

The visualeditor will not be mandatory for flow. It can't be, because some editors don't have javascript, and VE requires javascript. See WP:VisualEditor/FAQ#VEFlow. I completely agree that feedback (criticism/suggestions/bugreports/requests/etc) for VE and Flow is good/needed, but the wording in the header was factually incorrect and misleading, hence the change. –Quiddity (talk) 19:30, 28 July 2013 (UTC)

The point is that the "wikitext editor" will only be allowed to do what the "VisualEditor" does. And that will only be a subset of things that the "wikitext editor" can do now. In effect it means that we lose the "old" editor and get a "VisualEditor" with the graphical interface and a "VisualEditor" with the text interface. That is not a current "wikitext editor", although it might look like that from afar. It loses the main advantage of the normal "wikitext editor": flexibility.

Now it doesn't have to be this way, if WMF and the developers will act reasonably. It is relatively easy to show some box (or something) with words "This part is not supported by this interface. You can edit its source directly." (or something like that). Or at least ignore the unsupported part. Good editors do that. However, we are told that if something is supported by "wikitext editor" and unsupported by "VisualEditor", it will be simply rejected by the server... That's what we are furious about.

So, I still think that your change is wrong. --Martynas Patasius (talk) 20:01, 28 July 2013 (UTC)

There are some technical details at the top of Wikipedia_talk:Flow#Supported_Wikitext, and I've added an attemped summary of the issue from an editor's perspective (without the technical-aspects, and with examples of what we need) at the bottom of that thread. There are also some helpful discussions around this topic in the thread directly above that. (Note: I'm a wikitext lover, too. I've handcoded webpages in notepad/homesite/notepad++/gedit since '97! I want what you want - power and flexibility without changing my typing habits too much. I'm just trying to help the conversation remain a conversation, rather than letting it turn into an argument over the as-yet-uncreated fallback editor and its hypothetical features, which will supposedly all be based around Parsoid (and will include whatever features Parsoid has available in x months time). HTH.) –Quiddity (talk) 21:09, 28 July 2013 (UTC)

I guess it means we do not really disagree that much. You are saying that there are some things that must be achieved and we have to tell WMF what they are - I am saying that if we will do nothing, those things will not be achieved.

In effect the difference is that by now I do not trust WMF that much: after all, it wasn't hard to make "VisualEditor" just slightly annoying without provoking "everyone" to hate it with great passion. And "Flow" (or "Parsoid") is a much harder project. So I suspect that "Flow" is not actually going to be implemented reasonably. However, it might be that the project won't get finished - and that might be the best we can hope for... Thus I would prefer to make WMF adopt the slogan "There is no deadline!" and just waste money without causing much harm... --Martynas Patasius (talk) 22:50, 28 July 2013 (UTC)

VE is annoying and disgusting

• I am feeling both annoyed and disgusted from the unwill and the unability of the foundation and their programmers to finally improve referencing content. With atm rank 17 on DE:WP's alltime editcount I am considering myself of one of the most active editors in that language's WP but never from the first day of my activity there (2006-07-12) was made any significant improvement on referencing articles. Actually referencing in MS Word 5.0 in 1989 was more easy than in WP 2013. You get it? It' just thouroghly failure. --Matthiasb (talk) 20:59, 19 July 2013 (UTC)
  • I am nevertheless certain that a strictly time-based release of VE to German Wikipedia will be an unmitigated success - David Gerard (talk) 21:16, 19 July 2013 (UTC)
    • Everyone can believe what he wants. Please be asured: there is no Easter bunny. I cannot help myself: for a couple of years or three the foundation does the maximum for making Wikipedia unattractive for new users and is doing nothing repeat nothing to motivate old users contributing also in future. Well, frankly spoken, the only improvement introduced to Mediawiki was the useless Wikilove feature a.k.a. give away a cat picture. Sorry but I really do not believe that Wikipedia will surve 2020 if WMF is ruled like at this moment for some more time. As a long time user and as a man who has learned trading from the scratch I am sure, that the WMF is on a dangerous trip to nowhere. Unless they won't start to listen what editors are really needing WP is on a downwards loop. WMF lost way too much time with features not needed and even not helping at all. Throw away the VE as it is, nobody needs this. And finally listen to the communities. Well even if You never asked so far. --Matthiasb (talk) 21:49, 20 July 2013 (UTC)
      • (Pretty sure David was being sarcastic, Matthias.) Adam Cuerden ^(talk) 21:56, 20 July 2013 (UTC)

What really surprises me is the stubbornness the WMF is showing here in introducing the visual editor. Increasingly I find myself thinking that Wikipedia is being made harder and even impossible to edit step by step introducing an AFT nobody has ever needed or requested, an unusable Wikidata which has failed by design from the very start, now by doing away with the MediaWiki editor (after all, that's the tool that we use to bring in all content), and finally by replacing discussion pages with "Flow". The WMF, it appears, is not the least interested in the needs of its most faithful contributors, taking away the tools we need for our work, cf. the dying-away of the Toolserver, or the doing-away of the tick box to switch off visual editor for some hours on enwiki some weeks ago. I gather that it will not be possible to switch off "Flow". So, if we cannot even continue to discuss the way we used to what will be left for us to stay here? Even assuming lots of good faith, despite the WMF's best intentions, we will probably lose our core community pretty soon, and WMF does not seem to be interested in us any more. Been there, seen that. Paid editors are about to take over, I assume, while Wikimedia organisations are looking for a new community who likes these Facebook and Google kind of gadgets that are taking a lot of time and money to develop. Reminds me very much of Bertolt Brecht's poem Die Lösung ("The solution") on the relationship between the East-German state and its people after the resurrection of 1953: Wäre es da/ Nicht doch einfacher, die Regierung/ Löste das Volk auf und/ Wählte ein anderes? ("Would it not be easier/ In that case for the government/ To dissolve the people/ And elect another?").--Aschmidt (talk) 20:53, 23 July 2013 (UTC)

• Even Microsoft have shown more interest in their clients than the WMF have... Lukeno94 (tell Luke off here) 21:05, 23 July 2013 (UTC)
• Now WikiFahrenheit-451 as they burn our old tools: I can expect how many users will want to quit, but the trampling of our community should strengthen our resolve, as in Fahrenheit 451, we should form our own plans to improve tools, plus find sympathizers within WMF Platform Engineering who will help us to preserve the contents of the books before everything is burned in the Firestorm. -Wikid77 (talk) 16:03, 24 July 2013 (UTC)

• I find these comments annoying and disgusting. This is a serious forum, not a lavatory for wild, emotive venting. Tony (talk) 02:28, 26 July 2013 (UTC)

Seconded.OrangesRyellow (talk) 10:33, 26 July 2013 (UTC)

Yet the fact that such venting does take place and that people have felt the need to create a dedicated section of it shows pretty clearly the most common reaction... Double sharp (talk) 15:18, 31 July 2013 (UTC)

"Centralized discussion"?

Since at the moment this page seems to be the main for discussion of "VisualEditor", perhaps it should be mentioned in Template:Centralized discussion? A couple of "less main" discussions have been mentioned ([18])... --Martynas Patasius (talk) 18:29, 28 July 2013 (UTC)

The Germans state their stand

FWIW. Double sharp (talk) 00:53, 29 July 2013 (UTC)

Russian

ru:Википедия:Визуальный_редактор/Отзывы is the feedback at Russian Wikipedia; it is currently a list of bugs with notes that the launch was too early. Gryllida (chat) 06:38, 18 August 2013 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Fixed?

The problem should be fixed. Can everyone test? Okeyes (WMF) (talk) 14:45, 14 July 2013 (UTC)

Yep, seems to be fixed. All the other gadgets (Twinkle, clock, etc.) also appear to be back. Reatlas (talk) 15:05, 14 July 2013 (UTC)

Phew :). Much credit to the devs, for fixing this so quickly (and on a Sunday to boot). Okeyes (WMF) (talk) 15:06, 14 July 2013 (UTC)

Cookies all around. Reatlas (talk) 15:16, 14 July 2013 (UTC)

Proposal related to VE

Please see Wikipedia:Village pump (proposals)#Visual Editor clashes with instructions on help pages and the like.--Fuhghettaboutit (talk) 22:24, 14 July 2013 (UTC)

We have an issue

The tool that shuts off the VE is not working. We need a more reliable method to keep VE off for those who do not want it. Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:10, 14 July 2013 (UTC)

When one does a copy and paste one now gets two exact copies rather than one? Not sure if this is related to VE. Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:17, 14 July 2013 (UTC)

In the markup editor or the VE? I'm seeing the shutoff bug too; what browser are you on? Okeyes (WMF) (talk) 12:25, 14 July 2013 (UTC)

So, it looks like parsoid is DoSing the API cluster, which has implications for gadgets functioning. Mark Bergsma is looking into it now. Okeyes (WMF) (talk) 12:32, 14 July 2013 (UTC)

In the markup editor. When I copy and paste content, one paste gives me two copies of what I copied. It sucks. The WMF needs to concentrate on getting the basic editor to work more consistently. Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:42, 15 July 2013 (UTC)

Can you point to what else we're focusing on? What browser and OS are you using? Okeyes (WMF) (talk) 12:48, 15 July 2013 (UTC)

Using google chrome and a windows machine. Doc James (talk · contribs · email) (if I write on your page reply on mine) 08:02, 16 July 2013 (UTC)

Yep, I was just coming by to report that myself. I've got the box ticked on my Preferences, yet the Visual Editor links are still there. It's kinda pissing me off, because I click 'edit' out of habit and I can't really make any use of the VE. So please, let's make it go away for those of us who want it away, yes? Green-eyed girl (Talk · Contribs) 12:33, 14 July 2013 (UTC)

Yes; as said, it's not directly a problem with the VE, it's a problem with gadgets generally. Okeyes (WMF) (talk) 12:34, 14 July 2013 (UTC)

I'm experiencing this too. I am a heavy user of HotCat, Twinkle, and Provelt, and I can't use them all.--AR E N Z O Y 1 6A•t a l k• 12:40, 14 July 2013 (UTC)

• Looks like it's not a Parsoid problem, actually - some [expletive deleted] decided to DoS the API cluster externally. Okeyes (WMF) (talk) 13:03, 14 July 2013 (UTC)

• I can't even see the Gadgets tab full stop at the moment... Lukeno94 (tell Luke off here) 13:59, 14 July 2013 (UTC)

• Interesting. I've experienced this problem (disable not working) the day the VE was launched, but not since then. Someone not using his real name (talk) 14:11, 14 July 2013 (UTC)

There is actually a proper off switch for VE. It was chosen to disable the off switch for en:wp, and instead have a half-hidden option that the VE breaks every now and then. Enabling the off switch is apparently an "enhancement". The patch is awaiting deployment. Anyone from WMF have an idea if/when this change will go through? - David Gerard (talk) 14:14, 14 July 2013 (UTC)

Copy and paste

Copy and pasting content within an article using the markup editor has sucked for a long time (it often deletes spaces that should not be deleted). Lately it has begun to suck more than usual with two copies being created for a single paste. Not sure if this is related to VE. What about improving editing for those who edit most? I also wish that the auto fill button for PMIDs and ISBN worked faster and more consistently in the ref toolbar. These few changes would make me more productive. Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:57, 15 July 2013 (UTC)

"Not sure if this is related to VE" - you mean that this happens in the markup editor? And the ref toolbar is an enwiki-specific tool, not something the WMF built or supports. Okeyes (WMF) (talk) 13:08, 15 July 2013 (UTC)

Doc James does not use VisualEditor. My guess is the most likely problem is in the keyboard or its settings: a slightly sticky key will produce a duplicate paste, and a rapid key-repeat rate will do the same. (Both copies are back to back where you wanted them, right?)

This doesn't have anything to do with VisualEditor. It's ironic that we're getting complaints about this, given how many people keep telling us that VisualEditor should be turned off on the grounds that the old editing environment is bug-free. Whatamidoing (WMF) (talk) 17:30, 15 July 2013 (UTC)

No it is not a sticky key (I us a bunch of computers and I get no other duplication of key strokes or issues with other programs). And yes I am using the old editor. The old editor is far from bug free but faster and less buggy than the new one.

Yes I realize that the WMF does not maintain the ref toolbar. This is something that IMO paid programmer time should be put into. The WMF puts great efforts into attracting new editors (think education program) and great efforts making it easier for new people to edit but does not spend enough time making it easier for those who contribute extensively to edit more easily. Yes I realize that this is a little off topic :-) Doc James (talk · contribs · email) (if I write on your page reply on mine) 07:57, 16 July 2013 (UTC)

Okay just does it with Chrome and not Firefox. I will test further. Doc James (talk · contribs · email) (if I write on your page reply on mine) 08:19, 16 July 2013 (UTC)

Please let me know what you discover. It's not VE, obviously, but Bugzilla has a couple hundred open bugs on the old editor, and there's no reason why we can't add one more when you have the details together. Whatamidoing (WMF) (talk) 16:46, 16 July 2013 (UTC)

Thanks WAID. Seems to be working now on chrome. Will look at things further if it happens again. Doc James (talk · contribs · email) (if I write on your page reply on mine) 11:02, 17 July 2013 (UTC)

Visual Editor introducing links to disambiguation pages

See Wikipedia:Village pump (miscellaneous)#Disambiguation in crisis. benzband (talk) 23:28, 15 July 2013 (UTC)

IP problems

I can edit an entire article with Edit or Edit source. I can only edit a section using Edit. Both Edit and Edit source are displayed, but clucking on Edit source makes both disappear and nothing can be done. Please ask the NSA if this is a bug or an "undocumented feature". Thank you. 184.78.81.245 (talk) 19:36, 17 July 2013 (UTC)

How odd. What browser/OS? Okeyes (WMF) (talk) 19:38, 17 July 2013 (UTC)

Safari, on an iPad. You have any idea how many people use them these days? A lot. 184.78.81.245 (talk) 19:51, 17 July 2013 (UTC)

12,173 million requests from tablets, versus 170,807 million for desktop. I agree it's a problem - I don't think I disputed that - and this issue is a known, and being fixed. But right now we're prioritising the areas where we can get the biggest bang for our bugfix. Okeyes (WMF) (talk) 20:21, 17 July 2013 (UTC)

Doesn't appear to be the tablet that's the problem, as it works when I use Chrome for iPad. Did you alpha test with Safari? 184.78.81.245 (talk) 21:16, 17 July 2013 (UTC)

Yes, but not really the tablet version, which is distinct. As said, this is a known problem, and we're resolving it by hopefully moving away from having the links pop up - see bugzilla:50540. Okeyes (WMF) (talk) 21:20, 17 July 2013 (UTC)

This just shouldn't happen

Onto my watchlist today pops this edit:[19].

I notice it says "nowiki added" in the summary, and I've seen that VE does this from time to time, so I think - ok, I'll check it out, maybe it needs a quick fix.

Turns out it's utterly mangled a section with formatting and code - so, great, I think, what to do now? Seems I have 3 options:

• Ignore it. - not acceptable to me, I can't do that having seen it.
• Revert it. - well, no good either, because then I'm reverting whatever the last guy was trying to do. To further complicate it I left a talk page note for this particular user yesterday about some of his other edits, so if I revert it looks like I'm picking on him or policing him.
• Figure it all out and fix it - so this is what I try to do, by checking the entire huge article for the changes the other guy made, then restoring the mangled section from an old revision. Took about 10 minutes - no big deal in some ways, but still 10 minutes I could have spent doing something else.

So here's the thing, as I see it, when the editor is making changes to code that wasn't even being edited, that's even worse than vandalism, because the edit is made with good intent, and the software is the "sneaky vandal". At least it flagged the summary, which is something, I guess.

Over the top to describe it this way? You may feel that, but I'm describing how this affected my workflow and my editing experience - and I think that's what it's all supposed to be about, isn't it? Begoon ^talk 01:34, 18 July 2013 (UTC)

Timeline for beta

Hi! How long is the beta expected to run for IP users? VE seems to be introducing a lot of errors with IPs, so I'm assuming that the plan is to run the beta for a while to collect feedback, then do bug fixes, so I'm curious as to how long we need to be checking VE changes. - Bilby (talk) 01:28, 16 July 2013 (UTC)

Just to clarify the "lot of errors" statement above, I ran through 100 IP edits made with VE through recent changes. 12% of the edits contained errors that were attributable to VE - 7 were the nowiki tag problem. I can understand running this for a bit to get data, but if the number of problems by IPs is to be increased by about 10% through using VE, then the workload for recent changes volunteers is going to be a problem in the medium term. - Bilby (talk) 02:00, 16 July 2013 (UTC)

The WMF intends this to be permanent. Dragons flight (talk) 02:04, 16 July 2013 (UTC)

To be a little more precise about it - we are fixing bugs as quickly as possible (we've fixed more than 150 so far) - so while it's permanent, it's not permanent in THIS state, exactly. Philippe Beaudette, Wikimedia Foundation (talk) 02:08, 16 July 2013 (UTC)

In that case, why is it called a beta? This is a rollout, not a beta. But I'm more concerned, then, about the 10% error rate. That isn't sustainable. - Bilby (talk) 02:10, 16 July 2013 (UTC)

I'm not aware of any rule that there software must be taken away from users in between the beta and version 1.0 stages. Are you? It seems common enough for people to directly upgrade from the beta to 1.0. Whatamidoing (WMF) (talk) 17:23, 16 July 2013 (UTC)

As a general rule, if you provide a new software package, to all users, as the default, on a permanent basis, then isn't that a release? It isn't a big deal, but betas are for testing in preparation for a release (or at least a release candidate). :) - Bilby (talk) 20:10, 16 July 2013 (UTC)

Can't we just shut it down, fix the massive errors, and relaunch it in a month after some more testing? 10% is ridiculous. This software is clearly not ready for prime time. Adam Cuerden ^(talk) 04:26, 16 July 2013 (UTC)

100 edits is not a sample size that allows for statistical significance. What were the errors? Okeyes (WMF) (talk) 13:30, 16 July 2013 (UTC)

Probably true. I'm working through a sample of 500 edits at the moment, representing approximately 4 hours of IP edits. I'll get back to you on error type and numbers. - Bilby (talk) 16:51, 16 July 2013 (UTC)

Thanks. Whatamidoing (WMF) (talk) 17:23, 16 July 2013 (UTC)

Ok. I checked 500 edits by IPs using VE. I checked each edit individually for formatting errors, then classified the error type, whether it was subsequently fixed, reverted, or missed, (if missed, I fixed it), who fixed it if such occurred, and the degree to which VE was responsible. In regard to that last point, errors can be the result of bugs in VE, completely unrelated to VE (in which case they weren't counted), or because of formatting problems which are caused by user error, connected to the design of VE when it is working as intended.

Of the 500 edits, 47 had formatting errors which I connected to VE. 29 errors (just under 6%) were tagged as clearly due to bugs in VE. Another 6 errors were possibly due to VE bugs, but it was unclear. The remaining 12 were due to user error, but occur under VE because it makes certain errors easier to make (such as accidentally deleting an infobox).

The majority of the errors were the addition of nowiki tags. These were connected to:

• Leading space bug (1)
• Adding a wikilink with or without additional text (12)
• Adding an image within an external link. (1)
• Removing content of section and deleting the section title (leaves a nowiki tag between heading code) (3)
• Adding an AfD notice (1)
• Adding a new reference (2)
• Just inserting text (8) - might be due to copy-and-paste additions.

There was also one case where the close tag of a table was placed in nowiki tags. No idea why.

Other problems:

• Deleting templates. Not really VE's fault, but there's now a single key press deletion of infoboxes and other templates, which makes it easy to accidently remove.
• In one case, a wikilink was created with open but not close brackets. Could be a copy-and-paste.
• Paragraphs were in a couple of cases turned into headings. That's presumably an accident caused by pressing backspace on the first paragraph after a heading.
• For some reason the first part of a table was added to an existing table. See [20]
• Text was added as templates, such as a url. Presumably user error.
• A date format notice was deleted. Not sure how that occurred, but based on the other edits it looked accidental.

On the positive side, I was really happy to see people adding references. I didn't notice any that were properly formatted, (some may have been, but I wasn't specifically looking), but bare URLs are ok. Although there was some confusion in one case, where the editor set the group name for the ref, seemingly thinking it was the same as the ref name="" tag.

In regard to detection, 35 errors were fixed or reverted, and 12 were missed. 9 were fixed by the IP.

Hopefully that's of some use to you. Mostly it seems the nowiki bug is an issue, so if that is fixed soon this will improve enormously, but I think we'll find some needed changes to the workflow in VE. - Bilby (talk) 20:10, 16 July 2013 (UTC)

Agreed; I'm hoping for progress on that one :). The open-but-not close is interesting - got an example? Okeyes (WMF) (talk) 20:17, 16 July 2013 (UTC)

Sorry, I didn't keep the diff, but that one looked so much like a copy-and-paste that I wouldn't see it as an unusual bug. I've kept diffs for the next two days of data. It is a bit odd, but I really enjoy data collection when doing research, and it seems that this might be of some help. I've also moved to Google Docs, so if there is a wish for this I can share the raw data. - Bilby (talk) 00:13, 19 July 2013 (UTC)