In T249391#6332703, @Tacsipacsi wrote:

In T249391#6331296, @ppelberg wrote:

In T249391#6328367, @Tacsipacsi wrote:

• Idea prompted by @geraki: people who have the Prompt me when entering a blank edit summary (or the default undo summary) Special:Preferences enabled should see the custom edit summary field/functionality automatically.

Good idea, but unfortunately that’s a default preference on arwiki (T220186) and thus not a very good indicator there—people who have it on implicitly (i.e. no preference stored in DB) include junior contributors (obviously not a good idea to enable for them)

I'm glad you said something about this, @Tacsipacsi! I'd been assuming the Prompt me when entering a blank edit summary (or the default undo summary) preference was not a default preference at all wikis.

Actually arwiki is the only Wikimedia wiki that has this preference on by default (search for wmgForceEditSummary in InitialiseSettings.php).

Got it – thank you for point us to this configuration setting.

... while people who have it on explicitly are almost certainly a proper subset of those who would turn it on if it wasn’t the default, so taking explicit preferences into account excludes a lot of people (which may be acceptable, but should be considered).

Can you say a bit more here? Who are the people you are thinking will meet the following conditions?

1. People who expect to see custom edit summary field within the Reply Tool shown by default and
2. People who do not have the Prompt me when entering a blank edit summary (or the default undo summary) enabled?

I think very few people have this preference explicitly turned on if it’s implicitly on (they can’t even tick the preference in Special:Preferences since it’s already ticked, probably unchecking and re-checking would make it explicit, but that’s not very intuitive). I think most people who do have this preference on are those who have turned it on before May 2019 (when the patch in the mentioned task was merged). So the people meeting your conditions are basically (almost) everyone who became aware of the importance of edit summaries in the last 14 months.

Understood.

With the above in mind, I think we have enough information to develop an initial approach for determining in which cases the custom edit summary field/functionality should be exposed for people using the Reply Tool for the first time: [i]

• People using the Reply Tool for the first time should see the custom edit summary field exposed by default when using the Reply Tool for the first time if they meet both of the following conditions:
  • A) They explicitly turned on the Prompt me when entering a blank edit summary (or the default undo summary) setting in Special:Preferences AND
  • B) They are not using the Reply Tool at ar.wiki

The above prompts a new question about what is done at ar.wiki which I am going to post in a separate comment so it's easier to discussion.

i. This approach has been added as an answer to question #3 in the task description's "Open questions" section.

In T249391#6343091, @ppelberg wrote:

The above prompts a new question about what is done at ar.wiki which I am going to post in a separate comment so it's easier to discussion.

@Dyolf77_WMF, a question for you about how custom edit summaries within the Reply Tool are implemented. Before I ask that question, some context...

Context: we will be adding the ability for people to customize the edit summary that accompanies comments posted with the Reply Tool. A part of implementing this functionality involves us determining which people will expect for the custom edit summary functionality to be "turned on" when the use the Reply Tool for the first time (for the majority of people, the custom edit summary field will not be turned on when they use the tool for the first time).

Question: considering that on ar.wiki the Prompt me when entering a blank edit summary (or the default undo summary) preference is turned on for everyone by default [i][ii], we wonder whether you can think of another method the software can use to determine whether someone will expect to see the custom edit summary field available within the Reply Tool when they use it for the first time?

i. T249391#6332703
ii. At all other wikis, people need to manually turn on the Prompt me when entering a blank edit summary (or the default undo summary) preference which, we think, means it will reliable indicate that a particular person would expect to see the custom edit summary field within the Reply Tool when they use it for the first time.

Question: considering that on ar.wiki the Prompt me when entering a blank edit summary (or the default undo summary) preference is turned on for everyone by default [i][ii], we wonder whether you can think of another method the software can use to determine whether someone will expect to see the custom edit summary field available within the Reply Tool when they use it for the first time?

@ppelberg thanks for asking this, before answering your question I would like to inform you that summary edits is what I personally look at when replying comments.
Now about the method, I think it's already solved for newcomers but for senior editors,
a. if they ping a user from outside the conversation (not participating in the discussion),
b. if they reply to the discussion for the first time,
it will be convenient to type a summary of the edit (and an option to save preferences for the future).
Does this make sense?

