Project management and time tracking

26 April, 2006

How much time is it sensible to track? Who needs this information?

At work we use Trac to look after our projects. It’s very useful for what we do because a) it’s free b) it has tight Subversion integration c) it has a wiki d) it has a customisable issue tracker. It does also have downsides like its atrociously unfriendly wiki-syntax, but seeing as we weren’t using anything at all before, it’s a step in the right direction.

By default, Trac doesn’t do any kind of time management, so in a couple of projects we’ve added in a time_estimate field to issues and a bit of javascript for totalling up time estimates for milestones (in fact, it’s this Greasemonkey script), which is very handy indeed.

Trac is also useful to us because it generates iCalendar files for project roadmaps and RSS files for just about everything else.

So here’s the problem:

So, what about work I do that isn’t on a project?

Where do these days go?

Some suggested solutions:

At the moment I don’t really know what to do. I suspect that we should use something which imports Trac milestones and the corresponding issues and use that tool to schedule the tasks. This would also give us the option to add in custom, one-off tasks like the ones listed above. I suspect also, that we should do as Joel does and ignore dependencies and let the developers actually sort that out.

In fact, the more I think about it, the more I think that we should get the latest version of Jakarta POI and wire up Excel to Trac to keep track of all. It’s got to be the easiest solution, hasn’t it?

See other posts tagged with general and all posts made in April 2006.


27 April, 2006 at 08:14

Couldn’t you have a “not project time” trac project?

27 April, 2006 at 10:33

I didn’t think of that.

I’d only thought about one Trac instance per person for non-project time.

Hmm, your idea could work you know.

Henri Bergius
02 May, 2006 at 12:25

The way we’re trying to solve this is to enable multiple different “project extranets” in Trac, or whatever, and then using the DBE peer-to-peer network to actually copy tasks and work reports to our centralized OpenPsa install.

This isn’t quite ready yet, but the first implementation is promising.

The good part about this is that if different orgs participate in the same Trac-managed development project, each can get their tasks to their own project management software. Assuming it supports DBE, of course 🙂