Dies ist die mehrseitige Druckansicht dieses Abschnitts. .
Triage
1 - Richtlinien zur Issue-Triage
Zweck
Die Verwaltung von Issues beschleunigen.
Die Issues für etcd sind unter https://github.com/etcd-io/etcd/issues
aufgeführt
und werden mit Labels gekennzeichnet. Ein als Fehler erkanntes Issue erhält beispielsweise das Label area/bug . Neue Issues haben zunächst keine Labels; üblicherweise ergänzen die Maintainer und aktiven Mitwirkenden von etcd sie anhand ihrer Erkenntnisse. Die vollständige Liste der Labels steht unter
https://github.com/kubernetes/kubernetes/labels
Hier einige praktische vordefinierte Suchen nach Issues:
Geltungsbereich
Diese Richtlinien dienen als grundlegendes Dokument zur Sichtung und Einordnung neuer Issues in etcd. Alle sind eingeladen, bei der Verwaltung von Issues und PRs mitzuhelfen. Die hier beschriebenen Arbeiten und Verantwortlichkeiten richten sich jedoch an die Maintainer und aktiven Mitwirkenden von etcd.
Prüfen, ob ein Issue einen Fehler beschreibt
Prüfen, ob tatsächlich ein Fehler vorliegt. Falls nicht, die Erkenntnisse in einem Kommentar festhalten und triviale Issues schließen. Bei nicht trivialen Issues die Rückmeldung der meldenden Person abwarten, um mögliche Einwände zu berücksichtigen. Antwortet sie innerhalb von 30 Tagen nicht, das Issue schließen. Lässt sich das Problem nicht reproduzieren oder werden weitere Informationen benötigt, einen Kommentar für die meldende Person hinterlassen.
Inaktive Issues
Issues mit unzureichenden Angaben sollten geschlossen werden, wenn die meldende Person innerhalb von 60 Tagen keine Informationen nachliefert.
Doppelte Issues
Bei einem doppelten Issue einen entsprechenden Kommentar mit einem Verweis auf das ursprüngliche Issue hinterlassen und das Duplikat schließen.
Issues außerhalb von etcd
Manche gemeldeten Issues betreffen tatsächlich andere Projekte, die etcd verwendet, etwa grpc oder golang. In solchen Fällen sollte die meldende Person gebeten werden, ein Issue im zuständigen Projekt zu eröffnen. Das Issue schließen, sofern nicht ein Maintainer und die meldende Person es zur Nachverfolgung offen halten möchten.
Wichtige Labels prüfen
Sicherstellen, dass das Issue Labels für die betroffenen Bereiche hat, geeignete Verantwortliche zugewiesen sind und ein Meilenstein festgelegt ist. Fehlende Labels ergänzen. Lassen sich Labels wegen fehlender Berechtigungen nicht zuweisen oder lässt sich das richtige Label nicht bestimmen, ist das in Ordnung; bei Bedarf die Maintainer kontaktieren.
Bei Bedarf die verantwortliche Person erinnern
Wenn für ein von einem Entwickler übernommenes Issue innerhalb von 30 Tagen kein PR erstellt wurde, die verantwortliche Person kontaktieren und sie bei Bedarf bitten, einen PR zu erstellen oder die Zuständigkeit freizugeben.
2 - PR-Verwaltung
Zweck
Die PR-Verwaltung beschleunigen.
Die PRs für etcd sind unter https://github.com/etcd-io/etcd/pulls
aufgeführt.
Ein PR kann verschiedene Labels, einen Meilenstein, Reviewer usw. haben. Die vollständige Liste der Labels steht unter
https://github.com/kubernetes/kubernetes/labels
Hier einige praktische Suchbeispiele für PRs:
Geltungsbereich
Diese Richtlinien dienen als grundlegendes Dokument zur Verwaltung von PRs in etcd. Alle sind eingeladen, bei der PR-Verwaltung mitzuhelfen. Die hier beschriebenen Arbeiten und Verantwortlichkeiten richten sich jedoch an die Maintainer und aktiven Mitwirkenden von etcd.
Inaktive PRs bearbeiten
Die verantwortliche Person für den PR erinnern, wenn Review-Kommentare innerhalb von 15 Tagen nicht bearbeitet wurden. Antwortet sie innerhalb von 90 Tagen nicht, den PR nach Möglichkeit mit einem neuen Commit aktualisieren. Ist das nicht möglich, sollte der inaktive PR nach 180 Tagen geschlossen werden.
Bei Bedarf Reviewer erinnern
Reviewer reagieren zeitnah. Da alle viel zu tun haben, nach einer Review-Anfrage jedoch etwas Zeit lassen, falls keine schnelle Antwort kommt. Bleibt die Antwort 10 Tage lang aus, können sie durch einen Kommentar im PR, eine E-Mail oder eine Slack-Nachricht kontaktiert werden.
Wichtige Labels prüfen
Sicherstellen, dass dem PR geeignete Reviewer zugewiesen sind und ein Meilenstein festgelegt ist. Fehlende Zuweisungen oder andere wichtige Labels ergänzen. Lässt sich das richtige Label nicht bestimmen, einen Kommentar hinterlassen, damit die Maintainer es bei Bedarf festlegen können.