Ariel Balter <[email protected]> writes: > One would like to be able to do all of the following: > Case 1: > Ticket #A depends on tickets #B, #C, and #D all being done. In the > lingo of the MasterTicketPlugin, tickets #B, #C, and #D block #A > Case 2: > Tickets #B, #C, and #D all depend on #A being done. Or, #A blocks #B, > #C, #D > Case 3: > Ticket #A is essentially comprised of tickets #B, #C, #D. When #B, > #C, #D are closed, then #A is automatically closed. > > Cases 1 and 2 can be done with the MasterTicketPlugin. Case 3, which > Greg brought up in the thread mentioned above, views tickets as > "tasks" rather than bug reports or enhancement requests, the Trac > default paradigm. In this default paradigm, for Case 3, one should > either close #A, or close all of #B, #C, #D, and mark them as > duplicates. From a "bug tracking" scheme that is fine. From a > project management scheme, that defeats the purpose of defining sub > tasks.
In case 3, all of BCD are closed as individual work items. Then a human looks at A and says "yes, after doing B C and D I still think that task A is done" and closes it. I don't see any problem wtih this. The purpose of sub tasks is to express what needs to be done at a finer granularity and to be able to know that some subtasks are really complete - so manually reviewing A doesn't hurt these goals at all.
pgpsH08dKQt4Q.pgp
Description: PGP signature