In T249391#6356452, @Dyolf77_WMF wrote:

Question: considering that on ar.wiki the Prompt me when entering a blank edit summary (or the default undo summary) preference is turned on for everyone by default [i][ii], we wonder whether you can think of another method the software can use to determine whether someone will expect to see the custom edit summary field available within the Reply Tool when they use it for the first time?

@ppelberg thanks for asking this, before answering your question I would like to inform you that summary edits is what I personally look at when replying comments.

Can you say a bit more to this point? Are you saying that before replying to a comment on a talk page, you'll first notice the edit on your watchlist, review the edit summary that accompanied said edit and then go about drafting a response?

Now about the method, I think it's already solved for newcomers but for senior editors,
a. if they ping a user from outside the conversation (not participating in the discussion),
b. if they reply to the discussion for the first time,
it will be convenient to type a summary of the edit (and an option to save preferences for the future).
Does this make sense?

I think it does; I'm understanding the above as you describing the scenarios in which you would expect to be able to customize the edit summary that accompanies the comment you are writing with the reply tool. If that's not accurate, please let me know!

@Dyolf77_WMF, I should note: the question I asked in T249391#6343113 was to help us develop an approach for how we might identify users who might expect the custom edit summary functionality to be turned on within the Reply Tool the very first time they use it.

However, this is no longer a question that needs answering. Reason: the Reply Tool's custom edit summary will behave the same way for all people, until we become aware of evidence that suggests this approach needs to be revieded.

I've edited question #3 within the task description's "Open questions" section to reflect this thinking.

@ppelberg thanks for asking this, before answering your question I would like to inform you that summary edits is what I personally look at when replying comments.

Can you say a bit more to this point? Are you saying that before replying to a comment on a talk page, you'll first notice the edit on your watchlist, review the edit summary that accompanied said edit and then go about drafting a response?

@ppelberg no, usually (without the reply tool) I make my comment and before saving it, I type the summary edit.
With the reply tool, I make my comment and before posting my answer I would like to describe what I just wrote in the summary edit, that is not available with the reply tool. That is my personal approach, the summary edit is what I want to add to the Reply tool.

I made a few low fidelity sketches for the purposes of discussion. The challenge here is making a design that is obvious for senior contributors (such as @Dyolf77_WMF and marc) while simultaneously being non-disruptive to junior contributors. For in-context commenting, take a look at figma, otherwise, here are three ways we can go:

A. Tap in to add a message - this will always display the input field and you just need to tap into and then add the meage

B. Tap floating Button to expand - this is a material design-esque pattern of having a floating button of sorts that expand on click to reveal the input

C. Tap icon to reveal a shelf dropdown - a small icon will appear but open up a shelf with more options on click.

In T249391#6360679, @iamjessklein wrote:

A. Tap in to add a message - this will always display the input field and you just need to tap into and then add the meage

This should be pretty obvious for senior contributors, probably a bit too prominent for junior ones.

B. Tap floating Button to expand - this is a material design-esque pattern of having a floating button of sorts that expand on click to reveal the input

I think this is far too prominent for junior contributors, while not very intuitive for senior ones.

C. Tap icon to reveal a shelf dropdown - a small icon will appear but open up a shelf with more options on click.

This is maybe the least prominent of all—good for juniors, but maybe not very obvious for seniors.

As a conclusion, I think A is probably a bit better than C, while B should definitely be avoided.

In T249391#6360679, @iamjessklein wrote:

I made a few low fidelity sketches for the purposes of discussion...

Great idea, Jess.

In T249391#6361051, @Tacsipacsi wrote:

In T249391#6360679, @iamjessklein wrote:

A. Tap in to add a message - this will always display the input field and you just need to tap into and then add the meage

This should be pretty obvious for senior contributors, probably a bit too prominent for junior ones.

+ 1

B. Tap floating Button to expand - this is a material design-esque pattern of having a floating button of sorts that expand on click to reveal the input

I think this is far too prominent for junior contributors, while not very intuitive for senior ones.

+ 1

C. Tap icon to reveal a shelf dropdown - a small icon will appear but open up a shelf with more options on click.

This is maybe the least prominent of all—good for juniors, but maybe not very obvious for seniors.

@iamjessklein, this is the direction I think we should continue to explore.

