> If you truly need to make all of these other enhancements, do them in separate pull requests. Never fix a bug and refactor in the same pull request. Somehow,

> If you truly need to make all of these other enhancements, do them in separate pull requests. Never fix a bug and refactor in the same pull request. Somehow, in practice, I've seen the fixing plus enhancements work better in getting the code in a better shape. Also, why are we not good with doing both at the same time? If its because it makes things harder to review, I've found that pairing on the review and adding clarifying comments to the PR is a much better way. If its for the commit history, is it always more important to have a squeaky clean commit history than to have easier to read (I'm presuming this is the intent of the refactor) code? Is there some point after which the code is bad enough to sacrifice some commit history clarity to get better code? > You may even decide that these enhancements are distracting you from your immediate goal of shipping a feature. In this case, there is nothing wrong with addressing them in a tech debt sprint. Has anyone actually seen this work? In my experience, once the original bug is out of the way there is no motivation or vision on how or why to make the cleanup and the tech debt tasks are left to rot forever, while the code slowly turns into mud. Does anyone know how to avoid this? IMO the thing that works best is to do the yak shaving first before the bugfix. But also, timebox the effort for yak shaving - you're only allowed to do a certain amount.