DEV Community

Masato Ohba
Masato Ohba

Posted on

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.

Discussion (0)