Version 26 (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
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. For ticket type task, fixed is used even if there was no trackable change in the repository/documentation.
worksforme
- the problem reported was not really a problem; the requested feature is already implemented or can be obtained in a different way
wontfix
- 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, or the feature is implemented as a plugin.
- Note: 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.
- Note: If an API change is required to get a feature to work (that is intended to be implemented as a plugin), then a new ticket is opened with the requested API changes.
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. - 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.
- If marking as
And also, don't close or reopen a ticket without a reason.
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
- refactoring - indicates a refactoring step (e.g. patch) which changes structure but not functionality
- Related to work done in branches:
setuptools, workflow (see WorkFlow), permissions (see PermissionPolicy), xref (see TracCrossReferences), tracobject (see GenericTrac) - Related to some technology/APIs used: datetime, unicode, genshi, wsgi
- wannabee components:
attachment, authz, config, custom fields, diff, syntax highlighting, milestone, mimeview, email notifications, plugin, query, session - Related to backends and other 3rd party software
- DatabaseBackends: mysql, postgresql, pysqlite
- VersioningSystemBackends: svn (svn12, svn13, svn14), svk, mercurial
- Python compatibility issues: python21, python22, python25
- Other Python packages used: docutils, enscript, silvercity
- Platform specific issues: windows, solaris, macosx (TODO there are some Macintosh OS X to fix)
- Presentation issues
- Other kinds of grouping
Development Notes
(section contains notes subjecting the development of this document)
Policy for closing tickets for outdated Trac releases
- eblot: Following the update Matt did on #4222, I think we also need to document what is / would be the policy for outdated Trac releases (criteria to declare as wontfix, etc.)