Dieser Inhalt wurde automatisch aus dem Englischen übersetzt, und kann Fehler enthalten. Erfahre mehr über dieses Experiment.

View in English Always switch to English

Open-Source-Etikette

Wenn Sie noch nie an einem Open-Source-Projekt (OSP) gearbeitet haben, ist es eine gute Idee, diesen Artikel zu lesen, bevor Sie beginnen, zu MDN Web Docs und anderen Open-Source-Projekten beizutragen. Es gibt einige Verhaltensweisen, die Ihnen und den anderen Projektmitwirkenden helfen, sich wertgeschätzt und sicher zu fühlen und produktiv zu bleiben. Dieser Artikel vermittelt Ihnen nicht alles über Beiträge zu Open Source; sein Ziel ist es, grundlegende Themen für die Teilnahme an Open-Source-Communitys abzudecken.

Denken Sie darüber nach, warum Sie zu einem OSP beitragen

Bevor Sie beginnen, zu einem Open-Source-Projekt beizutragen, fragen Sie sich, warum Sie dies tun möchten. Es ist in Ordnung, wenn die Antwort auf diese Frage „Ich möchte etwas mit meiner Zeit anfangen“ lautet, aber noch bessere Gründe könnten sein:

  • Ich möchte meine Fähigkeiten verbessern.
  • Ich verwende dieses Tool ständig und habe einen Fehler darin gefunden oder möchte helfen, es zu verbessern.
  • Ich möchte anderen Menschen helfen, das Tool erfolgreicher zu verwenden.
  • Ich möchte anderen Menschen helfen, erfolgreicher zum Projekt beizutragen.
  • Ich möchte meine eigenen Fähigkeiten öffentlich für meinen College- oder Universitätskurs demonstrieren oder meine Chancen auf einen Job verbessern.

Einige dieser Gründe dienen dem eigenen Interesse, und das ist in Ordnung! Klare Gründe für Ihren Beitrag zu haben, macht Sie produktiver und erleichtert die Zusammenarbeit mit der Community.

Seien Sie höflich und freundlich, und vermeiden Sie aufwiegelnde oder beleidigende Sprache

Wir könnten dies mit „Seien Sie freundlich“ abkürzen. Dies ist unser wichtigster Ratschlag für alle, die beginnen, zu Open Source beizutragen. Seien Sie freundlich zu den anderen Mitwirkenden des Projekts, und es wird ein angenehmerer und produktiverer Ort sein.

  • Bedanken Sie sich bei Menschen, wenn sie Ihnen helfen.
  • Beglückwünschen Sie Menschen, wenn es angebracht ist, etwa wenn ihr Pull Request übernommen wird oder sie einen schwierigen Bug beheben.
  • Antworten Sie immer respektvoll, auch wenn Sie der Meinung sind, dass die Antwort auf eine Frage offensichtlich war oder jemand sich wiederholt.
  • Versuchen Sie, Menschen auf unterstützende Weise dabei zu helfen, besser zu werden. Beispielsweise sind Aussagen wie „das ist falsch“ oder „hier ist die Antwort“ nicht so hilfreich wie „Das ist in Ordnung, aber ich denke, es wäre besser, wenn wir es eher so machen würden; hier ist ein Blogbeitrag mit weiteren Ideen“ oder „Sie finden die Antwort hier; sehen Sie sich außerdem diesen Link für weitere häufige Antworten an“.

Mitwirkende sind hier, weil sie einen positiven Einfluss auf das Projekt haben möchten. Machen Sie darüber hinaus keine Annahmen, beispielsweise über:

  • Kenntnisse des Projekts und der Technologien, die zu seiner Erstellung verwendet werden
  • Geschlecht, Sexualität, Alter, gesprochene Sprachen, Standort, politische Ansichten, Religion oder andere persönliche Merkmale
  • Erfahrung mit Open-Source-Projekten
  • Selbstvertrauen
  • Erwartungen
  • Sinn für Humor

