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]

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