Reaktionsfähigkeit

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: 5,75%
• Metrikschlüssel: responsiveness
• null, wenn das Repository keine Issues und keine entschiedenen Pull Requests hat

Wie der Wert berechnet wird

Die ersten beiden Zählungen sind Lebenszeitsummen. Die Annahme von Erstbeiträgen liest stattdessen ein Zeitfenster von 30 Tagen; sie schließt von Automatisierung verfasste Pull Requests aus und wird selbst ausgeschlossen — mit renormalisierten übrigen Gewichten —, wenn in diesem Zeitfenster kein Pull Request eines Erstbeitragenden entschieden wurde. Sie erscheint nur in Berichten, die unter Methodik 2.1.0 oder später erstellt wurden (siehe Methodikversionen). Latenz-Perzentile — wie schnell Issues und Pull Requests entschieden werden — bleiben auf der veröffentlichten Roadmap.

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 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.
• Annahme von Erstbeiträgen liest dasselbe Ergebnis für Verfasser, die zuvor keinen gemergten Pull Request im Repository hatten. Ein Projekt kann mit seinen Stammbeitragenden zügig und großzügig umgehen und nichts von außerhalb dieses Kreises aufnehmen; die beiden Quoten fallen häufig genug auseinander, dass nur diese beschreibt, was Erstbeitragende erwarten dürfen.

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.
• Ein Zeitfenster ohne Erstbeitragende ist keine niedrige Bewertung. Dass niemand anklopft, ist nicht dieselbe Tatsache wie dass niemand eingelassen wird, und nur die zweite geht auf das Projekt selbst zurück; die Komponente wird daher ausgeschlossen statt mit null bewertet. Der Nenner sind die entschiedenen Pull Requests der Erstbeitragenden und nicht ihr Anteil an allen Merges: Ein reifes Projekt, in dem Stammbeitragende den Großteil der Arbeit landen, wird nicht dafür abgewertet, Stammbeitragende zu haben.
• 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