TKDO

Bug #248681
Comment #4

Comment 4 for bug 248681

Revision history for this message

Selene ToyKeeper (toykeeper) wrote on 2008-07-22:

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.

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.