Speed up the pull request process. Advice?

[rupertdenton]

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?

[codeapprove]

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.

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]

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?

[codeapprove]

I was actually in charge of a large open-source effort at Google (75 repositories, dozens of internal devs, hundreds of contributors) so I had a very unique position of being able to watch Googlers attempt to use Google engineering practices on GitHub.

For the most part they loved the open-source work (a lot more flexibility than internal systems) but they all complained about the code review! It just didn't give them the same rapid drive to consensus they got with Google's internal tools. And I think they were right.

So after I left Google I was very inspired to work on a better code review system for developers on GitHub. And that's how CodeApprove was born!

[marco_patino]

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.

[rupertdenton]

Oh interesting, hadn't heard about this. Do you like it? Any parts that aren't great? I'm definitely open to new tools!

[marco_patino]

there are like 3 devs that don't like it because they are used to the github way of doing things, they always have the github tab open and prefer not to have notifications in slack.

We disabled pullpo for these people. However they can still collaborate with the people that use pullpo. The comments they send to github are brought to slack too and viceversa.

Still, code reviews take 2 to 3 times less

[rupertdenton]

Yeah I did a bit of a deep dive on Pullpo - it looks great, small passionate team! I was curious if there is anything that you don't like about using it as part of your workflow? Like I can see your colleagues prefer a specifically different type of workflow - why did your team adopt it?

[marco_patino]

Most of the devs actually love it, and they have excellent customer support. I you suggest a feature, they'll probably do it.

[doctorfennel]

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

[amagne]

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.

[1] https://martinfowler.com/articles/ship-show-ask.html

[rupertdenton]

Wow, how have you found that improves things for your team?