It is a difficult topic, maybe the answer is a mix out of all of your points. But most of them can not be taken as a single indicator of the code quality or teams performance.
You can write shitty test code which still covers most of your code, the amount of bugs in features depends a lot on the complexity of the feature and the already existing code around it. AVG page load time does still not tell you how well the code is written. Low complexity is a good indicator but also does not say a lot alone.
For Bugs, I find it very important to discuss each Bug and its fix in the team, without making it a blame game. The Questions should be why did it happen (Answers could actually point to 1, 4, 5 in your list)? What can we improve to avoid similar bugs the next time?
A lot of times I just see Bugfixes after Bugfixes which could be traced back to the same root cause, like spaghetti code, if you would take the time to analyze it. This is basically what should happen in each Sprint Retrospective but rarely is done (at least in my experience).
all good ideas, but so what I want to get is some sort of number/numbers to be able to evaluate team performance over time.
And the page load is an indicator that I actually dislike most... especially since its average, there are just too many possible fluctuations there(amount of pages going up and down the peak ours, promotions on tv, etc.)
I guess for all things mentioned, you could record the numbers automatically, like every week and then create graphs and check the trend.
This should give you a quite good indication of how a team performs over time and to changes, for example, if a lot of new members join or if the workload is increasing.
If your company records over hours you should add these too, so you might see that the performance goes down if there are too many.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It is a difficult topic, maybe the answer is a mix out of all of your points. But most of them can not be taken as a single indicator of the code quality or teams performance.
You can write shitty test code which still covers most of your code, the amount of bugs in features depends a lot on the complexity of the feature and the already existing code around it. AVG page load time does still not tell you how well the code is written. Low complexity is a good indicator but also does not say a lot alone.
For Bugs, I find it very important to discuss each Bug and its fix in the team, without making it a blame game. The Questions should be why did it happen (Answers could actually point to 1, 4, 5 in your list)? What can we improve to avoid similar bugs the next time?
A lot of times I just see Bugfixes after Bugfixes which could be traced back to the same root cause, like spaghetti code, if you would take the time to analyze it. This is basically what should happen in each Sprint Retrospective but rarely is done (at least in my experience).
all good ideas, but so what I want to get is some sort of number/numbers to be able to evaluate team performance over time.
And the page load is an indicator that I actually dislike most... especially since its average, there are just too many possible fluctuations there(amount of pages going up and down the peak ours, promotions on tv, etc.)
I guess for all things mentioned, you could record the numbers automatically, like every week and then create graphs and check the trend.
This should give you a quite good indication of how a team performs over time and to changes, for example, if a lot of new members join or if the workload is increasing.
If your company records over hours you should add these too, so you might see that the performance goes down if there are too many.