Legend:

''First, thanks for the feedback. I'm not sure what section you mean when you say "concepts" and the [#Design design] section is intended to describe extension points that provide a common interface to other PM-related components. -- CLN, 2011-08-02''

561

561

562

'' I'm not sure where I was going with that, as I skimmed, I got the impressions some specific implementations were being incorporated. The ability to change these via extensibility is all I was commenting about. -- JW, 03 Aug. 2011''

563

562

564

- For example, one may not want a "work" field, since man hours effort, in their project may have little value. Instead, they may wish to use "days" for calendar time, or "dollars" for contractor costs.

''I envision the priority rule for scheduling being the most commonly replaced component. If risk doesn't mean anything to you, ignore it (or if risk is 0 throughout your project, it won't affect the priorities). -- CLN, 2011-08-02''

571

572

'' The ability to replace it is always preferred if possible. "ignored" fields as just clutter. Look at some of the default trac fields that people happen to not use. there are plugins designed to hide them, just to make life easier. That said, your comment is valid. If taken into context with the later concept of somehow making a "provider" for where this value comes from, it could be used rather than ignored --JW, 03 Aug. 2011''

569

573

570

574

- for any of this meta data, it would seem logical to support "Calculated fields" for the children, such as in the ValuePropagationPlugin

''Can you say more about how that would work? Frankly, my knowledge of Trac internals grows slowly and as needed for my little bit of plugin programming. -- CLN, 2011-08-02''

578

582

583

'' When I was typing that, I had in my mind the concept of how the TypedTicketWorkflowPlugin works. An .ini setting with additional data in the .ini value(s) that modify who/how that particular thing works. Not sure if that concept is something that can be applied here. Maybe something like the following:[[BR]]

584

{{{

585

[pm-config]

586

calc-end-date=custom

587

calc-end-date.provider=CustomCalPlugin

588

calc-end-date.params=%s

589

}}}

590

''or maybe something like this?''

591

{{{

592

calc-end-date = custom

593

calc-end-date.format =dd-MMM-yyyy

594

calc-end-date.provider = ValuePropogationPlugin

595

calc-end-date.params = method:max,query:parent=self

596

}}}

597

598

''Of course that example set is rather rough, hope it illustrates the thoughts. -- JW, 03 Aug. 2011''

599

600

''I specifically was of the line of thought that I would like to pull some of these values directly from my requirements specifications somehow, hence the lean toward some sort of configurable "provider" for the entries, as I have no idea how I would "pull" the data from the requirements at this point, other data from calculation and projections using different projection methods, as well as "override" capability where data is entered by hand sometimes. -- JW, 03 Aug. 2011''