It might be desriable to do T90665 ("Prompt existing users to enable VisualEditor for their account on the English Wikipedia.") early in this process, because existing users are the main source of help for new editors.

In T90667#1064549, @Whatamidoing-WMF wrote:

It might be desriable to do T90665 ("Prompt existing users to enable VisualEditor for their account on the English Wikipedia.") early in this process, because existing users are the main source of help for new editors.

Plausibly. On the other hand, it's a complicated-to-build and relatively invasive (even if "one time" UX impact on existing users who aren't hugely likely to switch.

Perhaps an initial invitation should use other methods, then, like watchlist notices, or a sitenotice banner that only displays on a small percentage of page views.

In T90667#1064559, @Whatamidoing-WMF wrote:

Perhaps an initial invitation should use other methods, then, like watchlist notices, or a sitenotice banner that only displays on a small percentage of page views.

Oh, sure. This was more planned as a pop-up in/on the editor for logged-in users, like T89701: Ask users to try the ContentTranslation beta feature when creating an article. Maybe we should add this into the plan here?

This was more planned as a pop-up in/on the editor for logged-in users

That can be done only while measuring what impact the pop-up has on editor productivity, though. Results can be unexpected sometimes. Cf. https://meta.wikimedia.org/wiki/Research:Asking_anonymous_editors_to_register

If a trial is considered, then the options should be removed (except categories), i.e. the page settings, advanced settings and languages, since each of these is either inappropriate for mainspace (noindex, not showing TOC) or doesn't produce the expected result (for example redirecting doesn't remove the previous page content, marking as disambiguation adds the magic word even though we use templates for them), or can't actually be used (languages). All these are best done directly in wikitext (or at wikidata) for now as the use case is quite small.

For updates about pilot and study, please see:
https://meta.wikimedia.org/wiki/Research:VisualEditor%27s_effect_on_newly_registered_editors
https://meta.wikimedia.org/wiki/Research:VisualEditor%27s_effect_on_newly_registered_editors/May_2015_study .
There's a conversation about success criteria at https://www.mediawiki.org/wiki/Talk:VisualEditor#Success_Criteria .
Updated timeline here.

So... the planning is complete? Is this task's description an accurate summary of the current plan?

(1) Deciding whether planning is "complete" is essentially arbitrary. There has been significant planning work, but adjustments will continue to be made as facts are learned. Whether it should have been declared "complete" now or a month ago is something that reasonable people could disagree upon.

(2) The task description is basically accurate, despite leaving out many significant components of each step. For example, "Step 2" is currently underway; both whether and when the plan proceeds to Step 3 depend upon the results of the test, multiple discussions, and several other factors. "Step 2" could prove that the devs failed at "Step 1", in which case proceeding to Step 3 would be inappropriate. Or it could show that it produced excellent results in one area but weak results in another, in which case people would have to decide how much value to put on each area (e.g., excellent results in an important area should probably outweigh weak results in a minor area, but weak results in an important area should probably outweigh excellent results in a minor area). Or it could show excellent results across the board, in which case we might have to wonder whether the "small percentage" proposed in Step 3 for T90664 is the correct place to start (e.g., versus a medium-sized percentage, or even 100% of newly registered accounts).

@Whatamidoing-WMF:
What about my comment at T90667#1178929 ? When editing in visual editor, I still see the advanced options menu, that provides unadapted functionality and is useless and confusing for new users. These should be removed. Except for categories of course, which should in fact be more visible IMO.

Do you have any examples of it causing problems? In my experience, editors (even experienced ones) usually ignore that whole menu.

As I understand it, the one-week trial's already half done, so I doubt that they would be making any significant changes to the interface during the trial itself.

In T90667#1326112, @Whatamidoing-WMF wrote:

Do you have any examples of it causing problems? In my experience, editors (even experienced ones) usually ignore that whole menu.

As I understand it, the one-week trial's already half done, so I doubt that they would be making any significant changes to the interface during the trial itself.

Ignoring the menu is a problem in itself since this leads to them not knowing about the ability to modify categories, which is actually useful (the only useful thing in the 'advanced' menu). Categories should be given more visibility and the other options removed. I don't have data but IMO it should be looked into.

Giving cats more visibility has been discussed in T52239: VisualEditor: Allow the user to edit categories at the bottom of the page, similar to HotCat. The idea there is to edit categories sort of like HotCat works (in Vector), right at the end of the page.