<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=498265) </details> <!--IssueSummary end--> ### Context A key challenge that a lot of contributors and maintainers experience with Merge Requests and similar functionality provided by Git-based software development platforms is around the back-and-forth comments while changes are being merged, which essentially makes the MR experience effectively one giant mutable changeset. This concern was also highlighted by Mitchell Hashimoto in his [blog post](https://mitchellh.com/writing/github-changesets) dated September 30, 2023, where he captured the challenges and also provided recommendations based on approaches taken by other platforms. ### Problem to solve Feedback and the state of the MR aren’t tied together. In particular, the state of the MR can get out of sync with feedback/comments, which can make it difficult to review. Some challenges as highlighted in the [blog](https://mitchellh.com/writing/github-changesets): 1. A review can become partially outdated and feedback may not make sense in the context of the changes a contributor pushed. 2. Work-in-progress commits towards addressing review feedback become visible when the branch is pushed. This forces contributors to address all feedback in a single commit, or for reviewers to deal with partially-addressed feedback. 3. You can't easily scrub to prior states of the MR. If you want to review a set of earlier commits while ignoring later commits, you only get the code changes, and you don't also get the point-in-time reviewer feedback. ### Proposal The proposed solution to this experience is using **Changesets**. Aside from addressing the challenges outlined above, one major advantage of this approach lies in the fact that the contributor can post multiple changesets with differing approaches to a problem in a single MR and the maintainer can potentially choose the non-latest changeset as the set of changes they want to see merged. ### Additional Details The changesets approach is also employed by other Git based tools such as [Gerrit](https://graphite.dev/guides/gerrit-change-sets), where each "Change Set" encapsulates a single coherent change to the codebase that is proposed by a contributor. Change Sets in Gerrit offer several benefits that enhance the code review process: 1. Focused Reviews: By encapsulating a specific change, reviewers can concentrate on understanding and evaluating just that change, rather than an entire branch of work. 2. Clear History: Each Change Set represents a logical unit of work, which leads to a cleaner, more understandable commit history. 3. Continuous Integration: The iterative nature of Change Sets aligns well with continuous integration practices, allowing for regular testing and review of small changes. Phabricator, a pre-commit code review workflows service, also provides a [similar experience](https://wiki.freebsd.org/Phabricator#Address_Revision_Feedback).