docs/project/ticket_wrangler_guide.pod - Tips for Ticket Wranglers
This document attempts to outline a set of "best practices" for dealing with tickets in Parrot's RT system. It is targeted at Parrot developers and "Ticket Wranglers" and is not intended as advice or instruction for end users. Ticket filing procedures for end users are documented in docs/submissions.pod.
A developer with sufficient permissions to modify the tickets in Parrot's RT system. All Parrot developers are expected to pitch in and help keep the ticket tracker in a healthy state. This means you!
The Parrot ticket tracker is currently the same as the Perlbug system used for Perl5 Development. It is available at https://rt.perl.org. The Parrot issues are in the queue parrot.
Where New refers to a pre-existing ticket sitting in the Parrot queue with a status of new.
new
Involves deciding whether the ticket is a real bug, a feature request, a duplicate or spam.
It is especially important that all new bugs which are marked [TODO], [PATCH] or [CAGE] be checked that they really are bugs of the given class. This is because some bugs, such as [TODO] and [CAGE] get their status set to open to indicate that something should be done, rather than something is being done.
open
Assign the issue to the queue spam. Note that if this is successful, you will no longer have permissions to view the ticket.
RT doesn't handle that case in a graceful manner. Set the relationship 'dependent on' to the duplicate issue. Add a comment to the ticket along the lines of "Duplicate of Ticket #123" and change the Tag field to "duplicate". Also, change the status to "rejected".
If not, ask for more input.
Is the subject line in the format "[TODO] subsystem - issue?
"[TODO] subsystem - issue
[TODO] tickets should have their status changed to open to prevent them from appearing in a listing of new tickets.
[TODO]
Is the subject line in the format "[PATCH] subsystem - issue?
"[PATCH] subsystem - issue
Make sure that there is actually a patch attached to the ticket. If you've applied a patch, be sure to include the revision in your response when closing the ticket.
Is the subject line in the format "[CAGE] subsystem - issue?
"[CAGE] subsystem - issue
[CAGE] bugs should have their status changed to open to prevent them from appearing in a listing of new bugs.
[CAGE]
This way you will receive further correspondence about the ticket.
If the ticket is more then 1 month old then it's considered old.
Give the requestor at least 1 week to respond. If no response is received then add a comment to the ticket saying that it is stalled because of no response from the requestor. Change the status to stalled.
stalled
If it's a [PATCH] ticket, it's possible that the patch was applied but the ticket/patch status was never changed. Also, not all list traffic regarding a ticket ends up in RT. It's best to look at the SVN repo to attempt to determine if the ticket was resolved.
Sometimes tickets are marked stalled because there's no hope if fixing them soon. Sometimes, no response is available from the requestor, or it can't be verified. Periodically, these tickets should be reviewed, and when possible, moved back to open or closed, as appropriate.
closed
Remember that every word you type into the ticket tracker is On The Record. Try not to say anything that could offend or hurt the feelings of anyone. That includes the ticket 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.
Try to add a little token of appreciation to every message you send in response to a ticket. Ticket 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 ticket/patch/whatever or perhaps some day become a Parrot developer.
Supposedly it's better customer relations to use issue(s) instead of the problem(s). Don't ask me why...
Always note why the ticket 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 ticket was unimportant or ignored.
Hi, Can you retest for this ticket 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
Hi, Can you resubmit this patch different against SVN trunk? Thanks, -J
Patch applied as rXXX. Thanks for submitting. -J
No response for requestor. Ticket being marked as 'rejected'. Thanks for reporting. -J
This doesn't appear to be an issue anymore. Thanks for submitting -J
Marking this ticket as 'resolved' because it seems to have fixed itself. Thanks for following up. -J
[tcl]: commit message
[tcl]: #37301: [BUG] 9262: env tests failing on win32
Courtesy of A. U. Thor <author@cpan.org>
Make it clear what your intent is when committing. It makes future maintenance much easier.
[PGE]: * Switched "PGE::Regex" to be "PGE::Grammar", to be more accurate. * Moved default rules from PGE::Regex into PGE::Match. * Updated various languages and tools to match.
You don't need to include the filename in the commit message as that's part of the commit itself. However, if your commit affects multiple directories, you may mention that, especially if it's part of a group of commits.
[PDD07]: whitespace -- part 5 ~ removed trailing spaces and tabs from t/exit/, t/dynpmc/, t/dynoplibs/
If all commits are much the same and require basically the same commit message, it can be useful to number the commit messages. For example:
[tools]: smartlink functionality -- part 3 ~ added regex attribute to Keyphrase class ~ filled in some more SmartLinkServer attribute init code ~ expanded LinkTree class functionality still TODO: merge smartlink and spec info, emit html, improve cmdline option code
You may optionally include items that are still todo, as it helps make your intentions clear.
Look at past commit messages, and http://cia.navi.cx/stats/project/parrot for more best practices.
There is a completely separate RT instance in which parrot tickets may occasionally appear. If you find one in this queue, create a new ticket in our RT system, add the original poster as a requestor to the new ticket, and remove yourself.
Then, close the ticket in the original system, and include a reference to the new ticket's url in our system when you close the original ticket.
https://rt.cpan.org/Dist/Display.html?Queue=parrot
Joshua Hoblitt (JHOBLITT) jhoblitt@cpan.org
jhoblitt@cpan.org
2 POD Errors
The following errors were encountered while parsing the POD:
Expected text after =item, not a bullet
To install Parrot::PMC, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Parrot::PMC
CPAN shell
perl -MCPAN -e shell install Parrot::PMC
For more information on module installation, please visit the detailed CPAN module installation guide.