I almost used markdown to maintain my lists, but the lack of checkboxes was a dealbreaker for me. Perhaps I should have tried to extend it. Oh well.

Now I maintain my lists as regular text files, with very little markup. While I’m guilty of faltering, I try to make sure that the majority of what I add are discrete actions. These, being the highest and most noble form of “to do” item, get a pseudo ASCII checkbox, ala:

[ ] Bring clock to work

[ ] Sort pending photos into the next DVD
[ ] ..burn photo DVD

Obviously these will render as HTML checkboxes. Also, note that I nest subtasks that can’t be performed immediately. Until the higher-level tasks are completed, there’s no sense bothering with the lower ones.

One step below an actionable item is a project. GTD defines a project as anything requiring more than one action to complete it. So, we have:

{ } New Menu changes
[ ] Add 'current' class to currently selected item to highlight it
[ ] Make newly created items populate in 'current' directory, not default directory
[ ] Clean up class names--make a default

Those three tasks belong to the “New Menu changes” project. Note the squiggly braces. This could render as a radio button, perhaps. Or a larger checkbox.

To complicate things, I’m guilty of using my inbox.txt list to just hold random notes and thoughts, as well as specific actions and projects. I eventually filter these out into the appropriate list, but if some program is going to process and render ANY list, it needs to be able to process EVERY list–including the inbox. So, here are a few more formatting rules I try to apply across the board;

• Lines starting with an asterisk are bullet-point items. Render as <li>.
• Lines starting with dashes are section breaks. They could render as <hr />
• Subsequent lines are to be grouped together if there is no blank line between them. This applies to bullet points, tasks, and projects.
• An ‘x’ in the braces ( like [x] ) indicates that the task/project has been completed. Render this as a checked checkbox.

And, since I’m lazy and end up just typing unformatted junk at the end of my inbox half the time, the magic rule that saves me:

• Lines with no special character at the beginning are free-form text. Render these as <p>text</p>

Now, armed with a very loose grammar, I can begin really thinking about a rendering engine for this.

I happen to be a fan of subversion, but any version control package will do. SVN allows me to easy tunnel my traffic over https, which makes life easy and secure in my world of oppressive firewalls and open access points.

What’s the secret? Simply keep your lists under version control. I have oodles of separate lists for various purposes, all under a ‘lists/’ folder in my home directory. The trick is to update in the morning and commit when you make changes, but even much of that is automatable.

Beside the benefit of maintaining synchronization between multiple workstations, this has a few non-obvious benefits as well. The version control server, by its very nature, provides backups of your precious lists. You could provide read-only access to your lists (or a subset thereof) to specific individuals. Or, you can do fancy server-side scripting/programming to operate on these lists. You could have a script to auto-checkout your lists and generate a daily HTML version. It could sort by priority, or pick stagnant tasks that have lived there for too long. If you’re clever, carefully crafted “tasks” could be pattern-matched at the server to actually perform simple tasks.

That reminds me…I have to add “make list-to-HTMLifier” to my lists…