Wikipedia:VisualEditor/RFC

RFC: VisualEditor launch issues

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 [1], 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 [2] bug seems to have been fixed now [3]. 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)

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)

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)

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)

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)

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)
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)

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)

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. —mountainhead / ? 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)

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)
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)

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 [4]) 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)

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)

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)

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)

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)

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)

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. ·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)

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.

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)

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 - [5]) 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 ([6]) 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)

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."[7]. and "Obviously there will be a fallback version."[8]. –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)

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. [9] 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)

Visual Editor and Flow

It's official - [10] - 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. [11], demo at [12].--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 [13] (a couple of edits further) does show that Flow is meant to become incompatible with "normal" editing. So do [14], [15]... Sorry, but trying to deflect well-deserved criticism from WMF like [16] 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)

"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 ([17])... --Martynas Patasius (talk) 18:29, 28 July 2013 (UTC)

The Germans state their stand

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