How to deal with people not finding the time to do code reviews?

Question

I'm finding that others not having the time to do reviews in a code-review enforced open-source (so volunteer) project is really slowing the velocity - it's really unmotivating to have 3-4 PRs of your sitting there for days and prohibits me from doing any new work.

Real life taking priority is of course understandable, but what's a solution for this? I'm thinking of allowing PRs to go through if they're unreviewed for 3-4 days, but that kills the entire point of having code review to begin with.

Does anyone have a good solution?

This is an open-source project and as such I definitely don't have the methods available to a commercial organisation to ensure code reviews are done in a timely manner.

Are you one of the administrator(s) for the project, one of the core developers or simply a contributor? — Steve Barnes, Jun 25 '17 at 12:17
You need to edit make clear why the answers to the duplicate gnat linked to don't answer your question already. — candied_orange, Jun 25 '17 at 12:40
Possible duplicate of How to get developers to do code reviews in a timely manner — David Arno, Jun 25 '17 at 15:19
@gnat doesn't look like a duplicate. This one is about an open source project, which changes available methods drastically... — Daniel Jour, Jun 25 '17 at 18:22

score 4 · Answer 1 · answered Jun 25 '17 at 18:13

Just a few ideas, as project lead you could possibly consider some or all of the following:

Have a reviewer leader board as a part of the release notifications &/or the project web site.
Announce, maybe quarterly, a week of "Backlog Clearance" when the no new code submissions are accepted during that time.
Encourage or organise code review parties where groups of potential reviewers get together for an evening, or a weekend day, of a combined social and lets clear the review queue event.
Have a clearly stated policy of patches & new features get considered for inclusion based on:
- New contributors always need to encourage them then
- Submissions from contributors that have submitted useful code reviews in order of the number of reviews in the last month, quarter, year.
- Everybody else.
If you have any sponsors see if funding can be found for a periodic "most quality reviews" award of some sort.
If your project is presented at conferences you could possibly have a separate review credits section to the slides, just make sure that everybody knows about it well in advance and that they have an option to remain anonymous.

Thanks so much for the suggestions! These seem to be for more longer-term PR backlogs, while I'd ideally like like mine to be 3-4 days old at max. — Vadim Peretokin, Jun 29 '17 at 07:23
@Vadi - Some reviews can take several days of full time paid work so I would say you are being optimistic on that. Plus of course if someone makes a commit the night before an applicable conference unless you can get a review party going at the conference... — Steve Barnes, Jun 29 '17 at 17:47

score 0 · Answer 2 · answered Jun 29 '17 at 07:23

0

I think in the end to achieve a short turnaround I'll go with an etiquette where the review window is 3-4 days and then the PR can be merged if it was reviewed by at least one other person.

answered Jun 29 '17 at 07:23

Vadim Peretokin

189

score -1 · Answer 3 · answered Jun 29 '17 at 12:49

I don't feel you can really solve this issue in 3-4 days. I have had the similar experience. But sometimes the simplest solution is the best. Have you just communicated directly with a team? Everybody has its own external and internal motivation. Find an approach that everybody could feel himself as a part of a valuable project. The other point is guidelines. Maybe your should create or check the detailed instructions to the newcomers.

How to deal with people not finding the time to do code reviews?

3 Answers3