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
  • Created by   Kirill Maximov
    5 years ago (24 Jan 2007 19:40)
  • Updated by   Yegor Yarko
    2 years ago (18 Mar 2010 11:03)
  • Jira: TW-1516
    (history, comments)
 
TW-1516 User commit statistics
3
Issue is visible to: All Users
  The issue is visible to the selected user group only
(like in TMate, FishEye)
Comments (3)
 
History
 
Linked Issues (?)
 
Yegor Yarko
  Yegor Yarko
23 Jul 2008 17:27
3 years ago
from feedback on Fri, 11 Jul 2008 22:09:29 +0400:
...
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.
Steffen Forkmann
  Steffen Forkmann
24 Jun 2009 11:04
2 years ago
Hi Yegor,

You are right this is all a bit fuzzy.
    
Steffen,


How does the build-failure rate per user / group evoles over time?


Provided, a single build failure can contain several changes to blame, this will be quite 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.

How does the new test case count per user / group evoles over time?


How would you bind a test case to a user? By associating changes of a user with the test that first appeared in the build?


Yes. I know this doesn't make sense for every developer team and of course tests without real body would fool the statistics.

What whould you like to see on the time axis? Should the values be averaged?


See attachment.

What is the test case / new code ratio (per user / per group)?


How would you measure that?

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
Related Attachments
Yegor Yarko
  Yegor Yarko
01 Jul 2009 16:52
2 years ago
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.