Iterative tasks proof of concept

[carmiac]

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:

• Updating recurring tasks to iterative
• Non-synthetic testing
• TaskWarrior integration
• More fancy recurrence parsing

[djmitche]

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]

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!

[carmiac]

After a few days of using this for my personal tasks, I found a few rough edges and have fixed them.

[carmiac]

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.

[djmitche]

I like this! I've got a few concerns about the design, and I'd like more folks to have a look than just me -- while the current recurrence stuff is not particularly functional for me (I get dupes all the time), lots of folks have filed various kinds of recurrence bugs so I think more perspectives will help.

Since most conversation about TW happens in GitHub these days (for better or worse), I think a good way to address this will be to just comment on all of those recurrence-related bugs pointing folks to this PR.

Once we've got the design nailed down, we'll need to rewrite this Markdown from the proposal document into more authoritative "this is how it works" documentation, similar to the Task Model page. That will be a good time to look in more depth at the implementation, too.

[djmitche]

It seems the strum bits here are just used to serialize this enum to task storage. Why are there multiple options for each type?

[carmiac]

They're here so that they can be used as iter_type shortcuts in TaskWarrior without needing to map them there. e.g. task add iter:daily iter_type:fp ...

[djmitche]

from @ForeverFloating in GothenburgBitFactory/taskwarrior#3982 (comment):

Would the RRULE implementation show users to use the RRULE syntax directly, or does it recognize only shorthand and text2rrule syntax?

[carmiac]

from @ForeverFloating in GothenburgBitFactory/taskwarrior#3982 (comment):

Would the RRULE implementation show users to use the RRULE syntax directly, or does it recognize only shorthand and text2rrule syntax?

Currently it only parses TaskWarrior shorthand and text2rrule, but checking for a direct RRULE would be very easy to add.

[gour]

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 orgmode, but it did not click. Then was experimenting with some Python-powered apps (etm/tklr-dgraham, but they' re not real CLI apps. Due to many recurring tasks in my setup, had to leave TW and, more or less settled on Tasklite.

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,
Gour

[carmiac]

Is there any raw estimate when it might land in the master?

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

[carmiac]

Ok, big update that changes from having the iterative task spawn closed tasks to having the iterative task close itself and spawn a new iterative task using a deterministic v5 UUID. This makes the dep management much simpler and provides a path to eventually implement per-recurrence changes via the "recurrence.confirmation=prompt" config.

[djmitche]

Dropping by to say that I agree: some things should move to TC. For me the line is, if a user stops running a Taskwarrior replica (maybe switches entirely to mobile and web frontends, for example), existing functionality should continue to work. Right now nothing recurs without a Taskwarrior replica, so moving recurrence to TC makes sense. In this context, the "live task metadata" is less of an issue: it just potentially looks different between task and other TC-based interfaces. But it could definitely use some cleanup.

In-replica config is, AIUI, in #741.

Are there other unresolved issues here?

[carmiac]

From my POV there are two or three issues remaining:

1. Update iterative-tasks.md so it matches the current design.
2. Evaluate the base UUIDv5 URL for iterative tasks in light of Add replica-level configuration #741 so it doesn't conflict.
3. More real world testing? I've been using it, but my use cases probably aren't everybody's.

I will try to tackle those in the next couple days.

[ryneeverett]

Once we've got the design nailed down, we'll need to rewrite this Markdown from the proposal document into more authoritative "this is how it works" documentation, similar to the Task Model page. That will be a good time to look in more depth at the implementation, too.

I would suggest that we're already at this stage and it would make sense to revise into documentation at this time. There are still some decisions to make about how this gets integrated into taskwarrior, but I don't think that should be a blocker for this PR and it makes more sense to have those discussions in the taskwarrior repo anyway.

Edit: And 10 minutes later I open another thread on the proposal document. :)

[carmiac]

ok, all updates done. I think I've addressed everything

[Ram-Z]

Related to the discussion here on adding wait and scheduled, there is also until...

"until" has two meanings for recurring/iterative tasks. It may refer to the end of the recurrence, or to the end of each task.

RRULE supports UNTIL= and COUNT= to end the recurrence, if text2rrule supports this, then this part is covered.

until is also standard field on tasks, after which the task gets automatically closed. In the current recurrence implementation, until affects the end of the recurrence, and there is no way of setting until for any of the child tasks.

Maybe until can now be used again for the iterative instances?

A classic example of where this is useful is "Bring garbage bins out". Collection is monday morning (due=mon), but if the task isn't done by 10am, there's no point in keeping it around (until=mon+10h).

[djmitche]

For the semver issue -- this is a major semver change, but that's OK! Bumping to 4.0.0-pre in Cargo.toml should fix it.

[carmiac]

And now the handing of due, wait, scheduled and until is done and matches what normal tasks do, while advancing in a reasonable way. RRule based COUNT is also supported, which lets you do somthing like
task add "fold a paper crane" iter:"daily 1000 times"
I ended up squashing the changes to make the rebase easier.

In addition to the rust tests, I have been testing this in taskwarrior with my chores task list. Seems to work well.