Our team is looking to optimise our pull request workflow. We are trying to increase the speed at which we ship (we're a startup). Interested any advice for making the PR system more efficient? Do others face this problem?
There are a lot of great tools in the space right now, I firmly believe that teams should not just accept what GitHub gives them. After all, we don't use Notepad as our main editor just because it ships with the machine.
I started CodeApprove (https://codeapprove.com) because I saw from the inside how big tech companies (Google, Meta, etc) optimize PR review. Rather than try to automate, replace, or artificially speed up the process, instead they've made great interfaces that allow reviewers and authors to always know whose "turn" it is in a code review and quickly find what they need to address. The goal is to get to resolution (or in other words, consensus) in as few rounds as possible and to make code review painless to the rounds themselves are short. A good tool goes a long way here.
That list is already a bit out of date, I can think of some newcomers (Planar, Pullpo) which would also be on the list if I was writing it today.
I've helped a bunch of teams make their code review process better (tools aside) and if you're looking for free advice on how to help your team review better I'm always happy to talk to people about this. Email is in my bio.
That's awesome! Can I ask what sort of feedback you were getting that lead to CodeApprove. I agree that sitting with the incumbents shouldn't be our default setting, curious about which parts you are trying to improve?
We use https://pullpo.io. It's a GitHub-Slack integration that creates ephemeral slack channels per pr, with all the people involved in the pr.
The first code comments still happen in GitHub, but then those comments go to slack (with the code context) so that the code review conversation happens there.
How cool is it! I agree that going along with the status quo shouldn't be the norm. Due to the small nature of the modifications, a code review is unnecessary
https://thebackrooms2.com
at Promyze, we started exploring the model Ship Show Ask. [1]
In this approach, PR authors are considered free of trust to evaluate themselves if:
- The code doesn’t require a code review since the changes are trivial (Ship)
- They’d like to show the code changes to colleagues and get their feedback (Show); This mode can sound totally counternatural as the feedback can be provided after the merge. This is part of the paradigm shift.
- The code requires a review (Ask)
So, instead of adding more people to review the code, we reconsider the necessity for each PR to be approved. This is how we positively impacted the lead time for change.
codeapprove|2 years ago
I started CodeApprove (https://codeapprove.com) because I saw from the inside how big tech companies (Google, Meta, etc) optimize PR review. Rather than try to automate, replace, or artificially speed up the process, instead they've made great interfaces that allow reviewers and authors to always know whose "turn" it is in a code review and quickly find what they need to address. The goal is to get to resolution (or in other words, consensus) in as few rounds as possible and to make code review painless to the rounds themselves are short. A good tool goes a long way here.
Last year I also wrote a quick survey of other tools which I've seen in the space and think are promising: https://medium.com/codeapprove/the-best-modern-code-review-t...
That list is already a bit out of date, I can think of some newcomers (Planar, Pullpo) which would also be on the list if I was writing it today.
I've helped a bunch of teams make their code review process better (tools aside) and if you're looking for free advice on how to help your team review better I'm always happy to talk to people about this. Email is in my bio.
rupertdenton|2 years ago
marco_patino|2 years ago
The first code comments still happen in GitHub, but then those comments go to slack (with the code context) so that the code review conversation happens there.
rupertdenton|2 years ago
doctorfennel|2 years ago
amagne|2 years ago
In this approach, PR authors are considered free of trust to evaluate themselves if:
- The code doesn’t require a code review since the changes are trivial (Ship)
- They’d like to show the code changes to colleagues and get their feedback (Show); This mode can sound totally counternatural as the feedback can be provided after the merge. This is part of the paradigm shift.
- The code requires a review (Ask)
So, instead of adding more people to review the code, we reconsider the necessity for each PR to be approved. This is how we positively impacted the lead time for change.
[1] https://martinfowler.com/articles/ship-show-ask.html
rupertdenton|2 years ago