= Trac Project Ticket Triage =

This page lists guidelines and conventions used within the Trac project for [http://en.wikipedia.org/wiki/Triage 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. 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. 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. 
   - `invalid`: the ticket was a test ticket, intended for another Trac, etc.
   - `duplicate`: there's already another ticket about the same issue

== 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 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.

== 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 [TracQuery TracQueries], so use them appropriately.
 - General indications
   * [query:group=status&keywords~=needinfo needinfo] - 
     waiting on information from the reporter 
   * [query:group=status&keywords~=tobedeleted tobedeleted] - 
     "noise" tickets that could eventually be safely deleted one day
   * [query:group=status&keywords~=helpwanted helpwanted] - tickets which are looking for contributors
   * [query:group=status&keywords~=review review] - 
     peer review requested
   * [query:group=status&keywords~=documentation documentation] - 
     things that need to be better documented
   * [query:group=status&keywords~=patch patch] - 
     same as review keyword, but when a patch is created by a third party
 - Related to branches
   * [query:group=status&keywords~=workflow workflow] - 
     waiting for workflow branch merge (see WorkFlow)
   * [query:group=status&keywords~=permissions permissions] - 
     waiting for permissions branch merge (see PermissionPolicy)
   * [query:group=status&keywords~=xref xref] - 
     related to the TracCrossReferences ideas
   * [query:group=status&keywords~=tracobject tracobject] - 
     related to the generalization of the Trac object/resource concept (see TracObjectModelProposal and TracDev/Proposals/DataModel)
 - Related to backends
   * [query:group=status&keywords~=mysql mysql]
   * [query:group=status&keywords~=postgres postgresql]
   * [query:group=status&keywords~=sqlite pysqlite]
   * [query:group=status&keywords~=svn12 svn12x], [query:group=status&keywords~=svn13 svn13y], [query:group=status&keywords~=svn14 svn 14z], ...
 - Other kinds of grouping
   * [query:group=status&keywords~=unicode unicode]
   * [query:group=status&keywords~=notification notification] - 
     any issue related to email notifications