Repository-Metriken

Reaktionsfähigkeit

Wie inspect.software die Reaktionsfähigkeit misst — Quoten der Issue-Erledigung und Pull-Request-Annahme über die Lebenszeit eines Projekts. 6% des Gesamtindex.

Methodik v1.13.0Aktualisiert 2026-07-13

Reaktionsfähigkeit misst, ob die bei einem Projekt eingehende Arbeit — Fehlerberichte, Funktionswünsche, beigesteuerte Patches — tatsächlich bearbeitet wird. Ein Issue-Tracker, in dem sich unbeantwortete Meldungen ansammeln, oder eine Warteschlange von Pull Requests, die ohne Auseinandersetzung geschlossen werden, sagt die Erfahrung voraus, die jeder künftige Nutzer und Beitragende machen wird.

  • Kategorie: Nachhaltigkeit & Governance (25% innerhalb der Kategorie)
  • Gewicht im Gesamtindex: 6,0%
  • Metrikschlüssel: responsiveness
  • null, wenn das Repository keine Issues und keine entschiedenen Pull Requests hat

Wie der Wert berechnet wird

KomponenteGewichtKriterien
Issue-Erledigung46,75Verhältnis geschlossener zu allen Issues × 46,75
PR-Annahme38,25merged / (merged + closed unmerged) × 38.25
OpenSSF Scorecard: Code-Review15Scorecard-Ergebnis 0–10, skaliert auf 15 Punkte

Die Zählungen sind Lebenszeitsummen. Latenz-Perzentile — wie schnell Issues und Pull Requests entschieden werden, über ein jüngeres Zeitfenster — stehen auf der veröffentlichten Methodik-Roadmap und kommen mit einer Versionserhöhung (siehe Methodikversionen).

Code-Review ist ergänzende geteilte Evidenz: Es prüft Freigaben auf Änderungssätzen, während die PR-Annahme Merge-Ergebnisse misst. Es bleibt eine Sicherheitskomponente und wird hier ausgeschlossen, wenn Scorecard nicht verfügbar ist oder n/a meldet.

Was die beiden Quoten bedeuten

  • Issue-Erledigung liest den Anteil der eingereichten Issues, die eine Entscheidung erreicht haben. Projekte, die ehrlich triagieren — beheben, beantworten oder mit Begründung schließen —, lesen sich gut; Projekte, in denen sich Issues stillschweigend stapeln, lesen sich niedrig.
  • PR-Annahme liest, was mit beigesteuertem Code unter den Pull Requests geschieht, die eine Entscheidung erreicht haben. Ein sehr niedriger Merge-Anteil kennzeichnet häufig ein Projekt, das Beiträge erhält, sie aber nicht aufnehmen kann oder will.

Das Ergebnis lesen

  • Schließen ist Entscheiden. Die Metrik verlangt nicht, dass jedes Issue behoben wird — ein begründetes „wontfix" ist eine Entscheidung. Bestraft wird unbegrenztes Anhäufen.
  • Lebenszeitquoten bewegen sich langsam. Ein Projekt, das seine Triage kürzlich verbessert hat, sieht diese Metrik nur allmählich erholen; die zeitfensterbasierten Latenzmessungen der Roadmap werden jüngeres Verhalten sichtbarer machen.
  • Repositories mit deaktivierten Issues und ohne PR-Historie sind hier null, mit renormalisierten Gewichten — siehe der Gesundheitsindex.

Den Wert verbessern

  • Nach Plan triagieren: veraltete Meldungen etikettieren, beantworten und mit angegebenem Grund schließen, statt sie unbegrenzt offen zu lassen.
  • Pull Requests in beide Richtungen entscheiden — gute zu mergen und ungeeignete ausdrücklich abzulehnen zählt beides als Trägerschaft.
  • Vorlagen aus der Community-Gesundheit heben die Qualität eingehender Beiträge und machen dauerhafte Triage günstiger.

Verwandt: Maintainer-Resilienz · Nachhaltigkeit & Governance

Von inspect.software veröffentlichte Ergebnisse sind Signale, keine Garantien — siehe wie sie zu lesen sind. Die vollständige Methodik ist versioniert und öffentlich: Methodik v1.13.0.