Ticket Types

Warning: this feature is not yet availble in the mainline Trac

Rationale

When creating a new ticket, Trac enables you to select the appropriate type for that ticket. Indeed, a ticket can represent anything ranging from a problem report, a support request, an idea for a new feature or actually any artifact that fits in your development process.

Among issue trackers, Trac was initially on the undifferentiated camp, everything was treated the same and it was only from the description that one could tell in which category a ticket would fit.

However, the need for a more structured partitioning of the ticket type appeared (e.g. #919, #1399) and several Trac sites where actually tweaking the severity field to be the ticket type, or creating TracTicketsCustomFields for that purpose.

Now, with the ticket type field, one is able to store this information as part of the core properties of the ticket, which permits to display the type of a ticket in more interesting places, usually next to the ticket number.

What does it look like?

in the Ticket page's title:	​http://projects.edgewall.com/trac/attachment/wiki/TicketTypes/tt_title.2.png?format=raw
in the TracTimeline:	​http://projects.edgewall.com/trac/attachment/wiki/TicketTypes/tt_timeline.2.png?format=raw
Also, it's the first field you can select when creating a new ticket:	​http://projects.edgewall.com/trac/attachment/wiki/TicketTypes/tt_new.2.png?format=raw

What if I don't like ticket types?

No problem. With trac-admin, you can use the ticket_type to perform a few things on ticket types:

• list
• add
• delete
• rename

You can customize the ticket types to match your local requirements.

If you delete all ticket types, then the feature is gone! Trac will work the same way it ever did without ticket types (i.e. Trac 0.[5-8].x behavior).

Why is the severity field gone?

Trac strives to be a simple to install, simple to use system. Offering in the default setup a combination of ticket type, severity, priority and milestone was deemed too daunting for new users.

The advised configuration is therefore:

• type, for categorizing the ticket
  • Defect: a bug, anything that does not work as expected
  • Enhancement: a new feature or an improvement over an existing one
  • Task: everything else, something that needs to be done
• milestone used for scheduling
• priority, for asserting the importance of a the ticket
  • blocker: basic functionality is not available until this is fixed
  • critical: severe loss of data due to the defect or highly needed enhancement
  • major: defect with major impact / big enhancement
  • minor: defect with minor impact / small enhancement
  • trivial: defect with little or no impact / cosmetic enhancement

However, some users would like to keep the current distinction between severity and priority:

• type, for categorizing the ticket
• milestone used for scheduling
• severity for trying to assert the objective importance or impact of the ticket (the values would be the same as those listed for the priority field above)
• priority to help organize the scheduling within a given milestone (fields like highest, high, normal, low, lowest). This is more a subjective field, based on other considerations than the objective severity (typically those of a product manager :-) ).

In order to support that usage, the severity field has been kept in the database. It simply needs to be "activated" by using the severity command in trac-admin.