obsidian-tasks
obsidian-tasks copied to clipboard
obsidian-tasks-group
feat: add estimated time (i.e. Duration) to complete in Task
⚠️ Please check that this feature request hasn't been suggested before.
- [X] I searched previous Ideas in Discussions didn't find any similar feature requests.
- [X] I searched previous Issues didn't find any similar feature requests.
🔖 Feature description
add estimated time to complete to any Task.
ex)
- [ ] [TODO]: find cheque book #P2 #someday ⏱ 0:15
the scope of the feature is as follows:
- add new task metadata to Task class and associated parsing
- support suggestions when typing a task in vault
- add rendering of metadata to a task line
- add to edit task modal
- add support in query lang to filter based on this new metadata
and of course, some new tests are going to need to be added ...
✔️ Solution
the current code has support for lots of task metadata such as dueDate, startDate, scheduledOn, etc.
the change required to implement additional metadata would sit next to what is already there to support these other ones and thus requires no refactoring, etc.
future refactoring wouldn't be impacted either as it doesn't add any additional burden w.r.t what it already would be to take the current pattern X to the new one Y.
❓ Alternatives
N / A
📝 Additional Context
I have already implemented this in a private fork, see the screencaps below.
The statements I made in Solution are true for at least points 1-4 of the scope I mentioned above, as this is what I already have implemented. As for point 5, I hope the statements still hold true.
https://user-images.githubusercontent.com/38915815/218111988-60855323-0fbd-4989-8bac-9fbb38474045.mov
Hi @BluBloos,
add estimated time to complete to any Task.
Yes, I think this will be really popular. Thank you very much for offering to contribute it!
- [ ] [TODO]: find cheque book #P2 #someday ⏱ 0:15
the scope of the feature is as follows:
- add new task metadata to Task class and associated parsing
I've asked on Discord for opinions about the emoji choice. If you're on Discord, would you mind keeping an eye out for replies please?
- add rendering of metadata to a task line
I imagine you would do this anyway, but I suggest putting this before all the existing fields, to avoid breaking any Tasks-parsing code other plugin authors may have written.
- add to edit task modal
The video was helpful.
Re 03:1 - interesting that it's interpreted as 3:01. That's fine, but I wondered whether it would be 3:10.
I'm unsure how closely this video matches your intention for a PR, but a lot of Tasks users are not developers, so something other than a regexp for showing the allowed pattern would be good.
- add support in query lang to filter based on this new metadata
When you come to add it, you should find that having added the filter, adding sort by and group by options will be very easy. I can imagine that people will find them useful, perhaps to find short tasks to fill available time.
Other items for your consideration:
- Please check out How do I add a new field to the Task class? which lists the current known steps to add storage of new fields to Tasks.
- Please write at least a first draft of the documentation. It doesn't need to be word-perfect, and it can have ad-hoc screenshots, but it should try to describe all the user-visible behaviours.
- I imagine that this might be merged before #1519 - but @esm7 please note a potential incoming new field, for later considering in the styling...
future refactoring wouldn't be impacted either as it doesn't add any additional burden w.r.t what it already would be to take the current pattern X to the new one Y.
I don't think I understand that sentence...
I just remembered: it would be helpful to add it to the show/hide instructions too. It’s also fine to split some of these thing over multiple PRs if you wish.
I've asked on Discord for opinions about the emoji choice. If you're on Discord, would you mind keeping an eye out for replies please?
I am on Discord, I'll keep an eye out!
I imagine you would do this anyway, but I suggest putting this before all the existing fields, to avoid breaking any Tasks-parsing code other plugin authors may have written.
I actually didn't think of this! Although, I am confused about this. What specifically are the other plugins parsing, is it the .md source?
I'm unsure how closely this video matches your intention for a PR, but a lot of Tasks users are not developers, so something other than a regexp for showing the allowed pattern would be good.
haha yes, certainly some cleanup will be needed on this front ... the video was very much "I have it at least working but there is still work to do".
Re 03:1 - interesting that it's interpreted as 3:01. That's fine, but I wondered whether it would be 3:10.
Good point! I think the interpretation of 3:10 is more consistent. Seems like the rule here is that there shall never be anything implicit between a digit and :. So for example, 3:01 should never be interpreted as 30:01.
As for the statement I made on X -> Y it was kind of like so:
for Idx : 0..3
do_A()
do_B()
do_C()
the above pattern is snippet X.
we could do a refactor (albeit a terrible? one) to some pattern Y:
do_A()
do_B()
do_C()
do_A()
do_B()
do_C()
do_A()
do_B()
do_C()
my planned PR is going to make some sort of change to X like so:
for Idx : 0..3
do_A()
do_B()
do_C()
also_do_D()
and so we can see that the refactor to Y should hopefully be minimally impacted.
Re 03:1 - interesting that it's interpreted as 3:01. That's fine, but I wondered whether it would be 3:10.
An alternative is to use a format such as (hours)h(minutes)m.
so ex) 10h30m, 10h, 30m, 10h3m
this way there should be no ambiguity, and in some cases the time spec can be terser
I've asked on Discord for opinions about the emoji choice. If you're on Discord, would you mind keeping an eye out for replies please?
I am on Discord, I'll keep an eye out!
Thank you.
I imagine you would do this anyway, but I suggest putting this before all the existing fields, to avoid breaking any Tasks-parsing code other plugin authors may have written.
I actually didn't think of this! Although, I am confused about this. What specifically are the other plugins parsing, is it the .md source?
Various plugin authors have implemented various bits of interoperability with subsets of features of various other plugins.
It's complicated.
Re 03:1 - interesting that it's interpreted as 3:01. That's fine, but I wondered whether it would be 3:10.
Good point! I think the interpretation of 3:10 is more consistent. Seems like the rule here is that there shall never be anything implicit between a digit and
:. So for example, 3:01 should never be interpreted as 30:01.
I think that's good. As much as possible I would like the mark-down to be unambiguous, and any flexibility being in the auto-suggest and/or Edit modals.
As for the statement I made on X -> Y it was kind of like so:
for Idx : 0..3 do_A() do_B() do_C()the above pattern is snippet X.
we could do a refactor (albeit a terrible? one) to some pattern Y:
do_A() do_B() do_C() do_A() do_B() do_C() do_A() do_B() do_C()my planned PR is going to make some sort of change to X like so:
for Idx : 0..3 do_A() do_B() do_C() also_do_D()and so we can see that the refactor to Y should hopefully be minimally impacted.
I still don't understand, so let me be a bit more specific about the kind of impact I am concerned about.
Now
Currently, the only documented bits of Tasks are the things in the user manual, like the filters and the modals.
Refactoring to me means 'no observable changes for users to the documented behaviours'.
(I am aware of Hyrum's law, but I'm also working on a volunteer basis, and I chose to favour making the current code more maintainable over maintaining backwards compatibility for users who have found ways to access unpublished bits of Tasks code)
This means I am free to rename classes and methods, divide up classes, move implementation details from one bit of code to another...
Post-API
As soon as we start documenting calling of code in Tasks, my other mode kicks in. I will try very hard to avoid breaking changes in documented facilities.
And that is what I mean by an API preventing future refactoring.
Re 03:1 - interesting that it's interpreted as 3:01. That's fine, but I wondered whether it would be 3:10.
An alternative is to use a format such as (hours)h(minutes)m.
so ex) 10h30m, 10h, 30m, 10h3m
this way there should be no ambiguity, and in some cases the time spec can be terser
I guess it would be good to find out if any other task-related Obsidian plugins provide tracking of required time, and try to be consistent...
An alternative to this that would interest me would be a 🍅Pomodoro field. I don't really want to type in how many minutes I think something will take. I want to think about how many Pomodoros it will take, which is easier to type in as a simple 1 digit integer (maybe 2 for incredibly long tasks).
Perhaps the true problem here is that it is not easy for users or even contributors to add additional fields to the Tasks plugin.
Perhaps the true problem here is that it is not easy for users or even contributors to add additional fields to the Tasks plugin.
interesting observation and probably fair.
One of my focuses, since taking over responsibility for Tasks last year, has been to make the searching, sorting and grouping code easier to develop and extend. There has been a lot of progress.
One that work is done, I may well turn to the code for adding fields.
An alternative to this that would interest me would be a 🍅Pomodoro field.
Maybe both could be allowed, e.g. 30m = 30 minutes, 1h = 1 hour, 4p = 4 Pomodoros?
Optionally, could even be displayed as 🍅🍅🍅 = 3 Pomodoros or ⌛⌛=2 hours. This would nicely emphasize the heavyweights in task lists.
I agree that some support for estimated time would be nice to have. According to GTD doctrine, the time to complete a task and the energy needed to complete a task are the crucial factors when choosing next actions, while priority (urgency) does not play a big role and is only considered after context, time and energy have been checked. Often you have only a limited left before a meeting, or you are tired after lunch, in which case you can't tackle time consuming or difficult tasks. So this makes sense. You can also consider time and energy as part of the context in which you do the task.
Currently, I'm just using two tags #quick and #chore. The quick tasks are those under 15 minutes, the chore tasks those that I can even do when a bit sleepy or unmotivated. All tasks that do not have these tags are longer or require more energy. For this, no additional support from the plugin is necessary. Though it would be nice to have them as checkboxes in the edit dialog. For the more fine-grained time and energy fields, sliders would be a suitable kind of UI element.
I love all the discussion and glad to see that estimated time is something that more than just I desire :)
(as a contributor that gives me motivation)
I certainly agree that both time formats should be allowed (i.e. let 1p, 2p, etc be a thing).
I'm currently using a dataview field for this, and using it to calculate estimated time to finish groups of tasks. I'm not on discord, but I rather like the styling of ⏱️ and 🍅, but maybe it makes sense to only use one. Previous to obsidian, I used ⌛ for estimated duration— the scheduled date emoji throws me (but I'm glad for the feature). Maybe worth considering whether actual vs. estimated would be a future thing.
+1 for this feature. I suffer pretty heavily from over scheduling my days and forcing myself to add "estimated times" for my tasks would be great. I think it would then be realistic to eventually parse the data so that I'm not scheduling more than a certain number of hours in any given day.
In addition, it would be nice to be able to indicate the ACTUAL time the tasks took. If there was a way to indicate the start time of the task, then upon checking off the tasks it adds a completionTime property alongside the meta data for estimated time. In an ideal world, I'd love to be able to let Tasks know that I'm starting a task, let them know when I've paused or finished, then have it calculate based on those times the actual time it took to complete the task, but even just being able to manually enter the time that it took would be incredibly helpful and provide a LOT of useful data!
For the styling, either a different type/color of clock could be used or graphics for completion. A couple examples: ⏲️ ⌚ 🏁 ☑️ ⏰
Hi @DrakeShad - for project-planning to be feasible and practical on a project with such a large number of requests, it’s important to keep each issue focused on a single topic.
This issue is about storing estimated time needed to complete a task.
You are describing time tracking which seems to me to clearly be a different topic.
As such, your comments here won’t ever get seen for planning or action.
Feel free to check whether there are existing requests for time tracking and up-vote them. And if not, to instead start a new request.
@claremacrae Thank you for the heads up! Will do. Started off by just wanting to comment a +1 for the feature and got carried away.
Perhaps the true problem here is that it is not easy for users or even contributors to add additional fields to the Tasks plugin.
interesting observation and probably fair.
One of my focuses, since taking over responsibility for Tasks last year, has been to make the searching, sorting and grouping code easier to develop and extend. There has been a lot of progress.
One that work is done, I may well turn to the code for adding fields.
Kudos to @claremacrae for the efforts to enhance the extensibility!
With your expertise, I'm wondering if you could give us a rough estimate of the workload involved in adding this feature. Also, is there anything the community can do to lend a hand in this initiative?
Your dedication and contributions to the project are truly appreciated!
Kudos to @claremacrae for the efforts to enhance the extensibility!
The custom filtering and grouping? Thank you.
With your expertise, I'm wondering if you could give us a rough estimate of the workload involved in adding this feature.
Not really, but I can give an incomplete list of code that will need to be updated... See these lists:
https://publish.obsidian.md/tasks-contributing/Code/How+do+I+add+a+new+field+to+the+Task+class
https://publish.obsidian.md/tasks-contributing/Code/How+do+I+add+a+new+task+filter
Since those lists were written, the following facilities have been added, so the above 2 pages will need to be updated for these changes - and all the code locations that go into implementing the features being documented...
- https://publish.obsidian.md/tasks/Scripting/Task+Properties
- https://publish.obsidian.md/tasks/Scripting/Custom+Filters
- https://publish.obsidian.md/tasks/Scripting/Custom+Grouping
Some of the most time-consuming bits of new features are the automated and manual testing, and coming up with examples for the user docs, and then adding those examples to the automated tests, to ensure that they are never broken.
Also, is there anything the community can do to lend a hand in this initiative?
One idea would be, if a beta version of a feature were available, having someone in the community do the following, if they could turn it round in a day or two, would be a really big help:
- really thorough manual testing - trying to break the code...
- come up with custom filter and custom group examples to be added to the Filters and Grouping docs pages
Normally I would suggest that if an somewhat experienced developer wanted to pair with me for an introduction to the code, and to get started in the new feature, that would be a good way forward.
However, I'm at or beyond my pairing capacity limit right now - nice place to be in, but essentially I'm juggling way too many balls right now...
Your dedication and contributions to the project are truly appreciated!
Thank you.
An alternative to this that would interest me would be a tomatoPomodoro field. I don't really want to type in how many minutes I think something will take. I want to think about how many Pomodoros it will take, which is easier to type in as a simple 1 digit integer (maybe 2 for incredibly long tasks).
Perhaps the true problem here is that it is not easy for users or even contributors to add additional fields to the Tasks plugin.
I'm agree with you, something like this?
Hi, thanks for the ideas ... But... 😄
Please keep discussion in this issue focussed on estimated time to complete a task.
Pomodoro seems like a difference concept to me. As such, discussion of it here will just be invisible and lost.
Feel free to see if there is already a pomodoro request elsewhere for Tasks, and if not, start a Feature Request on that.
An alternative to this that would interest me would be a tomatoPomodoro field. I don't really want to type in how many minutes I think something will take. I want to think about how many Pomodoros it will take, which is easier to type in as a simple 1 digit integer (maybe 2 for incredibly long tasks). Perhaps the true problem here is that it is not easy for users or even contributors to add additional fields to the Tasks plugin.
I'm agree with you, something like this?
Pomodoro is not expected in my very own personal case. Simply because it locks a task to certain time frame. A pomodoro session can be 25 m or 35 m. If I set a task to one pomodoro then it locks to default 25m. But in reality the task might need arbitrary minutes like 10m or 40m. So a proper duration is needed.
I also use pomodoro via superProductivity and what I do is logging how much pomodoro session I have completed in daily logs. In week logs I use a dataviewjs to calculate "pomodoro sessions count x minutes) to quickly grab a view how much time I have invested this week.
If you use Jira or Asana or Clickup for free just to check up how they are doing task management. You will get a more clear picture. The great thing about that is in my case I can stop burning out myself from overwork if I can measure how much task time is distributed to me this week via ploting in dataviewjs. To stop working at all cost when comulative work hours exceeds total task durations.
I just like to point out other potentially useful task metadata: time limit which prevents you from continuing the task after the limit time. By "prevents" I mean the user himself should be responsible for stopping the action. For example "clean kitchen 5 minutes" where 5 minutes is the time limit. In addition to using new task metadata in queries, it will improve the graphical look of tasks and makes it easier to input task metadata either using the suggest menu OR create/edit task pop up window.
We could benefit of having custom task metadata management where the user could choose which metadata appears in the create/edit task pop up window. Other customization would be to change the metadata order in create/edit task window and to define new metadata or to edit names of existing metadata. I'm not sure about abstract task metadata if we are only talking about few use cases, but definitely "estimated completion" and "time limit" are two different things and some users want "actual completion time" #1896. All of these three would be very powerful and useful task metadata. Currently users can use emoji menus to input any custom metadata into tasks but there is menu animation delay in mac at least which makes inputing emojis cumbersome (there are some solutions to this though).
Hi @maggaou,
Thanks for the suggestions, but this issue us about 'feat: add estimated time to complete in Task'...
Any comments on any other topic will get lost and never be acted on.
In case it's unclear why, it's time-consuming enough keeping up with all the on-topic requests, yet alone having to manually keep track of unrelated things...
Sorry @claremacrae, I didn’t realize there were active discussions section. My intention was to generate discussion around general task metadata framework. But there are already two related metadata feature requests with some activity so I think it’s unrealistic to ask to close them and make new issue with more general task metadata framework that covers both sub-usecases.
Sorry @claremacrae, I didn’t realize there were active discussions section. My intention was to generate discussion around general task metadata framework. But there are already two related metadata feature requests with some activity so I think it’s unrealistic to ask to close them and make new issue with more general task metadata framework that covers both sub-usecases.
It's up to you...
If you are thinking of something different from the existing requests, a New Feature request in Issues would be fine.
Hello Hello, I think I have something pretty quick and neat. Not sure if the discussion is still open about it though. Basically two fields should be enough. It's inspired from redmine.
You add fields :
- duration (day, hour)
- percent (0 - 100% done)
With this two fields, you don't necessarly have to manage time management yourself. This is enough for other people to build some UI, Dataviews and so themselves.
The only thing you could add is adapting supposed end of the task once it is placed in time automatically. So deducting end task date from: end date = begin date + duration either way: begin date = end date - duration
In the discussion context, even just "percent" would be enough, but since it mention the "estimated time to complete a task", you can quick calculate it from duration. Even if it's calculated from end date - begin date.
(A bit out of subject but still a bit related, could be using another plugin to synchronize the tasks with external tasks management such as Jira, Redmin, Gitlab, Github, etc..., since basically everything for tasks magenement are already in including time estimation)
Hi @Blondwolf - please read the comment above: https://github.com/obsidian-tasks-group/obsidian-tasks/issues/1649#issuecomment-1735223069
If you would like your suggestion to be considered, please make a new request. Thanks.
This request falls within a set of areas that we have decided not to support in Tasks.
- https://github.com/obsidian-tasks-group/obsidian-tasks/issues/2721
Closing as wontfix.