Our small team has 3 developers working full time on various projects. We practice throughout automated testing and aim to get 100% code coverage with unit tests.

Our internal version control system is git. Active development within git means couple or more new branches in the central repo daily and lots of merges.

Someone has to keep an eye on this whole stuff.

Having lots of automated tests, makes it much easier than running QC on them mannually after every commit

Questions to be answererd:

• is the last push ok?
• is the last merge to the master ok?
• is this new branch ok?

Solution

We use buildbot.

It has to watch several things:

1. Commits to the master branch, which are usually pre-release merges for my review.
2. Commits to other branches, which are usually work-in-progress
3. New branches - new work is done or something tangible appeared

Nice to have

Some integration with Trac. E.g. it would be nice to see what commits (to the central repo) where made on this ticket or what’s the last successful build for that ticket.

There are lots of fun, interesting and useful things to be done within git-buildbot-trac integrated system. Yet it requires some hands-on experience to check what’s the best corner to cut and the biggest pain to cure.

I, being a software developer, team leader, project manager and,
generally, a busy person, desperately need time tracking and planning
tools.

More exactly stated, it’s not the tool I need, but I need instant
answers to questions, whenever I’d like:

• where my time had gone?
• what’s the closest checkpoint time for every developer online?
• how much time my team mates spent and what task it was?
• how much time I have to bill my customer (per customer per project)?
• how much I have to pay to my developers (per developer, obviously)?

These questions are very different, require different information to
be collected and different decisions are to be made using the answers.

Personal time flow

Record attention flow (mouse pointer, active and top windows, keyb
activity) for future analysis.

Analysis result should within single graph depict time flow and how it
was really spent on different tasks.

Problem: how define “tasks” automatically/semiautomatically?

Similar solutions:

• (link to macosx solution lost)
• gfocustimer - declares to watch the focus, but doesn’t seem to work

How to implement:

• clone X11 xev to record X events to the database
• analyze db with a custom script

Communicate checkpoints

Since our usual communication channel is a jabber room, the solution
should be probably a jabber bot, residing there, monitoring what is
said and keeping a checkpoints record.

A log of some kind would be useful too.

Similar solutions: any?

How to implement: go and hack; it should be simple.

Track billable time

This, probably, should be a simple start-stop watch residing in a dock
area or completely off-screen.

It should record tasks and start/stop events to a local db, allow user
to edit it and report it upstream.

Similar solutions:

• kdepim-karm
• PTimeTracker
• GnoTime

How to implement: since there are vast number of time-counting
programs, the task boils down to integrating them with some protocol.

Consolidate billable time

Get updates from solution, crafted in the previous part, and drop it
into bigger db. This time the resulting db probably should be sql,
for the ease of reporting.

This also should integrate with Trac somehow.

Similar solutions: see above - everything starts with the protocol

How to implement: hack it.

Summary

This pretty much outlines what I need from time-tracking tools. Few
(if any) solutions are ready, so most of them are to be hacked out
ourselves. Will be glad to be proved wrong.

Now, well, the estimation is the whole different story.

In 1977, for instance, the National Institutes of Health hosted its second conference on obesity and weight control. “The importance of exercise in weight control is less than might be believed,” the assembled experts concluded, “because increases in energy expenditure due to exercise also tend to increase food consumption, and it is not possible to predict whether the increased caloric output will be outweighed by the greater food intake.”

That same year, The New York Times Magazine reported that there was “now strong evidence that regular exercise can and does result in substantial and—so long as the exercise is continued—permanent weight loss.”

By 1990, a year after Pi-Sunyer’s pessimistic assessment of the evidence, Newsweek was declaring exercise an “essential” element of any weight-loss program, and the Times had stated that on those infrequent occasions “when exercise isn’t enough” to lose weight, “you must also make sure you don’t overeat.”

It’s wonderful how they are easy to put things exactly in a wrong order.