Open source Etikette

Bevor Sie anfangen, zu einem Open-Source-Projekt beizutragen, fragen Sie sich, warum Sie das tun möchten. Es ist in Ordnung, wenn die Antwort auf diese Frage einfach "Mir ist langweilig und ich möchte etwas Produktives mit meiner Zeit anfangen" lautet, aber wahrscheinlich können Sie tiefer gehen als das.

Noch bessere Gründe könnten sein:

• Ich benutze dieses Werkzeug ständig und habe einen Fehler darin gefunden/möchte dazu beitragen, es zu verbessern.
• Ich möchte anderen Menschen helfen, das Werkzeug erfolgreicher zu nutzen.
• Ich möchte anderen Menschen helfen, erfolgreicher zum Projekt beizutragen.
• Ich möchte meine eigenen Fähigkeiten verbessern.
• Ich möchte meine eigenen Fähigkeiten öffentlich im Rahmen meines Studiums an der Hochschule oder Universität demonstrieren.
• Ich möchte meine eigenen Fähigkeiten öffentlich demonstrieren, um meine Chancen auf einen Job zu verbessern.

Einige dieser Gründe sind eigennützig, und das ist in Ordnung — wenn Sie Ihre Zeit damit verbringen, kostenlos an einem Projekt zu arbeiten, ist es fair, zu erwarten, dass Sie etwas dafür bekommen. Darüber hinaus macht es eine klare Reihe von Gründen für Ihr Engagement einfacher, zu entscheiden, woran Sie zuerst arbeiten sollten.

Ihre Anwesenheit im Projekt sollte produktiv sein und die der anderen nicht behindern.

Wir könnten dies auf "freundlich sein" abkürzen. Dies ist unser Haupttipp für alle, die mit Open-Source-Beiträgen beginnen.

Seien Sie freundlich zu den anderen Mitwirkenden des Projekts, und es wird ein glücklicherer und produktiverer Ort sein. Dazu gehört:

• Danke sagen, wenn Ihnen jemand hilft.
• Gratulieren, wo es angebracht ist (zum Beispiel, wenn jemand seinen ersten Pull Request eingereicht hat oder einen besonders schwierigen Fehler behoben hat).
• Immer respektvoll auf Menschen reagieren, auch wenn Sie der Meinung sind, dass die Antwort auf ihre Frage offensichtlich war oder dass sie sich wiederholen.
• Versuchen Sie, Menschen zu helfen, es beim nächsten Mal besser zu machen, auf unterstützende Weise, z.B. während Pull-Request-Überprüfungen oder wenn Sie ihre Fragen beantworten. Zu sagen "Das ist falsch" oder "Hier ist die Antwort" ist bei weitem nicht so hilfreich wie "Das ist okay, aber ich finde, dass es besser wäre, wenn Sie es mehr so versuchen, hier ist ein Blogbeitrag für mehr Ideen" oder "Sie können die Antwort hier finden; schauen Sie sich auch diesen Link für weitere häufige Antworten an".

Sie und die anderen Mitwirkenden sind (oder sollten) hier sein, weil Sie einen positiven Beitrag zum Projekt leisten möchten, aber darüber hinaus können Sie nichts über sie annehmen. Dazu gehören ihre:

• Kenntnisse über das Projekt und die Technologien, die zu dessen Erstellung verwendet wurden
• Geschlecht, Sexualität, Alter, gesprochene Sprachen, Wohnort, politische Ansichten, Religion oder andere persönliche Eigenschaften
• Erfahrung mit Open-Source-Projekten
• Vertrauen
• Erwartungen
• Sinn für Humor

Daher sollten Sie sich so weit wie möglich an das Thema halten und potenziell kontroverse Off-Topic-Themen wie Religion oder Politik vermeiden sowie unterstützend und respektvoll bleiben, selbst wenn Sie mit jemandem nicht einverstanden sind oder eine Entscheidung, die sie getroffen haben, nicht mögen.

Außerdem sollten Sie auf jegliche Flüche/belastende Sprache verzichten, selbst wenn es an niemanden im Besonderen gerichtet ist. Es ist für die Teilnahme nicht notwendig, und einige Menschen sind wirklich empfindlich darauf.

Seien Sie sich bewusst, dass in jedem guten OSP Regeln vorhanden sind, um seine Mitwirkenden davor zu schützen, sich beim Mitwirken unwohl zu fühlen. Dies erfolgt normalerweise in Form einer CODE_OF_CONDUCT.md-Datei auf GitHub.

Zum Beispiel werden die Repositories von MDN von den weitreichenden Mozilla-Richtlinien für die Teilnahme an der Community geregelt. Üblicherweise wird leicht beleidigendes Verhalten in den Repositories der MDN Web Docs (wie ständig vom Thema abzuschweifen/störend zu wirken oder unhöflich zu sein) zunächst mit einer Warnung im Repository, gefolgt von einer finalen Warnung, dann mit einem vorübergehenden oder dauerhaften Bann beantwortet. Schwerwiegendere Verhaltensprobleme wie Hassrede oder Drohungen gegen einen anderen Mitwirkenden werden nicht toleriert und führen wahrscheinlich zu einem sofortigen Bann.

Wenn Sie etwas erhalten, das Sie unwohl fühlen lässt, sollten Sie es immer über den im Verhaltenskodex bereitgestellten Mechanismus melden.

Denken Sie darüber nach, was Sie im Projekt tun möchten. Zum Beispiel haben wir eine große Liste von Problemen auf dem Aufgaben-Board für Mitwirkende, unterteilt nach verschiedenen Aufgabentypen.

Sie können auch durch das Erstellen von Pull Requests zu Problemen beitragen, die Sie beim Lesen von MDN-Artikeln bemerken.

Ein Großteil der Arbeit auf MDN dreht sich um das Schreiben von Dokumentationen und Codebeispielen, aber es gibt auch andere Möglichkeiten, beizutragen:

• Helfen Sie, eingehende Probleme zu triagieren.
• Helfen Sie, Tippfehler zu beheben.
• Helfen Sie, Grammatik zu verbessern und Seiten verständlicher zu machen.
• Helfen Sie, Menschen zu betreuen, die versuchen, Korrekturen vorzunehmen.

Jede Korrektur ist nützlich, egal wie klein, und wir werden keine Korrektur ablehnen. Dennoch versuchen Sie sicherzustellen, dass Ihre Korrekturen produktiv sind. Wir möchten von folgenden Arten von Beiträgen abraten:

• Aktualisieren Sie den Code-Stil nur, weil "Sie diesen Stil besser mögen".
• Aktualisieren Sie den Sprachstil nur, weil "Sie diesen Stil besser mögen".
• Wechseln Sie von US-Englisch zu britischem Englisch.
• Fügen Sie eine Menge Interpunktion hinzu oder entfernen Sie sie, wenn es eigentlich kein Problem gibt.
• Wechseln Sie das Test-Framework, das wir verwenden, zu etwas anderem, weil Sie es bevorzugen.

In vielen Fällen sind die Dinge in OSPs aus einem Grund so, wie sie sind. Sie sollten ihre Stilrichtlinien lesen, wenn sie eine haben, und sollten immer erst fragen, wenn Sie sich nicht sicher sind, ob etwas produktiv ist!

Gute OSPs werden immer die Dokumentation für Mitwirkende leicht zugänglich machen. Bei Projekten auf GitHub ist diese normalerweise in der Datei CONTRIBUTING.md des Repos zu finden oder manchmal in der Datei README.md des Projekts. Als Dokumentationsprojekt hat MDN Inhalte in einem README und eine anständige Menge an Mitwirkenden-Dokumentation auf der Website selbst (siehe Mitwirken zu MDN Web Docs).

Scheuen Sie sich nicht zu fragen, aber versuchen Sie IMMER, die Antwort auf Ihre Frage zuerst selbst zu finden, bevor Sie fragen. Auf diese Weise bauen Sie Ihr Wissen über das Projekt auf, werden unabhängiger und belasten die anderen Mitwirkenden nicht unnötig.

Natürlich werden die Dokumente nicht immer perfekt sein. Wenn eine Erklärung schwer zu finden oder nicht gut beschrieben ist, erstellen Sie ein Problem oder einen Pull Request, um zu versuchen, es selbst zu beheben.

Finden Sie immer heraus, wo der beste Ort ist, um Fragen zu stellen. Gute OSPs werden dies in ihrer Dokumentation immer klarstellen (siehe Kontakt aufnehmen). Wenn Sie allgemeine Fragen stellen möchten, nutzen Sie immer diese Kanäle. Erstellen Sie nicht einfach für jede Frage ein Problem auf GitHub, da dies unnötigen Lärm zum Projekt hinzufügt (siehe "Fortschritte machen, nicht Lärm" unten).

