To answer the question on use case: as an eng leader overseeing a large team or multiple teams, I would use this purely as an internal pulse-check, and that's it. Bringing these datapoints into a single place can help determine places to dig in, such as:
Are we auto-shipping PRs without diligent review/code comments?. Are senior engineers putting enough time/effort into PR review? Are there a subset of engineers carrying the team in terms of PR feedback? Does a junior engineer's progress align with status updates Are we shipping PRs in reasonable sizes? We just finished planning and are moving into build cycle, are product requirements allowing devs to start building as expected?
None of this email content is meant to be source-of-truth, but instead a signal/pulse-check.
I do agree with a lot of the feedback on worry about how this data is used — e.g. commit count != productivity. That said, a good manager is not going to mis-use this data and your poor manager is already a poor manager without it.
My team and I have actually been looking for something like this. Not to judge engineers productivity but to understand workload imbalances. For example, say we notice 2-3 people are doing all the PR reviews (something I think we could detect with this). Maybe the other engineers need training on PRs or we need to set expectations that everyone reviews PRs or maybe our PR load balancer isn't set up correctly.
So, good work and good luck. I'll definitely be showing this to my team. Thanks for sharing this with everyone!
I tried GitInsight and wanted to share my feedback. Recorded a 5 min feedback video.
https://www.loom.com/share/0fb4b5ec2f2744ed9f1239601f43f185?...
I hope you find it useful and if you don't please disregard the video.
Congrats on launch and happy building!!