On Thu, Apr 9, 2009 at 9:01 AM, Chris Nelson <[email protected]> wrote: > Olemis Lang wrote: >> On Wed, Apr 8, 2009 at 4:06 PM, Chris Nelson <[email protected]> >> wrote: >>... >>> 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.
This could look like progress bars representing tasks in the chart ;) > 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. > Let's write an interface for this and everybody will be able to do it their own way ;) >>> 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. > Oh yes ! This being said, it seems to be a great option ! >>... >> 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? > Work-Breakdown Structure ;o) >> 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 Or what IGanttProvider (the name is a joke, the idea is serious but possibly more than a single interface) will provide the (useful) data about the tickets being rendered, since possibly some of them may be computed at «display-time» and are not stored in tickets . > 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. > ... What t(he)ll, you 'r the first person ( since too long ) that understands me ... that's why I love Trac ;) > >>> 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 +1 > or of deferring their implementation? > ... but include'em later ;) >>> 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. > ok .. when details be out there, we'll c ... I'm in to develope this -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Se retira el BDFL ... ¿El fin de Python 3k? - http://feedproxy.google.com/~r/simelo-es/~3/HpncxTKfB1c/se-retira-el-bdfl-el-fin-de-python-3k_02.html --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
