Page MenuHomePhabricator

Replies v1.0: release replying to specific comments
Closed, ResolvedPublic

Description

This task description will be updated as new issues/questions come to light.


This ticket contains two lists:

  1. A list of Outstanding issues and
  2. A list of Open questions

Each issue and question contained within the tables below needs to be resolved before Replying v1.0 [1] is deployed to target wikis.


1. Outstanding issues

This list contains a list of the tasks that need "doing".

TicketDescriptionNotesStatus
T243621Create query string parameter to enable/disable DiscussionTools on target wikis-✅ Resolved
T240639Highlighting of the replies is incorrect on Beta cluster-✅ Resolved
T241193Replies with <gallery>...</gallery> tags do not render in preview properly-✅ Fixed
T241393Abandon changes dialog appears unexpectedly-✅ Fixed
T241861[Regression] Reply link disappears from a talk page after editing it from source mode-✅ Fixed
T238177Implement revised approach to previewing reply-Needs QA
T242184Create a change tag for edits made using DiscussionTools-In progress
T243364Instrument replying workflow-Ready for development

2. Open questions

This list contains questions that need to be "discussed" / "decided upon."

QuestionTicket/linkNotesStatus
What indentation syntax should the reply tool output when a contributor is replying to a "0th comment"?Near-term: the Reply tool will output : to indent a "level 1" comment. Longer-term: this approach may need to be changed to meet the needs of wikis that use different indenting conventions.🕰 Revisit
What wikitext should reply tool use for indentations? Does the tool inherit what syntax is used on a given page, does it use : in all cases? Context: when bullets are used for indentations (e.g. on ru.wiki), multi-line comments will render on the page as if they are separate comments unless contributors manually insert <br> tags as has been done here.Topic:Vcehgf0nr8rpi26a + Topic:Vejyl1e4sy0af5edNear-term: the reply tool will inherit the indentation syntax the comment "above it" uses. E.g. if you are responding to a comment that is indented with * your response will be indented using **). Longer-term: TBD. Depends – in part – on how T230683 is resolved.🕰 Revisit
What should happen when a discussion gets deleted/archived/moved while you're reading it?T235923#5741147This will not be addressed in v1.0. We are going to await to see how contributors use v1.0 in production before revisiting this potential issue🕰 Revisit
What should happen when you get blocked while composing a reply?T235923#5741147This will not be addressed in v1.0. We are going to await to see how contributors use v1.0 in production before revisiting this potential issue🕰 Revisit
How – if at all – should the reply workflow support the creation of a == new section ==?T241388v1.0 will not support the creation of a == new section ==🕰 Revisit
In long threads the reply textbox is a long way from the comment it is replying to (and the “Reply” button)...how should we handle/display the page when a lot of text means that there is a big gap between the original comment to which someone is attempting to reply, and the place where the reply will go? Where should the affordance for replying go? At the end of the original comment or the place where the reply will end up? [2]Topic:Vcpciv1kcnows4p5This will not be addressed in v1.0. We are going to await to see how contributors use v1.0 in production before revisiting this potential issue.T254208
What should happen when contributors attempt to manually include characters to indent/outdent and/or sign their comment?v1.0 will not support outdent templates. We will revisit this question as part of T236918, when we think about the treatment of pages in read mode🕰 Revisit
Should there be a workflow for adding a comment at level 0 within an existing discussion? If so, what should that workflow look like?v1.0 will NOT support adding a comment at level 0 of an existing discussion. TBD whether this comes as part of Replying v1.1 (T233446) or Starting a new discussion (T233446)🕰 Revisit
What can be done to ensure contributors drafting replies in long conversations always have the text-input visible/accessible, even while scrolling to see an earlier portion of the conversation ?Topic:Vcpciv1kcnows4p5This will not be addressed in v1.0. We are going to await to see how contributors use v1.0 in production before revisiting this potential issue.🕰 Revisit
How could the replying workflow be improved to make it easier for contributors to "locate" a reply they have already started drafting on lengthy talk pages?Topic:Vcpciv1kcnows4p5This will not be addressed in v1.0. We are going to await to see how contributors use v1.0 in production before revisiting this potential issue.T254208
How might the workflow be enhanced to support contributors seeking to reply to multiple comments on the same page?Topic:Vcpciv1kcnows4p5This will not be addressed in v1.0. We are going to await to see how contributors use v1.0 in production before revisiting this potential issue.🕰 Revisit
How many levels of indentation does the tool need to support Convention says "undent" after 5 levels; reply-link does so after 8Right now, there is no limit on the number of levels of indentation the tool will support. We do not have plans to implement any "outdenting rules" at this time.✅Resolved
How should the new replying workflow react to edit conflicts?T235923#5741147 + T240643DiscussionTools will use the same error handling as VE. See: T240519✅Resolved
If a contributor has a reply drafted and then presses "Escape," the text input area closes without warning; however, their draft is retained and can be accessed by clicking the same "Reply" link...how should this behave? Should contributors be warned? Should there be some visual indication to make contributors aware they have a draft pending?For now, contributors should be warned they will lose their changes. This approach may change when more robust auto-saving is added T240257✅Resolved
How should the software render multi-line comments?Currently, multi-line comments work in the same way they would on existing talk pages. The key difference with the new replying workflow is the software automatically calculates indentation depth and inherits the indentation syntax from the comment being replied to.✅Resolved
Currently, when Contributor A responds to Contributor B's post that's already received subsequent Replies 1, 2 and 3, Contributor A's reply (Reply 4) is appended to the bottom of the discussion, beneath Replies 1, 2 and 3, why is this so?Child comments are indented beneath their parents and newer comments are shown after older comments. This will be the logic in v1.0. Although, this may need to be adapted to meet a specific wiki's conventions.✅Resolved
What – if anything – should be pre-populated in the reply box?v1.0 of the reply text-input area will not be pre-populated with any text. This will be introduced in v1.1 (T236916)✅ Resolved
What happens when a contributor attempts to add a table in wikitext, within the reply text box?Near-term: we are assuming the real-time preview will provide contributors sufficient feedback to know what kind of syntax is supported and what syntax is not supported (e.g. indented tables). Longer-term: they might be supported. Depends on how T230683 is resolved.✅ Resolved
How might the replying text input more clearly communicate to experienced contributors how the workflow behaves (e.g. How and when does the reply workflow prepend indentation syntax?T238177For now, we are assuming the real-time preview will provide contributors the feedback they will need to understand how the software behaves. We might need to revisit this approach in a future iteration.✅ Resolved
How should time be represented on the page in "read" mode?T240360Version 1.0 will not include any changes to how time is represented to contributors in read mode. Instead, we will address this as part of v2.1 – T236918 – wherein we will focus on enhancing, "...the talk page read experience to help contributors more easily understand Talk Pages are spaces for discussion and how to participate in existing conversations."✅ Resolved
What level of indentation do replies to the first comment get? Do we assume they are replies to the first comment itself, or new sub-threads within the topic?For now, the software assumes replies to comment at indentation level 0 should be indented at indentation level 1✅ Resolved

  1. v1.0: T235592
  2. Possibilities include floating titles and contexts (see floating thread titles in Flow)

Related Objects

StatusSubtypeAssignedTask
OpenNone
Resolvedppelberg
Resolvediamjessklein
DuplicateNone
ResolvedEsanders
Resolvedppelberg
Resolvedmatmarex
ResolvedEsanders
Resolvedmatmarex
ResolvedEsanders
Resolvedppelberg
Resolvedppelberg
Resolvediamjessklein
Resolvedppelberg
ResolvedRyasmeen
Resolvedppelberg
Resolvedppelberg
Resolvedppelberg
Resolvedmatmarex
ResolvedEsanders
Resolvedmatmarex
Resolvedmatmarex
Resolvedppelberg
Resolvedppelberg
Resolvedppelberg
Resolvedppelberg
Resolvedppelberg
ResolvedWhatamidoing-WMF
ResolvedRyasmeen
Resolvedmatmarex
Resolvedmatmarex
InvalidNone
OpenNone
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
OpenNone
DeclinedNone
DuplicateNone
Resolvedppelberg
DuplicateNone
OpenNone
OpenNone
Resolvedppelberg
ResolvedEsanders
Resolvedppelberg
ResolvedJdforrester-WMF
ResolvedNone
ResolvedGilles
DuplicateNone
DuplicateNone
ResolvedSecuritysbassett
ResolvedEsanders
Duplicateppelberg
OpenNone
Resolvedmatmarex
ResolvedEsanders
Resolvedmatmarex
ResolvedDLynch
DuplicateDLynch

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
ppelberg updated the task description. (Show Details)Jan 6 2020, 1:16 AM

Updating the task description to include the question below, raised in T241388:

  • How – if at all – should the reply workflow support the creation of a == new section ==?
ppelberg updated the task description. (Show Details)Jan 6 2020, 4:10 PM
ppelberg updated the task description. (Show Details)EditedJan 6 2020, 10:40 PM

Updating the task description to include the question @Esanders raised today in the context of T241388:

  • How might we me track whether the new replying [and previewing] workflow causes an increase in the number of syntax errors? | T241388#5779747
ppelberg updated the task description. (Show Details)Jan 8 2020, 1:07 AM
Restricted Application added a subscriber: Liuxinyu970226. · View Herald TranscriptJan 8 2020, 1:07 AM
ppelberg updated the task description. (Show Details)Jan 8 2020, 1:18 AM
ppelberg updated the task description. (Show Details)Jan 8 2020, 1:35 AM
ppelberg updated the task description. (Show Details)Jan 8 2020, 2:21 AM
ppelberg updated the task description. (Show Details)Jan 8 2020, 2:39 AM
ppelberg updated the task description. (Show Details)Jan 8 2020, 2:46 AM
ppelberg updated the task description. (Show Details)Jan 8 2020, 6:09 AM
ppelberg updated the task description. (Show Details)

Task description update per T240360#5788185:

  • REMOVED: "T240360 | Determine our approach for v1.0 for displaying date and time... "
ppelberg updated the task description. (Show Details)Jan 8 2020, 10:13 PM

Updating the task description to include the ideas @MMiller_WMF + @Whatamidoing-WMF raised during today's staff meeting:

  • How might the replying text input more clearly communicate to experienced contributors how the workflow behaves (e.g. How and when does the reply workflow prepend indentation syntax to "your" comment?)
    • This relates to to a point @Alsee raised in T235923#5680589 in response to: "What – if anything – should be pre-populated in the reply box?"

I was far more concerned with helping new users understand. The product currently hides-from-the-user what they are doing. That's unhelpful.

I also expect experienced users will be frustrated if functionality is crippled. We shouldn't have to go back to full-page-editing just because the new software prohibits us fixing incorrect software-generated indent markup, or otherwise pointlessly restricts what we can do.

ppelberg updated the task description. (Show Details)Jan 11 2020, 12:49 AM
ppelberg updated the task description. (Show Details)Jan 11 2020, 1:51 AM
ppelberg updated the task description. (Show Details)Jan 11 2020, 2:02 AM
ppelberg updated the task description. (Show Details)
ppelberg updated the task description. (Show Details)
ppelberg updated the task description. (Show Details)Jan 11 2020, 2:21 AM
ppelberg added a comment.EditedJan 13 2020, 12:35 AM

Task description update
The task description has been updated to include the outstanding issues and questions we will need to resolve before v1.0 can be deployed.

Note: as new, blocking, questions and issues emerge, we will continue to document them on this ticket.

ppelberg updated the task description. (Show Details)Jan 13 2020, 12:35 AM
Alsee removed a subscriber: Alsee.Jan 13 2020, 3:47 AM
Jc86035 added a comment.EditedJan 13 2020, 5:57 PM

How many levels of indentation does the tool need to support

For what it's worth, {{outdent}} on the English Wikipedia has a default of 10. I've almost never seen it used at 5 levels. I think for 1.0 it would be acceptable to never outdent, particularly since the existing outdent templates are not consistent across wikis. (In future versions it might make sense to introduce a parser function or CSS class to avoid having to rely on templates.)

Currently, when Contributor A responds to Contributor B's post that's already received subsequent Replies 1, 2 and 3, Contributor A's reply (Reply 4) is appended to the bottom of the discussion, beneath Replies 1, 2 and 3, why is this so?

This is the English Wikipedia convention. (As such, it's more or less the de facto convention used on the multilingual projects.) The comment sort order is based primarily on the parent–child comment relationships and secondarily on their chronological order, with parent comments before child comments and then older comments before newer comments. This generally makes sense on the English Wikipedia, because this holds true for everything on the talk page (including sections, which are ordered based on the date of the oldest comment). A few wikis put new sections at the top on some or all pages (e.g. the Russian Wikipedia village pumps), probably because of some perceived advantages – most likely, that more recent sections are likely to be more relevant; this would be a valid justification for changing the visible sort order of the comments as well. I don't know which projects do that for comments, but allowing comments to be sorted in the interface would probably be much less troublesome than actually forcing people to order replies differently. Following the English Wikipedia convention regardless of community preferences is the "do nothing" option, and I think it would make sense for 1.0 if it won't be problematic.

It's probably worth figuring out the comment and section sort orders for all of the communities involved before inadvertently forcing any of them to deal with the software suddenly ignoring their preferred sort order.

What should happen when contributors attempt to manually include characters to indent/outdent and/or sign their comment?

Reply-link now has check boxes for the former, but not the latter. Later on I think it would make sense to show a warning pop-up somewhere (though it probably shouldn't take the cursor focus away from the text area), but in 1.0 I think it could be acceptable to do nothing.

ppelberg updated the task description. (Show Details)Jan 15 2020, 4:59 PM

Update to task description:

  • Updating the "Status" of issues listed in the "Outstanding issues" table.
ppelberg updated the task description. (Show Details)Jan 20 2020, 8:39 PM

Thank you for these comments, @Jc86035. Responses to the points you raised follow.


How many levels of indentation does the tool need to support

For what it's worth, {{outdent}} on the English Wikipedia has a default of 10. I've almost never seen it used at 5 levels. I think for 1.0 it would be acceptable to never outdent, particularly since the existing outdent templates are not consistent across wikis. (In future versions it might make sense to introduce a parser function or CSS class to avoid having to rely on templates.)

Agreed. V1.0 will not have any "outdent logic" incorporated into it.

Currently, when Contributor A responds to Contributor B's post that's already received subsequent Replies 1, 2 and 3, Contributor A's reply (Reply 4) is appended to the bottom of the discussion, beneath Replies 1, 2 and 3, why is this so?

This is the English Wikipedia convention. (As such, it's more or less the de facto convention used on the multilingual projects.) The comment sort order is based primarily on the parent–child comment relationships and secondarily on their chronological order, with parent comments before child comments and then older comments before newer comments. This generally makes sense on the English Wikipedia, because this holds true for everything on the talk page (including sections, which are ordered based on the date of the oldest comment). A few wikis put new sections at the top on some or all pages (e.g. the Russian Wikipedia village pumps), probably because of some perceived advantages – most likely, that more recent sections are likely to be more relevant; this would be a valid justification for changing the visible sort order of the comments as well. I don't know which projects do that for comments, but allowing comments to be sorted in the interface would probably be much less troublesome than actually forcing people to order replies differently. Following the English Wikipedia convention regardless of community preferences is the "do nothing" option, and I think it would make sense for 1.0 if it won't be problematic.

It's probably worth figuring out the comment and section sort orders for all of the communities involved before inadvertently forcing any of them to deal with the software suddenly ignoring their preferred sort order.

You explained this logic clearly – thank you. In v1.0, the software will indent child comments beneath their parents and newer comments will be shown beneath older comments. Although, to the point you raised, this logic may need to be adapted to meet a specific wiki's conventions.

What should happen when contributors attempt to manually include characters to indent/outdent and/or sign their comment?

...in 1.0 I think it could be acceptable to do nothing.

Agreed. v1.0 will not support outdent templates. We will revisit this question as part of T236918, when we think about the treatment of pages in read mode

20-Jan updates to task description:

  • REMOVED: T242466 from "Outstanding issues"; see this comment for explanation: T242466#5814371
  • ADDED: What indentation syntax should the reply tool output when a contributor is replying to a "0th comment"?
  • RESOLVED: What should happen when contributors attempt to manually include characters to indent/outdent and/or sign their comment?
  • RESOLVED: Currently, when Contributor A responds to Contributor B's post that's already received subsequent Replies 1, 2 and 3, Contributor A's reply (Reply 4) is appended to the bottom of the discussion, beneath Replies 1, 2 and 3, why is this so?~~
  • RESOLVED: How many levels of indentation does the tool support?
  • RESOLVED: How does the software render multi-line comments?\
ppelberg updated the task description. (Show Details)Jan 20 2020, 10:00 PM
ppelberg updated the task description. (Show Details)Jan 23 2020, 1:08 AM
ppelberg updated the task description. (Show Details)Jan 23 2020, 10:35 PM
ppelberg updated the task description. (Show Details)Jan 23 2020, 10:39 PM

23-Jan

  • UPDATED the "Status" of each of the "Outstanding issues" in the task description
ppelberg updated the task description. (Show Details)EditedJan 24 2020, 6:58 PM
ppelberg updated the task description. (Show Details)

24-Jan

ppelberg updated the task description. (Show Details)Jan 24 2020, 7:00 PM
ppelberg updated the task description. (Show Details)Jan 25 2020, 12:34 AM
ppelberg updated the task description. (Show Details)Feb 3 2020, 10:51 PM
ppelberg updated the task description. (Show Details)Feb 3 2020, 10:56 PM
ppelberg updated the task description. (Show Details)
ppelberg updated the task description. (Show Details)
ppelberg updated the task description. (Show Details)Feb 5 2020, 12:39 AM
ppelberg updated the task description. (Show Details)

5-Feb

  • REMOVED: T241391 from "Outstanding issues"
    • Rationale: T241391#5830536 resolves the issue that prevented the comment parser from being able to handle comments that contain varying levels of indentation within them. An open question remains about whether the current approach we've taken to detecting comments (T241391#5849380) is the correct one. Although, this is something we can evaluate most effectively after DiscussionTools are deployed to on live wikis. For the work evaluating the reliability of the comment parser, please see this task: T244432
ppelberg updated the task description. (Show Details)Feb 6 2020, 12:59 AM
ppelberg updated the task description. (Show Details)Feb 7 2020, 7:21 PM
ppelberg updated the task description. (Show Details)Feb 10 2020, 3:12 AM

10-Feb: update

JTannerWMF added a subscriber: JTannerWMF.

This task is now redundant and can be closed.

ppelberg closed this task as Resolved.Feb 11 2020, 11:38 PM
ppelberg updated the task description. (Show Details)

We are not doing anything to resolve edit conflicts; that will happen in T240643

Extra context: the remaining open tasks [1] and their respective levels of priority are reflected on the tasks themselves.


  1. T238177 T242184 T243364
ppelberg updated the task description. (Show Details)Jun 2 2020, 12:57 AM

Updating the task description to include the ticket (T254208) where we will examine the following issues:

In long threads the reply textbox is a long way from the comment it is replying to (and the “Reply” button)...how should we handle/display the page when a lot of text means that there is a big gap between the original comment to which someone is attempting to reply, and the place where the reply will go? Where should the affordance for replying go? At the end of the original comment or the place where the reply will end up?

How could the replying workflow be improved to make it easier for contributors to "locate" a reply they have already started drafting on lengthy talk pages?