[TW-565] New 'expire' attribute representing the absolute last day a task could be completed

[taskwarrior]

Cory Donnelly on 2010-08-03T17:44:47Z says:

Tasks that can no longer be completed shouldn't persist forever. This could be handled using a new 'expire' datetime attribute. After a task's expire date has passed, task should automatically remove (retire?) the task, probably with a pretty severe nag.

Some examples:

• Put the trash out (wait until Tuesday, due Tuesday night, expires Wednesday morning when trash is picked up)
• Record live broadcast of BBC America from 6pm to 7pm (due at 6pm, expires at 7pm)
• Submit final homework assignment to instructor (due on the 21st, expires on the 31st)

Some thoughts:

• 'expire' would reuse dateformats associated with the due attribute.
• wait <= scheduled <= due <= expire

This feature grew out of forum post "Process to handle tasks that have due dates and times but cannot be done once they're overdue":http://taskwarrior.org/boards/6/topics/show/621.

[taskwarrior]

Migrated metadata:

Created: 2010-08-03T17:44:47Z
Modified: 2014-02-09T02:04:42Z

[taskwarrior]

Paul Beckingham on 2010-08-08T18:47:21Z says:

So what happens to this task:

$ task add Send gift on sysadmin day due:7/31/2010 expire:7/31/2010

...after 7/31/2010? I don't mean where is my home directory - I would expect that to disappear, but what happens to the task? Deleted?

[taskwarrior]

Federico Hernandez on 2010-08-08T19:31:52Z says:

I could live with having it deleted. Others would like to have it "archived" - for statistics or just completeness purposes (but then we don't have archived as a status).

Another thing is that an expire date should be allowed without a due date. Expire together with wait or scheduled would allow for nice tasks like:

task add scheduled:100731 expire:100822 Vacation

[taskwarrior]

Cory Donnelly on 2010-08-09T08:18:45Z says:

Paul Beckingham wrote:

what happens to the task? Deleted?

A status:retired was promised (halfheartedly) for 2.0.0 in this Forum thread: "Task retirement home.":http://taskwarrior.org/boards/6/topics/show/159 I'm entirely content with expired tasks being deleted until/unless status:retired comes about.

[taskwarrior]

David Patrick on 2010-08-09T08:56:42Z says:

While the specter of a resurrected "retired" status is a bit chilling, there's the semantic disconnect of marking an expired task "deleted" or "done", and neither of these things really happened. Perhaps annotations are our friend here, and being automatically marked "deleted" with an annotation "expired on " would do.

[taskwarrior]

John Florian on 2010-08-23T18:06:23Z says:

I too would be fine with the deletion, but really like Davids thought of adding an annotation. Also, I agree with Fredde in that an expiry date is independent of a due date -- they may be used together, but shouldn't be required as such.

[taskwarrior]

David Patrick on 2010-10-14T20:48:01Z says:

is "expired" not status-worthy ? If we are going to give tasks expiry dates (and I hope we are) then those tasks will no longer be pending, but will not be completed. I think they should carry a status:expired attribute but could still be part of the completed.data file. Stats and histories would be meaningless if missed TV shows counted as completed tasks, but on the other hand, how many tasks were not completed because time ran out, would be worth tracking.

[taskwarrior]

Cory Donnelly on 2010-10-14T22:29:32Z says:

I get what where you're coming from David but I'm not a fan of status:expired -- it doesn't add any additional information beyond an expired date attribute. The equivalent is status:waiting, which I think we all agree was misguided.

I would prefer a new status that encapsulates expired and stalled and retired and any other similar tasks that aren't still pending so that we can exclude all of them from status:pending and status:completed reports. Although I don't like the name, a status:notpending type status would have a lot of value.

[taskwarrior]

Cory Donnelly on 2010-10-15T08:17:28Z says:

To be honest, I think we should rethink status:. Ready yourself, I'm about to blow your mind.

As it exists now, status: is unnecessary

The status attribute can be derived entirely from the state of other attributes and doesn't add any additional value by being explicitly set. In fact, it just confuses us by forcing us to ask questions like, "What status should expired tasks receive?" This is backwards.

Consider:

• if a task has a completed (aka end) date, it's completed.
• if a task has no completed date and it has an expired date that has passed, it's expired.
• if a task has no completed date and it has no expired date and it has a wait date that has not passed, it's waiting.
• if a task has no completed date and it has no expired date and it has either a wait date that has passed or no wait date at all, then it's pending.

By breaking away from a rigid status: attribute, we can have more nuanced statuses that better describe reality.

[taskwarrior]

Paul Beckingham on 2010-10-15T08:38:06Z says:

You're right. Status as an attribute is not necessary - it's derived data, like "age" or "overdue". Let's call it secondary data, inferred from primary data.

It is, however, a huge convenience. For example, when running a report, and applying a filter, consider the complexities, given the definition of "pending" that you gave. From the code perspective, losing status means converting a single std::map hash lookup into several lookups, plus logic. In addition, you used the logical "or" operation in your definitions, which we would need to support (planned for 2.0) before we could do this. This means it would be impossible to replace "report.list.filter=status:pending" until we support "or". We have a dependency.

But that just means that the code may keep the old status around as a convenience, but the idea of status can be eliminated from the file format, and from the users perception. I'm in favor.

[taskwarrior]

Federico Hernandez on 2010-10-15T11:29:32Z says:

And don't forget "scheduled" as starting point for tasks. Otherwise I agree with the arguments around "status". Both with Cory and Paul. :-)

[taskwarrior]

David Patrick on 2010-10-16T17:39:44Z says:

Paul Beckingham wrote:

[snip] the idea of status can be eliminated from the file format, and from the users perception. I'm in favor.

Audacious! Derived status will be quite the puzzle, compared to attribute status, but it takes care of the problem! Will we have to completely re-establish the language around the pending/done/deleted thing? or can we call it a "pseudo-attribute"? and most of us carry on obliviously using status:pending the way we do now, without needing to know that "status" is not an attribute directly represented in your .data file, but something described and derived, something easily customized and extended. perfect. status:pending, done, deleted, expired, rejected, retired, in-review, on-fire ? why not ? just an expression-in-an-rc-setting away, right ?

(I just got a chill from thinking about the unit-tests for this)

[taskwarrior]

Max Muller on 2010-11-29T21:00:37Z says:

Federico Hernandez wrote:

And don't forget "scheduled" as starting point for tasks. Otherwise I agree with the arguments around "status". Both with Cory and Paul. :-)

I just want to second the motion for a "scheduled" status or even just an attribute. For time management, it very valuable, with a long list of tasks, to assign them to days/times you intend to do them.

This can be accomplished using the wait command, although not as that command is intended, and its little bit of work to configure a custom report to show everything correctly . . . but waiting tasks don't show up on the calendar, which woiuld be important for scheduled tasks.

[taskwarrior]

Paul Beckingham on 2011-08-24T03:49:58Z says:

Deferring - trying to wind down 2.0.

[taskwarrior]

Paul Beckingham on 2012-05-14T03:43:18Z says:

Here is what we have in 2.0.1:

• Any task can now be expired with the 'until:' attribute, just like recurring tasks. When this happens, a task is deleted, and a message is generated.
• All tasks now accept a 'scheduled:', which is used by the 'ready' report.
• A new 'ready' report is like the 'next' report, but omits tasks that have a scheduled date in the future.

The idea of eliminating status, while very attractive, is being skipped for now. I would like to revisit this when the 'status:waiting' is eliminated.