> How about starting with mean time to merge a code change? I'm currently experimenting with using "Mode time" as I think it is less susceptible to data skew f

> How about starting with mean time to merge a code change? I'm currently experimenting with using "Mode time" as I think it is less susceptible to data skew from outliers. See example below: https://oss.gitsense.com/insights/github?p=days-open&q=days-closed%3A%3C%3D28%2Bmerged%3Atrue%2Bpull-age%3A%3C%3D120&t=crc-insights&tb=closed&v=cockroachdb%2Fcockroach%20----%20elastic%2Felasticsearch%20----%20microsoft%2Fvscode%20----%20prestodb%2Fpresto%20----%20sourcegraph%2Fsourcegraph%3A%3Agithub%3Acockroachdb%2Fcockroach%2Cgithub%3Aelastic%2Felasticsearch%2Cgithub%3Amicrosoft%2Fvscode%2Cgithub%3Aprestodb%2Fpresto%2Cgithub%3Asourcegraph%2Fsourcegraph%3A%3A%3A%3A%3A%3A1646157992581 https://oss.gitsense.com/insights/github?p=days-open&q=days-... For popular open-source projects that I used in the link above, the Mode time to merge is less than a day which is quite good in my opinion. And as you can expect, if you look at larger pull requests (>=10 file changes) the overall percentage drops by half as the link below shows: https://oss.gitsense.com/insights/github?p=days-open&q=pull-age%3A%3C%3D120%2Bmerged%3Atrue%2Bdays-closed%3A%3C%3D28%2Bfiles%3A%3E10&t=crc-insights&tb=closed&v=cockroachdb%2Fcockroach%20----%20elastic%2Felasticsearch%20----%20microsoft%2Fvscode%20----%20prestodb%2Fpresto%20----%20sourcegraph%2Fsourcegraph%3A%3Agithub%3Acockroachdb%2Fcockroach%2Cgithub%3Aelastic%2Felasticsearch%2Cgithub%3Amicrosoft%2Fvscode%2Cgithub%3Aprestodb%2Fpresto%2Cgithub%3Asourcegraph%2Fsourcegraph%3A%3A%3A%3A%3A%3A1646157992581 https://oss.gitsense.com/insights/github?p=days-open&q=pull-... I think what the link above shows is, you can't just willy-nilly use merge time to measure productivity, since there are a multiple variables at play. Full disclosure: The link that I referenced is my tool