Encouragement of Review Meeting

Initially, I wrote this snippet for internal purpose as an answer for what I had heard from another team's product managers; "our team's review takes much time", "we are struggling to estimate exact development term".

Then I introduced an idea to have a review meeting for smooth review; then I found it's even worth to be public.

Background

I recently heard some product managers (or even developers) are troubled with reviewing time. Is the situation like below?

~ One day ~

Manager: "How is your work going?"
Developer: "Almost finished, but... it still needs to go through review."
Manager: "Understood."

~ Another day ~

Manager: "Did your PR get merged?"
Developer: "Ah, not yet. I'll ping them again."
Manager: "Hmm, I see. How long does the review take?"
Developer: "Umm, not sure."

~ To be continued... ~

It's quite frustrating for everyone. Estimation by a developer tends to vary from the original one, and its release date does.

On the other hand, our team sometimes have kind of "pair reviewing" or "review meeting" for a complicated (large) pull-request in person. So far, it works so well that I'd like to share the way.

Premises

Most of the review time issues are caused by a large/complicated pull request, and lack of adequate description.

So first of all, developers should;

• Split pull-requests into adequate size ones if possible
• Write an appropriate description, chart, wiki, etc. for a feature they develop

Even though the idea above is right, we are sometimes compelled to implement a large/complicated pull request. And it will have been neglected for a long time...

Details

To avoid such situation, our team sometimes have "review meeting."

How?

1. An author who needs a review prepares PR and wiki (if necessary) beforehand, and book a review meeting
   • 2 or 3 is a good number of reviewers. If it's too much, all of them might not actively join a discussion.
2. The author explains his/her implementation by showing PR, wiki, chart, etc.
   • I know some devs are quite good at to write a chart.
3. A reviewer can ask/discuss anything anytime in the review meeting
   • Be calm. It's not an interview.
4. Note Questions/Discussion points as a review comment on GitHub
   • If we skip this step, some points will be missed.
5. After that, the reviewee reflects the content of the review meeting
   • Even if there are so many fixes, it's much easier to re-review since reviewers know why those changes are needed.

Note

• Not all of the pull requests requires "review meeting" and "pair review."
• They are just communication tools, so
  • If you are an author, don't be afraid to ask a review.
  • If you are a reviewer, it's quite encouraged to pay a high compliment to one's code.