I used to think every pull request (PR) needed to be "perfect". All win, no downsides.

But sometimes a PR is many steps forward, and one step backward. This doesn't necessarily mean the PR must be blocked.

Instead, I often suggest opening a separate ticket to address the downsides.

This way, the good stuff can be merged today, and the downsides can be addressed tomorrow.

Of course, there are plenty of exceptions to this rule.

I won't approve a PR that suddenly tanks performance, or opens up a security hole.

But I'll approve a PR that improves many things, but also has some temporary compromises that don't hurt the user experience.

View original on X