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

added feature proposal label

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)

added frontend ~897282 to schedule labels

changed milestone to %Backlog

@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

removed to schedule 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)

assigned to @tauriedavis

@DouweM Can you review these mockups and see if there is anything from our discussion that I missed?

Comments would work exactly the same when adding a comment to an issue or merge request discussion. You would be able to mark/unmark a comment as resolvable. You can resolve all comments, just as you can today. You can also collapse discussions (threads).

Comments on diffs are slightly different, in that they are always resolvable comments and there is something more specific you are commenting on than the issue/mr as a whole. This doesn't change much about the UI. I've included a design that allows you to still collapse each discussion. This mockup also includes adding multiple discussions to a single line.

@DouweM @victorwu I know this includes more than what is in this scope. I want to make sure we agree on this direction and then we can cut back to just the basics for a first iteration. Let me know your thoughts and if there is anything I missed.

Thanks @tauriedavis !

Not sure if we discussed this explicitly. If we introduce resolvability for issue discussions, would we bring that functionality of skipping to the next unresolved discussion and seeing how many unresolved discussions to issues as well?

@victorwu Yeah, that makes sense. I wonder if it should be "unresolved comments" though, since not every comment in a discussion needs to be resolved - like with diffs.

mentioned in merge request !11352 (merged)

@tauriedavis

Thoughts per image:

1. Ability to mark and unmark a comment as resolvable

What do you think about something like "Needs to be resolved" with a checkmark instead of "Mark as resolveable"? Describing the goal instead of the technical detail.
If we stick with "Mark as resolveable", I think it should be "resolveable"!

2. Replying to a comment

Looks good to me!

3. Ability to resolve all comments that can be resolved

I think we should continue to decide on a per-discussion basis if it is resolvable, instead of per-comment. A resolvable discussion mentions a problem, the comments on that discussion try to find to a solution, and when it is found, the discussion is resolved. It doesn't make sense to me to have a discussion where only 1 comment is resolvable. If that were to happen, it would make more sense to create a new discussion that can be resolved as a whole. So I think the "This comment is resolvable" checkbox and "Resolve all comments" label don't make sense here.
Note that currently, we do allow individual comments to be marked resolved/unresolved, but this is really just because we may find 2 problems in the diff one line, and currently don't have a way to create individual discussion for each. If we did, we could/should let go of resolving individual comments, and only allow this on a per-discussion basis.
Note that when marking an individual root-level comment as resolvable, you are really marking that comment and any subsequent replies on that comment (also known as: the discussion) as resolvable.
We also need an entire discussion to be resolved or not resolved, instead of its individual comments, because we automatically collapse resolved discussions in the Discussion tab, so that people are not distracted by them.
It is currently, and ideally would still be, possible to see on a MR discussion (diff or non-diff) when it was last updated and/or resolved and by whom, even when it is collapsed. This way it’s relatively easy to see when scrolling through the page what changed about the discussions since the last time you viewed it, by looking at those timestamps.

4. Make a comment resolvable initially

Looks good to me, as long as that's the form to create a root comment, not a comment on a discussion. In that case the text should be "This discussion needs to be resolved." or similar, per thought 3.1.

5. Collapsed version

Looks good to me, as long as we address thought 3.2 by showing the last updated/resolved time and author.

6. Commenting on a diff

Looks good to me, but it may be worth showing "This discussion will need to be resolved" in gray on the right of the "Comment" button, just like we have "Please review the contribution guidelines for this project." on https://gitlab.com/gitlab-org/gitlab-ce/issues/new

7. Appears on discussion tab

Looks good to me, as long as we address thought 3.1. and change "Resolve all comments" to "Resolve discussion" as it is now

8. Collapsed version

Looks good to me, as long as we address thought 5.1.

9. Ability to start an additional discussion on the same line

I would add some padding between the discussion and the "Start a new discussion" button.

10. Two discussions on one line

What will it look like when one of those discussions is resolved and collapsed and the other is still relevant?

