|
Project
|
TeamCity
|
|
Priority
|
Major |
|
Type
|
Feature |
|
State
|
Open |
|
Assignee
|
Pavel Sher |
|
Subsystem
|
Statistics |
|
Affected versions
|
No Affected versions |
|
Fix versions
|
High Priority Pool |
|
Fixed in build
|
No Fixed in build
|
|
Fixed in builds
|
no build yet
|
...
I'm thinking of measures like ratio of build successful over total builds per developer, broken build fix time per developer, number of commits per developer, etc.
You are right this is all a bit fuzzy.
(blaming developers that happen to commit together with bad change) Do you find this acceptable?
This also means that users that commit more often are more likely to be blamed by mistake.
Alternatively, failed builds with several changes might be ignored in the statistics.
I think failed builds with changes from different users should be ignored. That would be fair.
Yes. I know this doesn't make sense for every developer team and of course tests without real body would fool the statistics.
See attachment.
Ok this is really difficult. Maybe TC has to get a param (via service message?) from the build runner to get information about the current amount of code.
This could be "Lines of Code" or "Bytes of Code".
But this fuzzy value is really really interessting. Of course the management can't really compare two developers since they have different tasks. But every developer can see his own progress and hopefully wants to improve himself.
Regards, Steffen
Thank you for your reply. We return to the statistics from time to time internally, but do not have unanimous opinion on the subject. Your comments will definitely help us.
Not sure we will be able to include this into 5.0 but we will try.