Difference between revisions of "Karma For Continuous Integration"
Line 20: | Line 20: | ||
Martijn: maybe the teams could select the metrics that are being tracked. | Martijn: maybe the teams could select the metrics that are being tracked. | ||
+ | |||
+ | [Squirrel takes over at this point - didn't note names!] | ||
+ | |||
+ | Perhaps we could have team karma - not attached to a specific developer. | ||
+ | |||
+ | Or maybe karma could wear off or decay over time, so particular developers don't get a large amount. | ||
+ | |||
+ | Another idea: provide a message at commit time, telling the developer how he or she did on various measures. | ||
+ | |||
+ | It's hard to measure refactoring quality, which is one of the most important factors; in fact sometimes when doing tricky refactoring you intentionally (and temporarily!) incur technical debt. | ||
+ | |||
+ | Yet another idea: if karma to be measured, should change the components and the weighting over time, perhaps reviewing at each retrospective. | ||
+ | |||
+ | One last idea: someone could sacrifice karma to the team. |
Revision as of 13:53, 11 November 2007
Karma for CI, by Squirrel
Squirrel, Jason, Ronald, Frederik, Joel, Luc, Rija, Martijn, Pierre-Emmanuel, Dario, Tero, Raumo, Marko, Marc-Andre, Wolf, Roshan, David Z, Alexander, Ulrich, Robert, Cirilo, Marc
Problem at youDevise: the code was written by self-taught developers. They want to encourage people to write better code, without forcing them. They want to measure quality with some value.
Their solution: a tool where karma points are given when good things are done. BUT there is no tangible reward: no bonus, no salary increase, no assessment. The question asked to the attendants is: do you think it is worth building such a tool?
Alexander: this sounds like a fix for a situation he saw where bonuses were given depending on the number of lines.
Jason: our developers have became better. We now want to help them get better without training wheels.
Ulrich: this might be against collective code ownership. Also, it could be used negatively for people to compete against each other. Squirrel: yes, that might work only when there is a good atmosphere in the team.
Maybe just karma per team, not per developer.
Martijn: maybe the teams could select the metrics that are being tracked.
[Squirrel takes over at this point - didn't note names!]
Perhaps we could have team karma - not attached to a specific developer.
Or maybe karma could wear off or decay over time, so particular developers don't get a large amount.
Another idea: provide a message at commit time, telling the developer how he or she did on various measures.
It's hard to measure refactoring quality, which is one of the most important factors; in fact sometimes when doing tricky refactoring you intentionally (and temporarily!) incur technical debt.
Yet another idea: if karma to be measured, should change the components and the weighting over time, perhaps reviewing at each retrospective.
One last idea: someone could sacrifice karma to the team.