Goal: We want to reduce reliance on conventions and limitations for the patch-based contribution workflow. We want to establish the technical infrastructure for additional data around patches.

Out of scope is solving problems around maintainer coordination. E.g. one out of two maintainers is sufficient to mark a patch as accepted.

User stories

1. As a reviewer I want to see a record of all changes made by the patch author. That is, when the author adds another comment, I should be able to see that a change has happened.
2. As a merge coordinator I want to merge patches without the author needing to rebase them. These patches should show up as accepted.
3. As a maintainer I want to mark patches as rejected so that these patches don’t require my attention.
4. As an author, I want to be able to retract a patch so that maintainers know that it shouldn’t be reviewed anymore.
5. As a reviewer I want to add review comments to a patch so that the patch author can read them and update the patch with any feedback.

Prioritization

All of the user story requires us to add additional data for patches. This requires us to develop a distributed storage mechanism for that data. For that reason, we want to start with a user story that is small in scope.

User story 1 is the most impactful one but also the largest in terms of effort. It requires visual designs.

User story 2 is very specific to our team’s workflow. It also touches on merging patches which we should tackle holistically. It’s not a good candidate to start with.

User story 3 seems to have the right scope for us to tackle.

User Problems for Patches

• Maintainers need a way easily view all the patches that have been submitted in order to find and review the right patch. The current process is convoluted and requires the maintainers to type in the right peer and branch ID in order to pull the right patch.
• Maintainers need a way to easily mark a patch as accepted or rejected. We currently rely on the maintainer merging a patch into their main branch in order to automatically “accept” it. Maintainers should be able to reject a patch so the collaborator knows that additional work is needed

Retracting and rejecting a patch

Two related user stories:

As an author, I want to be able to retract a patch so that maintainers know that it shouldn’t be reviewed anymore.

As a maintainer I want to mark patches as rejected so that these patches don’t require my attention.