Difference between revisions of "Karma For Continuous Integration"

From CitconWiki
Jump to navigationJump to search
 
(One intermediate revision by the same user not shown)
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!]
 +
 +
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.

Latest revision as of 13:55, 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!]

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.