GothenburgBitFactory
Print changed "duration" in "task info" when start/end are changed
When start/end times of a completed task are changed, the CLI output of task info just prints a statement like:
End changed from 'Sat 26 Jun 2021 15:15:54' to 'Fri 25 Jun 2021 05:00:00'.
Given duration was printed when task was "done", that duration is now stale... So the suggestion in this ticket is to print duration too if duration has changed.
End changed from 'Sat 26 Jun 2021 15:15:54' to 'Fri 25 Jun 2021 05:00:00'.
(duration changed from: old duration to new duration)
Same goes with editing the start time of completed task. Currently if I modify start of a task, it just prints:
Start set to 'Fri 25 Jun 2021 03:00:00'.
The suggestion is to print:
Start set to 'Fri 25 Jun 2021 03:00:00'.
(duration changed from: old duration to new duration)
Perhaps task warrior can print duration only once at the end of a start - done epoch. This will require taskwarrior to remove string (duration:
) from the current completed epoch before printing a fresh one in the info line of the current edit to the task. In that case, instead of printing "(duration changed from:...", it would just print "(duration: )" like below. You can think which one makes more sense for task warrior. Thanks :)
Start set to 'Fri 25 Jun 2021 03:00:00'. (duration: <newduration>)
This can make it very easy to read task info and calculate how much total time was doing a task. Let's say if a task had 5 start-done epochs, then the user will see just 5 (duration:
) fields in task info. Which itself can perhaps have a different color group so it stands out from rest of the info.
Removing good-first-issue.
This is actually non-trivial, because the start attribute is removed when the task gets the completed status. History items in task info are currently composed based on modifications between two subsequent states of the task, and this issue would require to tackle the problem in a different way.
What would happen if the start attribute wasn't removed on completion? Bad things? That's valuable data that could be used for time accounting!
@linuxcaffe I agree about value of start attribute, in my case I'm using start/stop exclusively in timewarrior, and leave tasks 'start'ed in taskwarrior until completed. Unfortunately adding end to task in taskwarrior always removes start which is now lost information. It could be used to track when work initially began on the task, even after it was completed.
However, taskwarrior uses presence of start to mean "stopped task" and indeed this is what "task stop" does (removes start). I personally think time start/stop belongs in timewarrior rather than taskwarrior though, OR timewarrior should be integrated into taskwarrior, so there's not two separate things to start/stop. Currently there's not much point to start/stop in taskwarrior IMO, only start/done.
A "started" attribute might solve the problem, and a UDA could be used for this, but wouldn't be maintained by timewarrior itself.
I wouldn't know implementation details, but all this ticket is requesting is an ability for a user to see how much time and what exact time (dates) has been spent on a single task. For instance, let's say if one spends 2 hours every day for 5 days in a week, then user should be able to easily see that when they call task info by seeing 5 corresponding strings.
Historically the stance was that task does not handle activity interval tracking, but I think that's something we should re-evaluate. As @reportaman correctly argues here, the information is entered into the system but extracting it is not trivial (and technically even task info digs it out from the backlog.data history of modifications)
I think this is something we should re-evaluate. I'm bumping this from Backlog to our next major release.
Are we talking about storing multiple sets of start/end with a task? For all the start/stops that are ever done on a task? Time interval tracking doesn't really make sense in taskwarrior as it stands (that's what timewarrior is for). It sort of makes sense to keep a single start and end to delimit all the time a task was worked on until completion, but not to store multiple intervals, this would largely duplicate timewarrior's purpose.
Timewarrior could be integrated into taskwarrior though, rather than having separate tools and requiring elaborate hooking mechanisms to have them be synchronized... that might be a good idea (I'm sure people that only use timewarrior would disagree) but as long as they are separate tools it would just be duplicated functionality
@smemsh Having multiple start/stop durations/windows makes sense I guess. What you are saying is there should be a way to see the duration between first time ever a user started working on a task to the time when it was marked complete? Someone else might say they want to see the time between the task was created to the last time it was marked as complete. And further one might say they want to see the duration between task creation and the first time they ever started working on it (as a measure of how much time they are taking between task creation and actually getting to work on it).
IMO out of all such combination of events, the most useful (and currently maybe missing feature) is to be able to see how much & what time durations one has spent on a task. The rest are be easily visible from task info, even though not present as "duration" (one can calculate that). No opinion on where the code should be, that's to the wisdom of developers.
If having multiple start/stops breaks anything, then perhaps adding another internal state like "suspend/resume" could be the answer, not sure though if that makes the interface overly verbose.
... the most useful (and currently maybe missing feature) is to be able to see how much & what time durations one has spent on a task
yeah, what I'm saying is, this is implemented already, in timewarrior
I'm using start/stop but for me it's more of a "focus" button.
"This is the +ACTIVE task. Everything else is not +ACTIVE and thus it's irrelevant."
My TaskWarrior is configured to only show the current active task and hide everything else.
Because of the weak implementation, duration tracking is pretty much broken from my perspective (see https://github.com/GothenburgBitFactory/taskwarrior/issues/2210). I wouldn't mind if duration tracking would be completely dropped and/or moved to a taskwarrior plugin.
I have used Timewarrior excessively and tbh I feel like timew is better without the TaskWarrior integration. You'll end up doing task 1 done && task 2 start all the time because everything else creates gaps in the time sheet.
Personally I am happy with "just using my calendar for time tracking" idk if that makes sense. I schedule things for, say, two pomodoro (1 hour) and when they end up taking longer I will adjust my calendar to reflect the reality. It's more nuanced than this but you get the gist I think.
TL;DR Everybody uses taskwarrior differently. Some people don't use duration at all. Please keep this in mind when writing duration-logic which might take a lot of computer resources.
Timewarrior's basic units are time intervals, whereas Taskwarrior's are tasks. Timewarrior adds (1) interval tracking, (2) storage of arbitrary tags, (3) tooling to select active task (tags), (4) tooling to manipulate stored time intervals. Taskwarrior would need to have all these moved into it in order to obviate the need for Timewarrior. Most users of interval tracking would need the rest of the tooling also to accompany the interval records themselves.
Either separate or combined tools (for tasks and time) would work well for these purposes, I just think interval tracking belongs only in one or the other (or the combined tool), not both (it's already enough of a pain to synchronize them... for example when changing tags).