Author's Checklist

Give the PR a descriptive title, so that other members can easily (in one short sentence) understand what a PR is about
Every PR should have a proper, that shows the reviewer what has been changed and why.

Adding someone less familiar with the project or the language can aid in verifying the changes are understandable, easy to read and increase the expertise within the team.
It is important to include reviewers from both organizations for knowledge transfer.

Resolve a comment, if the requested change has been made.
Mark the comment as "won't fix", if you are not going to make the requested changes and provide a clear reasoning
- If the requested change is within the scope of the task, "I'll do it later" is not an acceptable reason!
- If the requested change is out of scope, create a new work item (task or bug) for it.
If you don't understand a comment, ask questions in the review itself as opposed to a private chat
If a thread gets bloated without a conclusion, have a meeting with the reviewer (call them!)

If the reviewers have not responded in a reasonable time (a day or two), ping them or raise the issue in a daily meeting.

Last updated 3 years ago