3 ms·
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
by phyzome 1y 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.
- akshaysg 1y agoYeah 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.
- phyzome 1y agoThe effort is part of what makes the outcome better, though.
- Cthulhu_ 1y ago> 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?
- spott 1y agoHow 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.