Repository metrics

Responsiveness

How inspect.software measures responsiveness — issue resolution and pull-request acceptance rates over a project's lifetime. 6% of the overall index.

Methodology v1.13.0Updated 2026-07-13

Responsiveness measures whether the work arriving at a project — bug reports, feature requests, contributed patches — actually gets handled. An issue tracker where reports accumulate unanswered, or a queue of pull requests closed without engagement, predicts the experience every future user and contributor will have.

  • Category: Sustainability & Governance (25% within category)
  • Weight in overall index: 6.0%
  • Metric key: responsiveness
  • null when the repository has no issues and no decided pull requests

How the value is computed

ComponentWeightCriteria
Issue resolution46.75ratio of closed to total issues × 46.75
PR acceptance38.25merged / (merged + closed unmerged) × 38.25
OpenSSF Scorecard: Code-Review15Scorecard's 0–10 result, scaled to 15 points

Counts are lifetime totals. Latency percentiles — how fast issues and pull requests are decided, over a recent window — are on the published methodology roadmap and will arrive with a version bump (see methodology versions).

Code-Review is complementary shared evidence: it checks approvals on changesets, whereas PR acceptance measures merge outcomes. It remains a Security component and is excluded here if Scorecard is unavailable or n/a.

What the two ratios mean

  • Issue resolution reads the fraction of filed issues that reached a decision. Projects that triage honestly — fixing, answering, or closing with a reason — read well; projects where issues silently pile up read low.
  • PR acceptance reads what happens to contributed code among pull requests that reached a decision. A very low merge share often marks a project that receives contributions but cannot or will not absorb them.

Reading the result

  • Closing is deciding. The metric does not require that every issue be fixed — a maintained "wontfix" is a decision. What it penalizes is unbounded accumulation.
  • Lifetime ratios move slowly. A project that recently improved its triage will see this metric recover gradually; the roadmap's time-windowed latency measures will make recent behavior more visible.
  • Repositories with issues disabled and no PR history are null here, with weights renormalized — see the health index.

Improving the value

  • Triage on a schedule: label, answer, and close stale reports with a stated reason rather than leaving them open indefinitely.
  • Decide pull requests both ways — merging good ones and explicitly declining unsuitable ones both count as stewardship.
  • Templates from community health raise incoming quality and make sustained triage cheaper.

Related: maintainer resilience · Sustainability & Governance