# Responsiveness

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


**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](/wiki/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

| Component | Weight | Criteria |
| --------- | ------ | -------- |
| Issue resolution | 46.75 | ratio of closed to total issues × 46.75 |
| PR acceptance | 38.25 | `merged / (merged + closed unmerged) × 38.25` |
| OpenSSF Scorecard: Code-Review | 15 | Scorecard'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](/wiki/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](/wiki/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](/wiki/community-health) raise incoming
  quality and make sustained triage cheaper.

Related: [maintainer resilience](/wiki/maintainer-resilience) ·
[Sustainability & Governance](/wiki/sustainability-governance)