On Jan 5, 12:08 am, Ryan J Ollos <[email protected]> wrote:
> Paul Boos wrote:
>
> > Thanks Jay,
>
> > Is TypedTicketWorkflow a plugin or is it a standard Trac feature?
> > Just
> > wanted to know where to go look to dive a little deeper... Just by
> > the name, I can tell TypedTicketWorkflow is a decent fit, but what
> > does
> > MasterTickets do? Can you point me to something that describes it?
>
> http://trac-hacks.org/wiki/MasterTicketsPlugin
>
> --
> View this message in
> context:http://old.nabble.com/Workflow---Project-question-tp26728935p27024143...
> Sent from the Trac Users mailing list archive at Nabble.com.
Sorry I never got back on this thread till now. google was blocked at
work for some time.
As for the master tickets part. Here is what we do for a more
complicated that it should be workflow :D
Using Typed ticket workflow, we have a special ticket type call
"Feature Ticket" which has additional workflow steps: Ready For Code
Review, Code Review Accepted, Code Review Failed, Merged to trunk,
Closed.
We "block a feature" using master tickets, with all the fixes,
enhancements and "tasks" we have planned for that feature. The Future
ticket then can't move to "Closed" until all the "sub tickets" are
verified (our closed state)
A more "V model" style waterfall could use MasterTickets to be
"blocked" by the appropriate level test/validation/verification task
ticket you create when you create the step.
So in my best ascii art (ok, not my best)
Functional Requirement ------------------------------------------------
>Acceptance Test "ticket"
|
System Requirement ----------------------------------------
>Integration test ticket
|
Subysystem Design Req --------------------------------
>Validation test
|
Subsytsem Design Item ------------------->Author/Unit
test
\ /
---Verify---
That last step there "Verify" is my own thing and it blocked by both
System Design Item, and the Author test. but basically the stuff on
the right blocks the stuff on the same line to the left, and the stuff
down the left side blocks 1 ore more items above it. (1 to many
almost always in my experience)
you could get invloved and make each of those tickets a type, and
possibly have their own workflow, but "probably" only need special
work flows for a few. Since we make devices, the validation test has
a special workflow, since there is manual test script that is run,
with reports and sign offs and all that crap. for example, but Many of
the other just have standard worflow.
The other option is to make the stuff on the right a step, or set of
steps in a typed workflow for each test, reducing the number of actual
tickets (by half) and the number of types. while still using master
tickets for "blocking" on the left side (this is what we do now, just
reassinging the ticket as appropriate for the "test" step)
in this model instead of 8 ticket types in the above V, you only have
4, but each type has a unique workflow step (follow the arrow for the
next step before ->closed)
You still have other ticket types as needed (defect, task,
enhancement, etc.)
Not sure this helps you much, but it is what I was referring to master
tickets for.
--
You received this message because you are subscribed to the Google Groups "Trac
Users" 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-users?hl=en.
