On Thu, Jun 26, 2008 at 11:51:45AM +0200, Christian Boos wrote: > > Jani Tiainen wrote: > > Christian Boos kirjoitti: > > > >> Lucas Eisenzimmer wrote: > >> > >>> I was just wondering whether you have a rough date in mind when Trac 0.12 > >>> might be stable. We are using Trac for requirements engineering and we > >>> would > >>> need 'real' ticket type depending workflows. Theoretically, the triage > >>> function of the AdvancedTicketWorkflowPlugin would do it, but for several > >>> ticket types with own, separated workflows it starts to get confusing and > >>> buggy very fast. > >>> > >>> > >> Granted, I also think that separated workflows for each ticket type are > >> clearer when you need them, which leaves open the problem of how to > >> transition from one such workflow to another when the type changes. > >> > > > > For example Redmine (that get's referred lot nowadays) has very > > "complex" workflow engine. You can have per issue type, per role > > configurations. > > Yes, seems nice. > > > But Redmine _doesn't_ allow change of issue type. But > > instead there is copy option where you have possibility to change type. > > > > This leads to very philosophical question: > > > > Is ticket, once issued, on the system locked to type it has? Currently > > Trac is very liberate in this sense and allows change of issue type > > which fits well to "staying away" philosophy. > > > > 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. > Some teams may want to have relaxed or different rules for some types of > tickets, it's all about the flexibility to add /adapted/ constraints. > I would rephrase what you said in the above by saying "the ticket > workflow allows you to adapt Trac to *your* way of doing things". If the > workflow is not adapted, it will get in your way, even if it's a simple > one. If having different workflows for different ticket types is really > what's adapted for you, then by definition it doesn't go in the way. > > > I see following solutions to this: > > * Don't allow type change > > > > No, for the reasons exposed above. > > > * Require default state for each ticket type and set that in > > case of change > > > > Might work (reset to "new"). > > > * Add change-on-copy functionality (similiar to Redmine) > > > > Unnecessarily complex for now. If one day different ticket types will > map to different kind of ticket resources (sub-classes, with different > fields as well), then this should be reconsidered. Even then, I'd favor > being able to do a smoother conversion if possible. > > > * Complex rules translating between states. > > > > The most flexible solution. > > > Translation is not even trivial. If you think of following: > > > > If we have enhancement states like: > > > > 'new', 'accepted', 'rejected' and 'implemented' > > > > And bug states like: > > 'new', 'accepted', 'invalid', 'testing', 'fixed' > > > > There is not much common... So it would lead to one more factor: You > > need to be able to restrict type to change depending on current state. > > > > Well, according to the idea exposed in the ticket, you could have > something like: > > [ticket-type-workflow] > # old type . old state => new type . new state > enhancement.rejected = defect.invalid > enhancement.implemented = defect.testing > enhancement.* = defect.* > defect.invalid -> enhancement.rejected > defect.testing -> enhancement.implemented > defect.fixed -> enhancement.implemented > defect.* = enhancement.*
Yeah, this looks like what i would want. +1 on something like this jeff --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
