Wikipedia talk:VisualEditor/Default State RFC

Watchlist notice?

Any reason why there isn't one? WP:CENT isn't enough. Risker (talk) 18:56, 30 July 2013 (UTC)

This is now moot given the (much more prominent) site notice. --MZMcBride (talk) 03:03, 1 August 2013 (UTC)

How do I answer this "until the current major bugs are fixed"?

I want to say that it should be opt-in for everyone, but only until the current set of major bugs are fixed. Then I want the developers to try again with opt-out. Should I add third options to the binary answers or what? EllenCT (talk) 19:03, 30 July 2013 (UTC)

I'd say that, if opt-in passes, we should follow this up with a poll as to what would be necessary before an opt-out. I, for one, would want support of basic wikitext and an end to the stupid on-hover-based selection of which tool to use for section editing, in addition to fixing major bugs, myself, largely because the VE team has made it clear they categorically refuse to fix those, despite them causing the <nowiki> bug and making section editing impossible on screen readers, respectively. Adam Cuerden ^(talk) 10:14, 31 July 2013 (UTC)

Are they refusing to fix table editing and cross-browser support? EllenCT (talk) 17:37, 31 July 2013 (UTC)

No, table editing is on the list, and apparently always has been on the list for this quarter. Some old browsers will never be supported. I believe this is largely because those browsers are either quite rare or because they are simply incapable of handling the necessary actions (or both). Whatamidoing (WMF) (talk) 22:56, 31 July 2013 (UTC)

What is the VisualEditor?

in my opinion, this Request for Comment illustrates why some users, myself included, find the Wikipedia a technically challenging place.

How can I comment on something when it isn't even explained what the Visual Editor is, or what it does? The wiki techies just assume that everyone has the same level of knowledge that they do. This simply isn't the case.

The very first bullet in this RFC should be an explanation of what the Visual Editor is. Mr Serjeant Buzfuz (talk) 14:51, 31 July 2013 (UTC)

Wikipedia:VisualEditor. It is the editing interface that you get right now when you click "edit" on an article. Mr Serjeant Buzfuz, it is possible that you edit using one of the blacklisted browsers (Internet Explorer is blacklisted, for example) so have not encountered this editing interface. Risker (talk) 15:55, 31 July 2013 (UTC)

I sorta know what VE is from a previous notification, and actually tried it a little, but it didn't work on templates. I am an Internet Explorer user, and thus blacklisted for who knows how long, which I also learned back when VE was supposedly (my pov) activated. So why am I getting this notification? Can't it be turned off for IE users? I just wasted 15 minutes or so trying to figure out if it was actually working for IE users yet. Please don't bother me till it's actually working for IE users, or at least include "IE users need not apply" or equivalent in a prominent place. Thanks. Cpfan776 (talk) 02:07, 1 August 2013 (UTC)

Focusing on improvements

While this RFC somewhat heads in this direction, I think we should recognize that VisualEditor is the future and instead spend time and energy focusing on possible real, actionable improvements to VisualEditor. --MZMcBride (talk) 17:14, 31 July 2013 (UTC)

Why not support the wikiproject proposal instead of making more new buried pages? There seems to be good support, so why not just start that page? Risker (talk) 17:22, 31 July 2013 (UTC)

A full response to these questions is available here. --MZMcBride (talk) 03:12, 1 August 2013 (UTC)

[Edit conflict]

VE is potentially the future, for some editors. However, it probably will never be suitable for low-bandwidth users on old computers, for example. Also,t he VE teasm's decisions have repeatedly crippled it, such their decision not to support Wikitext, instead causing buggy nowiki behaviour - the bug for that one has recently been marked "WONTFIX". Or the screenreader-breaking and generally poor functionality of the on-hover selection of which editor to use to edit sections.

VE is only the future should the VE team have some sense knocked into them.

If it's turned off, I'd say the next step is an RFC about VE itself. Something like:

Feature/bugfix

Description

Option 1: VE should not be turned on until after this is in place

Option 2: This must be included eventually, but is fine waiting until a while after relaunch

Option 3: Not important to me

Run that with enough options, and VE might become the ffuture after all. Adam Cuerden ^(talk) 17:30, 31 July 2013 (UTC)

Different responses between English and German wikipedias

I've noted several people pointing to the results of a poll on the German Wikipedia. Please note some very major differences between what we are doing on the page here, and what they did there. None of this multiple questions, they were straightforward and just voted on whether or not it should be opt-in. ONE question, publicised everywhere on their project. That is how they get over 400 people to voice an opinion. Risker (talk) 17:22, 31 July 2013 (UTC)

I hope this doesn't fail because I'm not good at organizing this kind of thing. Most people seem to be only answering question 1, anyway. Would I cause trouble by just adding a site notice that publicizes the RFC? Where would I go to get consensus to do so?—Kww(talk) 17:35, 31 July 2013 (UTC)

WP:AN, I think. Or, in theory, you could WP:BOLD edit MediaWiki:Sitenotice and MediaWiki:Sitenotice id; the only real rule seems to be it has to be something that affects all users. Adam Cuerden ^(talk) 17:37, 31 July 2013 (UTC)

KWW, I give you a lot of credit for starting this, especially after efforts by others were firmly rebuffed earlier in the process, and how much work and how much pressure from people even outside our usual editing community it took just to get the opt-out button on this project. There is some hope for change, based on Erik's recent post to Wikimedia-L mailing list. Risker (talk) 20:38, 31 July 2013 (UTC) Updated with link now that Quiddity has passed it to me

Where's Question 5?

I can't find question 5. Whether it is a typo or a dropped question can anyone please check in regards to its fate? --Marianian^(talk) 23:04, 31 July 2013 (UTC)

http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Default_State_RFC&diff=566435922&oldid=566434802 shows that for some reason, the numbering went from 1,2,3,4 to 1,2,2.5,3,4 to 1,2,2.5,3,4,6. No idea why.—Kww(talk) 23:17, 31 July 2013 (UTC)

I went ahead and renumbered it. Adam Cuerden ^(talk) 01:15, 1 August 2013 (UTC)

Special credit

While I specified in the top paragraph that this RFC was not a place to vent, I have to give special credit to Starblind:

This seems downright cruel given WP's supposed focus on editor retention/recruitment. Would anyone go to Disneyland if all they could ride was It's A Small World, which was broken and on fire?

[http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Default_State_RFC&diff=566641247&oldid=566641204

That said, stop that.—Kww(talk) 23:11, 31 July 2013 (UTC)

Way too many edit conflicts

Yeah. —$\mathrm {ITAC}$ $\mathrm {talk}$ 23:16, 31 July 2013 (UTC)

A modest question

So are any of the WMF staff testing with Visual Editor? If no, why not? After all the bad feelings the average contributor has for VE, I'd think doing that would be an important sign of support for it. And considering this project will serve as Sue Gardner's legacy at Wikipedia, I would hope she is making edits with it & using her experience to help make this the best piece of software possible. (Unless she wants to be known for being responsible for a buggy WYSIWYG editor that veteran editors refuse to use, & newbie editors find as difficult to use as editing Wikicode directly.) -- llywrch (talk) 01:09, 1 August 2013 (UTC)

I would certainly oppose adding that to this RFC. It's not a direct actionable question that we need to get a sense of the community's feeling on.—Kww(talk) 01:12, 1 August 2013 (UTC)

Sue's contributions are just as visible as anyone else's, so you can check if you'd like to know.

In general, staff isn't supposed to change content in their role as staff members, so you won't usually find many edits to articles in staff accounts. (For example, my article-edit count on the English Wikipedia is currently zero.) Whatamidoing (WMF) (talk) 17:25, 1 August 2013 (UTC)

Why just new users and anonymous editors?

NVM. They don't care. They spent time developing something and it's going to be pushed forward no matter what we say. --Onorem (talk) 01:15, 1 August 2013 (UTC)

Thank you for responding. --Onorem (talk) 02:24, 4 August 2013 (UTC)

Not sure what you were asking here? Everyone got VisualEditor, not just the groups you mentioned. Thanks. --Elitre (WMF) (talk) 07:00, 4 August 2013 (UTC) PS: if you were talking about questions at the RfC, there is at least one which demands plain switch-off.

The site notice, or watchlist thing, or whatever it was inviting new users and anonymous editors to this page. NVM. I really don't remember where I saw it, and I really don't care now. --Onorem (talk) 22:01, 4 August 2013 (UTC)

I bought twitter for dummies(like me), but I haven't yet had time to read it. I am looking forward to being more wiki fluent. — Preceding unsigned comment added by Susiedarling (talk • contribs) 01:40, 1 August 2013 (UTC)

Twitter for dummies. The name is perfect. Is there a facebook version? I think Wikipedia wants to review both because it sure seems like they're trying their hardest to make us more like both. --Onorem (talk) 13:34, 6 August 2013 (UTC)

Suggested changes

Firstly, I want to say that I and the other members of the VisualEditor team greatly appreciate the interest and time dedicated by members of the community. It's a delight to work on software that people really care about. As a longtime Wikipedian, I am deeply committed to getting this right.

With that in mind: we hear you. We're reading everything, and discussing daily. You are not being ignored. I read the comments here and throughout the wikis, as does Erik, as does Philippe and his team.

As background, I strongly suggest that you read Erik's post on the Wikimedia-l mailing list yesterday, which lays out our thinking and in particular on the need to maintain a steady and representative stream of users, not just for reporting bugs, but also to help us validate changes as we make iterations every few days. We cannot develop VisualEditor in isolation from real users.

That doesn't mean, though, that we need to continue running it in "firehose mode" as the primary editor. Therefore, I'd like to propose the following changes:

• We switch the tabs back around so that wikitext editor is more prominent as the "primary" way to edit.
• We also re-label the edit tab and section edit links to further emphasise that VisualEditor is not longer the primary. For instance, we could label them "Edit source" (or "Edit") and "VisualEditor" (or "VisualEditor ^beta") - I'm not sure what works best here.
• We remove the animation from the section edit links, showing both links all the time (with the VisualEditor link second, like the edit tabs, using the same language).
• We create a prominent notice that comes up when you load VisualEditor for the first time, explaining that the editor is a beta product, and that editors should be prepared for bugs.

Also note that it will, of course, continue to be possible to opt-out of VisualEditor using the existing preference, and users who have already done so will not see VisualEditor re-appear.

Do you think this would be an helpful way forward?

Yours,

Jdforrester (WMF) (talk) 01:42, 1 August 2013 (UTC)

Erik's message on the mailing list didn't address one important issue. You are months away from getting table editing implemented. You are months away from getting cut-and-paste to work. You are months away from acceptable performance. You have a list of several hundred bugs that have been found during this period of forced testing. Why do you need so much more feedback on this version? Why not focus on getting those elements corrected and then trying again when you have a product that there's a good chance that people will like?

You've seriously strained our good will. Most of us are still quite willing to give you a second chance, though. I don't think many of us would give you a third, though, so it's important to make good use of your opportunities.—Kww(talk) 01:53, 1 August 2013 (UTC)

@Kww:

Hey Kww,

That's a totally legitimate question. These are some of the main types of issues we're dealing with:

• Category A: straightforward bugs, e.g. "When I click this button in the dialog, it stops responding".
• Category B: performance issues, e.g. "It takes 25 seconds to save the page".
• Category C: user experience issues, e.g. "The reference dialog is not intuitive for me".
• Category D: missing functionality, e.g. "I can't insert or edit maths equations".

Our ability to address issues in each category is greatly enhanced by a significantly sized pool of users making real world edits using VisualEditor, and greatly decreased by seeing that set of users drop to a trickle, or a highly self-selective pool.

However, as I noted, you are correct that we don't require the firehose of usage that we're seeing today. That firehose has the benefit that it's truly unbiased -- IPs, new users, and long-time Wikipedians have all used VisualEditor in the last few weeks. But we understand that this is disruptive, and costing us goodwill. Sorry. :-( However, a compromise like the one we're suggesting above would help maintain a reasonable level of usage, while more fully informing users that they're participating in a beta test, and not changing the default experience for anyone.

Let me try to explain why each category of issue benefits from a large and diverse pool of users making real world edits.

Category A issues

Bugs of this type often depend on VisualEditor being in a certain state (e.g. a certain element on the page being selected), or only occur sporadically, or for users with certain configurations. We may be able to isolate and think we've fixed the bug under testing conditions, but it continues to occur in real-world conditions. Were we to go to 0 users and do all our testing internally, we'd do months of development and fix a lot of these issues, release again and have to re-open many of the bugs, because it turns out that users still encounter them under certain conditions. Users yell at us because the software still has bugs. That's fairly likely, and doesn't serve anyone well.

In order to catch issues and regressions while we're developing code, we use unit tests, automated browser tests, and automated parser round-tripping tests. We have a continuous integration pipeline that lets us know when a commit breaks a given test. All aspects of the testing pipeline can be improved, of course, but even with a solid testing pipeline, you'll run up against the limitations of automated testing. In particular, maintaining more than a basic set of cross-browser tests requires very large development effort in its own right, because browser automation tends to be brittle as the user interface changes.

Manual testing (literally paying people to follow test plans, perform exploratory testing, etc.) also only gets us so far. If you've done Web development, you will know, for example, that the number of browser variants to support is ever-increasing, with browser makers shifting to very short release cycles, and each release exhibiting slightly different characteristics. As you go down in versions one-by-one from Firefox 22, you might literally see the same bug manifest in a dozen different ways.

So, in order to really track an issue under real-world conditions and ensure that it's actually fixed, and in order to be complement our own testing efforts with the radically heterogeneous environments of our users, it is helpful to have a continued high level of real-world usage as development continues.

Category B issues

Performance may seem like the most straightforward thing to optimise without having a significantly-sized user base, but it's actually not. The reason is that such issues often require highly-unusual optimisation strategies. The largest area for performance improvements isn't in the server-side code, but in the client-side code that manipulates the document object model. We're highly likely to encounter new issues as we optimise performance, and we do need new reports as we iterate, rather than by the time we reach a final state.

Category C and D issues

Essentially, any time we make a change to the user experience, we need to see whether it works. Not just "works for us at WMF", or even "works for our projection of what real-world users would expect", but actually works. The diffs of real users making edits using VisualEditor are essential for this. Does the number of references being added go up? Does the number of unintended <nowiki>s go down? Are users successfully using the table editor? Once again, doing this in a "waterfall" model where we come to you in 6 months with a shiny table editor is the best way to ensure that you won't be satisfied with the changes we make, and that we won't either. Aiming, always, for the minimum viable product helps us iterate under real world conditions.

In sum, once again, while I completely understand the frustration with the opt-out beta period, we do need to build an unbiased, reasonably representative set of VE users in order to effectively support addressing any kind of issue you encounter, rather than quietly slaving away for a long time and then releasing a product that doesn't meet user needs and has lots of new and old bugs that only surface in real-world conditions.

Hope that's reasonable. Jdforrester (WMF) (talk) 03:17, 1 August 2013 (UTC)

James, I think you that you are underestimating the problem you are going to get into with regression against stable releases, and also against the problem of defining minimum feature sets. The biggest problem you face is that you are a long way from the minimum feature set, which includes full table editing capability, cutting-and-pasting both inside one VE window and between VE windows, good solid reference/citation wizards, and probably a retool of how Parsoid and VE deal with templates that don't meet your current definitions of being well-behaved. That combination of features is substantial, and runs the risk of having functional regressions while you try to move forward. If you attempt to address that with the multiple release/week cycle you are going to have to go through, you are going to have a horrible time pinning down when and where fixing one bug caused you to regress on another. There's a time and a place for Agile-style methodologies and a time and a place for things closer to a waterfall methodology. Competing with a fully functional editor is one of those places where Agile methodologies have difficulties. The problem here is that you aren't really fixing a problem: there's nothing about VE that makes the average Wikipedia user need to use it, and because we don't need it, we are pretty intolerant of bugs and poor performance. The whole "develop part, see how it flies, develop some more, see how it flies" stuff doesn't work so well when the user can just go next door and use a complete solution.

Another key thing to note is that the changes you are discussing only apply to people that choose to turn this on. Note that consensus so far in this RFC is strong: not only are you expected to turn this off for new users, you are expected to go through and disable VE for everyone. Everyone. After doing that, only people that think you have something worth using and testing will turn it on. It's your obligation to have something worth using and testing, not our obligation to test and use software that doesn't give us benefits. That's where the decision you made to make something the default editor when it fell so short of the minimum expected feature set is going to hurt you, and I can't deny it will be painful. It's pain you brought on yourself, however, by ignoring everyone when we kept begging you to slow down.

You have developed a fan-base though: people that saw VE and think it's worthwhile. Hell, I think it's probably worthwhile. People are still willing to help test if you ask nicely. Maybe not as fast and furious as this, but I would happily run template, citation, and table editors through their paces and let you know how they went. Other people have fetishes about typography management, and you haven't even begun to address their needs (if you can call anything that involves counting the pixels in the width of a horizontal line a "need"). There's a substantial group of people that pretty much fix typos and formatting that seem happy with VE as it stands and will give it a constant basic functionality check.

What you need to understand and internalize is that Wikipedia itself is amazing: a distributed, collaborative work with an enormous pool of collaborators that actually maintains a fairly cohesive style and voice despite the fact that most of us have never met. The tools we have built up for using the existing software have helped us accomplish that, and we need to see how new tools are going to enter into our workflow before they will be embraced. Right now, the released Visual Editor basically supports a substandard junior class of editor that will never be able to compete with people using the older tools. That's not good for the junior editor, not good for the older editors, and doesn't reflect well on the tool the junior editor is using.

No one is asking you to go completely away. What we are asking is for you to not be quite so much in our face. Not to belittle the tools we use, disparage our opinions, and try to pin the blame for UI deficiencies on editors. To recognize that VE is not better than our existing tool-chain, it just appeals to a different class of user. You've got a lot of expertise to draw on here. You've got free access to the opinions of software designers ranging from self-taught script kiddies to old guys like me (over 30 years of software engineering, including software developments where we wrote 2 million lines of code by ourselves, compiled them on compilers that we wrote ourselves, ran them on hardware platforms that we developed ourselves and debugged them with in-circuit emulators that we designed and developed ourselves). It would be a lot better if we all felt like you listened to us.—Kww(talk) 05:06, 1 August 2013 (UTC)

• Why must we mince words here? The thing sucks. It doesn't work, it isn't likely to work anytime soon, and the satisfaction rate with it is near zero. If it were a commercial product it would have been recalled by now and it's only developer pride and the fact that plenty of time has been wasted on it already that keeps it out of the wikidustbin completely. So why not make it a purely optional opt-in feature for the masochists who like to beta test stuff and let everyone else move on? It's painfully clear to everyone without a (WMF) behind their name that this 'feature' is nowhere remotely ready for prime time on one of the world's largest websites. Andrew Lenahan - Starblind 02:51, 1 August 2013 (UTC)
  • Of course it works. Several hundred (if not several thousand) of good edits are being made with it every day. :-)

    Does it have bugs? Of course. It's beta software. (And, by the way, there are thousands of bugs in MediaWiki as well.)

    Nobody is asking you to mince words, but I will ask you to assume a little good faith. I don't have a "(WMF)" in my username and likely never will, but I believe that VisualEditor is the future. I also advocated quite strongly for there to be an opt-out feature (that was successfully re-added) and I continue to advocate for making opt-out even easier (namely by removing the need to even visit Special:Preferences to opt out). I think we should focus on making improvements to VisualEditor rather than simply re-stating how much it currently sucks. --MZMcBride (talk) 03:01, 1 August 2013 (UTC)

    • Part of the problem with the 'let's just fix it' option is that it's totally open-ended. How long are we expected to tolerate during its supposed tweaking period it before it's considered a failed experiment? 6 more months? A year? Keeping in mind this is taking our donation money every second it exists. I say the numbers speak for themselves. If you worked at a soda company, you couldn't keep telling the boss, "I swear Turd Cola will be ready to market any day now! I just have to get the ratio of urea and bile just right! The last taste test only 94% hated it!" Sooner or later you just have to realise that you've cooked up a turd. Andrew Lenahan - Starblind 03:36, 1 August 2013 (UTC)
      • Hi Starblind. As you may or may not be aware, each edit made with VisualEditor (VE) is tagged. For example, here is one of my edits made with VisualEditor. According to this same search, you currently have 0 VisualEditor edits. So what, exactly, are you complaining about? Or more pointedly, who, exactly, are you complaining for? You may think VisualEditor is a complete piece of shit and you're certainly entitled to that opinion. But you seem to have no issue editing the wiki with the source editor and you seem to have no issue avoiding the use of VisualEditor. Can you please elaborate? --MZMcBride (talk) 07:31, 1 August 2013 (UTC)
        • Hi, you have to acknowledge that the reason that a lot of users who want to have VE going back to opt-in mode is not that they don't want to use VE (they can choose to disable it since we now have this option), but is because they are tired of seeing articles being damaged by edits made with VE (nowiki added, problems with tables, ...), damages that will have to be fixed mostly by other people than the one that are creating them with VE. About the number of bugs: you don't run easily on the thousands of MediaWiki bugs and they don't seem to damage articles, but with VE it's a different story. --NicoV ^{(Talk on frwiki)} 09:39, 1 August 2013 (UTC)

