Start a discussion from a non-discussion comment

cc @smcgivern @DouweM @tauriedavis : I don't think this is a high priority. But I found it so fun playing with #24378 (closed) that I anticipate many people will ask for this once #24378 (closed) is released.

I highlighted a couple of edge cases above. Definitely just opinions and will defer to good design and clean code.

added ~874211 label

If there is an existing comment, you turn it into a thread by adding a second comment. In other words, there can never be any threads that only have only one comment.

I think this would break consistency with the diff notes, unless you consider the diff itself the first comment? I don't think that consistency is essential from a UX perspective, though.

Should this feature supersede https://gitlab.com/gitlab-org/gitlab-ce/issues/24378? Namely this can be the new design, which is exactly Slack:

If there is an existing comment, you turn it into a thread by adding a second comment. In other words, there can never be any threads that only have only one comment.

@victorwu I very much disagree with this. As a reviewer, I want to be the one to decide user whether a comment of mine is a discussion that needs to be resolved or just a passing comment. That's not something for the MR author or any other commenter to decide.

Our discussions are like Slack threads but more powerful, and we shouldn't reduce that power to be more like Slack.

I know you said:

Let's start with issue comments, commits, snippets, and not consider merge request resolvable discussions for now, since resolvability is more complexity. We can cover that in the next issue.

But we should strive for internal consistency between MR and issues more than GitLab/Slack consistency.

I think it's perfectly reasonable to allow new discussions to be created (as in https://gitlab.com/gitlab-org/gitlab-ce/issues/24378) and allow existing individual comments to be turned into discussions by replying to them.

I would really like this change! Whenever I find myself wanting to use the "start discussion" feature, it's usually in response to another comment, and it would be makes sense to be able to turn that comment into the root of the discussion thread.

This change exactly! Was looking if there was already an issue for this! Very much appreciated if this is possible.

1 level deep max
we can do it like slack with an icon in the comment actions

As a next iteration on this again, we may look into starting a discussion on existing images in discussions, that way solving https://gitlab.com/gitlab-org/gitlab-ce/issues/24816

Yup there is now a glaring need for this because the existing feature of start discussion begs for it .

@DouweM : Would it be a relatively small update to add this? Seems like a good one we can consider for 9.3. We'd need some UX. But I don't see the existing UI changing much to support it.

What happens when you have a thread and start deleting comments from it? Proposal is that if you keep deleting comments from it, and there is only one comment left, it is "demoted" into a regular non-thread comment.

I think it can stay discussion for a first iteration.. or otherwise we'd have to add a system note with deleted all subcomments demoting to normal comment ... or something like that, as there is a system note with "started a discussion" (like where is that discussion now?)

@DouweM : Would it be a relatively small update to add this? Seems like a good one we can consider for 9.3. We'd need some UX. But I don't see the existing UI changing much to support it.

@victorwu For the backend, it's a small change. For the frontend, potentially more involved, since clicking the "Reply in new discussion" (or w/e) button should display the note as if it were a discussion and focus on the text field, but when canceling, it should go back to being a normal note again. So after clicking "Reply in new discussion", we have to display it on the frontend as a discussion, but not actually turn it into a discussion on the backend yet.

@victorwu good idea, looking forward to this

