Q:

Badges for project team members for motivation

Stack Exchange is using nice way to motivate contribution through Badges. I was thinking of implementing this same idea for my project team members. Badges will be awarded to project team members in recognition of their contributions to the project.
I thought I would use the three ranks of badge: Bronze, Silver, Gold. Rank depends on the volume of the effort through the project sprints.
Badges example for development project
Committer: commits working code changes into project repository (e.g. Bronze Committer=10 commits during 1 sprint, Silver Committer=25 commits, Gold Committer=50 commits)
Tester: test release and report bugs (e.g. Bronze Committer=2 bugs during 1 sprint, Silver Committer=5 bugs, Gold Committer=10 bugs)
My questions are:

Do you think this will be a good idea to motivate people and get the project on-time with good quality?
Did anyone use similar idea to motivate his team members? If yes, how do you implement it? Giving examples is much appreciated...  
What metrics would you suggest to implement this idea and how to measure them? Metrics I thought of like:  coding, commiting, completing tasks on time, testing, recording spent time, commenting in code, objectizing, organizing, integrating, standardizing, creativity and designing.  
For above proposed metrics in point #3 (and if you are proposing new metrics), how do you suggest to measure each of these metrics?

A:

If this is a project that people are currently getting paid to work on: ABSOLUTELY NOT!
First of all, the goals on the project should be plain and obvious, and on a software project, those goals can already be complicated.  Get thorough designs in on time, get code completed on time with as few defects as possible, incorporate feedback from code reviews, fix the unit tests you broke working on this new feature, get new units tests done on time, get doc/doc notes done on time.
Now on top of that, you want to add a bunch of "fuzzy" goals you mention in #3?  "Objectizing"?  If you propose a badge for that, before you finish your first sprint you are going to regret ever coming up with that idea.  People are going to be arguing that their objectization is better than someone else's objectization.  All kinds of time will be wasted on this.  And worst case: people are going to start getting personal because someone didn't like their objectization.  Goals like "organizaion" and "standardization" are equally fuzzy.
You already have enough goals.  Leave your developers alone to achieve those.  You don't want people spending time chasing badges (for which your organization receives no credit).  You want them trying to achieve real goals.
StackExchange can use these badges because we aren't getting paid for this.  And if it doesn't get done, only StackExchange loses out (though certainly the communities benefit from this assemblage of knowledge and people).  StackExchange also has an automated process for awarding badges.  How are you going to automate the awarding of the "designing" badge?  You can't.  So you're going to have to spend a lot of time doing it manually.
Developers are notorious for gaming any system you put in front of them.  The gaming of systems often leads to wasting energy while completely missing the point (real goals).  Your current goals are important and tough enough.  Keep your people focused on them.

A:

There are already a lot of theories and studies about motivation.  Extrinsic motivators, like badges, awards, and money, have been studied and I believe the results show they are marginal at best, do nothing, or maybe even decrease motivation.  The strongest motivators are intrinsic and are mastery, purpose, and autonomy.  
Follow the science....

A:

Is it a good idea?
As for mostly everything: it all depends on your team.
Some might be very receptive, some absolutely not. If we are talking of an in-house team, I believe it would work more easily with people who already trust you, and who have some sense of humor, as they will have to cope with something that looks un-corporate and hence, at first sight, perhaps “unprofessional” to some. I personally had this issue when I tried to add some other “social improvement” fun-yet-serious artifacts, and backed off when I realized the team was not receptive and considered it more as a game I wanted to play rather than an actually useful PM  practice.
Do others do so?
Well, not exactly badges, but along the same lines, and most certainly more impressive  ;)  check out for example the Swords and Shields Ceremony at Blizzard.
Metrics

coding: this is not a metric (what exactly are you measuring?).
commiting: this is a bad metric, quantity does not mean quality, and it is usually the opposite in software.
completing tasks on time: possibly, but on scope too, and in such a way that the completion was not done in such a terrible way that it will raise bugs later on…
…

Actually, I'll stop here. This has already been addressed.
You have to notice that the whole SE reputation and badges system relies on a community of human beings evaluating stuff. The only automation that takes place is in counting scores and associating badges to that score.
For testers, it should be a bit easier. The amount of spotted bugs, possibly weighted by severity, could be an easy metric. You could also consider the time before the report as another metric.
Philosophical considerations
Such a system is simply a model for reputation, and thus a way to simplify human trust attribution. However, for such a system to work, it has to map precisely to events fellow humans would acknowledge as impressive, or at least good in some way.
And I'm afraid this is exactly where you'll hit the limit of automation. By this very definition, automatically computable metrics cannot compute how good creative work is. Computers are very good at calculating stuff, not really at evaluating creative work. And coding is creative work.
Hence, I don't believe such a system would actually be sustainable to ask for contributions, as it would quickly raise doubts on whichever metric is used. Anything but fellow human evaluation will most probably be disregarded by other programmers, removing the very intention of improving reputation. It could even have the opposite effect, depending on the metrics used (“gold contributor? huh, this guy most probably did 30 shitty commits…”).

So, let's conclude. Adding a badge system is a cool goodie that simplifies such an evaluation by adding discrete steps to a continuous spectrum of evaluation, but for it to have any meaning, you need to make sure the way they are attributed is consensual. For this, I think the only valid metric is peers evaluation. This is difficult to obtain reliably on anything but projects with a solid community. 
Hence, I would advise to think twice before trying this reward system, as it could be disregarded quite easily, making you waste effort and look foolish, or even backlash if a subset of the population buys into it but not another, segmenting your community / team.

