Eli Carter wrote: > I think there are a couple of issues being conflated here. >
Eli, what you wrote sounds reasonable to me and I mostly agree with it. > 1) I think we need to be careful about what we do as a default workflow; it > should by default be as simple as we can make it. I think it would be better > to have people ask to make the workflow more complex, then have people turned > off by more workflow than they need. "new" -> "accepted" -> "closed" does > not capture the difference between "I've looked at it" and "I'm working on > it", but for those just starting out with Trac, that's probably good enough. > From this perspective, the default workflow should probably be simplified > from what is currently in the branch. (Remember, Trac by default > should "[stay] out of the way.") > So that would be the "simple" workflow. This could effectively be the one selected by default. > 2) The workflow used for t.e.o needs to meet the needs of the Trac > development > process. And it sounds like it would need a more advanced workflow than the > default shipped in Trac. > > Now, the t.e.o workflow would probably need to be a plugin... and it may be > that we want to ship that workflow, or one much like it, as an option in > Trac. (Which would require some way to disable interface implementations by > default.) Once we start down that road, we may want to have a couple of > workflows available out of the box. (With a code-review and/or a QA state > for instance.) > The "opensource" workflow would be the one I proposed, which I think is quite suited not only for t.e.o but in general for a distributed team of developers, where the work units have to be dispatched and coordinated effectively: 'assigned' : the ticket is validated and tentatively dispatched 'accepted' : someone effectively accepts to take care of the issue, otherwise it's still open for adoption 'started' : actual progress have been made on the issue (our current 'assigned' state) Note that this 'started' state could be advantageously replaced by a "progress" property, a la FlySpray (#1084). The "enterprise" would be the one frequently asked for, with the fixed -> verified -> closed sequence, in addition to what's already provided by the "opensource" workflow. It should be straightforward to pick one of these. I've to look at the code in more details to see if those 3 workflows could be implemented by the DefaultTicketActionController, in which case switching between these different workflows would be a matter of describing the adequate workflow graph in the trac.ini (see below), or if 3 separate action controllers would be needed (in which case, we probably need an ExtensionOption on the ITicketActionController interface). >> (As a side note, the above default_actions can't be modeled using the >> [ticket-status] / [ticket-actions] way, because the result of some >> ticket-action depend on the current state, so maybe this is indicative >> of a limitation we should address in the workflow configuration code) >> > ... > > I don't like the .ini configuration, but I haven't come up with a better idea > yet. > > Thoughts? > We could perhaps have one section for describing the whole graph, with entries like: # oldstate--action = newstate So the "simple" workflow could be described that way: [ticket-workflow] new--leave = new new--resolve = closed new--reassign = new new--accept = accepted accepted--leave = accepted accepted--resolve = closed accepted--reassign = new closed--leave = closed closed--reassign = closed closed--reopen = new (as usual in the above, the word "accept" means just what you choose it to mean, neither more nor less :-) ) -- Christian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
