Topic on 2017 wikitext editor/Feedback

No longer can use date formatting script

16
Valereee (talkcontribs)

I was used to switching back and forth to use User:Ohconfucius/script/MOSNUM dates but unfortunately installing new wikitext mode gets rid of that script in source editing too.

Alsee (talkcontribs)

The 2017 editor is incompatible with all previous scripts. User:Ohconfucius or someone else would have to rewrite the code to get it to work in the 2017 editor. However there is little chance that will ever happen. Almost exactly three years ago I ran an RFC at EnWiki Village Pump. Community consensus was to block it from being deployed as a replacement for the current wikitext editor. The Foundation has stalled this project in beta for three years, but it appears the manager on this project imagines he's going to steamroll forwards deployment at some point. I would not advise holding your breath.

Valereee (talkcontribs)

Thank you, I'd wondered why it had been in beta so long. I was testing out the beta to see how I liked it, and I did like many things about it. I use visual editor and source editing both and do end up switching back and forth for various reasons often. ~~~~

Whatamidoing (WMF) (talkcontribs)
Whatamidoing (WMF) (talkcontribs)

> being deployed as a replacement for the current wikitext editor

To the best of my knowledge, nobody in the WMF has ever proposed replacing the 2010 wikitext editor with the 2017 wikitext editor. I hope that nobody has been spreading that false rumor?

