Warum eigentlich zu Open-Source-Projekten beitragen?

Zu Open Source beizutragen, kann ein lohnender Weg sein, um nahezu alle erdenklichen Fertigkeiten zu erlernen, zu lehren und Erfahrungen zu sammeln.

Warum tragen Menschen zu Open Source bei? Es gibt viele Gründe!

Software verbessern, auf die Sie sich verlassen

Viele Open-Source-Beitragende waren vorher Nutzer*innen der Software, zu der sie beitragen. Wenn Sie einen Fehler in einer von Ihnen verwendeten Open-Source-Software finden, sollten Sie sich im Quellcode umsehen, ob Sie den Fehler evtl. selbst patchen können. Wenn ja, ist einen Patch einzureichen der beste Weg sicherzustellen, dass Ihre Kolleg*innen (und Sie selbst, wenn Sie auf die nächste Version aktualisieren) davon profitieren können.

Bestehende Fähigkeiten verbessern

Ob Programmierung, User Interface Design, Grafikdesign, Schreiben oder Organisieren: Wenn Sie auf der Suche nach Praxiserfahrung sind, werden Sie dafür passende Aufgaben in einem Open-Source-Projekt finden.

Treffen Sie Menschen, die an ähnlichen Dingen interessiert sind

Open-Source-Projekte mit warmherzigen, einladenden Communities schaffen langfristige Hobbys für viele Leute. Lebenslange Freundschaften können durch ihre Teilnahme an Open Source entstehen, sei es bei Konferenzen oder bei nächtlichen Online-Chats über Lahmacuns.

Mentoren finden und andere unterrichten

Wenn Sie mit anderen an einem gemeinsamen Projekt arbeiten, müssen Sie erklären, wie Sie dabei vorgehen und gleichzeitig andere Menschen um Hilfe bitten. Das Lernen und Lehren kann eine erfüllende Tätigkeit für alle Beteiligten sein.

Öffentliche Ergebnisse zeugen von Ihrer Arbeit und fördern Ihren Ruf (und Ihre Karriere)

Per Definition ist Ihre gesamte Open-Source-Arbeit öffentlich. Sie erstellen automatisch ein Portfolio. So können Sie überall vorzeigen, was Sie zu leisten im Stande sind.

Sozialkompetenzen erlernen

Softwareentwicklung ist eine soziale Tätigkeit, und Open-Source-Projekte bieten Führungserfahrungen, denn es müssen z.B. Konflikte gelöst, Teams organisiert und Aufgaben priorisiert werden.

Es ist ermutigend, auch kleine Änderungen vornehmen zu können

Sie müssen nicht lebenslang an Open Source mithelfen. Haben Sie schon einmal einen Tippfehler auf einer Website gesehen und sich gewünscht, dass ihn jemand beheben würde? Bei einem Open-Source-Projekt können Sie genau das tun. Open Source hilft Leuten, selbst in die Hand zu nehmen, wie sie die Welt erleben, und das ist an sich schon befriedigend.

Was “einen Beitrag leisten” bedeutet

Wenn Sie gerade erst anfangen, Open-Source-Arbeit zu leisten, kann der Prozess einschüchternd wirken. Wie finden Sie das richtige Projekt? Was, wenn Sie nicht wissen, wie man programmiert? Was, wenn etwas schief geht?

Keine Sorge! Es gibt viele Möglichkeiten, zu einem Open-Source-Projekt beizutragen. Die folgenden paar Tipps helfen Ihnen, dabei gute Erfahrungen zu machen.

Sie brauchen keine Programmierkenntnisse

Ein weit verbreiteter Irrtum! Aber in Wirklichkeit sind es oft andere Projektaspekte, die am meisten Unterstützung benötigen. Sie tun dem Projekt einen großen Gefallen, indem Sie anbieten, bei nicht-Code-Aspekten mitzuwirken!

Auch wenn Sie gerne Code schreiben, gibt es vielleicht bessere Möglichkeiten, sich an einem Projekt zu beteiligen und andere Leute aus der Community zu treffen. Solche Beziehungen aufzubauen, ebnet Ihnen den Weg zur Mitarbeit an anderen Projektaspekten.

