Greg Troxel wrote: > Chris Nelson <[email protected]> writes: >> Greg Troxel wrote: >... >>> I propose to use blocking/blocked-by >>> for the first, and parent/child for the second, with edges pointing >>> from a ticket to each child. >> >> I imagine tickets would have a 'children' field and a 'parent' field. > > Yes, but these would come from edges stored in the mastertickets > table in the db. The children field would be all tickets for which > there is a > me, X, child > row in the table, and parent would be > Y, me, child > with an integrity constraint that there is only one Y.
I admit to not having looked at how mastertickets is implemented. I *thought* it stored blocked/blockedby in additional fields of the ticket. Perhaps it does and you're talking about a new table for parent/child. >> ... the SubTickets proposal which directly addresses your >> need. > > http://trac.edgewall.org/wiki/SubTickets > > This seems like a much bigger change than I am proposing. I am just > trying to express the hierarchy so I can write reports to query > things. I'm not entirely happy with the SubTickets proposal either but it may guide this work, even if only providing an example of something we don't like and don't want to do. ;-) > It would be useful to show only top-level tickets in queries, and to > allow expanding them. In my project I expect to have high-level > tickets on a milestone Yes. > and subtickets on earlier milestones, so I > don't want to simply suppress subtickets. I'm not sure I see how that would work. > But, if the expression of edges was done, then the rest of the > subtickets proposal could be tried out. Evolution is easier than revolution. >> As my immediate focus is scheduling but I want to plan for parent/ >> child, I've thought a lot about how to roll-up data from child >> tickets. ... >> What do the resource allocation and duration of A look like? A has >> 40 hours work. If AA and AB have no dependencies, the overall >> duration of A is the longest duration of a subtask (7.5 days). >> That's controlled by Brian's effort so if Arthur has to do 16 hours >> in 7.5 days, or 26% (I think). > > I would say that A does not get allocated resources, just AA and AB, > and A's planned start time is the earlier of AA and AB, and planned > end the later, and that's that. In your example AA will be done in 4 > days and AB 7.5 so that's A's finish time. I wasn't thinking of actually allocating resources to the parent tasks but in, say, a Gantt where you show the parent task with the child tasks hidden, it'd be nice to have a balloon pop up when you hover over the parent task that showed how much the resources were assigned or consumed by the task. > Scheduling is probably on my list too - just not my immediate problem. > I don't think there is a conflict between WBS and scheduling. I agree. It'd be great if you went after WBS and I went after scheduling and we advanced toward PM on two fronts. Getting an architecture laid out on my PM ideas page should help us cooprate. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
