# Responsiveness

> How inspect.software measures responsiveness — issue resolution, lifetime pull-request acceptance, and how a project treats first-time contributors. 5.75% 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:** 5.75%
- **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 | 42 | ratio of closed to total issues × 42 |
| PR acceptance | 30 | `merged / (merged + closed unmerged) × 30` |
| Newcomer PR acceptance | 13 | merged share of the pull requests decided in the last 30 days whose author had no previously merged pull request here |
| OpenSSF Scorecard: Code-Review | 15 | Scorecard's 0–10 result, scaled to 15 points |

The first two counts are lifetime totals. Newcomer PR acceptance reads a
30-day window instead; it excludes bot-authored pull requests, and it is
excluded itself — with the remaining weights renormalized — when no first-time
contributor's pull request was decided in that window. It appears only on
reports produced under methodology 2.1.0 or later (see
[methodology versions](/wiki/methodology-versions)). Latency percentiles —
*how fast* issues and pull requests are decided — remain on the published
roadmap.

`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 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.
- **Newcomer PR acceptance** reads the same outcome for authors with no
  previously merged pull request in the repository. A project can be quick and
  generous with its regulars and merge nothing arriving from outside that
  circle; the two rates come apart often enough that only this one describes
  what a first-time contributor should expect.

## 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.
- **A window with no newcomers is not a low score.** Nobody knocking is not
  the same fact as nobody being let in, and only the second is the project's
  own doing, so the component is excluded rather than scored as zero. The
  denominator is newcomers' *decided* pull requests, not their share of all
  merges: a mature project where regulars land most of the work is not marked
  down for having regulars.
- 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)
