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.
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."
~ 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.
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...
To avoid such situation, our team sometimes have "review meeting."
- 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.
- The author explains his/her implementation by showing PR, wiki, chart, etc.
- I know some devs are quite good at to write a chart.
- A reviewer can ask/discuss anything anytime in the review meeting
- Be calm. It's not an interview.
- Note Questions/Discussion points as a review comment on GitHub
- If we skip this step, some points will be missed.
- 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.
- 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.