In late 2018, the then-product manager and I planned to move the 2017 wikitext editor out of Beta Features (i.e., the tickbox for turning it on/off moves into regular "Editing" preferences tab, with no changes to anyone's personal settings), but then he decided to change companies, and the team has been busy with other projects since then. If you all think the location of the prefs tickbox is really important, then I can ask to have the tickbox moved from the Beta Features prefs tab to the regular Editing prefs tab. I don't think it's all that important myself, though.

Alsee (talkcontribs)

@Whatamidoing (WMF) you saynobody in the WMF has ever proposed replacing the 2010 wikitext editor with the 2017 wikitext editor but the Project page for the 2017Editor says we'll begin to provide it by default in place of the current wikitext editor.

I don't know if you saw it but here is what the the project manager posted to the mailing list: our intent right from the beginning of our work on the visual editor has been to operate as the core 'platform' for all kinds of editing... there are currently six pieces of editor software beyond the visual editor... Our goal is to gradually reduce the number of pieces of software with equivalents based on the single platform... experimenting with providing a more modern wikitext editor

The goal is to reduce the number of editors. The manager then built an additional wikitext editor. (The opposite of reducing.) That means the plan was either to build-and-immediately-scrap the 2017Editor (obviously not), or the plan was to scrap the current wikitext editor as redundant to the new editor. So please don't claim there was no plan to kill the current wikitext editor. At best, there was a plan to exterminate the current editor and no one informed you.

Some of your comments suggest there might be a miscommunication or misunderstanding. For example you talk about the location of the preference setting - I see that as irrelevant. I don't care where the preference is. Put it anywhere you want. You also try to reassure me that the Foundation won't change the preferences of existing users - again I see that as irrelevant. Go ahead and change the prefs for existing users - I don't care (much). It just will annoy us and most of us will simply change it back. Promising you'll keep the current editor for the next hundred years doesn't much matter either. Maybe the issue will be more clear if I narrow it down to the essential part:

(Not) deploying the 2017Editor as default for new users.

I have no idea if it is intentional, but you're trying to advance or the Foundation's agenda to make 2017Editor the default for new users by hiding it in the things-you-don't say. It's not working. The issue is the default. And apparently I need to explain that "default" is what is given to a blank-slate new user.

The Foundation kept Flow as a walking-corpse for six years. For six years, all fixes and upgrades on the project were wasted acts of necrophilia. I had to organize consensus across three wikis to get the Foundation to acknowledge that the project failed. Three years ago I delivered the Foundation the EnWiki consensus on the 2017Editor. The 2017Editor has been kept as a walking-corpse for three years. Any upgrades or bug-fixing on this project are wasted acts of necrophilia. Apparently the only way I can help the Foundation is to again organize consensus across multiple wikis until the Foundation buries this corpse.

Whatamidoing (WMF) (talkcontribs)

On the difference between hopes and plans:

This seems to be my week for people quoting half a sentence to prove a point. That sentence begins "Only once we've met our quality requirements (including new-user testing and experienced-user happiness)...". That hasn't happened (because the team switched projects). Therefore there has never actually been a proposal to make that change.

The Foundation does not actually have a plan, a proposal, a goal, or an agenda to deploy the 2017WTE as default for new users, or anyone else.

Have some staff previously written about their hopes to do so? Yes. Is anyone actually going to do it? I make no promises about the next decade, much less then next century, but I can tell you that nobody at the WMF right now is even talking about doing this. The only deployment plan ever actually written and proposed for the 2017WTE was to not turn it on by default for anyone ā€“ and that plan was never implemented.


Alsee (talkcontribs)

First I'd like to note something a staff member said that really stuck with me. They said something to the effect of "The worst case scenario is when a project blows up on deployment day". At the opposite end the best and cheapest time to identify problems is in the initial concept&design stage, before anything is built. Between those endpoints there's a steady sliding scale of "earlier is always better". For brevity, I will say the Foundation has Institutional patterns that tend to railroad itself into the worst case scenario. I acknowledge efforts to improve, but they have been uneven with limited success. I will switch back to the main topic, and reintegrate this side-comment in a minute.

The manager who built 2017Editor stated our intent right from the beginning of our work on the visual editor has been to operate as the core 'platform' for all kinds of editing... there are currently six pieces of editor software beyond the visual editor... Our goal is to gradually reduce the number of pieces of software with equivalents based on the single platform. I will emphasize "Our goal" and that the the goal was to reduce the number of editors. The product page was also clearly written with an expectation that "quality requirements" will be met at some point, it estimates "probably in mid-2017", and it explicitly states an intent to "provide it by default in place of the current wikitext editor" when the anticipated conditions are met. I don't have a link handy, but I recall the manager was so dead-set on steamrolling the project out that he declared it some sort of binding strategy "Contract" superseding all consensus. In fact that manager made it clear that the Parser Unification project was his roadmap for deploying the 2017Editor. If Parser Extermination Unification is deployed, that will break previews in the current editor and "fix" previews in the 2017Editor. However that would actually be purely disruptive. It doesn't end the consensus-block against deployment of the 2017Editor, so deploying Parser Extermination Unification would just sabotage the current editor. Hmmm.... I wonder if there would be consensus against Parser Extermination Unification?

The Foundation has earned a reputation for doublespeak and weaslewords and dishonesty when staff are pursuing an unpopular agenda. I doubt I was the only person who had a rather unfavorable view when you attacked me about "plans" in the 2017Editor RFC. There was clearly a sizable group of staff dedicating substantial resources with a well-organized intention for eventual full deployment. I don't think many people cared much about how you defined "plans", I don't think many people cared that no specific deployment date had been set.

Whether is was deliberate or whether it was poor project management, the 2017Editor project was effectively built in secret. Building a new editor should have been a big deal. There was no project page for it, and as far as I'm aware there was little or no prior advertisement. When I stumbled across a stray reference to it, I was told that no information would be available until the initial version was essentially complete. Returning to my earlier comments, the worst possible time for the community to weigh in on the project is when there is a concrete deployment plan. The best time for the community to review and comment would have been in the concept&planning stage. The Foundation's inclination to say the 2017Editor RFC shouldn't have been run at that time was part of the Foundation's institutional pattern of railroading itself into the worst case scenario. The editors in that RFC were clearly not swayed by your argument that there was "no plan". The fact that it had been BUILT was evidence enough that it was well past time for the community to give the Foundation clear feedback on the product. Earlier would have been better, later would have been worse.

If nobody in the Foundation has any plans to deploy the 2017Editor as default, then the Foundation should terminate the product and yank it from beta completely. As the manager who built it well argued, we shouldn't have [eight] different interfaces by which to confuse users, [eight] different sets of bugs to track down, and [eight] different places where features can interact in unexpected ways and which need to be tested. If the 2017Editor isn't going to replace the current Wikitext editor, it is a wasteful drain of resources to maintain a redundant editor.

On the other hand if there are such plans (or goals or hopes or daydreams or whatever you want to call them), then that crashes head-on into existing consensus against the product. I am certain that the EnWiki consensus will be echoed at enough other wikis to constitute an effective Global community consensus. And again we have the conclusion that it is a wasteful drain of resources to maintain a redundant editor that can't be deployed.

The only rationales for maintaining the 2017Editor are either an unrealistic fantasy that consensus will change, or a pathological fantasy of hostile deployment by force.

Whatamidoing (WMF) (talkcontribs)

> If Parser Extermination Unification is deployed, that will break previews in the current editor and "fix" previews in the 2017Editor.

Why do you believe that having one parser provide all previews in all editors (and also be the same parser that creates the HTML displayed on all devices) will break previews in the 2010 wikitext editor?

Alsee (talkcontribs)
Whatamidoing (WMF) (talkcontribs)

That is the main point of the parser unification project. All parsing work, including all previews and processing all pages after they're written to the database, will be done by the same parser. See, e.g., the second paragraph of Parsing/Parser Unification: "The goal of this project is to arrive at a single parser that supports all clients and use cases." The word "all" in that sentence includes the preview button in the 2010 wikitext editor.

Whatamidoing (WMF) (talkcontribs)

On the status of the 2017WTE:

I do not agree that the 2017WTE is a failed project. It's been used for 7 million edits so far (1.8 million edits at the English Wikipedia). More than a million articles have been created in it. Along with many other experienced editors, I use it preferentially (mostly because of the built-in link search, although others like its citation and template tools).

The 2017WTE is VisualEditor's built-in wikitext mode. Maintenance for the 2017WTE is maintenance for VisualEditor. VisualEditor is in maintenance mode (=the same status as most of the editors that the WMF supports), rather than active development. That means that no major new features are planned, but bugs are being fixed.[1]

  1. ā†‘ They did release a new table-editing feature last month, to fulfill an emergency request from English Wikipedia editors working on the pandemic-relate articles. It allows editors to sum columns in tables. This, however, was unplanned work.
Whatamidoing (WMF) (talkcontribs)

On the 2017WTE for new editors:

I'm curious why you object to new editors having the 2017WTE automatically.

Just in case this wasn't already clear, whatever wikitext you (mis)type into the 2017WTE, that's exactly what gets saved, exactly what gets shown in the diff, and exactly what the next person to edit the page has to work with. Parsoid never touches it, so there is no possibility of any round-tripping errors, no automatic correction of Special:LintErrors, no whitespace changing, etc.

I don't remember why you are concerned about which toolbar is at the top of a new editor's screen, given that all of the wikitext toolbars available to new editors produce the same end result: the wikitext that's on their screen is the wikitext that gets saved. Is it just the small (and temporary) differences in the previews, or was there more to it than that?

Alsee (talkcontribs)

I could list direct practical reasons, primarily the longer load time. (We especially don't want new users staring at a loading-bar and deciding to abort.) But it's deeper than that.

One of the topics I plan to open on the new Village Pump page will the Foundation's general VE strategy over the last decade. It will be long and I'll have to pull together a lot of supporting links. I'm not going to do that here. The very short version is that I intent to try to lay out a case that the Foundation has been pursuing a strategy that is well-intentioned, but harmful. The 2017Editor is both a symptom and a part of that strategy.

There was a joke from the manager who built the 2017Editor. I have a link saved somewhere, but not handy. There was discussion was about the low adoption rates of VE. He said (approximately) there were two ways to get more people into VE. Either the Foundation could make VE better, or the Foundation could make wikitext worse.

To again quote that manager, our intent right from the beginning of our work on the visual editor has been to operate as the core 'platform'. He wasn't trying to build a better wikitext editor. He was pursuing an agenda, an agenda to rebuild the wiki around VE "as the core platform". He didn't care that building the 2017Editor inside VE would result in harmful load times. That harm was an utterly irrelevant and acceptable trade-off. The Foundation isn't deliberately making wikitext worse, nonetheless the Foundation's VE strategy is resulting in a systematic series of tradeoffs sabotaging our primary editing environment.

If one buys into the theory that VE is bringing a glorious future with hordes of new users, then the strategy makes sense. If that theory is wrong, then the Foundation is systematically killing the goose that lays the golden eggs.

Pppery (talkcontribs)
Alsee (talkcontribs)

Yep, that's the joke I had in mind.

Reply to "No longer can use date formatting script"