feature request: "estimated time" and "time worked on"

[bert]

As a feature request that might be for future version, it could be interesting to implement some new tags, one storing the estimated time to work on a task, and another one to have the time that has already spend on.

This should help to see what task can be done quickly when you just want to work for some minutes, or the total amount of time a task need for all its subtasks to be done for example.

What's your opinion?

[Selene ToyKeeper (toykeeper)]

It would be relatively easy to add a tag for estimated time required. PyGTD had this feature, and I found myself spending time to fill in the data and then never, ever using it. However, with some other features (sort/filter tasks by length, maybe?), it might be a little more useful.

Tracking time spent is much harder. I see a couple options:

  - You could manually calculate it and attach it somehow.
  - Functions could be added to start/stop a task, list "running" tasks, record total time, and so on.

In either case, you might be better off just using gnotime.

For invoicing, I've found it easier to just "punch in", keep a short log of what I'm doing, then "punch out".

So, to summarize, I guess that's a definite "maybe"...

[Selene ToyKeeper (toykeeper)]

Could you describe a little about how you would use the features you described, and what you want to do with them? This will help define what actually needs to be done, or perhaps suggest alternate ways to accomplish the same goals.

One thought which comes to mind... to keep track of short tasks you could do quickly, you could just apply a context called @quick or @short or @bite-sized. Or, I've also seen people track temporal data via percent tags (%lastminute, for example). I may add support for '%' in much the same way it handles '@' now, just to give people the option of having two separate tag namespaces. I doubt I'd use it, but it's easy to add and would help a few people.

[bert (bertagaz)]

My thought was to have tkdo able to handle estimated time to spend on each tasks.

With estimated time, there is a way to calculate remaining time, with that estimated time minor a "time worked on" tag or whatever, or maybe just by using the percentage with the estimated time.

Having a way to handle multiple tags for a task might be a solution though, but I like to have percentage too, so using the % symbol isn't in my opinion a good trick. Maybe having tkdo able to manage multiple @ tags for a task could be the way to have what I was thinking with estimated time and a good enhancement for everyone too.

If this option we are discussing here isn't of any interest but for me, I'm ready to use tkdo as it is though :]

And I'm thinking maybe this discussion would have been at a better place doing it simply by mail, so sorry of I'm using a wrong channel by posting it here.

Hope to be explicit enough too :]

[Selene ToyKeeper (toykeeper)]

Okay, so two approaches. Both require a tag for estimated time.

  - One way to calculate time spent is (estimated time * completion percent). The user bumps up the percent to indicate time spent. This does a good job of estimating how close a task is to being complete, but a poor job of tracking the actual time involved.

  - Another way is to explicitly track time spent, either by entering time after working, or by using start/stop buttons. This is good for tracking how long a task takes (assuming the user doesn't forget to start/stop tasks), but the time spent isn't likely to match the estimated time when the task is done.

Neither seems ideal, and I haven't really figured out how it would work when applied to projects (task trees) instead of individual tasks. Should the top-level node hold the metadata? Should it go in individual leaf nodes? Maybe somewhere in the branches in-between? If the top node calculates its data based on child tasks, how can the user access the top-level data? (TKDO only displays leaves, so the top would be implicit)

The start/stop buttons provide an extra benefit that they can be logged. Then users can see what they worked on recently, not just what they completed. (of course, this should happen anyway if tasks are sufficiently split into pieces, but that doesn't always happen)

> Having a way to handle multiple tags for a task might be a solution

It already handles multiple tags per task. The UI is a bit lacking, though. To add a tag, hit 'e' to edit the title, then just append @foo @bar @baz to the end. And deleting tags requires an external editor. But it otherwise works fine with multiple tags per task.

> using the % symbol isn't in my opinion a good trick.

It wouldn't conflict with completion percentages. I'm not yet sure if a second tag namespace is worthwhile, but it wouldn't cause problems.

> And I'm thinking maybe this discussion would have been at a better place
> doing it simply by mail, so sorry of I'm using a wrong channel by posting it here.

This is fine, or email is fine. Whichever. The blueprints feature on launchpad is where feature requests should go, in theory, but I don't think it has any facilities for discussion there. So, that leaves bug reports, launchpad questions, and email as workable options. Bugs allow others to chime in if desired, though, and provide a public record later that something has been discussed.

I don't have a clear vision of what time-tracking features should do in TKDO, or how they should work. So, what I'm interested in is hearing about what the user interface would be like, and how it fits into your workflow. And, if this was completely implemented, what benefits does it provide?

Also, if you haven't yet, be sure to try gnotime. It's designed for this sort of thing. Even if it's not suitable, maybe it will help answer some questions.

[Selene ToyKeeper (toykeeper)]

I'm marking this as incomplete until the idea is defined better.