Repository code reviewers analysis on example of dev.to

In this post I am going to analyze different approaches for searching the best reviewers for your code and Pull Requests.
I am going to do that based on dev.to code repository.
At the end there will be an example on how to do the same but in automated way.

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 high 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

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!

Manual search for reviewers

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 of 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.

Automated way

Add project with dev.to code repository to Efficiefy.io app
Open page with Pull Requests, see that for PR with number 9621 there is a list of rhymes, Ridhwana as a recommended reviewers.

P.S.

I would be glad to hear how do you find recommended reviewers at your projects. Would you like to have a demo?
You may see screenshots of the app by link