Edgewall Software

Version 67 (modified by Ryan J Ollos, 10 years ago) ( diff )

Push an InstallationIssue to the MailingList.

Trac Project Ticket Triage

This page lists guidelines and conventions used within the Trac project for ​triage of tickets.

As a matter of fact, we happen to mainly 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, like query:status!=closed&milestone= or report:20.

There are currently:

  • 24 untriaged tickets
  • 0 tickets for which we're waiting for feedback
  • 1056 valid tickets to work on…

How to help?

First, there is a good deal of tickets which are not yet triaged. Anyone with some knowledge about the Trac project can help us to apply the triaging rules, in order to detect duplicate requests, eliminate invalid tickets and identify the real issues by assigning them a milestone.

  • tickets which are targeting a software which has nothing to do with Trac should be closed as invalid with the WrongTrac mention in the comment
  • tickets which are targeting a Trac plugin should be closed as cantfix with the PluginIssue mention in the comment. If the identity of the plugin is easily determined, add the TH:<Plugin> mention.
    • if the plugin is "agilo", then mention AgiloForScrum and add support@… to the CC:
  • 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 as well: close tickets which haven't received the requested feedback since a few months or further process them if they received some 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.

Milestone

  • If resolution is fixed, the Milestone should be set accordingly to the RoadMap. See report:36 for tickets that should be corrected one day.
  • If resolution is duplicate, cantfix, wontfix, invalid or worksforme the Milestone should be blank. See report:35 for tickets that should be corrected.
  • 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.
  • 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.

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 / cantfix
the problem reported is not really Trac's problem (use cantfix when 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, or because the feature would be better implemented as a plugin (use wontfix)
  • 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 very clear what that change should be, it is preferable to keep the request for change next to the use case (i.e. keep that ticket opened for the purpose of the API change).
invalid
the ticket was a test ticket, intended for another Trac, etc. (WrongTrac, InstallationIssue)
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.
  • Finally, if it's the nth time such a duplicate has been created, it's about time to list it in the ticket duplicates hall of fame, i.e. the MostFrequentDuplicates page.

And also, don't close or reopen a ticket without a reason.

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.

Ticket Description

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, in order to not spread misleading information, e.g. #4297 or to summarize the current status of a long running issue, e.g. #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.

Keywords

The purpose of keywords is to be able to generate pertinent and focused TracQueries, so use them appropriately.

See TracDev/Topics for an expanded view of the above.

Development Notes

(section contains notes about 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.)

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 existent processes have some deficits (for sure there are documentation deficits, that's why this document was initiated) see #4174
  • core developers have final authority to close tickets
Note: See TracWiki for help on using the wiki.