PR review friction

As a non committer occasionally reviewing PRs, I recently had to review the same PR 4 times over the course of a week.
I know it does not sound too bad, but my point is that it seemed kinda unnecessary:

  • The suspected cause was that the PR just got rebased several times on top of master;
  • It was a “minor” code change, and did not receive any updates through the process;
  • There did not seem to be any apparent conflicts with master.

As an occasional contributor, I probably have made the same mistake (preemptive rebase to avoid potential future merge conflicts madness) as well, without realizing the increased burden I was putting on the reviewing process.

Have other reviewers experienced similar feelings regarding the review process?
Are there other frictions that could be changed by “contributor education”?

Should a “Make life easier for the reviewers” be added to the contributors documentation (or even to the PULL_REQUEST_TEMPLATE)?

If you mark files as “viewed” in the GitHub review UI, that removes some of the pain. It will remain viewed on rebases if the diff does not change.

2 Likes