Edgewall Software

Changes between Version 79 and Version 80 of TracTicketTriage


Ignore:
Timestamp:
Aug 19, 2015, 11:01:41 AM (9 years ago)
Author:
figaro
Comment:

Cosmetic changes

Legend:

Unmodified
Added
Removed
Modified
  • TracTicketTriage

    v79 v80  
     1[[PageOutline(2-5,Contents)]]
     2
    13= Trac Project Ticket Triage
    24
     
    1315
    1416Anyone 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.
    15  - tickets which have nothing to do with Trac should be closed as //invalid// with the **WrongTrac** mention in the comment
    16  - tickets regarding 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.
    17    - if the plugin is "agilo", then mention **AgiloForScrum** and add support@agile42.com to the CC:
     17 - tickets which have nothing to do with Trac should be closed as `invalid` with the **WrongTrac** mention in the comment.
     18 - tickets regarding 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 in the comment.
     19   - if the plugin is "agilo", then mention **AgiloForScrum** and add `support[at]agile42.com` to the CC:
    1820 - 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.
    19  - for complaints about the long inactivity on opened tickets, refer to **ThisTicketWasOpenedTenYearsAgo** 
     21 - for complaints about the long inactivity on opened tickets, refer to **ThisTicketWasOpenedTenYearsAgo**.
    2022
    21 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 feedback.
     23For 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.
    2224
    2325Finally, among the valid tickets, [query:status!=closed&milestone!=&keywords!~=needinfo&type=defect&group=milestone many are categorized as defects]. Those should probably get the most attention or be recategorized as enhancements if they are not real defects.
     
    2527== Milestone
    2628
     29Setting milestones to tickets adheres to the following dos and don'ts.
     30
    2731=== Dos
    2832
    29  * If resolution is `fixed`, the Milestone should be set accordingly to the RoadMap. See report:36 for tickets that should be corrected one day.
     33 * If resolution is `fixed`, the Milestone should be set according to the RoadMap. See report:36 for tickets that should be corrected.
    3034 * If resolution is `duplicate`, `cantfix`, `wontfix`, `invalid` or `worksforme` the Milestone should be blank. See report:35 for tickets that should be corrected.
    3135 * If the ticket is valid and related to Trac, but no developer is planning to work on it for a next release, use [milestone:unscheduled].
     
    4145
    4246 `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.
    43  `worksforme`:: the problem reported was not really a problem; the requested feature is already implemented or can be obtained in a different way
    44  `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//)
    45    * ''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.
    46    * ''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).
    47  `invalid`:: the ticket was a test ticket, intended for another Trac, etc. (WrongTrac, InstallationIssue)
    48  `duplicate`:: there's already another ticket about the same issue
     47 `worksforme`:: the problem reported was not really a problem; the requested feature is already implemented or can be obtained in a different way.
     48 `cantfix` / `wontfix` :: 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`).
     49   * '''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.
     50   * '''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, ie keep that ticket opened for the purpose of the API change.
     51 `invalid`:: the ticket was a test ticket, intended for another Trac or something similar and should be closed as WrongTrac, PluginIssue or InstallationIssue.
     52 `duplicate`:: there is already another ticket about the same issue:
    4953   * If marking as `duplicate`, include referring ticket #s in both duplicate and duplicated tickets.
    50      - In duplicate ticket: ''This ticket is a duplicate of #1234''
    51      - In original request: ''#2345 has been marked as a duplicate of this ticket''
     54     - In duplicate ticket: ''This ticket is a duplicate of #1234''.
     55     - In original request: ''#2345 has been marked as a duplicate of this ticket''.
    5256   * 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.
    53    * Finally, if it's the n^th^ time such a duplicate has been created, list it in the ticket duplicates hall of fame, i.e. the MostFrequentDuplicates page.
     57   * Finally, duplicates created many times should be listed in the ticket duplicates hall of fame MostFrequentDuplicates.
    5458
    5559And also, don't close or reopen a ticket without a reason.
     
    8488   * [kwquery:patch] -- same as review keyword, but when a patch is created by a third party
    8589   * [kwquery:documentation] -- things that need to be better documented
    86    * [kwquery:tobedeleted] -- "noise" tickets that could eventually be safely deleted one day
     90   * [kwquery:tobedeleted] -- noise tickets that could eventually be safely deleted one day
    8791 - Related to work done in branches:
    8892   [kwquery:setuptools],
     
    165169   * [kwquery:crash] -- There is a segmentation fault or other serious OS level error implied.
    166170   * [kwquery:memory] -- Out of memory condition, most probably involving memory leaks.
    167    * [kwquery:security] -- Security issues with Trac
    168    * [kwquery:weird] -- Bugs from outer space
    169    * [kwquery:performance] -- Performance sensitive issues
    170    * [kwquery:refactoring] -- Non-functional changes that improve the codebase
    171    * [kwquery:release] -- Coordination of software releases
     171   * [kwquery:security] -- Security issues with Trac.
     172   * [kwquery:performance] -- Performance sensitive issues.
     173   * [kwquery:refactoring] -- Non-functional changes that improve the codebase.
     174   * [kwquery:release] -- Coordination of software releases.
     175   * [kwquery:weird] -- Bugs from outer space.
    172176
    173177See TracDev/Topics for an expanded view of the above.
    174178
    175 === Development Notes
     179== Development Notes
    176180
    177181This section contains notes about the development of this document.
    178182
    179 ==== Policy for closing tickets for outdated Trac releases
    180 
    181 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
    182 
    183 ==== Policy for closing tickets
     183=== Policy for closing tickets
    184184
    185185Suggestions subjecting ticket-close-policies:
     
    187187 * Avoid closing tickets without a comment of the reporter; this is especially true if the reporter is an active contributor.
    188188 * Be open minded and accept that the existing processes have some deficiencies [comment:ticket:4174:15 see #4174].
     189 * 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
    189190 * Core developers have final authority to close tickets.