Trac Project Ticket Triage
This page lists guidelines and conventions used within the Trac project for triage of tickets.
We focus on the Milestone information to decide whether a ticket has been triaged or not. Therefore, still to be triaged tickets can be found in queries specifying an unset milestone, such as query:status!=closed&milestone= or report:20.
There are currently:
How to help?
Anyone with some knowledge about the Trac project can help to apply the triaging rules, detect duplicate requests, eliminate invalid tickets and identify the real issues by assigning them a milestone.
- tickets which have nothing to do with Trac should be closed as
invalidwith the WrongTrac mention in the comment.
- tickets regarding a Trac plugin should be closed as
cantfixwith the PluginIssue mention in the comment. If the identity of the plugin is easily determined, add the
TH:<Plugin>mention in the comment.
- tickets which are clearly about installation issues or support requests should be invalidated as well, qualifying it as an InstallationIssue and directing the reporter to the MailingList.
- for complaints about the long inactivity on opened tickets, refer to ThisTicketWasOpenedTenYearsAgo.
For the tickets that are waiting for user feedback, anyone can help: close tickets which haven't received feedback since a few months or further process them if they have received feedback.
Finally, among the valid tickets, many are categorized as defects. Those should probably get the most attention or be recategorized as enhancements if they are not real defects.
Setting milestones to tickets adheres to the following dos and don'ts.
- If resolution is
fixed, the Milestone should be set according to the RoadMap. See report:36 for tickets that should be corrected.
- If resolution is
worksforme, the Milestone should be blank. See report:35 for tickets that should be corrected.
- If the ticket is valid and related to Trac, but no developer is planning to work on it for a next release, use unscheduled.
- If the ticket is valid and related to Trac, but not directly related to a release, use not applicable.
- Don't assign a milestone without a reason or patch.
- Don't modify a milestone as anonymous and without a reason.
- Don't assign a milestone of a bugfix only release (e.g. 0.10.5) to enhancement request tickets.
Status and Resolution
- 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 traceable change in the repository/documentation.
- the problem reported was not really a problem; the requested feature is already implemented or can be obtained in a different way.
- the problem reported is not really Trac's problem (use
cantfixwhen we don't control the code involved); alternatively, the requested feature won't be implemented, because we don't think it fits in the scope of the core of Trac and would therefore be better implemented as a plugin (use
- 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 could be opened with the requested API changes. If it's not clear what that change should be, then keep the request for change next to the use case, ie keep that ticket opened for the purpose of the API change.
- the ticket was a test ticket, intended for another Trac or something similar and should be closed as WrongTrac, PluginIssue or InstallationIssue.
- there is 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.
- Finally, duplicates created many times should be listed in the ticket duplicates hall of fame MostFrequentDuplicates.
- If marking as
And also, don't close or reopen a ticket without a reason.
When the ticket is neither about something that requires a modification to the documentation or the code, use the
Only administrators can edit ticket descriptions. They are only edited to fix formatting errors, not the actual content. Occasionally, we may also add editorial notes to not spread misleading information, eg #4297 or to summarize the current status of a long running issue, eg #4132 or #2611. In all cases, it should be quite clear from the formatting what's coming from the original author and what has been annotated afterwards.
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
- needfixup — waiting for corrections from the patch author
- verify — the ticket looks to be a valid bug report, but it would be worth that someone actually reproduces it, mainly because the person doing the triage can't reproduce it himself for some reason (different platform / browser / database, etc.)
- consider — interesting tickets, mainly for enhancements requests, that are worth to consider in the scope of a given milestone, but for which there's no commitment yet
- helpwanted — tickets which are looking for contributors
- bitesized — bite-sized work items, ideal for new contributors to dive in
- review — peer review requested
- patch — same as review keyword, but when a patch is created by a third party
- documentation — things that need to be better documented
- tobedeleted — noise tickets that could eventually be safely deleted one day
- Related to work done in branches: setuptools, workflow (see WorkFlow), permissions (see TracPermissions), xref (see TracCrossReferences), tracobject (see GenericTrac)
- Wannabee components: attachment, authz, batch-modify config, custom fields, diff, syntax highlighting, milestone, mimeview, plugin, preferences, query, session
- Related to backends and other third party software:
- DatabaseBackends: mysql, postgresql, pysqlite
- VersionControlSystems: svn (svn12, svn13, svn14, svn15, svn16, svn17, svn18), svk, mercurial, git
- Repository hooks: pre-commit-hook, post-commit-hook, CommitTicketUpdater
- Python compatibility issues: python25, python26, python27
- Other Python packages used: pygments, docutils, pytz, textile
- Platform specific issues: windows, solaris, macosx
- Presentation issues:
- Other kinds of grouping:
- crash — There is a segmentation fault or other serious OS level error implied.
- memory — Out of memory condition, most probably involving memory leaks.
- security — Security issues with Trac.
- performance — Performance sensitive issues.
- refactoring — Non-functional changes that improve the codebase.
- release — Coordination of software releases.
See TracDev/Topics for an expanded view of the above.
This section contains notes about the development of this document.
Policy for closing tickets
Suggestions subjecting ticket-close-policies:
- User intentions should be taken in account.
- Avoid closing tickets without a comment of the reporter; this is especially true if the reporter is an active contributor.
- Be open minded and accept that the existing processes have some deficiencies see #4174.
- 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.) — eblot
- Core developers have final authority to close tickets.