@DouweM : Do you have cycles to work on this in 9.3? (Assuming that you would want to continue this, as opposed to say someone on @smcgivern 's team.)

mentioned in issue #29795 (moved)

@victorwu I think so, yeah, with help from ~Frontend. There shouldn't be much Backend work needed here.

@tauriedavis : Do you think we can have some final UX here in time for 9.3?

@jschatz1 : Let's do this for 9.3? I think everyone in GitLab would use it!

Yep, I think thats doable!

assigned to @tauriedavis

mentioned in issue #31313 (closed)

@victorwu I think that's a great idea.

changed milestone to %9.3

added Deliverable label

mentioned in issue #31520 (closed)

@victorwu Check out this flow and let me know what you think. With abuse and threaded comments being added to the actions, I think we need to collapse some - I've added this in the mockups here. Let me know if you'd like to split this into separate issues.

With threaded comments, I don't think the comment toggle is necessary anymore and can be changed back to just being "comment".

Does anyone see why this would still need to be in the ui?

@tauriedavis "Start a thread" sounds wierd. Other than that it looks great.

@jk I took that copy directly from Slack, to be honest. But open to better suggestions.

Maybe "Reply in new thread"?

… or just plain "Reply" could be enough since it shows indented form without doing anything else.

@tauriedavis

With threaded comments, I don't think the comment toggle is necessary anymore and can be changed back to just being "comment".

Does anyone see why this would still need to be in the ui?

I'd like to propose to add just another button named something like Start a discussion next to Comment one.

Pros:

A user will have to make only one click to add either a comment or a thread.
If a user makes a mistake (click to wrong button), it'll be nothing, because we will give him an ability to convert comment -> thread and vice versa.

Cons:

One more button might confuse a user. But I'm not sure, especially if we add an icon to each button (does it fit current design guidelines?).

What I don't like in current implementation is that it makes me make 3 clicks to start a thread/discussion.

I think "Reply" works, I updated the copy. Thanks @jk

@blackst0ne I'm not sure I understand the need for your proposal. It sounds like you want to pull out the dropdown button and make the comment box have four buttons: Comment, Start a discussion, Comment & close issue, and Discard draft. I am arguing that with this issue and the new design, a "Start a discussion" button in the comment form is not necessary. Each individual comment will have an icon that is used as a way to reply to that individual comment (ie. start a thread, like in Slack). This only requires two clicks (Click "Reply" and then click "Comment"). I don't feel this is too many clicks and follows the same user flow as replying to a thread in an MR diff.

I think making the distinction between comment and discussion is unnecessarily complex with this design.

@tauriedavis : Earlier in this thread. Scroll way up (https://gitlab.com/gitlab-org/gitlab-ce/issues/30299#note_26609931), @DouweM explains why he thinks we should still keep the ability to start a thread at the outset, for consistency essentially.

As for the designs (https://gitlab.com/gitlab-org/gitlab-ce/issues/30299#note_26609931), they look great. Only question is regarding the new "meatballs menu" (https://twitter.com/lukew/status/591296890030915585). I think this would be a brand new UI element in GitLab? Wanted to confirm this is the first place we would be using something like this for collapsing, and why meatballs is good, as opposed to say kebab.

I don't see any reason why to have menu on "Comment" button. You add comment, then later you hit reply to start a thread there. That's it. Anything else is redundant and pollutes UI.

hahah I haven't heard that called a meatball menu before @victorwu. We use "kebob" on the profile page:

They are both overflow menus. An ellipses is commonly known as meaning "there is more here," which is why I chose that version. I don't have a brilliant reason for one over the other, they both are just meant as a means of accessing overflow information. We can use the Kebob to be consistent with the profile.

I don't see any reason why to have menu on "Comment" button. You add comment, then later you hit reply to start a thread there. That's it. Anything else is redundant and pollutes UI.

I completely agree here. I don't understand the consistency comment. MR's create resolvable discussions, issues do not. They are inherently inconsistent.

Thanks @tauriedavis . I didn't pay attention to mobile. That's great. So we should still use meatball then and not use kebab to be consistent?

Consistency sounds good - updated to kebob!

removed assignee

mentioned in issue #31652 (closed)

@victorwu @tauriedavis In the current design, are we getting rid of the "Comment"/"Start discussion" toggle, or not?

As I've described earlier in https://gitlab.com/gitlab-org/gitlab-ce/issues/30299#note_26609931, I'm very much opposed to removing it, since it would cripple the "Start discussion" functionality, which was never intended to just add threads like in Slack, but explicitly designed as a code review feature: to leave feedback that the user needs to resolve, that is not connected to a specific piece of diff, but more generic like "Please add a changelog item" or "Did you check how this affects the API?". These need to start out as resolvable discussions to ensure they're not forgotten about by either the MR author or reviewer. See https://gitlab.com/gitlab-org/gitlab-ce/issues/24378 and https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7527.

On issues, deciding up front if something needs to be a discussion or a regular comment doesn't seem as useful, but on merge requests this is an absolute must. We could get rid of the toggle on the issues, snippets and commit pages, and only keep it on the MR page, but that breaks consistency.

The mockups in https://gitlab.com/gitlab-org/gitlab-ce/issues/30299#note_28612600 currently don't support such a discussion that doesn't yet have any replies, and the proposal in "What happens when you have a thread and start deleting comments from it? Proposal is that if you keep deleting comments from it, and there is only one comment left, it is "demoted" into a regular non-thread comment." is also incompatible with this.

I think this discussion is getting muddied by seeing discussions as the same thing as (Slack) threads, which they are not, especially on merge requests.

@DouweM Starting a discussion just to make a comment "resolvable" is a well hidden feature. The use-case makes sense, but implementation via starting a discussion feels more like an accident, than a feature.

@jk Perhaps, but then we should come up with a new UX that is more obvious instead of removing the feature :)

@tauriedavis : Can you provide a design that includes starting a thread with the initial comment, per https://gitlab.com/gitlab-org/gitlab-ce/issues/30299#note_29124779. Thanks!

I don't think starting a thread from an initial comment makes sense. I think creating a resolvable comment initially does make sense but I left that off per:

Let's start with issue comments, commits, snippets, and not consider merge request resolvable discussions for now, since resolvability is more complexity. We can cover that in the next issue.

I think this might start a larger conversation that might be better for a separate issue but it makes sense to me that there is only one type of comment and that comment can either be resolvable or not. I know we've discussed this before but I do not see the difference between a discussion, a resolvable discussion, and a comment. There may be a difference code-wise, but from a user perspective you have:

A comment
A comment that you can resolve

You can respond to a comment, and this creates a thread of comments. Any comment can be turned into a comment that can be marked as complete.

I agree with @jk about the current UI being hidden. I am not advocating for removing the feature, either.

I think each comment should have a way to make it resolvable. On create or edit, there can be a checkmark that allows you to make it resolvable and this would work for all areas that have comments.

Thoughts?

@tauriedavis This sounds good.

Maybe a better wording on the checkbox: "This comment needs to be resolved." … With a small question mark which explains what happens next (like the one next to time tracking in the sidebar). The "resolvability" on its own is too passive — the label should suggest there will be another action later.

Yep, that works for me @jk

mentioned in issue #32044 (closed)

Start a discussion from a non-discussion comment

Applies to

Out of scope

Description

Reply button

Designs

Child items ...

Activity

Pros:

Cons:

Start a discussion from a non-discussion comment

Applies to

Out of scope

Description

Reply button

Relates to

Activity

Pros:

Cons: