Just because it can be measured, doesn't mean it should be.
These 'measures' would be much more useful if they were used to determine the control limits of the software process being used.
'hours from pull request to merge' for an open source project is silly. who cares? 'number of commits a month'? who cares. what is the value of those commits.
why the focus on 'constant churn of software'? I don't see it.
I get where you're coming from, and can see a lot of people seeing it that way.
But to me, metrics like 'PR to merge time' help highlight bottlenecks, even in open source. It’s not just about churn, it’s about ensuring contributions are flowing smoothly. Quality matters, but so does making sure contributions don’t stall.
Do you think lead time as a concept matters so much in open source repos? As in, if a contributor feels like contributing they will otherwise not. Because there's no accountability, the lead time becomes pointless - wdyt?
Good point, but I’d say lead time still matters. Even in open source, slow responses can kill motivation. Quick feedback keeps contributors engaged and makes the project feel more active.
And I don't understand how to correlate your Dep. frequency here with PR merges. There's one point where the project might build vs considering every PR merge as a deployment. Don't you think that would shake the metrics rating for this repo as per your assessment?
We track PR merges as potential deployments to measure flow and efficiency, even if not every merge triggers an immediate deploy. It’s more about tracking how fast the code moves through the pipeline.
I guess another way to think about lead time in open source might be to gauge the overall project health: more active and engaged community that is. What do you think??
Just because it can be measured, doesn't mean it should be.
These 'measures' would be much more useful if they were used to determine the control limits of the software process being used.
'hours from pull request to merge' for an open source project is silly. who cares? 'number of commits a month'? who cares. what is the value of those commits.
why the focus on 'constant churn of software'? I don't see it.
I get where you're coming from, and can see a lot of people seeing it that way.
But to me, metrics like 'PR to merge time' help highlight bottlenecks, even in open source. It’s not just about churn, it’s about ensuring contributions are flowing smoothly. Quality matters, but so does making sure contributions don’t stall.
Do you think lead time as a concept matters so much in open source repos? As in, if a contributor feels like contributing they will otherwise not. Because there's no accountability, the lead time becomes pointless - wdyt?
Good point, but I’d say lead time still matters. Even in open source, slow responses can kill motivation. Quick feedback keeps contributors engaged and makes the project feel more active.
hmm.. ok
And I don't understand how to correlate your Dep. frequency here with PR merges. There's one point where the project might build vs considering every PR merge as a deployment. Don't you think that would shake the metrics rating for this repo as per your assessment?
We track PR merges as potential deployments to measure flow and efficiency, even if not every merge triggers an immediate deploy. It’s more about tracking how fast the code moves through the pipeline.
I guess another way to think about lead time in open source might be to gauge the overall project health: more active and engaged community that is. What do you think??