Edgewall Software
Modify

Opened 19 years ago

Closed 19 years ago

Last modified 9 years ago

#919 closed enhancement (fixed)

[patch] Add a category field to the Tickets

Reported by: Christian Boos Owned by: Christian Boos
Priority: high Milestone: 0.9
Component: ticket system Version: devel
Severity: normal Keywords: ticket category
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Christopher Lenz)

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.

Attachments (8)

category.1048.patch (13.9 KB ) - added by cboos@… 19 years ago.
patch that implements the proposed feature
category.1060.patch (92.9 KB ) - added by cboos@… 19 years ago.
The previous patch was incomplete (trac/upgrades/db8.py was missing)
category.1105.patch (17.8 KB ) - added by cboos@… 19 years ago.
… and the previous patch was sort of a cumulative one, including many other local changes. Sorry. Don't use it!
new_ticket_with_category.png (11.0 KB ) - added by cboos@… 19 years ago.
I
ticket_view_with_category.png (20.8 KB ) - added by cboos@… 19 years ago.
I
ticket_change_with_category.png (7.9 KB ) - added by cboos@… 19 years ago.
I
timeline_with_category.png (39.5 KB ) - added by cboos@… 19 years ago.
this one also illlustrate the patch #890
custom_query_with_category.png (23.9 KB ) - added by cboos@… 19 years ago.

Download all attachments as: .zip

Change History (25)

by cboos@…, 19 years ago

Attachment: category.1048.patch added

patch that implements the proposed feature

by cboos@…, 19 years ago

Attachment: category.1060.patch added

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

by cboos@…, 19 years ago

Attachment: category.1105.patch added

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

comment:1 by anonymous, 19 years ago

Resolution: worksforme
Status: newclosed

comment:2 by Christopher Lenz, 19 years ago

Description: modified (diff)
Resolution: worksforme
Status: closedreopened

Please don't just close a ticket without comment.

by cboos@…, 19 years ago

I

by cboos@…, 19 years ago

I

by cboos@…, 19 years ago

I

by cboos@…, 19 years ago

Attachment: timeline_with_category.png added

this one also illlustrate the patch #890

by cboos@…, 19 years ago

comment:3 by cboos@…, 19 years ago

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.

comment:4 by Christian Boos, 19 years ago

Priority: normalhigh

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

comment:5 by Christian Boos, 19 years ago

Owner: changed from Jonas Borgström to Christian Boos
Status: reopenednew

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

comment:6 by trac@…, 19 years ago

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.

comment:7 by Christian Boos, 19 years ago

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.

comment:8 by trac@…, 19 years ago

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.

comment:9 by Angel Marin <anmar@…>, 19 years ago

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.

comment:10 by trac@…, 19 years ago

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

comment:11 by Christian Boos, 19 years ago

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.

comment:12 by trac@…, 19 years ago

That is exactly what I was thinking.

comment:13 by Christian Boos, 19 years ago

Status: newassigned

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

comment:15 by Christian Boos, 19 years ago

Resolution: fixed
Status: assignedclosed

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

comment:16 by anonymous, 18 years ago

Milestone: 0.9

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

comment:17 by Ryan J Ollos, 9 years ago

Reporter: changed from cboos@… to Christian Boos

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.