It's difficult to disagree with the changes you're proposing, particularly as they echo similar thoughts that I posted earlier today. ;-) I have some minor quibbles (e.g., I think the beta notice should be dismissable, rather than only loaded for the first time based on a cookie), but otherwise these are all sound suggestions that I hope can be implemented as soon as possible.

While I think everyone leading this RFC (and participating in it) is acting in good faith, I think it's important to recognize (as both you, James, and Erik do) that a few vocal power-users on the English Wikipedia cannot speak for everyone. Some good ideas have been brought forward in this RFC and I'm hoping further good ideas are on the way from the very bright and dedicated group of power-users who contribute so much to Wikimedia wikis. However, VisualEditor is a shared endeavor that I hope we all want to see done right.

Again, I think your proposed changes should be of the highest priority, as I think they will be a sign of good faith and good will toward the community and will assuage a lot of the concerns we've been seeing with VisualEditor's deployment. --MZMcBride (talk) 02:56, 1 August 2013 (UTC)

I agree with Jdforrester's suggestions, and think they are the best solution to this issue. I'd also like to note that the visual editor isn't as bad as people make it seem and that it is very useful. A part of the aversion to the visual editor is because it has many bugs and is slow, but a big part is just general change aversion. I like the visual editor: it makes many tasks, such as inserting references, easier (if we exclude the few bugs that prevent some actions). It's great how I can simply click on a reference button and then transclude a template and just fill the parameters without having to keep constantly switching from the editing tab to the tab with the template documentation of the citation template, and have all the parameters and their descriptions right in the editor. There are many things that are good about the visual editor. I don't think it'd be a good idea to remove the visual editor from anywhere, whatever the reason. Nobody is forced to use the visual editor, and if it was made less prominent, then there would be no problem anymore. It doesn't need to be removed, hidden or made opt-in only. -- Rastus Vernon (talk) 02:59, 1 August 2013 (UTC)

While you're entitled to your opinions, consensus is very much against that view, with the current tally being 191 opt-in to 15 opt-out, much worse than 10 to 1. And the response from the German wikipedia was even more decisive. The community has spoken, will the developers choose to listen this time? Andrew Lenahan - Starblind 03:16, 1 August 2013 (UTC)

As long as the visualeditor tab is labelled as "Visual Editor - BETA" I will be more than willing to accept these changes. PantherLeapord|My talk page|My CSD log 04:30, 1 August 2013 (UTC)

Should we move Jdforrester's suggestions to the main page to look for acceptance of the community? -- Sameboat - 同舟 (talk) 04:43, 1 August 2013 (UTC)

We cannot develop VisualEditor in isolation from real users: well, for the moment, it seems quite the contrary.

1) Every major features of VE seems to have been developed in isolation from real users: why didn't you start focused discussions with users for major features rather than deploying features that were totally useless at first (reference editing, ...) ? You could still start those focused discussions but you don't

2) You don't take into account the more important issues for many users: hundreds of articles are currently being damaged every day when edited with VE. And your answer to the main problem is WONT FIX. Usually on every wiki, a tool that is causing damages is simply blocked until fixed, but you're WMF so you consider yourself are above this.

Erik's mail is also based on the assumption that the opt-in alpha period wasn't sufficient, but he conveniently forget to say that you couldn't do anything useful with VE during the alpha (no template editing, no reference editing, ...) so users ended up either not being able to make their edit. There's never been a true opt-in alpha period.

--NicoV ^{(Talk on frwiki)} 04:44, 1 August 2013 (UTC)

Otherwise, concerning your proposals: ok for 1, 2 (rather "Edit" to have the same on every namespace and something like "Visual Editor (experimental)" experimental being easier to understand than beta), 3. For proposal 4, I think its' not enough: it should be dismissed by choice, not only displayed the first time; and the message should be explicit on how to disable it, that edits should be checked by the editor because bugs are expected and that the editor has many limitations. Otherwise, I still believe that VE should go back to opt-in to decrease the number of damages to articles until these problems are fixed. --NicoV ^{(Talk on frwiki)} 09:33, 1 August 2013 (UTC)

• (edit conflict)I agree with James' suggestions. As someone who is spending a lot of time working with VE and the bugs it is causing, I see that VE has a great future. What it needs though is for people to realise that it isn't ready yet, but that the only way for it to ever be ready is by lots of real world testing. There are some bugs that require very specific combinations of elements in order to happen, for example Template:Bug and Template:Bug, that they just wont be found by testing in a controlled environment. That doesn't mean it has to be the default editor, and I've stated elsewhere that it shouldn't be, but it needs to be easily accessible for people who want to test it. If you just want to make a simple spelling correction, then VE is already up to the task so we shouldn't force someone uncomfortable with wikitext into the source editor. Equally, there should be a way for people who don't want anything to do with VE to be able to opt out completely - but the vocal minority of such users should not prevent those who want to use VE from doing so. Clearly marking VE as beta and making the source editor default should reduce the volume of the problems. Going forward there should always (even after the end of beta) be an equal choice between editors - neutrality is a founding principle and we should reflect that. Thryduulf (talk) 09:44, 1 August 2013 (UTC)

• Yes, James's proposals seem a useful way forward. I'll probably continue to try to use VE for my editing, hoping to have a decreasing need for "VE cleanup" Edit Source edits as time progresses. But my motivation for editing is to enjoy myself, to contribute generally to the encyclopedia and improve it, to be useful: I can tolerate some misbehaviour from VE and quite enjoy making careful bug reports on the feedback page. I can see it's all very different for someone with a mission to improve the coverage of Field XXX in Wikipedia, or to get a Featured Article on Topic YYY, especially if they're time-poor, or for someone coming new to editing who doesn't know what the hell is going on when "edit" leads them to totally different interfaces according to whether they're in article space or on a talk page etc. PamD 11:12, 1 August 2013 (UTC)
• Without specifically commenting on James's proposal, I would add to PamD's comments above: I am an example of someone working on a topic I'd like to get to featured article status; I'm using VE as much as I can, and am fine with the current level of functionality. Of course I'd like to see it improve, and I'm sure it will. I'd like to thank the development team for getting this far, and encourage them to keep the visibility and usage of VE high, along with the ability to opt out, of course. We need this tool for the future and we need high-volume usage now to help us get there. If the budget for the dev team were as large as you might get with a Google or Apple team, then sure, I'd expect VE to be a bit cleaner and more comprehensive by now, but we don't have those resources and should not expect outcomes that require those resources. I have no complaints about the rollout so far. Mike Christie (talk - contribs - library) 11:22, 1 August 2013 (UTC)
• Support all four changes suggested by jdforrester. In addition I hope referencing improvements (mainly citation templates & autofill) can be prioritized, as that is the main thing for me personally right now keeping me from doing basically all simple text edits with the VE.--WS (talk) 14:11, 1 August 2013 (UTC)
• Support for this. It makes sense, and also provides an example to use for other changes in the interface. DGG ( talk ) 18:40, 1 August 2013 (UTC)
• Yes, really good suggestions. (I liked the animation. I think moving the [edit] links to the right and keeping the animations will be better than having non animated edit links along with the section headings. The animation draws the eyes, making them more prominent but with less disturbance/distraction. What do you think?···Vanischenu^「m/_Talk」 19:14, 1 August 2013 (UTC)
• A little discussion on the talk page of an RFC cannot be used to subvert the RFC itself. These are all fine suggestions so long as the obvious result of the RFC (that VE is disabled for all accounts, old and new, until the editor specifically enables it) is done first.—Kww(talk) 19:18, 1 August 2013 (UTC)
• First off, I expect the WMF to abide by the results of this RFC, just as they did the one on the German Wikipedia. Our reasons are just as good as theirs are, and we have already assumed a huge amount of good faith here. I think the proposal at the start of this section is appropriate for now, but we need to have some discussion separate to this RFC for the WMF and the English Wikipedia community to jointly determine appropriate methods for introducing software, and the discussion should include how to ramp up the visibility of VisualEditor. Risker (talk) 19:23, 1 August 2013 (UTC)
• I think that we should adopt the four proposals as laid out by jdforrester, and see what happens. If those don't suffice, then we should push for opt-in only. The advantage of doing it as he suggests is that this gives new editors a choice. Even if they decide that VE isn't for them, they'll see its possibilities, and the "beta" label on it will tell them that it will get better. If we go to opt-in only, virtually no new editors are going to be aware of the promise of VE, let alone try it out - because new editors don't go systematically though their preferences (lots of preferences) to decide what to turn on and off. -- John Broughton (♫♫) 23:27, 1 August 2013 (UTC)

• How often do you think a small group of editors should try to override an RFC on the RFC's talk page, John? Is this some kind of new RFC procedure that I've never heard of before?—Kww(talk) 00:37, 2 August 2013 (UTC)

• @Kww: I'm unaware of any Wikipedia rule that says that when a topic is being discussed at an RfC, it cannot be discussed anywhere else but the main RfC page. If there is such a rule, I'd appreciate your pointing it out, and then I'll certainly not violate it again. -- John Broughton (♫♫) 01:28, 2 August 2013 (UTC)

• It's a matter of intent, John. I read your comment as indicating that if the RFC closes with a recommendation to opt-in, you believe we should ignore the result and continue with opt-out. That's not a matter of discussion in multiple places, that's a matter of advocating that we disregard community consensus. Did I misread you?—Kww(talk) 01:32, 2 August 2013 (UTC)

• Strongly agree with all 4 suggestions. For labels, I'd suggest "Edit wikitext" and "VisualEditor ^beta". I agree that making it opt-in at this point would be problematic, as at least some (IP/New/Old) editors do prefer using it, and might not understand how to find it again. Also, per Wouterstomp, please prioritize improving the referencing tools - WP:Reftoolbar should be the guide. –Quiddity (talk) 00:33, 2 August 2013 (UTC)

 Done @Kww, MZMcBride, Starblind, NicoV, and Rastus Vernon:, @PantherLeapord, Sameboat, Thryduulf, PamD, and Mike Christie:, @Wouterstomp, Vanischenu, Risker, John Broughton, and Quiddity: As an update, this is now - I've posted an explanation for the decisions I've made and the reasons we've done it like this at Wikipedia:VisualEditor/August 2013 update. Jdforrester (WMF) (talk) 05:27, 2 August 2013 (UTC)

'tis appreciated. (Note, I've changed your link from "here" to the actual pagename, per click here being considered harmful ;) –Quiddity (talk) 05:32, 2 August 2013 (UTC)

