Comment by phyzome
3 days ago
My solution is to organize my PRs as a sequence of commits that explain what they do, and then a PR description that gives an overview and motivates the changes. I've gotten really positive feedback on this, and it dramatically speeds up reviews of my code. Overall less work for the team. (And it often helps me find problems before I even submit the PR.)
As for other people's PRs? If they don't give a good summary, I ask them to write one.
> If they don't give a good summary, I ask them to write one.
Exactly; if people can't be bothered to describe (and justify) their work, or if they outsource it to AI that creates something overly wordy and possibly wrong, why should I be bothered to review it?
How much time does it take you to craft the PR compared to writing the code? Just curious if crafting the PR becomes significantly easier with practice.
Yeah I did this too as an engineer!
I think this is a valid part of the "crafting PR" skill that's under appreciated, and part of the goal of Haystack here is to make that part of PR craft effortless.
The effort is part of what makes the outcome better, though.