> Let's take the example of bugs vs. enhancements. I'd say among tickets, > 40% are clearly bugs, 40% are clearly enhancements requests and 20% > could be seen as either one or the other, depending on the point of view. > So I think it really makes sense to be able to requalify a ticket from > bug to enhancement and vice versa, if the point of view changes (e.g. it > could be up to the "owner" to have the final say on this). > > > Restrictions like different workflows pushes Trac usage to more "getting > > in a way" philosophy. > > For most workflows, I think it makes sense to treat an enhancement or a > bug the same, even for the "enterprise workflow" we ship as an example. > But a mere "task" probably doesn't need to go through Q&A, for example.
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. So there could be a couple of general states (submitted, ...) and then type-specific states after the type has been decided. Also, rather than to morph or copy tickets, it can be useful to add subtickets with suitable types (assign several tasks as subtickets to an enhancement etc.) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