I find that using "Edit source" and "Edit beta" is a bad idea: "source" or "beta" don't mean much for a basic user. At least as long as VE is alpha/beta, we should keep the default "Edit" for the classic wikitext editor. For VE, I think "experimental" (or other true english word) is more obvious than "beta" for non tech people. On Preferences, we already have "(experimental)" used for Live preview. --NicoV ^{(Talk on frwiki)} 06:49, 2 August 2013 (UTC)

We need to keep in mind what the interface will look like at the end of the beta, so we don't heighten the confusion at that point. With the current setup, it's simply a matter of taking off the "beta" label (short of a drastic refactoring of the edit UI altogether), without additional confusion. It'll take some time to adjust to this change for sure (as it does to any change), but at least we can keep it in place and let folks develop muscle memory with the new system which they get to retain.

As for "edit source", I think the devs chose "Edit source" in the first place because "View source" already appears on semi-protected pages. So introducing the notion of source-editing into the vernacular does not seem unreasonable to me. It may be worth revisiting that at some point -- personally I prefer "wikitext" to "source" because it sounds more friendly and less programm-y.

As for "beta" vs. "experimental", it's partially a matter of finding something short (string length) that has widely understood meaning - keep in mind these strings have to appear both on section edit links and tabs. The meaning of "beta" in this context is explained in the message that comes up when you first invoke VE.--Eloquence* 07:02, 2 August 2013 (UTC)

I think the changes suggested are a big step in the right direction. I also like "wikitext" better than "source" as it is likely to be more meaningful to the general public, takes very little extra space, and will not confuse the experienced editors. Experimental is clearer than beta. If space is an issue then beta is OK, Much better than nothing. Nothing is Really Bad™. Cheers, • • • Peter (Southwood) ^(talk): 09:23, 2 August 2013 (UTC)

Opening up the whole article for editing in VE is also an unpleasant surprise (Really Bad™) which should be eliminated urgently. When you click on a section edit link you expect to edit a section, not the whole article. Finding the place you wanted to edit is sometimes a non-trivial exercise. If this can't be done for technical reasons, take away the VE link at the section headers and have it only at the top tab. • • • Peter (Southwood) ^(talk): 09:23, 2 August 2013 (UTC)

Restore site notice?

For a few hours last night, a site notice pointing to this RfC was up. It resulted in about 100 editors expressing an opinion here, in the space of a few hours. The site notice was removed in the small hours. Could we restore it? No one notices watchlist notices: the site notice was very clearly more effective in bringing eyes to this page. Andreas JN466 14:30, 1 August 2013 (UTC)

Discussion here: MediaWiki_talk:Sitenotice#Remove_VisualEditor_default_state_RFC_notice Andreas JN466 14:34, 1 August 2013 (UTC)

I agree it should be put back. Kumioko (talk) 14:35, 1 August 2013 (UTC)

Could you please say that over at MediaWiki_talk:Sitenotice#Remove_VisualEditor_default_state_RFC_notice as well? Thanks. Andreas JN466 14:39, 1 August 2013 (UTC)

Well, err, yes: a site-wide notice results in more visitors (and thus editors) to a page. Film at 11. --MZMcBride (talk) 15:03, 1 August 2013 (UTC)

MZM, WP:CIVIL please. —Sladen (talk) 02:50, 2 August 2013 (UTC)

I'm trying my best. --MZMcBride (talk) 03:29, 2 August 2013 (UTC)

Thank you

Thank you for even more great info. as I have just heard of the Visual Editor. — Preceding unsigned comment added by Mikeg0513 (talk • contribs) 17:55, 1 August 2013 (UTC)

Anonymous editors?

If I create a username such as "Mr. Mysteroso123" or "anonymousguy111", or some such, and edit under that, I'm an "anonymous editor" in the sense that no one knows who I am, but is this what is meant?

If I edit under my IP address, I'm anonymous in the sence that I have "no name", "a -nonym -ous", but then everyone can easily find out where I am and therefore potentially even who I am, so it's not really as "anonymous" as editing under an assumed name, in the commonly understaood meaning of the word "anonymous".

So the term "anonymous editor" is ambigous.

If you mean "IP address editors", why not just say that? It would be more precise, less ambiguous, and not propagate the myth that editing under your IP address means that no one can know who you are. Chrisrus (talk) 19:44, 1 August 2013 (UTC)

I agree that "anonymous" is too ambiguous. But "IP address editor" is ambiguous to non-technical people too. It would be best to have a term that non-technical users would understand without further explanation. Even "log in" and "log out" can be problematic, because they overlap with the idea of "logs" and "logging". What we mean is "not-signed-in" editors. If you have not signed in your edits will be logged against your current IP address, which may allow people to identify your location, etc. When you haven't signed in, you should see something like the lower UI:

We also need a vocabulary that distinguishes users who do not have accounts from those who do have accounts but are not currently signed in. "Anon" vs "registered" doesn't do this. But perhaps that's a discussion for another day.... - Pointillist (talk) 22:45, 1 August 2013 (UTC)

This could be a bad idea

This could be a bad idea in which it will change MediaWiki to a visual editor only mode in the future like some other organizations/companies/whatever does. For example, many people new to MediaWiki could mass demand visual editor only in which all wikis could be forced to visual editor. Source mode is the best to use even for new, anonymous, etc users for they can actually learn something without it being handed to them like hey all I have to do is click this and that, an example of not learning could be Wikia(No offense wikia)--Micronationalist1999 (talk) YOUR PROUD BANANA 22:24, 1 August 2013 (UTC)

Thanks for your input! Please make sure you give your thoughts on the actual RFC page rather than this talk page where it could be overlooked. Killiondude (talk) 06:54, 2 August 2013 (UTC)

The purpose of Wikipedia is not to learn wikitext markup. It is to create and use an encyclopaedia that anyone can edit. Wikitext is a barrier to a large number of people who could provide a lot of valuable content. • • • Peter (Southwood) ^(talk): 09:40, 2 August 2013 (UTC)

[citation needed]. There's no evidence that wikitext specifically is a significant barrier to entry or that it has anything to do with the wiki's editor retention stats, nor that a visual editor will provide even the slightest help with that; without that evidence, all of this development time and serious disruption to the wiki is being made over what amounts to a glorified hunch. (While it is too early to tell, of course, how things will be when all the bugs are worked out, what evidence we do have suggests that the visual editor has, so far, been actively harmful.) The visual editor itself is going to require time to learn and use, and there's no reason to think that the time required to learn how to do "simple" edits via the editor is any less than with wikitext; there's also plenty of reasons to suspect that wikitext makes it much easier for new users to pick up day-to-day 'mid-level' skills for whatever area they want to focus on (since they can see how something was done by viewing the text, whereas a visual editor doesn't tell you what of its numerous confusing buttons to push to replicate something you saw elsewhere.) Additionally, while it's certainly true that the purpose of Wikipedia is not to learn wikitext, it is unfortunately inescapable that the wiki is constructed entirely out of it; no editor is ever going to be able to provide full control over wikitext without becoming hopelessly complex in the process. That means that creating an alternative "learning path" where people spend their time learning how to use a complicated visual editor is only setting them up for eventual frustration when they learn that the complicated visual editor they've been wasting their time learning is still useless for many tasks -- even learning every single one of its dozens of unintuitive buttons still doesn't let you do everything you will need, and actively replaces the learning that would have helped them contribute more broadly. --Aquillion (talk) 22:30, 2 August 2013 (UTC)

I believe that you will find links to the evidence that you seek at Wikipedia:VisualEditor/Why. If you'd prefer anecdotal evidence to systematically gathered quantitative data, I've personally had people tell me that they do not edit Wikipedia because the markup is too confusing. Most recently, I spoke with someone in June who said that he had tried to fix an error in a page, and that he simply closed the window after seeing how complicated the code was.

The complexity varies a lot by page. There are some that I think most people could figure out in a minute or so. There are others, like the huge template-constructed tables of television episodes or election results, that even I find complicated. Whatamidoing (WMF) (talk) 22:07, 3 August 2013 (UTC)

No, there's no evidence at Wikipedia:VisualEditor/Why; all it has is a graph showing that 1-year retention has been declining over time after an initial spike when Wikipedia first appeared (and even then, the graph is from 2009, over four years ago -- even if it showed what you claim, which it does not, it would be ridiculous to use it as a justification for anything.) It links to the A/B test, which shows that the visual editor has driven people away, but nothing in there concretely connects the problem to wikitext. Either way, that graph says nothing about why it was declining back in 2009; I think a very reasonable assumption is that Wikipedia (when it first exploded into the popular consciousness) spread rapidly to everyone who was interested in using an encyclopedia and who was currently using the internet, then increasingly gradually once those people were recruited. Wikipedia's graph of usage also mirrors the problems with retaining users seen by many other major sites with unrelated purposes, like Amazon and Yahoo; the early internet was a fundamentally different place, and usage trends have changed in a way that makes it harder to recruit people. All of this is at least partially speculative, of course, but it's no less speculative than the random and arbitrary speculation that Wikipedia's shift in usage was because of wikitext, or the entirely unproven and speculative assertion that a WYSIWYG editor is easier to use. I don't find your speculation or your anecdotal evidence to be convincing at all -- surely many users are now going to be scared off by the clunky and excessively-complex appearance of the bloated visual editor, while previously, many parts of Wikipedia had very simple layout and did not require knowledge of wikitext at all. (And, of course, the most complicated parts of the wiki -- the most intimidating ones -- are entirely impossible to edit with the visual editor by any means.) --Aquillion (talk) 01:20, 4 August 2013 (UTC)

Again: I believe that you will find links to the evidence that you seek at Wikipedia:VisualEditor/Why. Not "directly on the page", but "links to". Please read the subpage Wikipedia:VisualEditor/Why/User Test Data. You will also want to look for information on the 2010 Usability Initiative, which interviewed former editors about why they quit editing. A substantial minority said that they quit because wikicode was getting too complicated. Another substantial minority said unpleasant encounters with community members was the primary reason they quit. Another large fraction gave changing life circumstances (like acquiring full-time work) as their reason for quitting. But the fact remains that some actual, real former editors said that wikicode was too complicated for them.

It would be interesting, of course, to correlate those complaints about excessive complexity with the rise of infoboxes and citation templates (the two things people most frequently identify as being frighteningly complicated to look at in wikicode), but I don't believe that anyone has attempted that. Whatamidoing (WMF) (talk) 21:24, 4 August 2013 (UTC)

Super simple intro

I just now put in a few extremely simple sentences as a brief intro explaining what VE is for people who have no technical understanding and very little experience with editing the encyclopedia. Invertzoo (talk) 22:45, 1 August 2013 (UTC)

In which they need to L.E.A.R.N the technical understaning and get experience with the help page and some tutorials by using their brains instead of having something handed to them.--Micronationalist1999 (talk) YOUR PROUD BANANA 23:35, 1 August 2013 (UTC)

Confusing Source Code

This should be enabled because to most new users, as I once was, the source coding can be very confusing. Now, it is for this reason VE should be enabled for new/anonymous users because a user may want to fix what seems like a simple typo, and he or she goes to fix it, and unknowingly contributes to a larger problem.
Ben (talk) 23:58, 1 August 2013 (UTC)

Thanks for your opinion! If you haven't already, please make sure you add your thoughts to the actual RFC rather than this talk page. Killiondude (talk) 06:53, 2 August 2013 (UTC)

PLEASE CLARIFY WHERE DISCUSSION SHOULD BE TAKING PLACE

Many people are contributing to this discussion yet it is currently being 'discussed' on the Project page AND the Talk page. Which page should this discussion be taking place on & should all comments be moved across to the correct page? --Iryna Harpy (talk) 06:10, 2 August 2013 (UTC)

I think it depends what you want to discuss. This page has many subsections discussing different things. The project page (WT:VE) is more of a meta-page that is about a variety of things including text on the actual project page, a corresponding wikiproject, and some bugs that should probably have been reported on WP:VE/F. Things like this that have site-wide and long-lasting implications tend to have discussions that spill over everywhere. Just find where your 2 cents fit best. :-) Killiondude (talk) 06:52, 2 August 2013 (UTC)

Fair enough. I've already inserted nearly a buck's worth on the project page. No doubt, someone will start up an offshoot talk page on some point of order & I'll be able to continue my squawking there. Cheers for the response! --Iryna Harpy (talk) 07:11, 2 August 2013 (UTC)

Category D issues

Jdforrester gave an interesting categorisation of "issues" and the need for extensive user testing in the various categories. The fourth and last was Category D: missing functionality, e.g. "I can't insert or edit maths equations" and it seems implausible that any sort of testing can help with a functionality that isn't even there. Where users could perhaps help is in the design stage. In the area of mathematics, which is explicitly an example of a missing functionality, and which happens to be the area I edit in, there is a considerable amount of expertise and experience in the community about user interfaces for editing mathematics. Perhaps WMF developers should be engaging specialised communities such as this at an early stage? A notice at Wikipedia talk:WikiProject Mathematics asking for contributions to the design of the user interface would be much appreciated and probably quite helpful. There's a discussion there right now illustrating the degree of experience and range of opinions in that community on the subject of displaying mathematics. I do hope developers have not underestimated the extreme difficulty of designing a viable point-and-click interface for mathematics — in fact I would go so far as to say that in my opinion nobody has ever succeeded in producing any kind of interface which can match the productivity of TeX-based markup. Spectral sequence (talk) 18:19, 2 August 2013 (UTC)

I believe that several people have already provided their opinions about TeX and related options, but more are always welcome.

There are several obvious missing functionalities, but some are far from obvious, usually because they are only used on a tiny number of pages. Whatamidoing (WMF) (talk) 20:41, 2 August 2013 (UTC)

Thanks for that — glad to hear you have already started to engage. Could I ask how and where you wish to engage with the existing community of mathematics editors? Will you post on Wikipedia talk:WikiProject Mathematics‎ with the contact details, please? It would be interesting to know what the developers plans are for the VE mathematics interface, and I'm sure you'll find there's a lot of useful experience and expertise in the mathematics community available for you to tap into if you would share your thinking with us as early as possible. Spectral sequence (talk) 21:17, 2 August 2013 (UTC)

