Hacker News new | ask | show | jobs
by ellefire 15 days ago
It's expensive when you factor in each PR having to wait for someone to come and review it - it's easier to get your work done in larger PRs when that's the case, although it's a perverse incentive
2 comments

Even with low review turnaround, having each PR get to a defined "goal" makes it clear if the early commits that prepare the co-debase for the goal are going in the right direction. If they were submitted as individual PRs the reviewer can only check that they don't break things but has to trust the submitter that the design is right for what will follow.
easy solution is to design ahead of PR time
I mean, that's a positive feedback loop. It takes longer to review, because they're expecting them to be big. Big PRs/MRs are left there until there's a big enough free time block to tackle and discuss. If the PRs are small, obvious things, they can be merged in minutes.

(Depending on what the PR's about and how the team organizes. Ideally, there's consensus on the goals or who's responsible for what. Reviews can be limited to finding bugs and e.g. organizational problems)