Topic on Talk:Talk pages project

Flow blew up for fundamentally the same reason the the 2017WikitextEditor project blew up, and the same reason the SingleEditTab project went boom. They all went boom because of a problematic obsession with a mostly-insignificant secondary editor that almost no editors want use. They all tried to force the wiki over to VE in various ways.

@PPelberg (WMF), can we please please please agree on the following points?

1. Please confirm the default editor will be wikitext. There may be an option to switch to VE as a secondary editor. (I believe this has already been resolved on Phabricator, but I include it for completeness.)
2. Please confirm the team will not try to use VE's "wikitext mode", also known as 2017WikitextEditor, as the Wikitext editor. The community overwhelmingly rejected deploying VE's wikitext mode as a wikitext editor for article space, and we don't want this jeopardizing the talk project.
3. Please confirm the team will not try to use VE or VE's parser (parsoid) for previews. Previews must use the genuine wikitext parser. If you check the link above, this is one of the reasons the 2017WikitextEditor project blew up.
4. Please close Phab task T238218, which proposes running everything through VE's parser.

No point attempting to discuss this in this thread

P.S. Wow we just discovered another impressively bad Flow/parsoid bug. I applied a single <s>strikethough</s> to the entire post, but magically one line in the middle renders without strikethrough. Does anyone think this is SANE behavior? Does anyone think it would be acceptable for the new Talk Page interface to bug out like that, because the team runs everything though VE's parser?

It's not strictly a Parsoid bug; the cause seems to be that you put the closing </s> on the same line as the last list entry, instead of putting it on the next line. Both parsers interpret this as "put the </s> inside the list item", and both parsers then have to fix the resulting incorrect nesting, but the parsers do this in different ways.

It would presumably be better to change the code so that the nesting works. Unfortunately, because this would be a possible resolution (and the code was syntactically incorrect to begin with), I think it's fairly likely that the issue won't be fixed; I'm aware that this is what's happened for similar edge cases.

Ehm... Most wikipedias are happy with VE and don't have any problem with the 2017WikitextEditor. In any case, complex wikitext is extremely rare in Talk pages. It is all a matter of conventions and habits. If some wikitext does not look good in preview, that may be a sign that it is too complex for any case.

Geraki I do not intend to engage in a pointless fan-vs-critic debate about VE. The data shows a low percentage of edits are made with VE. It's a mostly-insignificant secondary editor that few editors choose use.

If you like VE, fine, it's available as a secondary editor for those who want to use it. The rest of us just get upset when the Foundation neglects or sabotages our primary tools. The obsession with VE has directly resulted in the failure of several projects.

And "looking good" in preview is nonsensical. A preview is either correct or incorrect. A preview that fails to preview is a clear design error.

Please read again what I wrote. If I need to clarify, then "non-english wikipedias are happy with VE". The data shows a low percentage of edits are made with VE,^{[citation needed]} in english wikipedia where it is not enabled by default to new users, but at least in my home wiki it is a big percentage even among experienced users.^{[citation needed]} So, since the WMF is creating a feature for Mediawiki in general and all Wikipedias, and not only for English wikipedia, let it be one more option that English Wikipedia may (once more) opt-out.

Geraki I did read what you wrote, and what I said was correct. I said The data shows a low percentage of edits are made with VE. Period. You incorrectly rewrote my words to say English Wikipedia. No. I was talking about global edit data. You tagged my statement as 'citation needed', so I'll pile on the data.

The raw global data shows approximately 18 Visual Editor edits per minute. The raw global data shows approximately 1000 total edits per minute. 18 divided by 1000 equals 1.8% of all edits are Visual edits. The 1000 edits per minute includes wikitext edits, Visual edits, Wikidata edits, and things such as pagemoves and administrator actions. Discounting things like wikidata edits and pagemoves increases the Visual percentage as compared to Wikitext, but not by much.

The Foundation did the work of filtering the data to just Visual edits vs wikitext edits. Here's their results:

