Bug Triaging und Issue Curation #

Der Issue Tracker ist wichtig für die Kommunikation im Projekt, da er als zentraler Ort dient, um Funktionsanfragen zu stellen, Fehler zu melden, wichtige Projekte zu identifizieren, an denen gearbeitet werden muss, und Prioritäten zu diskutieren. Aus diesem Grund ist es wichtig, die Issue-Liste zu kuratieren, Issues mit Labels zu versehen und gelöste oder unlösbare Issues zu schließen.

Das Sichten von Problemen erfordert kein besonderes Fachwissen in den Interna von Matplotlib, ist für das Projekt äußerst wertvoll, und wir begrüßen jeden, der sich an der Problemsichtung beteiligt! Personen, die nicht Teil der Matplotlib-Organisation sind, haben jedoch keine Berechtigung, Meilensteine zu ändern, Labels hinzuzufügen oder ein Problem zu schließen . Wenn Sie nicht über genügend GitHub-Berechtigungen verfügen, um etwas zu tun (z. B. ein Label hinzufügen, ein Problem schließen), hinterlassen Sie bitte einen Kommentar @matplotlib/triageteammit Ihren Empfehlungen!

An Problemen arbeiten, um sie zu verbessern #

Die Verbesserung von Problemen erhöht ihre Chancen, erfolgreich gelöst zu werden. Richtlinien zum Einreichen guter Ausgaben finden Sie hier . Ein Dritter kann nützliches Feedback geben oder sogar Kommentare zu dem Problem hinzufügen. Die folgenden Aktionen sind normalerweise nützlich:

Dokumentieren von Problemen, bei denen Elemente fehlen, um das Problem zu reproduzieren, z. B. Codebeispiele

Vorschlag einer besseren Verwendung der Codeformatierung (z. B. dreifache Backticks im Markdown).

Vorschlag, den Titel und die Beschreibung neu zu formulieren, um das zu lösende Problem deutlicher zu machen

Links zu verwandten Themen oder Diskussionen, während kurz beschrieben wird, wie sie zusammenhängen, z. B. „Siehe auch #xyz für einen ähnlichen Versuch“ oder „Siehe auch #xyz, wo dasselbe gemeldet wurde“, bietet Kontext und hilft bei der Diskussion

überprüfen, ob das Problem reproduzierbar ist

klassifizieren Sie das Problem als Feature-Request, langjährigen Bug oder Regression

Triage-Team #

Wenn Sie dem Triage-Team beitreten möchten:

Triage 2-3 Probleme richtig.
Bitten Sie jemanden aus dem Triage-Team (öffentlich oder privat), Sie dem Triage-Team zu empfehlen . Wenn Sie mit jemandem an dem triagierten Problem gearbeitet haben, wäre er eine gute Person, die Sie fragen könnten.
Üben Sie Ihre neue Kraft verantwortungsvoll aus!

Jeder mit Commit- oder Triage-Rechten kann auch einen Benutzer nominieren, der eingeladen wird, dem Triage-Team beizutreten.

Sichtungsoperationen für Mitglieder des Kern- und Sichtungsteams #

Darüber hinaus können Mitglieder des Kernteams und des Triage-Teams die folgenden wichtigen Aufgaben übernehmen:

Labels für Issues und PRs aktualisieren: Siehe die Liste der verfügbaren Github-Labels .
Triage-Probleme:
- Reproduzieren Sie das Problem , wenn der gepostete Code ein Fehler ist, kennzeichnen Sie das Problem mit "Status: bestätigter Fehler".
- Regressionen identifizieren , feststellen, ob der gemeldete Fehler in einer neueren Version von Matplotlib wie erwartet funktioniert hat, und wenn ja, die letzte funktionierende Version bestimmen. Regressionen sollten für das nächste Bugfix-Release als Meilenstein festgelegt werden und können als „Release kritisch“ gekennzeichnet werden.
- Schließen Sie Nutzungsfragen und weisen Sie den Reporter höflich darauf hin, stattdessen Diskurs oder Stack Overflow zu verwenden und als "Community-Unterstützung" zu kennzeichnen.
- Schließen Sie doppelte Ausgaben , nachdem Sie überprüft haben, ob es sich tatsächlich um Duplikate handelt. Idealerweise verschiebt der ursprüngliche Einsender die Diskussion in das ältere, doppelte Problem
- Schließen Sie Probleme, die nicht repliziert werden können , nachdem Sie Zeit (mindestens eine Woche) gelassen haben, um zusätzliche Informationen hinzuzufügen

Ein typischer Arbeitsablauf zum Sichten von Problemen #

Der folgende Arbeitsablauf [ 1 ] ist ein guter Weg, um die Problemsichtung anzugehen:

Danke dem Reporter, dass er ein Problem eröffnet hat