Planen Sie gerne Veranstaltungen?

  • Veranstalten Sie Workshops oder Meetups über das Projekt, wie @fzamperin für NodeSchool
  • Organisieren Sie die Projektkonferenz (falls vorhanden)
  • Unterstützen Sie die Community-Mitglieder dabei, die richtigen Konferenzen zu finden und dort Vortragsideen einzureichen.

Mögen Sie Design-Arbeit?

  • Verbessern Sie Layouts, um das Projekt benutzerfreundlicher zu machen
  • Führen Sie Nutzerstudien durch, um Navigation oder Menüs der Software zu verfeinern (wie z.B. Drupal es vorschlägt)
  • Erstellen Sie einen Designleitfaden, um dem Projekt zu einem einheitlichen visuellen Design zu verhelfen
  • Erstellen Sie Kunst für T-Shirts oder ein neues Logo, wie z.B. die Mitwirkenden von hapi.js

Schreiben Sie gerne?

  • Erstellen und verbessern Sie die Projektdokumentation
  • Erstellen Sie eine Übersicht von Anwendungsbeispielen, welche die Verwendungsmöglichkeiten der Software zeigen
  • Starten Sie einen Newsletter für das Projekt oder kuratieren Sie Highlights aus der Mailingliste
  • Schreiben Sie Tutorials für das Projekt, so wie die Mitwirkenden von PyPA
  • Übersetzen Sie die Projektdokumentation

Organisieren Sie gerne?

  • Verlinken Sie doppelte Issues und schlagen Sie neue Labels vor, um den Issue Tracker in Ordnung zu halten
  • Gehen Sie offene Issues durch und schlagen Sie alte zur Schließung vor, wie @nzakas in ESLint
  • Stellen Sie konstruktive Fragen zu kürzlich eingereichten Issues, um Diskussionen voranzubringen

Mögen Sie das Programmieren?

  • Finden Sie ein offenes Issue, das Sie bearbeiten können, wie @dianjin in Leaflet
  • Bieten Sie die Implementierung neuer Funktionen an
  • Automatisieren Sie etwas, z.B. die Softwareinstallation
  • Verbessern Sie Werkzeuge oder Tests

Helfen Sie gerne anderen Leuten?

  • Beantworten Sie Fragen zum Projekt, z.B. auf Stack Overflow (wie dieses Postgres-Beispiel zeigt) oder auf Reddit
  • Beantworten Sie Fragen in offenen Issues
  • Helfen Sie bei der Moderation von Diskussionsforen oder anderen Kommunikationskanälen

Helfen Sie gerne Anderen beim Programmieren?

  • Überprüfen Sie den Code in Pull Requests
  • Schreiben Sie Tutorials, wie ein Projekt verwendet werden kann
  • Bieten Sie einem Anderen Mentoring an, wie @ereichert für @bronzdoc in Rust

Es muss nicht immer ein Softwareprojekt sein!

Während sich “Open Source” oft auf Software bezieht, kann man an fast allen anderen Arten von Projekten zusammenarbeiten: Bücher, Rezepte, Listen, Kurse, uvm. werden als Open-Source-Projekte entwickelt.

Zum Beispiel:

Auch wenn Sie ein*e Software-Entwickler*in sind, kann Ihnen die Arbeit an einem Dokumentationsprojekt den Einstieg in Open Source erleichtern. Es ist oft weniger einschüchternd, an Projekten zu arbeiten, die keinen Code beinhalten, um Vertrauen und Erfahrung in den Zusammenarbeitsprozess als solchen zu stärken.

Sich in einem neuen Projekt orientieren

Für alles über eine Tippfehlerkorrektur hinaus ist ein Beitrag zu Open Source, als würde man sich zu einer Gruppe von Fremden auf einer Party gesellen. Wenn Sie anfangen, über Lamas zu reden, während die Anderen tief in einer Diskussion über Goldfische stecken, werden diese Sie wahrscheinlich ein wenig seltsam ansehen.

