The number of times a pull request goes back and forth between the author and a reviewer.
Why it matters: Each time a pull request is passed back and forth, developers are required to context switch and spend more time on one particular line of work. If this happens frequently, the review process can become a bottleneck to shipment and a source of demotivation to engineers who are trying to complete their tracks of work.
How to use it: When Review Cycles is high for a team, it may indicate that either (1) there are differing ideas around what “done” means, (2) there’s misalignment around what kind of changes are expected to come out of a review process, or (3) conflicting opinions about how a solution should be implemented. If the Review Cycle is high for a particular submitter, it might mean that they’re struggling with the codebase or dealing with unclear requirements.
How it's calculated: A review cycle is a comment, request for change or approval by someone other than the PR author. The cycles increment when there is a back and forth between the reviewer and the author.
Some examples:
I open a PR and merge it without any interaction from anyone else, that’s 0 review cycles
I open a PR and you approve it, that’s one review cycle
I open a PR you leave a comment, I make another commit to fix it, then you approve it, that’s 2 review cycles
I opened a PR, and no one made any edits or changes; that still counts as 0 review cycles