You have a system. People use it. (Congratulations!) But people find bugs. So you have a bug tracking system. And you have a support team, a team of developers dedicated to addressing bugs in the system.
You get an email from an important user with a list of issues she’s uncovered. And, oh crap, several of them are definitely urgent and important. Enough so that you think the support team should probably (and would probably want to) drop what they’re doing to fight this fire.
So, wasting no time, you copy and paste the text of the email into a new ticket in your bug tracking system and send it to the support team.
Boo.
What happens when a developer fixes the two high priority issues in the email, but there are three left? What if those three are low urgency, low importance, and high effort? It’s one item in your bug tracking system. The implication, of course, is that they should fix everything before marking the bug fixed. But that’s not what you want done in this case, surely.
If you want them to consider the issues separately, you should log them separately. Track them separately. It tends to take just a few minutes and can save more than a little angst.
Developers! You’ve seen this. Maybe you’re nodding knowingly or shaking your head sadly as you read this. But do you think you’re immune to it? You’re not. You do basically the same thing when you change a whole bunch of stuff with one commit.
What if we want to roll back two of the six things you changed in that commit? What if something breaks after that commit gets integrated? Now I have six places where something might have gone wrong.
Boo.