Bevor Sie blindlings mit Ihren eigenen Vorschlägen daherkommen, lernen Sie zunächst, die Situation einzuschätzen. Dies erhöht die Chancen, dass später Ihre Ideen wahrgenommen und gehört werden.

Anatomie eines Open-Source-Projekts

Jede Open-Source-Community ist anders.

Jahrelanges Arbeiten an einem Open-Source-Projekt bedeutet, dass Sie dieses eine kennengelernt haben. Wechseln Sie zu einem anderen Projekt, werden Sie feststellen, dass das Vokabular, die Normen und die Kommunikationsstile völlig unterschiedlich sein können.

Allerdings folgen viele Open-Source-Projekte einer ähnlichen Organisationsstruktur. Das Verständnis der verschiedenen Rollen in der Community und des Gesamtprozesses wird Ihnen helfen, sich schnell auf jedes neue Projekt einzustellen.

Ein typisches Open-Source-Projekt beinhaltet die folgenden Typen von Personen:

  • Autor*in: Die Person/en oder Organisation, die das Projekt erstellt hat/haben
  • Owners: Die Person/en, die administrativen Zugang zu der Organisation oder dem Repository hat/haben (nicht immer derselbe wie der/die ursprüngliche Autor*in).
  • Maintainers: Mitwirkende, die für die Umsetzung der Vision verantwortlich sind und für die organisatorischen Aspekte des Projekts. (Dies können auch Autoren oder Eigentümerinnen des Projekts sein.)
  • Contributors: Alle, die etwas zum Projekt beigetragen haben.
  • Community-Mitglieder: Personen, die das Projekt nutzen. Sie können in Diskussionen aktiv sein oder ihre Meinung über die Richtung des Projekts äußern.

Größere Projekte können auch Gremien oder Arbeitsgruppen haben, die sich auf verschiedene Aufgaben konzentrieren, wie z.B. Tooling, Triage, Community-Moderation und Eventorganisation. Suchen Sie auf der Website eines Projekts nach einer “Team”-Seite oder im Repository nach “Governance”-Dokumentation, um diese Informationen zu finden.

Ein Projekt hat auch eine Dokumentation. Diese Dateien werden in der Regel im Hauptverzeichnis eines Repositories aufgelistet.

  • LICENSE: Per Definition muss jedes Open-Source-Projekt eine Open-Source-Lizenz haben. Wenn das Projekt keine Lizenz hat, ist es nicht Open Source.
  • README: Die README ist die Bedienungsanleitung, die neue Community-Mitglieder im Projekt willkommen heißt. Sie erklärt, warum das Projekt nützlich ist, und wie man beginnen kann, es zu nutzen.
  • CONTRIBUTING: Während READMEs den Menschen helfen, das Ergebnis des Projektes zu nutzen, hilft die Kontributionsdokumentation dabei, zum Projekt beizutragen. Sie erklärt, welche Arten von Beiträgen benötigt werden und wie der Prozess funktioniert. Obwohl nicht jedes Projekt eine CONTRIBUTING-Datei hat, signalisiert ihre Präsenz, dass dieses Projekt offen für Beiträge ist.
  • CODE_OF_CONDUCT: Der Verhaltenskodex legt die Grundregeln für das Verhalten der Teilnehmer*innen fest und trägt dazu bei, ein freundliches und einladendes Umfeld zu schaffen. Obwohl nicht jedes Projekt eine CODE_OF_CONDUCT-Datei hat, signalisiert ihre Präsenz, dass dieses Projekt offen für Beiträge ist.
  • Andere Dokumentation: Es kann zusätzliche Tutorials, Walkthroughs oder Governance-Richtlinien geben, vor allem bei größeren Projekten.

Schließlich verwenden Open-Source-Projekte die folgenden Werkzeuge, um Diskussionen zu organisieren. Wenn Sie die Archive durchlesen, erhalten Sie ein gutes Bild davon, wie die Gemeinschaft denkt und arbeitet.

  • Issue Tracker: Hier diskutieren Personen über Themen, die im Zusammenhang mit dem Projekt stehen.
  • Pull Requests: Hier diskutieren und überprüfen Personen anstehende Änderungen.
  • Diskussionsforen oder Mailinglisten: Einige Projekte nutzen solche Kanäle für Konversationen (z.B. “Wie kann ich…“ oder “Was denkt ihr über…“) anstelle von Fehlerberichten oder Feature Requests. Andere verwenden den Issue Tracker für alle Konversationen.
  • Synchroner Chat-Kanal: Einige Projekte verwenden Kanäle wie z.B. Slack oder IRC für gelegentliche Gespräche, Zusammenarbeit und schnellen Austausch.

So finden Sie ein Projekt, zu dem Sie beitragen können

Sie haben gelernt, wie Open-Source-Projekte funktionieren. Jetzt ist es an der Zeit, ein Projekt zum Beitragen zu finden!

Wenn Sie noch nie zu Open Source beigetragen haben, nehmen Sie einen Ratschlag von US-Präsident John F. Kennedy an, der einmal sagte: _“Fragen Sie nicht, was Ihr Land für Sie tun kann - fragen Sie, was Sie für Ihr Land tun können”.

Zu Open Source können Sie auf allen möglichen Ebenen beitragen, in allen möglichen Projekten. Sie müssen nicht darüber nachdenken, was genau Ihr erster Beitrag sein wird oder wie er aussehen wird.

Denken Sie stattdessen zunächst über die Projekte nach, die Sie bereits verwenden oder verwenden möchten. Nach dieser Logik könnten dies die Projekte werden, zu denen Sie aktiv beitragen werden.

Innerhalb dieser Projekte, wann immer Sie sich denken, dass etwas besser oder anders sein könnte, handeln Sie nach Ihrem Instinkt.

Open Source ist kein exklusiver Club, sondern besteht auf Leuten wie Ihnen. “Open Source” ist nur ein schicker Begriff, um die Probleme der Welt als behebbar zu begreifen.

Sie können eine README überfliegen und einen defekten Link oder einen Tippfehler finden. Oder Sie sind ein*e neue*r Benutzer*in und haben bemerkt, dass etwas kaputt ist, oder ein Problem, das Ihrer Meinung nach wirklich dokumentiert sein sollte. Anstatt es zu ignorieren und weiterzuziehen oder jemand zu bitten, es zu reparieren, können Sie vielleicht selbst mitmachen und mithelfen. Das ist des Pudels Kern bei Open Source!

28% der Gelegenheitsbeiträge zu Open Source betreffen die Dokumentation (z.B. eine Korrektur der Rechtschreibung oder Formatierung, oder das Schreiben einer Übersetzung).

28% of casual contributions to open source are documentation, such as a typo fix, reformatting, or writing a translation.

