I do agree that the process of comitting, pushing, and opening a PR can be a bit clunky. But I also think PRs are super valuable because they encapsulate code and discussion in one place that's easy to reference in the future.<p>If I find a line of code that confused me, finding the PR where it happened is often the solution.<p>That said I think GitHub's code review tools are lacking and hold us back from doing our best.<p>I'm building something better at codeapprove.com, if you or your team is interested please email me: sam@habosa.com
Possibly off-topic, but the "a bug is cheaper to fix the earlier on it's discovered" idea came from a since-debunked bit of research, and even if it were true in 1995, has since become untrue through tech advances in how we execute modern deployments, e.g. if I commit a bug in my UI, fixing it in production is the same process as fixing it in dev, just pushing a commit.<p>I wish I had a citation, but my google-fu is getting circumvented by "error" and "cost to fix a bug" being too related.
The problem isn't so much with PRs themselves but the journey up to the PR. If the reviewer has no context of the work, or the author has diverged too much from what was planned, things can quickly get messy with questions and knowledge sharing that should have been done before the code was written in the first place. I don't see PRs going away any time soon but they should be treated more as a part of a CI/CD pipeline and less as an actual code check.
Sounds like the problem is a unit of work is split between too many people, i.e. how the people in the example are using PRs, not PR (as a tool) itself.