I owe a couple replies: *scope creep* pottster, I completely understand scope creep and what it can do to software. However, I have submitted literally hundreds of software ideas to open source and commercial software initiatives. It is a purposeful focus for me to be exceptionally aware of the general current scope of the software and understand the impact of adding functionality. This is how I know to delineate between adding functionality that has UI and/or UX impacts and those that do not. New UI controls mean new explanations, new helpfile links, etc, so they impact development and more importantly they impact whether a new prospective user (revenue potential) feels overwhelmed by the amount of software nomenclature they must learn. (I feel "Don't Make Me Think" by Steve Krug applies to ALL software - not just the web). When functionality can be added with a simple question or even a default behavior, the impact is dramatically reduced.
I expressed the minimum requirement that I believe gives 80% of the value of what I am getting at - something that seems to be an underlying development theme in MLO already. The scope creep that you outlined does not have to be a natural progression simply by facilitating this request. The potential for scope creep is always there and using the rationale that it is a slippery slope should not be used to downplay an idea - this downplay could be used on every feature request on this forum. *Incremental* I also want to point out to all that this suggestion is specifically incremental. It does not require a comprehensive design of the whole idea of "task dependencies" to add significant value. In fact, I wonder why it could not be the default behavior when coping tasks trees. I can't think of a time when I would need a complete duplicate of a task tree with the same dates in real life. Can anyone enlighten us on whether there is a use case for leaving all dates the same or if it is simply the natural result of doing a copy of tasks in the absence of any other requirements? *additional value* As background I use these dates to populate other systems - rush shipping on registration systems, cut off dates, etc. So having the system determine them automatically has a big productivity boost in that it supports: *) fewer date determination mistakes, *) rapid setup of dependent systems. *nschm873*, thanks for updating me on the official term. *My Workaround* I held back on expressing my work around because I feel there is significant value to the feature. Not only is my work around a lot of manual work (hence the name "work around") but sometimes the long standing devotees of a product (which I seem on my way to becoming) almost consider work arounds to be features - even if they are buried in forum content. My work around is simply to add a T-minus tag to the name of each subtask. "Print Courseware [T-5]" If I copy or move an event date, I redo the dates using these tags. This way I can use start times for their intended purpose and calendar sync is preserved. Currently on my most complex "backward planned" event I only have about 10 identified subtasks to change - but if this grows to include more detail on these or other projects, the work around will be very unmanageable. Thanks, D. -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To post to this group, send email to mylifeorgani...@googlegroups.com. To unsubscribe from this group, send email to mylifeorganized+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en.
