Arrow_left   Arrow_right
 
  #105

Smarter "waiting-for" context.

    • Created on: Fri, 12 Aug 2005 (over 6 years ago)
    • Reported by: Anonymous
    • Assigned to: bsag
    • Milestone: Someday/Maybe
    • Severity: -
    • Keywords: -
    • Status: Invalid
    • Priority: Normal (3)
    • Component: Functionality (app)
    • Type: -
    • Resolution: -
    • Version: -
    I'm noticing that as time progresses, I have projects with several next actions that all become stale simultaneously, and the reason is because some other task/project has come up that either trumps that project in priority, or somehow makes that other project completely dependant upon the new task/project.

    It would appear that there needs to be a way to set an entire project into a "waiting for" context.

    Also, if you have a task that is in the "waiting-for" context, it would then seem that you should be able to set a primary context for the task, and when placing it into "waiting-for", select the task or project it is waiting for. When that task/project gets moved to complete, the task should automatically leave (or at least prompt the user) the "waiting-for" context and set itself into its new home.

    In this same vein, when an item gets moved either to or from the "waiting-for" context, it's staleness factor should either be refreshed or ignored. "Waiting For" means just that, it is waiting for something. Turning the item all sorts of alarming colors doesn't do anything but induce stress. :) As of right now the only way to get rid of the staleness colors is to get a due date, even if it is is "waiting for" something else. That just doesn't make sense, now does it? ;)
  • Followers
     
    Ico-users bsag (Assigned To) , lrbalt 
     
    Attachments
    No attachments
    Associations
     
    Ticket No. Relation Summary Status Action
    #300 Duplicated Next Action Dependencies Fixed  
    Activity
     
    User picture

          on Aug 15, 2005 @ 03:48AM UTC * By bsag

    I wonder if you could implement this in a more generalized way by introducing the concept of dependencies. For example, let's say you have Actions A, B, and C, with due dates of 9/14, 9/21, and 9/28 respectively (pardon my US-centric date formatting). Assume, conceptually, that Action A must be completed before Action B, and B must be completed before C. If you could specify these dependencies in Tracks, then you could do things like override the color used to display them (for example, mark them with blue to indicate they are waiting for another Action). Perhaps you could also make an entire Project dependent on an Action outside the Project, or even on another Project.

    From a conceptual standpoint, I don't think this would be too difficult to do for single dependencies. Introducing multiple dependencies might be a little rough though...
    User picture

          on Aug 29, 2005 @ 03:34AM UTC * By Anonymous

    Milestone changed from 2.0 to -none-
    Status changed from New to Accepted
    Yes, something like this would be good, with or without dependencies (which I'd like to add at some point in a simple form).
    User picture

          on Apr 13, 2006 @ 08:39AM UTC * By Anonymous

    I think not dependencies should be avoided if possible, as it will start to encroach on the simplicity of the process.
    User picture

          on Apr 30, 2006 @ 05:35PM UTC * By Anonymous

    Dependencies are something I'm looking for as well. Probably the simplest way to implement them would be to add a drop down of the other tasks in the same project.

    The tricky part is the display of dependencies. I'd kind of like to see a tree view that showed the number of tasks depending on a todo with a plus sign to expand them out. That way my list wouldn't be full of tasks I can't do yet because the "Next Action Item" wasn't done yet.
    User picture

          on Jan 07, 2009 @ 11:16PM UTC * By lrbalt

    Milestone set to Someday/Maybe
    User picture

          on May 13, 2009 @ 04:17AM UTC * By bohrax

    Status changed from Accepted to Invalid
    I took the liberty of closing this ticket as I think it is treated in a more generic way in #300. Please let me know if you think this is wrong.
    Time Expenditure
    Loading