Last year I wrote a few articles on how to use Taskwarrior to implement GTD. Shortly after, I went back to using Emacs Org mode instead. Now I'm back to using Taskwarrior and I'm using it entirely differently this time.
Moving away from Taskwarrior
To my surprise, I didn't move away from Taskwarrior because I was making things too complicated. I moved away from Taskwarrior because I wanted everything productivity-related in one place. Org mode handles tracking progress/history on and keeping notes for projects much better than Taskwarrior does. That is, if you use Taskwarrior the naive way.
Of course I missed the fact that Taskwarrior is much more easily programatically controlled as I was trying to automate.
As it turns out, removing a lot of bad practices from my workflow made it much easier to go back to Taskwarrior.
Too much stuff
Part of GTD is to keep everything safe in you system, so you can trust the system. I was keeping all notes on a project in a single file
project.org. There was no distinction between the tasks of the project I was committed to doing at the moment and the tasks I wanted to do eventually. For regular projects this doesn't make sense at all, but for software projects this is the natural way to do it.
The next problem was that event hough I had a way to construct a waiting-for list, I neglected to keep it up to date. None of the items on the list reminded me of the list enough to check them off once the waiting was over. The items on the waiting-for list were distributed across multiple
project.org files. I would have to manually go over the waiting-for list every week to keep it up to date. This made I/O bound projects unmanageable.
Moving back to Taskwarrior
Someday-maybe and Notes
To move back so Taskwarrior, I realized I was going to need to keep my notes per project. For starters, I wrote this tiny zsh script:
Now I can type
n project to bring up the notes for any project. This way I can keep notes on every project and still use Taskwarrior.
The most important change is that now I only keep my actions on taskwarrior and keep all the someday-maybe actions for a specific project in the
project.org file. Keeping the amount of tasks in Taskwarrior small is essential to being able to manage them. It's good to keep every (eventual) task in the system, but put them in the someday-maybe list, not in your regular task list.
Automatically up to date projects
Now I could take advantage of the fact that taskwarrior can be accessed programatically. Here is a little script that tells me what projects have no
Now I just added the following to my
.zshrc so that I would be reminded to keep my projects up to date with
+next actions whenever I open a terminal.
This ensures that my system reminds me to keep my projects up to date.
Automatically polling the waiting-for items
To finish the transition back to Taskwarrior, I added another piece of code to my
.zshrc to ensure that I keep my
+waiting items up to date:
Now my system encourages me to keep my
+waiting items up to date as well.
Best practices for Taskwarrior
With my projects and
+waiting items automatically up to date, I could now safely transition back to Taskwarrior.
In conclusion, using Taskwarrior the naive way has some huge disadvantages, but if you adhere to these best practices it is actually better than org mode.
Commit to fewer tasks, but record the others in a someday-maybe list.
Use the someday-maybe list heavily. Look at them every week in the review to make sure you're okay with not doing what's on the list.
Commit to as few projects at a time as possible and keep them up to date.
+waitingitems to keep tabs on I/O bound projects.