Changes between Version 116 and Version 117 of ProjectManagementIdeas

Timestamp:

Aug 3, 2011, 4:42:26 PM (13 years ago)

Author:

Jay

Comment:

Follow up(s)

ProjectManagementIdeas

@@ -560 +560 @@
 ''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''
 
+'' 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''
+
   - 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.
 
@@ -567 +569 @@
 
 ''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''
+
+'' 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''
 
     - for any of this meta data, it would seem logical to support "Calculated fields" for the children, such as in the ValuePropagationPlugin 
@@ -577 +581 @@
 ''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''
 
+'' 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]]
+{{{
+[pm-config]
+calc-end-date=custom
+calc-end-date.provider=CustomCalPlugin
+calc-end-date.params=%s
+}}}
+''or maybe something like this?''
+{{{
+calc-end-date = custom
+calc-end-date.format =dd-MMM-yyyy
+calc-end-date.provider = ValuePropogationPlugin
+calc-end-date.params = method:max,query:parent=self
+}}}
+ 
+''Of course that example set is rather rough, hope it illustrates the thoughts.  -- JW, 03 Aug. 2011''
+
+''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''
+
 == More Feed Back Here ==