Resolvability of discussions in issues
In order
- https://gitlab.com/gitlab-org/gitlab-ce/issues/30299
- https://gitlab.com/gitlab-org/gitlab-ce/issues/32451
- https://gitlab.com/gitlab-org/gitlab-ce/issues/32452
Description
- When creating a discussion (either by creating the first comment, or converting an existing comment), optionally indicate that it is resolvable.
- When you resolve the discussion, you truly resolve the entire thing. There is no concept of individual comment resolvability.
- This applies to issues, merge requests (non diff), commits, and snippets.
- If a single root comment has no replies, we still show the reply panel so a user can easily reply, resolve, jump to the next discussion, and make an issue from the unresolved comments.
Mockups
Activity
mentioned in issue #32452 (moved)
Updated mockups! cc @DouweM
mentioned in issue #30299 (moved)
@tauriedavis continuing from my comment about the collapse/expand button, I don't think it should be at the same “level” as the actions to interact with the discussion (“Create issue for discussion” and “Jump to next discussion”). Now that I look at this, it makes me want to put the “Reply” and “Mark as resolved” actions with the same visual weight as the button actions, after all these are the most important actions one can have with the discussion.
I'm thinking about a single place with all of the actions, instead of two lines (at least when collapsed). I don't have any particular suggestions (sorry), I guess it's something to experiment with.
@tauriedavis The “Create issue for discussion” and “Jump to next discussion” options really only make sense for unresolved discussions that are expanded by default, so what do you think about only showing those when the discussion is expanded, not when it's collapsed?
I don't think I don't think we need the extra "Expand/Collapse" button, I think the one on the main discussion is fine. People are more likely to expand a collapsed discussion than the other way around, which they can do by clicking anywhere in the "2 replies" widget already.
assigned to @tauriedavis
changed milestone to %Backlog
@tauriedavis yup, that sounds/looks great. Should the checkbox label be “Mark comment as resolvable” to be consistent with the dropdown option? Also, wouldn't it be preferable to verb that option as “Mark asMake it resolvable” to differentiate making a comment resolvable from marking a comment as resolved? And finally, what's the option label for reverting the resolvability of a comment?
added UX label
-
That makes sense to me, thanks @pedroms!
changed milestone to %Next 2-3 months
mentioned in issue #34527 (closed)
mentioned in issue ux-research#21
moved to gitlab#9931
Hey!
GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current
gitlab-cerepository will become a read-only mirror, without any proprietary code. All development is moved to the currentgitlab-eerepository, which we will rename to justgitlabin the coming weeks. As part of this migration, issues will be moved to the currentgitlab-eeproject.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/13855You 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/13855What 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 theee/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/13304Will 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.
