How to Handle Boost Tickets

As of this writing, Boost has lots of open tickets, almost all of which were transferred to our Trac automatedly from SourceForge. Here are some effective ways of handling them.

Put the Reporter on the Notification List

The ticket reporter's name is a SourceForge userid. You can keep that person abreast of developments by adding @users.sf.net to the userid—then they'll get emails about all changes to the ticket.

Move attachments over from SourceForge

Unfortunately when the tickets were moved over from SourceForge, attachments were not moved with them. You can find the old tickets ​here, download the attachments, and attach them to the Trac tickets. Having a complete record is important to Boost's integrity!

Fix the Bugs that are Assigned to You

(Duh!) If you're logged in, here they are, in order of decreasing priority. However, if your SourceForge UserID is not the same as your Trac UserID, you may have a whole slew of other open tickets. See this report for all the owned tickets sorted by their original owner IDs.

Triage Unassigned Tickets

report:10 shows all tickets that haven't been assigned to real developers.

Assign Component and Owner

The most obvious thing you can do is to set the ticket's “component” field to the right library and assign the ticket to the maintainer of that library. If the right library doesn't appear in the “component” menu, send an email to boost-owner@… requesting that it be added. If you can't find an obviously-correct owner, try to put the maintainer's email address in the Ticket's Cc: list. Probably someone needs to start a Wiki page that identifies Boost library maintainers by their Trac/SVN ids.

Close Invalid “Feature Requests”

“Feature requests” that are actually suggestions for new Boost libraries are invalid—as tickets, that is. There's nobody to whom they can be assigned. The reporter should be directed to start a discussion in some forum where a qualified domain expert is likely to be listening.