Denken Sie sorgfältig darüber nach, wie Sie die Kommunikation im Projekt handhaben - stellen Sie sicher, dass sie nützlich ist und die Arbeit anderer Mitwirkender nicht erschwert. Pull Requests zur Behebung von Fehlern einzureichen ist großartig, aber sind sie wirklich nützlich und leicht zu überprüfen? Probleme zu erstellen und an anderen Gesprächen teilzunehmen ist in Ordnung, aber sind Ihre Probleme und Kommentare themenbezogen oder fügen sie nur Lärm hinzu?

In der Regel sollten Sie:

• Ein Thema pro Problem diskutieren — es ist einfacher, Probleme fokussiert und produktiv zu halten.
• Ein Problem pro PR beheben — es mag für Sie etwas mehr Arbeit sein, aber es ist viel einfacher, eine einzelne, klare Korrektur zu überprüfen.
• Zu anderen Threads beitragen, wenn Sie einen nützlichen Punkt zu machen haben oder die Frage eines anderen beantworten können.
• Fragen über andere Mechanismen wie Chatrooms oder Foren stellen, wenn Sie sich nicht sicher sind, ob etwas nützlich ist oder Sie eine einfache Frage haben.
• Zuerst das Handbuch lesen, um zu versuchen, die Frage selbst zu beantworten, bevor Sie sie stellen.

Nicht:

• Probleme verkomplizieren, indem Sie versuchen, mehrere Themen gleichzeitig zu diskutieren oder Off-Topic-Kommentare zu machen.
• Versuchen, mehrere Korrekturen in einen einzigen Pull Request zu packen. Es macht es viel schwieriger zu überprüfen und wirft Verdachtsmomente auf (einige Leute könnten denken, dass Sie versuchen, schädlichen Code zwischen den gültigen Änderungen zu verstecken).
• Viele Probleme eröffnen, die vage Fragen stellen.
• Fragen stellen, ohne vorher versucht zu haben, das Problem selbst zu lösen.

OSPs sind ziemlich demokratisch - viele Entscheidungen werden abgestimmt, und Sie können im Wesentlichen frei beitragen, wie Sie möchten, solange Sie niemanden daran hindern, ebenso beizutragen.

Einige Dinge werden jedoch weitgehend von einer kleinen Gruppe von Kernmitarbeitern entschieden. Sie können jederzeit gegen eine Entscheidung argumentieren, aber manchmal wird ein Moderator eine Entscheidung treffen, die Ihrer Meinung widerspricht. Sie müssen diese Entscheidungen respektieren und akzeptieren.

Es ist nützlich, die Moderatoren eines beliebigen Projekts kennenzulernen, sodass Sie wissen, an wen Sie sich am besten wenden können, um Hilfe zu erhalten, z.B. in Pull-Requests oder Problem-Threads.

Denken Sie daran, dass viele Menschen, die an OSPs arbeiten, dies in ihrer Freizeit und ohne Bezahlung tun, und dass alle Menschen, die an OSPs arbeiten, im Allgemeinen sehr beschäftigt sind. Wenn Sie auf etwas warten, wie z.B. eine Pull-Request-Überprüfung oder eine Antwort auf eine Frage, seien Sie geduldig.

Es ist vernünftig, einige Tage zu warten und dann jemanden höflich darauf hinzuweisen, ob er Zeit hatte, es sich anzuschauen. Wenn sie zu beschäftigt sind, ist es das Beste, eine weitere Woche zu warten und dann nachzufragen.

Es ist NICHT vernünftig, Forderungen zu stellen, wie z.B. nach einer schnellen Antwort.

Wenn jemand darauf wartet, dass Sie etwas für ihn tun, sollte Ihnen ebenfalls die gleiche Höflichkeit entgegengebracht werden, aber gleichzeitig sollten Sie versuchen, so schnell wie möglich zu antworten. Wenn Sie wirklich keine Zeit finden können, lassen Sie es sie wissen und bitten Sie die Betreuer, Ihnen zu helfen, jemand anderen für die Aufgabe zu finden.

• Anleitung zum Beitragen zu Open Source
• Allgemeinere freeCodeCamp "Anleitung zum Beitragen zu Open Source"-Liste
• Einstieg in das Beitragen zu Open Source