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.