Iterative tasks proof of concept#729
Conversation
|
|
||
| Second, the next due date and wait are calculated from the RRule. For fixed or fixed+ styles, this is a single RRule library call. For chained, it requires updating the RRULEs DTSTART before calling. | ||
|
|
||
| Yes, this is basically an inversion of the current recurring system, where a hidden “parent” task spawns new pending tasks. The advantage is that since the spawned tasks are completed, it’s not possible to end up with multiple pending tasks that are all copies of each other. In case of a sync issue, there may be multiple copies of completed tasks, but that is far less important. Iterative tasks also require less special handling, as there is no need to hide a parent task most of the time and then still have a way to find it when the user wants to edit or delete it. |
There was a problem hiding this comment.
This is really clever!
I don't see how sync issues would create multiple copies? I can see that if I mark a task as Completed in two replicas before they have sync'd with each other, I'll get two copies -- is that what you mean?
There was a problem hiding this comment.
Thanks! And yes, thats exactly what I mean. I also haven't fully worked out the implications for the original iterative task and how due dates will be affected in that situation, but think that the general sync mechanisms should take care of it.
|
|
||
| First, pre-3.0 based applications are completely left out as all iterative functionality is implemented in TaskChampion. | ||
|
|
||
| Second, all applications that haven’t been updated to recognize the Iterative status may hide or mishandle Iterative tasks. The biggest issue is likely to be marking an Iterative task done and then losing it as an iterative task. If that happens, it will disappear from that client's perspective and the iteration never advances. There are a few possible mitigations, such as a secondary UDA flag that legacy clients wouldn't set, but this might just need to be documented as a possible issue during a transition phase. This is the largest risk in the proposal. |
There was a problem hiding this comment.
We could do a major update to Taskwarrior, with instructions to not create iterative tasks until all replicas are updated to that major version.
djmitche
left a comment
djmitche
left a comment
There was a problem hiding this comment.
I'm excited about this! I read the doc but haven't looked at the source yet, and left a few comments. I'll be glad to see more people looking at this!
The primary change is that Iterative tasks now update their dependencies and dependents upon completion.
|
After a few days of using this for my personal tasks, I found a few rough edges and have fixed them. |
|
The only thing remaining from my original plan is adding a config option to not create the logged tasks. Since replicas don't really have a configuration system, I'd rather not block on that. |
|
from @ForeverFloating in GothenburgBitFactory/taskwarrior#3982 (comment):
|
Currently it only parses TaskWarrior shorthand and text2rrule, but checking for a direct RRULE would be very easy to add. |
|
Hello, an ex-TW user here! I used the app for many years and can say it's the best and most productive task-management app. Tried with Now even integrated Tasklite with Timewarrior, but I'm excited seeing there is work on "recurrence overhaul" ❣️ Is there any raw estimate when it might land in the master? Don't know if you're aware of Tasklite's solution, but it has proper recurring support. Syncing support and mobile-apps are nice-to-have add-ons, but robust recurring is a must. 😉 Sincerely, |
I don't really know, but one thing that would really help is testing. If you could build and test this branch and report anything you find, good or bad, I would appreciate it. https://github.com/carmiac/taskwarrior/tree/iterative-tasks |
|
|
||
| ### Just Moving Recurrence Handling | ||
|
|
||
| It would be possible to move the current recurrence system to TaskChampion, either as is of with the changes suggested in the [abandoned RFC](https://github.com/GothenburgBitFactory/taskwarrior/blob/develop/doc/devel/rfcs/recurrence.md). This would be simpler in several ways, but would still have most of the same backwards compatibility issues and not fix many of the known problems with recurring tasks. |
There was a problem hiding this comment.
I think that is a use case for the Recurring system, which is why I don't want to deprecate it, just provide a simpler system for different needs.
IMO, it's ok to have both systems temporarily so that the new system is thoroughly tested before being imposed on users, but maintaining both long-term isn't a great idea.
The current recurrence system may be more flexible but it also has lots of problems which will never be fixed. That's why the Recurrence Overhaul has been the most demanded feature for at least the last 5 years. [citation needed]
We should strive to maintain taskwarrior's flexibility to support a broad spectrum of users and use cases -- one of taskwarrior's best virtues -- but that doesn't mean adding (or this case maintaining) a substantial amount of complexity to support edge cases. IMO, being a little less flexible and a little more opinionated on this would give most users a better experience.
TLDR, I think the proposal should include replacing the recurrence system eventually and that should inform design decisions now.
5 participants
This is a proof of concept of iterative tasks, or recurrence v2. In the pr is a document describing the general approach and design.
Going this route would allow TaskWarrior a way to address many of the reported issues with recurring tasks, either in the PR or in future work.
It definitely has not been sufficiently tested in the real world yet and there are some missing features, but I wanted to start a conversation before moving forward any more on this.
The basics of creating and iterating iterative tasks is in this PR. Still missing are: