[nshntarora]

This is a nice idea, and amazing execution on this. Really excited to see how this picks up.

But here are my concerns with the Git contributions to reward performance.

A company I interned at installed a Git history analysis tool, and used stats from that in 1:1s and performance reviews.

About a month after I joined, I had one such 1:1 with my manager. He was like, "Congratulations! You made 53% of all contributions to frontend last month. You're our star performer."

I wasn't. I was responsible for upgrading our frontend from React 15 to React 16. Most of the changes that happened were thanks to the Codemod, and a lot of find / replace magic.

[protontypes]

A very good point. Solving the problem that you describe is one of the core challenges of LibreSelery. We combine multiple weights calculated based on different project data. Via the GitHub API we can even create weights based on projects activity like merging, code review, issue creation, etc...

By the accumulation of multiple weights, we try to avoid rewarding just one behavior. One of the most important metrics will be how much pull requests X have been solved based on the Y issues. We also have a minimum contribution limit that you can adjust for your project. Generally, all weights can be adjusted for each project. By making all payments transparent, everyone involved can see what the distribution looked like in the past. In principle, every company has metrics for the distribution of funds. Unfortunately, these are often very non-transparent. In contrast, we try to solve the whole thing by combining different transparent movement quantities.

You can find more information about this issue here:

https://github.com/protontypes/libreselery/issues/132 https://github.com/protontypes/libreselery/issues/159