I think the "side project" framing actually makes this problem more solvable, because you don't have to completely solve every aspect of the problem. It seems

I think the "side project" framing actually makes this problem more solvable, because you don't have to completely solve every aspect of the problem. It seems likely that developing an easy to measure metric would start to help the issue, which is what Pioneer may be looking for. E.G., measure the productivity of repo owners (managers/leads) by their lag in accepting pull requests. Measure the quality of submitted code by comparing how often my code is accepted compared to someone else's (w/in the organization/language/community). From there you could build more of a productivity measurement suite, e.g. maybe connect test coverage and bug reports to specific commits and start to score a coder. Basically, look at currently-existing data points about coders that a specific team culture believes are important to productivity. Then baseline that against a comparable group, and present reports. Another trick is to simply measure stuff over time. (This is a bit trickier, due to what you hinted at w/ LOC... but still measures change over time, which is really useful for managers.) The final thought I have is that it is useful to connect events over time that are related to the same code/feature/branch. If my team's workflow is design/develop/test/commit....gap....deploy to users, then bugs are temporally disconnected from development efforts. Connect things over time in an easy to use report, that has value.