Categories
Linux Unix

Warring with My Tasks

The local LUG had a talk recently about Task Warrior, which inspired me to give the tool a poke.

I have had excessively fragmentary handlings of outstanding ToDo items, where I have assortedly used:

  • Index cards to note things, but this is really ephemeral; I tend to turf them quickly, and only the most immediate things would get captured here, and evaporate as quickly. These can get clever; I didn’t get enough into that, I’m not hipster enough for that!
  • For a while (and this has gotten to be pretty distant in the past) I used todo.txt to capture things to do. Unfortunately, there’s not much of a synchronization mechanism, so I at one point ran the iOS app on my (still around somewhere) iPod Touch, later on Android phones, with occasional copying onto Unix desktop. But because coordinating versions amounted to doing by-hand git patching, this was way less useful than wanted.
  • For quite some time, I used Org Mode files for my grocery list, syncing between desktop and mobile devices using SyncThing. This was decently viable, actually, allowing me to manage the document on desktop (with a lovely big keyboard and big screen for mass editing) and on mobile device (so the list is handy to mark off purchases). Once in a while, I would push completed items into a side file for posterity. I also copy this data to a Git repository (for arguably “more posterity”); it is not as automated as it ought to be, trying to automate Git checkins was more troublesome than it ought to be.

But in November, at the above mentioned talk, I installed Task Warrior on my phone and decided to give it a try. FYI, I run it in a Termux session on my phone. There do exist a couple of TaskWarrior apps, but I have not yet been able to get them to sync to my taskd server. I am happy enough with the Termux-based CLI access. Perhaps I should set up a web server as an alternative interface? We’ll see…

Overall Configuration

I have the app (apt-get install taskwarrior) installed on a variety of hosts:

  • Work desktop, which syncs against central taskd
  • Chromebook laptop, syncs against central taskd
  • Home server Karush, which hosts taskd and has client syncing against taskd
  • OnePlus 5 (Android phone), where termux hosts the app, syncing against taskd

I installed taskd on a server at home. This was a bit of a pain in the neck; setting up users and certificates is fairly fiddly as also is setup of each client. It took a few tries to get it all working, and I went through a couple of user UUIDs before I was done. It comes with a systemd unit file; I have not thus far had that work, so I have to browse through history (boo, hiss!) to find the right command to restart it properly upon system reboot it took some effort to get that working properly.

One interesting thing I noticed; when syncing got “deranged” and I wound up on a new user UUID, I found that, in order to get things unstuck, I had to edit ~/.task/backlog.data. Note that this file contains the UUID of the user that it intends to sync against. (I’m not 100% sure; this may be the “local” idea of the UUID of the user…) The removal of the UUID at the top of that file led to the local instance of task generating a new UUID and proceeding.

Usage

I basically started out by tossing in all sorts of tasks that popped up, without too much intentionality, just making sure that knowledge about upcoming Things To Do got captured. I wasn’t sure what projects or tags to use; it is out of seeing a bunch of tasks that need to be classified that the patterns will emerge. I am basically just 3 months into this, so while some patterns have emerged, there are plenty more to come.

  • It turns out that tagging with +home and +work is mighty useful, for the simple reason that it allows en-masse deferral of tasks. At the end of the work day, I find it handy to simply defer items to another day thus:
    task +work status:pending wait:tomorrow
    It would probably be valuable to defer things further, so that my list of things to do immediately does not get randomly cluttered.
  • I have been adding in lots of periodic tasks as they pop up:
    • Paperwork tasks such as filing copies of pay stubs, bank statements, tax documents, and bills of importance
    • Preparations for annual events
    • Reminders for mailing list moderation
  • Some projects have been emerging, but not quickly or well. It is easier to think about adding tags, and occasionally a tag emerges as being important enough to call it a project.
  • I am not using dependencies nearly much as I probably ought to.
  • As “wishful thinking,” I’d like it if I could have grocery items dependent on a “go to grocery store” task, and have the children pop up as current the moment I arrive at the store and mark that first task done. That also means I’d like it if the children were being “masked” as not ready to proceed (ergo not listed) until I get there.
    • In reviewing Tomas’ presentation, I found The Better Way to deal with this, which is to use contexts. If my grocery items all have +metro as the locational tag (my nearby grocery store is called Metro), then I can define the relevant context:
      task context define metro +metro
      then
      task context metro
      More inclusions and exclusions could be done; in any case, it is clearly useful to use some contexts so when in a particular place, the set of tasks are restricted to those of relevance.
  • Projects (indicated by adding project:taxes.2019 or project:bugzilla.20721 or project:website) are evidently more useful than I had thought, once I start using the dotted notation to allow hierarchical subprojects. They had appeared to be way less useful than labels, but hierarchy changes that. Both are good things (in moderation!) and are good used together.

Future Items

  • Another few months of patterns hopefully leads me to get a bit smarter about how I’m using this, particularly with regards to deferring items I can’t do immediately.
  • I need to get the “sorta graphical” Android client working; need to fight with the configuration to get that working.
  • There are some interesting analytical reports such as task burndown to get some longer term patterns out of it. For that to provide value requires more data collection.
  • I imagine I should be automating some task management, such as having things like the following:
    • TaskWarrior should draw a feed of tasks from bug reports. There’s an extension to pull from Github
    • We’re apparently getting into Scrum work; it would be neat to pull Jira tasks into TaskWarrior automatically
  • There’s an Emacs mode; wait, wait, that’s actually comparatively complete, despite being exceeding brief. It works, and is already useful.
    It probably would be worth extending this to allow operations other than ‘a’ (to add a task) and ‘g’ (to refresh the list), to have a set of interactions one might perform on visible items. The Kubernetes interaction mode for Emacs has some relevant examples.
  • I’m told hooks are interesting, and certainly grasp the broad concept from the way that Emacs uses hooks really really a lot…
    At first glance, it seems less interesting than I had expected…
    • One use case is to automatically commit changes to Git; that is broadly interesting, but I think I can live with that taking place pretty periodically rather than continuously. Especially in that I switch clients a lot, so that keeping consistency would require a lot of Git synchronization.
    • Another usage is to rewrite tasks.
      An interesting example was to change notations, so @projectname would be used to specify project, which is shorter than project:projectname. As above, this needs to run “everywhere” which seems less than convenient. (Again, needs Git repo synchronization, this time for the repo containing the hooks.)

Conclusions

I have been happy enough with my experiences with TaskWarrior, and will be continuing to use it. There are clearly plenty of features I am not using yet, some of which may make sense to poke at further.