This is an interesting problem. There are several potentially useful views of the data.
I set up the stylesheet 'Z_TimeSpentReport.xsl' to present the estimated and actual time spent next to one another. The calculated times sum up for the parents. This has 2 weaknesses:
1. You can't easily compare. For instance, if you want to compare month to month, you need to filter for the month, generate the report, print or store the data, then do the next filter etc... Would be great to have a report that presents time data for several time periods.
2. Accruing / grouping times on something other than parent. For instance, grouping by a tag or category. A common thing would be to say (e.g.) I will spend x% of my time on routine work, y% on improvement work etc... I would like to then compare intended with actual over time.
Of note, ideally you would be able to assign a target percent to the category, rather than messing with all the individual tasks contributing to the category.
I still intend to write a stylesheet to report times grouped by category.
The above would depend on the filter applied prior to the report. For review purposes, you would mainly be using completed tasks.
I am not sure 'due date' vs 'completion date' will be generally useful. Depends on how TDL is used. If due date is used as a deadline, then reporting on say % tasks completed before/after/on deadline (and related measures) is useful. However, it is less useful where the due is used like an 'action date', and is constantly moved.
One thing TDL currently can't measure that might be of interest is either how many times a start / due date has been deferred, or the magnitude of the overall deferral. This is related to the concept of the 'baseline' in projects and gantt charts.
Depends on how you want to do it. As a minimum, you could store a 'baseline' due or start value. This could then allow the calculation of the total amount of time deferred. If you want to know the number of times deferred, you could do this using an integer counter I guess. If you want to know the actual deferral dates as well, you need to store the actual dates...
What this doesn't tell you of course is the number of times you actually worked on a task / project. A way to do this would be to log the start and end times of a task, when using the timer. Therefore a task could/would have multiple start and end times, potentially over days or weeks. But that would be a lot of data. As I understand it, TDL currently adds the duration to a total duration.
The above suggestion would allow for a 'journal' style report, potentially linked in with a calendar.
This could lead to assigning times to tasks ahead of time (eg when planning your day). This could mean you don't need to use the timer function to generate the data. Ideally this would be achieved by dragging on a day calendar...
But all of this is a significant change to how TDL works, and I am not sure what the interest would be for this type of reporting.
Ha! That makes more sense.
As I understand it, the burndown would only be a reflection of either the completed tasks vs uncompleted ones, or the % effort completed / not completed. This is useful I guess as a monitor of progress against a tasklist/project.