On Friday 27 June 2008 03:16:02 pm Michael Stratmann wrote: > On 27 Jun., 16:18, Eli <[EMAIL PROTECTED]> wrote: > > Too simple? Everything you list below is doable with the provided > > configurable workflow and a trivial plugin to add a few permissions. > > Sorry for not being clear enough. By 'too simple' I meant the default > workflow itself, not the configurability (great and necessary feature, > is there a plugin to comfortably set up the workflow?).
There aren't tools to help you graphically create the workflow, or anything like that... you'll be modifying the .ini file. But in the contrib directory you will find some tools for graphing a workflow from the .ini. > 1. I do not know a single commercial environment, where Trac's default > workflow would be acceptable (having ISO9000, CMMI or SPICE in mind). > Of course the default workflow depends on whom you expect to be your > audience. Right. Everyone has different requirements for their workflow. The default is very simplistic--as it should be. If you have real requirements, you're going to need to customize any tool you choose to use. There are a couple of other workflow configs in the contrib/workflow directory that you may find to be a better starting point. Feel free to propose something that would be a better fit for ISO9000 or whatever for inclusion in that directory. > 2. From looking at some tickets on t.e.o and comments about triage I > got the impression, that a more structured workflow might be > beneficial even to the Trac project itself. Looks like the project is > drowning in open tickets and nobody really knows what to do with them. > > Change management processes are so much more than just requesting and > then coding some piece of SW. If I were a higher manager or from > quality management I would ask "Is Trac suitable for our process > improvement activities?" Then I'd discover only a tiny workflow on > t.e.o which is not even lived properly. I would remove Trac from my > candidate list. Trac is highly customizable -- you can have as much or as little workflow as you want. What you see on t.e.o is not the most bureaucratic workflow that Trac will support. 0.11 added the customizeable workflow, and we have not taken advantage of that on t.e.o. yet. (Hey, the release is less than a week old!) We have talked about changes to the workflow to better suit us, but have not returned to that discussion in the midst of other issues. > I was forced to read quite many details on Trac to decide to use Trac. > The general approach obviously has a strong focus on quality. Due to > the central position of Trac for managing my customer's project, I > (and Trac) carry some responsibility. Being forced to change the tool > mid of project would be a disaster. I had to rule out some tools, > because they depended on a single developer or were almost dead. I > need to be sure Trac will live on and grow properly. The present > change management on t.e.o, as it appears to me at a first glance, > worries me. I looked through that Redmine thread, too. Then take a longer look at what Trac is capable of. I hope you will find it more powerful than your initial impression. Eli ------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram [EMAIL PROTECTED] `------------------------------------------------- --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
