Some people ( http://johnkendrickonline.com/2009/1...-waiting-game/ ) use the context field to indicate whether they are "waiting" for someone to get back to them. This is a bit of a bastardization. Waiting is not a context. Waiting is a state of action. The context is the person/thing from whom they are awaiting the response.
I know OF has the "on hold (waiting)" status element, but this element is not suitable. In fact, it is a bit incomprehensible:
1) You can set a context to be "on hold". What does that mean?
2) If you try to put a task on hold, it puts the whole project on hold.
3) On hold and waiting are sometimes different things. I might have a project that is on hold, but I might also have an active project where I am simply waiting for someone to act before I can carry out the next task. One state implies inaction while the other is an active waiting state.
I would love it if OF had more functionality in the "waiting for" department including the ability to diarize a tickler for following up. For instance, I might delegate a task on Monday and set OF to remind me to follow up with that person on Friday if I haven't had an answer. To do this now in OF, I have to set that follow up as a task in-and-of itself. Which it really isn't. Really the task is the task, and my follow up is an discipline to complete the task.
One way to solve this would be to add the ability to associate a task with more than one context so I can assign it to a waiting context and diarize that part. I bet having more than one context would have other uses, for instance if I need to go grocery shopping with my wife is that a grocery store context or a wife context? Both.
Another way to solve this would be to have more robust handling of a waiting state including follow up reminders.
Ideally, both features could be added to the product.
I know OF has the "on hold (waiting)" status element, but this element is not suitable. In fact, it is a bit incomprehensible:
1) You can set a context to be "on hold". What does that mean?
2) If you try to put a task on hold, it puts the whole project on hold.
3) On hold and waiting are sometimes different things. I might have a project that is on hold, but I might also have an active project where I am simply waiting for someone to act before I can carry out the next task. One state implies inaction while the other is an active waiting state.
I would love it if OF had more functionality in the "waiting for" department including the ability to diarize a tickler for following up. For instance, I might delegate a task on Monday and set OF to remind me to follow up with that person on Friday if I haven't had an answer. To do this now in OF, I have to set that follow up as a task in-and-of itself. Which it really isn't. Really the task is the task, and my follow up is an discipline to complete the task.
One way to solve this would be to add the ability to associate a task with more than one context so I can assign it to a waiting context and diarize that part. I bet having more than one context would have other uses, for instance if I need to go grocery shopping with my wife is that a grocery store context or a wife context? Both.
Another way to solve this would be to have more robust handling of a waiting state including follow up reminders.
Ideally, both features could be added to the product.
Threaded Mode