Filter discussion (tab) by comments or activity in issues and merge requests
Original proposal
At the moment when you enter a MR you see the following tabs Discussion
, Commits
, Pipelines
, Builds
, Changes
. I believe that everything is fine except the discussion tab. This tab includes also the push activity that a user makes to this MR, labels that are added, if he marked/unmarked the MR with WIP etc. You can clearly see that the Discussion
word does not match here. It's should be named Activity
and more over there should be a tab with only the discussions.
I believe that the first tab a user should see when entering a MR must be the Activity
including what ever the current Discussion
tab has and have another tab Discussion
having only the discussions. This way it will be possible for the users to separate the actual discussion from the push events and you will have the advantage of adding more events on Activity
tab on the future.
Design and requirements
-
For both issues and merge requests.
-
It has the dropdown in the sticky bar, and you can choose to show or hide the system notes. In particular, the two choices are:
- Show all activity: Same behavior as existing. Show all system notes and comments/discussion.
- Show comments only: Show only user comments, including discussion threads.
-
For merge requests, we are using the existing sticky bar, and adding the new dropdown.
- The new dropdown should only appear when you are in the discussion tab.
-
For issues, we are introducing a new sticky bar:
- The new dropdown should be added to the new sticky bar.
- The emoji reactions buttons for the description should be moved into this new sticky bar.
-
Your selection choice is saved to your user, so that if you log into GitLab from any device, your previous selection persists. In particular:
- The first time you log into GitLab (or equivalent, when this feature is deployed for existing users), anytime you visit any issue in the instance, the default choice is
Show all activity
. If at any time you change that setting on any issue, that persists in the system so that next time you visit any issue, that same choice is shown. - Exactly analogous behavior for merge requests.
- These are two separate saved choices per user per instance. So for a given user, there is one choice for all issues in the instance. And there is a separate choice for all merge requests in the instance.
- The first time you log into GitLab (or equivalent, when this feature is deployed for existing users), anytime you visit any issue in the instance, the default choice is
-
Note:
- The emoji reactions bar on issue page will be sticky.
- In this issue, we only focus on the toggle behavior.
Merge request page | Issue page |
---|---|
![]() |
![]() |
Real-time cases
- Suppose you have set the filter to "Show all activity"
- If new data comes in (system activity or comments), they appear on the page as normal (and as expected).
- Suppose you have set the filter to "Show comments only"
- If new comments come in, they appear on the page as normal.
- If new system activity comes in (e.g. new commits, milestone changed), they do not show up, respecting the filter.
Out of scope
- The scope of this issue is the saved choices, the sticky bar updates, and the filtering capability. The new design of how comments appear is not in scope here. This is in https://gitlab.com/gitlab-org/gitlab-ce/issues/29294.