A better way to track bugs for Boost [ From a session at BoostCon 2008 ]

At BoostCon 2008, after I gave a presentation talking about how bugs were handled in boost, and what some of the problems were, we realized that there was little to no understanding about how bugs were entered/tracked/processed in boost. We brainstormed for a while, and came up with a process that (a) is being documented, and (b) should give us better results, and (c) make it easier to track bugs.

• Bugs are identified, either "in the wild", or via discussion on the mailing list, or by the author of the library, or some other way. The bug is entered into the Trac system (by creating a ticket) - and can be assigned to a person or not.

State "Triage": This is for tickets that are not immediately assigned to a person, but rather to boost as a whole. The "Bug Wrangler" (initially me [ Marshall ], until I can recruit some help ) will examine these tickets, and assign them to a person (or fix trivial bugs, or reject obviously inappropriate bugs). Once the tickets are assigned to a person, they move on to....

State "Assigned": Here each ticket has a responsible person. The person to whom the ticket is assigned should examine the ticket. He can either:

• Assign the ticket to someone else
• Mark it as invalid/Duplicate/WontFix
• or "Accept" it.

By Accepting the ticket, he agrees that it is really a bug, and it is correctly assigned. Once that happens, the ticket moves to ....

State "Accepted": Here, the ticket has an owner, and the Triage team and the owner have agreed who that is. When ticket reaches "Acceptance", it needs to have an assignee, a milestone, a priority, and a classification (Bug/Support Request/Feature Request). From here, ticket may be closed in all different manners (Fixed/Invalid/WontFix/etc), or they can be assigned to someone else, in which case they go back to "Assigned", until the new "owner" accepts it.

The idea here is that no one will get ticket w/o their consent (acceptance). However, the other side is that ticket should not spend a lot of time in the "Assigned" state - they should be accepted on a timely basis.

Closing ticket as "Fixed": When a developer closes a ticket as "fixed", there will be a field in the form where he can indicate a unit test that demonstrates the bug (in the old version) and verifies the fix (in the new version). Eventually, a failure of this unit test may automatically re-open the bug (or at least notify the developer).

Milestones: When a ticket is accepted, it should have a milestone attached to it. For example, many of the tickets currently have a milestone of 1.36.0. When the release process for 1.36.0 begins, the release manager will contact all the authors with tickets marked with that milestone, and ask about the status of those tickets. At that point, all the tickets that will not be fixed for 1.36.0 should have their milestones changed (by the authors) to reflect the new reality. This is a process change from the current system, where, at release, all open tickets whose milestones have been reached have their milestones changed. In the new system, the milestones will be checked early in the release cycle.

Also, we will probably add a "Unset" milestone; so that "To be determined" no longer means either "No one has looked at this" and "I've looked at it, but I'm not sure when the fix will make it into a release".

Patches: The section "Patches" in the track will be going away. A patch is just a bug with a proposed fix. The current patches will be re-categorized into "bugs" or "feature requests", depending on what is appropriate.

Inactive/Help Wanted tickets: We want to be able to mark tickets as "inactive", meaning that the developer is not working on this ticket at the current time, and/or "Help wanted", where the developer is looking for help in solving this ticket.

What we will be looking for:

• ticket that spend a lot of time in "Assigned" (but never accepted)
• Support Requests that languish for years.
• Tickets with

Other concerns:

• Libraries with multiple maintainers. This can be solved (with a bit of extra work) by setting up a single maintainer who hands tickets off to his colleagues.
• Libraries without maintainers.

I will add a picture soon.