Verhaltensregeln für Open-Source-Projekte
Wenn Sie noch nie an einem Open-Source-Projekt (OSP) mitgearbeitet haben, empfiehlt es sich, diesen Artikel zu lesen, bevor Sie beginnen, zu MDN Web Docs oder anderen Open-Source-Projekten beizutragen. Einige Verhaltensweisen helfen Ihnen und den anderen Mitwirkenden, sich wertgeschätzt und sicher zu fühlen und produktiv zu bleiben. Dieser Artikel vermittelt Ihnen nicht alles, was Sie über die Mitarbeit an Open-Source-Projekten wissen müssen. Er behandelt grundlegende Themen für die Teilnahme an Open-Source-Communitys.
Überlegen Sie, warum Sie zu einem OSP beitragen möchten
Bevor Sie beginnen, zu einem Open-Source-Projekt beizutragen, fragen Sie sich, warum Sie das tun möchten. „Ich möchte meine Zeit sinnvoll nutzen“ ist eine völlig akzeptable Antwort. Weitere Gründe könnten sein:
- Ich möchte meine Fähigkeiten verbessern.
- Ich nutze dieses Tool ständig und habe einen Fehler darin gefunden oder möchte helfen, es zu verbessern.
- Ich möchte anderen helfen, das Tool erfolgreicher zu nutzen.
- Ich möchte anderen helfen, erfolgreicher zum Projekt beizutragen.
- Ich möchte meine Fähigkeiten öffentlich nachweisen, etwa für mein Studium oder um meine Chancen bei der Jobsuche zu verbessern.
Einige dieser Gründe dienen Ihren eigenen Interessen, und das ist völlig in Ordnung! Wenn Sie klare Gründe für Ihre Mitarbeit haben, können Sie produktiver sein und leichter mit der Community zusammenarbeiten.
Seien Sie höflich und freundlich und vermeiden Sie provokante oder beleidigende Sprache
Kurz gesagt: Seien Sie freundlich. Das ist unser wichtigster Rat für alle, die beginnen, zu Open-Source-Projekten beizutragen. Begegnen Sie den anderen Mitwirkenden freundlich. So wird das Projekt zu einem angenehmeren und produktiveren Ort.
- Bedanken Sie sich, wenn Ihnen jemand hilft.
- Gratulieren Sie anderen, wenn es angebracht ist, etwa wenn ihr Pull Request übernommen wurde oder sie einen schwierigen Fehler behoben haben.
- Antworten Sie immer respektvoll, auch wenn Ihnen die Antwort auf eine Frage offensichtlich erscheint oder sich jemand wiederholt.
- Versuchen Sie, anderen auf unterstützende Weise zu helfen, besser zu werden. Beispielsweise sind „Das ist falsch“ oder „Hier ist die Antwort“ weniger hilfreich als „Das ist in Ordnung, aber ich denke, es wäre besser, wenn wir es so machen würden. Hier ist ein Blogbeitrag mit weiteren Anregungen“ oder „Die Antwort finden Sie hier; unter diesem Link finden Sie außerdem Antworten auf häufige Fragen“.
Mitwirkende sind hier, weil sie das Projekt positiv beeinflussen möchten. Treffen Sie darüber hinaus keine Annahmen über andere, etwa hinsichtlich:
- ihrer Kenntnisse des Projekts und der Technologien, mit denen es erstellt wurde
- ihres Geschlechts, ihrer Sexualität, ihres Alters, der Sprachen, die sie sprechen, ihres Wohnorts, ihrer politischen Ansichten, ihrer Religion oder anderer persönlicher Merkmale
- ihrer Erfahrung mit Open-Source-Projekten
- ihres Selbstvertrauens
- ihrer Erwartungen
- ihres Sinns für Humor
Bleiben Sie beim Thema und vermeiden Sie kontroverse Themen wie Religion oder Politik. Verzichten Sie auf Schimpfwörter oder potenziell beleidigende Sprache. Das verbessert die Kommunikation selten und kann anderen die Teilnahme erschweren.
Bleiben Sie unterstützend und respektvoll, auch wenn Sie mit jemandem nicht einverstanden sind oder eine Entscheidung nicht gut finden.
Beachten Sie, dass jedes gute OSP Regeln hat, die Mitwirkende davor schützen sollen, dass sie sich bei ihrer Mitarbeit unwohl fühlen.
Diese finden Sie auf GitHub üblicherweise in einer Datei namens CODE_OF_CONDUCT.md (ein Beispiel ist der mdn/content CODE_OF_CONDUCT).
Für die Repositories von MDN gelten die umfassenden Mozilla-Richtlinien zur Teilnahme an der Community (CPG). Auf leicht unangemessenes Verhalten in den Repositories von MDN Web Docs, etwa ständige themenfremde oder störende Beiträge oder Unhöflichkeit, folgt normalerweise zunächst eine Verwarnung, dann eine letzte Verwarnung und schließlich ein vorübergehender oder dauerhafter Ausschluss. Schwerwiegenderes Fehlverhalten wie Hassrede oder Drohungen gegen andere Mitwirkende wird nicht toleriert und führt wahrscheinlich zu einem sofortigen Ausschluss.
Wenn Sie etwas erleben, das Ihnen Unbehagen bereitet, sollten Sie es stets über das im Verhaltenskodex vorgesehene Verfahren melden.
Wählen Sie sinnvolle Beiträge
Überlegen Sie, was Sie im Projekt tun möchten. Beispielsweise finden Sie im Aufgabenboard für Mitwirkende eine umfangreiche Liste von Issues, die nach verschiedenen Aufgabentypen gegliedert sind. Sie können auch beitragen, indem Sie Pull Requests erstellen, um Probleme zu beheben, die Ihnen beim Lesen von MDN-Artikeln auffallen.
Ein großer Teil der Arbeit an MDN besteht darin, Dokumentation und Codebeispiele zu schreiben. Es gibt aber auch andere Möglichkeiten, beizutragen. Sie können beispielsweise helfen, eingehende Issues zu sichten, Tippfehler zu korrigieren, die Grammatik zu verbessern, damit Seiten verständlicher werden, oder Menschen bei ihren Korrekturen unterstützen. Jede Korrektur ist nützlich, egal wie klein sie ist. Achten Sie dennoch darauf, dass Ihre Änderungen sinnvoll sind. Von folgenden Arten von Beiträgen raten wir ab:
- Code-Stil, Formulierungen in Fließtexten oder das Test-Framework zu ändern, nur weil Ihnen eine andere Variante besser gefällt.
- Seiten von US-amerikanischem auf britisches Englisch umzustellen.
- Satzzeichen hinzuzufügen oder zu entfernen, obwohl die ursprüngliche Zeichensetzung korrekt ist.
- Änderungen einzureichen, die Sie nicht selbst geprüft, getestet und verstanden haben.
- Viele gleichartige Änderungen auf zahlreichen Seiten vorzunehmen, ohne sie vorher zu besprechen.
Bei OSPs sind Dinge oft aus gutem Grund so, wie sie sind. Lesen Sie vorhandene Stilrichtlinien. Wenn Sie unsicher sind, ob eine Änderung sinnvoll ist, fragen Sie immer zuerst nach!
Denken Sie daran, dass Sie für Ihre Beiträge verantwortlich sind. Wenn Sie nicht erklären können, warum Sie eine Änderung vorgenommen haben, reichen Sie sie nicht ein.
Lesen Sie die Dokumentation
Gute OSPs stellen Dokumentation für Mitwirkende leicht zugänglich bereit. Bei GitHub-Projekten steht sie üblicherweise in der Datei CONTRIBUTING.md des Repositories, manchmal auch in der Datei README.md des Projekts. Als Dokumentationsprojekt verfügt MDN Content über eine README-Datei und eine umfangreiche Dokumentation für Mitwirkende auf der Website selbst (siehe Ressourcen für die Community).
Scheuen Sie sich nicht, um Hilfe zu bitten. Versuchen Sie aber immer zuerst, die Antwort auf Ihre Frage selbst zu finden. So erweitern Sie Ihre Kenntnisse über das Projekt, werden selbstständiger und belasten andere Mitwirkende nicht unnötig. Wenn eine Erklärung schwer zu finden oder unzureichend ist, erstellen Sie ein Issue oder versuchen Sie, das Problem mit einem Pull Request selbst zu beheben.
Finden Sie heraus, wo Sie Fragen stellen können
Finden Sie heraus, wo Sie am besten Fragen stellen. Gute OSPs erläutern dies in ihrer Dokumentation (siehe Kontakt aufnehmen). Nutzen Sie für allgemeine Fragen stets diese Kanäle. Erstellen Sie nicht für jede Frage ein GitHub-Issue, denn das erschwert die Übersicht im Projekt (siehe den nächsten Abschnitt).
Bringen Sie das Projekt voran, statt unnötigen Aufwand zu verursachen
Überlegen Sie genau, wie Sie im Projekt kommunizieren: Ihre Beiträge sollten nützlich sein und die Arbeit anderer Mitwirkender nicht erschweren. Pull Requests zur Behebung von Fehlern sind willkommen. Achten Sie aber darauf, dass sie sinnvoll oder leicht zu prüfen sind. Es ist völlig in Ordnung, Issues zu erstellen und sich an anderen Gesprächen zu beteiligen. Fragen Sie sich dabei jedoch, ob Ihre Issues und Kommentare zum Thema beitragen oder nur unnötigen Aufwand verursachen.
Grundsätzlich sollten Sie:
- Pro Issue nur ein Thema besprechen. So bleiben Issues übersichtlich und zielführend.
- Pro Pull Request nur ein Problem beheben. Das bedeutet für Sie möglicherweise etwas mehr Arbeit, aber eine einzelne, klar umrissene Korrektur lässt sich viel leichter prüfen.
- Sich an anderen Diskussionen beteiligen, wenn Sie etwas Nützliches beizutragen haben oder die Frage einer anderen Person beantworten können.
- Issues, Beschreibungen von Pull Requests und Kommentare in eigenen Worten verfassen. Kurz und konkret ist besser als lang und ausgefeilt.
- Für Fragen andere Wege wie Chatrooms oder Foren nutzen, wenn Sie sich nicht sicher sind, ob ein Beitrag sinnvoll ist, oder wenn Sie eine einfache Frage haben.
- Zuerst die Dokumentation lesen und versuchen, die Antwort selbst zu finden, bevor Sie fragen.
Vermeiden Sie es:
- Issues unnötig zu verkomplizieren, indem Sie mehrere Themen gleichzeitig besprechen oder themenfremde Kommentare schreiben.
- Mehrere Korrekturen in einen einzigen Pull Request zu packen. Das erschwert die Prüfung erheblich und kann Misstrauen wecken: Manche könnten vermuten, dass Sie zwischen den berechtigten Änderungen schädlichen Code verstecken möchten.
- Pull Requests zu erstellen, die Sie nicht selbst geprüft haben.
- Viele Issues mit vagen Fragen zu erstellen.
- Fragen zu stellen, ohne zuerst selbst nach einer Lösung gesucht zu haben.
OSPs sind (fast) demokratisch
OSPs sind recht demokratisch: Über viele Entscheidungen wird abgestimmt, und Sie können weitgehend selbst entscheiden, wie Sie beitragen möchten, solange Sie andere nicht an ihrer Mitarbeit hindern.
Manche Dinge werden jedoch weitgehend von einer kleinen Gruppe zentraler Mitwirkender entschieden. Sie können gegen jede Entscheidung argumentieren, aber manchmal trifft eine moderierende Person eine Entscheidung, die Ihrer Meinung widerspricht. Diese Entscheidungen müssen Sie respektieren und akzeptieren.
Es ist hilfreich, die moderierenden Personen eines Projekts kennenzulernen. So wissen Sie, wen Sie beispielsweise bei Pull Requests oder in Issue-Diskussionen am besten um Hilfe bitten können.
Seien Sie geduldig und reagieren Sie zeitnah
Denken Sie daran, dass viele Menschen in ihrer Freizeit und unbezahlt an OSPs arbeiten und dass alle Beteiligten im Allgemeinen sehr beschäftigt sind. Wenn Sie beispielsweise auf die Prüfung eines Pull Requests oder die Antwort auf eine Frage warten, haben Sie Geduld.
Es ist angemessen, einige Tage zu warten und dann höflich nachzufragen, ob die betreffende Person bereits Zeit hatte, sich damit zu befassen. Wenn sie zu beschäftigt ist, warten Sie am besten noch eine Woche, bevor Sie erneut nachfragen.
Es ist nicht angemessen oder höflich, etwa eine schnelle Antwort zu verlangen.
Wenn jemand darauf wartet, dass Sie etwas erledigen, sollten Sie die gleiche Rücksicht erfahren. Versuchen Sie zugleich, so zeitnah wie möglich zu reagieren. Wenn Sie wirklich keine Zeit finden, teilen Sie dies mit und bitten Sie die Verantwortlichen des Projekts, Ihnen zu helfen, jemand anderen für die Aufgabe zu finden.
Sie sind dafür verantwortlich, Ihre Beiträge weiter zu begleiten. Antworten Sie selbst auf Kommentare der prüfenden Personen und erstellen Sie nur so viele Pull Requests, wie Sie betreuen können.