DISCLAIMER
This page and analysis was created independently from DEV.TO(forem.com) authors and owners, based on the data available as an open source at GitHub(https://github.com/forem/forem) and with regard to the code licence.

TL;DR

Using Efficiefy.io the procedure takes just a few seconds and requires a just a few clicks.

Problem to be solved

I am a software engineer and worked for several years as a Tech Lead on different projects. To be able to provide a software product of a good quality it is important to establish reliable processes of code review.

The hardest question to be solved during a review process setup is how to select the best possible reviewer(s) for pull requests - people, who know affected code components and used technologies well?

There could be different solutions for this:

  • Everyone reviews code which he wants
    Pros: no pain with searching for reviewers
    Cons: this approach does not guarantee enough number and quality of reviewers
  • Tech lead is reviewing everything
    Pros: guarantee for at least one reviewer
    Cons: tech lead could be overwhelmed with different tasks, so review quality would suffer; this leads to a single point of failure - if lead is absent, then process is significantly affected
  • Assigning best possible reviewers based on experience in affected code components, modules, libraries and frameworks
    Pros: maximum reviewing quality, the best way to share knowledge within a team
    Cons: hard to automate, requires either lots of manual work or using proper tools

In this article I would like to concentrate on the 3rd option. Let's consider some repository as an example: https://github.com/forem/forem, this is a Dev.to community open source repository. I will show two ways of achieving results: by manual work and by using tools like Efficiefy.io.

Let's consider this Pull Request as an example https://github.com/forem/forem/pull/9621
Let's find who could be the best recommended reviewers for it!

Traditional way: manual work

We need to have a look at a git history for each affected file and understand who did the most changes for each. After that we need to combine found reviewers into a list for up to 3-5 people.

More files in PR means more time spent. We will calculate total time spent on the procedure and amount of diffs to be looked at.

This PR has 9 files changed. Author is mstruve.
Let's look at the files to see who worked mostly on it.

  1. .travis.yml
    Here we may see a pretty long history of changes: https://github.com/forem/forem/commits/e883fedbfdd0209bf31af5d50a712294093f3fad/.travis.yml
    Candidates(excluding mstruve): rhymes, maestromac, Zhao-Andy, citizen428, nickytonline, snackattas, vaidehijoshi, etagwerker, benhalpern.
    That is a long list. After looking at 15 different commits, I could assume that for this file the best reviewers could be: maestromac, citizen428, rhymes.
    Spent: 10 minutes.
    Looked at: 15 diffs.
  2. Envfile - this file was deleted completely, so skipping it.
    Spent: 0 minutes.
    Looked at: 0 diffs.
  3. Gemfile
    Here is its history: https://github.com/forem/forem/commits/03888b918784064bccb41cfead52180f2e5e7c82/Gemfile
    What I see immediately, is that it is significantly polluted by auto commits done by bots, like dependabot.
    Candidates(excluding mstruve): maestromac, rhymes, lightalloy, benhalpern, jacobherrington, citizen428, swrobel, atsmith813, lizthegrey, nickytonline, vaidehijoshi, joshpuetz, fdoxyz, etagwerker.
    That is event harder. After looking at 30 commits, I could assume that for this file the best reviewers could be: rhymes, citizen428, vaidehijoshi.
    Spent: 15 minutes.
    Looked at: 30 diffs.
  4. Gemfile.lock - this is technical file, auto-generated normally, so could be skipped.
    Spent: 0 minutes.
    Looked at: 0 diffs.
  5. app/views/internal/configs/show.html.erb
    Here as well is a long history of changes: https://github.com/forem/forem/commits/03888b918784064bccb41cfead52180f2e5e7c82/app/views/internal/configs/show.html.erb
    Candidates(excluding mstruve): rhymes, jacobherrington, benhalpern, citizen428, vaidehijoshi, Ridhwana, lightalloy, JibranKalia, jitendra1998, maestromac, JuanVqz, icncsx, AlbertoPdRF, Zhao-Andy, lisasy.
    After looking at 30 commits, I could assume that for this file the best reviewers could be: rhymes, benhalpern, citizen428, Ridhwana.
    Spent: 15 minutes.
    Looked at: 30 diffs.
  6. config/initializers/0_application_config.rb
    This is an easy task, the history is short: https://github.com/forem/forem/commits/03888b918784064bccb41cfead52180f2e5e7c82/config/initializers/0_application_config.rb
    I will consider only 2 last commits, because other ones are two old.
    Candidates(excluding mstruve): ledestin, rhymes, both could be considered as recommended.
    Spent: 1 minutes.
    Looked at: 2 diffs.
  7. config/sample_application.yml
    Here again, history is not too long: https://github.com/forem/forem/commits/03888b918784064bccb41cfead52180f2e5e7c82/config/sample_application.yml
    I will consider only 3 last commits, because other ones are two old.
    Candidates(excluding mstruve): jacobherrington, citizen428, both could be considered as recommended.
    Spent: 2 minutes.
    Looked at: 3 diffs.
  8. docs/backend/configuration.md
    This is an easy one: https://github.com/forem/forem/commits/03888b918784064bccb41cfead52180f2e5e7c82/docs/backend/configuration.md
    Candidates(excluding mstruve): citizen428, Zhao-Andy, joshpuetz. All three could be recommended ones.
    Spent: 2 minutes.
    Looked at: 4 diffs.
  9. vendor/cache/envied-0.9.3.gem - it is a bin file, could be skipped.
    Spent: 0 minutes.
    Looked at: 0 diffs.

Now we need to combine all lists per files of recommended reviewers into one list.
To do that, we would need to look at which files were changed mostly, so have higher weight in review.
I would say, these are files 1, 5 and 7.
So, final list of recommended reviewers could be: citizen428, Ridhwana.
Other reviewers, which could be helpful: rhymes, maestromac, vaidehijoshi, benhalpern.
Totally spent: 45 minutes.
Looked at: 84 diffs.

Efficiefy the way

Open page https://app.efficiefy.io/area/pull-requests, see that for PR with number 9621 there is a list of rhymes, Ridhwana as a recommended reviewers.

Contact me

I would be glad to hear how do you find recommended reviewers at your projects.

Would you like to try the Efficiefy.io? It is open for testing now: https://app.efficiefy.io/