Wenn Sie Issues suchen, die Sie beheben könnten, hat jedes Open-Source-Projekt eine Seite, die Neuling-freundliche Issues aufzeigt. Navigieren Sie zur Repository-Hauptseite auf GitHub und fügen Sie /contribute der URL hinzu (z.B.https://github.com/facebook/react/contribute).

Weiterhin, können Sie auf folgenden Seiten neue Projekte zum Beitragen entdecken (alle englischsprachig):

Eine Checkliste, bevor Sie einen Beitrag leisten

Wenn Sie ein Projekt gefunden haben, zu dem Sie beitragen möchten, prüfen Sie kurz, ob das Projekt Ihren Beitrag wahrscheinlich annehmen wird oder nicht. Sonst wird Ihre harte Arbeit vielleicht nicht fruchten.

Hier ist eine praktische Checkliste, um zu beurteilen, ob ein Projekt für neue Mitwirkende geeignet ist.

Erfüllt die Definition von Open Source

Das Projekt nimmt aktiv Beiträge entgegen

Sehen Sie sich die Commit-Aktivität auf dem Main Branch an. Auf GitHub können Sie diese Informationen auf der Repository-Hauptsite sehen.

Schauen Sie sich als nächstes die Issues des Projekts an.

Führen Sie nun die selben Schritte für die Pull Requests des Projekts durch.

Das Projekt ist einladend

Ein Projekt, das freundlich und einladend ist, signalisiert Offenheit gegenüber neuen Mitwirkenden.

Wie man einen Beitrag einreicht

Sie haben ein Projekt gefunden, das Ihnen gefällt und sind zum Leisten eines Beitrags bereit? Endlich! So erreichen Sie dies auf die richtige Art und Weise.

Effektive Kommunikation

Unabhängig davon, ob Sie ein*e einmalige*r Beitragende*r sind oder versuchen, einer Gemeinschaft beizutreten, ist die Zusammenarbeit mit anderen eine der wichtigsten Fähigkeiten, die Sie bei der Open-Source-Arbeit entwickeln werden.

Bevor Sie ein Issue oder einen Pull Request aufmachen oder eine Frage im Chat stellen, sollten Sie diese Punkte im Hinterkopf behalten, damit Ihre Ideen effektiv rüberkommen.

Erklären Sie den Kontext. Bringen Sie andere schnell auf den neuesten Stand. Wenn Sie auf einen Fehler stoßen, erklären Sie, was Sie zu tun versuchen und wie Sie ihn reproduzieren können. Wenn Sie eine neue Idee vorschlagen, erklären Sie deren Nutzen für das Projekt (nicht nur für Sie!).

😇 “X funktioniert nicht, wenn ich Y tue”

😢 “X ist kaputt! Bitte reparieren!”

Machen Sie Ihre Hausaufgaben vorher. Es ist OK, nichts zu wissen, aber zeigen Sie, dass Sie es versucht haben. Bevor Sie um Hilfe bitten, stellen Sie sicher, dass Sie die README, die Dokumentation, Issues (offene und geschlossene), die Mailingliste und das Internet nach einer Antwort durchsucht haben. Die Leute werden Lernversuche zu schätzen wissen.

😇 “Ich bin mir nicht sicher, wie man X implementiert. Ich habe die Hilfeseiten überprüft, aber X dort nicht erwähnt gefunden.”

😢 “Wie mache ich X?”

Halte Anfragen kurz und direkt. Ähnlich wie das Senden einer E-Mail, erfordert jeder Beitrag, egal wie einfach oder hilfreich er ist, eine Überprüfung durch jemand anderen. Viele Projekte haben mehr eingehende Anfragen als helfende Personen. Seien Sie kurz und bündig. Sie erhöhen die Chance, dass Ihnen jemand helfen kann.

😇 “Ich würde gerne eine API-Anleitung schreiben.”

😢 “Ich fuhr neulich auf der Autobahn und hielt zum Tanken an, und dann hatte ich diese erstaunliche Idee für etwas, was wir tun sollten, aber bevor ich das erkläre, lass mich dir etwas zeigen…“

Kommuniziere öffentlich. Obwohl es verlockend ist, sollten Sie sich nicht privat an Projektbetreuer*innen wenden, es sei denn, Sie müssen vertrauliche Informationen weitergeben (z.B. ein Sicherheitsproblem oder eine schwere Verletzung des Verhaltenskodex). Vom öffentlichen Austausch können mehr Menschen lernen und profitieren. Diskussionen können an sich schon Beiträge zum Projekt sein.

😇 (als Kommentar) “@-maintainer Hallo! Wie sollen wir dieses PR behandeln?”

😢 (als E-Mail) “Hallo, und t’schuldigung, dass ich per Mail schreibe, aber ich habe mich gefragt, ob Sie schon Zeit hatten, mein PR zu prüfen?”

Fragen stellen, ist OK (aber seien Sie geduldig!). Jeder war irgendwann einmal neu im Projekt, und selbst erfahrene Mitwirkende müssen sich auf den neuesten Stand bringen, wenn sie sich ein neues Projekt ansehen. Ebenso sind selbst langjährige Maintainer*innen nicht immer mit jedem Teil des Projekts vertraut. Zeigen Sie ihnen die gleiche Geduld, die Sie von ihnen erwarten würden.

😇 “Danke, dass Sie sich diesen Fehler angesehen haben. Ich bin Ihren Ratschlägen gefolgt. Hier ist die Ausgabe.”

😢 “Warum kannst Du mein Problem nicht lösen? Ist das nicht Dein Projekt?”

Respektieren Sie die Entscheidungen der Gemeinschaft. Ihre Ideen könnten von den Prioritäten oder der Vision der Gemeinschaft abweichen. Diese gibt Ihnen vielleicht eine Rückmeldung oder beschließt, Ihre Idee nicht weiterzuverfolgen. Auch wenn Sie Kompromisse suchen und besprechen sollten, müssen die Maintainer*innen mit einer Entscheidung länger leben als Sie selbst. Wenn Sie mit deren Richtung nicht einverstanden sind, können Sie jederzeit an Ihrem eigenen Fork arbeiten oder Ihr eigenes Projekt starten.

😇 “Ich bin enttäuscht, dass Sie meinen Anwendungsfall nicht unterstützen können, aber ich verstehe Ihre Erläuterung, dass er nur einen kleinen Teil der Benutzer*innen betrifft. Danke fürs Zuhören.”

😢 “Warum unterstützen Sie meinen Anwendungsfall nicht? Das ist inakzeptabel!”

Vor allem: Bewahren Sie Stil. Open Source besteht aus Menschen aus der ganzen Welt, die mit uns zusammenarbeiten. Nuancen gehen über Sprachen, Kulturen, Regionen und Zeitzonen hinweg verloren. Darüber hinaus erschwert die schriftliche Kommunikation die Vermittlung eines Tonfalls oder einer Stimmung. Nehmen Sie in Open-Source-Diskussionen gute Absichten an. Es ist in Ordnung, eine Idee höflich zurückzuweisen, nach Kontext zu fragen oder Ihre Position genauer zu erklären. Versuchen Sie einfach, das Internet als einen besseren Ort zu verlassen, als Sie es gefunden haben.

Erfassen Sie den Kontext

Bevor Sie etwas tun, sollten Sie kurz sicherstellen, dass Ihre Idee nicht schon an anderer Stelle besprochen wurde. Überfliegen Sie die README des Projekts, Issues (offen und geschlossen), die Mailingliste und Stack Overflow. Sie müssen nicht stundenlang alles durchgehen, aber eine schnelle Suche nach ein paar Schlüsselbegriffen bringt Sie weiter.

Wenn Sie Ihre Idee woanders nicht finden können, sind Sie bereit für den ersten Schritt. Wenn sich das Projekt auf GitHub befindet, werden Sie Ihre Idee vermutlich als Issue kommunizieren oder einen Pull Request erstellen:

  • Issues sind wie ein Gespräch oder eine Diskussion.
  • Pull Requests sind der Beginn der Arbeit an einer Lösung.
  • Eine unkomplizierte Kommunikation, wie z.B. die Klärung einer Vorgehensweise oder Frage, versuchen Sie es in Stack Overflow, IRC, Slack oder anderen Chat-Kanälen, falls das Projekt über solche verfügt.

Bevor Sie ein Issue oder einen Pull Request öffnen, überprüfen Sie die Beitragsdokumentationen des Projekts (normalerweise eine Datei namens CONTRIBUTING, oder in der README), um zu verstehen, was in Anfragen erwünscht ist. Beispielsweise kann das Projekt verlangen, dass Sie einer Vorlage folgen oder Tests verwenden.

Wenn Sie einen substantiellen Beitrag leisten wollen, öffnen Sie einen Issue, bevor Sie daran arbeiten. Bevor Sie Arbeiten ausführen, die möglicherweise nicht angenommen werden, schauen Sie sich das Projekt lieber eine Weile an (auf GitHub, auf “Watch” klicken, um über alle Konversationen informiert zu werden), und lernen die Community-Mitglieder kennen.

Ein Issue erstellen

In der Regel sollten Sie in den folgenden Situationen ein Issue erstellen:

  • Melden Sie einen Fehler, den Sie nicht selbst beheben können.
  • Diskutieren Sie ein übergeordnetes Thema oder eine Idee (z.B. über die Community, Vision oder Regelungen des Projekts).
  • Ein neues Feature oder eine andere Projektidee vorschlagen

Tipps für die Kommunikation zu Issues:

  • Wenn Sie ein offenes Issue sehen, das Sie in Angriff nehmen wollen, kommentieren Sie dies und lassen Sie die Leute wissen, dass Sie am Ball sind. Auf diese Weise ist es weniger wahrscheinlich, dass jemand eine Arbeit doppelt macht.
  • Wenn ein Issue vor einer Weile geöffnet wurde, ist es möglich, dass es woanders bearbeitet wird, oder bereits gelöst wurde. Daher bitten Sie um Bestätigung, bevor Sie mit der Arbeit beginnen.
  • Wenn Sie ein Issue geöffnet haben, aber die Antwort später selbst herausgefunden haben, kommentieren Sie das Issue, um anderen Leuten die Antwort mitzuteilen. Schließen Sie danach das Issue. Auch die Dokumentation dieses Ergebnisses ist ein Beitrag zum Projekt.

Einen Pull Request erstellen

In den folgenden Situationen sollten Sie in der Regel einen Pull Request öffnen:

  • Triviale Korrekturen einreichen (z.B. eines Tippfehlers, eines defekten Links oder eines offensichtlichen Fehlers)
  • Beginn der Arbeit an einem Beitrag, um den Sie bereits gebeten wurden oder den Sie bereits in einem Issue diskutiert haben.

Einen Pull Request muss keine fertige Arbeit darstellen. Es ist in der Regel besser, es frühzeitig zu starten, damit andere zuschauen oder Feedback zu Ihrem Fortschritt geben können. Markieren Sie es einfach als “WIP” (Work in Progress) in der Betreffzeile. Sie können später jederzeit weitere Commits hinzufügen.

Wenn das Projekt auf GitHub läuft, können Sie hier einen Pull Request stellen:

  • Forken Sie das Repository und klonen Sie es lokal. Verbinden Sie Ihr lokales mit dem ursprünglichen “upstream”-Repository, indem Sie es als Remote hinzufügen. Pullen Sie Änderungen von “upstream” möglichst oft, damit Sie auf dem Laufenden bleiben, und Konflikte beim Einreichen Ihres Pull Requests weniger wahrscheinlich werden. (detailliertere Anweisungen finden Sie hier.)
  • Erstellen Sie einen Branch für Ihre Änderungen.
  • Verweisen Sie auf relevante Issues oder unterstützende Dokumentation in Ihrem PR (z.B. “Closes #37”).
  • Fügen Sie Vorher-/Nachher-Bildschirmfotos hinzu, wenn Ihre Änderungen Unterschiede in HTML/CSS enthalten. Ziehen Sie die Bilder per Drag & Drop in den Textkörper Ihres Pull Requests.
  • Testen Sie Ihre Änderungen! Führen Sie vorhandene Tests aus und erstellen bei Bedarf neue. Egal ob es Tests gibt oder nicht, stellen Sie sicher, dass Ihre Änderungen das bestehende Projekt nicht brechen.
  • Tragen Sie im Stil des Projekts bei, nach bestem Wissen und Gewissen. Dies kann bedeuten, dass Sie Einrückungen, Semikolons oder Kommentare anders verwenden als in Ihrem eigenen Repository, aber es erleichtert dem oder der Betreuer*in das Zusammenführen, und anderen das Verständnis und die Pflege in der Zukunft.

Wenn dies Ihr erster Pull Request ist, sehen Sie sich Make a Pull Request an, die @kentcdodds als Video-Tutorial erstellt hat. Sie können auch üben, ein Pull Request in @Roshanjossey\s “First Contributions“-Repository zu erstellen.

Was passiert, nachdem Sie einen Beitrag eingereicht haben?

Geschafft! Herzlichen Glückwunsch, dass Sie zu einem Open-Source-Projekt beigetragen haben. Wir hoffen, dass weitere folgen.

Nachdem Sie einen Beitrag eingereicht haben, tritt einer der folgenden Fälle ein:

😭 Sie erhalten keine Antwort.

Hoffentlich haben Sie das Projekt auf Anzeichen von Aktivität überprüft, bevor Sie einen Beitrag leisten. Auch bei einem aktiven Projekt kann es jedoch vorkommen, dass Ihr Beitrag keine Resonanz findet.

Wenn Sie seit über einer Woche keine Antwort erhalten haben, ist es fair, nachzuhaken und höflich jemanden um eine Rezension zu bitten. Wenn Sie den Namen der richtigen Person kennen, um Ihren Beitrag zu überprüfen, können Sie sie oder ihn mit einem @ erwähnen.

Kontaktieren Sie diese Person nicht privat, denn öffentliche Kommunikation ist für Open-Source-Projekte unerlässlich.

Wenn Sie höflich nachhaken und trotzdem niemand antwortet, könnte dies für immer so bleiben. Es ist kein gutes Gefühl, aber lassen Sie sich davon nicht entmutigen. Sowas passiert allen mal! Es gibt viele mögliche Gründe und Umstände, die außerhalb Ihrer Kontrolle liegen, und die eine Antwort an Sie verhindert haben könnten. Versuchen Sie, ein anderes Projekt oder einen anderen Weg zu finden, um einen Beitrag zu leisten. Genau darum ist es ein guter Grund, nicht zu viel Zeit in Beiträge zu investieren, bevor nicht andere Mitglieder des Projektes auf Sie reagieren.

🚧 Jemand wünscht Änderungen an Ihrem Beitrag.

Es ist üblich, dass Sie aufgefordert werden, Änderungen an Ihrem Beitrag vorzunehmen, z.B. bezüglich des Umfangs Ihrer Idee oder bezüglich Ihres Code.

Wenn jemand Änderungen vorschlägt, reagieren Sie darauf. Der- oder diejenige hat sich die Zeit genommen, Ihren Beitrag zu überprüfen. Einen Pull Request zu eröffnen, aber nicht weiterzuverfolgen, ist schlechter Stil. Wenn Sie nicht wissen, wie Sie Änderungen vornehmen sollen, recherchieren Sie dies und bitten um Hilfe, wenn Sie sie brauchen.

Wenn Sie keine Zeit mehr haben, an dem Problem zu arbeiten (zum Beispiel, wenn das Thema seit Monaten vor sich hin brodelt aber sich Ihre Umstände geändert haben), lassen Sie es den Maintainer*in wissen, damit sie oder er keine Antwort erwartet. Vielleicht übernimmt jemand anderes Ihren Pull Request.

👎 Ihr Beitrag wird nicht angenommen.

Ihr Beitrag kann schlussendlich akzeptiert werden oder auch nicht. Hoffentlich haben Sie nicht schon zu viel Arbeit investiert. Wenn Sie nicht sicher sind, warum es nicht akzeptiert wurde, ist es durchaus sinnvoll, die oder den Maintainer*in um Rückmeldung und Erläuterung zu bitten. Letztendlich müssen Sie jedoch deren Entscheidung respektieren. Werden Sie nicht ausfallend. Sie haben immer die Möglichkeit, an Ihrem eigenen Fork des Projektes zu arbeiten, wenn Sie mit dem Original nicht einverstanden sind!

🎉 Ihr Beitrag wird angenommen.

Hurra! Sie haben erfolgreich einen Open-Source-Beitrag geleistet!

Sie haben es geschafft!

Egal, ob Sie gerade Ihren ersten Open-Source-Beitrag geleistet haben oder nach neuen Beitragsmöglichkeiten suchen: Wir hoffen, Sie zum Mitmachen motiviert zu haben. Selbst wenn Ihr Beitrag nicht angenommen wurde, vergessen Sie nicht, sich zu bedanken, wenn ein*e Projektbetreuer*in sich bemüht hat, Ihnen zu helfen. Open Source wird von Leuten wie Ihnen gemacht: Issue für Issue, Pull Request für Pull Request, usw., oder auch mal alle Neune auf einmal.