History

Wait¶

Do this thing.. but not right now
wait
is the simple answer to questions we haven't even asked yet.

The idea of discriminating those tasks you are "waiting for" is one of the central GTD pillars, and it makes a lot of sense; no matter how high a priority a task might be, if you are waiting for something, it's NOT a next action. Maybe important, and you may have to track it, but by definition, waiting for something means it's beyond your control, and you should get it OFF the top of your ToDo list, until... whatever it is you're waiting for. so
wait no more !

The most basic reason to add "wait" is to allow users to get those tasks out of their faces most of the time, and to put those tasks all in one place, for review.

implementation¶

new status:wait
new attribute wait:<date>
new command; wait (and the opposite is...unwait ? wait.not ? go ?)
new report report.waiting

command line usage¶

task ls stat:wait          lists only those with stat:wait,
task -W ls                 ls report including waiting tasks
task waiting               lists only those with stat:wait,
                              and should be grouped by who
                              or what is being waited for, somehow.
task <ID>(s) wait          changes ID's status from whatever it was, to "wait" 
                              (using revert method to change it back)
task <ID>(s) wait:<date>   put the task into a "wait" state, till the later date,
                               isn't that great ?
task proj:examp wait +2w   would put a whole project to sleep for two weeks,
                              that's right, change all those records and fergetaboudit !
task <ID> wait -1w         would put a task to sleep, and wake it up one week before it's due date.
                              (the task would have to have a due:<date> for this to work)

interactive usage¶

tasks marked stat:wait are NOT shown by most default listings, but status:wait tasks will be included in any other listing (where valid) by hitting (Z)show.all

(w)ait changes selected(s) to status:wait, or reverts back from status:wait
->[relative.date | date]<enter>(confirm)
(W)aiting (?) (scroll, select, revert status) lists a waiting-for report,, grouped by dependency, sort by tags

(hard to define right now, but when dependencies finally come on line, this is one of the best-use cases. It should be made possible to even add a dependency to a CONTACT ! yes)

comments¶

While there are some logic issues around wait date after due date, and some interesting questions about the relationship(s) of pending, started, due, wait, done, etc, this one is going to be great when these elements come together;
keep it out of sight but review it well and often.
It is illogical (and should be impossible) to change from stat:done, stat:deleted or stat:contact to stat:wait

silly things that we might do, but probably shouldn't¶

oh, and, "wait" makes "hideuntill" want to runaway and hide.

r maybe the wait command should just toggle status wait | whateveritwas

we should not allow tasks to be initially created with stat:wait, so that if the tasks status is changed to wait, there is something to revert to. (pending or someday) This happens automatically when wait.date is reached.

Also available in: HTML TXT

Taskwarrior

Wiki