Community-Gesundheit misst, ob ein Repository darauf eingerichtet ist, Nutzer und Beitragende zu empfangen: die Standarddateien, die Neuankömmlingen sagen, was das Projekt ist, zu welchen Bedingungen es genutzt werden darf und wie man teilnimmt. Diese Dateien sind der Unterschied zwischen einer Codebasis und einer Community.
- Kategorie: Community & Verbreitung (35% innerhalb der Kategorie)
- Gewicht im Gesamtindex: 6,3%
- Metrikschlüssel:
community_health
Wie der Wert berechnet wird
Eine gewichtete Checkliste der Standarddateien, jeweils vorhanden oder fehlend (die Lizenz-Zeile kann auch Teilpunkte erhalten — siehe unten):
| Komponente | Gewicht |
|---|---|
| README | 22,5 |
| Lizenz | 22,5 |
| CONTRIBUTING-Leitfaden | 18 |
| Verhaltenskodex | 13,5 |
| Issue-Vorlage | 7,2 |
| PR-Vorlage | 6,3 |
Wie die Lizenz erkannt wird
Die Lizenzpräsenz wird einmal geprüft, aus drei gemeinsam betrachteten Quellen: den Lizenz-Metadaten des Repositorys selbst, dem Community-Profil von GitHub und dem veröffentlichten, werkzeugneutralen License-Check der OpenSSF Scorecard. Eine Datei, die irgendeine Quelle erkennt, gilt als vorhanden — die Quellen weichen bei rund 1% der Repositories voneinander ab, und ein einzelner nicht verfügbarer Endpunkt darf eine Lizenz nicht als fehlend ausweisen.
Das Ergebnis ist einer von drei Zuständen:
| Zustand | Bedeutung | Anrechnung |
|---|---|---|
| Standard | Eine anerkannte Lizenz, identifiziert über den SPDX-Code | 22,5 |
| Eigen | Eine Lizenzdatei ist vorhanden, ihr Text ist jedoch keine anerkannte Lizenz | 16,9 |
| Keine | Keine Quelle hat eine Lizenzdatei gefunden | 0 |
Eine eigene Lizenz ist eine echte Lizenz und erhält den größten Teil des Gewichts. Sie erhält nicht das gesamte Gewicht: Eine Lizenz, die automatisierte Werkzeuge nicht identifizieren können, ist ein tatsächliches Hindernis für die Übernahme, denn Policy-Werkzeuge, unternehmensinterne Prüfungen und Paket-Registries stützen sich sämtlich auf anerkannte Kennungen, und ohne eigene Lektüre des Textes lässt sich nicht feststellen, was erlaubt ist. GitHub weist diesen Fall als NOASSERTION aus — eine gefundene, aber nicht klassifizierbare Lizenz, was nicht dasselbe ist wie gar keine Lizenz.
Das Scorecard-Ergebnis bleibt eine Komponente der Metrik Sicherheitslage; hier ist es einer von drei Eingangswerten und wird schlicht als License ausgewiesen.
Warum diese Dateien Gewicht tragen
- README und Lizenz sind tragend. Ein Repository ohne README ist nicht übernehmbar; ein Repository ohne Lizenz ist in den meisten Organisationen rechtlich unbenutzbar — keine nachgelagerte Rechtsabteilung wird eine Abhängigkeit freigeben, deren Bedingungen undefiniert sind. Zusammen tragen sie die Hälfte der Metrik.
- CONTRIBUTING und ein Verhaltenskodex wandeln beiläufiges Interesse in dauerhafte Teilnahme um, was direkt in die Kontinuität einfließt, die die Maintainer-Resilienz misst.
- Vorlagen heben die Signalqualität eingehender Issues und Pull Requests und senken die Triage-Last der Maintainer — ein kleiner, aber realer Faktor für die Reaktionsfähigkeit, die ein Projekt aufrechterhalten kann.
Das Ergebnis lesen
- Die Checkliste ist größenunabhängig: Ein eine Woche altes Projekt kann 100 erreichen, bevor es seinen ersten Star hat, und ein berühmtes Projekt ohne Lizenz liest sich sichtbar unvollständig. Das ist beabsichtigt — diese Metrik misst Vorbereitung, nicht Zugkraft.
- Verifiziert wird die Präsenz, nicht die Prosaqualität — siehe den Hinweis zur Ehrlichkeit der Messung in Signale, keine Garantien.
Den Wert verbessern
Jede Komponente ist innerhalb einer Stunde direkt umsetzbar:
- Ein README schreiben, das abdeckt, was das Projekt tut, wie es installiert wird, und ein minimales Beispiel enthält.
- Eine
LICENSE-Datei mit einer anerkannten SPDX-Lizenz ergänzen. CONTRIBUTING.md, eineCODE_OF_CONDUCT.mdund Issue-/PR-Vorlagen unter.github/ergänzen.
Dies ist typischerweise die am schnellsten zu bewegende Metrik der gesamten Methodik.
Verwandt: Community & Verbreitung · Dokumentation