Last week I brought an old institution back to life: "karma bugs". Let me explain.

Using a revisioning system is a good idea for any software development (ie: subversion, git or anything like that). Using a change management system is another (ie: bugzilla, mantis and others). Establishing procedures to track source code changes to bugs/change requests is even better. Simply said: every commit requires a (valid) issue number in the check-in comment.

That procedure is easy to follow most of the time in software development. However, especially small things that need to be done shouldn't require developers to create an issue in the change management system in order to fix whatever little tidbit needs attention. Examples could be spelling errors in messages, documentation enhancements, additional unit tests and stuff like that. Noone wants to do these little things if the overhead for doing these is a burden (as creating a proper entry in a change management system usually is).

The "karma bug" is a pre-created issue in the change management system that all developers can reference in their check-in messages for all these little good deeds (thus "karma bug"). At the end of the predefined validity perdiod of the karma bug (like a time period or a release target) all commits are evaluated and the developer with the highest score gets a reward. Just how the scoring is done is something that every project needs to determine theirselves. We've used the number of changed lines as our scoring metric, but anything goes.

I've seen "karma bugs" work wonders for projects both in terms of developer acceptance (with respect to integrating revisioning and change management systems) and even code quality (because doing good deeds might yield rewards).