[patch] Add a category field to the Tickets

[Christian Boos]

A category field can be used, well, to categorize tickets. This is a way to assign different meanings to tickets.

Even today, a ticket can represent many things:

• a bug
• another kind of problem report
• a patch
• a question
• a TODO
• a reminder
• a feature request
• etc.

But this is not direclty apparent. One has to go through the ticket itself to figure out, or to use tricks like the one used for this ticket (the [patch] prefix in the summary). Not to mention that the severity field is used to track the enhancements… It happens sometimes that a missing feature is of critical importance!

It would be nice to have the possibility to make this categorization explicit. This would allow to search for enhancement requests or bugs, and to make that information stand out in reports too.

Of course, the precise categories vary from project to project. By using trac-admin, one can modify the list of available categories.

For instance, I use:

• ER for Enhancement Requests
• PR for Problem Reports
• Task for something to be done
• Event when something happened and I want people to know
• ( … and also Milestone, because I work on the Ticket/Milestone unification, but that's a different story :) )

The proposed patch seems to work quite well, including the timeline and query module. I haven't change the default reports to include the category information yet, though.

What is also missing are different icons for the different categories, which could be used in the timeline.

[cboos@…]

patch that implements the proposed feature

[cboos@…]

The previous patch was incomplete (trac/upgrades/db8.py was missing)

[cboos@…]

… and the previous patch was sort of a cumulative one, including many other local changes. Sorry. Don't use it!

[Christopher Lenz]

Please don't just close a ticket without comment.

[cboos@…]

I

[cboos@…]

I

[cboos@…]

I

[cboos@…]

this one also illlustrate the patch #890

[cboos@…]

While that patch is a bit old, I find it very useful. I'm willing to work on an updated version if anyone shows interest. As I don't have a public trac available, you can still figure out how it looks like thanks to the recently added snapshots.

[Christian Boos]

There's now a branch dedicated to this feature: source:branches/cboos-dev/category-branch

[Christian Boos]

See [1489] for the first iteration of the updated patch.

[trac@…]

I am concerned that the category field is not sufficiently orthogonal to severity and priority.

Tickets in Trac 0.8.1 have severity and priority. As already pointed out in the notes for #1399, severity allows for a value of enhancement to describe a feature request as opposed to a bug report. The counter argument states that blocker type features exist. However, that distinction seems to imply a degree of priority.

In general I like the idea of having a ticket category or type that implies a special icon for use on the Timeline. Once we commit to that idea, however, it weakens the severity concept enough to make me wonder if either severity or priority should be eliminated.

For that matter, we might want different ticket types to have more or less fields than other types of tickets. For example, it does not seem intuitive for an Event ticket to have a priority? Yet in my experience, if the field is on the screen people feel compelled to fill them in with a value, so the fewer fields, the less intimidating the interface.

In the end, I wonder if a proliferation of ticket types and fields to describe them would make Trac less process agnostic and more intimidating.

[Christian Boos]

A few comments:

• different ticket types currently share the same ticket icons; as you said, it would be nice to be able to differentiate them graphically in the timeline. It would be easy to add that later, currently I'm more concerned about the initial idea being adopted.
• I understand your concern about redundancy between priority and severity. A lot of bug tracking systems deal with only one concept, and that's fine. However, you could use the severity field to rate the issue in an objective way (the importance of the enhancement/defect), and the priority to indicate what's actually going on with the issue (e.g. high if someone is currently working on it, low if nobody cares…). Just a matter of usage conventions.
• As for the specific fields for specific ticket types, I completely agree with you. However, I envision to do that as part of the TracObjectModelProposal, where fields could be attached to any kind of Trac Object. In this perspective, types and subtypes will have their own list of fields. The category will then naturally evolve to subtypes of tickets.
• A proliferation of ticket types would be a bad thing in all cases, but an appropriate number would certainly make the system more usable. By default, there are 3 types proposed: Bug, Feature and Task. I guess that's reasonably simple. See ​Ruby on Rails's Trac: they have Faults, Enhancements and Patches standing out in their customized interface. I'm quite sure they wouldn't mind having the possibility to directly create a ticket from one of those categories.

[trac@…]

Your points are well taken. The ticket categories of Bug, Feature, and Task are quite intuitive. They are better than the current model of using a special value of severity to indicate a feature.

However, I still think that we need to guard against field proliferation at every turn. The tool that I moved my team off of (and onto Trac) suffered from field proliferation. The tool allowed the administrator to define up to 26 fields for its equivalent of a ticket. Guess how many fields were defined … that's right, 26. Many of the fields were redundant and many others only applied to a fraction of tickets.

Trac is an elegant tool because the developers avoid the trap of solving every request by adding fields or features. Trac is focused and flexible, I'm just trying to do my part to make sure this feature is equally focused and flexible.

Having said that, your second bullet point illustrates my primary concern. The subtle distinctions that you draw between objective severity and ground truth priority might be useful, but in my opinion, usually just require more work to keep the data up to date. I think that priority is determined by many factors, including severity, and the target milestone. Because priority is typically implied by other fields I would vote to leave it out of the core tool (assuming category is added) in the interest of keeping the core simple and light, rather than complex and cumbersome.

[Angel Marin <anmar@…>]

Perhaps a way of avoiding intimidation would be to remove the non objective fields (priority and perhaps milestone and assign to) from the new ticket page (in a configurable way). Then filling up a new ticket would be less intimidating.

[trac@…]

I like that idea. Perhaps the presence of certain fields on the new ticket page should be tied to permissions.

[Christian Boos]

Right, that's a good idea. Also, an user would be able to report the severity, but only the developer (or the manager) would be able to set the priority and the milestone.

[trac@…]

That is exactly what I was thinking.

[Christian Boos]

The source:branches/cboos-dev/category-branch#1567 is candidate for merging in the trunk. Comments and tests appreciated!

[Christopher Lenz]

Some feedback on this thread: ​http://lists.edgewall.com/archive/trac/2005-April/thread.html#2790

[Christian Boos]

After a few adaptations, the patch got merged in [1691]

[anonymous]

As far as I can tell, this feature is included in 0.9.