The next pattern in the Defect Tracking Pattern Language deals with the context of a development team that may be geographically dispersed or otherwise not able to sit together in an XP way, but has a sense of collective or at least weak code ownership. The product being worked on is large an complex enough that a defect tracking tool is need and used.
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 bug lifecycle. 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. If you are using a bug tracking system that allows it, you may watch bugs you do not own but have a stake in. 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.
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.
However
Adhering tightly to this pattern requires discipline in using the bug tracking system. The Use a Tracking Tool and Document Work patterns are intimately tied to this pattern's effectiveness.
See: DocumentWork