Sie sollten bei dem bleiben, worüber Sie schreiben, und kontroverse Themen wie Religion oder Politik vermeiden. Unterlassen Sie Schimpfwörter oder potenziell beleidigende Sprache. Sie verbessert die Kommunikation nur selten und kann es anderen erschweren, teilzunehmen.

Seien Sie unterstützend und respektvoll, auch wenn Sie jemandem nicht zustimmen oder eine Entscheidung nicht mögen, die diese Person getroffen hat. Beachten Sie, dass in jedem guten OSP Regeln vorhanden sind, die seine Mitwirkenden davor schützen, sich während ihrer Beiträge unwohl zu fühlen. Diese finden sich auf GitHub üblicherweise in einer Datei namens CODE_OF_CONDUCT.md (siehe den CODE_OF_CONDUCT von mdn/content als Beispiel).

Die Repositories von MDN unterliegen den umfassenden Mozilla Community Participation Guidelines (CPG). Leicht beleidigendes Verhalten in MDN-Web-Docs-Repositories (etwa ständiges Abschweifen vom Thema bzw. Stören oder Unhöflichkeit) wird üblicherweise zunächst mit einer Warnung, anschließend mit einer letzten Warnung und danach mit einem vorübergehenden oder dauerhaften Ausschluss beantwortet. Schwerwiegendere Verhaltensprobleme wie Hassrede oder Drohungen gegen andere Mitwirkende werden nicht toleriert und führen wahrscheinlich zu einem sofortigen Ausschluss.

Wenn Sie etwas erhalten, durch das Sie sich unwohl fühlen, sollten Sie dies immer über den im Verhaltenskodex angegebenen Mechanismus melden.

Wählen Sie effektive Beiträge

Überlegen Sie, was Sie im Projekt tun möchten. Beispielsweise haben wir auf dem Aufgabenboard für Mitwirkende eine große Liste gemeldeter Issues, die nach verschiedenen Aufgabentypen aufgeteilt ist. Sie können auch beitragen, indem Sie Pull Requests öffnen, um Probleme zu beheben, auf die Sie beim Lesen von MDN-Artikeln stoßen.

Ein großer Teil der Arbeit bei MDN dreht sich um das Schreiben von Dokumentation und Codebeispielen, aber es gibt auch andere Möglichkeiten, beizutragen. Dies kann das Priorisieren eingehender Issues, das Beheben von Tippfehlern, das Korrigieren der Grammatik zur besseren Verständlichkeit von Seiten oder die Betreuung von Personen umfassen, die Korrekturen vornehmen möchten. Jede Korrektur ist nützlich, unabhängig davon, wie klein sie ist, und wir lehnen keine ab. Stellen Sie dennoch sicher, dass Ihre Korrekturen produktiv sind. Wir raten von folgenden Arten von Beiträgen ab:

  • Aktualisierung von Codestil, Sprache im Fließtext oder Test-Framework, weil sie Ihnen besser gefallen.
  • Änderung von Seiten von US-amerikanischem Englisch zu britischem Englisch.
  • Hinzufügen oder Entfernen von Satzzeichen, wenn das Original korrekt ist.

In vielen Fällen sind Dinge in OSPs aus einem bestimmten Grund so, wie sie sind. Sie sollten Styleguides lesen, sofern vorhanden, und im Zweifelsfall immer zuerst fragen, ob etwas produktiv ist!

Lesen Sie das Handbuch

Gute OSPs stellen Dokumentation für Mitwirkende immer leicht zugänglich bereit. Bei GitHub-Projekten befindet sie sich üblicherweise in der Datei CONTRIBUTING.md des Repositorys oder manchmal in der README.md-Datei des Projekts. Als Dokumentationsprojekt verfügt MDN Content über eine README und eine gute Sammlung von Dokumenten für Mitwirkende auf der Website selbst (siehe Community-Ressourcen).

Haben Sie keine Angst, um Hilfe zu bitten, aber versuchen Sie immer zuerst, die Antwort auf Ihre Frage zu finden, bevor Sie fragen. Auf diese Weise erweitern Sie Ihr Wissen über das Projekt und werden unabhängiger, ohne die anderen Mitwirkenden unnötig zu belasten. Wenn eine Erklärung schwer zu finden oder nicht besonders gut beschrieben ist, erstellen Sie ein Issue oder einen Pull Request, um sie selbst zu verbessern.