Der Issue-Tracker ist für viele Menschen die erste Interaktion mit dem Matplotlib-Projekt selbst, über die einfache Verwendung der Bibliothek hinaus. Daher möchten wir, dass es eine einladende, angenehme Erfahrung ist.
Ist das eine Nutzungsfrage? Wenn ja, schließen Sie es mit einer höflichen Nachricht ab.
Werden die notwendigen Informationen bereitgestellt?

Überprüfen Sie, ob der Poster die Ausgabevorlage ausgefüllt hat. Wenn wichtige Informationen (die Version von Python, die verwendete Version von Matplotlib, das Betriebssystem und das Backend) fehlen, bitten Sie den ursprünglichen Poster höflich, die Informationen bereitzustellen.
Ist das Problem minimal und reproduzierbar?

Bei Fehlerberichten bitten wir den Melder, ein reproduzierbares Minimalbeispiel bereitzustellen. Siehe diesen nützlichen Beitrag von Matthew Rocklin für eine gute Erklärung. Wenn das Beispiel nicht reproduzierbar oder eindeutig nicht minimal ist, können Sie den Reporter gerne fragen, ob er ein Beispiel liefern oder das bereitgestellte vereinfachen kann. Erkenne an, dass das Schreiben von minimal reproduzierbaren Beispielen harte Arbeit ist. Wenn der Reporter Probleme hat, können Sie versuchen, selbst einen zu schreiben.

Wenn ein reproduzierbares Beispiel bereitgestellt wird, Sie aber eine Vereinfachung sehen, fügen Sie Ihr einfacheres reproduzierbares Beispiel hinzu.

Wenn Sie das Problem nicht reproduzieren können, melden Sie dies bitte zusammen mit Ihren Betriebssystem-, Python- und Matplotlib-Versionen.

Wenn wir weitere Informationen aus diesem oder dem vorherigen Schritt benötigen, kennzeichnen Sie das Problem bitte mit "Status: Klärung erforderlich".
Ist das ein Rückfall?

Während wir uns um eine fehlerfreie Bibliothek bemühen, haben Regressionen höchste Priorität. Wenn wir fehlerhaften Benutzercode haben, der früher funktioniert hat, sollten wir das im nächsten Patch-Release beheben!

Versuchen Sie festzustellen, wann die Regression aufgetreten ist, indem Sie den Reproduktionscode mit älteren Versionen von Matplotlib ausführen. Dies kann durch veröffentlichte Versionen von Matplotlib erfolgen (um die Version zu erhalten, in der es zuletzt funktioniert hat) oder indem Sie git bisect verwenden , um das erste Commit zu finden, bei dem es beschädigt wurde.
Ist dies ein doppeltes Problem?

Wir haben viele offene Fragen. Wenn eine neue Ausgabe ein Duplikat zu sein scheint, zeigen Sie auf die ursprüngliche Ausgabe. Wenn es sich um ein eindeutiges Duplikat handelt oder der Konsens besteht, dass es redundant ist, schließen Sie es. Stellen Sie sicher, dass Sie dem Reporter trotzdem danken und ihn ermutigen, sich auf das ursprüngliche Problem einzulassen und vielleicht zu versuchen, es zu beheben.

Wenn das neue Problem relevante Informationen enthält, z. B. ein besseres oder etwas anderes Beispiel, fügen Sie es dem ursprünglichen Problem als Kommentar hinzu oder bearbeiten Sie den ursprünglichen Beitrag.

Beschriften Sie das geschlossene Problem mit "Status: Duplikat".
Stellen Sie sicher, dass der Titel das Problem genau widerspiegelt. Wenn Sie die erforderlichen Berechtigungen haben, bearbeiten Sie es selbst, wenn es nicht klar ist.
Fügen Sie die relevanten Bezeichnungen hinzu, z. B. „Dokumentation“, wenn es um Dokumentation geht, „Bug“, wenn es sich eindeutig um einen Fehler handelt, „Neues Feature“, wenn es sich um eine neue Feature-Anfrage handelt, …

Wenn das Problem klar definiert ist und die Behebung relativ unkompliziert erscheint, kennzeichnen Sie das Problem als „Gutes erstes Problem“ (und möglicherweise eine Beschreibung der Behebung oder einen Hinweis darauf, wo in der Codebasis zu suchen ist, um anzufangen).

Ein zusätzlicher nützlicher Schritt kann darin bestehen, das entsprechende Modul zu taggen, z. B. das "GUI/Qt"-Label, falls relevant.

An PRs arbeiten, um die Überprüfung zu unterstützen #

Das Überprüfen des Codes wird ebenfalls empfohlen. Beitragende und Benutzer sind herzlich willkommen, am Überprüfungsprozess gemäß unseren Überprüfungsrichtlinien teilzunehmen .

Danksagung #

Diese Seite wurde leicht vom scikit-learn-Projekt übernommen .