Choice of direction

[djmitche]

First, I think it's about time to get the 0.4.0 release out -- I believe we just need to finish the new replica storage backend?

Once that's out, we're already on our way to the next few releases. But I want to think a little ahead. Aside from "a thing that can track my tasks", what is the first bit of new-and-cool functionality we want? I see three options:

1. Highly polished CLI
2. Sophisticated, reliable sync functionality
3. A collection of integrations

The first option would, I think, largely be chasing TW, and IMHO we need to further differentiate TC from TW. Also, TC's CLI is really nice, so that's a lot of work.

The second option is, I think, the technical differentiator from TW. Being confident that I can tap in a task on my phone and have that appear everywhere I look at my task list, without anyone else seeing my task list. That's core functionality for TC, whereas it's a bit of an add-on for TW.

The third option is, I hope, the organizational differentiator. TC should have an "ecosystem" of tools that integrate it with various things -- maybe a starred email shows up in my task list, or I can ask my home-automation thing to add a task. There should definitely be a mobile app! I'd personally like to sync my tasks with my github issues and pull requests.

[dbr]

Yep I think the SQLite backend was the last ticket for the 0.4.0 release. I'll update that PR shortly with my progress!

Highly polished CLI [...] largely be chasing TW, and IMHO we need to further differentiate TC from TW

I agree - trying to match the polish and comprehensiveness TaskWarrior's CLI is a bit.. ambitious! It's been developed over a very long time

However by the same token, since we are starting afresh, we can make TC's CLI smaller (easier to learn), simpler, and smoother to use - which would be a valuable differentiator to someone not already invested in TW

Being confident that I can tap in a task on my phone and have that appear everywhere I look at my task list, without anyone else seeing my task list

Agreed.

TC should have an "ecosystem" of tools that integrate it with various things

I completely agree having the replica API be a core part of the project is a great thing.

For an an example, we had an internal application I was using for some UI framework related experiments, and for fun I tried to integrate taskchampion into it - took maybe 30 minutes to create a replica and make a basic editable display of tasks. To do the same with most other approaches would be a lot more work (even the most basic "todo.txt" approach would involve some kind of design to choose where the file gets saved/created/etc, tracking file-modifications and live-reloading to try and avoid conflicts, and so on)

So it should be quite appealing to write integrations like you describe (syncing GH issues to TC and so on)

I guess an extension of this is it being written in Rust - aside from being trendy and cool (which I mean in an unreservedly good way), I think it'd be fair to say Rust is quite a lot friendlier to new contributors than C++, moreover with a project with quite good test coverage, documentation, enforced linting and formatting. Having the same API easily accessible to write other interfaces should, I hope, help make TC a valuable thing

[djmitche]

I suppose an update here is in order.

At the moment, I'm seeing TC as a proving ground for things I'd like to see implemented in TW, before I implement them there.

I'm working on defining the TW data model and sync protocol as an API, such that there can be multiple cooperating implementations. With that done, it's likely that taskchampion-sync-server will become the main implementation of a sync server for TW. And it may be that taskchampion becomes an easily-embedded library for interacting with task data, as @dbr described above. Whether taskchampion-cli sticks around remains to be seen.

The upshot of all of this is:

• I want to prioritize work on data-model- and sync-related functionality, so that it can become the basis of a TW RFC. I plan to move this work into the 0.5.0 milestone.
• Work on improving the Rust API is also welcome. In particular, figuring out ways to embed it in other languages would be great.
• Work on the CLI is probably not a good use of time right now (which is not to say PRs won't be merged!)