Version 16 (modified by 17 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
- 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.
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 adding an enhancement request ticket, don't set the milestone to a bugfix only release (e.g. 0.10.2).
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.
Keywords
The purpose of keywords is to be able to generate pertinent and focused TracQueries, so use them appropriately.
- General indications - influencing the ticket workflow
- 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 work done in branches
- setuptools - waiting for setuptools branch merge (see ?)
- 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 some technology/APIs used
- wannabees components
- Related to backends and other 3rd party software
- DatabaseBackends
- VersioningSystemBackends
- Python, python modules, misc.
- python21, python22, python25 - compatibility issues
- docutils
- enscript
- silvercity
- Platform specific issues
- Presentation issues
- Other kinds of grouping
Development Notes
(section contains notes subjecting the development of this document)
- ilias said: note to mgood: this is a draft document, under collaborative development. I've used the trac abilities to interlink to an directly related open ticket. Please do not remove those links, and if you do so, please add at least a "Comment about the change".
- ilias said: possibly the sections of the the document should be in the order on which a user hits on the fields (e.g. Ticket Type first).
sid said: maybe, but you definitely want to convey the most important info first… so priority if information is not necessarily the same order as the tickets appear on the ticket view page.
- ilias said: the 'keywords' section should possibly moved out to a separate document
sid said: I disagree. The keywords is a long section, but I want one page open while I'm working on tickets for reference, not 2.. and I think all on one is a good plan to stick to. If it gets too complicated for 1 page, time to simplify!
- More discussion here (from mgood): I've started a topic on the MailingList for discussing the suggestions in #4259 and #4260: http://groups.google.com/group/trac-dev/browse_thread/thread/39f61acef4526dbc/1d9e8471e57f40a1#1d9e8471e57f40a1
- And from Ilias:
task
ticket types need to be closed with a valid resolution, too. see #4212