Eli Carter wrote: > All, > > I re-worked the trac.ini configuration quite a bit, and got things working to > a level that I think they're ready for discussion. There is a lot of cleanup > left, some permission checking stuff that isn't done, little error checking, > etc. > > The workflow-experiment sandbox has 4 example workflows: trivial, simple, > opensource, and enterprise. Each is in a <name>-workflow.ini file in the top > directory, and can be inserted into a trac.ini. >
Ok, those 4 levels should cover most of the needs. > Each transition can have a list of operations: > owner_del - clears the owner > owner_set - sets the owner to the selected user > owner_set_to_self -sets the owner to the logged-in user > resolution_del - clear the resolution > resolution_set - set the resolution > Interesting - "action" tokens that can be associated to a state transition. Probably something similar could be done for permissions (addendum: just realized you did). > The opensource workflow is based on the description that Christian gave on > March 6th, but with some differences. > - assigning to yourself != accepting. You have an accept action, use it. > Well, this was essentially meant to be a shortcut for (new -> accepted), but your statement implies that the accept action is present for the new state, so that would work as well. > - if you accept a ticket you do not own, you also get ownership > Ok > - reassigning a started ticket puts it in assigned state; it needs to be > accepted or started by the new owner Well, the more I think about it, the more I think that for conveying the idea that "I've started to work on the ticket", a progress field (#1084) would be more appropriate. This would have the advantage to show at a glance what issues are currently being worked on, see http://bugs.flyspray.org/ for an example. Plus it's somewhat orthogonal to the workflow. Work on a ticket "accumulate", whatever happens to the ticket (especially if it's reassigned from one developer to the next). A new ticket submitted with a patch could be said "in progress" as well. Also, when I made my initial proposal, I've already pondered about the "needinfo" status, but thought that the workflow was already complex enough. Getting rid of the "started" state would make room for the "needinfo" state, as proposed by Manu and Alec (we could alternatively use the "feedback" status name, as Mantis does). Even better, the progress bar could be grayed out or shown in red if the ticket is stalled because in "needinfo" state... > The enterprise workflow adds a QA step for validating things are correct. > And > it drops the "accepted" state. > Why? I think it's important to get the "ack" from the assignee ("acknowledged" could be an alternative name for the "accepted" state, again in reference to Mantis). > ... > > Second, I don't like the way it looks in the .ini; it's very verbose. > Reasonable defaults would probably help a lot here, but it still feels > awkward. I do like having all of it in one section instead of two, though. > You're talking of the proposed ...-workflow.ini files? Yeah, even the trivial-workflow.ini is scary :-), we should come up with something simpler. > Third, I branched off the workflow branch because this is primarily for > discussion purposes. If people like it, I can clean up the workflow branch > from the beginning. I still have to actually try out the branch, those were early comments... -- 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 -~----------~----~----~----~------~----~------~--~---
