Version 5 (modified by 18 years ago) ( diff ) | ,
---|
Trac Project Ticket Triage
(document status: under development - please provide feedback to increase clarity and completeness)
This page lists guidelines and conventions used within the Trac project for triage of tickets.
Status and Resolution
- Don't close or reopen a ticket without a reason
fixed
is used when the resolution of the ticket can be linked to some change in the repository, a code change, a primary documentation fix, a contribution script added, etc. Otherwise use:worksforme
: the problem reported was not really a problem; the requested feature is already implemented or can be obtained in a different waywontfix
: the problem reported is not really Trac's problem; the requested feature won't be implemented because we don't think it fits in the scope of the core of Trac. In some cases however (e.g. #2611), we let the issue open even if the cause of the issue is not directly Trac's fault, so that workarounds and user experience can be collected.invalid
: the ticket was a test ticket, intended for another Trac, etc.duplicate
: there's already another ticket about the same issue
Milestone
- If resolution is
fixed
, the Milestone should be set, otherwise it should be blank. - Don't assign a milestone without a reason or patch.
- Don't modify a milestone as anonymous and without a reason.
- If marking as
duplicate
, include referring ticket #s in both duplicate and duplicated tickets.- In duplicate ticket: This ticket is duplicate of #1234
- In original request: #2345 has been marked as duplicate of this ticket
- We usually let open the ticket which contains the most up-to-the-point discussion about the issue, the one which contains an appropriate patch, or other than that, the oldest ticket.
Ticket Title
- [PATCH] prepended - if you are the original ticket creator, then adding
[PATCH]
to the ticket title indicates a patch attached to ticket for review and integration that works for you.
Ticket Type
When the ticket is neither about something that requires a modification to the documentation or the code, use the task
type.
(note: those ticket types need to be closed with a valid resolution, too. see #4212)
Keywords
The purpose of keywords is to be able to generate pertinent and focused TracQueries, so use them appropriately.
- General indications
- needinfo - waiting on information from the reporter
- tobedeleted - "noise" tickets that could eventually be safely deleted one day
- helpwanted - tickets which are looking for contributors
- review - peer review requested
- documentation - things that need to be better documented
- patch - same as review keyword, but when a patch is created by a third party
- Related to branches
- workflow - waiting for workflow branch merge (see WorkFlow)
- permissions - waiting for permissions branch merge (see PermissionPolicy)
- xref - related to the TracCrossReferences ideas
- tracobject - related to the generalization of the Trac object/resource concept (see TracObjectModelProposal and TracDev/Proposals/DataModel)
- Related to backends
- Other kinds of grouping
- unicode
- notification - any issue related to email notifications
Note:
See TracWiki
for help on using the wiki.