Finden Sie heraus, wo Sie Fragen stellen können

Finden Sie heraus, wo Sie Fragen am besten stellen können. Gute OSPs machen dies in ihrer Dokumentation immer deutlich (siehe Kontakt aufnehmen). Wenn Sie allgemeine Fragen stellen möchten, nutzen Sie immer diese Kanäle. Erstellen Sie nicht für jede Frage ein Issue auf GitHub, da dies dem Projekt unnötiges Rauschen hinzufügt (siehe den nächsten Abschnitt).

Machen Sie Fortschritt, nicht Rauschen

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 Bugs einzureichen ist großartig, aber stellen Sie sicher, dass sie nützlich oder leicht zu überprüfen sind. Issues zu erstellen und an anderen Gesprächen teilzunehmen ist in Ordnung, aber sind Ihre Issues und Kommentare themenbezogen oder fügen sie nur Rauschen hinzu?

Als Regel gilt:

  • Besprechen Sie ein Thema pro Issue — so lassen sich Issues leicht fokussiert und produktiv halten.
  • Beheben Sie ein Issue pro PR — dies kann für Sie etwas mehr Arbeit bedeuten, ist aber viel leichter zu überprüfen als eine einzelne, klare Korrektur.
  • Beteiligen Sie sich an anderen Threads, wenn Sie einen nützlichen Punkt beitragen oder die Frage einer anderen Person beantworten können.
  • Stellen Sie Fragen über andere Mechanismen wie Chats oder Foren, wenn Sie nicht sicher sind, ob etwas nützlich ist, oder wenn Sie eine einfache Frage haben.
  • Lesen Sie zuerst das Handbuch, um zu versuchen, die Frage selbst zu beantworten, bevor Sie sie stellen.

Tun Sie Folgendes nicht:

  • Erschweren Sie Issues, indem Sie versuchen, mehrere Themen gleichzeitig zu besprechen oder Kommentare abseits des Themas abgeben.
  • Versuchen Sie nicht, mehrere Korrekturen in einen einzelnen Pull Request zu packen. Das erschwert die Überprüfung erheblich und weckt Verdacht (manche Menschen könnten denken, dass Sie versuchen, bösartigen Code zwischen den gültigen Änderungen zu verstecken).
  • Öffnen Sie nicht viele Issues mit vagen Fragen.
  • Stellen Sie keine Fragen, ohne zuerst versucht zu haben, das Problem selbst zu lösen.

OSPs sind eine Demokratie (fast)

OSPs sind recht demokratisch — über viele Entscheidungen wird abgestimmt, und Sie können weitgehend so beitragen, wie Sie möchten, solange Sie niemanden anderen am Beitragen hindern.

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

Es ist nützlich, die Moderatoren eines Projekts kennenzulernen, damit Sie wissen, wen Sie am besten um Hilfe bitten können, beispielsweise in Pull Requests oder Issue-Threads.

Seien Sie geduldig und zeitnah

Bedenken Sie, 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 wie eine Überprüfung eines Pull Requests oder eine Antwort auf eine Frage warten, seien Sie geduldig.

Es ist angemessen, einige Tage zu warten und dann jemandem höflich eine Nachricht zu senden, um zu fragen, ob die Person Zeit hatte, es sich anzusehen. Falls sie zu beschäftigt ist, ist es möglicherweise am besten, eine weitere Woche zu warten und dann erneut nachzufragen.

Es ist nicht angemessen oder höflich, Dinge wie eine schnelle Antwort zu verlangen.

Wenn jemand darauf wartet, dass Sie etwas für diese Person tun, sollten Sie dieselbe Höflichkeit entgegenbringen, aber gleichzeitig versuchen, so zeitnah wie möglich zu antworten. Wenn Sie wirklich keine Zeit finden können, teilen Sie dies mit und bitten Sie die Maintainer, Ihnen dabei zu helfen, jemand anderen für die Aufgabe zu finden.

Siehe auch