Changes between Version 116 and Version 117 of ProjectManagementIdeas


Ignore:
Timestamp:
Aug 3, 2011 6:42:26 PM (3 years ago)
Author:
yoheeb@…
Comment:

Follow up(s)

Legend:

Unmodified
Added
Removed
Modified
  • ProjectManagementIdeas

    v116 v117  
    560560''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'' 
    561561 
     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 
    562564  - 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. 
    563565 
     
    567569 
    568570''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'' 
    569573 
    570574    - for any of this meta data, it would seem logical to support "Calculated fields" for the children, such as in the ValuePropagationPlugin  
     
    577581''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'' 
    578582 
     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] 
     586calc-end-date=custom 
     587calc-end-date.provider=CustomCalPlugin 
     588calc-end-date.params=%s 
     589}}} 
     590''or maybe something like this?'' 
     591{{{ 
     592calc-end-date = custom 
     593calc-end-date.format =dd-MMM-yyyy 
     594calc-end-date.provider = ValuePropogationPlugin 
     595calc-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'' 
     601 
    579602== More Feed Back Here == 
    580603