⏱️ Why we made this bot

Code reviews should be fast. This is very important because of 2 main reasons:

• Greater efficiency. Having fast code reviews and short-lived feature branches is much more efficient.
  • First, you are less likely to encounter merge conflicts so you don't spend useful time resolving them.
  • Second, it’s easier and faster to get into the context of recent pull requests than stale ones. This also saves time.
• Code reviews are a blocking step by default. Unless you use pair programming (not for everyone nor every task) or the SHIP/SHOW/ASK strategy (which I recommend). Most code reviews are blocking: until the changes meet all the requirements and get the necessary approvals, the code is not going to production.

As the Google engineering team says:

🚨 What’s the problem

The problem is that many developers still don’t have the habit of prioritizing code reviews over other tasks and they are not incentivized to do so.

Not blaming developers here. As developers, we all hate to wait a long time for our PRs to be reviewed.

🔥 Why MergeTimer

The concept of MergeTimer is to make the workflow force fast code reviews, bringing developers closer to the main branch. Of course, you can always deactivate automatic merge, pause the timer, or add branch protection rules to main.

But the mere fact of having a timer on PRs gives devs a common objective of completing the code review before the timer reaches 0.

🤔 Other solutions to the problem

• Pair programming and pushing directly to main/trunk (Trunk Based Development for small teams). This is another way to make the workflow force fast code reviews, but also forces pair programming which is not ideal for everyone or for every task.
• Code review channels by Pullpo. Facilitates faster code reviews by bringing code review conversations to temporary Slack PR-Channels that are synced both ways with your GIT provider.