"Rationale," "Enhancements to explore" and other "Considerations" to keep in mind below.

Rationale
I think we should continue to explore direction C: Dropdown for the following reasons:

• Of the three, it seems least likely to catch the attention of, and [potentially] subsequently confuse, Junior Contributors
• Considering some percentage of Senior Contributors will expect, and subsequently be looking for edit summary functionality within the Reply Tool, I think they will be more likely to notice an affordance that we might otherwise think to be too obscure in a different context. [i]
  • Of course, if Senior Contributors are not noticing the affordance, we can iterate on the implementation to make it more likely that they do.

Enhancements to explore

• In response to the @Tacsipacsi raised above RE this direction potentially not being obvious for Senior Contributors, can we play around with how and where the affordance is presented so that it is more closely related to the "posting process/flow"?
  • Thinking: if the affordance is more closely related to/positioned in the context of the "posting process/flow", Senior Contributors will be more likely to explore (read: click) the affordance because it will cause some version of the following thought process:
    • 1. "Ok, I've written them comment I want to post and now I want to post it."
    • 2. "Here is the button I need to click to post the comment."
    • 3. "But hold on, what about the edit summary?"
    • 4. Looks in the vicinity of the "Reply" button for something that might reveal the edit summary field
    • 5. Notices the affordance we're talking about above.
    • 6. Clicks it.
    • 7. ✅ Learns how to expose the edit summary field in the Reply Tool

Considerations

• I think we should avoid adding affordances to the lower right hand corner of the text input area for it will likely conflict the ULS IME component (T255191).
• The custom edit summary field should be pre-populated with the automatic summary that, if unchanged, would be posted with the comment they are writing.

i. This assumes the affordance is presented and positioned in a context within the tool where Senior Contributors are most likely to be thinking about/looking out for the functionality it offers.

Thanks @Tacsipacsi and @ppelberg I am going to do another round of iteration that incorporates your feedback and will post here.
I'd like us to still keep A in the mix for the purpose of conversation. I wouldn't want to make this a horrible experience for Senior Contributors and in fact this this might be an opportunity to enhance this experience slightly.

Of the three, it seems least likely to catch the attention of, and [potentially] subsequently confuse, Junior Contributors

Why are Junior Contributors a consideration here if this feature is only available to those who explicitly enable it in their preferences?

Not also that on article pages the edit summary label is defined in the message summary which many wikis override, for example in en.wiki it links to a help page and says "Briefly describe your changes" in small text: https://en.wikipedia.org/wiki/MediaWiki:Summary

Communities may expect this custom label to be used here as well, but we could also make a case for this being a different enough context that we want to create new messages from scratch.

Ahh good point @Esanders Ill add that summary to the requirements.

You also make a good point about the junior contributor not seeing this unless its enabled, which makes me want to lean in more to making it obvious. Thoughts @ppelberg? @Tacsipacsi ?

In looking into this with Jess, the summary edit message is heavily customised on many wikis, for example on zh.wiki it is used to provide a gadget that adds clickable common edit summaries:

This gadget will probably have to be updated to make it work, but that is for the zh.wiki community to fix.

In T249391#6362825, @Esanders wrote:

Of the three, it seems least likely to catch the attention of, and [potentially] subsequently confuse, Junior Contributors

Why are Junior Contributors a consideration here if this feature is only available to those who explicitly enable it in their preferences?

I'm glad you voiced this, Ed. Two things in response:

1. We decided to have the functionality exposed within the tool rather than in Special:Preferences. The task description's "Implementation details" section was updated on Wed, Jul 22, 17:13 (PST) to reflect this. [i]
2. I did not explicitly mention the update above in a comment; IIRC, this is something Jess and I talked about offline. This is a good lesson for me about why it's important to make sure every edit to an in-progress task's description is accompanied by a comment announcing said edit.

i.

To start, we will implement an approach that most closely resembles Approach 2: expose "Edit Summaries" inside the tool.
This means, all of the actions people need to take to customize their edit summary will happen within the Reply Tool.

In T249391#6362974, @Esanders wrote:

In looking into this with Jess, the summary edit message is heavily customised on many wikis, for example on zh.wiki it is used to provide a gadget that adds clickable common edit summaries:

Follow up question

