Ein Leitfaden zur Etikette in Open Source

Open-Source-Software floriert. Große Unternehmen bauen auf Software auf, die auf offener Zusammenarbeit basiert, und genießen die vielen Vorteile einer signifikanten Community-Akzeptanz. Kostenlose und Open-Source-Software ist erstaunlich in ihrer Fähigkeit, viele Menschen aus aller Welt zusammenzubringen und ihre Bemühungen und Fähigkeiten auf der Grundlage ihrer Interessen zu bündeln.

Dennoch, und da wir aus so vielen unterschiedlichen Hintergründen kommen, lohnt es sich, einen Moment innezuhalten, um darüber nachzudenken, wie wir zusammenarbeiten. Die Art und Weise, wie Sie sich bei der Zusammenarbeit mit anderen verhalten, kann manchmal beeinflussen, ob Ihre Arbeit zusammengeführt wird, ob sich jemand um Ihr Problem kümmert oder in einigen Fällen, warum Sie zukünftig von der Teilnahme am Repository ausgeschlossen werden könnten. Dieser Beitrag wurde geschrieben, um Menschen bestmöglich zu leiten, wie diese Kommunikation reibungslos verläuft. Hier ist eine Stichpunktliste zur Etikette in Open Source, die Ihnen helfen soll, eine angenehmere Zeit in der Community zu verbringen und zu einer besseren Gemeinschaft beizutragen.

Für den Maintainer

• Verwenden Sie Labels wie „hilfe benötigt“ oder „anfängerfreundlich“, um Personen zu Problemen zu leiten, an denen sie arbeiten können, wenn sie neu im Projekt sind.
• Wenn Sie Benchmarks durchführen, zeigen Sie den Autoren des Frameworks/der Bibliothek/etc. den Code, den Sie zum Benchmarking verwenden möchten, bevor Sie ihn ausführen. Ermöglichen Sie ihnen, einen PR (es ist in Ordnung, eine Frist zu setzen). Auf diese Weise wissen Sie, wenn Ihr Benchmark durchgeführt wird, dass Sie deren Zustimmung haben und er so fair wie möglich ist. Dies behebt auch Probleme wie das Benchmarking von Entwicklungs- anstelle von Produktionsversionen oder Benutzerfehler.
• Wenn Sie jemanden um Hilfe bitten oder ein Problem als „hilfe benötigt“ kennzeichnen und jemand einen PR einreicht, schreiben Sie bitte einen Kommentar, warum Sie ihn schließen, wenn Sie sich entscheiden, ihn nicht zu mergen. Andernfalls ist es respektlos gegenüber ihrer Zeit, da sie Ihrer Handlungsaufforderung gefolgt sind. Ich würde sogar so weit gehen zu sagen, dass es schön wäre, jeden PR, den Sie schließen ODER mergen, zu kommentieren, um den Grund zu erklären bzw. sich zu bedanken.
• Schließen Sie keinen PR von einem aktiven Mitwirkenden und implementieren Sie dieselbe Funktionalität nicht selbst neu. Tun Sie das einfach nicht.
• Wenn bei einer Problemdiskussion ein Streit ausbricht, der persönlich wird, beenden Sie ihn so schnell wie möglich und übergeben Sie ihn an die Kern-Maintainer. Sperren Sie das Problem und stellen Sie sicher, dass der Verhaltenskodex gegebenenfalls durchgesetzt wird.
• Haben Sie einen Verhaltenskodex und machen Sie dessen Existenz deutlich. Sie könnten den Contributor Covenant Verhaltenskodex in Betracht ziehen. GitHub bietet inzwischen auch eine einfache Integration von Verhaltenskodizes mit einigen Basisvorlagen.

Für den Nutzer

