You are here: Contributions » Boost.Guild » Ticket Handling 

Ticket Handling

Adopt tickets (i.e., bug reports), filtering them and finding fixes.

Your goal: reduce open tickets, transforming some into a valuable set of fixes: low-hanging fruit for release managers to incorporate.

Pick a boost component (library). One you love. Or one that baffles you. Or one that has a lot of open tickets.

Get to know your library by reading the documentation and getting to know its regression tests. This is important: the regression tests exercise the library. They're your touchstone.

Get to know the system (Trac) for reporting bugs, and the ticket workflow. (More references below.) Peruse the open tickets.

Adopt a ticket. Spend a little time understanding it.

Triage: modify the ticket's attributes (e.g., severity) as necessary. (E.g., is this really a feature request? A showstopper?) Add your e-mail to the CC. [More detail req'd here.]

Interact with the ticket's submitter by adding comments, as appropriate: ask for clarity, etc.

Map the ticket to existing regression test(s). You understand them better than the submitter.

Is it covered? Work with the submitter to reproduce the problem by adapting a test.

Should a regression be modified, or a new one written? Do it and attach it to the ticket as a trunk patch. But don't mark the patch as ready to bring into the trunk yet: a fix needs to go with it.

Close the ticket if you can. If you're so inclined, move beyond triage to take a shot at handling it.

Is it a real bug? Take a shot at a fix. Use the current trunk from subversion as your starting point. Run bjam in the library's test directory. See Regression Troubleshooting for details.

Stumped? Can't figure it out?

  • Be self-study.Put it down and come back to it later. A couple times. There's no shame asking for help, but doing it yourself is most satisfying.
  • Collaborate with other volunteers in your position.
  • Ask a mailing list.
  • Skip it and move on. Come back in a month, or leave it for someone else.

Follow up on changes you submitted to the trunk, and close those tickets when they're fixed.

Mark your patchesas safe for a reviewer to merge into the trunk. [Method to mark them is TBD, but likely adding a special keyword

Keep your own list of brief descriptions of everything you fix, for input to the next version's release notes.

Be diplomatic with submitters. You're boost's ambassador to them. Bear with their aggravation at boost not working as they think it should. They might be wrong, but they've still donated their time to improve boost with this ticket. Your attention helps them feel heard, and that alone is huge.

Be patient with everyone: maintainers, release managers, submitters, trunk-patchers. They're all volunteering their time. Things always move more slowly than you want.

No new features. That's outside the Guild's scope. If you'd like to add features, work toward becoming a library maintainer.

Your inputs for a given library (or "component"):

  • The component's documentation.
  • Its regression tests.
  • The open tickets on it.
  • The current trunk regression results.

Your outputs:

  • Modifications to tickets: your comments, updated attributes (severity, milestone, etc.), closing them if possible.
  • Patches to the trunk: mods to (or new) regressions, attached to a ticket.
  • Bullet items on the new release notes. See a previous version for a sample.

Required reading and references:

You're hired. Dive in. You don't need any special permissions.

Thanks for helping improve boost! Your contribution is greatly appreciated.

Last modified: 2013-01-10


^ Top

Previous page: Boost.Guild
Next page: Regression Troubleshooting