• @Esanders are there reason(s) why we would need to recycle the summary component? Reason I ask: I wonder whether by using summary in the context of the Reply Tool, the tool would "inherit" messaging that was written for a full-page editing context and thus be perpetuating the issues T241403 is intended to resolve.

• 5. Should the tool be able to "remember" whether people have used the custom edit summary functionality in the past?

As discussed with @Esanders and @iamjessklein offline, to start, the tool will NOT remember – implicitly via a sticky preference or explicitly via a setting – whether someone prefers the custom edit summary field be exposed within the Reply Tool.

Reason: let's first learn how people use the functionality.

The task description's "Open questions" section has been updated with the above.

Here's an iteration that I'd love feedback on. The idea is to keep it simple with a very subtle advanced toggle that opens up a shelf with the summary input. cc/ @ppelberg @Esanders

subtle advanced toggle

reveal shelf with SUMMARIES and WATCH THIS CONVO

or just reveal shelf with SUMMARIES:

In T249391#6374275, @iamjessklein wrote:

Here's an iteration that I'd love feedback on. The idea is to keep it simple with a very subtle advanced toggle that opens up a shelf with the summary input.

I think these are moving in a good direction; nice work, Jess.

A couple quick things:

• It looks like F32034315 is missing the "Watch this page" checkbox by the "Reply" and "Cancel" buttons...can you post an updated mockup that includes that checkbox?
• It looks like in F32034315 and F32034201, the custom edit summary field is NOT being pre-populated with the automatic summary [i], can you post updated mockups that include this?

i. /* Section heading */ Reply

Update: 12-August
Below are the notes and next steps from the conversation @iamjessklein and I had today about the mockups that were posted in T249391#6374275.

Notes

• We came to agree that the "Watch this page" checkbox is a setting that should be considered an "advanced" function of the tool.
  • Where "advanced," in this context, means it is functionality that people do not need to know about/interact with to use the tool successfully.
• We came to agree the "Advanced" language is a good way of meeting the requirement that, " People writing a comment with the Reply tool should not be led to wonder or think about whether a custom edit summary is required."

Next steps

• @iamjessklein is going to update the screenshots in T249391#6374275 to show edit summary field pre-populated with automatic edit summary [i]

• @iamjessklein is going to explore where and how the "Watch this page" checkbox should be represented within the tool and how that checkbox should relate to the new "Advanced" affordance such that the following requirements are met:
  • Junior Contributors do not become distracted by it
  • Senior Contributors will know how to find it
  • Generally: people understand the "Watch this page" checkbox to be a non-required/advanced setting

i. /* Section heading */ Reply

Additional questions
A couple of other questions that came to mind:

• @iamjessklein: Are you able to show a mockup of how the custom edit summary will look in the Reply Tool's source mode? Thinking: I'm curious to see how it will interact with the tool's preview. I also assume this will be the mode Senior Contributors will use it most often in.
• @iamjessklein: Can you experiment with introducing a heading called "Reply summary" near the edit summary text field? Thinking: I wonder whether a bit of context will help those Junior Contributors who do happen upon this field understand what it is. It also seems to be a common pattern. [i]
• @Esanders: do you foresee any issues with the character counter that is shown in the mockups in T249391#6374275? Thinking: I wonder whether the character count will be accurate across languages considering the edit summary limit seems to technically be [i] 500 unicode points rather than 500 characters.

i.

Updates

Below are "Decisions" and "Next steps" that emerged in the conversation @Esanders, @iamjessklein and I had earlier today.

Decisions

• Character counter: the character counter will be displayed when people are within 100 characters of reaching the limit
• Text field: the summary text field should not adapt to the text written into it (read: the text people write should not impact the size of the field)
• Text field heading: the summary field should have a header called Reply summary
• The "Advanced" affordance should be visible in both of the tool's input modes: source and visual

The "decisions" above have been added to the "Implementation details" section of the task description.

Next steps
@iamjessklein to experiment with the following:

• Making the "advanced shelf" less prominent within the tool differentiated from the commenting area
• Adding the Reply summary heading to the summary text field
• Identifying a place for the "Watch this page" checkbox within the advanced shelf/area

The latest round of mockups are to be used for the purpose of pulling together a rough prototype.

High level changes:

