2008/6/28 Michael Stratmann <[EMAIL PROTECTED]>: > On 28 Jun., 08:16, Risto Kankkunen <[EMAIL PROTECTED]> wrote: >> I wonder how common or useful it is to change a ticket type after it >> has already gone through some state transitions? I think the type of >> the ticket (enhancement, defect, task) should be pretty obvious after >> some person from the project has looked into it. One might even argue >> that the type should only be set by a project member, not by the >> submitter. > > Examples: Customer complains "This is a bug". Developer gets to > analyse it and agrees. Project manager gets it and says: "Oh no, that > was not part of contract, it's an addon we can get money for it.". > From QA point of view: It matters if you have 10 new bugs per week or > 5 new bugs and 5 feature requests, whilst developers solve only 7. The > predicted delivery date (and the blame for the delay) strongly depend > on that.
So, for this use case, being able to change the ticket 'type' should itself be part of the workflow, no? Instead of having multiple ticket types each having a different workflow causing a lot of trouble if you try switching from one to the other, you could have *one* bigger workflow covering all of them. It would have to model a ticket 'type' but could then have well defined transitions between them. Just a thought. - Thomas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
