In the spirit of clarity/specificity in naming, and because I just had a conversation at work about this, I thought I’d write about it here.

A defect (or feature) describes the system.
A ticket (or task) describes work to be done on the system.

There is a tendency to conflate the two, and try to shoehorn inappropriate properties into one or the other. This is usually based on whether you happen to be using a ticketing tool or a defect tracking tool.

It is easy to want to combine the two, because after all, fixing a defect requires work (often not just developer work either, if for example, the defect is caused by a network configuration issue that requires system engineering work), has an assignee, and states such as open/closed, etc.

I’m not arguing against tracking both in the same tool, but I’m arguing for a clearer separation. For instance, if someone is assigned a bug, they become the owner of it. They then create a task to fix the bug. When the task is complete the change the status of the bug to resolved (or verify, or whatever your workflow specifies)

Now, if you have two separate tools, it gets pretty tedious. Thus the urge to combine them.

Defects have state, they do not have dynamic components. In one sense, I’m arguing against object orientedness, in the OOP sense, though a defect has accessors and mutators, a defect does not perform actions.

If you’re a development organization, you probably think of things in terms of defects and features. Because when all the defects and features are implemented, your work is done. However, if you’re in an operational organization, you probably think of things in terms of work and requests.

Work may be done to fix a defect, and a feature may be requested, but that ‘s a semantic blurring between describing a feature and describing what needs to be done to implement it.

I’d argue that integration between tools is desirable. A ticket should be able to reference a defect, and a task should be created to work on a defect. This can be on the same form and handled seamlessly, but I think it’s better to help everyone think about the separate terms.