One Issue Per Ticket, Please!

Bug tracking systems exist to help many people organise their efforts in order to fix a problem or add a feature.

The lifecycle of a bug may go something like this:

1. Reporter opens a ticket
2. A developer gets assigned the ticket
3. The developer completes work on the ticket
4. The developer marks the ticket as resolved, and assigns it back to the Reporter
5. The reporter checks the fix, and closes the ticket.

Though there are many versions of this lifecycle, the purpose is to move an issue from new to closed, logging the steps taken on that particular issue.

Problems arise when one ticket contains many issues.

Someone will see that a bug has been worked on or resolved, and on testing the feature will find another semi-related issue that has either snuck in with the work for the original issue, or not been detected up until that point. Spotting this, they will add a comment to the original ticket. This is wrong.

The correct course of action in this situation is to open a new ticket – not to add the problem to the discussion on the original issue. The latter course of action quickly degrades the ticket into an email-like exchange which can cause confusion. If email were a good enough solution, we wouldn’t need bug tracking systems. The only time it is reasonable to add a comment to an existing ticket is when the comment relates only to the original issue.