I've given up testing V/E

I was one of the testers early in the year and I thought it might be helpful to explain why it was such a frustrating exercise and why I wouldn't recommend it to others. Firstly there were too many testers for the size of the development team, we kept finding that we'd not discovered a new bug, rather we were the nth editor to report a particular known bug (Taking it out of Beta testing early has presumably only made that worse). Sometimes bug reports just went off into the archive without comment or action. Secondly it quickly became clear that v/e is not aimed to be a logical editor for people like myself who make large numbers of minor typo fixes. For me the lack of prefill in the edit summary field is a big deal, much bigger than for the editor who spends half an hour over each edit and for whom the edit summary is a small part of their editing. Once I heard that they weren't going to fix the prefill issue then I knew I'd personally be sticking with the classic editor. Then there's the whole problem with bugzilla. it isn't a wiki, it isn't even in SUL. Bugzilla looks almost like a tool the developers use to insulate themselves from the community. Lastly but most seriously I've done software testing in previous careers, I've been on the testing side and also the development side. In my experience it works best when you go back to the tester and tell them that you've now fixed the bug they spotted. ϢereSpielChequers 18:23, 2 August 2013 (UTC)

I completely agree and had the same reaction. When I found out about VE it was May and as I was testing I found that the developers weren't particularly interested in fixing the bugs, they seemed to be more interested in documenting them so that when they released VE they could say the problem was identified. When we told them months ago that the program wasn't ready and they should delay it, they didn't listen and released it anyway wiping away any good will that the community had. Even given the huge push back they received from the community. They have even made comments in various places that the response from the community was better than they expected. Really? This is better than expected? I would hate to see what they did expect. Kumioko (talk) 18:59, 2 August 2013 (UTC)

Thank. That just confirms my suspicions about this. It is nice to have some confirmation. However, I am a little dismayed some criticism of me making the same points on the main page for making the same points, along with positive suggestions of how things might be improved (which impact on improved project management to test properly before releasing beta software, and proper survey design to avoid loaded questions), which allege that I have only made denigratory comments and that I have been entirely negative. I hope it doesn't mean that not only do the team not want to do anytjing about bugs, but they do not want people to specifically criticize what has emerged and make positive suggestions of how they might work better.  DDStretch  (talk) 20:31, 2 August 2013 (UTC)

I wouldn't take it personally. The same types of comments have been made to many of us. It seems unless you are there to pat the WMF on the back and tell the what great job they did and how wonderful VE is they don't want to hear it and just dismiss comments as meaningless. Kumioko (talk) 20:43, 2 August 2013 (UTC)

Kumioko, if you look at the chart here, I think you will find that the devs resolved almost a hundred bug reports during May. That doesn't sound to me like evidence that they "weren't particularly interested in fixing the bugs". Since the software developers seem to prefer actually fixing the bugs to merely talking about the need to fix them, though, I can easily see how the situation might result in an inaccurate appearance that they didn't care. I'm sorry that their decision to fix more bugs instead of fixing fewer bugs but documenting their work on this particular wiki left you with such an inaccurate idea about whether the bug reports were read or being used. Whatamidoing (WMF) (talk) 21:18, 2 August 2013 (UTC)

Whatamidoing, that was a good attempt at deflecting my comments but ineffectual I'm afraid. It has nothing to do with that at all. None of what you say is accurate of what occurred or what has been conveyed by the developers repeatedly in multiple conversations. My criticism at the developers and other members of the WMF isn't based on their lack of comments but what they actually did and said when they said it. Your also right they fixed a lot of bugs in May but fixing 100 problems of hundreds is hardly sufficient. Kumioko (talk) 22:41, 2 August 2013 (UTC)

Agree totally. This seems like a development team that had a good idea, and plunged ahead with it, but brought it out to a large pool of user-testers before they realized that they bit off more than they could chew. Philosophically and practically, I can see a lot of value in making an easy-to-use interface available for the casual editor. As a semi-active editor, I found it disconcerting to have the vast majority of edits I made become less-convenient. There were 2 major impediments: the VE interface became the default in many contexts, requiring me to learn new habits to do the same old thing and the VE was, and continues to be, unreasonably slow. The bugs and lack of clarity in scope compounded this by making me do everything twice: once in VE to discover it wouldn't work, then again in source to get it done. It would have been better to hold off launch (both Beta and production) until the dev team had a more mature product. It would also be good to slow the increase in scope of VE until there's enough hardware bandwidth available to support it. I hope neither has gotten to the stage that it's too late to do anything. --Wcoole (talk) 21:13, 2 August 2013 (UTC)

WereSpielChequers, the edit summary "prefill" (or drop-down with previously used summaries) is currently involved in bugzilla:52133 and it seems like there is a chance that this *could* be fixed. Killiondude (talk) 23:31, 2 August 2013 (UTC)

But it was also raised as Template:Bug and the devs don't seem interested in fixing it ("low enhancement" and some pretty negative comments). PamD 09:22, 3 August 2013 (UTC)

Hi Killiondude, it is good to hear that they are now considering how to fix this, though I'm not keen on the drop down box solution, we already have that as an option and it doesn't work well for me. But it is a sign of there being too many testers even at the Beta phase in May problem that I didn't hear that news from the developers or the community liaison. ϢereSpielChequers 17:47, 3 August 2013 (UTC)

I would like to thank everybody here who has kept testing VE since May. I have actually read several comments of people, not just on en.wp, who noticed many improvements in these months (personally, I don't think you really need charts to see that), but I guess their stories are not so interesting ;) Anyway, I am not aware of people being personally notified about bugs, simply because Bugzilla has exactly this feature (you get an email each time someone updates that bug, so I really suggest that you give it a try!) I'd also notice that Bugzilla has been around like, forever, so that's at least one thing I would not blame VE for :) --Elitre (WMF) (talk) 19:06, 3 August 2013 (UTC)

Thanks Elitre, I'm aware that bugzilla precedes this saga, but this has highlighted its deficiencies, especially because of the way the number of testers was increased far beyond the ability of the developers to cope. I believe that most of the bugs that I found in May were ones that had already been identified, and I doubt that has changed. It is now August, major problems like v/e's unacceptable slowness for older CPUs have been known for literally months. So the typical experience of someone reporting a v/e bug is going to be that after a while someone will mark it as a dupe of an existing bug, they will then discover how long the bug was known about before they suffered from it, and then they won't hear anything more. Bugzilla might have worked with a smaller group of testers or if the developers were so on top of things that most reported bugs were new bugs. But it isn't a suitable system for this situation. It is especially problematic for using IP editors as guinea pigs since Bugzilla does not allow reporting by unregistered IP editors. ϢereSpielChequers 23:39, 3 August 2013 (UTC)

I'm pleased to see that there is some sort of serious discussion regarding the state of VE being raised here. The fact is that there are more than a few bugs left to be ironed out, yet accusations as to wikimarkup elitism is being thrown around on the project page. Why has been accepted that VE must be rolled out right here, right now? Has some sort of belated Y2K bug been detected making the rolling out of a seriously flawed beta version not only inevitable but urgent? There seems to be a mentality surrounding VE that, now that it's gone live it's reached some invisible 'point of no return'. Please, take a serious look at some of the comments regarding where it's failing. The issues do not revolve around elitism or some imagined dinosaur mentality. --Iryna Harpy (talk) 10:40, 3 August 2013 (UTC)

The problem is that well-established and proven methods of managing this kind of project, including when and how to test it, and when and how to roll it out, have apparently not been followed completely. Thus we have a buggy editor released that cannot do many of the tasks people would want it to do (this highlights a lack of proper prior research about users' needs), and a set of loaded questions that form this RFC produced that seem to pre-suppose that this editor will be kept and firmly introduced, almost in its present state, to beginners and anonymous editors when it is still announced to be "beta software". I quite agree with what various users have said, both on this talk page and on the main RFC page for these discussions, but I am dismayed at the dismissive reaction that mean many of our valid criticism of the faults of the software, and the apparent flaws in the process of managing this entire project are ignored. Iin one of my cases, a reply to some serious suggestions for improvement was used merely as an attack on my own personal integrity, so that I ended up being called unduly negative and denigrating. This seems to be a case of attention being given too much to the presentation of some new software and its praise, rather than a critical examination and frank appraisal of its content and actual process of development. At least, I would have hoped that the project team would have looked at the various wikipedia articles on software management and introduction, and then I hope they would at least have been able to give rational reasons why the well-accepted processes seem to not have been used here. Similarly, I would have expected some justification of the elementary mistakes made in asking such loaded questions in this RFC to be justified in a similar way (I have taught, advised and evaluated survey design and questionnaire design for over 30 years, so I do know about this issue in great detail.) Unfortunately, all we have are attempts to be dismissive of criticisms and attacks by others, which in other contexts would seem like defensiveness in the knowledge of problems that need to be covered up. I hope to be proved wrong here, but I would like to see some hard and definitive answers to these problems that have been raised by an official team-leader of this piece of software and project. It could have been done a lot better with some elementary knowledge unless special factors are present, and it would be good to know just what these factors could have been (if there are any), and how they were evaluated to be so important that this apparently flawed process was adopted and the well-established procedures not followed.  DDStretch  (talk) 11:35, 3 August 2013 (UTC)

I've come to the point of believing that main reason for the schedule can be found in here. Every time the question was asked about why maintaining the insane schedule was asked, no answer. --NicoV ^{(Talk on frwiki)} 12:21, 3 August 2013 (UTC)

It's pretty much impossible to explain why they've "maintained the insane schedule", because they haven't actually stuck to the original schedule. I believe that the only event on the schedule published earlier this year that happened on the originally projected date was the 01 July rollout to registered editors at the English Wikipedia. Everything since then has been delayed by weeks to months.

At this point, more than 90% of wikis will get VisualEditor after Wikimania. Nobody at the WMF seems to be even slightly unhappy about that, and I've never seen a single staffer suggest that it would even be desirable. (In fact, the only thing they have said is that it would be extremely undesirable to deploy anything or make any changes at all during Wikimania.) The "must be done by Wikimania" rumor seems to just be another unfounded rumor with no basis in fact. Whatamidoing (WMF) (talk) 22:19, 3 August 2013 (UTC)

Granted, Wikimania may or may not be the reason. But if its not then why on earth would the WMF insist on keeping pushing VE after so many have said it isn't working, isn't wanted or isn't compatible. I have been on Wiki for years and I have seen the community push back on a lot of things. VE is the most reviled feature that the WMF has ever pushed out and largely because they refuse to except the fact that the app isn't ready for rollout. If they would just see reason and slow the F down and fix the problems then I think most folks would be ok with it or get behind it. But when we have an application that still causes massive errors and doesn't even work on most major browsers then its time to accept they F'ed up pull it back into an opt in state and keep working on it until its worthy of our time. But right now its a waste of our time to even use it given all the problems and its making people stop editing. Kumioko (talk) 22:45, 3 August 2013 (UTC)

I gave up trying to deal with developers after they kept insulting me for asking that the ridiculously-bad handling of large PNGs be fixed, or the several fixes made and abandoned actually be finished. Did you know complaining is grounds for block on bugzilla? It's off-topic, see. Adam Cuerden ^(talk) 00:48, 4 August 2013 (UTC)

Like DDStretch, I've been involved with my university's survey & questionnaire unit (attached to the Faculty of Economics, Business Studies) for the last 20 years, and have to agree that the methodology deployed here could be presented as a prime example of a flawed strategy from inception to delivery. I've also worked on web development since the mid 90's and am all too familiar with overexcited IT specialists getting caught up in the moment and forgetting all about the demographic they are purportedly serving. Similar concepts of 'updating' the Wikipedia entry page RfC recently brought up issues of primary concern which are constantly being overlooked:

A) Many contributors do not live in a major US city with high broadband speeds, nor do they even have access to newer computers (much less be in a position of being able to install contemporary browsers). I have sincere doubts that, even if VE was even close to par for newer computers, it would not be backwards compatible for more than a couple of older OS's or older versions of predominant browsers. Well, that's wonderful incentive for attracting new contributors. If you don't already feel like a second-class citizen, we'll make certain you don't forget it.

B) The fact that VE does not show hidden code, doesn't support mathematical & scientific algorithms & symbols, does not support non-Latin-based charactersets/scripts, etc. is a serious concern, not something to be addressed at a later date if someone gets around to it & can actually find a fix.

Ultimately, Wikipedia is being treated as a test site for budding programmers to flex their grey-matter muscle. I seriously believe that 'What Wikipedia is Not' should be expanded to state that it is not a commercial site trying to compete with the gimmickry of social networking sites luring in those with expendable incomes to the ends of attracting advertising bucks. Also, while Wikipedia is not a democracy, neither is it here to be usurped by minority interest groups over and above the needs/wants of of the majority. New ideas on methods of delivery do not necessarily equal progress. --Iryna Harpy (talk) 04:31, 4 August 2013 (UTC)

Incidentally, Whatamidoing, responses such as, "At this point, more than 90% of wikis will get VisualEditor after Wikimania. Nobody at the WMF seems to be even slightly unhappy about that, and I've never seen a single staffer suggest that it would even be desirable." do not actually qualify as being valid responses to valid questions being posed by contributors who have serious & legitimate concerns about VE both in general & on specific matters. You're merely relaying a point that has been understood by those who are not part of the WMF. Could you please provide some information on the number of individuals who constitute WMF as opposed to the number of Wikipedians who are regular contributors (usually working on their own & in their own spare time)? WMF = what percentage of the overall content of Wikipedia? An approximation would suffice. --Iryna Harpy (talk) 05:04, 4 August 2013 (UTC)

The question asked was whether the WMF staff cared about having VE rolled out before Wikimania. The answer, as far as I can tell, is "no". This seems to me to be a relevant answer to a valid question.

I don't think that I understand your question about the percentage of content. The WMF staff does not create encyclopedia content as part of their jobs. Staff members are permitted to volunteer just like anyone else. For example, you have made 456 edits to all WMF projects combined so far, and I think that my volunteer account is approaching 75,000 these days. But that's strictly volunteer work and has nothing at all to do with my current role as a staff member. Whatamidoing (WMF) (talk) 21:42, 4 August 2013 (UTC)

It's just not the truth to say that the only part of the schedule that was kept was July 1st, because many steps were kept or delayed for 1 week at the last moment (but still compatible with showing that VE is the default editor at wikimania)... A/B test was kept, rollout to registered users was kept (July 1st), rollout to anonymous users was kept (July 15th), rollout to registered users on major wikis was kept (July 24th), rollout to anonymous users on majour wikis was kept (July 29th). There has been no explanation about why keeping this timetable, even when asked so many times, when VE is clearly showing that it's not ready. The only step that has been really postponed is the rollout to all other projects. --NicoV ^{(Talk on frwiki)} 06:57, 4 August 2013 (UTC)

Not true. Please check the history of any page including the schedule to find out how many things (not just dates) changed. --Elitre (WMF) (talk) 07:02, 4 August 2013 (UTC)

Yes, I have checked: July 15th (anonymous on enwiki) instead of July 8th, July 24th (registered on major wikis) and 29th (anonymous) instead of July 15th. For me, this is still a schedule that was kept without any explanation on why it was so urgent (still no answer to that question). --NicoV ^{(Talk on frwiki)} 07:10, 4 August 2013 (UTC)

