Changes between Version 61 and Version 62 of TracTicketTriage

Timestamp:

Jul 27, 2012, 2:38:39 PM (12 years ago)

Author:

Christian Boos

Comment:

document the implicit conventions we have for invalid tickets

TracTicketTriage

@@ -13 +13 @@
 
 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@agile42.com to the CC: 
+ - tickets which are clearly about installation issues or support requests should be invalidated as well, mentioning an InstallationIssue
 
 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.
@@ -38 +42 @@
  `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 [wiki:TracPlugins plugin].
+ `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 [wiki:TracPlugins 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 [wiki:TracPlugins 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.
+ `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.