• "Advanced Shelf" is below the widget via a left aligned dropdown
• Reply Summary is now incorporated into the shelf
• Watch this page is now incorporated into the shelf
• There are treatments for when the user is approaching the point limit and when they surpassed it

Mockups

Advanced button - unclicked

Default - in visual mode

Approaching Point Limit - Visual

Past point Limit - Visual

Default - Source - Signed Out

Default - Visual - Signed Out

@Esanders - If you have any confusion during prototyping, just use your judgement, document what you aren't sure about and then we can tag team on it together.

The team will pick this up this week

Change 622343 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] WIP Edit summary in advanced mode

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

In T249391#6409085, @gerritbot wrote:

Change 622343 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] WIP Edit summary in advanced mode

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

Update

• The patch demo linked below [i] implements the core functionality spec'd in this task. It intentionally is not opinionated about interface polish/presentation.
• The patch demo linked below assumes when someone affects the contents of the custom edit summary field without inputting any content into the Reply Tool's text input area, the comment will be considered to be empty. Therefore, the changes to the custom edit summary field will NOT be auto-saved and the Reply Tool will NOT re-open upon the page being reloaded.

Next steps

• @ppelberg to review patch demo [i]
• @ppelberg to share the patch demo [i] on mw.org for community members to try and share feedback

https://patchdemo.wmflabs.org/wikis/23fd7e0b373b74aceaf8ddec1d82ab09/w/index.php/Talk:Main_Page

Hello, I asked somebody to test new demo version, but he did not register new label Advanced (he used tool before). He wrote: "OK then, why not" Short tutorial how to customize summary should be great. What do you think?

To another user I wrote, that he should click on Advanced. He wrote that it is 'interesting"

I found Advanced immediately and I think it is good function for many users. For example at Administrations Noticebord at Czexh Wikipedia admins usually use "(not) done" or something like that (not "reply").

In T249391#6413987, @ppelberg wrote:

Next steps

• @ppelberg to review patch demo [i]

This is looking good, @Esanders. Some "Tweaks" and a "Question" below. [i]

TWEAKS

