Assign priorities to tasks

[adam-jw-casey]

This could be used to decide which tasks to work on first for better workload calculation (#50)

[adam-jw-casey]

This is important so that tasks marked ASAP are not necessarily scheduled before those with a date.

There are tasks with no fixed due date (not DueDate::Date), that nonetheless should be done sooner rather than later (not DueDate::None). The logical option is to make them DueDate::ASAP, but this displays and schedules them earlier than any other task.

But not all tasks are equally important - there are tasks with a due date some days or weeks in the future that should nonetheless be worked on sooner than some that should be done ASAP.

[adam-jw-casey]

The trouble is, where does this end? Does priority necessarily rank a task to be done earlier, regardless of time constraint? This would lead to the ridiculous situation of a high-priority task with a None due date being ranked before a medium-priority task with an ASAP due date. On the other hand, is wouldn't be possible to, for instance, only override ASAP, because that would break the order within the priority.

[adam-jw-casey]

There's also the question of whether priority should be a property of a task or a category.

[adam-jw-casey]

This is getting into the realm of defining cost functions for each task, which would be interesting with #50.

For instance, you could define the cost/badness of completing any given task by a certain date. The current NONE would be equivalent to a universal cost of 0 - it doesn't matter if or when it ever gets done (although that's not strictly what NONE means). ASAP would be something like an exponential increase with time. Or more perhaps an asymptotic approach to some maximum cost. And Date might be a sigmoid around the due date, or a step function at the due date.

In this case, the priority would be the scaling factor on the cost function.