That's still a major point no one from WMF seems to want to answer... and we're still asking and waiting on an answer as to WHY this roll out has been treated as if it were an absolute priority over even being able to decide on what to name the tabs! The names have been changed but, for any new users, there's absolutely nothing intuitive about the nomenclature. You hadn't even thought that out properly. Is this some sort of rollercoaster ride with unstoppable momentum or are you simply not prepared to listen to contributors asking you to slow down due to valid concerns? WHY IS THE VISUAL EDITOR BEING ROLLED OUT WHILE HAS BEEN IDENTIFIED AS BEING FUNDAMENTALLY SERIOUSLY FLAWED? Is that really such a difficult question to answer? --Iryna Harpy (talk) 10:20, 4 August 2013 (UTC)

NicoV, the A/B test was also delayed.

Iryna, perhaps you could explain what's left to "slow down" here at the English Wikipedia. Nothing else (except many bug fixes) was planned for the English Wikipedia after the IP rollout. The only thing that could be "slowed down" (rather than "reversed" or "hidden" or "removed") is availability at other projects, which naturally would have no effect here. Whatamidoing (WMF) (talk) 21:42, 4 August 2013 (UTC)

Not only do we need to delay the rollout to other project until VE is fixed we need to de-roll it here. They can't even get it to work with some of the major browsers and can't get it to stop adding or removing stuff it shouldn't be doing. At this point the WMF is responsible for every error that VisualEditor makes. But in this case we can't block them as we would anyone who fails to follow the rules of use for AWB, twinkle or the other tools.Kumioko (talk) 21:52, 4 August 2013 (UTC)

The A/B test was delayed only a few days, and instead of delaying the rest, it got reduced to 3 days, and the roll out kept going on immediately (registered, anonymous) without even waiting for the analysis... And you keep dodging the question about why it was urgent to roll out VE to every one, as it has been done each time the question was asked. --NicoV ^{(Talk on frwiki)} 21:57, 4 August 2013 (UTC)

In my opinion the reason he and others are dodging the question is because there is no reason or justification for it. He doesn't answer because he doesn't know any more than the rest of us. Kumioko (talk) 22:03, 4 August 2013 (UTC)

For a programmer, you're doing an excellent impression of a politician, Whatamidoing. No matter how I parse your response to me it reads as game of semantics rather than anything remotely resembling an answer. If the implementation of V/E is a foregone conclusion, why is the RFC even bothering to ask questions such as whether unregistered users & anonymous IP's should be given the option of opting in, etc.? Surely, the whole kit & caboodle was planned to be in place ASAP regardless of whether it actually worked or not. I'll play at semantics with you: why isn't V/E being rolled back in order to discuss and analyse fundamental issues plaguing the system when there is such an overwhelming negative response to V/E in its current state? Personally, I'm not calling for it to be scrapped as it may well develop into a reasonable supplementary tool (if not as a viable alternative to source coding) at some point in the future. The future, however, is not here and now. V/E is beyond problematic in its current state and the attitude to the naughty naysayers smacks of blatant disregard for those who have to clean up the messes it leaves in its wake. You're dodging the real questions and you know it. Delays on rolling out flawed software and quickly rolling back while bugs are fully identified & addressed are counted by weeks and months, not by hours. --Iryna Harpy (talk) 01:32, 5 August 2013 (UTC)

I am not a programmer. (I'm also female.)

The RFC was begun by editors at the English Wikipedia. The WMF has no reason to interfere in their decision to discuss it. In fact, the WMF is actually interested in their opinions on the matter. The "number of users" isn't so interesting, but the reasons, concerns, and specific problems identified are very interesting, because it helps the devs understand what the most pressing problems are for the real users.

NicoV, I think that the devs' understanding and the community's understand of the schedule are very different. You ask "why was it so urgent?" As far as I can tell, it wasn't rolled out because it was "urgent"; it was rolled out because it was normal to do so at that point in development. We had discussions here about what features were important to have in place before it was made available to all of our editors here. We all agreed that VisualEditor could be made available as soon as basic support for refs and templates was available. These features were added, and therefore it was made available to everyone shortly afterwards. There was no "rush" or "urgency" to get it out on the devs' part. I realize that a software developer's idea of "ready" and an end-user's idea of "ready" can be very different, but the devs actually thought it was ready (by their definition). The WMF is not averse to slipping schedules; in fact, if you go read about previous projects, you'll see that they have something of a reputation for delivering products late, and this doesn't seem to bother them. So: why the rush? There was no rush. There were only different ideas about what constitutes readiness.

VisualEditor has not been completely removed for all users at this time for several reasons, which you will find repeated on this and other pages. Just in case you haven't seen them or did not recognize that these were answers to your question, I offer these brief summaries of several major points:

1. Removing VisualEditor means hiding it from new users who have made hundreds of successful edits in VisualEditor and do not know how to use the old markup editor. "I want to hide this from everyone who is using it" requires a substantially stronger justification than "I want to hide this for my account only".
2. The devs need to know what does and doesn't work for thousands of real-world users on thousands of articles, so that they can figure out what effect each small change has. They need to know how it works, or doesn't, for people working on an enormous variety of articles. It's useful to know whether it works on a very average article like Golden-crowned Sparrow, but it's also important to find out whether it breaks the very few articles here that uses the {{R}} template system or WP:List-defined references. It's important to find out how the table breaks when someone (quite possibly me) misformats a table. Real-world experience, with all of the odd combinations of browsers, computers, articles, previous actions, and user skills, is not something that can be achieved with structured testing or by having a few dozen experienced editors opt-in.
3. The staff is mostly out of town for the first half of August. There is essentially a code freeze until the middle of August. You should not expect anything other than a total, site-completely-down disaster to result in changes before August 15th.

NB that this is not a complete list of reasons, and that in being a summary, some of the nuance and complexity is being lost. But please notice also that, to the extent that any of these points sound familiar to you—I believe you have personally contested some of these points—then that familiarity is proof that this question has been answered within your 'hearing' already. Whatamidoing (WMF) (talk) 19:17, 5 August 2013 (UTC)

"...it was rolled out because it was normal to do so at that point in development isn't true, Whatiamidoing. Most developers wait until they have basic functionality. Additionally, if they do A/B testing, they wait until they have analysed the results before they proceed. It's extremely implausible that the release wasn't done in order to be able to claim that a date goal was met.

I've said it before and I will say it again: when one has made an extremely public mistake, the best route forward is usually a heartfelt apology and a pledge not to repeat the mistake again. It's unfortunate that the WMF still fails to acknowledge that it even made a mistake, much less showing any inclination to apologize for it and learn from it.—Kww(talk) 20:21, 5 August 2013 (UTC)

I do agree with Kww, because it wasn't 1 roll out, but 5 roll outs. I've been in the software development community for quite a while, and when you start to roll out a software and see many bugs piling up fast, as a developer you never want to roll out to even more users, but that's what you're telling happened on the last several rolls out ?

And, when I read that staff is mostly out of town for the first half of August, I understand that the initial planning was to have a full roll out to every wiki just before every staff was unavailable (29 July: Launch to all logged-in and anonymous users on all other projects) and let every wiki then deal on their own with the problems ? What a great planning... --NicoV ^{(Talk on frwiki)} 20:58, 5 August 2013 (UTC)

As I said, your idea of basic functionality and the devs' idea apparently differ. The devs seem to subscribe to the agile programming notion of many small "incomplete" deployments rather than one big "finished" one. What you've seen is consistent with that philosophy. Notice that I'm not claiming that this philosophy is popular with end users, only that what you are seeing is normal for developers that subscribe to this approach. As a person who is not afflicted with early adopter syndrome myself, I personally have more sympathy for your definition than for the devs', but this is entirely normal for this style. Whatamidoing (WMF) (talk) 18:30, 6 August 2013 (UTC)

Otherwise, to answer your points:

1. Advertisement has been made now that VE has been rolled out to everyone on enwiki, so even going back to opt-in, you would probably get many users opting in, but at least they would be warned that VE is alpha/beta and they need to check their edits. That's the main reason I'm among the users asking for "opt-in": so that people using VE are aware of it being alpha/beta, and so that we can reduce the number of articles being damaged daily.
2. The problem is that the staff already has hundreds of bug reports/enhancements to work on, and they can't keep up with the flow. So, what many are asking is that the staff takes care of that backlog before letting it be used by everybody, because the only way to make users aware of the current problems is to make them act themselves to activate VE before using it.
3. For 3, I've already answered above, and I'm baffled by this. --NicoV ^{(Talk on frwiki)} 21:06, 5 August 2013 (UTC)

1. Every VisualEditor user has received (or will receive, if they've never opened it) a warning about this. Until you acknowledge the warning, you are not permitted to do anything else in VisualEditor. If your actual goal is to warn the users, then it has already been met.
2. The devs have already resolved 70% of the bugs already reported, which suggests that they are keeping up with the flow. Also, if you're familiar with the agile programming philosophy, continuing to receive reports is important. Then you can discover unintended side effects. For example, VE users originally were massively, wildly more likely to use edit summaries than users of the classic wikitext editor, and now they're only significantly more likely. Something changed, but what? If you dump two hundred bug fixes on the system at once, you'll have no hope of figuring out which ones had that effect.
3. The original rollout would have given them a bit more than a week to deal with any truly major problems (e.g., VisualEditor simply does not work on the Chinese Wikipedia; by the way, there have been none in the projects that have enabled VisualEditor so far). Since major problems are usually obvious within minutes, if not hours, of general use, then a week is probably enough. Whatamidoing (WMF) (talk) 18:30, 6 August 2013 (UTC)

Well, in agile programming, there are several concepts: customer satisfaction (not achieved), welcome changing requirements (not achieved), working software (not achieved), close, daily cooperation between business people and developers (not achieved), minimal bugs (not achieved), ...

There are currently more than 700 open bugs for VE and 140 for Parsoid: how do you come to resolved 70% of the bugs and keeping up with the flow ?

If users have been warned, then it's not enough, because damaged articles are piling up. The problem is that the goal of Wikipedia is producing an encyclopedia, not becoming a testing platform as you seem to believe... --NicoV ^{(Talk on frwiki)} 19:39, 6 August 2013 (UTC)

Where is the most simplistic option for this discussion?

All I see is section after section of loaded questions. Where is the area to simply state that "Yes/No, Visual editor should be/not be enabled for new users and anonymous editors?" or simple Yes/No answers? The fact that the entire commenting thing is split into specific section only makes me wonder if the whole process is making it more difficult for honest answers and voting? --293.xx.xxx.xx (talk) 21:03, 2 August 2013 (UTC)

Well, it is a request for comment and not a "request for vote". That having been said, you can answer yes or no in the specific/corresponding section(s). I think this was a rather well organized RFC. Nothing is perfect, especially with the massive amount of people commenting and discussing. I don't really like that people have turned the main RFC page into a general discussion forum at the bottom, though. Killiondude (talk) 23:33, 2 August 2013 (UTC)

Well, they do ask for comment, and my comment is a simple Yes/No format, so at least some arrangement should be added in.--293.xx.xxx.xx (talk) 00:07, 3 August 2013 (UTC)

I suspect you meant the 'simplest' option, not the most 'simplistic' - well, I certainly hope that's what you meant! Yes/No formats are, by nature, far more loaded as they assume right and wrong answers. The objective here is to initiate dialogue. As it stands, many are already of the opinion that the questions posed are not only loaded but the wrong questions. Without the opportunity to engage in a discussion, the broader Wikipedia community would be entirely disempowered... which is not what RFC's are about. As it stands, if you don't want to comment, you are free to simply add an 'agree', 'disagree', 'support', etc. without explaining yourself. Cheers! --Iryna Harpy (talk) 04:53, 5 August 2013 (UTC)

About 2.1 Question syntax

2.1 Question 1: When a new account is created, should the preference be set to disable VE ("opt-in") or to enable VE ("opt-out")?

Should that read,

2.1 Question 1: When a new account is created, should the preference be set to disable VE ("opt-out") or to enable VE ("opt-in")?

As in opting out of the VisualEditor? Df2 (talk) 08:12, 3 August 2013 (UTC)

No, "opt-out" means you must choose if you wish to turn it off, e.g default is on. Adam Cuerden ^(talk) 10:44, 3 August 2013 (UTC)

I understand the confusion: You can read it as should the preference be set to disable VE ("the user must manually opt-in") or as should the preference be set to disable VE ("the user is already opted-in by default"). Whatamidoing (WMF) (talk) 22:22, 3 August 2013 (UTC)

Opt-in for experienced users

I propose adding the following question to the RFC: "Should users with technical flags (e.g. Autopatrolled, Rollbacker, Administrator) be able to opt-in rather than have to opt-out)? --Синкретик (talk) 09:37, 3 August 2013 (UTC)

This RFC is irrelevant

You are hopelessly naive if you don't think the Wikimedia Foundation won't ram the VisualEditor through against any editor objections.

That said, personally, I think it's a good thing. Wikipedia as has long needed stronger leadership to cut through its dysfunctional editor bureaucracy and make life better for ordinary users.

Yes, the VisualEditor is far far too slow, it has a few bugs and its UI has issues (e.g. its clunky UI for templates, especially references) but it's clearly a step forward. Well, as long as they don't reintroduce that ridiculous "edit" rollover. -Halo (talk) 06:44, 4 August 2013 (UTC)

Past experience is that if the community outrage goes beyond a certain point then the WMF will backtrack. So no people are not naive if they think that it is worth objecting. In the case of the visual editor a few months ago almost everyone wanted this and the criticism of the WMF was almost entirely over them being too slow to deliver a working visual editor. Things have changed, and there is now quite a bit of distrust of any sort of visual editor, but I suspect that the majority are still with me in wanting this providing the bugs can be fixed. Most of the current disagreement is over how many editors are needed to test something which still has bugs that were spotted three months ago. I'm in the zero camp as I see no point in testing until some major bugs are fixed, others argue for some level of ongoing testing and a number are very strongly asserting that they don't want to be forced into using V/E in the future. So the area of disagreement may not be where you think, as for the project needing strong leadership; Well that isn't any way to run a volunteer community, people have tried that model and it just doesn't work. Even if the Foundation had the money to offer a thousand or so editors jobs writing an encyclopaedia it wouldn't want to be legally responsible for what they write, and some of the best editors are volunteers who have no interest in turning their hobby into a paid job. ϢereSpielChequers 13:28, 4 August 2013 (UTC)

• This RFC is not irrelevant. As with any and all RFCs, not everyone will be happy about the direction that emerges; and there may be questions of disregarded consensus, but the RFC itself is the vehicle to have your collaborative input published if for posterity alone; and to me the damn fool is the one who decides to forgo his own right to be heard to spite his forgone conclusion that his voice is of no consequence. :) John Cline (talk) 13:51, 4 August 2013 (UTC)
• I also agree that the RFC is a good thing. Rarely do more than 500 editors show up to vote to do anything so to see more than 300 vote to oppose VE it shows that the community doesn't like it and the WMF needs to take that seriously. The WMF doesn't edit, so if they want to keep this a volunteer site then they need to listen to the community, not ignore us and expect us to clean up their mess. I agree with WereSpielChequers that the WMF couldn't make this project work without the volunteers and I agree that they need to stop ramming it down peoples throats with the argument its for testing purposes. I think the app has a lot of potential, but its far from being ready and all the WMF has done by forcing it out half finished and with major bugs is make it less likely the community will ever accept it. We are going to need to cut this RFC off at some point and submit a formal proposal to the WMF letting the know the result. What they choose to do will tell us a lot about what they think about the community.Kumioko (talk) 16:08, 4 August 2013 (UTC)
  • It isn't clear whether this RFC is asking about the current "beta" situation or all future "beta" versions, or the eventual model once Visual Editor is Fit for Purpose™? Who decides what would make it fit for purpose anyway: can we have an RFC on that? - Pointillist (talk) 16:30, 4 August 2013 (UTC)
    • I didn't want to muddle the RFC with questions about the future. There's a lot of things that may happen and a lot of people will have different opinions about what we should do depending on what happens. I focused the questions on what we should do now. If things change in the future, we can have another RFC about what to do at that time.—Kww(talk) 16:44, 4 August 2013 (UTC)
      • Thanks - Pointillist (talk) 16:56, 4 August 2013 (UTC)

IE users

Before you put this up for discussion, you should at least make it clear that IE users cannot participate. As we represent the majority of editors, I think it would have been in order to make it clear that the new editor was only available to those using certain browsers. I have been pressing for a WYSIWYG approach to Wiki editing for years but have always been bulldozed down by the hierarchy. Now it's here, I would have liked to have clearer instructions on how to access the beta version and explanations on why it is not available to IE users. Is this yet another Google venture?--Ipigott (talk) 21:50, 4 August 2013 (UTC)

No, it's nothing to do with Google - I use Firefox and up until I disabled the blighter, VE was functional for me. I do know that the structure of Internet Explorer is vastly different from the other common Web browsers (Chrome, Safari, Firefox) that're available, which may be why IE users can't use VE (i.e. it relies on something the other browsers have that IE does not). IANAP, however, so you'd have to ask clarification from the devs. —Jeremy v^_^v ^Bori! 22:20, 4 August 2013 (UTC)

They still can't get it to work right with IE. So they turned it off and it likely nothing below 8 will ever be usable. So that gives a couple of notes. First, all the problems so far identified are with browsers not used by the majority and once IE is supported, we are likely to see another large spike in bugs. Kumioko (talk) 00:19, 5 August 2013 (UTC)

According to Wikimedia, IE accounts for about 20% of non-mobile reader traffic [1]. That's still a significant amount, but your claim that IE accounts for anything like "the majority of editors" is likely wrong. Dragons flight (talk) 00:15, 5 August 2013 (UTC)

Maybe but I don't think the 20% number is accurate either. Kumioko (talk) 00:20, 5 August 2013 (UTC)

So, basically, we've returned to a serious fundamental problem being that, aside from being browser dependent, V/E is platform and OS dependent. I've already brought up the issue of backwards compliance after the 2013 Main Page Redesign Proposal RFC made it abundantly clear that many contributors don't have access to broadband, much less new computers. What versions of Chrome, Firefox, Safari, Opera, etc. are the minimum for being able to use V/E? It's fine to say that they'll still be able to edit at source level but the more elitist Wikipedia becomes, the less new contributors will feel welcome to be proactive. --Iryna Harpy (talk) 01:56, 5 August 2013 (UTC)

It's worse than just broadband. VE is pretty slow on anything but fairly high-end machines. Albeit getting somewhat better over time, as in, "unusable" changing to "theoretically usable, but still not a good idea" Adam Cuerden ^(talk) 11:22, 5 August 2013 (UTC)

The blacklist includes:

• all Internet Explorer; eventually, this will be only IE 8 and earlier. IE is notorious for having "creative" interpretations of web standards, and supporting it is a problem for everyone, not just the WMF. A bit less than 10% of editors use a semi-modern IE and will have access eventually. A bit less than that use old versions and will not have access ever.
• old Firefox, versions 14 and older
• old versions of Safari and Chrome
• old versions of Opera. Recent Opera (12 and newer?) are semi-supported: it is not blacklisted but not whitelisted, either, so users get a warning.

Old browsers are simply incapable of doing some of the things that need to be done. A 20-year-old web browser or OS is simply not capable of doing this. I don't know if there is an organized list of browsers, but if there are other browsers or specific versions of interest, I can ask. Whatamidoing (WMF) (talk) 19:37, 5 August 2013 (UTC)

Where exactly has anyone spoken about hugely old web browsers? XP and IE 7 still take up a significant enough chunk of the market for there to be a justification for running VE on slightly older stuff. VE shouldn't require super-powerful computers anyway, and yet it appears to at present. I've not seen any reason for the lack of Opera support given anywhere. The fact IE has "creative" interpretations of web standards is irrelevant; as a major web browser, the VE should not have been released until it supported it. People running IE are generally the sort of people the VE is supposed to attract, anyway; they're non-power users. That, and IE is the only browser with a stable, official 64-bit build, so some may use it for that reason. Lukeno94 (tell Luke off here) 20:34, 5 August 2013 (UTC)

IE is the only browser with a stable, official 64-bit build? You surprise me. I don't understand what is either unstable (in the everyday sense of the word) or "unofficial" about, say, Firefox 22 for Linux 64. (Actually I don't use this; I instead use the "Iceweasel" flavor, which is arguably even more "official", coming as it does directly from a Debian repository.) ¶ I presume that the lack of support for Opera is caused by this or that Opera-specific problem; have the developers of VE spurned offers of help to fix this? -- Hoary (talk) 00:51, 6 August 2013 (UTC)

