Better Task Management for Projects

What would a minimal task tracking system look like if it was built into iCal/CALDAV?

I was thinking about this, because I’ve been tracking my time for projects recently with TimeTagger. This is a great open source project for tracking time, similar to Harvest and other commercial offerings.

But rather than having separate tools for this, and having to remember to track any meetings that are in your calendar anyways, let’s imagine what it would look like if this was built-in to the calendar standard.

And the best part is that it would be extremely simple to implement!

This is part of my 3 post wishlist for extended calendar features:

• Part 1: Events Relative to Easter and the Lunar Calendar
• Part 2: Task Management for Projects
• Part 3: Relating Events to Emails & Vice Versa

The Implementation

This feature is so simple to implement, I’m surprised that it doesn’t already exist.

For each meeting, all we’d need to add is a special key that tracks which project the calendar object ¹ belongs to. The value of this key is a project “tag”, which is a hierarchical value representing project and possibly subproject.

For example, below is an event that is tagged with the DemoProj project and HelloWorld task. Specifically, look for the XPROJECT property:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//hacksw/handcal//NONSGML v1.0//EN
BEGIN:VEVENT
UID:uid1@example.com
DTSTAMP:19970714T170000Z
ORGANIZER;CN=John Doe:MAILTO:john.doe@example.com
XPROJECT:DemoProj::HelloWorld
DTSTART:19970714T170000Z
DTEND:19970715T040000Z
SUMMARY:Bastille Day Party
GEO:48.85299;2.36885
END:VEVENT
END:VCALENDAR

With this setup, each event is optionally assigned to a task.

These tasks can then be hierarchically nested, where a :: separates each parent task.

For example, the header indicates that the event is a DoSomething task within the larger DemoProj project.

XPROJECT:DemoProj::DoSomething

It would even be possible to support tagging the event with multiple projects, which would split the time between them. Though this is generally discouraged in existing task tracking tools. For example:

XPROJECT:DemoProj::DoSomething
XPROJECT:DemoProj::AnotherTask

Reporting

All this tracking is useless without being able to report on the data. The common questions these tools answer are:

• How many hours did you work this week for each client/project?
• What tasks took up most of your time?
• What percentage of your hours were overhead?

Using the XPROJECT data, these questions are answerable via the standard Calendar querying API where you filter the query to only calendar objects that have the XPROJECT property set.

This API also supports filtering objects further based on the content, which means you can query calendar objects for certain project tags.

That being said, it is inefficient to iterate all calendar objects within the reporting period each time you want to generate a report. What we really need is an aggregate API.

However, this doesn’t exist from what I can tell in CalDAV. And extending the standard and waiting for adoption in mainstream servers is a huge uphill battle.

So, it would be better to implement a sidecar client, which would satisfy this aggregate reporting role. The service would …

• Watch your calendar data for any changes to events
• Track aggregates as the calendar data changes
• Expose an aggregate reporting API

This way, you’d be able to continue using any standards-compliant CalDAV server.

The sidecar service would also be able to track any metadata relating to projects. For example:

• Project Name
• Time Estimate, Budget
• Hourly Rate (if different from your normal billing rate)
• … and anything else you can think of

And, this service could also help implement any other nice to have features like:

• Bulk migrating events from one project/task to another
• Highlighting calendar events that aren’t tagged to any project/task
• Generating invoices

Now, you might be thinking that this is a pretty big cop-out. Basically I’m suggesting packing all the interesting features into this sidecar service. And you’re right!

But that highlights the fundamental suggestion. Time tracking is possible as an extension of your calendar, not a replacement for it or a 2nd tool that you have to track things in.

Store the underlying data in CalDAV and build features on top of that.

But, Why?

TimeTagger and Harvest work fine. So, why do this? Ownership and Cooperation

First, you own the data. Yes, you might be using and paying for a hosted calendar service. But if your account is suddenly canceled. You can migrate to another provider or host your own server.

You can backup your calendar using the open CalDAV protocol and walk away whenever you want.

Second, you can connect to the CalDAV content from multiple services. For example, how awesome would it be if appointments booked through Calendly or Cal.com automatically tracked time to your client? What other synergies can be had if services were based on open standards instead of proprietary silos?

This type of cooperation across services is possible to some extent with Zapier, IFTTT, N8N, and other integration/automation tools. But why do we need an 3rd tool just to connect things, when they’d be directly interoperable if they used open standards.

Conclusion

The interesting thing about this proposal is that it can be implemented almost completely as an extension to existing, mainstream CalDAV servers. The full implementation would include:

• A XPROJECT-aware CalDAV client
• A sidecar service for aggregate reporting

And in combining these things, you’d get similar functionality to Harvest or TimeTagger, but it’d be integrated into your existing calendar.

And this has amazing side effects. For example, you’d be able to integrate this with appointment booking systems like Calendly or Cal.com.

This standards compliant co-existance is an under-appreciated feature in today’s SAAS-ified landscape.

But, we can dream. And through open source, we can fill the future with software that works for us, instead of siloing everything off.