6 ms·

Speed up the pull request process. Advice?

• doctorfennel 3y ago
  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 https://thebackrooms2.com
• amagne 3y ago
  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 https://martinfowler.com/articles/ship-show-ask.html
  • rupertdenton 3y ago
    Wow, how have you found that improves things for your team?
• marco_patino 3y ago
  We use https://pullpo.io 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 3y ago
    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 3y ago
      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 3y ago
        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 3y ago
          Most of the devs actually love it, and they have excellent customer support. I you suggest a feature, they'll probably do it.
• codeapprove 3y ago
  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 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-tools-2022-468b51751fa 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 3y ago
    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 3y ago
      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!