No. Volunteer developers are welcome. In fact, I understand that the reason that Opera is now off the blacklist is because of a volunteer. Whatamidoing (WMF) (talk) 18:37, 6 August 2013 (UTC)

Whatamidoing (WMF), I'd suggest that none of us are asking about specific browsers for our own benefit but that of the entire Wikipedia demographic. I have no doubt that there are many, many valuable contributors who don't have the money for constant upgrades but do have invaluable knowledge. Knowledge is Wikipedia's greatest resource. The more Wikipedia does to exclude contributors based on their economic status, the more it will lose it's most valuable resource. Just looking at the comments by utter illiterates carrying on about how cool VE is is absolutely nauseating. There, I've said it: I'm an intellectual snob. Pandering to the dolts & further disempowering anyone who isn't privileged enough to be middle-American is not going to nurture this knowledge-base. I still feel that, in order to work on Wikipedia, it is essential to know some basic coding. If the name of the game is to attract quality over quantity contributors then developing methods of making people feel like second class citizens is a mistake. In an ideal world, a visual editor that really works for everyone would be a delight. This isn't an ideal world, nor is VE even close to being an ideal visual editor. I apologise if this sounds mean-spirited as I don't want to be mean about it. I know you and your colleagues have worked hard and are continuing to work hard on an ambitious project... but it's really not functioning well enough to have rolled out. If it's still Alpha, don't pretend it's Beta. --Iryna Harpy (talk) 01:21, 6 August 2013 (UTC)

Hisorically, Wikipedia has had a remarkably low penetration of IE users, and that is WMF's main argument for not rolling it out on IE at first. I actually suspect that works against them: I suspect the overlap of the "I use IE because I don't know how to install software on my PC" population and the "oooh, wikitext is too scary for me" population is quite large.—Kww(talk) 02:03, 6 August 2013 (UTC)

This is all very puzzling. I "have the money for constant upgrades", but I choose to spend it elsewhere, not least because my infrequent upgrades cost no money whatever. I've no idea what being American or not, let alone being middle-American or not, has to do with any of this. I thought that I should give VE a whirl, and read that To edit a page using VisualEditor, click on the "Edit^beta " tab at the top of the page (of an article or user page); but there's no such tab at the top or anywhere else, and the string "beta" appears nowhere in the page of an article (unless of course the article itself includes it). (Maybe I've failed some intelligence shibboleth.) I've never encountered anyone who's said "I use IE because I don't know how to install software on my PC"; I have encountered plenty of people who say variations on (a) "Yes I have an internet. What do you mean, 'Internet Explorer'?" or (b) "I have to use Internet Explorer because the batshit 'security' obsession of the IT people in my company prevents me from installing any alternative." -- Hoary (talk) 02:16, 6 August 2013 (UTC) PS the IQ test I failed was related to RTFM. My "skin" was Cologne Blue; when I changed it to Vector, I successfully used VE with both Iceweasel (not the latest version) and Chromium (thereby incidentally disproving the assertion in WP:VisualEditor that VisualEditor currently works only in the most modern versions of Firefox, Chrome and Safari). -- Hoary (talk) 09:48, 6 August 2013 (UTC)

Your rant has been directed at... whom, precisely, Hoary? You've taken snippets out of a couple of comments and made kovbasa out of them. Perhaps you could start again & make a little effort at actually making coherent a point. Is your point that you edit on IE at work (you're a bad person) and that you can't use VE because IE is the only browser you have access to. Maybe you should start actually doing your 'work' at 'work', or do they pay you for 'attendance' & the pleasure of your using their equipment & broadband for your personal development? --Iryna Harpy (talk) 06:27, 6 August 2013 (UTC)

(i) What "rant"? (ii) I do not edit on IE at work or anywhere else. (iii) When I edit at work (which is rare), I normally do so on Iceweasel. (iv) Thank you for your concern for my employer's return on its investment in me. (v) My point is that a number of the assertions and assumptions above are bizarre. Among these: Wikipedia excludes contributors by economic status; a significant number of the browsers still in use are 20 years old; "IE is the only browser with a stable, official 64-bit build"; the reason why people don't add an alternative to IE is that doing so seems/is too difficult; some of the comments on this matter have been by "utter illiterates"; upgrading software costs money. -- Hoary (talk) 07:27, 6 August 2013 (UTC)

• I was referring to Windows builds with my 64-bit comment, as Windows is the predominant OS. There are surely more people using IE on Windows XP than those using Firefox on Linux. I run Chrome on Windows 7, so this doesn't affect me; nevertheless, it potentially would have affected me at my old school, which still ran XP, and some of the machines were stuck on IE7. Lukeno94 (tell Luke off here) 08:08, 6 August 2013 (UTC)

• Yes, what you say is true. Incidentally, I'm very willing to believe that I move in very atypical circles, but I do move in more than one of them, and in these circles OS X is about as widely used as Windows. So although Linux isn't a predominant OS, I start to wonder if OS X might be. -- Hoary (talk) 09:43, 6 August 2013 (UTC)

• Mac OS X is definitely widespread enough, and stable enough, for it to be a factor. Linux is a bit more tricky; there are so many different versions of it, and it's not at the same level as Mac OS X or Windows. Also an interesting question; I wonder how VE would run on a Chromebook? Lukeno94 (tell Luke off here) 18:42, 6 August 2013 (UTC)

• Relatively few of our users have IE8 or older. Given the fact that support is going away for IE8 soon, this number will be falling even further. Nobody ever promised that this JavaScript-based editor would work for every single user. For example, if your web browser is 20 years old, then I guarantee that it won't work, because your web browser is older than JavaScript.
• Given the uptake at the Spanish Wikipedia, which draws a lot of users from South and Central America, I don't believe that the evidence supports the belief that only wealthy users get VisualEditor.
• I'm a little mystified by the solution favored by some people here. VisualEditor is temporarily not available to IE9 and IE10 users. IE has gone on and off the blacklist over the last year; it was most recently re-added to the blacklist when user testing in June proved that it wasn't working (e.g., Template:Bug, in which IE users can't save a page because of one of IE's non-standard quirks). So it's currently not available for about 10% of our users because the users have IE9 or IE10, and they are working on changing VisualEditor to work around IE's quirks. But the proposed "solution" to this gap—this temporary unavailability to a small group of editors—seems to be to take the product away from the 80% of users who don't use any version of IE, until the IE fixes are in place again (in a few weeks). This idea that taking it away from everybody will make it available for more people does not seem logical to me. Whatamidoing (WMF) (talk) 19:12, 6 August 2013 (UTC)

• Stop making the absurd comments about 20-year-old web browsers. We're talking about IE 7/IE 8 and Windows XP here, which are still being used by enough people for them to be taken into consideration. Also, people on IE are rarely "power users", and isn't the whole point of VE to enable "non-power users" to edit? It's nothing to do with wealth whatsoever; anyone can pirate an OS. VE should not have been released without support for the latest version of IE, and blaming the quirks of IE doesn't change that fact. Besides, if you'd waited until it worked with IE, then you'd have had a much more stable, feature complete version of the editor, and it would've been more of a success... Lukeno94 (tell Luke off here) 19:24, 6 August 2013 (UTC)

Why exactly should IE's problems hold back everyone else? Is it truly important to you that every user have exactly the same access at the same time? I believe that IE7 represents less than 2% of Wikipedia users, which is not IMO a really sizable group. Would you block everyone else over one or two percent? If so, then why aren't mobile users, which represent a dramatically larger group, on your list of groups to worry about? Whatamidoing (WMF) (talk) 19:39, 6 August 2013 (UTC)