11. Both appear separately on the discussion tab and are collapsible.

Looks good to me!

Thanks for such detailed feedback @DouweM!

1. Ability to mark and unmark a comment as resolvable

What do you think about something like "Needs to be resolved" with a checkmark instead of "Mark as resolveable"? Describing the goal instead of the technical detail.

I did initially think a checkmark would make sense here. We use this on other dropdowns to indicate an option has been marked. However, the rest of the dropdown are actions, rather than options. And I thought mixing the two would be weird.

If we stick with "Mark as resolveable", I think it should be "resolveable"!

Yes, definitely. This was a typo, that I always seem to make :)

3. Ability to resolve all comments that can be resolved

I think we should continue to decide on a per-discussion basis if it is resolvable, instead of per-comment. A resolvable discussion mentions a problem, the comments on that discussion try to find to a solution, and when it is found, the discussion is resolved. It doesn't make sense to me to have a discussion where only 1 comment is resolvable. If that were to happen, it would make more sense to create a new discussion that can be resolved as a whole. So I think the "This comment is resolvable" checkbox and "Resolve all comments" label don't make sense here.

I feel like this is a limiting use case. Not all comments need to be resolved. And replying to a comment does not necessarily mean that an action needs to be taken. It may be that comments on diffs all need to be resolved, but I'm not sure I buy that every comment within a thread needs to be resolved. This is why I'm trying to push towards not thinking of threads as discussions that need to be resolved as a whole.

Note that currently, we do allow individual comments to be marked resolved/unresolved, but this is really just because we may find 2 problems in the diff one line, and currently don't have a way to create individual discussion for each. If we did, we could/should let go of resolving individual comments, and only allow this on a per-discussion basis.

I would be okay with this for diffs, but I don't think it works for individual comments on issues/mrs that have replies.

Note that when marking an individual root-level comment as resolvable, you are really marking that comment and any subsequent replies on that comment (also known as: the discussion) as resolvable.

I disagree with this. I don't know why it has to be that black and white.

We also need an entire discussion to be resolved or not resolved, instead of its individual comments, because we automatically collapse resolved discussions in the Discussion tab, so that people are not distracted by them.

This makes sense for diff comments, but I'm not sure it makes sense for MR/Issue comments.

It is currently, and ideally would still be, possible to see on a MR discussion (diff or non-diff) when it was last updated and/or resolved and by whom, even when it is collapsed. This way it’s relatively easy to see when scrolling through the page what changed about the discussions since the last time you viewed it, by looking at those timestamps.

Sounds good, I will add that to the mockups.

4. Make a comment resolvable initially

Looks good to me, as long as that's the form to create a root comment, not a comment on a discussion. In that case the text should be "This discussion needs to be resolved." or similar, per thought 3.1.

I don't think it has to be, per 3.

5. Collapsed version

Looks good to me, as long as we address thought 3.2 by showing the last updated/resolved time and author.

Will add that

6. Commenting on a diff

Looks good to me, but it may be worth showing "This discussion will need to be resolved" in gray on the right of the "Comment" button, just like we have "Please review the contribution guidelines for this project." on https://gitlab.com/gitlab-org/gitlab-ce/issues/new

Sure thing, I don't see a problem stating that.

7. Appears on discussion tab

Looks good to me, as long as we address thought 3.1. and change "Resolve all comments" to "Resolve discussion" as it is now

Yeah, lets get to a conclusion on 3 in order to decide this.

8. Collapsed version

Looks good to me, as long as we address thought 5.1.

9. Ability to start an additional discussion on the same line

I would add some padding between the discussion and the "Start a new discussion" button.

Will double check padding.

10. Two discussions on one line

What will it look like when one of those discussions is resolved and collapsed and the other is still relevant?

Great question, will add that in the next iteration.

Biggest thing we need to decide on is individual comments as resolvable vs. entire discussions as resolvable. I'd like to get some more input from other uxers here. @pedroms can you take a look and weigh in on this?

