Skip to content

Add a review rotation

Janis Altherr requested to merge add-reviewer-rotation into master

Why is this change being made?

This MR introduced the idea of a Reviewer Rotation. This is to ensure that simple, small MRs can be reviewed in a shorter timeframe than is currently possible.

It is not uncommon for a simple 4-line MR to take up to three days to be merged. This doesn't raise any eyebrows because our current Target MR Review Duration is 21 days.

I think this is appropriate for MRs for features that are introduced within the monthly release cadence. But I would proclaim that there are other MRs that would benefit from a shorter cadence: Quick solution validation experiments on gitlab.com, bugfixes, and lastly (my primary concern) complex features divided into small MRs where each MR builds on the previous one.

I believe a long review cycle is a huge challenge to our iteration value:

  • It disincentivises small, iterative MRs that build on each other in favour of chunking it all together to avoid switching back and forth between MRs
  • The cognitive load for the MR creator is bigger the later the feedback arrives, as the context switch gets more expensive
  • In contrast, a fast review cycle may also improve community contributions as instant feedback is usually encouraging

Next steps

The next step would be to automate the rotation calendar using a script based upon reviewer roulette. Using the team member's timezone availability, holiday schedule, potential blocks, reviewer roulette would be able to assign rotations fairly across team members. In MRs, danger bot could use this information to suggest an available reviewer (with the hint that the rotation is for small and/or urgent MRs only)

Author Checklist

  • Provided a concise title for this Merge Request (MR)
  • Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
    • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added.
  • Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
    • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
    • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
  • If the changes affect team members, or warrant an announcement in another way, please consider posting an update in #whats-happening-at-gitlab linking to this MR
    • If this is a change that directly impacts the majority of global team members, it should be a candidate for #company-fyi. Please work with internal communications and check the handbook for examples.

Edited by Janis Altherr

Merge request reports