For gawd's sake, this "20 year old browser" catchphrase really has the political spin-doctor in you running riot. No one has mentioned anything about a preference for Word Perfect as their preferred word processor... and seriously suspect the average older contributor/editor doesn't send off to the MP3 PRO club for for their cracked software. There are a lot of people who don't run 64-bit OS's simply because their favourite programs & 3rd party plugins are only 32-bit compatible. In itself, that's irrelevant as people are going to have to move along whether they prefer to or not. What IS relevant is that what you're doing is working on the assumption that the inevitable is here & now and that V/E is capable of accommodating enough platforms, OS's & browsers to be backwards compliant within reason & to be able to keep up with advents in the future. Seriously? You haven't even managed to debug it enough to get past Alpha phase & you've rolled it out as a Beta system when it can't handle anything beyond the most simple tasks. And you're seriously expecting that there should be any vote of confidence when, in its present state, it's caused a furore. The Tearoom has asked for assistance in handling the queries about the system because they don't know their way around it themselves. The Village Pump is about to explode and I'm still getting <nowiki> markups just editing pages that contain anything other than straightforward text (god forbid that there be an image floated left for aesthetic purposes because you can't get to the wrapped text underneath that div). Take a look at the RFC page. If that isn't a vote of no confidence in your brilliant system, I don't know what is. The articles look like abortions absolutely dripping with edit source/edit beta/edit me yellow and call me a banana tabs at every subsection when V/E doesn't edit subsections. I've been having nightmares about it and, unlike you, I don't even get paid to have nightmares about it. — Preceding unsigned comment added by Iryna Harpy (talk • contribs)

• From Template:Bug it isn't clear what "IE's non-standard quirk" (per Whatamidoing (WMF)) is. I'm not a MS-apologist (mainly use Chrome myself) but IMO you need to be careful about making "non-standard" claims without taking a look at the other side of the coin. Is this in fact a situation where IE doesn't follow W3C technical recommendations, or is because there's some security thing—that no-one has standardized—where IE is giving the user more protection than the other browsers? Maybe that's why corporates stick with IE? The headline "Wikipedia wants editors to lower their security" probably isn't what we need right now. - Pointillist (talk) 22:29, 6 August 2013 (UTC)

  I believe that a brief inquiry at your favorite web search engine will remove any lingering concerns you might have about IE being more secure than other web browsers, especially if you specifically ask it about IE7, which Luke specifically called out as important in his opinion. Major websites like Gmail and Google Docs stopped supporting IE7 two years ago. In fact, anyone who wants to use HTML5 has stopped supporting IE7, because IE7 can't do HTML5. A lack of support for IE7 is normal and increasingly expected. The two typical policies are to drop support for any browser (assuming it requires special efforts) either when it is the third-oldest browser from the company (so support IE9 and 10, but not IE8, and support Firefox 22 and 21, but not 20) or when it reaches a tiny fraction of your traffic. IE7, at latest count, is responsible for only ~1.5% of desktop/laptop traffic at all WMF websites (it is probably slightly less here), and dropping steadily. In contrast, mobile editing (tablets and smartphones) is rising rapidly. Whatamidoing (WMF) (talk) 18:06, 7 August 2013 (UTC)

  I'm perfectly comfortable with the principle that major new functionality requires an up-to-date browser (sorry, Lukeno94!). IE6+7+8 use on wikimedia is now down to 6.66% so I can't see any problem excluding them from Visual Editor. I wouldn't even mind excluding IE9 (4.04% used) on the basis that IE11 will be out soon. So we agree almost completely. I'm just questioning whether there's really a W3C standard that applies to Template:Bug. I suspect it's more like Chrome/FF do it one way, and IE does it another way, there's no right or wrong. I didn't mean to imply that in general IE gives users more security than other browsers, just that perhaps on this occasion IE is enforcing more/different security, because of their focus on corporate use. - Pointillist (talk) 11:29, 9 August 2013 (UTC)

• 6.66% is still a HUGE amount of people. Add in IE9, and that's 10%. Considering that VE is aimed at the non power-users, and those are more likely to be using older browsers (or any version of IE)... Lukeno94 (tell Luke off here) 11:33, 9 August 2013 (UTC)

• I do understand your point. I can see the challenge, and I appreciate that non power-users are less likely to upgrade their machines, and some people won't feel comfortable switching browsers from IE to FF or Chrome. But it's also an opportunity to persuade people that the effort is worthwhile and pretty much inevitable if they want to get the most out of the web in future. - Pointillist (talk) 12:01, 9 August 2013 (UTC)

• That's an absurd suggestion! Wikipedia shouldn't be cherry-picking browsers or users, and it certainly shouldn't be promoting any. We're talking about 10% of the viewers of Wikipedia here - even 1% is a big enough amount of people for their browsers to need accommodating. At the moment, it must be nearer 20-30% of all users who can't use VE, when you take into account Opera, the other versions of IE, and some other, smaller browsers. Lukeno94 (tell Luke off here) 12:23, 9 August 2013 (UTC)

• Well, I respect your position. All the best - Pointillist (talk) 13:50, 9 August 2013 (UTC)

Ending support for IE 8

Microsoft has already sounded the death knell for the idea of being forced to use old versions of IE at work:

• Windows XP support ceases on 8th April 2014 ([2]). Microsoft says "Continuing to run Windows XP SP3 in your environment after April 8, 2014 exposes your company to potential security risks, as unsupported and unpatched environments are vulnerable to security threats." (here). So corporates who have stuck with XP will have to upgrade their desktop OS to one that supports the newer versions of IE that the VE requires.
• Likewise, Office 365 will cease to support IE8 on 8th April 2014. They say "Internet Explorer 8 doesn’t support any of the innovations made over the past five years. To deliver the kind of rich mobile and touch experiences that users expect today, Office 365 needs to focus our innovation on modern browsers such as Internet Explorer 10." (here).
• In their service alert email to customers, they say "Office 365 now requires the following software: The current or immediately prior version of Internet Explorer; or the latest release of Chrome, Firefox, or Safari." As I read it, this is telling a major segment of their business users that they should be running a modern browser – I expect IE11 will come out at the same time as Windows 8.1 so according to the Office 365 definition of “the current or immediately prior version of Internet Explorer” even IE9 will be out of scope.

On this basis the VE team's decision not to support IE8 doesn't exclude any class of editor. Either you're a corporate who mandates the use of IE because it supports Group Policy, or you're a home user/small business. If you're a corporate you've got to upgrade your OS anyway. If you don't need to worry about group policy, you can either switch browser for free (e.g. Firefox 22 supports XP SP2) or upgrade your OS for $$$. Either way, you'll still be able to use VE once the team releases it for IE9+. - Pointillist (talk) 07:46, 6 August 2013 (UTC)

• If you were a very daring home user or small business, you might even change your OS for zero $$$. Firefox 22 runs under Linux as well. -- Hoary (talk) 07:56, 6 August 2013 (UTC)

  That's an important point – thanks for mentioning it. It's installed by default in Ubuntu, for example. - Pointillist (talk) 08:01, 6 August 2013 (UTC)

• BTW, if anyone's interested in the projected support for odd browsers, mw:VisualEditor/Target browser matrix (warning: user data is a year old) has some predictions. In general, anything that fails to have both an HTML5 feature called contentEditable and robust, standards-compliant JavaScript cannot handle VisualEditor. As usual, if we know that a certain browser is incapable of running VisualEditor (or anything else), then we'll 'blacklist' the browser and the user will get exactly the same user experience that everyone had last year: one editing environment that uses wikitext. Whatamidoing (WMF) (talk) 20:08, 8 August 2013 (UTC)

Thanks for linking to the old target browser matrix page, I hadn't seen it before. It's interesting, but horribly flawed:

• The data in that table is nearly a year old. There's newer data at [3] but apparently these statistics have been generated from "old, buggy" scripts.
• The vast majority of events in the stats are GET (i.e. reading articles). In June 2013, the GETs were 97.8% of the statistics (source). We need to know which browsers are being used for editing, not which browsers are being used for reading. They might be the same, but without the detailed data we can't be sure of that.
• Anyway, counting GETs at the Squid level probably doesn't reflect the effect of downstream caches. If IE is predominantly used by corporates, the IE stats might be lower because corporates' network gateways have much bigger/smarter caches than home broadband routers.

I don't have any problem with the VE team deciding to support only IE9 and above, but I am a bit surprised to see such misleading data being used to make—or at least defend—such important decisions. It's not as if the WMF lacks sufficient resources to do proper data collection and analysis. - Pointillist (talk) 23:14, 8 August 2013 (UTC)

@Pointillist: The data hasn't been updated since the data was last deemed accurate, that's true; I'm looking forward to the data being updated and improved, and particularly a cut of the data for current editors (as you say, this would be informative - though I'd caution that this would skew decisions based on the data in favour of things that support people who are already editors, rather than the pool of likely contributors, or that of potential ones). I'd note BTW that the decision to not attempt to support IE8 was made in early 2012 based on technical competence of IE, not on usage. Jdforrester (WMF) (talk) 01:43, 9 August 2013 (UTC)

Entirely agree about the "current" vs "likely" mismatch—even the best stats can't measure people's future behavior. The good news is that use of IE6/7/8 on wikimedia has fallen sharply since last year: it was 11.82% in the Sept 2012 matrix whereas this June it was only 6.66%. Those are the people who'll need to switch browser or upgrade their OS if they want to use VE. - Pointillist (talk) 09:32, 9 August 2013 (UTC)

I've heard—and I don't know if it's accurate—that readers are more likely to use IE than editors. Whatamidoing (WMF) (talk) 17:13, 9 August 2013 (UTC)

