'''Coordinate Efforts through Defect Lifecycles'''

Untracked bugs can lead to wasted or duplicate effort. The wrong programmer attempts to fix it or multiple programmers all work on different solutions at the same time without coordination. Or a programmer works on an already-fixed bug not knowing that the fix is in. The bug isn't really a bug, it's a new piece of functionality, leading to scope creep. Low priority, easy, or "fun" bugs get fixed before the higher priority bugs.

'''Therefore:'''

Define and use a BugLifeCycle. Assign bugs to one person at a time, and give that individual responsibility for resolving it or assigning it elsewhere.

As the customer, watch your bugs and respond to queries for additional information or candidate fixes. If a bug you reported is no longer an issue, close it. As the developer, update your bugs when you work on them. If you get stuck, assign them to another developer. If you need additional information or want comments from the submitter, assign it back to them with appropriate status.

Also, identify someone to play the Dispatcher role, and modify priority and assignments as necessary. The Dispatcher role can streamline the process of moving a bug through its lifecycle.

----
I think it's important that the TrackingTool allows to connect or join bugs or even to split one defect into more defects.
* Joining bugs - the developer see that the a few reports describe all the defect. He can join the defects to one new defect. All the other subdefects will now correspond to the new one.
* Connecting - different defects which all have the same cause can be connected to one new defect. See joining bugs
* Splitting -  One report has more than one defect described. Split the report into more defects. (The main report is closed/fixed/... when all subdefects are closed/fixed/...)
* Disconnect - Defects which are connected do not have the same cause. 

-- AndreasSchweikardt is still searching for the perfect tool.


See: DocumentWork

DefectTrackingPatterns