My task management: input queues

Published on Thu 10 December 2015. Filed under . Tags .

I have a complex task management system, which was partially influenced by Getting Things Done and by blog posts of Leo Babauta, while it seems to have randomly evolved into a different thing since. I’m writing how it currently works (or doesn’t), to better understand what mistakes I made and how I can fix them.

To know what tasks I should do, I use my ‘real’ task management system (really many such systems, including a separate database of bookmarks from several browsers) which is a topic for a future article. I have to write all my ideas and input them to that system: it is too complex to be used in real-time. To efficiently organize this, and never feel guilty of forgetting an idea too complex to fit on a book’s margin, and to blame the ‘real’ system for forgetting important deadlines, I have multiple slightly formalized methods of keeping these ideas until I add them to a real task management system.

I call them input queues. That term is misleading: they are not input, since if I can do a task ‘now’ instead of inputting it to the ‘real’ system, I do it; they are not queues since they are random streams of consciousness which I split, merge and reorder into tasks.

Handwritten notes

The most basic input queue was a square piece of paper with some notes handwritten (using a pencil, nearly never a pen). Each day I checked all such queues, and marked with vertical lines on left the notes of inputted tasks (striking out lines corresponding to already done tasks). I never needed them after inputting all tasks and having no space left. (Two situations motivated me to use these cards as an input queue only and keep a separate digital ‘real system’: previously I had to carry many of these when traveling, not only enough to fill while away from home, and my family had thrown away all my important notes stored in a large cylindrical container.)

Phone notes

Now I usually carry my phone and it’s easier to access than the pencil and paper. I use the Simply Do Android app to maintain a single task list named ‘queue’: I add all ideas as items there and remove them when inputting them to the main system (or when putting the listed products in a shopping basket: a second order input queue). The app is too complex for my needs, but it works well enough. While this doesn’t have such a technical motivation as with paper notes, I type all tasks from this queue to the main system manually: it requires more thinking than using software to automatically copy the list and might lead into better notes.


I have adapted my email inbox into another input queue. I have a rule of having no unread mails, unless they are for tasks to input (or do) during the nearest several days. I keep the inbox empty by periodically moving mails to other formats (this is a task scheduled in the main system; I used to do it once a week before backup, while I’m now moving to more automated daily backups).

Really there are two ‘inbox’ folders: the real inbox for mails not sorted by my Sieve filters to other folders, and a separate one for notification mails, e.g. from mailing list moderation, from apticron and Parabola issue trackers. (Mailing lists get their own folders, inbox mostly gets spam and mails for which I haven’t updated the Sieve script yet.)

I keep the usual input queue rules for unread mails: I mark the uninteresting ones as read when browsing new mails (on phone or from Gnus), when doing the needed task (replying, approving moderated list mails, upgrading systems, etc) or when adding a task in the real system to do more. Rarely I check my sent mails for ideas for blog posts.


Some entries in the real task system result from discussions on IRC; I need to remember to never refer to IRC logs: they are unreadable and unsearchable. I copy the relevant log fragments if needed. (Same when reporting Parabola issues.)

Browser tabs

I use browser tabs for pages that I’m currently reading (or planning to read in near future), for Kanboard dashboard (one of my ‘real systems’ which I input the tasks to), and a blank tab. The blank tab would be useful if I really cleaned the queue and closed all pages to read: the browser loses my tab groups if it doesn’t have at least two tabs open. (I also used to read a microblogging site which counted the number of unread posts unless their page was in the active tab: so I needed at least one other open tab to know how many posts to read. This was solved by technical changes making that site nearly completely useless for me.)

Tabs don’t work well for the long-term: Firefox-based browsers sometimes forget the page position, e.g. when the page temporarily fails to load. They are worst for pages that I read up to a point and return to after a year of not visiting their tab. (Most smaller browsers that I know don’t keep the page position or tabs at all when restarting them, so they are completely unusable for me. Firefox used to have a reading mode which also had this misfeature; it’s ironic.)


I don’t have a separate ‘Downloads’ directory on my personal computers: all files downloaded from the browser go to the desktop directory. In case of PDF ebooks, I either read them and move to my git-annex repo with such files (in an appropriate directory for read PDFs), or move them to the ‘to read’ directory.

Browsing them in Okular, I reopen them on the page where I stopped reading. I use other systems to manually synchronize page numbers between different computers where I might read the same book.

For EPUB ebooks, I use Cool Reader on my phone. After reading the book, I remove the file from the phone, possibly moving it to the git-annex repo or a random directory on one of my computers. Pages with ebooks are bookmarked; for serialized novels (like most fanfics) I use a custom bookmark record field for tracking reading progress. (Several years ago I had an eink ebook reader device; initially I used it with very poor and buggy vendor firmware, later with OpenInkpot; it is why I now run a newer version of the same application as was included in OpenInkpot on my phone.)

Feed reader

I have a personal instance of Tiny Tiny RSS (previously on my remote VPS, then on various computers that I own and access via my VPN). Most of the feeds are Web comics; but there are also some interesting technical blogs and aggregators. It naturally works as the main source of links in my bookmarks system, both in the ‘read’ and ‘to read’ categories.

Initially I kept all unread articles in tt-rss, but later I lost them by accidentally marking all articles as read (instead of just articles from a single feed). Now I have thousands of the ‘to read’ bookmarks exported from a tt-rss database backup. I plan to periodically export newer ones there too.

Conclusions and future ideas

Writing this helped me notice several significant problems in my current workflow. (‘Current’ is a very relative word here: I changed many parts of the system, but mostly not the input queues, during a several months break between starting and finishing this article.)

Each input queue (other than the handwritten notes) involves a separate set of programs. There is no integration between them and with the ‘real’ systems. This is by design, but I have surely noticed this before calling it a ‘design’. Instead of just several complex task management systems (‘real’ ones), I also have many more for tasks that I move to the more complex ones.

I had many issues with synchronization of data between computers: there should be no such problems here due to the input queue idea. Each queue is separate and all its tasks are quickly moved to the ‘real system’ or done. This doesn’t work well with big tasks like reading a large book (or any sufficiently complex fanfic). (My experience with advocates of task management systems suggests that I’m using my own system incorrectly, so I don’t get its claimed benefits.)

Maybe I need to completely separate input queues from the real systems (and put reading the book in the real system), but open tasks in these systems need reevaluating if they are needed if I’m not doing them for a longer time… becoming another input queue.

To ease synchronization between computers, I preferred storing most data (other than input queues) in DVCS repos. But there are no obvious winners among distributed task management systems; I have chosen using Kanboard as one of the ‘real systems’ instead of writing my own. Now I run Kanboard on one computer and access these various systems from one laptop only, making distributed designs much less important.

I also often forget about synchronizing most input queues (and that I have several others, like files on the phone), so my real systems have tasks reminding me.