Pull request review workflow

  • Review the PR ASAP after being allocated to it.
  • Run code and use it as the end user would. Double check requests in feature’s description.
  • After exploring feature from your own expectations, review the "QA checklist" created by the feature’s developer in the feature card. Work on whatever hasn’t been covered.
  • If feature behavior is wrong, don't review code yet. Allocate PR back to developer and describe, in detail, correct feature behavior. Describe meticulously, providing screenshots and flows if applicable. Miscommunication led to misunderstanding, therefore you need to invest time in describing it better now. After explaining the issue again, mention the original issue's author for her/him to know what was done wrong.
  • Review code. Use same process described here.

Giving feedback

  • Offer alternative implementations, but assume the author has already considered them ("What do you think about using a custom validator here?").
  • Ask questions rather than make demands/commands. Engage in conversation: "What do you think about ?", "Did you consider...?", "Can you clarify...?".
  • Offer compliments in code lines when you learn something new or something is done well.
  • Don't say "Why didn't you just...?" "just", "simply", "easily" don't give good feels. Don't use them when asking questions.
  • Avoid selective ownership of code ("mine", "not mine", "yours").
  • Be explicit. Remember people don't always understand your intentions online.
  • Don't use hyperbole ("always", "never", "endlessly", "nothing").
  • Don't use sarcasm.
  • When satisfied, comment on the pull request.
  • Delete feature branch.