Improve 'Resolve Thread' Lifecycle for MR Comments
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem to solve
There are 3 different and incompatible ways of using the 'revolve' functionality on MR comments:
- Some developers treat it as the checkbox of a to-do list; as the contributing developer, they will resolve comments as soon as they've made the necessary fixes, so that the thread will be minimized and they can see what they still need to work on.
- Some developers treat it as a way of communicating the resolution of the issue to the reviewer; as the contributing developer, they will resolve the comment once the fix has been committed and pushed, so that the reviewer will be notified.
- Some developers treat it as a gatekeeper in the review process; they feel that only the reviewer, not the contributing developer, should resolve comments, after confirming that the proposed fixes (or the given reasoning for not fixing it) is satisfactory
Intended users
Developers and reviewers
User experience goal
- As the author of an MR, I want to be able to track which issues raised by my reviewer I've handled and which are still to-do, in a way that persists across browser sessions, without affecting anyone else
- As the author of an MR, I want to be able to communicate to my reviewer when I've made the changes requested for a given issue and in which commit, without spamming the MR with a lot of manual 'Done' or 'Fixed in $COMMIT_HASH' comments
- As the reviewer of an MR, I want to know which issues the author thinks they've fixed, so that I don't bug the author with 'you missed this one' comments for issues they're still working on
- As the reviewer of an MR, I want to be able to track which of the issues I've raised have been resolved to my satisfaction
Proposal
- Add user-local 'Done' flag
- Any thread so flagged will automatically be folded in the MR view, just like resolved comments, but only for the user who flagged it
- Any new comments to the thread will automatically clear the flag
- Besides a to-do list for the contributing developer, this would also be useful for other interested parties to persistently hide threads they do not care about
- Add a new state to the existing 'resolved' mechanism: 'Suggest resolved', indicating that the contributor thinks that the issue has been fixed
- Contributor can optionally use a pulldown menu next to the 'Suggest resolved' button to specify a commit from the MR in which the fix was made
- Reviewer is notified by email
- Reviewer can then either resolve the thread permanently or dismiss the proposed resolution
- Only the reviewer (i.e. the user who started the comment thread) sees a big 'Resolve thread' button; other users can still resolve a thread directly, but the option is hidden in the 'more actions' dropdown
Permissions and Security
N/A
Documentation
N/A
Availability & Testing
TBD
What does success look like, and how can we measure that?
N/A
What is the type of buyer?
Unknown
Is this a cross-stage feature?
Unknown
Links / references
Edited by 🤖 GitLab Bot 🤖