Platform	Visual editor percentage	Wikitext editor percentage
Desktop (visual editor default wikis)	14.8%	85.2%
Desktop (wikitext editor default wikis)	5.7%	94.3%
Mobile	6.1%	93.9%

On Mobile and on wikis where Visual Editor is enabled as the secondary editor, the percentage of Visual edits is approximately zero. On Wikis where Visual editor is shoved onto all new users as the default, the percentage of Visual edits is.... not particularly far from zero.

The Foundation also collected data on retention-by-editing-interface. See the graph at File:2018-10_Wikimedia_editing_interface_retention.png. The retention rate for VE is about HALF the retention rate for the wikitext editor. When new users are dropped into VE by default, the majority of them either quit editing or they switch to the Wikitext editor. Either way that is obviously bad. The Foundations's stealth-deployment of a VE-default as part of the Single-Edit-Tab project needs to be reversed.

1. I rewrote my words.
2. The raw global data you are presenting in wikitext includes also API edits (bot, wikidata, twinkle, reverts, etc). Only Wikidata is at this time 250 edits per minute end it is still Satuday night in the US 😎. Also, they obviously include edit data from english wikipedia where VE is hidden behind preferences, and edits in Talk namespaces where VE is also not available. So, the data is biased, since it includes non manual edits, non human edits, and edits from projects and namespaces where practically VE is not available.
3. The graph you are presenting shows the same drop in using either editor (same percentage switched editor). And from what I read in the analysis, more users that opened the VE editor achieved a successful edit (saved it) than those that opened the wikitext editor on desktop (11.6%>10.2%) and way more on phone (15.1% > 2.5% !). So please do not exclude edit attempts that may or not result in counting an edit, because many new users become frustrated when they press an Edit button and see a mess of wikitext.

The raw global data you are presenting in wikitext includes...

There's no need to repeat what I said. But it's good to know you agree that I was right when I said it.

And if you had bothered to keep reading you'd have seen table showing the Foundation's data for VE edits vs Wikitext edits. The figures for VE are abysmal.

The graph you are presenting shows the same drop in using either editor

You clearly misunderstood the graph. I suggest you read it more carefully. It's a survival graph, and all of the graphs start at 100%. After 25 weeks, about 97.2% of VE users have either QUIT EDITING or they've switched to wikitext. After 25 weeks, twice as many wikitext users are still editing and still using wikitext.

If it were a graph for cancer treatment, the VE graph shows half the survival rate. That is catastrophically bad.

english wikipedia where VE is hidden behind preferences

You're just plain wrong. Go check. You can switch between both editors using the control in the top right corner of the editor. If you click to VE once, it will keep loading VE every time (until you actively select wikitext again).

I read in the analysis, more users that opened the VE editor achieved a successful edit (saved it)

It's it is true that you read it, however the Foundation has a bad habit of confirmation bias in their data handling. One of the problems with VE is that it's slower to load, in some cases catastrophically slow to load. That is one of the places we lose editors. Of course that's powerful evidence VE is driving people away, so staff decided to filter it out of the data. If someone tries to edit, and VE is slow or dies, and they leave, they excluded that from their VE-failure data. The wikitext figures are also deceptively low because it is a common wikitext workflow to open extra work-tabs to view or copy some wikitext. The only important figure is how many edits we get, it doesn't matter many edit windows are opened to get those edits.

You’ve mentioned that particular graph before (during phase 1 of the talk pages consultation), and I don’t think it’s as cut-and-dry as “the lower retention rate means the editor is worse”, because the retention rate is affected by multiple factors and how much users like VE may not even be the most significant contributing factor. I don’t remember what I said about the graph then, but off the top of my head, three factors that would affect the rates include:

• new users who find editing relatively intuitive (regardless of which editor they use) may prefer wikitext, and their competence may make them more likely to be retained;
• users who have previously edited other MediaWiki sites (including sister projects) may be more likely to prefer wikitext due to being more familiar with it, and their experience and the reason(s) they’re editing here would make them more likely to be retained;
• users who do not intend to stay for very long (e.g. they want to make a spelling correction but they’re never going to come back) would not benefit from learning wikitext, so they would probably just use whichever editor comes up first or might deliberately choose VisualEditor, and the reason(s) they’re here would make them less likely to be retained.