assigned to @victorwu

1. Ability to mark and unmark a comment as resolvable

What do you think about something like "Needs to be resolved" with a checkmark instead of "Mark as resolveable"? Describing the goal instead of the technical detail.

I did initially think a checkmark would make sense here. We use this on other dropdowns to indicate an option has been marked. However, the rest of the dropdown are actions, rather than options. And I thought mixing the two would be weird.

@tauriedavis Fair enough. In any case, part of my concern was about the phrasing "Mark as resolveable". Even though "resolvable discussions" is what we call these internally, the intention behind that action is not so much to mark something as something, but to require that discussion/comment to be resolved in order to move forward with the MR. I don't think "mark as resolvable" is strong enough in indicating that. What do you think about "Needs to be resolved"/"Doesn't need to be resolved" or "Requires/Needs resolution"/"Does not require/need resolution" for the 2 different states?

3. Ability to resolve all comments that can be resolved

I think we should continue to decide on a per-discussion basis if it is resolvable, instead of per-comment. A resolvable discussion mentions a problem, the comments on that discussion try to find to a solution, and when it is found, the discussion is resolved. It doesn't make sense to me to have a discussion where only 1 comment is resolvable. If that were to happen, it would make more sense to create a new discussion that can be resolved as a whole. So I think the "This comment is resolvable" checkbox and "Resolve all comments" label don't make sense here.

I feel like this is a limiting use case. Not all comments need to be resolved. And replying to a comment does not necessarily mean that an action needs to be taken.

Right, I'm not saying that all discussions need to be resolved, I'm saying that a discussion as a whole can be resolvable or not resolvable, but not an individual comment inside a discussion.

So there would be a way to toggle the resolvability of a discussion (which may at that point only consistent of 1 comment), but not of an individual comment inside a discussion. Either all comments in a discussions are resolvable (i.e. the discussion is resolvable) or none of the comments in a discussion are resolvable (i.e. the discussion is not resolvable). A single root comment can be made resolvable, which technically makes it a 1-comment resolvable discussion. Any subsequent replies to that comment become part of that resolvable discussion.

I may not have been clear before, but with that in mind, please read my thought 3 again, and see if it makes more sense now :)

It may be that comments on diffs all need to be resolved, but I'm not sure I buy that every comment within a thread needs to be resolved. This is why I'm trying to push towards not thinking of threads as discussions that need to be resolved as a whole.

But does it make sense to have a thread/discussion consisting 4 comments, only 2 of which needs to be resolved? That implies to me that it's not a thread about 1 subject at all, but rather a thread about 2 subjects, that would have been better off as 2 separate threads. If it was 2 separate threads/discussions, the resolvability status could be a property of the entire discussion, and we could easily collapse that discussion if it is resolved, since we can now regard that discussion as no longer relevant.

If we agree that the intention is for each discussion/thread to represent a single sub-subject of the main issue/MR, whether that be a specific line of code or a part of a proposal someone isn't sure about, wouldn't it make sense to resolve the entire discussion about that subject at once?

Note that currently, we do allow individual comments to be marked resolved/unresolved, but this is really just because we may find 2 problems in the diff one line, and currently don't have a way to create individual discussion for each. If we did, we could/should let go of resolving individual comments, and only allow this on a per-discussion basis.

I would be okay with this for diffs, but I don't think it works for individual comments on issues/mrs that have replies.

Note that when marking an individual root-level comment as resolvable, you are really marking that comment and any subsequent replies on that comment (also known as: the discussion) as resolvable.

I disagree with this. I don't know why it has to be that black and white.

We also need an entire discussion to be resolved or not resolved, instead of its individual comments, because we automatically collapse resolved discussions in the Discussion tab, so that people are not distracted by them.

This makes sense for diff comments, but I'm not sure it makes sense for MR/Issue comments.

4. Make a comment resolvable initially

Looks good to me, as long as that's the form to create a root comment, not a comment on a discussion. In that case the text should be "This discussion needs to be resolved." or similar, per thought 3.1.