• Ein Dankeschön für das Projekt, bevor Sie eine Anfrage zu neuen Funktionen stellen oder einen Fehler melden, wird in der Regel geschätzt.
• Erstellen Sie bei der Eröffnung eines Problems nach Möglichkeit eine kleine, isolierte, einfache Reproduktion des Problems unter Verwendung eines Online-Code-Editors (wie Codepen oder Codesandbox) und eines GitHub-Repositorys, falls nicht anders möglich. Der Prozess kann Ihnen helfen, das zugrunde liegende Problem zu entdecken (oder zu erkennen, dass es kein Problem mit dem Projekt ist). Er erleichtert es auch den Maintainern, Ihnen bei der Lösung des Problems zu helfen.
• Schlagen Sie bei der Eröffnung eines Problems bitte eine Lösung für das Problem vor. Nehmen Sie sich ein paar Minuten Zeit, um ein wenig zu recherchieren. Dieser Blogbeitrag enthält einige Vorschläge, wie man ein wenig in den Quellcode eintauchen kann. Wenn Sie sich nicht sicher sind, erklären Sie, dass Sie nicht sicher sind, was zu tun ist.
• Wenn Sie ein Problem eröffnen und es nicht selbst lösen können, erklären Sie dies bitte. Es wird erwartet, dass Sie die Probleme, die Sie ansprechen, selbst lösen. Wenn jemand anderes es tut, ist das ein Geschenk, das er Ihnen macht (daher sollten Sie in diesem Fall angemessene Dankbarkeit ausdrücken).
• Reichen Sie keine Probleme ein, die Dinge wie „Wird das überhaupt noch gepflegt?“ sagen. Ein solcher Kommentar ist beleidigend für die investierte Zeit, er vermittelt den Eindruck, dass das Projekt nicht mehr gültig ist, nur weil sie eine Pause brauchten, an etwas anderem arbeiteten, ihr Vater starb oder sie ein Kind bekamen oder aus einem anderen unzähligen menschlichen Grund nicht auf Abruf für Code zur Verfügung standen. Es ist völlig in Ordnung zu fragen, ob es eine Roadmap für die Zukunft gibt, oder basierend auf vergangenen Commits zu entscheiden, dass es für Ihren Geschmack nicht mehr ausreichend gepflegt wird. Es ist nicht in Ordnung, passiv-aggressiv zu jemandem zu sein, der etwas kostenlos für Sie erstellt hat.
• Wenn jemand einen PR respektvoll ablehnt, weil er zwar gültigen Code enthält, aber nicht in die Richtung geht, die er für das Projekt wünscht, kommentieren Sie den Pull Request nicht weiter. Zu diesem Zeitpunkt könnte es eine bessere Idee sein, das Projekt zu forken, wenn Sie das Bedürfnis nach einer Funktion stark empfinden.
• Wenn Sie einen wirklich großen Pull Request für ein Projekt einreichen möchten, an dem Sie kein Kernmitwirkender sind, ist es eine gute Idee, über ein Issue anzufragen, ob die von Ihnen angestrebte Richtung sinnvoll ist. Dies bedeutet auch, dass Ihr Pull Request mit größerer Wahrscheinlichkeit gemergt wird, da Sie ihnen eine Vorabinformation gegeben und den Plan kommuniziert haben. Besser noch, brechen Sie es in kleinere Pull Requests auf, damit es nicht zu viel auf einmal zu verdauen ist.
• Vermeiden Sie Anspruchsdenken. Die Maintainer des Projekts schulden Ihnen nichts. Wenn Sie beginnen, das Projekt zu nutzen, liegt es in Ihrer Verantwortung, zur Wartung beizutragen. Wenn Ihnen die Art und Weise, wie das Projekt gewartet wird, nicht gefällt, seien Sie respektvoll, wenn Sie Vorschläge machen und Hilfe zur Verbesserung der Situation anbieten. Sie können das Projekt jederzeit forken, um es selbst weiterzuentwickeln, wenn Sie der festen Überzeugung sind, dass es nicht die Richtung ist, die Sie persönlich einschlagen würden.
• Machen Sie sich vor jeglichen Aktionen an einem Projekt mit den Mitwirkenden-Richtlinien vertraut, die oft in einer CONTRIBUTING.md-Datei am Stammverzeichnis des Repositories zu finden sind. Wenn keine existiert, reichen Sie ein Issue ein, um zu fragen, ob Sie bei der Erstellung helfen könnten.

Abschließende Gedanken

Das übergreifende Thema dieser Tipps ist es, höflich, respektvoll und freundlich zu sein. Der Wert von Open Source für unsere Branche ist unermesslich. Wir können ihn für alle zu einem besseren Ort machen, indem wir einige einfache Etikette-Regeln befolgen. Denken Sie daran, dass die Maintainer von Projekten oft in ihrer Freizeit daran arbeiten. Vergessen Sie auch nicht, dass Nutzer von Projekten manchmal neu in der ständig wachsenden Softwarewelt sind. Dies sollten wir bei der Kommunikation und Zusammenarbeit berücksichtigen. So können wir die Open-Source-Community zu einem besseren Ort machen.