No, there is no plan to replace wikitext with VE. And your data doesn't mean nobody uses VE. If someone wants to use it - let them use, you can disable it. Why do you fight with every improvements, even if they can be choosen from preferences?

No, there is no plan to replace wikitext with VE.

Actually the Foundation did publish an official plan to replace wikitext with VE... however that was back in 2011. This is 2019. The people who came up with that plan are either gone, or they have accept it isn't about to happen, or they keep quiet about their wish for it to happen because they know the Foundation is not about to back any open moves to remove wikitext.

And your data doesn't mean nobody uses VE.

Good to hear that we're in agreement. The number of people who actively choose to use VE is close to zero percent, and close to zero percent does not equal zero.

If someone wants to use it - let them use, you can disable it.

Good to hear that we're in agreement. As I said before, and I quote, "If you like VE, fine, it's available as a secondary editor for those who want to use it."

Why do you fight with every improvements, even if they can be choosen from preferences?

I've never fought an improvement. Note that I'm not going to play any game where you attempt to assert your personal preference for anchovy-icecream as an improvement. Improvement is defined by what best serves the community as a whole.

VE is the secondary editor, you can reach it it a single click, and then the software will remember your preference and load VE every time for you. You have a rare preference, and that's fine by me. I don't care what race, religion, or gender person you personally want to marry. I also don't care what editor you personally prefer. You're welcome to marry who you want, and you're welcome to use whatever editor you prefer. However there would be a serious problem here if you start a fight because you want to pressure the majority to conform to your minority preference.

• I am only going to make one comment because I object to the editor I am forced to use to edit this page. (Seriously? No preview button?) If anyone wants anything further from me, ask on my talk page and transfer the answer here yourself.

Re: "In any case, complex wikitext is extremely rare in Talk pages. It is all a matter of conventions and habits. If some wikitext does not look good in preview, that may be a sign that it is too complex for any case." let me be blunt:

If anyone at the WMF attempts to force VE on the English Wikipedia community without extensive consultation done on a standard English Wikipedia page The shit will hit the fan, multiple veteran contributors will resign, various news sources will publish stories about our latest battle with the WMF, the board of directors and/or the CEO will intervene, and finally whoever tried to shove this down our throats will end up backing off, much as T&S backed off at [ https://en.wikipedia.org/wiki/Wikipedia:Community_response_to_the_Wikimedia_Foundation%27s_ban_of_Fram#End_of_community_consultation_on_temporary_and_partial_office_bans ].

The URL above would be a good place to start if you really want to consult with the English Wikipedia community on this. --Guy Macon (talk) 14:46, 22 November 2019 (UTC)

As long as visual editor is primary/secondary editor for editing articles, it should be primary/secondary editor for editing talk pages. (Just like in this editor you can use both and I'm currently typing it in wikitext.)

I made fair statistics of visual editor usage on enwiki and (my home) cswiki. It's 8% of all non-bot saved edits on enwiki and 25% on cswiki. So let's not call VE "danger".

Yeap! 27.5% in elwiki. And it will be more if we count users instead of edits. (Also: wikitext users usually go editing section to section instead of the whole page: that counts as more edits for the same result)

Here is another reason why I hate being forced to use VE to follow this discussion. 10 "from another wiki" notifications this morning, none of them replies to me. Unsubscribing now.

Again, if you give me a CHOICE to use VE, that's great. If you FORCE me to use VE my response is at [ http://www.guymacon.com/flame.html ].

@Guy Macon: Following the discussion is not a VE thing, that is a Flow thing... which the talk page project will not be injecting.

"being forced to use VE to follow this discussion" makes no sense, just like flaming about it.

Understanding the matter at hand would be beneficial for a discussion.