Wenn du schon mal die Issue-Listen in meinen Repos durchstöbert oder selbst eins erstellt hast, hast du vielleicht schon mal gesehen, dass ich folgenden Kommentar abgebe und dann das Issue schließe:
Zuerst mal sorry, wenn das irgendwie unangenehm für dich war. In diesem Beitrag möchte ich versuchen, die Gründe dafür zu erklären.
Open-Source-Software wird "wie besehen" bereitgestellt
Zuerst sollten wir uns über Open-Source-Software (OSS) einig sein. Wenn du dir die MIT-Lizenz anschaust, eine der beliebtesten Lizenzen, wirst du folgende Aussage finden:
Die Software wird "WIE BESCHRIEBEN" bereitgestellt, ohne jegliche Garantie, ausdrücklich oder impliziert, einschließlich, aber nicht beschränkt auf Garantien der Marktgängigkeit, Eignung für einen bestimmten Zweck und Nichtverletzung.
"Wie beschrieben" bedeutet, dass du frei bist, den Code zu nutzen, zu forken oder wie du möchtest mit dem aktuellen Zustand zu ändern. Das bedeutet, dass die Autoren nicht verpflichtet sind, irgendetwas zu reparieren oder zu verbessern, was du jetzt oder in Zukunft haben könntest. Da es frei und Open Source ist, gewinnen die Autoren oder Maintainer nichts, egal ob du es nutzt oder nicht. Es gibt so etwas wie einen 24/7-Kundenservice nicht. Theoretisch solltest du als Nutzer von Open-Source-Code für den Code, den du verwendest, verantwortlich sein.
Ja, das klingt beängstigend. Aber zum Glück sind die Dinge in der Praxis nicht so schlimm. In vielen Open-Source-Projekten bauen wir Vertrauen zwischen Nutzern und Maintainern auf. Nutzer tragen zu Projekten bei, indem sie Probleme melden, die sie festgestellt haben, oder Lösungen über Diskussionen und Pull Requests teilen. Maintainer verwenden ihre Zeit für das Reviewen, Entscheidungen treffen, Veröffentlichungen managen und Distributionen durchführen. Sowohl Nutzer als auch Maintainer arbeiten freiwillig auf das gleiche Ziel hin - die Software für alle besser zu machen.
Wartung erfordert Anstrengung, und zwar viel
Software, einmal geschrieben, ist nie fertig. Wartung spielt eine entscheidende Rolle, um ein Projekt "am Leben" zu halten, Bug- oder Sicherheitsupdates rechtzeitig zu erhalten und auf lange Sicht nachhaltig zu sein. Dinge wie das Triagieren von Issues, das Überprüfen von PRs und Diskussionen können viel Aufwand von den Maintainern erfordern. Während bei Open-Source-Projekten das Verhältnis von Nutzern zu Maintainern häufig unausgeglichen ist. Viele beliebte Projekte haben möglicherweise nur einen oder zwei Maintainer hinter den Kulissen. Wenn ein Projekt wächst und mehr Nutzer gewinnt, können die erforderlichen Aufgaben zur Wartung des Projekts schnell über die Kapazitäten eines Einzelnen hinausgehen.
Warum Reproduktion
Eine gute minimale Reproduktion eines potenziellen Problems kann den Maintainern enorm helfen,
die Ursache schnell zu identifizieren und den Fix zu landen. Ohne eine minimale Reproduktion können Maintainer allein aus der Beschreibung des Issues oder einem Screenshot nicht einmal wissen, ob es sich um ein echtes Problem des Projekts handelt oder ob es durch andere Faktoren verursacht wird. Um das zu identifizieren, müssen Maintainer möglicherweise zusätzliche Zeit aufwenden, um selbst eine Reproduktion zu finden, oder sich in das riesige Projekt stürzen, das Leute als "nicht-minimale Reproduktion" geteilt haben. Stunden könnten vergehen, aber was, wenn sich herausstellt, dass es kein Problem gibt oder es nicht reproduzierbar ist? Was, wenn es hunderte solcher Issues gibt, mit denen du umgehen musst?
Meiner Meinung nach ist nach einer minimalen Reproduktion zu fragen, nach einem Ausgleich der aufgewendeten Mühe. Wenn jeder sich die Zeit nehmen könnte, eine minimale Reproduktion zu erstellen, bevor er Issues öffnet, würde das den Maintainern Hunderte von Stunden sparen (oder sogar sich selbst helfen, Lösungen/Fehler auf Nutzerseite zu finden, dann bräuchten sie das Issue gar nicht erstellen). Ein gut untersuchtes und gut erklärtes Issue würde auch die Maintainer eher bereit machen, ihre Zeit und Mühe im Gegenzug aufzuwenden.
Hier möchte ich den Begriff "Vermutung der Fehlerfreiheit" prägen. Ähnlich wie die Unschuldsvermutung im Recht sollten Issues als unschuldig betrachtet werden, bis sie mit einer minimalen Reproduktion als "schuldig" erwiesen sind. Issue-Ersteller sollten verantwortlich sein, genügend Informationen bereitzustellen, um zu beweisen, dass das Problem nicht durch andere Faktoren verursacht wird.
Wie man eine minimale Reproduktion erstellt
Fehlgeschlagene Testfälle
Wenn du ein Entwickler bist und mit dem Testprozess vertraut bist. Die besten Reproduktionen sind Pull Requests, die fehlgeschlagene Testfälle hinzufügen. Dieser Ansatz hebt nicht nur das Problem hervor, sondern beschreibt auch klar das erwartete Verhalten. Mit dem Continuous Integration (CI)-System lässt sich auch die Korrektur nach dem Landen überprüfen und bietet einen Schutz gegen zukünftige Regressionen.
Um mit dieser Methode fortzufahren, beginne damit, den Quellcode des Projekts zu klonen und die Entwicklungsumgebung einzurichten. Dann erstelle einen neuen Branch und navigiere zum Testordner, um einen fehlgeschlagenen Testfall hinzuzufügen, der die von dir beobachtete Diskrepanz widerspiegelt. Nachdem du erfolgreich den neuen Test zum Scheitern gebracht hast – was den Bug anzeigt --, committe die Änderungen und erstelle dann einen Pull Request, der das Problem in seiner Beschreibung detailliert.
Hier sind echte Beispiele:
- vuejs/language-tools #2113
- PR erstellt durch Hinzufügen eines fehlgeschlagenen Tests
- Der Maintainer hat später einen Fix gepusht, um den Test bestehen zu lassen
- PR wird gemerged, und die Tests werden verbessert, um mehr Fälle abzudecken
Bitte beachte, dass diese Methode nicht immer anwendbar ist. Wenn der Bug nicht mit einem Testfall reproduziert werden kann, kannst du stattdessen versuchen, Repository-Reproduktionen zu erstellen, wie unten beschrieben.
Reproduzierbare Projekte oder Playgrounds
Dieser Abschnitt ist entnommen aus Please include a repro von Rich Harris. Es wird auch empfohlen, [eine detaill
iertere Erklärung von Rich Harris](https://youtu.be/dB_YjuAMH3o?t=1376) anzusehen.
In einigen Fällen gibt es eine projektspezifische Möglichkeit, Probleme zu demonstrieren – zum Beispiel haben Rollup, Svelte und Vue alle dedizierte REPLs. Benutze sie!
Oft ist es nicht möglich, das Problem mit einem REPL zu veranschaulichen. Hier ist, was du tun kannst:
- Erstelle ein Beispiel-Repo auf GitHub oder Stackblitz (oder wo auch immer)
- Demonstriere das Problem, und nur das Problem. Reduziere es auf das absolute Minimum an Code, das das Problem zuverlässig zeigt. Entferne alle Abhängigkeiten, die nicht direkt mit dem Problem zusammenhängen.
- Installiere alle deine Abhängigkeiten in
package.json. Wenn der Maintainer das Repo nicht klonen undnpm install && npm run build(oder ähnlich – siehe Punkt 4) ausführen kann, um das Problem zu sehen, weil der Maintainer irgendein global installiertes CLI-Tool oder ähnliches benötigt, würde das es schwerer machen, das Problem zu lösen. - Füge Anweisungen im Repo hinzu, zusammen mit einer Beschreibung des erwarteten und tatsächlichen Verhaltens. Offensichtlich sollte das Issue auch Informationen über den Bug enthalten, aber es ist wirklich hilfreich, wenn
README.mddiese Informationen enthält, plus einen Link zurück zum Issue. Wenn es Anweisungen übernpm install && npm run buildhinaus gibt, sollten sie hier stehen.
Zusammenfassung
Als Maintainer schätze ich alle Issues und Pull Requests, die geöffnet werden. Und ich glaube, es ist wahr, dass einige der Issues, die wir ohne Reproduktion geschlossen haben, noch echte Bugs haben könnten, die behoben werden müssen. Aber um nicht von den Benachrichtigungen überwältigt zu werden, müssen Maintainer Prioritäten bei der Bearbeitung der Aufgaben setzen. Die Anzahl der Issues in einem handhabbaren Rahmen zu halten, ist einer der Wege, um das Projekt langfristig gesund zu halten.
Ich glaube, Open Source geht darum, gemeinsam großartige Dinge zu bauen, nicht nur auf den Schultern der Maintainer. Ich wünsche mir, dass wir zusammen eine bessere und gesündere Gemeinschaft schaffen können. Danke fürs Lesen 😊