On Tuesday 06 March 2007, Christian Boos wrote:
> To summarize, currently we have (sandbox/pycon/workflow):
...
> and I propose that we use instead:
...

I think there are a couple of issues being conflated here.

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.")

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.)

> (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)

You can work around that by having different names for the actions; 
the 'reassign':'closed' action could be "fix_owner", as an example.
But again, it's something of a work-around.

However, I believe that the expected approach for something like what you 
described is not to use the .ini configuration thing, but instead write a 
plugin to provide that workflow, and disable the existing workflow module.

I don't like the .ini configuration, but I haven't come up with a better idea 
yet.

Thoughts?

Eli

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to