Edgewall Software

Version 22 (modified by ilias@…, 17 years ago) ( diff )

refactorign keyword, some discussion

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

  • Don't close or reopen a ticket without a reason
  • 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. Otherwise use:
    • 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.
    • 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.

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

Development Notes

(section contains notes subjecting the development of this document)

Section order

  • lazaridis: possibly the sections of the the document should be in the order on which a user hits on the fields (e.g. Ticket Type first).
    • sid: maybe, but you definitely want to convey the most important info first… so priority if information is not necessarily the same order as the tickets appear on the ticket view page.
      • lazaridis: ok, seems you are right

Keywords on separate page

  • lazaridis: the 'keywords' section should possibly moved out to a separate document
    • sid: I disagree. The keywords is a long section, but I want one page open while I'm working on tickets for reference, not 2.. and I think all on one is a good plan to stick to. If it gets too complicated for 1 page, time to simplify!
      • lazaridis: 1-page solution is fine. You are right that a long keyword sections indicates the need to simplify, as it's an indication that something is wrong.

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.)
Note: See TracWiki for help on using the wiki.