But number of commits is a horrible way to infer seniority. Unless you value "frequency of checkpointing changes" above all else. You get what you measure, so I suspect OP is going to get a lot of small commits in the future.
But number of commits is a horrible way to infer seniority. Unless you value "frequency of checkpointing changes" above all else. You get what you measure, so I suspect OP is going to get a lot of small commits in the future.
The reason it works is that people write commit message like "Fix X for ACME Corp", and the project leads tend to work on the project for the most calendar time - they may not have the most commits if they have to attend meetings, but after a project/release "finishes", one person ends up sticking around for a while to handle any issues that come up. That naturally gives them some small commits.
To me the risk to me is that this may not generalize, since different projects/products are run in varying ways.
I could imagine search with some standards (commit message format, branch/rebase strategies, requiring an associated tickets) would be really effective, though not so much the general case. Hope you can share in a follow up post if you find ways to deal work around these problems.
I have some material for a couple follow-ups to this, so stay tuned - dealing with code separate from natural language text is an interesting topic as well.