Page MenuHomePhabricator

Replies v1.0: release replying to specific comments
Open, Needs TriagePublic

Description

Open questions

QuestionTicket
How and where should the preview be represented?T238177
What happens when a contributor attempts to add a table in wikitext, within the reply text box?
What should comments posted using this feature be tagged with in the edit summary?
Should there be a workflow for adding a comment at level 0 within an existing discussion? If so, what should that workflow look like?
What happens when a contributors taps the "person" symbol in the reply box's toolbar?
What – if anything – should be pre-populated in the reply box?
How many levels of indentation does the tool need to support Convention says "undent" after 5 levels; reply-link does so after 8
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?
Should we use existing full page conflict resolution (clunky and unhelpful), or prioritize a new experience?
How should we render multi-line comments?
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? [1]
What happens when Contributor A responds to Contributor B's post that's already received subsequent replies? Is Contributor A's reply appended to the bottom of the discussion? Is it inserted at the point of reply?
What should happen when contributors attempt to manually include characters to indent/outdent and/or sign their comment?
What – if anything – does the software present for unsigned comments?
How should time be represented on the page in "read" mode?

  1. Possibilities include floating titles and contexts (see floating thread titles in Flow)

Details

Related Gerrit Patches:
mediawiki/tools/release : masterStart branching DiscussionTools for wmf/

Event Timeline

ppelberg renamed this task from v1.0: Release replying to specific comments version 1.0 to Replies v1.0: release.Oct 18 2019, 9:32 PM
ppelberg renamed this task from Replies v1.0: release to Replies v1.0: release replying to specific comments.

Change 546462 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/tools/release@master] Start branching DiscussionTools for wmf/

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

Change 546462 merged by jenkins-bot:
[mediawiki/tools/release@master] Start branching DiscussionTools for wmf/

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

During the team's 30-October planning meeting, we identified questions that still need to be answered. Those questions are listed below. They have also been added to the task description.

Open questions

  • What happens when a contributor attempts to add a table in wikitext, within the reply text box?
  • What should comments posted using this feature be tagged with in the edit summary?
  • Should there be a workflow for adding a comment at level 0 within an existing discussion? If so, what should that workflow look like?
  • What happens when a contributors taps the "person" symbol in the reply box's toolbar?
ppelberg updated the task description. (Show Details)Thu, Oct 31, 6:13 PM
ppelberg added subscribers: Esanders, iamjessklein.
ppelberg updated the task description. (Show Details)Thu, Oct 31, 8:31 PM
Jc86035 added a subscriber: Jc86035.EditedWed, Nov 6, 10:17 AM

I feel like it should be obvious that ideally a wikitext table should just work like it normally would? It is technically possible to indent a table in the current software using current discussion formatting conventions, though I think until recently I always used {{outdent}} because I didn't realize that you could do this. (Nevertheless, the use of the table forces the list to end, even if additional list items are placed directly below.)

ppelberg updated the task description. (Show Details)Wed, Nov 6, 4:03 PM

I feel like it should be obvious that ideally a wikitext table should just work like it normally would? It is technically possible to indent a table in the current software using current discussion formatting conventions, though I think until recently I always used {{outdent}} because I didn't realize that you could do this. (Nevertheless, the use of the table forces the list to end, even if additional list items are placed directly below.)

I think you're describing just putting the table non-indented after the list item? Which would be a solution to our problem, I guess, but it isn't a great solution. It's not possible to actually indent a table, as far as I know, unless you use HTML syntax for either the list or the table (which is another not-great solution).

I feel like it should be obvious that ideally a wikitext table should just work like it normally would? It is technically possible to indent a table in the current software using current discussion formatting conventions, though I think until recently I always used {{outdent}} because I didn't realize that you could do this. (Nevertheless, the use of the table forces the list to end, even if additional list items are placed directly below.)

I think you're describing just putting the table non-indented after the list item? Which would be a solution to our problem, I guess, but it isn't a great solution. It's not possible to actually indent a table, as far as I know, unless you use HTML syntax for either the list or the table (which is another not-great solution).

No, it is actually possible to indent a table, for some reason. Try putting this into Special:ExpandTemplates:

:::::::{|class=wikitable
|test
|}

Huh, I had no idea, that indeed works. It only works with : though, not *, so that probably doesn't solve this for us either though.

I tried to figure out how it's implemented, and it's apparently a special case of the table syntax, rather than list syntax. It results in a separate single-item list, not connected to neighbor list items, so it always causes "list gap".

