Ditto here also.

 

We added a custom field for ‘type’ and removed the “enhancement” entry

from severity.  We considered splitting out severities to 3*n entries (where n

is the number of entries in the defaults) and the 3 is for (task, feature, bug),

but that’s less straight forward than having a severity of “enhancement”

which is a little wierd itself.

 

While this is awesome (and I pretty much tried every bug tracker, project

manager, etc software out there), there are very good reasons to build it

in.  Mostly, wanting it in the reports without having to write the SQL

ourselves and do that fancy “join” regarding the database and custom

fields.

 

Seems to me any such customizations would have to be patched back in after

each upgrade ... but that’s another subject and I don’t know what I’m

talking about...so...I won’t.

 

Bug, feature and task are exactly what we wanted – would be nice defaults

for ‘type’.  We note that these aren’t exactly always disjoint things (is

that a bug or a feature ?), but where there are shades of grey ... there

should be and those shades of grey will be reflected in the reports/queries

from trac .. as they should be.

 

on Tirelli wrote:

>

>   Christian,

>

>   Im my company we use Track 0.8 and we created a custom field for

> "Type" with the values "Bug", "Feature", "Maintenance Request" and

> "Information Request". Of course the types you listed can be used with

> Task being used for MR and IR. Anyway, it would be good for us to have

> it as a built in field instead of a custom.

>   Regarding type, severity and priority, we use all of them here:

>

> Type: to classify the type of the ticket

> Severity: to inform the impact the issue has in his context

> Priority: the order the developers/analysts should use to solve tickets

 

We use these fields exactly the same way.  Sometimes we have bugs that

pop that are pretty severe in terms of things like dataloss, but they

chance of it happening is really small.  Our customers would rather we

fix other problems first.

 

>   Don't know if it is the best way to use them, but this is the way we

> use them here.

>

>   So, it would be good for us to continue having the 3 fields.

 

Same here.

 

-John