Create an interface for .patch files in merge requests
Problem to solve
As a developer using GitLab, I want .patch files to render in merge request comments and threads, so that I can skip the whole process of downloading the patch and reviewing it locally.
Intended users
Generally, anybody who will review and submit merge requests, so, developers and development leads.
User experience goal
The user should be able to attach a .patch file to a merge request, and all other viewers of this merge request should be able to view the patch file as a code diff without downloading it. Applying this patch (similar to how suggestions work) would also be nice.
Not really sure what to do here with large patches, multiple files might be tricky.
Proposal
TBH I don't get how to write this section. Maybe you can help? I'm new to this.
Further details
The current suggestions are useful, but only sometimes. For example, consider the case where we want to suggest replacing one library call with the other - then commenting with a suggestion on a function invocation may break the merge request code when applied (imports would also need to be changed).
Rendering whole .patch files and allowing merge request authors to apply them would resolve that problem.
Permissions and Security
No additional permissions are required, this is just an enhancement to the usual merge request process.
Documentation
Not sure what to write here, the suggesting link to https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements redirects to https://docs.gitlab.com/ee/development/documentation/workflow.html.
Availability & Testing
What does success look like, and how can we measure that?
Success metrics: faster feature delivery from developers (due to reducing friction).
Acceptance criteria: the solution should be able to render the attached .patch files correctly.
What is the type of buyer?
Buyer persona looks like the AppDev Manager - the closest to actual development, will get faster feature delivery times.
Enterprise tier - this is generally more useful for open-source projects or small teams, so I'm guessing Starter.
Is this a cross-stage feature?
Not in my understanding.