Developer PR Review Scheduling

The Problem

Randomly assigning reviewers to PRs works okay, but it can also be a little scattered at times. Most times, in fact, the work falls on the same people over and over.

Solution

Rotate two designated developers to review PRs, assigned at each dev meetup/ sprint cycle, and lasts till the next sprint cycle (2 weeks later... Tuesday to Tuesday). Here are some of the details we discussed:

• Whenever a PR is submitted, the two designated devs should always be assigned once the PR has passed all it's GitHub Actions. One reviewer of the pair will always be a {riskassessment} "veteran".

  • Veterans include Robert, Jeff, Andrew, and Aaron
  • We'll keep track of who's "on-duty" via slack's riskassessment-dev channel
  • Given there's 7 of us, you can expect to be "on duty" every three sprint cycles (1.5 months)

• Some Logistics:

  • Reviewers, ensure the PR addresses the entire scope of the GitHub issue
    • If it doesn't, that's fine but keep the issue open, and add a comment stating that the issue was "partially resolved with #[PR Num]" and describe what work is still left to be completed.
  • The expectation is that reviewers will at least take a peek at the code within 2 business days of the PR being opened and assigned. If it's been 2 biz days and you don't have time to review, please let everyone know on the PR, saying: "hey, I don't think I can review this within 2 days, can you look [other reviewer]?" for example.
  • PR authors, please keep your PRs as draft until it is absolutely ready for review. Aka, don't unnecessarily burden the reviewers prior to the code being ready. Make sure all checks have passed.
  • If the PR addresses a bug on master, it's a really high priority! Review immediately and add Aaron as the third reviewer. Other people who are not assigned during that 2-week sprint cycle are still allowed to provide a review. They just aren't expected to!
  • If the PR solves and issue marked as an "enhancement" label, add Aaron as a reviewer (in addition to the other two). Just because Aaron is a reviewer doesn't mean the others can't provide an initial review. Enhancements usually change the app's functionality in a major (or sometimes minor) way, so we'll want an extra set of eyes on it.
  • If you started a review, but it doesn't get merged by the next meetup, try to finish it. But if you can't, no worries! Just let the new reviewers know the status of the review. Provide lots of context on GitHub so it's easy for the next person to pick it up.