Is the current plan to eventually allow tables to be used without any additional syntactical/formatting difficulty (i.e. would it definitely be possible by version 3)? If so, would changes to the parsing of talk pages be made in the first version?

I think the best resolution for the specific table+indent issue (separate from the talk pages project, since the project could end up using a different solution altogether) would be to properly implement tables within lists and allow them to be used inside all list types, since there are a number of bugs related to this odd special case (e.g. T71699, T8776).

ppelberg updated the task description. (Show Details)Sat, Nov 16, 1:55 AM
ppelberg updated the task description. (Show Details)Sat, Nov 16, 2:01 AM
ppelberg updated the task description. (Show Details)
ppelberg updated the task description. (Show Details)Mon, Nov 18, 9:08 PM
ppelberg updated the task description. (Show Details)Tue, Nov 19, 1:00 PM
ppelberg added a subscriber: Alsee.

Updating task description

Alsee added a comment.Thu, Nov 21, 3:07 AM

I think many of these questions answer themselves when you keep in mind that we're not building a new discussion system, we just want to help the the user more quickly and more easily insert the exact same blob of wikitext they currently do.

How should time be represented on the page in "read" mode?

The time is just a text-blob on the page. Don't mess with the page content, and don't make weird changes to the parser trying to transform it. About the only change to the read-view should be the addition of reply links.

What – if anything – does the software present for unsigned comments?

The new interface isn't expected to detect them, so there's nothing to do here. You just need to add reply-links in the spots where you do detect a comment-signature. Automatic signing in the new interface should largely eliminate this issue anyway.

How many levels of indentation does the tool need to support

I just quicky tested the existing system. It supports at least 200 colons without complaint. In other words there are effectively no technical constraints on this. The wisdom of 200 colons is a social question. Just allow us us to edit or delete the auto-indent markup and can do what we currently do.

What happens when a contributors taps the "person" symbol in the reply box's toolbar?

I think this aspect of Flow that can probably be copied without issue.

What – if anything – should be pre-populated in the reply box?

I've described my vision for this before, but I'll repeat it as it directly relates to every subsequent question in this list:
(1) Show show the indentation markup at the start of the first line. Perhaps make it click-to-edit-or-delete and give it a hover tooltip.
(2) The current demo includes a reply-ping to the previous user. I'm not 100% sure but I lean towards including this by default for replies. It will definitely help ensure posts by new users are seen.
(3) Show ~~~~ at the the bottom right corner, perhaps with a tooltip and click-to-edit-or-delete.
The concept is that the user could copy exactly what is shown in the box, go to the wikitext editor, paste it, and save. It shows both experienced editors and new users exactly what is hapening.

How should we render multi-line comments?

If the user hits enter, it would be good if you can repeat the automated indentation markup on the new line. This is exactly how we do it now, this just auto-generates the usual indentation string.

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

The line starts with the automated indentation, then you just glue on whatever the user types. The user text is just a blob, you don't even need to look at it. When we want a bullet list or number list in the middle of the comment we just add * or # after the automatic indentation markup.

If the user wants to delete or modify the auto-indentation, let them. Don't fight the user, they probably have a good reason.

Regarding ~~~~ or any string that would trigger a reply-link in the middle of a comment, it may be good to detect that and show a caution message. I think we'll want a template or something so we can suppress unwanted reply-links, (i.e. don't show the reply link if a specific magic word appears right after that point.) The most common trigger for a false reply link would probably be quoting comment-with-signature.

What happens when a contributor attempts to add a table in wikitext, within the reply text box?

Again, whatever the user types is a generic blob. We're not changing what the user would have added to the page, and we're not changing how it's displayed. The only issue is that the user needs to be able to delete or alter the automated indentation markup. We typically drop to zero indentation for some kinds of content in the middle of a comment, such as tables or chunks copied from articles or some kinds of quotations. The signature and last part of the comment are usually indented to match the initial indention of the comment.

Should there be a workflow for adding a comment at level 0 within an existing discussion? If so, what should that workflow look like?
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?

I believe there should be a "reply" link after each existing comment, which applies the appropriate indentation. I believe every section should probably have a "Add comment" link at the bottom, which would normally be zero indent. However I think "New Comment" should probably default to a single * or # indentation if the previous top-level-comment has a single * or #. That would almost always be the correct behavior for our "voting" RFC/AFD/RFA type discussions. The first voter will apply a single * or #, and subsequent votes continue it.