| | 1 | = How to Handle Boost Tickets = |
| | 2 | |
| | 3 | 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. |
| | 4 | |
| | 5 | == Fix the Bugs that are Assigned to You == |
| | 6 | |
| | 7 | Duh! |
| | 8 | |
| | 9 | == Put the Reporter on the Notification List == |
| | 10 | |
| | 11 | 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. |
| | 12 | |
| | 13 | == Triage Unassigned Tickets == |
| | 14 | |
| | 15 | report:10 shows all tickets that haven't been assigned to real developers. |
| | 16 | |
| | 17 | === Assign Component and Owner === |
| | 18 | |
| | 19 | 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@lists.boost.org 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. |
| | 20 | |
| | 21 | === Close Invalid “Feature Requests” === |
| | 22 | |
| | 23 | “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. |
