NAME ^

docs/dev/wranglers.pod - Tips for Bug Wranglers

ABSTRACT ^

This document attempts to outline a set of "best practices" for dealing with bugs in Parrot's RT system. It is targeted at Parrot developers and "Bug Wranglers" and is not intended as advice or instruction for end users. Bug filing procedures for end users are documented in docs/submissions.pod.

WHAT IS A BUG WRANGLER? ^

A developer with sufficient permissions to modify the tickets in Parrot's RT system. All Parrot developers are expect to pitch in and help keep the bug tracker in a healthy state. This means you!

WHERE IS IT? ^

The Parrot bug tracker is currently the same as the Perlbug system used for Perl5 Development. It is available via HTTP at http://rt.perl.org. The Parrot issues are in the queue parrot.

BUG HANDLING PROCEDURES ^

New Bugs ^

Where New refers to a pre-existing bug sitting in the Parrot queue with a status of new.

TODO Bugs ^

Old Bugs ^

If the bug is more then 1 month old then it's considered an old bug.

TIPS FOR CORRESPONDENCE ^

Don't be a Butthead ^

Remember that every word you type into the bug tracker is On The Record. Try not to say anything that could offend or hurt the feelings of anyone. That includes the bug submitter and other developers. When, as a Parrot developer with commit rights, you send correspondence you are representing the Parrot project and by proxy TPF. If in doubt, either send the message privately or not at all.

Say thank you! ^

Try to add a little token of appreciation to every message you send in response to a bug. Bug requestors are doing labor for free! The least you can do is let them know that you appreciate their efforts.

Something like:

    Thanks,

    Thanks for following up.

    Thanks for reporting.

    Thanks for X!

Can work wonders. If you can make someone feel good about themselves maybe they'll submit another bug/patch/whatever or perhaps some day become a Parrot developer.

Don't say "problem" ^

Supposedly it's better customer relations to use issue(s) instead of the problem(s). Don't ask me why...

Make it clear why the bug status changed ^

Always note why the bug is having it's status changed. Particularly if it is being closed or rejected. Nothing will irritate people more then letting them think that their bug was unimportant or ignored.

Example Correspondence ^

    Hi,

    Can you retest for this bug with the latest sources from SVN and confirm
    that this still an open issue?

    Thanks,

    -J

or

    Hi,

    Would you mind retesting with the latest sources from SVN?

    Thanks,

    -J

or

    Hi,

    Can you resubmit this patch different against SVN trunk?

    Thanks,

    -J

or

    Patch applied as rXXX.  Thanks for submitting.

    -J

or

    No response for requestor.  Bug being marked as 'rejected'.
    Thanks for reporting.

    -J

or

    This doesn't appear to be an issue anymore.
    Thanks for submitting

    -J

or

    Marking this bug as 'resolved' because it seems to have fixed itself.
    Thanks for following up.

    -J

AUTHOR ^

Joshua Hoblitt (JHOBLITT) jhoblitt@cpan.org


parrot