However, the VE development aims to address the needs of the casual, non-nerdy, non-computer native, not-yet wikipedia editor. So the VE fails specifically for a relevant portion of its intended audience.-----<)kmk(>--- (talk) 19:48, 10 August 2013 (UTC)

Not sure what you mean by "casual"? - Pointillist (talk) 09:38, 12 August 2013 (UTC)

The share of supported browsers in the target browser matrix is a little over 53%. Numbers may have shifted since last year. But there certainly was no land slide toward the most recent browser versions. So the visual editor fails for about 1/3 of all use cases. This in itself is a major bug. It makes the wikipedia experience rather inconsistent.-----<)kmk(>--- (talk) 19:38, 10 August 2013 (UTC)

It's apparently shifted more than you expected. Also, some of the browsers "work" but aren't "fully supported" at this time. Opera is in that class, and the work of a volunteer dev has changed it from the "no" category to the "yes" category. At the moment, the best estimate is that VisualEditor option appears on approximately five out of six articles (pageviews). Whatamidoing (WMF) (talk) 05:21, 12 August 2013 (UTC)

• I'm calling rubbish on that estimate. The three or four latest versions IE on their own will form about 15-20% of the views, then there's all the views from mobile devices, and the slightly-older web browsers that the WMF have pretended don't exist... Lukeno94 (tell Luke off here) 07:21, 12 August 2013 (UTC)

My hat's off to the dexterity and patience of people who manage to make lucid and substantial contributions via phones and tablets. I don't normally use Chrome on mine, but now that I do try to use Chrome (for Android) I see that yes I am able to use VE via Chrome (for Android). Which are the slightly older web browsers that the WMF have pretended don't exist? -- Hoary (talk) 12:41, 12 August 2013 (UTC)

We've had a few bug reports from tablet users, so obviously they are getting the option to use VisualEditor. I don't recall seeing any from mobile phone users myself, but presumably it's similarly possible.

Luke, this is based on pageviews, not on users. IE makes up about 20% of users; it does not make up 20% of page views. I guess that IE users spend less time reading Wikipedia than people with more modern computing resources. Whatamidoing (WMF) (talk) 16:50, 12 August 2013 (UTC)

Should anyone care, VE worked fine for me in Safari on iOS 7 (iPod touch 5th gen). Except for the fact that it's always annoying "clicking" fiddly links with my fingers, of course. Ignatzmice•talk 18:12, 12 August 2013 (UTC)

Moving misc. discussion

Hi. Can most of the stuff at WP:VE/RFC#Related discussions be moved to this talk page? The page is cumbersome to load and follow without every person thinking they need a whole new subsection dedicated to their comments. Killiondude (talk) 22:38, 5 August 2013 (UTC)

I'd second that but am not familiar enough with the RFC process and the rules, if any, involved with maintenance tasks such as moving those discussions to this page. As there are quite a few would that all get appended to the bottom of this page? Should they be replaced with links to the discussion on this page? --Marc Kupper|talk 20:06, 6 August 2013 (UTC)

problem with numbered votes in opt-out for question 1

I added my vote to the opt-out section of the first question, at the very end of this, but it restarted the numbering at 1. I think it has something to do with the comment of the humble editor above me, but I don't know exactly what the problem is or how to fix it. Any ideas? Thanks! AgnosticAphid talk 06:16, 6 August 2013 (UTC)

Fixed. --NicoV ^{(Talk on frwiki)} 06:48, 6 August 2013 (UTC)

Hey, thanks. Those are some strange nowiki tags on that page you posted! But I think the problem is that whoever that was accidentally didn't select the whole name when they made the intra-wiki link, and then the VE added a nowiki tag because if you add a single letter to the end of a link, like "[[thi]]s" it would ordinarily show up as part of the link, like this. So VE was just trying to preserve the mistaken edit! I mean, they probably meant to link [[Dostoievski]] rather than [[Dostoievsk]]i. So it seems like more of a typo than a bug to me, personally. I do know there are actual problems with tables, though! AgnosticAphid talk 07:02, 6 August 2013 (UTC)

Yes, it was accidental but VE behaviour is surely not what the editor intended to do. An other possibility for this is that the user tried a spelling, and when he added the link he saw that the spelling was wrong so he fixed the spelling just after adding the link. There are a lot of other situations where VE add nowiki tags (see abuse filter 550 which is still triggered several hundred times a day) which are not intended by the user, or that VE trashes an article (tables, ...). There's also the possibility to delete a template without intending to and being aware that you did it. It's all these problems that make me vote for opt-in because a novice won't know that garbage has been added to the article. --NicoV ^{(Talk on frwiki)} 09:24, 6 August 2013 (UTC)

Changing the user preference label

Hi. I've begun a discussion at MediaWiki talk:Visualeditor-preference-betatempdisable#Changing this message to discuss whether we should change the user preference label that completely disables VisualEditor. Please participate there. --MZMcBride (talk) 06:53, 6 August 2013 (UTC)

Comment on the process

Generally when a topic is under discussion people are discouraged from making significant changes to the topic until the discussion is concluded. In this case, the RFC was started July 30 01:24^[4] and at 2 August 2013 05:22 the developers rolled out Wikipedia:VisualEditor/Updates/August 1, 2013 to this site. It appears many of the changes in this rollout were in response to early feedback on the RFC.

While it's great that there was a near immediate response from the software developers it also means that some of the questions in the RFC are no longer valid as they are about VE's behavior in July.

Should the RFC be kept open?

There's a secondary issue which is I found the July version of VE to be so disruptive that I had disabled it. I see from the RFC comments that many others had also disabled VE for the same reason I had. I learned about the August update when reading the RFC comments, re-enabled VE, and have left it enabled. Should a site-notice go out to editors that still have VE disabled about the August update? --Marc Kupper|talk 20:04, 6 August 2013 (UTC)

I think the whole process is correct. By enabling the VE to a wider audience, there is A, more feedback and B, more motivation of others to provide input/help with development (it is, after all, open source, and its more interesting for many developers to work on a popular application than on some test program which might never even be used). So the wider deployment of the VE in fact accelerates its development, and I therefore guess that soon all 'major' issues will be solved. I'd say its a post modern kind of process :) -- Stratoprutser (talk) 21:59, 6 August 2013 (UTC)

Some of the more important problems are difficult to solve and will take a while, but I am looking forward to the next update, which might happen as early as 15 August. Among other things, it is supposed to halve the "nowiki" problem (which has already declined substantially during the last month). Whatamidoing (WMF) (talk) 18:10, 7 August 2013 (UTC)

Further reading

There's a raucous but very informative (and very long) thread about the VE introduction and the problems with it on Wikipediocracy (a site dedicated to critiquing (or perhaps destroying) all things Wikipedian). A few of the folks posting to the thread are in the software development industry, and their views on this release might help put this in context a bit. It's a very long forum thread, but probably not quite as long as the RfC. --SB_Johnny | ^talk✌ 23:02, 6 August 2013 (UTC)

Cheers for the link. Distinctly illuminating! --Iryna Harpy (talk) 22:46, 7 August 2013 (UTC)

Page length

At time of writing, the RFC page stands at nearly 850,000 bytes (850kB) and growing. Would this make it the longest page ever on Wikipedia?

On a serious note though, the RFC should be closed soon, or the page size will grow towards an unacceptable level. Insulam Simia (talk) 12:23, 7 August 2013 (UTC)

The page is already beyond critical mass (about 500K for some browsers). I do also agree its time for this RFC to close and the WMF to act on consensus. Kumioko (talk) 20:38, 7 August 2013 (UTC)

This RFC was opened 30 July. After 7 days, one would expect everyone with an opinion on this matter has spoken. I doubt any further light or insight will come into this discussion. -- llywrch (talk) 21:26, 7 August 2013 (UTC)

Its time to present this to the WMF for action

Now that we have an RFC which shows the WMF clerly what the consenus for how to deal with Visual Editor its time someone presents it to them for action. Hundreds of people voted in this RFC which is, in and of itself, a sign that Visual Editor has caught people attention. The community clearly feels that VE needs to be disabled to opt in only and a variety of other changes until it is fixed and working. Excuse my rather blunt tone here, because it should have never came to this in the first place but its time for the WMF to step up and do as consensus reflects. Kumioko (talk) 20:36, 7 August 2013 (UTC)

I seriously doubt that anything can be done before the developers have returned from Wikimania. There is a code freeze in effect until August 15th.

I have no opinion on whether this should be closed, or left open for other people, or split into subpages, or anything else. However, if you wanted to help speed the process along, then you might help find a team of experienced, uninvolved admins to formally close it. If the decision makers have to find time to read through 850K of comments and figure out which ones pre-date James F's proposal and might be addressed by those changes, then the decision will necessarily be delayed by however many hours that takes them. Whatamidoing (WMF) (talk) 22:43, 7 August 2013 (UTC)

I agree we may as well keep it going until after Wikimania and that it might take a while to read through. Kumioko (talk) 23:29, 7 August 2013 (UTC)

Certainly you aren't suggesting that all votes from before the edit buttons were swapped out should be discarded, are you, Whatamidoing (WMF)? Everything James has done was relevant only to question 4, and they pretty unambiguously satisfied the demand to "Explicitly warn that it is beta software". It was irrelevant to the other questions. Ratios like 465/110, 254/57, and 179/46 are pretty unambiguous. Only questions 2.5 and 5 have any judgment calls. —Kww(talk) 03:04, 9 August 2013 (UTC)

I don't think that anything should be discarded wholesale. However, a thoughtful close will consider the comments that a person made and not just the "vote", and it will consider which people's suggestions or comments have been addressed on individual questions. Whatamidoing (WMF) (talk) 17:01, 9 August 2013 (UTC)

• Agreed, present to the WMF for action. N2e (talk) 13:40, 9 August 2013 (UTC)

• RFCs typically last thirty days. This would mean that this discussion (or vote) would end on August 29 or August 30, I believe.
  RFCs also typically have a formal closing. This requires an established user (admin or otherwise) reading through the discussion and writing a closing statement. As WhatamIdoing suggests, a group of users closing this RFC may make sense here. --MZMcBride (talk) 21:07, 12 August 2013 (UTC)

• You don't think WP:SNOW applies to this one, MZMcBride? The problem with your approach is that if we wait another two weeks to start some formal multi-admin close, by the time we are done, Erik is going to claim that he's done so much since the RFC started that he no longer views the RFC results as valid, meaning we would need to do this over again, and every time we came to the close, the results would be rejected due to age. There's such an intensely lopsided result here that there's no benefit in waiting, and every day we wait is another day that the software is misconfigured to enable VE by default to new editor and IPs.—Kww(talk) 01:21, 16 August 2013 (UTC)
  • My only thought at this point is that I'm too involved to have an objective opinion on this RFC or any discussion or decision related to it. :-) --MZMcBride (talk) 03:13, 16 August 2013 (UTC)

• I think this RfC has run its main course. I haven't noticed any new sections or what not popping up lately. Command and Conquer Expert! ^{speak to me...}_{review me...} 22:40, 12 August 2013 (UTC)

• I completely agree and I think we need someone to lose this out and submit it to the WMF. I believe its probable they will tell us that we cannot tell them what to do, which has been the basic argument from day one. But I think we at least need to show the that the community has come to a consensus about some issues pertaining to Visual editor. They can choose to follow the consensus of the community or continue to spit in the communities face. Kumioko (talk) 03:39, 16 August 2013 (UTC)
• Agree also. I don't know how to close a RFC on enwiki, so I will let other people do it. The result of the RFC is pretty clear, at least for questions 1, 2 and 3. To me it doesn't seem that anything that has happened since the beginning of this RFC should change much in the votes (a lot of votes are explained by the beta status). We'll see if WMF will keep disregarding the community or if they finally decide to work more closely with contributors. --NicoV ^{(Talk on frwiki)} 17:02, 17 August 2013 (UTC)
• I know how to close it but I think an argument could reasonably be made, based on my comments and activity, that I am too involved. I am going to request an uninvolved admin to stop by and see if anyone is willing. If no one is willing I will try and find time later in the week. Kumioko (talk) 01:02, 18 August 2013 (UTC)

  A request was made at AN here but does not seem to have attracted much attention. My guess is that with so many people on vacation this time of year, there just weren't many people willing to do the entire thing by themselves. One way to reduce the workload is to find a team, rather than dumping everything on one person. Three is typical for an RFC of this size, although one per 'question' and someone else for the additional proposals is another option that might work here. WhatamIdoing (talk) 01:08, 18 August 2013 (UTC)

  • Thank you I hadn't noticed that. I just left a note for Arbcom to consider drafting the results for submission to the WMF. The request can be seen here. I admit its a little outside the scope of the Arbcom but as the defacto legal body for Wikipedia and the intermediary between the WMF and the community, it seemed reasonable that they should do it since it pertains to a WMF decision. We'll see what they say. Otherwise I don't mind helping on it but as I said above I believe it would open the door for debate because I have been so vocally opposed to several aspects of VE. Kumioko (talk) 01:23, 18 August 2013 (UTC)
    • As expected the Arbcom has declined to get involved so I guess we need a couple folks to close this out and submit the results. Any takers? It doesn't require an admin but someone with some experience with RFC's would be good. Kumioko (talk) 15:23, 27 August 2013 (UTC)
    • I submited for the RFC to be closed here. If no one bites in the next few days I'll probably draft something up and then post something here for review. Kumioko (talk) 15:32, 27 August 2013 (UTC)

Wikimedia response

In response to this RfC, some thoughts from me on next steps:

Context

Firstly, I want to make clear what the Wikimedia Foundation's position is with regard to RfCs, votes, polls, and other more formal community discussions which take place on the Wikimedia projects concerning software development.

The Wikimedia movement is a complex, symbiotic interplay between many entities within it, each with their own priorities and areas of expertise. The Wikimedia community – without which Wikipedia, the other Wikimedia projects, and the Wikimedia Foundation would not exist – makes virtually all day-to-day decisions in areas of content, and has particular expertise there.

Similarly, the Wikimedia Foundation does the bulk of the work of evolving the technical platform that underpins the projects. Our work is done in an open source manner, with many volunteers and third parties contributing. Most of the time, this process is entirely uncontroversial: bugs are fixed, features are added (such as mobile editing, or mobile uploads) that pose some challenges but are, overall, smoothly adopted. Most requests from the community are, similarly, uncontroversial, and quickly met if there are no technical or principled reasons not to meet them. New changes are rolled out each week, and issues are sorted as they arise.

All features and fixes, however, are evaluated in a way that is in line with the movement's relationships. A basic hurdle is engineering: is the proposed fix technically possible? Other factors include whether the feature is in line with our goals as an organisation, or the goals of the movement. Community concerns are factored in, as are the concerns of our Product department, and quantitative and qualitative data is brought into play if it is available. This combination means that decisions around what to deploy, when, and where, are complex. The only way to resolve conflicts within them is through negotiation and mutual recognition that we have shared ownership of the projects: that no single concern or party, be it engineering difficulty or community concerns, be it the Foundation or the volunteers who make up the projects, can come into play unilaterally. We have to work in partnership, and cannot do so if debates are framed as being between one side "demanding" something, or another side "imposing" something. Discussions are complicated by the fact that WMF is hierarchically organised, and so can speak quickly and with one voice, while the community generally looks for broad consensus that takes time to build and interpret. This necessitates trust and assuming good faith.

So, simply put, we do not blindly follow the community's position on technical matters, whether it's expressed in RfCs or other discussion formats – but equally, we do not blindly follow what we think is "right", ignoring the community's thoughts, concerns and suggestions. Instead, we try to advance shared interests as best we can, with an appreciation that feature deployments are complex, and that the decisions we make around them have to include all the factors mentioned above.

Impact of VisualEditor's opt-out beta release

In this case, we are talking about VisualEditor's release as an opt-out (rather than opt-in) beta at the English Wikipedia.

From an engineering perspective, while much work still needs to be done, the software is workable; it did not cause site-wide problems of the kind that would have made us disable it, and almost all of the page corruption issues are now fixed. From the point of view of the Foundation goals and the movement goals, it is fully within scope: we exist to allow for the creation and spread of knowledge, and VisualEditor enables that process. This is something recognised by both the Foundation and the community in the Wikimedia Foundation Guiding Principles.

From a community perspective, however, the beta had a huge, transformative impact on user experience. We have no qualms about apologising for this. It should have been ramped up more gradually to reduce the disruption and catch particularly problematic bugs before they could cause damage on a larger scale. As an engineering organisation, we try to advance our platform quickly by "releasing early and releasing often", but in this case we made a mistake, and we shouldn't have ramped-up with the VisualEditor as quickly as we did.

The data we have provides us with both positive and negative points about VisualEditor. One thing we have noticed, which we feel is beneficial, is that users are 6 times more likely to use edit summaries than with the markup editor – though earlier in VisualEditor's development it was more than 10 times more likely, and we're investigating what led to the shift. We've also heard a lot of qualitative feedback from users, new and old, that indicates the VisualEditor is a better interface for making small changes to content, or a better interface full stop. Some manual spot reviews of changes made with VisualEditor has shown that, though there are some issues, only a very few edits result in broken content or mistakes, and of course errors due to misunderstanding wikitext do not occur. At the same time, there are some indications that people using VisualEditor are, for whatever reason, slightly more likely to be reverted. It's a mixed bag.

Changes made mid-RfC and possible future changes

In acknowledgement of this, while the RfC was underway, we made several important changes to the user interface on English Wikipedia:

• We made the "Edit source" link the first link both in the set of tabs, and in the set of section edit links.
• We added the "beta" label to all links that point to VisualEditor.
• We disabled the animation on section edit links.
• We added a message that is displayed to VisualEditor users when they first use it. The message currently reads as follows: "This is our new, easier way to edit. It's still in beta, which means you might find parts of the page you can't edit, or encounter issues that need to be fixed. We encourage you to review your changes, and we welcome reports about any issues you might encounter in using VisualEditor (click the 'beta' button to submit feedback). You can keep using the wikitext editor by clicking the "Edit source" tab instead – unsaved changes will be lost."

These changes are described in more detail here.

The purpose of these changes was to make it clearer to users that VisualEditor is still beta software, and to enable them to use the source editor easily. This worked; since these changes have been implemented, VisualEditor peak usage has roughly halved, dropping from about 700 edits/hour to about 350 edits/hour, and for logged-out users from about 400 edits/hour to about 180 edits/hour. See the general VisualEditor metrics dashboard for these and other statistics. In making these changes, we have achieved our intended effect of lessening the burden on the English Wikipedia of beta software (which can still sometimes cause significant issues) being prominently available in the interface. Naturally, we have also fixed hundreds of bugs, improved performance and added new features since the July beta roll-out.

Difficulty of an "opt-in" release

We understand that the RfC is asking for VisualEditor to be a preference which has to explicitly turned on in order to become available. Our concern with this approach is that a preference available to registered users will skew VisualEditor towards use by experienced users only, and that overall usage will likely remain very low.

In order to develop and improve VisualEditor during its "beta" period, we need to understand the impact of changes on a day-to-day basis in real-world conditions. This helps us make the software better quickly, and understand the concerns of different user groups. A good example is the edit summary change noted above; it went from 10 times as likely to 6. Seeing these kinds of drops and increases helps us see the impact of seemingly innocuous software changes, and roll back or improve changes to the software that cause harm. We can look at diffs of edits by logged-out, newly-registered and other kinds of user and understand from looking at their changes exactly where they struggle and how we can help them. This is evident on the feedback pages as well, where experienced users often analyse the changes made by new users and help explain what likely went wrong.

This has very near-term significance for us in the development of VisualEditor. For example, one of the near-term areas of improvement we are working on is the dialog for references. Right now, it's just a simple text box, without built-in support for citation templates except through VisualEditor's normal template features. We intend to implement a workflow dialog which lets each wiki configure their preferred primary citation templates, and to expose them as "quick-add" tools through the user interface. As we deploy and improve it "in production", we can quantify whether the number of citations by different user groups (logged-out, new, experienced, etc.) goes up or down. Building this in a vacuum of what we think will work – or even what the consensus of experienced editors thinks will work – generally guarantees something that doesn't, in fact, work at all well. Continually improving and optimising in the real world based on data and feedback is the path to making a great product.

Next steps

We realise that, given the outcome of the RfC, many community members may feel that the changes already implemented, and those that we propose to do in the next few weeks, do not go far enough. However, we'd like to make the case that having the VisualEditor beta within reach for all users, without the need to flip a switch, will lead to a better product in a shorter amount of time, because it will get more real-world usage. We believe that working in partnership with the changes we've already made should be possible, and we hope that you'll agree that this is a reasonable approach. We're prepared to make further changes, such as simpler opt-outs (coupled with easier opt-ins with targeted calls-to-action to ensure appropriate participation); there are some preliminary sketches of what this might look like which we'd be happy to work up if that seems sensible.

I'd appreciate your comments on the near-term and possible mid-term changes to the beta. Below, I've suggested a number of changes we could make that I think might adjust the experience of VisualEditor in ways that might meet the objectives of all of us. We're open to other possibilities, and of course to discussing the details of either implementation, but we want to make clear upfront that these are options that are workable from our perspective. Following the principle of shared stewardship, we ask you to consider our arguments, as well, before making up your mind. We hope you can see that we're listening, and looking for a way forward that enables the beta to continue with reasonable and representative levels of usage, while taking all of our concerns – be they community, research, engineering or principle-based – into account.

Jdforrester (WMF) (talk), Product Manager, VisualEditor team 16:02, 11 September 2013 (UTC)

Possible further changes

Instant opt-out from VisualEditor in the beta welcome screen

In addition to the changes, we are considering adding an "instant opt-out" option to the welcome screen that comes up when you first open VisualEditor. This will flip the user preference to temporarily disable VisualEditor, without needing users to have to know about, find and go to their Preferences page. We hope that the presentation of a clear choice on the welcome screen will make it clear that the user is choosing to opt-out or continue using VisualEditor during the beta.

Instant opt-out from VisualEditor in the help menu (as well)

Because the beta welcome screen appears only once for each user, we could also add a similar "instant opt-out" option in the help menu, which would work in the same way and be similarly "instant", and available all the time. This does add to the clutter of the already-confusing help menu, however, and we'd want to be careful to make sure the help menu continues to be, well, helpful.

(One-way) switch to wikitext editor button in the toolbar

We have been working on a button that will have the user switch to the wikitext editor for their current edit - initially one-way, but in the longer-term this could be a proper two-way integration similar to what WordPress has (though with some delay in switching). This is particularly aimed at users who find they cannot add or change something they want to in VisualEditor yet, or on reviewing their edit before saving see that VisualEditor has broken the wikitext and they wish to fix it before saving.

Prominent instant opt-out banner in every VisualEditor editor

We could have a much more "heavy" approach for opt-out, with a prominent banner along the top of the toolbar on every VisualEditor editor, but this would both be quite disruptive and we'd likely need to balance it with an equivalent opt-back-in banner in the wikitext editor for users who had opted-out (at least in the future when we needed even more wide-spread engagement from particular communities).

Discussion

• …