Mentions table and 'respond to' lists
Dev: https://dev.gitlab.org/gitlab/gitlab-ee/issues/211
Many people are asking for multiple assignees for merge requests
- Top 2 item on http://feedback.gitlab.com/forums/176466-general/suggestions/4678160-ability-to-assign-merge-request-to-multiple-users
- It comes up frequently in talks with customers (Qualcomm)
- People want to switch from Gerrit which supports is
If you dive in the the matter you always hear that what users want is the ability to see where they should respond. A button in merge requests that says 'respond to' that shows where they are mentioned but have not responded yet. You want to have a list of things you should take action on: https://news.ycombinator.com/item?id=8654897 It can be confusing to have multiple reviewers: https://news.ycombinator.com/item?id=8654952
Functional proposal:
- Users see a 'mentioned in' list of merge requests they were mentioned in.
- Users also see a 'to respond' list of merge requests they were mentioned in but didn't comment in after being mentioned. If they respond but are mentioned again the merge request gets added to the list again.
- We already show the participants in each merge request. With this feature you would also indicate in that list if they responded after their latest mention or not.
Technical proposal:
To make this we should create a mentions/subscriptions table for issues and merge requests. Each subscription can have two boolean attributes: do you need to respond and have you muted this issue or merge request. This muting is something we will have to implement anyway at some point.
I also believe we should make this a CE feature since it is so fundamental.
Sytse
Previously discussed in https://dev.gitlab.org/gitlab/gitlabhq/issues/1711 and https://dev.gitlab.org/gitlab/gitlabhq/issues/1221
We can also call it a mentions table, this is more descriptive but it is strange to add the mute attribute on there.
Maybe muted issues and merge requests still show up in the respond to and you just don't get emails. That would mean we better make muted and subscriptions tables. Muted table should wait for https://dev.gitlab.org/gitlab/gitlabhq/issues/1724 since that basically solves the problem.
Maybe we should not call it mute but unsubscribe, that way the table name and the feature makes sense again.
Jacob
We already show the participants in each merge request. With this feature you would also indicate in that list if they responded after their latest mention or not.
Sounds to me that this way, a MR can never escape the 'someone needs to respond to it' state because every person checking in to get the MR of their 'respond to' list would put the MR back on the 'respond to' list of everybody else in the MR.
Sytse
The MR is only added to your 'respond to' list if you specifically are mentioned. Not if there is an update.
The mentioned in list is less actionable. I'm option for first showing a 'respond to' list to the users. We can add this as a tab on the dashboard.