• A. Until we decide to revise the behavior of the automatic edit summary (T254117), can the Reply summary field be pre-populated as follows /* Section heading */ Reply ?
• B. Can we make it so you can press ⇥ to shift focus from the Reply Tool's text input area to the Advanced link as described below?
  • 1. Write a comment in the Reply Tool (doesn't matter what mode)
  • 2. Press ⇥ have the browser's focus go to the Advanced link
• C. Can we make it so you can press ⇥ to shift focus from the Reply Tool's text input area to the Reply summary field as described below?
  • 1. Write a comment in the Reply Tool (doesn't matter what mode)
  • 2. Click the Advanced link so as to expose the Reply summary field
  • 3. Modify the contents of the Reply summary field
  • 4. Press ⇧ + ⇥ (x2) to have the browser's focus go back to the Reply Tool's text input field
  • 5. Press ⇥ to have the browser's focus go to the Reply summary field (❗️Currently, the browser's focus remains on the Reply Tool's text input at this step)
• D. Can we make it so you can press ⇧ + ⏎ to publish a comment after having written something in the Reply Tool's text input and having the browser's focus be in the Reply summary field?

QUESTIONS

• Why is it that a custom edit summary is retained is "Scenario A" but not retained in "Scenario B"?
  • Scenario A
    • 1. Type a comment in the Reply Tool (shouldn't matter what mode)
    • 2. Click Advanced to expose the Reply summary field
    • 3. Modify the contents of the Reply summary field
    • 4. Reload the page [after bypassing the browser's warning]
    • 5. Notice the Reply Tool opens with the comment you drafted in Step 1 and the Reply summary field and content you drafted in Step 3 intact
  • Scenario B
    • 1. Type a comment in the Reply Tool (shouldn't matter what mode)
    • 2. Click Advanced to expose the Reply summary field
    • 3. Modify the contents of the Reply summary field
    • 4. Click Advanced to hide the Reply summary field
    • 5. Reload the page [after bypassing the browser's warning]
    • 6. Notice the Reply Tool opens with the comment you drafted in Step 1 and the Reply summary field is NOT exposed
    • 7. Click Advanced to expose the Reply summary field
    • 8. Notice the summary you drafted in Step 3 has been discarded

i.

In T249391#6413987, @ppelberg wrote:

• The patch demo linked below [i] implements the core functionality spec'd in this task. It intentionally is not opinionated about interface polish/presentation.

Note: Considering the above, I've limited feedback to the custom edit summary's functionality.

In T249391#6414261, @Patriccck wrote:

Hello, I asked somebody to test new demo version...

Thank you for taking the initiative to try out the patch and share this with others, @Patriccck!

A comment and two follow up questions to the feedback you shared in line below...

In T249391#6414261, @Patriccck wrote:

...he did not register new label Advanced (he used tool before). He wrote: "OK then, why not" Short tutorial how to customize summary should be great. What do you think?

It sounds like for this person, and potentially others, the way the Advanced link is presented within the tool is not obvious enough.

A resulting question for you:

• 1. How did you ask this person to try the Patch demo prototype? I ask this curious to know what this person might've been thinking as they were trying out the prototype.

To another user I wrote, that he should click on Advanced. He wrote that it is 'interesting"

• 2. What did you take their reaction to mean?

...without the context of the interaction it's a bit hard to know what "interesting" means :)

I found Advanced immediately and I think it is good function for many users. For example at Administrations Noticebord at Czexh Wikipedia admins usually use "(not) done" or something like that (not "reply").

This is great to hear.

In T249391#6413987, @ppelberg wrote:

Next steps

• @ppelberg to review patch demo [i]

T249391#6414799

• @ppelberg to share the patch demo [i] on mw.org for community members to try and share feedback

See: https://www.mediawiki.org/wiki/Topic:Vstemnhdi8w8iw95.

In T249391#6414839, @ppelberg wrote:

Thank you for taking the initiative to try out the patch and share this with others, @Patriccck!

A comment and two follow up questions to the feedback you shared in line below...

In T249391#6414261, @Patriccck wrote:

...he did not register new label Advanced (he used tool before). He wrote: "OK then, why not" Short tutorial how to customize summary should be great. What do you think?

It sounds like for this person, and potentially others, the way the Advanced link is presented within the tool is not obvious enough.

Yes, I think it too. I think that this button or label (?) could be difficult to find and use for some users.

A resulting question for you:

• 1. How did you ask this person to try the Patch demo prototype? I ask this curious to know what this person might've been thinking as they were trying out the prototype.

I wrote: "Try reply. There should be a prototype for filling summaries."

To another user I wrote, that he should click on Advanced. He wrote that it is 'interesting"

• 2. What did you take their reaction to mean?

...without the context of the interaction it's a bit hard to know what "interesting" means :)

He wrote, that this new function for filling summaries is interesting. :-) Nothing more, nothing less.

I found Advanced immediately and I think it is good function for many users. For example at Administrations Noticebord at Czexh Wikipedia admins usually use "(not) done" or something like that (not "reply").

This is great to hear.

Needless to say, I use the tool more than all users at cswiki. :-) And I also sawn this post.

All tabbing issues are covered by T172694.

Adding "Reply" and the auto-save issue are fixed in the latest patchest.

I've set it to highlight the word "Reply" when you open the drawer as a compromise to make it easier to remove, as someone editing the commit message will likely not want to use this default text.

In T249391#6416787, @Esanders wrote:

All tabbing issues are covered by T172694.

Roger that. @Esanders: does "D" from T249391#6414799 [i] qualify as a tabbing issue?

I've set it to highlight the word "Reply" when you open the drawer as a compromise to make it easier to remove, as someone editing the commit message will likely not want to use this default text.

Good call.

Adding "Reply" and the auto-save issue are fixed in the latest patchest.

Is this [ii] the right Patch demo wiki to be testing the patchset on? I assume so, considering the patches on which it is built was updated earlier today [iii], but for some reason I'm not seeing the changes you mentioned above implemented. [iv]

i.

D. Can we make it so you can press ⇧ + ⏎ to publish a comment after having written something in the Reply Tool's text input and having the browser's focus be in the Reply summary field?

ii.

In T249391#6418303, @ppelberg wrote:

In T249391#6416787, @Esanders wrote:

All tabbing issues are covered by T172694.

Roger that. @Esanders: does "D" from T249391#6414799 [i] qualify as a tabbing issue?

• As discussed during today's standup, "D" [i] does NOT qualify as a tabbing issue and should be implemented as part of this task.

Adding "Reply"

I can confirm this looks fixed.

...the auto-save issue are fixed in the latest patchest.

Based on what I've seen so far, this does not appear to be fixed. Here is the behavior I've encountered:

1. Visit https://patchdemo.wmflabs.org/wikis/65ba8c5ba1bd0a7be13e324ce9c522d1/w/index.php/Talk:Main_Page
2. Type a comment in the Reply Tool (shouldn't matter what mode)
3. Click Advanced to expose the Reply summary field
4. Modify the contents of the Reply summary field
5. Click Advanced to hide the Reply summary field
6. Reload the page [after bypassing the browser's warning]
7. Notice the Reply Tool opens with the comment you drafted in Step 2 and the Reply summary field is NOT exposed
8. Click Advanced to expose the Reply summary field

Actual

8. ❗️Notice the Reply summary you drafted in "Step 4" has NOT been retained; instead, the default copy – /* Heading name */ Reply – appears

Expected

8. ✅ Notice the Reply summary you drafted in "Step 4" has been retained

i. Assuming you've already written something in the text input are, pressing ⇧ + ⏎ while your cursor is in the Reply summary field should cause the comment you wrote to be posted to the page.

Notes from conversation with Ed:

• icon next to Advanced should be used from OOUI

• The Advanced dropdown will appear underneath preview (as seen in this mockup showing source mode)

• The character counter should show inside the text input.

Update: 2-September
Today, @iamjessklein and I talked about the prospect that people seeking to customize the edit summary that accompanies the comments they write with the Reply Tool might not find it. We decided this is something we should revisit once the functionality is deployed and we've gotten feedback from a larger number of people.

This work will happen here: T261908.

@ppelberg needs to file a ticket for the comment summary auto-save issue (issue d). Will additionally talk to @iamjessklein about what the edit summary field will be called in UI.

In T249391#6447709, @JTannerWMF wrote:

@ppelberg needs to file a ticket for the comment summary auto-save issue (issue d).

Done: T262501

Will additionally talk to @iamjessklein about what the edit summary field will be called in UI.

@iamjessklein and I talked about this and agreed that we'd like for the text that appears above the summary field to read: Comment summary.

Reason: "comment" is the noun many volunteers have used to refer to what the Reply Tool produces.[i][ii][iii][iv][v]

Note: it could turn out that Senior Contributors find this language confusing or undesirable. If that's the case, we can revisit this decision once we have evidence of such.

Next steps

• @iamjessklein to conduct a quick design review

i. https://w.wiki/bep
ii. https://w.wiki/beq
iii. https://w.wiki/ber
iv. https://w.wiki/bet
v. https://docs.google.com/document/d/1jfuWa6T1hYgyhdDFqfRG2HJSpcZ0eAOxeE_plBOOzTk/edit#heading=h.fp4nukpilegf

👍 on design review

Deployment note
Support for custom edit summaries (what this task introduces) can be deployed once it's gone through code review.

Notes

• T261816 is not blocking the deployment of custom edit summaries.
  • Reason: the decisions that depend on T261816 (e.g. how we prioritizeT261539) will be negligibly impacted by the us not having 1-2 week's worth of usage data.
• QA for this task will happen as part of T261477; I've added the custom edit summary test cases as rows 26-30 to the "T261477" sheet in the Reply Tool QA workbook. (We may end up representing this testing differently depending on what @Ryasmeen thinks is best).

Change 622343 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Edit summary in advanced mode

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

@matmarex: I am not seeing any of the fixes for the sub-tasks on Beta cluster. Let me know when they are ready to be tested :)

Automatic updates of the beta cluster were apparently broken. I can't find a task about this, but folks on #wikimedia-releng on IRC confirmed it.

It looks like the latest version is there right now, but I'm not sure if the updates are actually fixed or if someone just updated it manually.

If the beta cluster is still acting funny, then I created a demo wiki on Patchdemo, which you can try using instead: https://patchdemo.wmflabs.org/wikis/d15e6b8ee1e889aa1627639667551df5/w/index.php/Talk:Main_Page (it doesn't have any patches applied, just the current version of the code, that would be on the beta cluster right now if everything worked correctly there).

All other sub-tasks are working on both Beta cluster and Patch Demo, except T263061.