As @matmarex pointed out offline, this is now the same as our getPreferredEditor logic in article editing, which we use whenever we the user hasn't made an explicit editor selection (e.g. a red-link)

We should also state that this logic only applies to the first time they open the tool. Every subsequent time they open the tool we will remember the last mode they used in it.

Per this morning's meetings, we are not going to run a variant test at this time.

As such, I am updating the task description to include the approach we arrived at around defaults, as Ed alluded to in: T250523#6114627.

Context
Here are the reasons we decided to forego a variant test of the text input modes for now:

• We assume the risk of a non-technical user being presented with the source mode and becoming confused and/or discouraged (as has been the case in article editing) to be relatively low considering they will not see any wikicode in the Reply tool's text input.
• We assume it is likely that a non-technical user who is presented with the source mode and not able to perform a certain action in the current interface (e.g. sending a ping), will click over to the visual mode considering how visually prominent it is in the interface.
• The time and effort required to implement and analyze the variant test does not seem to warrant the value it would provide considering the bullet points above.

In T250523#6114627, @Esanders wrote:

As @matmarex pointed out offline, this is now the same as our getPreferredEditor logic in article editing, which we use whenever we the user hasn't made an explicit editor selection (e.g. a red-link)

We should also state that this logic only applies to the first time they open the tool. Every subsequent time they open the tool we will remember the last mode they used in it.

@Esanders I've attempted to represent the above in the task description; please let me know if anything looks off to you.

Change 595031 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] Create a user preference to store visual/source mode

https://gerrit.wikimedia.org/r/595031

Change 595031 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Create a user preference to store visual/source mode

https://gerrit.wikimedia.org/r/595031

Testing instructions
Adding the following "Testing instructions" to the task description:

• If QA has a vagrant virtual machine, all configurations described in the "Text input mode configuration" section can be tested.
• If QA does NOT have a vagrant virtual machine, only the user-level configurations (read: preferences) described in the "Text input mode configuration" section can be tested.
  • Reasons: https://en.wikipedia.beta.wmflabs.org/'s wiki-level configurations cannot be changed.

I tested this today on both Beta and Partner wikis.

There are two things I observed while doing that:

First case:

1. A contributor posts a reply.
2. Goes to Preferences section and changes the Editing mode preference to source/visual mode.
3. Then goes back to discussion page and click on Reply again.

It shows the previously used editor, not the one that has just been set to. My understanding was, when a user explicitly chooses an editing mode, it will override the last used editor choice. How should it behave in this case?

Second case:

1. User goes to Preferences section first and then sets source mode as preferred editing mode.
2. Then clicks on Reply link, and switches the editing mode to visual.
3. Then reopens the comment box again, this time it opens the last used editing mode: visual, instead of preferred editing mode: source.

Is this behavior expected?

In T250523#6204414, @Ryasmeen wrote:

I tested this today on both Beta and Partner wikis.

There are two things I observed while doing that:

Thank you for flagging these, Rummana.

First case:

1. A contributor posts a reply.
2. Goes to Preferences section and changes the Editing mode preference to source/visual mode.
3. Then goes back to discussion page and click on Reply again.

It shows the previously used editor, not the one that has just been set to. My understanding was, when a user explicitly chooses an editing mode, it will override the last used editor choice. How should it behave on this?

The behavior you described above is expected.

Said differently: the last text input mode someone used to post a comment using the Reply tool is the text input mode people should "land in" when clicking the "Reply" link in a future session, regardless of what preference is set in "Preferences" > "Editor" > "Editing mode."

The reasons this currently works as it does:

• We are assuming people will see the context in which the Reply tool is used (discussions) and the ways in which it is used (adding comments, pinging other users, etc.) as being different enough from where (all namespaces and contexts) and how (adding/modifying/removing existing content) they use other editing interfaces. [i]
  • This leads to the following conclusion: people will expect to be able to set different preferences for the Reply tool and the full-page editing interfaces.
• Initially, the simplest way to implement the above, is to have the Reply tool remember the mode used when posted the last comment.
  • Additional, more granular controls can be added later...if necessary.

Second case:

1. User goes to Preferences section first and then sets source mode as preferred editing mode.
2. Then clicks on Reply link, and switches the editing mode to visual.
3. Then reopens the comment box again, this time it opens the last used editing mode: visual, instead of preferred editing mode: source.

Is this behavior expected?

This behavior is also expected for it is subject to the same logic and reasoning above. In short: the last text input mode someone used to post a comment using the Reply tool supersedes/overrides the what preference is set in "Preferences" > "Editor" > "Editing mode."

i. Note: when using the Reply tool for the first time, it will inherit the preference people have set for other editing interfaces.

@Ryasmeen before closing this out, can you confirm that what you commented in T250523#6204414 were the only issues/questions that emerged in the testing you did?

Asked another way: by me addressing the issues you raised in T250523#6204414, can we assume the Reply tool is behaving as is described in the "Text input mode configuration" section of the task description?

In T250523#6212296, @ppelberg wrote:

@Ryasmeen before closing this out, can you confirm that what you commented in T250523#6204414 were the only issues/questions that emerged in the testing you did?

Asked another way: by me addressing the issues you raised in T250523#6204414, can we assume the Reply tool is behaving as is described in the "Text input mode configuration" section of the task description?

@ppelberg, those were the only two questions that I had when I checked with logged in users.
I checked with logged out user accounts today and in all partner wikis only the source mode is showing up when I used dtenable=1, regardless of what the default configuration is.
Using dtvisual=1 does not show any Reply links at all.

Also, I could only test the user-level configurations from preferences section described in the "Text input mode configuration" section. Couldn't test the ones that say "follow behavior defined in getPreferredEditor".

In T250523#6212559, @Ryasmeen wrote:

In T250523#6212296, @ppelberg wrote:

@Ryasmeen before closing this out, can you confirm that what you commented in T250523#6204414 were the only issues/questions that emerged in the testing you did?

Asked another way: by me addressing the issues you raised in T250523#6204414, can we assume the Reply tool is behaving as is described in the "Text input mode configuration" section of the task description?

@ppelberg, those were the only two questions that I had when I checked with logged in users.
I checked with logged out user accounts today and in all partner wikis only the source mode is showing up when I used dtenable=1, regardless of what the default configuration is.

This is expected considering the source mode is the only mode that is currently available on our partner wikis without using ?dtvisual=1.

Using dtvisual=1 does not show any Reply links at all.

Funky. @Ryasmeen: do you remember the URL of the page you tried this on? Appending dtvisual=1 to this URL seems to works as expected for me: https://fr.wikipedia.org/wiki/Discussion_Projet:Outils_de_discussion?dtvisual=1

Also, I could only test the user-level configurations from preferences section described in the "Text input mode configuration" section. Couldn't test the ones that say "follow behavior defined in getPreferredEditor".

Understood. This is expected per the following bit in the task description:

• If QA does NOT have a vagrant virtual machine, ONLY the user-level configurations (read: preferences) described in the "Text input mode configuration" section can be tested; the "Partner wiki article editor default configurations" can be tested as well.
  • Reasons: https://en.wikipedia.beta.wmflabs.org/'s wiki-level configurations cannot be changed.

Resolving this because the visual mode is now deployed to our partner wikis as a Beta Feature and thus the dtvisual= parameter is obsolete.