I don't think it has to be, per 3.

Biggest thing we need to decide on is individual comments as resolvable vs. entire discussions as resolvable. I'd like to get some more input from other uxers here. @pedroms can you take a look and weigh in on this?

I fail to see the use case for having a discussion consisting of 4 comments, that can all be individually marked as resolvable or not resolvable, and then individually marked as resolved or not resolved. A thread of 4 comments that has 2 non-resolvable comments, 1 resolved comment, and 1 unresolved comment feels to me like it should really have been 3 different discussions.

assigned to @DouweM

mentioned in issue #32451 (moved)

changed title from Start a thread from a non-thread comment to Start a discussion from a non-discussion comment

mentioned in issue #32452 (moved)

changed the description

After reading through this long (but interesting) discussion and weighing in everyone's valid opinions, here are my thoughts:

The dropdown action as “Mark as resolvable” / “Unmark as resolvable” makes more sense as it starts with a verb and is consistent with the rest of the actions. If we were to rephrase the other actions to match “Needs to be resolved”, as an example, “Report abuse” would be “Has abusive content” or similar.
My mental model for this is, starting from the broadest level: Discussions > Discussion (aggregates comments and their replies) > Comment > Replies (in essence they're comments).
A Comment starts a Discussion if it has Replies, and the whole Discussion (read: the first Comment) is resolvable, not its individual Replies.
A Comment may be resolved on its own if it's marked as resolvable, even if it doesn't have replies.
I don't see the need to have “This discussion needs to be resolved” when replying to a comment. However, I do think it's helpful to inform the user of this when starting a new discussion.
The “Start a new discussion” button sounds good, but perhaps “New discussion at this line” is clearer?
Keep the “Reply” icon intact and don't impose the discussion-toggling behavior. Instead, rely only on the “X replies” toggle to open and close the discussion (of course it would need to be visually adapted when opened)
Indenting the replies is crucial for the understanding of discussions and resolvability. I like how @tauriedavis represented that for issue discussions, but that should also be applied to merge requests. Perhaps moving the first comment to the left, aligning it with the code line numbers.
Reducing the visual weight of the replies is also important, maybe with a smaller avatar.

Some different examples for issues and merge requests:

Issue	Merge request

Thanks @pedroms - we came to the same conclusion about resolving the entire discussion yesterday in our meeting so its great you agree. I also think you have some nice ideas in terms of UI and will adapt them to the final designs.

@tauriedavis cool, I'm glad we all got to the same conclusions. That means we're getting this right

… That means we're getting this right

… Or we are all wrong.

I've updated the mockups. I think I addressed all comments.

Threaded comments on issues and mrs:

Resolvable discussions on issue and mrs: https://gitlab.com/gitlab-org/gitlab-ce/issues/32451#note_30065551

Multi-discussions per line on diffs:https://gitlab.com/gitlab-org/gitlab-ce/issues/32452#note_30065762

@tauriedavis nice, thanks! Overall I think it solves the problem, but here are my two thoughts:

What does “Last updated by…” mean? If we're only talking about replies, maybe it could be clearer as “Last reply by…”?
- If we only have one reply, maybe: “John Doe replied about 2 months ago”
- If we have multiple replies from the same person, maybe “2 replies by John Doe” and under it “Last reply about 2 months ago”
I'm not sure about the icon design and placement of the collapse/expand toggle:
- Icon design: it's not the most common design, maybe a simple chevron or triangle would suffice, also because the collapsing/expanding behavior has only one direction, it doesn't expand or collapse from the middle
- Placement: when collapsed, the blue “X replies” link is more visible than the button on the far right side, which is a bit out of the reading flow. When expanded, I would look for the same location of the blue link to collapse the replies. It also looks like it relates to the “Reply…” input as it is inside the same container and very close to it, like a submit button.

mentioned in issue #32645 (closed)

mentioned in issue #20901 (moved)

@tauriedavis Instead of "2 replies[NEWLINE]Last updated by Tim Smith about 2 months ago", what do you think about 2 replies — last by Tim Smith about 2 months ago? This also addresses @pedroms's first point.

@victorwu I see this is assigned to me as a Deliverable for 9.3. Where are we at with this? Who will work on backend for this? Please let me know.

@fatihacet I will work on the backend, but we only finalized the UX on Friday. As you can see a little bit up there are still some questions, but nothing that should block development.

Let me know how you'd like to go about this, and if you think it's easiest for frontend or backend to start!

I think the copy @pedroms suggests makes sense:

2+ replies from multiple people: Last reply by [Name] about [time period] ago
2+ replies from the same person: by [Name] about [time period] ago
1 reply: by [Name] about [time period] ago

@pedroms Was looking at another way to do expand/collapse and this is what I came up with:

Basically I just left the top summary there and you can expand/collapse from there. What are your thoughts?

@fatihacet Most of the UX is finished and I believe you (or whoever from frontend) can get started while we finalize how to expand/collapse.

changed the description

@tauriedavis Nice!

Since we're also going to add this new design for non-diff discussions on MRs, that are resolvable, I was wondering if from https://gitlab.com/gitlab-org/gitlab-ce/issues/32451#note_30065551 we do or do not need those 3 buttons inside the collapsed discussion? As I said in https://gitlab.com/gitlab-org/gitlab-ce/issues/32451#note_30348952, I don't think we do.

@DouweM I agree! I've updated mockups for that view and removed those buttons but was waiting to upload until we have a consensus here.

@tauriedavis I agree with the suggested copy for varying number of replies and the way that is visually represented

I think the expand/collapse is much better like this because it's consistently in the same place. However, to reduce the visual clutter a bit, I would suggest:

Reduce the size of the avatars when the discussion is collapsed, which makes the whole toggle block a bit smaller. Since it already has a light gray background, this shouldn't impair its visual highlighting. Maybe size them like the assignee avatars in the collapsed issue sidebar:
- This reminds me that we need to design a “maximum” state when we have lots of different people replying. Take a look at the multiple assignees issue, where the maximum is 3 avatars and then a +N.
Move the chevron icon from the right to the left, before the avatars
With the toggle block smaller and the chevron before the avatars, we can change the content of the toggle block when it's expanded, so we don't repeat things. Replace the avatars and reply information with “Hide replies” or similar.

Of course, feel free to disagree and improve upon this

assigned to @fatihacet

changed the description

After chatting with @cperessini about this, he brought up two interesting points:

Highlight discussions with new replies (comments not yet seen by the current user)
Option to expand/collapse all discussions, which helps when CMD+F'ing the issue (I consider this a stretch)

changed the description

Highlight discussions with new replies (comments not yet seen by the current user)

@pedroms See https://gitlab.com/gitlab-org/gitlab-ce/issues/27482#note_27689646

changed the description

@tauriedavis : Can you fill in the details / mockups as necessary in the description for the scenarios we talked about. Thanks!

mentioned in merge request !11687 (closed)

@jk thanks, let's discuss that point there.

mentioned in issue #27482 (moved)

Thanks for those suggestions @pedroms! I've included them in the updated design (see description).

@fatihacet The UX here should be finalized now.

changed the description

Thank you @tauriedavis . Can you provide a design for this existing scenario. Thanks.

@victorwu That's in https://gitlab.com/gitlab-org/gitlab-ce/issues/32451#note_30612665, https://gitlab.com/gitlab-org/gitlab-ce/uploads/bfd6e2ced31e2209c6b999a90120f1fe/issues-mr__discussions--resolvable.png

Thanks @DouweM @tauriedavis . I should have looked at the other issue more carefully. I took the comments there and the design and stuck it in the description in this issue.

changed the description

Emojis would appear the same as they do now:

added UX ready and removed UX labels

unassigned @tauriedavis

Moving to 9.4 per https://gitlab.slack.com/archives/C4GD359EJ/p1496685583541310.

changed milestone to %9.4

changed the description

mentioned in merge request !12069 (merged)

@victorwu the reason for moving it, is we weren't able to ship it? But why?

@JobV : During the 9.3 iteration, @fatihacet discovered that additional technical work is required to align the FE code with Vue in order to develop the feature here. That is being done here in 9.4.

OK good luck @fatihacet!

mentioned in issue #34705 (closed)

changed milestone to %9.5

mentioned in issue #34917 (closed)

Maybe I'm missing something, but why do comments need to be unresolvable ever? There may be nothing to resolve, but what's the harm in having the ability to mark it resolved anyway?

It seems to me the main issue is whether there's an indication of comments being unresolved as a potential blocker. So, I think "Needs resolution" is the checkbox we'd want. Either a comment/discussion is marked so that we notice that it needs resolution before we close the issue or merge the MR or we don't get that notice because it doesn't matter.

How about all comments and discussions can be marked resolved but only select ones are marked as "needs resolution" so that there's an expectation of those getting resolved?

changed milestone to %10.0

@victorwu Unfortunatly . We will have to do this for 10.1. We still need to get the refactored finished and @filipa and @fatihacet will be out most of this month.

I'm a little late to this thread but +1 for this feature-request and I just wanted to ask if a simpler version of this implementation would just be an option in the edit dropdown of a comment to convert it into a discussion.

Mostly for me I find that team-members want to start a discussion but accidentally leave a comment.

changed milestone to %10.2

changed milestone to %10.3

mentioned in issue ux-research#21

changed milestone to %Next 3-6 months

When someone creates a comment that should be a discussion I have been copying it into a new discussion as a quote, then replying to that.

I whipped up a greasemonkey script to make that process a little easier:

https://gitlab.com/snippets/1678201

moved to gitlab#9056

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue

Start a discussion from a non-discussion comment

In order

Resources

Description

Technical requirements

Out of scope

Mockups

Last reply by copy:

Designs

Child items ...

Activity

Pros:

Cons:

1. Ability to mark and unmark a comment as resolvable

2. Replying to a comment

3. Ability to resolve all comments that can be resolved

4. Make a comment resolvable initially

5. Collapsed version

6. Commenting on a diff

7. Appears on discussion tab

8. Collapsed version

9. Ability to start an additional discussion on the same line

10. Two discussions on one line

11. Both appear separately on the discussion tab and are collapsible.

1. Ability to mark and unmark a comment as resolvable

3. Ability to resolve all comments that can be resolved

4. Make a comment resolvable initially

5. Collapsed version

6. Commenting on a diff

7. Appears on discussion tab

8. Collapsed version

9. Ability to start an additional discussion on the same line

10. Two discussions on one line

1. Ability to mark and unmark a comment as resolvable

3. Ability to resolve all comments that can be resolved

4. Make a comment resolvable initially

Frequently Asked Questions

Admin message

Admin message

Start a discussion from a non-discussion comment

In order

Resources

Description

Technical requirements

Out of scope

Mockups

Last reply by copy:

Activity

Pros:

Cons:

1. Ability to mark and unmark a comment as resolvable

2. Replying to a comment

3. Ability to resolve all comments that can be resolved

4. Make a comment resolvable initially

5. Collapsed version

6. Commenting on a diff

7. Appears on discussion tab

8. Collapsed version

9. Ability to start an additional discussion on the same line

10. Two discussions on one line

11. Both appear separately on the discussion tab and are collapsible.

1. Ability to mark and unmark a comment as resolvable

3. Ability to resolve all comments that can be resolved

4. Make a comment resolvable initially

5. Collapsed version

6. Commenting on a diff

7. Appears on discussion tab

8. Collapsed version

9. Ability to start an additional discussion on the same line

10. Two discussions on one line

1. Ability to mark and unmark a comment as resolvable

3. Ability to resolve all comments that can be resolved

4. Make a comment resolvable initially

Frequently Asked Questions