3

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.

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

3 Answers 3

Reset to default
4

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.
Improve this answer
2
  • 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
    Commented Jun 29, 2017 at 7: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
    Commented Jun 29, 2017 at 17:47
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.

Improve this answer
-1

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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.