Comment by ZephyrBlu
5 years ago
It's less about setting up for the review and more about getting teammates to review the PRs promptly.
I work remotely, so my (Small) team mostly works async even though we're in similar time zones. I doubt trying to ping them for 10 PR reviews in a single day would go well.
Async + people trying to do their own stuff + 10 interruptions is not a great combo. Comments/discussion on a PR can grind things to a halt as well.
I completely agree everything you're saying about making PRs easy to review though. My team already tend to do those things thanks to our manager.
Could be about incentives then. At Google the code reviews you do are tracked so doing many looks good for your performance reviews, so some people try to be fast with reviews to get more reviews. If you don't get any credit for doing code reviews then I can see it being very hard to get people to do them though.
Also as long as you have a pending review sent to you it shows up as a "you have stuff to do" icon in the google tools until you respond to it, just like if you got a message, I guess that helps as well.
Interesting. We don't track code reviews as far as I'm aware, and we use GitHub so you just get an email if you're tagged as a reviewer.
I would say it's not uncommon to have to wait a day for reviews.
The the first thing to do if you want to improve that is to ensure you track code reviews. Meaning, you can see what changes each person reviewed and not just submitted, and then you can use that data to talk about performance etc. If one person does all the reviews then he should get a ton of credit since that is hard important work. Typically lead programmers do more reviews and juniors writes more changes, so a person doing a lot of reviews is associated with seniority and something to strive for rather than avoid. Also I bet your manager would be interested in that information as well, so maybe you just need to suggest it to them.
3 replies →