Change Request Metric Revision

[geekygirldawn]

The Starter Viability Model, talks about some of the reasons to care about change requests that aren't reflected in the actual Change Request metric.

Projects with very low count of change requests are unlikely to be keeping up with security updates – or with trends for development in their ecosystem. Change requests with high spikes of activity might also indicate that a project doesn’t provide sufficient checks to avoid unnecessary revisions/toil around the same feature.

I think we should tweak the Objective / Description to add these ideas, but I know we are in the process of reformatting our metrics using a new template, and I didn't want to interfere with that work. I'm happy to propose these changes if that would be helpful (if so, I just need to know where we landed on the new template) :)

[geekygirldawn]

Note: I've added this to the agenda for the metrics dev WG meeting on May 23.

[sgoggins]

The implication seems to more clearly be to address whether or not there are change requests accepted. Bots for security can open a lot of PRs that are never closed or merged. So, there's the "absence of a bot" condition, as well as the "failure to incorporate bot based security questions. https://github.com/sgoggins/wg-evolution/blob/main/focus-areas/code-development-efficiency/change-request-acceptance-ratio.md

[sgoggins]

From 8/1/2024 Metrics WG Meeting ^