Ariel Balter <[email protected]> writes: > One possibility would be to have "tasks" or "projects" in addition to > "tickets". Another might be if, as you have said, to define the right > kind of edges--connections between tickets.
Tickets are already, by default, of type { defect, enhancement, task }.
> I changed my "Blocks" and "Blocked By" to "Required For" and "Required
> By". One possibility would be to keep tickets as they are, and create
> ''another'' table that would record the project subdivision data. For
> example, suppose #A has sub-tasks #B and #C. Also, suppose #B blocks
> #C. Then we could make two tables:
>
> Blocks:
> | #A | #B | #C
> #A | 0 | 0 | 0
> #B | 0 | 0 | -1
> #C | 0 | 1 | 0
>
> Required By:
> | #A | #B | #C
> #A | 0 | -1 | -1
> #B | 1 | 0 | 0
> #C | 1 | 0 | 0
>
> I was trying to see if I could come up with a really clean way to encode
> the information into one table. But I think the information is actually
> disjoint. So, two tables might be best.
See the existing sql schema. This is not how it looks, and I think it's
easy to extend.
> Perhaps we could make a parallel plugin a-la MasterTicketePlugin that is
> for task hierarchy. But, would we need an additional plugin to handle
> accumulating effort etc. properly?
Sure, or make TimingAndEstimationPlugin do it. plugin granularity is
cool if it saves development time or lets people choose functionality
subsets, but it can be overdone too.
pgpyJymec5Icn.pgp
Description: PGP signature
