You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
taskwarrior has so many date attributes, and sched:date is not currently handled by the app.
Why so many dates? Lemme explain;
due:date is when the task should be completed, often driven by an external motivator, like somebody expecting something. After this date the task is overdue.
sched:date is when the user intends to do a task. This can/ should be before the due:date, so (for example) do it on sched:date and deliver it before due:date. If we want to include sched:date, we'll have to squeeze it into task_edit view.
start:date is intended to act as a marker that the task is IN PROGRESS. taskwarrior can also track start and stop times to show how much time has been spent on a task, but taskwarrior CLI does that solely through the task history function, and the start:date value is cleared on ``task 42 stop", so if we want to track accumulated start/stop times, we'll have to find another method (like creating a start/stop time annotation) Until then a started task should be highlighted, maybe sent to the top of the list, as the task currently in progress. Currently, taskwarrior-flutter assigns a start:date when a task is created, the same as entry:date, and (imho) this a mistake, and when a task is created, the attribute should default to null, unless set by user.
wait:date is a stalling tactic, if you can't do a task right now, you can hide a task from view until wait:date
until:date is when a task will be automatically deleted, as it can not be completed after that date. Think of a task to put out the garbage or buy concert tickets, no point having those tasks listed after that.
end:date is created automatically when a task is completed or deleted. We don't need a UI element to control it, as it's not intended to be user-modifiable.
Would you like to work on this issue?
None
By submitting this issue, I have confirmed that:
I have starred the repo ⭐ and watched 👀 it on GitHub and followed the contribution guidelines.
The text was updated successfully, but these errors were encountered:
Describe your issue
taskwarrior has so many date attributes, and sched:date is not currently handled by the app.
Why so many dates? Lemme explain;
due:date is when the task should be completed, often driven by an external motivator, like somebody expecting something. After this date the task is overdue.
sched:date is when the user intends to do a task. This can/ should be before the due:date, so (for example) do it on sched:date and deliver it before due:date. If we want to include sched:date, we'll have to squeeze it into task_edit view.
start:date is intended to act as a marker that the task is IN PROGRESS. taskwarrior can also track start and stop times to show how much time has been spent on a task, but taskwarrior CLI does that solely through the task history function, and the start:date value is cleared on ``task 42 stop", so if we want to track accumulated start/stop times, we'll have to find another method (like creating a start/stop time annotation) Until then a started task should be highlighted, maybe sent to the top of the list, as the task currently in progress. Currently, taskwarrior-flutter assigns a start:date when a task is created, the same as entry:date, and (imho) this a mistake, and when a task is created, the attribute should default to null, unless set by user.
wait:date is a stalling tactic, if you can't do a task right now, you can hide a task from view until wait:date
until:date is when a task will be automatically deleted, as it can not be completed after that date. Think of a task to put out the garbage or buy concert tickets, no point having those tasks listed after that.
end:date is created automatically when a task is completed or deleted. We don't need a UI element to control it, as it's not intended to be user-modifiable.
Would you like to work on this issue?
None
By submitting this issue, I have confirmed that:
The text was updated successfully, but these errors were encountered: