“We (developers, people) have need in quite various planning and action tracking tools. No one tool could fit everyone’s needs. The real problem, as I perceive it, is that there are no widely accepted (as RSS or HTML or whatever) format for plan and action tracking. Given such representation, we can develop various tools from little unix-type to behemots (if someone really needs them nowdays) that allow to do exactly what we need from them now. But…. No accepted model – no solutions what simply plug in. Would be glad to know that I’m wrong.”

— Andrey Khavryuchenko, in the comments to an article about nagging issue tracking

That’s a good idea. No, really. It is a very bright idea. We all have different mindsets, visions and needs. We need different ways of working with planning software.

But we have one in common: we need to plan and to take an action, avoiding procrastination, missed deadlines or forgotten tasks. We all need not to waste our time.

I’ve decided to think more about it. What if I will try to analyze requirements to such a format (protocol)? Let me try.

Planned Action

First major part of such protocol is planning actions. What properties are essential for a planned action?

description and payload
tag information (like arbitrary tags, context, aspect, etc.)
participants
when action should be taken? (i.e. when work on action should be started)
when is a deadline for this action?

Let me go through these items in details:

Description and Payload

Each action should have a description that makes it meaningful for a human. It should answer to a question “What should be done?”. It could be either short few words text (like “Have a lunch”) or more or less complete and detailed action description. I imagine description is a variable length text.

What is a payload? Payload is an arbitrary number of binary files referenced. It could be ~~Word~~OpenOffice documents, arbitrary URLs, text notes. In my understanding, payload should be a set of URLs, each having textual description of each one.

Tag Information

Each action should be able to be tagged with either arbitrary tags (like “interesting”,”exciting”) or special kind of tags (like “context:home”, “context:office”, “aspect:book keeping”, etc.). In order to make this system as flexible as it is possible, I’d suggest that tag value could also be a URL. What for? Well, it could be a proper way of specificating such things like context. Each person’s context is different, even it has the same name. “home” for John is not equal to “home” for Yurii. So if each one will refer own contexts: http://john.name/asap/context/home, http://rashkovskii.com/asap/context/home. Also these URLs could lead to some data stored on their servers, for example, textual context definition.

Participants

Participant is a set of URLs, each of which refers to a participant of an action. Each URL has an attached textual description, which may be used for naming participants or their roles.

When Action Should be Taken?

It is one of the most important properties of an action. It describes on which conditions action executed should be started. I envision following ways of describing it:

Datetime with an optional order of magnitude (minutes, hours, days, weeks, months, years). I.E. You could specify something very specific like “Jan 1, 2008 11:30AM” or you can say something like “Jan 1, 2008 first 12 hours”, “Jan 1, 2008 anytime this day”, “Jan 1, 2008 to Jan 4, 2008”, “Jan 1, 2008 or any day this week”, “Jan 1, 2008 or any day this month”, “Jan 2, 2008 or any day this year”. Of course, this way should be specificated quite precisely. I see no problem with it, but it just needs to be detailed and well-thought.
Consequent execution (dependent action). Action could be dependent on a number of another actions. Once that actions are completed, you can start on this action.
Someday. No specific date, no specific condition to start execution of this action.
Never. Action that will be never planned for an execution.

When is a Deadline for this Action?

This property describes when this action should be completed. I envision following options:

Datetime with an optional order of magnitude (minutes, hours, days, weeks, months, years). I.E. You could specify something very specific like “Jan 1, 2008 11:30AM” or you can say something like “Jan 1, 2008 first 12 hours”, “Jan 1, 2008 anytime this day”, “Jan 1, 2008 to Jan 4, 2008”, “Jan 1, 2008 or any day this week”, “Jan 1, 2008 or any day this month”, “Jan 2, 2008 or any day this year”. Of course, this way should be specificated quite precisely. I see no problem with it, but it just needs to be detailed and well-thought.
Relative datetime, with an optional order of magnitude.
Someday. No specific date for a deadline
Never. It is planned that action will be never done.

Take Action

Which Action?

In order to take action, we need first to be aware of its existence. We need to have a protocol or format that will deliver a schedule or a list of actions that require execution. This format should be able to describe events that take an arbitrary length in calendar (like “Sep 1, 2007 7:00AM”, “Sep 1, 2007 7AM-9AM”, “Sep 1, 2007”, “Sep 1-7, 2007” or “September 2007” or a whole calendar).

Action should occupy Calendar form its first day (“when action should be taken?”) till its deadline. If action has no specific date of start (like consequent, dependent action), it should be calculated indirectly (in case of dependent action, it should be a date right after latest required action deadline).

Take it!

Protocol should provide a capability to tell that action is really has been taken and is in progress. It should store exact datetime of when it was taken.

Release

Release is an opposite function to “Take it!”. It tells that action focusing has been stopped. It should store exact datetime of when it was happened. It will allow to track time spent on an action.

Also this function should have a “completes” boolean attribute. If true, this means that action is actually completed and needs no further attention (should be reflected in a respective action).

I realize that currently this draft is very raw. It could be much better if I will return and improve it. It could be better if you will propose how to improve it.

I’m publishing this to review it once (I said once? much more!) again, to have some feedback and then I will move further to analyzing which existent technology solutions could be used to accomplish this protocol or whether we need to have some new simplistic format/protocol; or both. I have some ideas, but I want them to be polished.

I will be really glad to hear if something already exists (because this means that I will be happy with my planning and taking action very soon). I will be very glad if I will get some feedback from readers.

I’m looking forward to have a good technology stack for planning and taking actions.

I’m also interested to hear whether all this stuff I wrote above is a bullshit :)