Olemis Lang wrote: > On Wed, Apr 8, 2009 at 4:06 PM, Chris Nelson <[email protected]> > wrote: >> >> I'd like to gather the requirements for it. > >> o) > >> Is it best to do it in a thread on this mailing list or start a wiki >> page at Trac-Hacks ? >> > > both ;o)
I'll start the page after in a few days and summarize this thread there. > ... >> By "project", I mean a set of related milestones. > > Milestones *SHOULD* be represented in the diagram as a single point > at due time | date Little diamonds like Microsoft Project? Yes, I agree. >... >> The chart should be able to show all tickets, though that may be a >> very complex chart. > > or alternately all those tickets matched by a (query | report) or any > other ticket group provider ;) Oh, that'd be nice. Have a "Chart these" button on a ticket report page. >... >> To effectively display project progress, tickets must have estimated >> and actual times as in the TimingAndEstimation plugin. > > Is this sched vs execution (plan vs real progress ;) time? My bias is for the way we use it here: actual is how much time you've put in. Estimate is how long it's expected to take. When we accept a ticket, we put in an initial estimate. If we find out that the task is much more or less complex than originally believed, we revise the estimate. Time remaining is always estimate-actual. However, since this seems to be a matter of contention, I think I'd take Yogi Barra's advice (When you get to a fork in the road, take it.) and add a configuration option to specify whether remaining time is in the DB or must be computed. >... >> Ticket dependencies that must be supported include: >> >> 1. Task B must follow task A. >> 2. Task A is composed of tasks B and C. A's estimated time is the >> total of B's and C's. > > What does this means exactly ? How will it be represented in the > chart? That would depend on what level of detail you'd zoomed to. I would expect to see only A until I drilled down by clicking on it or something then A would be replaced by B and C. >... > About providing the data to Gantt plugin and the interaction with > other plugins, specific interfaces (dont know if they'r already there > ;) should be included in order to gather the data about WBS and deps, Remind me what WBS is? > and so on. I mean instead of requiring a plugin, IMHO it is better to > say «if you want to render data in your Gantt chart, implement > interfaces X, Y, Z and config» instead of «Gantt plgin depends on > plgin X, Y, Z». This also means that users will be able to use their > own estimation and deps algos if they want to. Yes, I see your point. Gantt would have configuration options to specify what fields to get things out of so you could layer it on TimingAndEstimation or TracHours or whatever. Those configuration values could default to expecting a certain plugin but not require that plugin. >> Types 3 and 4 are more unusual and a useful Gantt chart can be >> created without immediate support for these links in the first >> release. > > +1 ... You're in favor of type 3 and 4 dependencies or of deferring their implementation? >> It is also desirable to have loop detection to error-proof the tool >> used to create dependencies. >> > > hmmm ... perhaps stated like this : > > «loops and other errors should be highlighted in the graph» Maybe. >> It would be nice to be able to choose an As Late As Possible or As >> Soon As Possible algorithm for laying out tasks. > > IMHO this should be left to other plugins (components), in order to > allow different approaches (perhaps providing a default impl, ok I > agree) Maybe. I'm not sure how this would work. >> The chart (or an accompanying report or tool) should aid in resource >> leveling by (at least) showing overcommitted resources. > > But this is a completely different & potentially complex (yet useful) > development needed. Perhaps it should be deferred ... practical dev > is important ;) I agree it's not integral to charting dependencies. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
