diff --git a/_articles/de/best-practices.md b/_articles/de/best-practices.md
new file mode 100644
index 00000000000..088900303a8
--- /dev/null
+++ b/_articles/de/best-practices.md
@@ -0,0 +1,315 @@
+---
+lang: de
+title: Gute Maintainer-Praxis
+description: Erleichtern Sie Ihr Leben als Open-Source-Maintainer! Von der Dokumentation von Prozessen bis zum Einsatz Ihrer Community.
+class: best-practices
+toc:
+ was-bedeutet-es-eine-software-instand-zu-halten: "Was bedeutet es, eine Software instand zu halten?"
+ dokumentieren-sie-ihre-prozesse: "Dokumentieren Sie Ihre Prozesse"
+ lernen-nein-zu-sagen: "Lernen, \"Nein\" zu sagen"
+ nutzen-sie-ihre-community: "Nutzen Sie Ihre Community"
+ delegieren-sie-an-bots: "Delegieren Sie an Bots"
+ es-ist-okay-pause-zu-machen: "Es ist okay, Pause zu machen"
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+ - metrics
+ - leadership
+---
+
+## Was bedeutet es, eine Software instand zu halten?
+
+Wenn Sie ein Open-Source-Projekt pflegen, welches viele Leute benutzen, haben Sie vielleicht bemerkt, dass Sie weniger programmieren und mehr auf Issues reagieren.
+
+In der Anfangsphase eines Projekts experimentieren Sie mit neuen Ideen und treffen Entscheidungen nach Ihren Wünschen. Da Ihr Projekt immer beliebter wird, werden Sie mehr mit Ihren Benutzer\*innen und Mitwirkenden zusammenarbeiten.
+
+Die Instandhaltung eines Projekts erfordert mehr als nur Code. Diese Aufgaben sind oft unerwartet, aber genauso wichtig für ein wachsendes Projekt. Wir haben einige Möglichkeiten zusammengestellt, um Ihnen das Leben zu erleichtern, von der Dokumentation von Prozessen bis hin zur Nutzung Ihrer Community.
+
+## Dokumentieren Sie Ihre Prozesse
+
+Dinge aufzuschreiben, ist eine der wichtigsten Aufgaben, die Sie als Maintainer\*in erledigt.
+
+Dokumentation verdeutlicht nicht nur Ihr eigenes Denken, sondern macht auch anderen Menschen verständlich, was Sie brauchen oder erwarten, bevor sie überhaupt fragen.
+
+Dinge aufzuschreiben, erleichtert das "Nein" sagen, wenn etwas nicht in Ihren Projektrahmen passt. Es macht es auch einfacher für die Menschen, mitzumachen und zu helfen. Sie wissen nie, wer Ihr Projekt lesen oder nutzen könnte.
+
+Selbst wenn Sie keine vollständigen Absätze niederschreiben: besser Stichworte aufzulisten, als gar nichts zu schreiben.
+
+Denken Sie daran, Ihre Dokumentation auf dem neuesten Stand zu halten. Wenn Sie dies nicht immer tun können, löschen Sie Veraltetes oder markieren es als solches, damit Mitwirkende wissen, dass Updates gerne angenommen werden.
+
+### Schreiben Sie Ihre Projektvision auf
+
+Schreiben Sie zunächst die Ziele Ihres Projekts auf. Fügen Sie sie Ihrer README hinzu oder erstellen Sie eine separate Datei namens VISION. Wenn es andere dafür nützliche Artefakte gibt (z.B. eine Projekt-Roadmap) machen Sie auch diese öffentlich.
+
+Eine klare, dokumentierte Vision hilft Ihnen, sich zu konzentrieren und den "Scope Creep" durch Beiträge anderer zu vermeiden.
+
+Zum Beispiel entdeckte @lord, dass eine Projektvision ihm herauszufinden half, in welche Anfragen er Zeit stecken sollte. Als frisch gebackener Maintainer bedauerte er, dass er sich nicht auf den Kern seines Projekts fokussiert hat, als er seine erste Feature-Anfrage für [Slate](https://github.com/lord/slate) erhielt.
+
+
+
+### Kommunizieren Sie Ihre Erwartungen
+
+Es kann nervenaufreibend sein, Regeln niederzuschreiben. Manchmal hat man das Gefühl, das Verhalten anderer Leute zu überwachen, oder ein Spaßverderber zu sein.
+
+Allerdings sind niedergeschriebene und fair durchgesetzte Regeln nützlich für Projektbetreuer\*innen. Sie verhindern, dass man in Dinge hineingezogen wird, die man nicht tun will.
+
+Die meisten Menschen, die auf Ihr Projekt stoßen, wissen nichts über Sie oder Ihre Lebensumstände. Sie vermuten vielleicht, dass Sie dafür bezahlt werden, daran zu arbeiten, insbesondere wenn sie Ihr Projekt regelmäßig benutzen und davon abhängig sind. Vielleicht haben Sie mal viel Zeit in Ihr Projekt gesteckt, sind aber jetzt mit einem neuen Job oder Familienmitglied beschäftigt.
+
+All das ist völlig in Ordnung! Stellen Sie nur sicher, dass andere davon erfahren.
+
+Wenn Sie Ihr Projekt in Teilzeit oder auf freiwilliger Basis betreuen, seien Sie ehrlich, wie viel Zeit Ihnen zur Verfügung steht. Die weicht vermutlich von der Zeit ab, die Ihrer Meinung nach für das Projekt benötigt wird, oder die andere erwarten.
+
+Hier sind ein paar Regeln, die es wert sind, aufgeschrieben zu werden:
+
+* Wie ein Beitrag geprüft und akzeptiert wird (_Benötigen sie Tests? Ein Issue-Template?_)
+* Die Arten von Beiträgen, die Sie akzeptieren werden (_Wollen Sie nur Hilfe bei einem bestimmten Teil Ihres Codes?_)
+* Wenn es angebracht ist, den Vorgang zu verfolgen (z.B. _"Sie können innerhalb von 7 Tagen eine Antwort von einer Betreuerin oder einem Betreuer erwarten. Wenn Sie bis dahin noch nichts gehört haben, können Sie gerne den Thread pingen."_)
+* Wie viel Zeit Sie für das Projekt aufwenden (z.B. _"Wir verbringen nur ca. 5 Stunden pro Woche für dieses Projekt"_)
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules) und [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) bspw. geben ihren Betreuer\*innen und Mitwirkenden nützliche Grundregeln mit.
+
+### Kommunikation öffentlich halten
+
+Vergessen Sie nicht, auch Ihre Interaktionen zu dokumentieren. Wo immer Sie können, halten Sie die Kommunikation über Ihr Projekt öffentlich. Wenn jemand versucht, Sie privat zu kontaktieren, um eine Feature- oder Support-Anfrage zu besprechen, verweisen Sie sich höflich an einen öffentlichen Kommunikationskanal, wie z.B. eine Mailingliste oder einen Issue Tracker.
+
+Wenn Sie sich mit anderen Betreuer\*innen treffen oder eine wichtige Entscheidung privat treffen, dokumentieren Sie diese Gespräche in der Öffentlichkeit, selbst wenn es nur um die Veröffentlichung einer Notiz geht.
+
+Auf diese Weise haben alle Neulinge in Ihrer Community die selben Informationsmöglichkeiten wie Alteingesessene.
+
+## Lernen, "Nein" zu sagen
+
+Sie haben Dinge aufgeschrieben, und im Idealfall würden auch alle Ihre Dokumentation lesen. Allerdings werden Sie in Wirklichkeit andere daran erinnern müssen, dass dieses Wissen existiert.
+
+Alles zu verschriftlichen hilft, persönliche Befindlichkeiten aus Situationen zu entfernen, in denen Sie Ihre Regeln durchsetzen müssen.
+
+"Nein" zu sagen macht keinen Spaß, aber _"Ihr Beitrag entspricht nicht den Kriterien dieses Projekts"_ fühlt sich weniger persönlich an als _"Ich mag Ihren Beitrag nicht"_.
+
+"Nein" zu sagen hilft in viele Situationen, in denen Sie als Maintainer\*in auftreten werden: unnötige Arbeit für andere erledigen, nicht in den Anwendungsbereich passende Feature-Anfragen, jemand zur Ordnung rufen, der eine Diskussion entgleist, usw.
+
+### Das Gespräch freundlich halten
+
+Die wichtigsten Orte, an denen Sie üben werden "Nein" zu sagen, sind Ihr Issue Tracker und die Pull-Request-Liste. Als Projektbetreuer\*in werden Sie unweigerlich Vorschläge erhalten, die Sie nicht akzeptieren wollen.
+
+Vielleicht verändert ein dort eingereichter Beitrag den Umfang Ihres Projekts oder passt nicht zu Ihrer Vision. Vielleicht ist die Idee gut, aber schlecht umgesetzt.
+
+Unabhängig vom Ablehnungsgrund ist es möglich, Beiträge, die nicht den Standards Ihres Projekts entsprechen, taktvoll zu behandeln.
+
+Wenn Sie einen Beitrag erhalten, den Sie nicht annehmen möchten, könnte Ihre erste Reaktion darin bestehen, ihn zu ignorieren oder so zu tun, als ob Sie ihn nicht gesehen hätten. Dies könnte die Gefühle anderer Personen verletzen und sogar andere potenzielle Mitwirkende in Ihrer Gemeinschaft demotivieren.
+
+
+
+Lassen Sie keinen unerwünschten Beitrag offen, weil Sie sich schuldig fühlen oder nett sein wollen. Im Laufe der Zeit werden unbeantwortete Issues und PRs die Projektarbeit stressiger und einschüchternder machen.
+
+Schließen Sie Beiträge lieber sofort, von denen Sie wissen, dass Sie sie nicht annehmen wollen. Wenn Ihr Projekt bereits unter einem großen Rückstand leidet, hat @steveklabnik Vorschläge für [eine effiziente Behandlung von Issues](http://words.steveklabnik.com/how-to-be-an-open-source-gardener) (Englisch).
+
+Zweitens sendet das Ignorieren von Beiträgen ein negatives Signal an die Gemeinschaft um Ihr Projekt. Einen Projektbeitrag einzureichen, kann einschüchternd sein, besonders für Neulinge. Auch wenn Sie ihren Beitrag nicht annehmen, danken Sie der einreichenden Person für ihr Interesse. Das ist ein großes Kompliment!
+
+Wenn Sie einen Betrag nicht annehmen wollen:
+
+* **Bedanken** Sie sich für den Beitrag.
+* **Erklären Sie, warum es nicht in den Rahmen des Projekts passt** und geben Sie klare Verbesserungsvorschläge, wenn Sie dazu in der Lage sind. Seien Sie dabei freundlich, aber bestimmt.
+* **Verlinken Sie auf die entsprechende Dokumentation**, wenn Sie diese haben. Wenn Sie wiederholt ähnliche Beiträge bekommen, die Sie nicht akzeptieren wollen, weisen Sie darauf in Ihrer Dokumentation hin, um weitere Wiederholungen zu vermeiden.
+* **Schließen Sie die Anfrage**
+
+Sie sollten nicht mehr als 1-2 Sätze benötigen, um zu antworten. Als beispielsweise ein Benutzer von [celery](https://github.com/celery/celery/) einen Windows-bezogenen Fehler meldete, [antwortet](https://github.com/celery/celery/issues/3383) @berkerpeksag mit:
+
+
+
+Wenn Ihnen der Gedanke, "Nein" zu sagen, Angst macht, sind Sie nicht allein. Wie @jessfraz [es formulierte](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> Ich habe mit Maintainern aus verschiedenen Open-Source-Projekten gesprochen, Mesos, Kubernetes, Chromium, und sie alle sind sich einig, dass einer der schwierigsten Aufgaben des Maintainertums darin besteht, "Nein" zu Patches zu sagen, die man nicht will.
+>
+> I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want.
+
+Fühlen Sie sich nicht schuldig, weil Sie den Beitrag von jemandem nicht annehmen wollen. Die erste Regel in Open-Source-Projekten, [nach](https://twitter.com/solomonstre/status/715277134978113536) @shykes lautet: "'Nein' ist vorübergehend. 'Ja' ist für immer." Obwohl es gut ist, sich in die Begeisterung einer anderen Person hineinzufühlen, ist die Ablehnung eines Beitrags nicht dasselbe wie die Ablehnung der Person dahinter.
+
+Wenn ein Beitrag nicht gut genug ist, sind Sie nicht verpflichtet, ihn anzunehmen. Seien Sie freundlich und reaktionsschnell, wenn Menschen zu Ihrem Projekt beitragen möchten. Aber akzeptieren Sie nur Änderungen, von denen Sie wirklich glauben, dass sie Ihr Projekt verbessern werden. Je öfter Sie "Nein" sagen, desto einfacher wird es. Versprochen.
+
+### Seien Sie proaktiv
+
+Um das Volumen der unerwünschten Beiträge zu reduzieren, erklären Sie den Prozess der Einreichung und Annahme von Beiträgen in einem "Contribution Guide".
+
+Wenn Sie zu viele minderwertige Beiträge erhalten, verlangen Sie zum Beispiel, dass die Mitwirkenden vorher ein wenig Arbeit leisten, z.B.:
+
+* eine Issue- oder PR-Vorlage/-Checkliste ausfüllen
+* ein Issue erstellen, bevor sie ein Pull Request einreichen
+
+Wer nicht Ihren Regeln folgt, dessen Issue können Sie sofort schließen und dabei auf Ihre Dokumentation verweisen.
+
+Auch wenn sich dieser Ansatz zunächst unfreundlich anfühlt, ist es für beide Seiten gut, proaktiv zu sein. Es verringert die Chance, dass jemand zu viele Arbeitsstunden in ein Pull Request vergeudete, das Sie nicht akzeptieren werden. Und es macht Ihre Arbeit einfacher zu verwalten.
+
+
+
+Manchmal, wenn Sie "Nein" sagen, kann Ihr potenzieller Mitwirkender verärgert sein oder Ihre Entscheidung kritisieren. Wenn deren Verhalten feindselig wird, unternehmen Sie [Schritte, um die Situation zu entschärfen](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) oder entfernen Sie sie sogar aus Ihrer Gemeinschaft, wenn keine Bereitschaft zur konstruktiven Zusammenarbeit erkennbar ist.
+
+### Mentorschaft etablieren
+
+Vielleicht reicht jemand in Ihrer Community regelmäßig Beiträge ein, die nicht den Standards Ihres Projekts entsprechen. Es kann für beide Seiten frustrierend sein, immer wieder Ablehnungen zu erfahren.
+
+Wenn Sie sehen, dass jemand von Ihrem Projekt begeistert ist, aber ein wenig aufpoliert werden muss, haben Sie Geduld. Erklären Sie in jeder Situation deutlich, warum ein Beitrag nicht den Erwartungen des Projekts entspricht. Versuchen Sie, sie auf eine einfachere oder weniger zweideutige Aufgabe hinzuweisen. Beispielsweise ein Problem, das mit _"good first issue"_ gekennzeichnet ist. Wenn Sie die Zeit dazu haben, erwägen Sie folgendes: Die oder den Mitwirkenden durch den ersten Beitragsprozess hindurch anzuleiten oder finden Sie in Ihrer Community jemanden, der/die zu einer solchen Betreuung bereit sein könnte.
+
+## Nutzen Sie Ihre Community
+
+Sie müssen nicht alles selbst machen. Die Gemeinschaft Ihres Projekts existiert aus einem bestimmten Grund! Auch wenn Sie noch keine aktiv Beitragenden haben: Viele Benutzer\*innen können Ihnen bei der Projektarbeit helfen.
+
+### Teilen Sie die Arbeitslast
+
+Wenn Sie auf der Suche nach Mitwirkenden sind, fragen Sie doch einfach mal herum.
+
+Wenn Sie neue Mitwirkende bemerken, die wiederholt Beiträge leisten, erkennen Sie deren Arbeit an, indem Sie ihnen mehr Verantwortung anbieten. Dokumentieren Sie, wie andere in Führungsrollen hineinwachsen können, wenn sie es wünschen.
+
+Andere zu ermutigen, [sich am Projekt zu beteiligen](../building-community/#teilen-sie-die-eigentümerschaft-an-ihrem-projekt), kann den eigenen Arbeitsaufwand erheblich reduzieren, wie @lmccart in ihrem Projekt [p5.js](https://github.com/processing/p5.js) feststellte.
+
+
+
+Wenn Sie sich aus Ihrem Projekt zurückziehen müssen (egal ob temporär oder auf Dauer), ist es keine Schande, jemand anders zu bitten, für Sie zu übernehmen.
+
+Wenn andere Leute von Ihrer Projektrichtung begeistert sind, gewähren Sie ihnen Commit-Rechte oder übergeben Sie formell die Kontrolle. Wenn jemand einen Fork Ihres Projektes erstellt hat, und es an anderer Stelle aktiv pflegt, sollten Sie in Erwägung ziehen, aus Ihrem ursprünglichen Projekt heraus auf den Fork zu verweisen. Es ist großartig, dass Menschen Ihr Projekt weiterleben sehen wollen!
+
+@progrium [fand heraus](http://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) (Englisch), dass es seinem Projekt [Dokku](https://github.com/dokku/dokku) auch nach seinem Rückzug weiter zu leben half, dass er die Vision dokumentiert hatte,
+
+> Ich habe eine Wiki-Seite geschrieben, die beschreibt, was ich wollte und warum ich es wollte. Aus irgendeinem Grund war es für mich eine Überraschung, dass die Maintainer\*innen das Projekt in diese Richtung bewegten! Ist es genau so passiert, wie ich es getan habe? Nicht immer. Aber sie brachten das Projekt trotzdem näher an das heran, was ich aufgeschrieben habe.
+>
+> I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I'd do it? Not always. But it still brought the project closer to what I wrote down.
+
+### Lassen Sie andere ihre eigenen Lösungen bauen
+
+Wenn ein potenzieller Mitwirkender eine andere Meinung über das Ziel Ihres Projekt hat, sollten Sie ihn oder sie vielleicht sanft ermutigen, an einem eigenem Fork zu arbeiten.
+
+Ein Projekt zu forken, muss keine schlechte Sache sein. Projekte kopieren und modifizieren zu können, ist eine der besten Möglichkeiten, die Open Source mitbringt. Ihre Community-Mitglieder zur Arbeit an eigenen Forks zu ermutigen, kann ein notwendiges Ventil für Kreativität bieten, die nicht mit der Vision Ihres Projekts in Konflikt gerät.
+
+
+
+Das Gleiche gilt für Benutzer\*innen, die wirklich eine Lösung haben möchten, deren Erstellung Sie einfach nicht leisten können. Das Anbieten von APIs und Plugin-Systemen kann anderen helfen, ihre eigenen Bedürfnisse zu erfüllen, ohne den Quellcode direkt ändern zu müssen. @orta [fand heraus](https://artsy.github.io/blog/2016/07/03/handling-big-projects/), dass Plugins für CocoaPods zu "einigen der interessantesten Ideen" führten:
+
+> Es ist fast unvermeidlich, dass Maintainer, sobald ein Projekt groß wird, viel konservativer werden müssen, was die Einführung von neuem Code angeht. Sie werden gut darin, "Nein" zu sagen, aber viele Menschen haben legitime Bedürfnisse. Verwandeln Sie also Ihr Werkzeug in eine Plattform.
+>
+> It's almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying "no", but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform.
+
+## Delegieren Sie an Bots
+
+So wie es Aufgaben gibt, die andere Menschen Ihnen abnehmen können, gibt es auch Aufgaben, die kein Mensch jemals zu erledigen haben sollte. Bots sind Ihre Freunde. Verwenden Sie sie, um sich Ihr Leben als Maintainer\*in zu erleichtern.
+
+### Verlangen Sie Tests und andere Kontrollen, um die Codequalität zu verbessern.
+
+Eine der wichtigsten Möglichkeiten, wie Sie Ihr Projekt automatisieren können, ist das Hinzufügen von Tests.
+
+Tests geben Mitwirkenden den Mut zu Änderungsvorschlägen, denn sie können nichts (unbemerkt) kaputt machen. Sie erleichtern es sich damit auch selbst, Beiträge schnell zu prüfen und anzunehmen. Je reaktionsschneller Sie sind, desto engagierter kann Ihre Gemeinschaft sein.
+
+Richten Sie automatische Tests ein, die bei allen eingehenden Beiträgen ausgeführt werden und stellen Sie sicher, dass Ihre Tests problemlos lokal von den Mitwirkenden ausgeführt werden können. Verlangen Sie, dass alle Codebeiträge Ihre Tests bestehen, bevor sie eingereicht werden können. Sie sichern einen Mindeststandards für die Qualität aller Einreichungen. [Verpflichtende Status-Checks](https://help.github.com/articles/about-required-status-checks/) auf GitHub können dazu beitragen, dass keine Änderungsvorschläge angenommen werden, die nicht Ihre Tests bestanden werden.
+
+Wenn Sie Tests hinzufügen, erklären Sie deren Funktionsweise in Ihrer CONTRIBUTING-Datei.
+
+
+
+### Automatisieren Sie grundlegende Wartungsaufgaben
+
+Viele Maintainer\*innen populärer Projekte sind mit ähnlichen Problemen konfrontiert, darum gibt es [viele fertig entwickelte Lösung](https://github.com/showcases/tools-for-open-source), die Wartungsarbeiten automatisieren können. Einige Beispiele:
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) automatisiert Ihre Veröffentlichungen
+* [mention-bot](https://github.com/facebook/mention-bot) erwähnt potentielle Reviewer für Pull Requests
+* [Danger](https://github.com/danger/danger) hilft bei der Automatisierung des Code Review
+
+Für Fehlerberichte und andere allgemeine Beiträge hat GitHub [Issue- und Pull-Request-Templates](https://github.com/blog/2111-issue-and-pull-request-templates), die Sie erstellen können, um die Kommunikation zu optimieren. @TalAter hat einen [Choose Your Own Adventure Guide](https://www.talater.com/open-source-templates/#/) erstellt, der Ihnen beim Schreiben dieser Vorlagen hilft.
+
+Um Ihre E-Mail-Benachrichtigungen zu verwalten, können Sie [E-Mail-Filter](https://github.com/blog/2203-email-updates-about-your-own-activity) so einrichten, dass sie nach Priorität sortiert werden.
+
+Wenn Sie etwas fortgeschrittener werden wollen, können Stilvorgaben und Linter die Projektbeiträge standardisieren, und so leichter überprüf- und akzeptierbar machen.
+
+Wenn Ihre Standards jedoch zu kompliziert sind, erhöht dies möglicherweise die Barriere für Mitwirkende. Stellen Sie sicher, dass Sie nur gerade genug Regeln einführen, um allen das Leben leichter zu machen.
+
+Wenn Sie sich nicht sicher sind, welche Tools Sie verwenden sollen, schauen Sie sich an, was andere beliebte Projekte tun, insbesondere die in Ihrem Ökosystem. Wie sieht beispielsweise der Beitragsprozess für andere Node-Module aus? Durch die Verwendung ähnlicher Tools und Ansätze wird Ihr Prozess auch für Ihre Zielgruppe vertrauter.
+
+## Es ist okay, Pause zu machen
+
+Open-Source-Arbeit hat Ihnen einmal Freude gemacht. Vielleicht bereitet sie Ihnen inzwischen Sorgen oder Schuldgefühle.
+
+Vielleicht fühlen Sie sich überfordert oder spüren eine wachsende Angst, wenn Sie an Ihre Projekte denken. Und in der Zwischenzeit häufen sich die Issues und Pull Requests.
+
+Burnout ist ein echtes und allgegenwärtiges Problem in der Open-Source-Arbeit, vor allem bei Maintainer\*innen. Dabei ist Ihr Wohlbefinden eine unabdingbare Voraussetzung für das Überleben eines jeden Open-Source-Projekts.
+
+Obwohl es gar nicht extra gesagt werden müsste: Machen Sie ruhig mal Urlaub! Sie sollten darauf nicht warten, bis Sie sich ausgebrannt fühlen. @brettcannon, ein Python Core Developer, entschied sich nach 14 Jahren freiwilliger OSS-Arbeit für einen [einmonatigen Urlaub](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/).
+
+Genau wie bei jeder anderen Art von Arbeit, werden Sie durch regelmäßige Pausen ausgeruht, glücklich und wieder gespannt auf Ihre Arbeit sein.
+
+
+
+Manchmal kann es schwierig sein, eine Pause von der Open-Source-Arbeit zu machen, wenn es sich so anfühlt, als ob alle Sie brauchen. Vielleicht versuchen die Leute Ihnen für Ihre Abwesenheit Schuldgefühle einzureden.
+
+Tun Sie Ihr Bestes, um Unterstützung für Ihre Benutzer\*innen und die Community zu finden, während Sie von einem Projekt weg sind. Wenn Sie nicht die Unterstützung finden, die Sie brauchen, machen Sie trotzdem eine Pause. Stellen Sie sicher, dass Sie kommunizieren, wann Sie nicht erreichbar sind, damit die Leute nicht durch Ihre mangelnde Reaktionsfähigkeit verwirrt werden.
+
+Pausen gelten nicht nur für den Urlaub. Wenn Sie keine Open-Source-Arbeit am Wochenende oder während der Arbeitszeit machen wollen, teilen Sie diese Erwartungen anderen mit, damit sie Sie nicht stören.
+
+## Achten Sie zuerst auf sich!
+
+Die Aufrechterhaltung eines beliebten Projekts erfordert andere Fähigkeiten als die früheren Phasen des Wachstums, aber es ist nicht weniger lohnend. Als Maintainer\*in üben Sie Führung und persönliche Fähigkeiten auf einem Niveau, das nur wenige Menschen erleben. Es ist zwar nicht immer einfach zu handhaben, aber klare Grenzen zu setzen und nur das zu übernehmen, womit Sie sich wohlfühlen, hilft Ihnen, glücklich, ausgeruht und produktiv zu bleiben.
diff --git a/_articles/de/building-community.md b/_articles/de/building-community.md
new file mode 100644
index 00000000000..c3d8abfad3f
--- /dev/null
+++ b/_articles/de/building-community.md
@@ -0,0 +1,315 @@
+---
+lang: de
+title: Offenherzige Gemeinschaften aufbauen
+description: Bauen Sie eine Community auf, die Menschen ermutigt, Ihr Projekt zu nutzen, zu unterstützen und weiter zu verbreiten.
+class: building
+toc:
+ ihr-projekt-zum-erfolg-führen: "Ihr Projekt zum Erfolg führen"
+ ihre-nutzergemeinschaft-vergrößern: "Ihre Nutzergemeinschaft vergrößern"
+ konflikte-beilegen: "Konflikte beilegen"
+order: 4
+image: /assets/images/cards/building.png
+related:
+ - best-practices
+ - coc
+---
+
+## Ihr Projekt zum Erfolg führen
+
+Ihr gerade gestartetes Projekt wird schon verbreitet und Leute schauen vorbei? Fantastisch! Wie überzeugen Sie sie, da zu bleiben?
+
+Eine einladende, offenherzige Gemeinschaft ist eine Investition in die Zukunft und in den Ruf Ihres Projekts. Wenn Ihr Projekt gerade erst die initialen Kontributionen erfährt, fangen Sie damit an, den frühen Kontributor\*innen eine positive Erfahrung zu bereiten, und machen Sie es ihnen leicht, wiederzukommen.
+
+### Geben Sie Leuten das Gefühl, willkommen zu sein
+
+Die Community Ihres Projekts kann nach @MikeMcQuaid als "Kontributorentrichter" ([contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel)) aufgefasst werden:
+
+
+
+Während Sie Ihre Community aufbauen, überlegen Sie sich, wie jemand am Eingang des Trichters (potenzielle\*r Benutzer\*in) theoretisch den Weg nach unten finden könnte (aktiver\* Mitstreiter\*in). Ihr Ziel ist es, jede Phase des Mithelfens möglichst reibungslos zu gestalten. Denn wenn die Leute "leichte Beute" machen können, ermutigt sie dies zu weiteren Beiträgen.
+
+Beginnen Sie mit der Dokumentation:
+
+* **Helfen Sie beim Einstieg in ihr Projekt.** [Eine freundliche README](../starting-a-project/#eine-readme-schreiben) und anschauliche Codebeispiele erleichtern Allen, die auf Ihr Projekt stoßen, den Einstieg.
+* **Erklären Sie in klaren Worten, wie Leute beitragen sollen**, bspw. in [einer CONTRIBUTING-Datei](../starting-a-project/#ihre-beitragsrichtlinien-aufschreiben), und indem Sie die Issues stets aktuell halten.
+
+[GitHubs 2017er Open-Source-Umfrage](http://opensourcesurvey.org/2017/) zeigte, dass unvollständige oder verwirrende Dokumentation das größte Problem für Open-Source-Anwender\*innen ist. Eine gute Dokumentation lädt zur Interaktion mit Ihrem Projekt ein. Wenn jemand ein Issue oder Pull Request erstellt, bietet sich für Sie die Möglichkeit, diese Person durch den Trichter zu bugsieren.
+
+* **Wenn Leute neu zu Ihrem Projekt hinzustoßen, danken Sie ihnen für ihr Interesse!** Ansonsten braucht es nur eine negative Erfahrung, um jemanden nachhaltig abzuschrecken.
+* **Antworten Sie schnell.** Wenn Sie einen Monat lang nicht auf jemandes Issue reagieren, ist es wahrscheinlich, dass diese Person Ihr Projekt bereits vergessen hat.
+* **Nehmen Sie verschiedener Beitragsarten an.** Viele Mitwirkende beginnen mit einem Fehlerbericht oder einer kleinen Korrektur: Es gibt [viele Möglichkeiten, einen Beitrag zu leisten](../how-to-contribute/#was-einen-beitrag-leisten-bedeutet) zu einem Projekt. Lassen Sie Leute so helfen, wie diese es möchten.
+* **Wenn es einen Beitrag gibt, mit dem Sie nicht einverstanden sind,** bedanken Sie sich trotzdem, aber [erklären warum](../best-practices/#lernen-nein-zu-sagen) die Idee nicht in den Projektrahmen passt. Verlinken Sie auf relevante Dokumentation, wenn vorhanden.
+
+
+
+Die Mehrheit der Open-Source-Mitwirkenden sind "Gelegenheitsmitwirkende": Personen, die nur gelegentlich an einem Projekt mitarbeiten. Möglicherweise haben sie nicht die Zeit, sich mit Ihrem Projekt vertraut zu machen. Daher ist es Ihre Aufgabe, es Leuten leicht zu machen, einen Beitrag zu leisten.
+
+Andere zur Mitarbeit zu ermutigen, ist auch eine Investition in sich selbst: Wenn Sie Ihre größten Fans dazu befähigen, mit an etwas zu arbeiten, das sie begeistert, stehen Sie unter weniger Druck, alles selbst zu erledigen.
+
+### Dokumentieren Sie alles
+
+
+
+Wenn Sie ein neues Projekt starten, mag es sich normal anfühlen, Ihre Arbeit privat zu halten. Aber Open-Source-Projekte gedeihen, wenn Sie Ihren Prozess öffentlich dokumentieren.
+
+Wenn Sie Dinge aufschreiben, können mehr Leute an jedem Schritt des Weges teilnehmen. Vielleicht bekommen Sie Hilfe zu etwas, von dem Sie nicht einmal wussten, dass Sie es brauchen.
+
+Dinge aufzuschreiben, ist mehr als nur technische Dokumentation. Wenn Sie den Drang verspüren, etwas aufzuschreiben oder Ihr Projekt privat zu diskutieren, fragen Sie sich, ob Sie es nicht doch öffentlich machen können.
+
+Seien Sie transparent was die Roadmap Ihres Projekts angeht, die Arten von Beiträgen, nach denen Sie suchen, wie Beiträge überprüft werden, oder warum Sie bisherige Entscheidungen so getroffen haben.
+
+Wenn Sie feststellen, dass mehrere Benutzer\*innen auf das gleiche Problem stoßen, dokumentieren Sie die Antworten in der README.
+
+Ziehen Sie in Betracht, Besprechungsnotizen oder Schlussfolgerungen zu veröffentlichen. Die Rückmeldungen, die Sie aufgrund dieser Transparenz erhalten, könnten Sie überraschen.
+
+Alles zu dokumentieren, gilt auch für Ihre Arbeit. Wenn Sie an einem umfangreichen Update Ihres Projekts arbeiten, erstellen Sie früh einen Pull Request und kennzeichnen Sie ihn als "Work in Progress" (WIP). So fühlen sich andere Personen frühzeitig in den Prozess eingebunden.
+
+### Antworten Sie schnell
+
+Wenn Sie [für Ihr Projekt werben](../finding-users), werden Leute Ihnen Rückmeldungen geben. Vielleicht in Form von Fragen, wie etwas in Ihrem Projekt funktioniert, oder sie brauchen Starthilfe bei der Benutzung.
+
+Versuchen Sie, schnell zu reagieren, wenn jemand ein Issue oder Pull Request einreicht, oder eine Frage zu Ihrem Projekt stellt. Eine schnell Antwort gibt den Leuten das Gefühl, an einem Dialog teilzunehmen, und das kann ermutigend wirken, weiter mitzuhelfen.
+
+Auch wenn Sie die Anfrage nicht sofort inhaltlich prüfen können, hilft die frühzeitige Bestätigung, das Engagement zu erhöhen. Ein Beispiel: @tdreyno reagiert auf einen Pull Request an [Middleman](https://github.com/middleman/middleman/pull/1466):
+
+
+
+[Eine Mozilla-Studie fand heraus, dass](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) Kontributor\*innen, deren Codebeitrag innerhalb von 48 Stunden überprüft wurde, deutlich häufiger nochmal mithalfen.
+
+Ihr Projekt kann an allen möglichen Stellen des Internets besprochen werden, wie z.B. auf Stack Overflow, Twitter oder Reddit. Dort können Sie Benachrichtigungen einrichten, um über Erwähnungen Ihres Projektes informiert zu werden.
+
+### Geben Sie Ihrer Gemeinschaft einen Ort, an dem sie sich versammeln kann.
+
+Es gibt zwei Gründe, Ihrer Gemeinschaft einen Ort der Begegnung zu geben.
+
+Der erste Grund ist, Menschen mit gemeinsamen Interessen zu helfen, sich kennenzulernen. Menschen mit gemeinsamen Interessen wollen sich zwangsläufig treffen können, um über diese zu reden. Wenn die Kommunikation öffentlich und zugänglich ist, kann jede\*r die Archive lesen, um sich auf den neuesten Stand zu bringen und sich daran zu beteiligen.
+
+Der zweite Grund nützt Ihnen selbst: Wenn Sie den Leuten _keinen_ öffentlichen Ort geben, um über Ihr Projekt zu sprechen, werden sie wahrscheinlich direkt mit Ihnen in Verbindung treten. Am Anfang mag es einfach erscheinen, hin und wieder mal auf private Nachrichten zu antworten, aber mit der Zeit, besonders wenn Ihr Projekt populär wird, werden Sie sich erschöpft fühlen und der Versuchung widerstehen, mit Leuten über Ihr Projekt privat zu kommunizieren, anstatt sie an einen bestimmten öffentlichen Kanal zu verweisen.
+
+Öffentliche Kommunikation kann ganz einfach sein: Bitten Sie Leute, ein Issue zu öffnen, anstatt Ihnen direkt eine E-Mail zu schreiben oder in Ihr Blog zu kommentieren. Sie können für Leute, die über Ihr Projekt sprechen möchten, auch eine Mailingliste einrichten oder einen Twitter-Account, einen Slack- oder IRC-Kanal. Oder all dies gleichzeitig ausprobieren!
+
+[Kubernetes' Kops](https://github.com/kubernetes/kops#getting-involved) legt alle zwei Wochen Bürozeiten fest, um den Mitgliedern der Gemeinschaft zu helfen:
+
+> Die Kops-Betreuer\*innen haben sich bereit erklärt, Zeit einzuplanen für die Arbeit mit Neuankömmlingen, die Unterstützung von Pull Requests, sowie für die Diskussion über neue Funktionen.
+>
+> Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features.
+
+Wichtige Ausnahmen von öffentlicher Kommunikation sind: 1) Sicherheitsprobleme und 2) Verstöße gegen den Verhaltenskodex; Sie sollten immer eine Möglichkeit anbieten, solche Probleme privat zu melden. Wenn Sie Ihre persönliche E-Mail-Adresse dafür nicht verwenden möchten, richten Sie eine dedizierte Adresse ein.
+
+## Ihre Nutzergemeinschaft vergrößern
+
+Eine Gemeinschaft kann sehr kraftvoll sein. Dies kann zu Segen und Fluch werden, je nach Art der Nutzung. Wenn die Projektgemeinschaft wächst, gibt es Möglichkeiten, ihr zu einer konstruktiven Kraft zu verhelfen, anstatt zu einer destruktiven.
+
+### Dulden Sie keine destruktiven Akteure
+
+Jedes populäre Projekt wird unweigerlich Menschen anziehen, die Ihrer Gemeinschaft mehr schaden als helfen. Beispielsweise indem Sie können unnötige Debatten starten, über triviale Dinge streiten oder andere schikanieren.
+
+Tun Sie Ihr Bestes, um eine Null-Toleranz-Politik gegenüber solchen Leuten zu verfolgen. Denn wenn obiges Verhalten unsanktioniert bleibt, werden andere Kontributor\*innen sich genervt fühlen und evtl. sogar Ihr Projekt verlassen.
+
+
+
+Regelmäßige Debatten über triviale Aspekte Ihres Projekts lenken alle davon ab, sich auf wichtige Aufgaben zu konzentrieren. Neue Leute, die zu Ihrem Projekt kommen, können diese Gespräche sehen und wollen nicht teilnehmen.
+
+Wenn Sie ein destruktives Verhalten in Ihrem Projekt beobachten, sprechen Sie es öffentlich an. Erklären Sie freundlich aber bestimmt, warum so etwas nicht akzeptabel ist. Wenn das Problem weiterbesteht, müssen Sie die [Verursacher\*innen bitten, das Projekt zu verlassen](../code-of-conduct/#ihre-verantwortung-als-maintainerin), Ihr [Verhaltenskodex](../code-of-conduct/) kann eine konstruktive Anleitung für solche Gespräche sein.
+
+### Holen Sie Mitwirkende dort ab, wo sie sich stehen
+
+Eine gute Dokumentation wird nur immer wichtiger, je mehr Ihre Community wächst. Gelegenheitskontributor\*innen, die mit Ihrem Projekt nicht vertraut sind, lesen Ihre Dokumentation, um schnell den nötigen Überblick zu bekommen.
+
+Geben Sie in Ihrer CONTRIBUTING-Datei explizit an, wie sie anfangen sollen. Vielleicht möchten Sie sogar eine eigene Sektion für diesen Zweck einrichten: [Django](https://github.com/django/django) zum Beispiel, hat eine spezielle Startseite, die neue Mitwirkende willkommen heißt.
+
+
+
+Die Liste der Issues sollte durchsortiert sein, Bugs z.B. als solche markiert, sowie Issues auch für unterschiedliche potentielle Kontributor\*innen: z.B. [_"first timers only"_](https://medium.com/@kentcdodds/first-timers-only-78281ea47455), _"good first issue"_, oder _"documentation"_. [Solche "Labels"](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) vereinfachen es Neuankömmlingen, sich in Ihrem Projekt zurechtzufinden und mit der Lösung eines Problems zu beginnen.
+
+Nicht zuletzt sollten Sie die Dokumentation nutzen, um Leute mit offenen Armen zu empfangen und ihnen Schritt-für-Schritt zu helfen.
+
+Sie werden mit den meisten Leuten, die auf Ihr Projekt stoßen nie interagieren. Ihnen könnten Beiträge entgehen, weil jemand sich eingeschüchtert fühlte, oder nicht herausfand, was es denn zu tun gab. Schon ein paar freundliche Worte können verhindern, dass jemand einfach weiter zieht.
+
+Zum Beispiel: [Rubinius](https://github.com/rubinius/rubinius/) beginnt [den Kontributionsratgeber](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md) mit:
+
+> Zum Einstieg möchten wir Dir erstmal unseren Dank aussprechen, dass Du Rubinius nutzt. Dieses Projekt wurde mit viel Liebe aufgebaut und wir schätzen alle Benutzer\*innen, die Fehler aufspüren, Geschwindigkeitsverbesserungen vornehmen und bei der Dokumentation helfen. Jeder Beitrag bedeutet uns etwas, also vielen Dank für Ihre Teilnahme! Wir bitten Sie jedoch, einige Richtlinien zu befolgen, damit wir Ihr Issue erfolgreich bearbeiten können.
+>
+> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.
+
+### Teilen Sie die Eigentümerschaft an Ihrem Projekt
+
+
+
+Leute sind begeistert davon, an Projekten mitzuwirken, wenn sie ein Gefühl für Verantwortung bekommen. Das bedeutet nicht, dass Sie Ihre Projektvision umdrehen müssen, oder Beiträge annehmen, die Sie nicht wollen. Je mehr Anerkennung Sie anderen Menschen jedoch zollen, desto eher werden diese bei Ihrem Projekt bleiben.
+
+Schauen Sie, ob Sie Wege finden können, Verantwortlichkeiten so weit wie möglich mit Ihren Projektteilnehmer\*innen zu teilen:
+
+* **Lassen Sie einfache (unkritische) Bugs unangetastet.** Nutzen Sie diese stattdessen als Gelegenheit, neue Mitwirkende zu rekrutieren, oder helfen Sie einem hilfsbereiten Neuling, den Prozess eines Bug-Fixes zu durchlaufen. Es mag zunächst unnatürlich erscheinen, aber Ihre Investition wird sich im Laufe der Zeit auszahlen. @michaeljoseph hat zum Beispiel einen Mitwirkenden gebeten, einen Pull Request zu einem der folgenden Probleme in [Cookiecutter](https://github.com/audreyr/cookiecutter) zu stellen, anstatt es selbst zu beheben.
+
+
+
+* **Führen Sie eine CONTRIBUTORS- oder AUTHORS-Datei in Ihrem Projekt**, die alle Leute aufzählt, die einen Beitrag geleistet haben, wie z.B. bei [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md).
+
+* Wenn Sie schon eine etwas größere Gemeinschaft versammelt haben, **senden Sie eine Rundmail oder schreiben ins Blog**, dass Sie Kontributor\*innen danken. Rusts [This Week in Rust](https://this-week-in-rust.org/) und Hoodies [Shoutout-Grüße](http://hood.ie/blog/shoutouts-week-24.html) sind zwei gute Beispiele dafür.
+
+* **Geben Sie allen Kontributor\*innen Schreibzugriff.** @felixge fand heraus, dass dies Leute [zu mehr Feinschliff ihrer Beiträge anspornt](https://felixge.de/2013/03/11/the-pull-request-hack.html), und gewann sogar neue Maintainer\*innen für Projekte, an denen er selbst schon eine Weile nicht mehr arbeitete.
+
+* Wenn Ihr Projekt auf GitHub liegt, **verschieben Sie es von Ihrem Privat-Konto in das einer [Organisation](https://help.github.com/articles/creating-a-new-organization-account/)** und fügen Sie zur Sicherheit mindestens eine\*n weitere\*n Administrator\*in hinzu. Organisationen machen die Zusammenarbeit mit externen Mithelfenden einfacher.
+
+Realistischerweise haben [die meisten Projekte](https://peerj.com/preprints/1233.pdf) nur einen oder zwei Verantwortliche, welche die meiste Arbeit erledigen. Ja größer Ihr Projekt, und je größer seine Nutzer\*innengemeinschaft, desteo einfacher wird es sein, Hilfe zu finden.
+
+Während Sie vielleicht nicht immer Leute finden, die einem Aufruf folgen, erhöht so ein Signals doch die Wahrscheinlichkeit, dass Andere mitmachen. Je früher Sie damit anfangen, desto eher können die Leute helfen.
+
+
+
+## Konflikte beilegen
+
+In der Anfangsphase Ihres Projekts ist es einfach, wichtige Entscheidungen zu treffen: Wenn Sie etwas tun wollen, dann tun Sie es einfach.
+
+Je beliebter Ihr Projekt wird, desto mehr Menschen werden sich für von Ihnen getroffene Entscheidungen interessieren. Selbst wenn Sie keine große Gemeinschaft von Mitwirkenden haben: Wenn Ihr Projekt viele Benutzer\*innen hat, werden darunter Leute sein, die sich über Entscheidungen auslassen oder ihre eigenen Themen ansprechen.
+
+Wenn Sie eine freundliche, respektvolle Gemeinschaft gepflegt und Ihre Prozesse offen dokumentiert haben, sollten Alle zur Lösungsfindung in der Lage sein. Aber manchmal stoßen Sie auf ein Problem, das etwas schwieriger zu lösen ist.
+
+### Setzen Sie die Messlatte für Freundlichkeit
+
+Wenn sich Ihre Gemeinschaft mit einem schwierigen Thema auseinandersetzt, können sich Gemüter schnell mal erhitzen. Menschen können wütend oder frustriert werden und es an Anderen oder an Ihnen auslassen.
+
+Ihre Aufgabe als Maintainer\*in ist es, solche Situationen vor einer Eskalation zu bewahren. Selbst wenn Sie eine klare eigene Meinung zu diesem Thema haben, versuchen Sie, die moderierende Position einzunehmen, anstatt sich in den Kampf zu stürzen und Ihre Ansichten durchzusetzen. Wenn jemand unfreundlich wird oder das Gespräch an sich reißt, [handeln Sie sofort](../building-community/#dulden-sie-keine-destruktiven-akteure), um die Diskussionen zivil und produktiv zu halten.
+
+
+
+Andere Leute erwarten von Ihnen, ein gutes Beispiel abzugeben. Sie können immer noch Enttäuschung, Unzufriedenheit oder Besorgnis ausdrücken, aber tun Sie dies auf eine ruhige Art und Weise.
+
+Es ist nicht einfach, einen kühlen Kopf zu bewahren, aber Führung zu zeigen, verbessert die Gesundheit der Gemeinschaft. Das Internet wird es Ihnen danken!
+
+### Nutzen Sie die README als Verfassung
+
+Ihre README-Datei ist [mehr als nur eine Anleitung](../starting-a-project/#eine-readme-schreiben). Sie ist auch das Dokument, das Ihre Ziele, Ihre Produktvision und Ihre Roadmap aufzeigt. Wenn die Leute sich zu sehr darauf konzentrieren, über die Vorzüge einer bestimmten Funktion zu diskutieren, kann es helfen, Ihre README zu überprüfen und das überragende Ziel Ihres Projekts anzusprechen. Der Verweis auf Ihre README entpersönlicht eine Diskussion auch, sodass Sie wieder konstruktiver geführt werden kann.
+
+### Der Weg ist das Ziel
+
+Einige Projekte nutzen einen Abstimmungsprozess, um wichtige Entscheidungen zu treffen. Auf den ersten Blick ist es sinnvoll, so eine Antwort zu finden, anstatt sich gegenseitig zuzuhören und auf die Sichtweisen Anderer einzugehen.
+
+Abstimmungen können aber politisch werden, wenn sich die Community-Mitglieder unter Druck gesetzt fühlen, sich gegenseitig einen Gefallen zu tun oder auf eine bestimmte Wahl zu treffen. Außerdem stimmt nicht jede\*r mit ab, z.B. weil es ein [stille Mehrheit](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in Ihrer Gemeinschaft geben könnte, oder neue Benutzer\*innen einfach nicht wussten, dass eine Abstimmung stattfindet.
+
+Manchmal ist eine Abstimmung notwendig, um ein Patt aufzulösen. Aber soviel Sie können, betonen Sie die [Konsensfindung](https://de.wikipedia.org/wiki/Konsensprinzip) statt des Konsenses an sich.
+
+Im Rahmen der Konsensfindungsprozesses diskutieren die Mitglieder der Gemeinschaft wichtige Anliegen, bis sie das Gefühl haben, angemessen gehört worden zu sein, und wenn nur noch geringe Bedenken bestehen, kommt die Gemeinschaft voran. Die Konsensfindung erkennt an, dass eine Gemeinschaft möglicherweise keine perfekte Antwort finden kann. Stattdessen priorisiert sie das Zuhören und die Diskussion.
+
+
+
+Auch wenn Sie als Projektbetreuer\*in keine Konsensfindung betreiben möchten, ist es wichtig, dass die Leute ein offenes Ohr bei Ihnen finden. Anderen zuzuhören, und sich für die Lösung ihrer Probleme einzusetzen, hilft beim Entschärfen sensibler Situationen sehr. Lassen Sie Ihren Worten aber auch Taten folgen.
+
+Überstürzen Sie Entscheidungen nicht, nur um eine Lösung herbeizuführen. Stellen Sie sicher, dass jede\*r sich gehört fühlt und dass alle Informationen öffentlich gemacht wurden, bevor Sie sich auf eine Entscheidung zubewegen.
+
+### Halten Sie Diskussionen fokussiert auf Aktionen
+
+Diskussionen sind wichtig, aber es gibt einen Unterschied zwischen produktiven und unproduktiven Gesprächen.
+
+Fördern Sie Diskussionen, die sich aktiv auf eine Lösung zubewegen: Wenn klar ist, dass Dinge zerredet werden, oder die Konversation vom Thema abweicht, persönliche Anfeindungen passieren, oder die Leute sich über kleine Details streiten, ist es Zeit für eine Beendigung der Diskussion.
+
+Die Fortsetzung solcher Diskussionen ist nicht nur schlecht für das jeweilige Thema, sondern auch für die Gesundheit Ihrer Gemeinschaft. Die Botschaft zu vermitteln, dass unproduktive Diskussionen erlaubt oder sogar gefördert werden, könnte Leute zukünftig davon abgehalten werden, Probleme anzusprechen oder zu lösen.
+
+Bei jedem Diskussionsbeitrag ihrerseits, oder von Anderen, sollten Sie sich fragen _"Wie bringt uns dies einer Lösung näher?"_
+
+Falls die Diskussion abdriftet, fragen Sie die Teilnehmer\*innen: _"Welche Schritte sollten wir als nächstes gehen?"_ um sie wieder zu fokussieren.
+
+Wenn eine Diskussion offensichtlich nirgendwo hinführt, es keine klaren Maßnahmen zu ergreifen gibt, oder schon welche ergriffen wurden, schließen Sie das Issue und erklären Sie, warum Sie es geschlossen haben.
+
+
+
+### Wählen Sie Auseinandersetzungen mit Bedacht
+
+Der Kontext ist wichtig: Überlegen Sie, wer an der Diskussion beteiligt ist und wie die Diskutanten den Rest der Gemeinschaft repräsentieren.
+
+Ist jeder in der Community verärgert oder gar mit diesem Thema beschäftigt? Oder ist er ein\*e einzelner Unruhestifter\*in? Berücksichtigen Sie nicht nur die Aktiven, sondern vergessen Sie Ihre stillen Community-Mitglieder nicht.
+
+Wenn das Thema nicht die breiteren Bedürfnisse Ihrer Gemeinschaft widerspiegelt, müssen Sie vielleicht nur die Sorgen einiger Weniger anerkennen. Wenn es sich um ein wiederkehrendes Problem ohne klare Lösung handelt, weisen Sie sie auf frühere Diskussionen hin und schließen Sie das Issue.
+
+### Identifizieren Sie einen Community-Tiebreaker
+
+Mit einer positiven Herangehensweise und klarer Kommunikation sind die schwierigsten Situationen lösbar. Aber auch in einem produktiven Gespräch kann es einfach zu Meinungsverschiedenheiten kommen. Identifizieren Sie dann eine Person oder Gruppe, die quasi als Schiedsrichter\*in fungieren kann.
+
+Ein\*e solche\*r Schiedsrichter\*in kann die oder der Hauptverantwortliche für das Projekt sein, oder eine kleine Gruppe von Leuten, die über eine Entscheidung abstimmen. Idealerweise haben Sie einen Tiebreaker und den damit verbundenen Prozess in einer GOVERNANCE-Datei identifiziert, bevor Sie diese verwenden müssen.
+
+Ihr\*e Schiedsrichter\*in sollte der letzte Ausweg sein, denn zunächst entzweiend wirkende Probleme sind eine Chance für Ihre Gemeinschaft, zu wachsen und zu lernen. Nutzen Sie diese Möglichkeiten, um in einem gemeinsamen Prozess zu einer Lösung zu kommen, wo immer dies möglich ist.
+
+## Das ❤️ von Open-Source sind Gemeinschaften
+
+Gesunde, blühende Gemeinschaften sorgen für den Antrieb für Tausende von Stunden, die jede Woche in Open-Source gesteckt werden. Viele Mitwirkende verweisen auf andere Menschen als Grund dafür, an Open-Source zu arbeiten (oder eben nicht). Indem Sie lernen, diese Kraft konstruktiv zu nutzen, werden Sie jemandem da draußen helfen, ein unvergessliches Open-Source-Erlebnis zu haben.
diff --git a/_articles/de/code-of-conduct.md b/_articles/de/code-of-conduct.md
new file mode 100644
index 00000000000..3805ba701a7
--- /dev/null
+++ b/_articles/de/code-of-conduct.md
@@ -0,0 +1,130 @@
+---
+lang: de
+title: Ihr Verhaltenskodex
+description: Fördern Sie ein gesundes und konstruktives Miteinander durch die Festlegung und Durchsetzung eines Verhaltenskodex.
+class: coc
+toc:
+ warum-brauche-ich-einen-verhaltenskodex: "Warum brauche ich einen Verhaltenskodex?"
+ einen-verhaltenskodex-festlegen: "Einen Verhaltenskodex festlegen"
+ entscheiden-wie-sie-ihren-verhaltenskodex-durchsetzen: "Entscheiden, wie Sie Ihren Verhaltenskodex durchsetzen."
+ ergreifen-sie-geeignete-maßnahmen: "Ergreifen Sie geeignete Maßnahmen"
+ ihre-verantwortung-als-maintainerin: "Ihre Verantwortung als Maintainerin"
+order: 8
+image: /assets/images/cards/coc.png
+related:
+ - building
+ - leadership
+---
+
+## Warum brauche ich einen Verhaltenskodex?
+
+Ein Verhaltenskodex ist ein Dokument, das die Erwartungen an das Verhalten der Projektteilnehmer\*innen festlegt. Einen Verhaltenskodex festzulegen und durchzusetzen, kann dazu beitragen, eine positive soziale Atmosphäre für Ihre Community zu schaffen.
+
+Verhaltenskodizes schützen nicht nur Ihre Teilnehmer\*innen, sondern auch Sie selbst. Wenn Sie ein Projekt pflegen, werden Sie vielleicht feststellen, dass unproduktive Einstellungen von anderen dazu führen können, dass Sie sich im Laufe der Zeit ausgelaugt oder unglücklich über Ihre Arbeit fühlen.
+
+Ein Verhaltenskodex bevollmächtigt Sie, ein gesundes, konstruktives Miteinander zu fördern. Proaktiv zu sein, verringert die Wahrscheinlichkeit, dass Sie oder andere projektmüde werden, und hilft Ihnen, Maßnahmen gegen unerwünschtes Verhalten zu ergreifen.
+
+## Einen Verhaltenskodex festlegen
+
+Versuchen Sie, so früh wie möglich einen Verhaltenskodex festzulegen: idealerweise, sobald Sie Ihr Projekt starten.
+
+Neben der Klarstellung Ihrer Erwartungen beschreibt ein Verhaltenskodex Folgendes:
+
+* Wo er gilt _(nur für Issue und Pull Requests oder auch bei Community-Veranstaltungen?)_
+* Für wen er gilt _(Community-Mitglieder und Maintainer\*innen; Aber was ist mit den Sponsor\*innen?)_
+* Was passiert, wenn jemand gegen ihn verstößt
+* Wie jemand Verstöße melden kann
+
+Wo immer Sie können, nutzen Sie Vorhandenes. Der [Contributor Covenant](https://contributor-covenant.org/) ist ein Verhaltenskodex, der von über 40.000 Open-Source-Projekten wie Kubernetes, Rails und Swift verwendet wird.
+
+Der [Django-Verhaltenskodex](https://www.djangoproject.com/conduct/) und der [Citizen Code of Conduct](http://citizencodeofconduct.org/) sind ebenfalls zwei gute Beispiele.
+
+Legen Sie eine CODE_OF_CONDUCT-Datei in das Stammverzeichnis Ihres Projekts und machen Sie sie für Ihre Community sichtbar, indem Sie sie von Ihrer CONTRIBUTING- oder README-Datei verlinken.
+
+## Entscheiden, wie Sie Ihren Verhaltenskodex durchsetzen.
+
+
+
+Sie sollten erklären, wie Ihr Verhaltenskodex durchgesetzt wird, **_bevor_** es zu einem Verstoß kommt. Dafür gibt es mehrere Gründe:
+
+* Es zeigt, dass Sie es mit Maßnahmen ernst meinen, wenn sie gebraucht werden.
+
+* Ihre Community wird sich sicherer fühlen, dass Beschwerden tatsächlich geprüft werden.
+
+* Sie vergewissern Ihre Community, dass der Überprüfungsprozess fair und transparent ist, sollte es jemals zu einem Verstoß kommen.
+
+Sie sollten Leuten einen privaten Weg (z.B. eine E-Mail-Adresse) geben, um einen Verstoß gegen den Verhaltenskodex zu melden und erklären, wer diesen Bericht erhält. Es kann ein\*e Maintainer\*in, eine Gruppe von Maintainer\*innen oder eine Verhaltenskodex-Arbeitsgruppe sein.
+
+Vergessen Sie nicht, dass jemand einen Verstoß über eine Person melden können möchte, die diese Berichte erhält. Bieten Sie in diesem Fall die Möglichkeit, Verstöße an eine andere Person zu melden. @ctb und @mr-c zum Beispiel [erklären zu ihrem Projekt](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Fälle von missbräuchlichem, belästigendem oder anderweitig inakzeptablem Verhalten können per E-Mail an **khmer-project@idyll.org** gemeldet werden, die nur an C. Titus Brown und Michael R. Crusoe geht. Um ein Problem zu melden, das einen von ihnen betrifft, senden Sie bitte eine E-Mail an **Judi Brown Clarke, Ph.D.** den Diversity Director am BEACON Center for the Study of Evolution in Action, einem NSF Center for Science and Technology.*
+>
+> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*
+
+Django's [Enforcement Manual](https://www.djangoproject.com/conduct/enforcement-manual/) dürfte für Sie eine gute Vorlage liefern, auch wenn Sie für ein kleineres Projekt vielleicht weniger umfassende Regeln benötigen.
+
+## Durchsetzung Ihres Verhaltenskodexes
+
+Manchmal wird jemand trotz Ihrer Bemühungen etwas tun, das gegen diesen Kodex verstößt. Es gibt mehrere Möglichkeiten, negatives oder schädliches Verhalten zu bekämpfen, wenn es auftritt.
+
+### Sammeln Sie Informationen über die Situation.
+
+Nehmen Sie jede Stimme aus der Community so wichtig wie Ihre eigene. Wenn Sie einen Bericht erhalten, dass jemand gegen den Verhaltenskodex verstoßen hat, nehmen Sie ihn oder sie ernst und untersuchen Sie die Angelegenheit, auch wenn sie nicht Ihren eigenen Erfahrungen mit dieser Person entspricht. Damit signalisieren Sie Ihrer Gemeinschaft, dass Sie ihre Perspektive schätzen und ihrem Urteilsvermögen vertrauen.
+
+Das betroffene Community-Mitglied kann ein\*e Wiederholungstäter\*in sein, der oder die anderen immer wieder Ärger bereitet, oder es hat nur einmal etwas gesagt oder getan. Beides kann je nach Kontext Anlass zum Handeln sein.
+
+Bevor Sie antworten, geben Sie sich Zeit, um zu verstehen, was passiert ist. Lesen Sie die bisherigen Kommentare und Gespräche der Person durch, um besser zu verstehen, wer es ist und warum sie oder er so gehandelt haben könnten. Versuchen Sie, andere Perspektiven als Ihre eigenen über diese Person und ihr Verhalten zu sammeln.
+
+
+
+### Ergreifen Sie geeignete Maßnahmen
+
+Nachdem Sie genügend Informationen gesammelt und verstanden haben, müssen Sie entscheiden, was zu tun ist. Denken Sie bei Ihren nächsten Schritten daran, dass es Ihr Ziel als Moderator\*in ist, eine sichere, respektvolle und kollaborative Umgebung zu fördern. Überlegen Sie nicht nur, wie Sie mit dieser Situation umgehen, sondern auch, wie sich Ihre Reaktion auf das Verhalten und die Erwartungen Ihrer Community auswirken könnte.
+
+Wenn jemand einen Verstoß gegen einen Verhaltenskodex meldet, sind Sie gefragt, nicht die Community. Manchmal enthüllt die oder der Meldende Informationen, die eine große Gefahr für Karriere, Ruf oder körperliche Unversehrtheit darstellen. Sie oder ihn zu zwingen, den Gemeldeten zu konfrontieren, könnte eine kompromittierende Situation erzeugen. Sie sollten die direkte Kommunikation mit der gemeldeten Person übernehmen, es sei denn, die oder der Meldende verlangt ausdrücklich etwas anderes.
+
+Es gibt einige Möglichkeiten, wie Sie auf einen Verstoß gegen den Verhaltenskodex reagieren können:
+
+* **Geben Sie der betreffenden Person eine öffentliche Warnung** und erklären Sie, wie sich sein oder ihr Verhalten negativ auf andere ausgewirkt hat. Nutzen Sie dafür vorzugsweise den Kommunikationskanal, auf dem das schädliche Verhalten aufgetreten ist. Öffentliche Kommunikation zeigt dem Rest der Gemeinschaft, dass Sie den Verhaltenskodex ernst nehmen. Seien Sie freundlich, aber bestimmt.
+
+* **Privat auf die betreffende Person zugehen**, um zu erklären, wie sich ihr oder sein Verhalten negativ auf andere ausgewirkt hat. Sie können einen privaten Kommunikationskanal verwenden, wenn es sich um sensible persönliche Daten handelt. Wenn Sie mit jemandem privat kommunizieren, setzen Sie die meldende Person darüber in Kenntnis. Aber setzen Sie sie bei E-Mails nicht ohne Erlaubnis in CC.
+
+Manchmal kann keine Lösung erreicht werden. Die gemeldete Person kann aggressiv oder feindselig werden, wenn er oder sie damit konfrontiert wird oder das Verhalten nicht ändert. In dieser Situation sollten Sie vielleicht stärkere Maßnahmen in Betracht ziehen. Zum Beispiel:
+
+* **zeitweise Suspendierung** in Form eines vorübergehenden Verbots, sich an den Aspekten des Projekts zu beteiligen.
+
+* Die Person **dauerhaft aus dem Projekt verbannen**.
+
+Projektteilnehmer\*innen auszuschließen, sollte nicht auf die leichte Schulter genommen werden, da es eine permanente und unvereinbare Meinungsverschiedenheit darstellt. Sie sollten diese Maßnahmen nur ergreifen, wenn klar ist, dass eine Lösung nicht möglich ist.
+
+## Ihre Verantwortung als Maintainerin
+
+Ein Verhaltenskodex sollte nicht willkürlich durchgesetzt werden. Sie sind der oder die Vollstrecker\*in des Verhaltenskodexes und es ist Ihre Verantwortung, diese Regeln auch zu befolgen.
+
+Als Maintainer\*in legen Sie die Richtlinien für Ihre Community fest und setzen diese durch. Dies bedeutet, dass jeder Bericht über einen Verstoß gegen den Verhaltenskodex ernst genommen wird. Dem oder der Beschwerdeführer\*in ist eine gründliche und faire Prüfung geschuldet. Wenn Sie feststellen, dass das gemeldete Verhalten kein Verstoß ist, stellen Sie dies klar und erklären Sie, warum Sie nichts dagegen unternehmen werden. Die Reaktion der meldenden Person ist eine andere Sache: das nur persönlich als problematisch empfundene Verhalten zu tolerieren oder die Projekt-Community zu verlassen.
+
+Ein gemeldetes Verhalten, das _genau genommen nicht_ gegen den Verhaltenskodex verstößt, kann dennoch auf ein Problem in Ihrer Gemeinschaft hinweisen. Sie sollten dieses potenzielle Problem untersuchen und entsprechend handeln. Dies kann die Überarbeitung Ihres Verhaltenskodex umfassen, um akzeptables Verhalten zu klären und/oder mit der Person zu sprechen, deren Verhalten gemeldet wurde. In diesem Falle stellen Sie klar, dass sie oder er vielleicht nicht konkret gegen den Verhaltenskodex verstoßen hat, aber den Rand des Akzeptablen erreicht haben, und andere Teilnehmer\*innen sich unwohl fühlen.
+
+Letztendlich setzen Sie als Maintainer\*in die Standards für akzeptables Verhalten (durch). Sie haben die Fähigkeit, die Gemeinschaftswerte des Projekts zu gestalten. Die Teilnehmer\*innen erwarten, dass Sie diese Werte auf faire und ausgewogene Weise durchsetzen.
+
+## Fördern Sie das Verhalten, das Sie in der Welt sehen wollen 🌎
+
+Wenn ein Projekt feindselig oder unwillkommen erscheint, und wenn auch nur durch das von Anderen tolerierte Verhalten einer einzelnen Person, riskieren Sie den Verlust vieler weiterer Mitwirkender. Es ist nicht immer einfach, einen Verhaltenskodex anzunehmen oder durchzusetzen, aber die Förderung einer einladenden Umgebung wird Ihrer Gemeinschaft helfen, zu wachsen.
diff --git a/_articles/de/finding-users.md b/_articles/de/finding-users.md
new file mode 100644
index 00000000000..507a561d13e
--- /dev/null
+++ b/_articles/de/finding-users.md
@@ -0,0 +1,195 @@
+---
+lang: de
+title: Finden Sie Nutzer*innen für Ihr Projekt
+description: Ziehen Sie Ihr Open-Source-Projekt groß, indem Sie es in die Hände zufriedener Anwender*innen legen.
+class: finding
+toc:
+ tue-gutes-und-rede-darüber: "Tue Gutes und rede darüber!"
+ klären-sie-ihre-botschaft: "Klären Sie Ihre Botschaft"
+ helfen-sie-menschen-dabei-ihr-projekt-zu-finden-und-zu-beobachten: "Helfen Sie Menschen dabei, Ihr Projekt zu finden und zu beobachten."
+ gehen-sie-auf-die-zielgruppe-ihres-projekts-zu-online: "Gehen Sie auf die Zielgruppe Ihres Projekts zu (online)"
+ gehen-sie-auf-die-zielgruppe-ihres-projekts-zu-offline: "Gehen Sie auf die Zielgruppe Ihres Projekts zu (offline)"
+ reputation-aufbauen: "Reputation aufbauen"
+order: 3
+image: /assets/images/cards/finding.png
+related:
+ - beginners
+ - building
+---
+
+## Tue Gutes und rede darüber!
+
+Es gibt keine Regel, die besagt, dass man den Start eines Open-Source-Projektes verkünden _muss_. Viele erfüllende Beweggründe für Open-Source-Arbeit haben nichts mit Popularität zu tun. Aber anstatt _zu hoffen_, dass Ihr Open-Source-Projekt gefunden und genutzt wird, sollten Sie über Ihre harte Arbeit reden.
+
+## Klären Sie Ihre Botschaft
+
+Bevor Sie mit der eigentlichen Arbeit an einem Projekt beginnen, sollten Sie (er)klären, was es tut und warum es wichtig ist.
+
+Was macht Ihr Projekt anders oder interessant und warum haben Sie es begonnen? Die Beantwortung dieser Fragen hilft Ihnen dabei, die Bedeutung Ihres Projekts zu kommunizieren.
+
+Denken Sie daran, dass Menschen sich als Nutzer\*innen engagieren und letztendlich zu Mitwirkenden werden, weil Ihr Projekt ein Problem für sie löst. Wenn Sie über die Botschaft und den Wert Ihres Projekts nachdenken, versuchen Sie durch die Brille der _Benutzer\*innen und Mitwirkenden_ zu blicken. Was könnten jene sich wünschen?
+
+Code-Beispiele wie @robb sie verwendet, können klar kommunizieren, warum sein Projekt "[Cartography](https://github.com/robb/Cartography)" nützlich ist:
+
+
+
+Tiefere Einblicke in das Thema "Botschaften", finden Sie in Mozillas ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/)-Übung zur Entwicklung von Personas.
+
+## Helfen Sie Menschen dabei, Ihr Projekt zu finden und zu beobachten
+
+
+
+Helfen Sie Leuten dabei, Ihr Projekt zu finden und es sich zu merken, indem Sie sie auf einen einzigen Namensraum verweisen.
+
+**Preisen Sie Ihre Arbeit an unter _einem_ Nutzernamen an.** Twitter-Name, GitHub-URL oder IRC-Kanal sind einfache Möglichkeiten, Leute auf Ihr Projekt aufmerksam zu machen. Diese "Marktstände" bieten auch der wachsenden Gemeinschaft Ihres Projekts einen Ort, an dem sie sich treffen können.
+
+Wenn Sie noch keine "Marktstände" für Ihr Projekt einrichten möchten, bewerben Sie immer Ihren eigenen Twitter- oder GitHub-Namen. Werben Sie für Ihren Twitter- oder GitHub-Namen, damit die Leute wissen, wie Sie zu erreichen sind oder wo Ihre Arbeit beobachtet werden kann. Wenn Sie bei einem Meeting oder einer Veranstaltung sprechen, stellen Sie sicher, dass Sie Ihre Kontaktinformationen erwähnen oder in Ihren Folien nennen.
+
+
+
+**Ziehen Sie eine Website für Ihr Projekt in Betracht.** Eine Website macht Ihr Projekt freundlicher und einfacher zu navigieren. Vor allem, wenn die Seite klare Dokumentation und Tutorials enthält. Außerdem zeigt eine Website auch, dass Ihr Projekt aktiv ist, was wiederum Ihrem Publikum Vertrauen in den Nutzen Ihres Projektes gibt.
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689) (Mitbegründer von Django) sagte, dass eine Website _"mit Abstand das Beste, das wir in der Frühphase von Django gemacht haben"_.
+
+Wenn Ihr Projekt auf GitHub gehostet ist, können Sie mithilfe der [Pages-Funktion](https://pages.github.com/) einfach eine Webseite erstellen. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), und [Middleman](https://middlemanapp.com/) sind [einige Beispiele](https://github.com/showcases/github-pages-examples) für exzellente, reichhaltige Seiten.
+
+
+
+Nun, da Sie die Botschaft Ihres Projekt klargestellt haben, und seine einfache Auffindbarkeit gewährleistet haben, lassen Sie uns rausgehen und mit Ihrem Publikum sprechen!
+
+## Gehen Sie auf die Zielgruppe Ihres Projekts zu (online)
+
+Internetkommunikation ist ein großartiger Weg, um die Botschaft Ihres Projektes schnell zu verbreiten und verteilen zu lassen: Online-Kanälen bieten das Potenzial, ein sehr breites Publikum zu erreichen.
+
+Nutzen Sie die Vorteile bestehender Online-Communities und -Plattformen, um Ihr Publikum zu erreichen. Wenn es sich bei Ihrem Open Source Projekt um ein Softwareprojekt handelt, erreichen Sie Ihr Publikum wahrscheinlich auf [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), oder [Quora](https://www.quora.com/). Finden Sie die Kanäle, von denen Sie denken, dass die Menschen am meisten von Ihrer Arbeit profitieren werden, oder sich begeistern lassen.
+
+
+
+Finden Sie Wege, um Ihr Projekt auf relevante Art und Weise mit anderen zu teilen:
+
+* **Lernen Sie relevante Open Source Projekte und Communities kennen.** Manchmal müssen Sie nicht direkt für Ihr Projekt werben. Wenn Ihr Projekt perfekt für Datenwissenschaftler geeignet ist, die Python nutzen, lernen Sie die Python Data Science Community kennen. Wenn die Leute Sie kennenlernen, ergeben sich natürliche Gelegenheiten, über Ihre Arbeit zu sprechen und sie mit anderen zu teilen.
+* **Finden Sie Personen, die mit dem Problem konfrontiert sind, das Ihr Projekt löst.** Suchen Sie in verwandten Foren nach Personen, die in die Zielgruppe Ihres Projekts fallen, beantworten Sie deren Fragen und finden Sie einen taktvollen Weg, um Ihr Projekt als Lösung vorzuschlagen.
+* **Bitten Sie um Feedback.** Stellen Sie sich und Ihre Arbeit einem Publikum vor, das Sie für relevant und interessant hält, und geben Sie an, wer Ihrer Meinung nach von Ihrem Projekt profitieren könnte. Versuchen Sie, diesen Satz zu vervollständigen: _"Ich denke, dass mein Projekt wirklich den X helfen würde, die versuchen, Y zu tun."_. Hören Sie zu und reagieren Sie auf das Feedback anderer, anstatt einfach nur Ihre Arbeit anzupreisen.
+
+Generell gilt: Konzentrieren Sie sich darauf, anderen zu helfen, bevor Sie um Gegenleistungen bitten. Da jeder leicht ein Projekt online bewerben kann, wird es eine Menge Rauschen geben: Um sich von der Masse abzuheben, machen Sie den Leuten Ihren persönlichen Kontext klar, und nicht nur Ihre Wünsche.
+
+Wenn niemand auf Ihre anfängliche Kommunikation achtet oder darauf reagiert, lassen Sie sich nicht entmutigen! Die meisten Projektstarts sind ein iterativer Prozess, der Monate oder Jahre dauern kann. Wenn Sie beim ersten Mal keine Antwort erhalten, versuchen Sie es mit einer anderen Taktik oder suchen Sie nach Wegen, wie Sie die Arbeit anderer zuerst aufwerten können. Ein Projekt zu starten und zu bewerben, erfordert Zeit und Engagement.
+
+## Gehen Sie auf die Zielgruppe Ihres Projekts zu (offline)
+
+
+
+Offline-Veranstaltungen helfen Ihnen dabei, neue Projekte beim Publikum bekannt zu machen und engagierte Leute zu erreichen. Insbesondere können Sie mit Entwickler\*innen direkt in Kontakt treten und Interesse an Ihrem Projekt wecken.
+
+Wenn Sie gerade erst anfangen, [Vorträge zu halten](http://speaking.io/), tun Sie das am besten auf einem lokalen Treffen ("Meetup"), bei dem es um die Sprache oder die Programmierumgebung geht, in der Ihr Projekt angesiedelt ist.
+
+
+
+Wenn Sie noch nie auf einer Veranstaltung gesprochen haben, sind Gefühle der Nervosität völlig normal: Denken Sie daran, dass Ihr Publikum da ist, weil es wirklich von Ihrer Arbeit hören möchte.
+
+Während Sie Ihren Vortrag ausarbeiten, konzentrieren Sie sich auf das für Ihr Publikum Interessante, das ihm einen Mehrwert bietet. Gestalten Sie Ihren Vortrag in einem freundlichen, zugänglichen Tonfall. Lächeln, atmen und Spaß haben.
+
+
+
+Wenn Sie sich gut vorbereitet fühlen, sollten Sie sich überlegen, mit einem Konferenzvortrag für Ihr Projekt zu werben. Das kann Ihnen helfen, mehr Menschen zu erreichen; Manchmal aus der ganzen Welt.
+
+Suchen Sie nach Konferenzen, die speziell auf Ihre Sprache oder Ihre Programmierumgebung zugeschnitten sind. Bevor Sie Ihren Vortrag einreichen, recherchieren Sie die Konferenz, um Ihren Vortrag auf die Teilnehmer\*innen zuzuschneiden und Ihre Chancen zu erhöhen, auf der Konferenz als Redner\*in akzeptiert zu werden. Sie können oft ein Gefühl für Ihr Publikum bekommen, wenn Sie frühere Redner\*innen der Konferenz recherchieren.
+
+
+
+## Reputation aufbauen
+
+Zusätzlich zu den oben skizzierten Strategien ist der beste Weg, Menschen für Beiträge in Ihrem Projekt zu gewinnen, deren Projekte zu teilen und zu unterstützen.
+
+Wenn Sie Neuankömmlingen helfen, Ressourcen gemeinsam nutzen und durchdachte Beiträge zu anderen Projekten leisten, können Sie einen guten Ruf aufbauen. Ein aktives Mitglied in der Open-Source-Gemeinschaft zu sein, hilft Leuten dabei, den Kontext Ihrer Arbeit zu verstehen. Es wird zudem wahrscheinlicher, dass Leute Ihr Projekt aufmerksam verfolgen und teilen. Die Entwicklungsbeziehungen zu anderen Open-Source-Projekten können sogar zu offiziellen Kooperationen führen.
+
+
+
+Es ist nie zu früh oder zu spät, um mit dem Aufbau eines guten Rufs zu beginnen. Auch wenn Sie bereits ein eigenes Projekt gestartet haben, suchen Sie weiterhin nach Möglichkeiten, anderen zu helfen.
+
+Ein Publikum aufzubauen, schafft man nicht über Nacht. Das Vertrauens und den Respekt anderer zu gewinnen, nimmt Zeit in Anspruch, und der Aufbau Ihres Rufes endet nie.
+
+
+
+## Weitermachen!
+
+Es kann lange dauern, bis Leute Ihr Open-Source-Projekt bemerken. Das ist in Ordnung! Einige der populärsten Projekte erreichten erst nach Jahren ein hohes Aktivitätsniveau. Konzentrieren Sie sich darauf, Kontakte aufzubauen, anstatt zu hoffen, dass Ihr Projekt spontan an Popularität gewinnt. Seien Sie geduldig und teilen Sie Ihre Arbeit mit denen, die sie zu schätzen wissen.
diff --git a/_articles/de/getting-paid.md b/_articles/de/getting-paid.md
new file mode 100644
index 00000000000..8ffbc598854
--- /dev/null
+++ b/_articles/de/getting-paid.md
@@ -0,0 +1,217 @@
+---
+lang: de
+title: Für Open-Source-Arbeit bezahlt werden
+description: Verstetigen Sie Ihre Open-Source-Arbeit, indem Sie finanzielle Unterstützung für Ihre Zeit oder Ihr Projekt erhalten.
+class: getting-paid
+toc:
+ warum-manche-menschen-finanzielle-unterstützung-suchen: "Warum manche Menschen finanzielle Unterstützung suchen"
+ die-eigene-arbeitszeit-finanzieren: "Die eigene Arbeitszeit finanzieren"
+ geldquellen-für-ihr-projekt-auftun: "Geldquellen für Ihr Projekt auftun"
+ eine-argumentationslinie-für-finanzielle-unterstützung-aufbauen: "Eine Argumentationslinie für finanzielle Unterstützung aufbauen"
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+ - best-practices
+ - leadership
+---
+
+## Warum manche Menschen finanzielle Unterstützung suchen
+
+Ein Großteil der Open-Source-Arbeit wird ehrenamtlich geleistet, z.B. wenn jemand in einem Projekt, das er benutzt, auf einen Fehler stößt und eine schnelle Lösung vorschlägt. Außerdem basteln viele Leute einfach in ihrer Freizeit an einem Open-Source-Projekt.
+
+
+
+Es gibt viele Gründe, warum eine Person _nicht_ für ihre Open-Source-Arbeit bezahlt werden möchte.
+
+* **Sie haben vielleicht schon einen Vollzeitjob, den sie lieben,** und der ihnen ermöglicht, in ihrer Freizeit einen Beitrag zu Open-Source-Software zu leisten.
+* **Sie mögen Open Source als Hobby,** oder als kreative Flucht und wollen sich finanziell nicht verpflichtet fühlen, an ihren Projekten arbeiten zu müssen.
+* **Sie ziehen andere Vorteile aus ihren Open-Source-Beiträgen,** wie z.B. den Aufbau ihres Rufs oder Portfolios, das Erlernen neuer Fertigkeiten oder das Gefühl, in einer Gemeinschaft eingebettet zu sein.
+
+
+
+Für andere kann eine Bezahlung die einzige Möglichkeit sein, sich an Open Source zu beteiligen. Sei es, weil das Projekt ständige oder zeitintensive Mitarbeit erfordert, oder seien es persönliche Gründe.
+
+Populäre Projekte aufrecht zu erhalten, kann eine große Verantwortung sein, die 10 oder 20 Stunden pro Woche in Anspruch nimmt, statt nur ein paar Stunden pro Monat.
+
+
+
+Bezahlte Arbeit ermöglicht Leuten aus verschiedenen Lebenssituationen heraus, sinnvolle Beiträge zu leisten. Manche Menschen können es sich eben nicht leisten, unbezahlte Zeit für Open-Source-Projekte aufzuwenden, z.B. weil ihre finanzielle Situation, Schulden, Familien- oder anderen Betreuungspflichten dies nicht zulassen. Das heißt, die möglichen Beiträge von talentierten Menschen, die es sich ehrenamtliche Arbeitszeit nicht leisten können, würden nie das Licht der Welt erblicken. Dies hat ethische Implikationen, wie @ashedryden [beschreibt](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), da die Beiträge, die das Licht der Welt erblicken, eher zu Gunsten derjenigen tendieren, die bereits Vorteile im Leben haben. Und sie diese aufgrund ihrer freiwilligen Beiträge weiter ausbauen können, während Andere, die nicht zu freiwilligem Engagement in der Lage sind, auch daraus keine Vorteile ziehen können. Dies wiederum verstärkt den derzeitigen Mangel an Vielfalt in der Open-Source-Welt.
+
+
+
+Wenn Sie auf der Suche nach finanzieller Unterstützung sind, gibt es zwei Möglichkeiten: Sie können Ihre eigene Arbeitszeit finanzieren, oder Sie können eine organisatorische Finanzierung für das Projekt finden.
+
+## Die eigene Arbeitszeit finanzieren
+
+Heutzutage werden viele Leute für Open-Source in Teil- oder Vollzeit bezahlt. Der häufigste Weg dahin ist, mit Ihrem Arbeitgeber darüber zu sprechen.
+
+Es ist einfacher, sich für Open-Source-Arbeiten zu entscheiden, wenn Ihr Arbeitgeber das Projekt tatsächlich nutzt. Wenn nicht, werden Sie kreativ: Vielleicht nutzt Ihr Arbeitgeber nicht das Projekt, aber Python, und die Pflege eines beliebten Python-Projekts hilft dabei, neue Python-Entwickler\*innen anzuziehen. Vielleicht sieht Ihr Arbeitgeber dadurch generell entwicklerfreundlicher aus.
+
+
+
+Wenn Sie kein existierendes Open-Source-Projekt haben, an dem Sie gerne arbeiten würden, sondern lieber Ihre aktuellen Arbeitsergebnisse quell-offen hätten, sollten Sie Ihren Arbeitgeber bitten, einen Teil seiner internen Software zu öffnen.
+
+Viele Unternehmen entwickeln Open-Source-Programme, um ihre Marke aufzubauen und Talente zu rekrutieren.
+
+@hueniverse z.B., fand heraus, dass es finanzielle Gründe gab, die [Investition von Walmart in Open Source zu rechtfertigten.](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). Und @jamesgpearce fand heraus, dass Facebooks Open-Source-Program [den Unterschied in der Personalakquise](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) machte:
+
+> Es ist eng mit unserer Hackerkultur und der Wahrnehmung unseres Unternehmens verbunden. Wir fragten unsere Angestellten: "Kanntet ihr das Open-Source-Programm von Facebook?". Zwei Drittel sagten "Ja". Die Hälfte sagte, dass das Programm positiv zu ihrer Entscheidung beigetragen hat, für uns zu arbeiten. Das sind keine marginalen Zahlen, und ein sich hoffentlich fortsetzender Trend.
+>
+> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
+
+Wenn Ihr Unternehmen diesen Weg einschlägt, ist es wichtig, die Grenzen zwischen Gemeinschafts- und Unternehmenstätigkeit klar zu halten, denn Open Source erhält sich letztlich durch Beiträge von Menschen auf der ganzen Welt. Und das ist größer als jedes einzelne Unternehmen oder jeder einzelne Standort.
+
+
+
+Wenn Sie Ihren derzeitigen Arbeitgeber nicht davon überzeugen können, Open-Source-Arbeit zu priorisieren, sollten Sie sich überlegen, einen neuen Arbeitgeber zu finden, der Mitarbeit an Open Source fördert. Zum Beispiel:
+
+* Manche Firmen, wie [Netflix](https://netflix.github.io/) oder [PayPal](https://paypal.github.io/), zeigen ihr Open-Source-Engagement auf ihren Webseiten
+* [Rackspace](https://www.rackspace.com/en-us) veröffentlicht seine [Open-Source-Beitragsrichtlinie](https://blog.rackspace.com/rackspaces-policy-on-contributing-to-open-source/) für Angestellte
+
+Aus einer großen Firma stammende Projekte, wie z.B. [Go](https://github.com/golang) oder [React](https://github.com/facebook/react), stellen vermutlich auch weiterhin Leute für Open-Source-Arbeit an.
+
+Außerdem können Sie versuchen, abhängig von Ihren persönlichen Umständen, selbstständig Geld zu sammeln, um Ihre Open-Source-Arbeit zu finanzieren, zum Beispiel:
+
+* @gaearon finanzierte seine Arbeit an [Redux](https://github.com/reactjs/redux) mittels einer [Patreon-Crowdfunding-Kampagne](https://redux.js.org/)
+* @andrewgodwin finanzierte Arbeit an Djangos Schemamigrations [mittels einer Kickstarter-Kampagne](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+
+## Geldquellen für Ihr Projekt auftun
+
+Abgesehen von Vereinbarungen für einzelne Projektteilnehmer\*innen, sammeln Projekte manchmal Geld von Unternehmen, Einzelpersonen oder anderen ein, um die laufende Arbeit zu finanzieren.
+
+Geld von einer Organisation kann verwendet werden, aktuelle Projektteilnehmer\*innen zu bezahlen, die Kosten für den Betrieb des Projekts zu decken (z.B. Hosting-Gebühren) oder in neue Funktionen oder Ideen zu investieren.
+
+Da Open Source populärer wird, ist die Finanzierung von Projekten immer noch experimentell, aber es gibt einige allgemeine Optionen.
+
+### Geld mittels Crowdfunding-Kampagnen oder Sponsoren einsammeln
+
+Sponsoren lassen sich einfacher finden, wenn Sie bereits ein starkes Publikum oder einen guten Ruf haben, oder Ihr Projekt sehr beliebt ist.
+
+Hier einige Beispiele für gesponsorte Projekte:
+
+* **[webpack](https://github.com/webpack)** sammelt Geld von Firmen und Einzelpersonen [mittels OpenCollective](https://opencollective.com/webpack)
+* **[Vue](https://github.com/vuejs/vue)** wird [mittels Patreon finanziert](https://github.com/open-source/stories/yyx990803)
+* **[Ruby Together](https://rubytogether.org/),** eine nicht-Gewinn-orientierte Organisation zahlt für die Arbeit an [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), und anderen Ruby-Infrastrukturprojekten
+
+### Eine Einnahmequelle schaffen
+
+Abhängig von Ihrem Projekt können Sie kommerziellen Support, gehostete Optionen oder zusätzliche Funktionen in Rechnung stellen. Wie beispielsweise:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** bietet Bezahlversionen mit zusätzlichem Support
+* **[Travis CI](https://github.com/travis-ci)** bietet Bezahlversionen ihres Dienstes
+* **[Ghost](https://github.com/TryGhost/Ghost)** ist ein Non-Profit mit Bezahldiensten
+
+Einige populäre Projekte, wie z.B. [npm](https://github.com/npm/npm) und [Docker](https://github.com/docker/docker), sammeln sogar Wagniskapital ein, um ihr Wachstum zu unterstützen.
+
+### Fördermittel beantragen
+
+Einige Softwarestiftungen und Unternehmen bieten Zuschüsse für Open-Source-Arbeiten an. Manchmal können Zuschüsse an Einzelpersonen ausgezahlt werden, ohne eine juristische Person für das Projekt zu gründen.
+
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** erhielt eine Förderung des [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
+* Arbeiten an **[OpenMRS](https://github.com/openmrs)** wurden von [Stripes Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) gefördert
+* **[Libraries.io](https://github.com/librariesio)** erhielt Fördermittel der [Sloan Foundation](https://sloan.org/programs/digital-technology)
+* Die **[Python Software Foundation](https://www.python.org/psf/grants/)** fördert Python-relvante Arbeiten
+
+Weitere, detaillierter erklärte Möglichkeiten, um für Open-Source-Arbeit bezahlt zu werden, finden Sie in [der Anleitung "Lemonade Stand"](https://github.com/nayafia/lemonade-stand) von @nayafia. Die verschiedenen Finanzierungsarten erfordern unterschiedliche Fähigkeiten, die Sie Ihren Stärken entsprechend in Erwägung ziehen sollten.
+
+## Eine Argumentationslinie für finanzielle Unterstützung aufbauen
+
+Egal ob Ihr Projekt eine neue Idee umsetzt, oder schon seit Jahren besteht: Sie sollten sich Gedanken über passende Finanzierung machen, Geldquellen identifizieren, und diesen ein überzeugendes Argument liefern können.
+
+Egal, ob Sie für Ihre eigene Zeit oder für ein Projekt Geld sammeln möchten, Sie sollten in der Lage sein, die folgenden Fragen zu beantworten.
+
+### Einfluss
+
+Warum ist dieses Projekt nützlich? Warum gefällt es Ihren (potenziellen) Nutzer\*innen so gut? Wo wird es in fünf Jahren sein?
+
+### Wichtigkeit
+
+Versuchen Sie Beweise für die Wichtigkeit Ihres Projektes zu sammeln: Metriken, Anekdoten oder Referenzen. Gibt es Unternehmen oder bemerkenswerte Personen, die Ihr Projekt gerade nutzen? Falls nicht, hat es jemand Bekanntes empfohlen?
+
+### Nutzen für die Geldgeber
+
+Geldgeber (sei es Ihr\*e Arbeitgeber\*in oder eine Förderstiftung) werden von vielen Anderen angesprochen: Warum sollte gerade Ihr Projekt unterstützt werden? Wie profitiert der Geldgeber selbst davon?
+
+### Nutzung der Gelder
+
+Was genau werden Sie mit der vorgeschlagenen Finanzierung erreichen? Konzentrieren Sie sich auf Projektmeilensteine oder -ergebnisse, anstatt ein Gehalt zu zahlen.
+
+### Wie empfangen Sie das Geld
+
+Hat der Geldgeber irgendwelche Anforderungen an die Auszahlung? Müssen Sie beispielsweise eine gemeinnützige Organisation sein, oder einen gemeinnützigen finanziellen Sponsor haben? Oder werden die Mittel an eine\*n einzelne\*n Auftragnehmer\*in anstatt an eine Organisation vergeben? Diese Anforderungen variieren zwischen den Geldgebern, also sollten Sie dies im Vorhinein in Erfahrung bringen.
+
+
+
+## Experimentieren und nicht aufgeben
+
+Es ist nicht einfach, Geld zu sammeln. Egal ob Sie ein Open-Source-Projekt, einen gemeinnützigen Verein oder ein Software-Startup betreiben. In den meisten Fällen müssen Sie kreativ werden. Identifizieren Sie den Modus der Bezahlung, stellen Sie Recherchen an und versetzen Sie sich selbst in die Rolle der Geldgeber\*innen. Dies wird Ihnen beim Finden eines überzeugenden Argumentes für die Finanzierung helfen.
diff --git a/_articles/de/how-to-contribute.md b/_articles/de/how-to-contribute.md
new file mode 100644
index 00000000000..fc9b59979a1
--- /dev/null
+++ b/_articles/de/how-to-contribute.md
@@ -0,0 +1,634 @@
+---
+lang: de
+title: Wie zu Open Source beitragen?
+description: Möchten Sie zu Open Source beitragen? Hier finden Sie einen Leitfaden für Einsteiger und Fortgeschrittene.
+class: contribute
+toc:
+ warum-eigentlich-zu-open-source-projekten-beitragen: "Warum eigentlich zu Open-Source-Projekten beitragen?"
+ was-einen-beitrag-leisten-bedeutet: "Was 'einen Beitrag leisten' bedeutet"
+ sich-in-einem-neuen-projekt-orientieren: "Sich in einem neuen Projekt orientieren"
+ so-finden-sie-ein-projekt-zu-dem-sie-beitragen-können: "So finden Sie ein Projekt, zu dem Sie beitragen können"
+ wie-man-einen-beitrag-einreicht: "Wie man einen Beitrag einreicht"
+ was-passiert-nachdem-sie-einen-beitrag-eingereicht-haben: "Was passiert, nachdem Sie einen Beitrag eingereicht haben?"
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+ - beginners
+ - building
+---
+
+## 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!
+
+### 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 müssen keinen Code beisteuern
+
+Ein weit verbreiteter Irrtum! Aber in Wirklichkeit sind es oft andere Projektaspekte, die am [meisten Unterstützung benötigen](https://github.com/blog/2195-the-shape-of-open-source). Sie tun dem Projekt einen _großen_ Gefallen, indem Sie anbieten, bei nicht-Code-Aspekten mitzuwirken!
+
+
+
+Auch wenn Sie gerne Code schreiben, sind andere Beitragsarten eine gute Möglichkeit, 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](https://github.com/nodeschool/organizers/issues/406)
+* 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](https://www.drupal.org/community-initiatives/drupal-core/usability))
+* 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](https://github.com/hapijs/contrib/issues/68)
+
+### 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](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Ü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](https://github.com/eslint/eslint/issues/6765)
+* 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](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* 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](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) 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](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### 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:
+
+* @sindresorhus kuratiert eine [Liste von "awesome"-Listen](https://github.com/sindresorhus/awesome)
+* @h5bp unterhält eine [Liste möglicher Bewerbungsfragen](https://github.com/h5bp/Front-end-Developer-Interview-Questions) für Frontend-Entwickler\*innen
+* @stuartlynn und @nicole-a-tesla [sammeln lustige Fakten über Papageitaucher](https://github.com/stuartlynn/puffin_facts)
+
+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 zu 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](https://choosealicense.com) 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:** Wo Leute über Themen diskutieren, die im Zusammenhang mit dem Projekt stehen.
+* **Pull Requests:** Wo Leute anstehende Änderungen diskutieren und überprüfen.
+* **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](https://www.igor.pro.br/publica/papers/saner2016.pdf) zu Open Source betreffen die Dokumentation (z.B. eine Korrektur der Rechtschreibung oder Formatierung, oder das Schreiben einer Übersetzung).
+>
+> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
+
+Auf einer der folgenden Seiten können Sie neue Projekte zum Beitragen entdecken (alle englischsprachig):
+
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](http://www.firsttimersonly.com/)
+* [Your First PR](https://yourfirstpr.github.io/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](http://up-for-grabs.net/)
+* [Contributor-ninja](https://contributor.ninja)
+
+### 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 Master-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 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-Diskussionsn 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 an einem besseren Ort zu verlassen, als wenn Sie es gefunden haben.
+
+### Erfassen Sie den Kontext
+
+Bevor Sie etwas tun, sollten Sie kurz sicherzustellen, 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 ein Pull Request stellen:
+
+* **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 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 eine 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](https://help.github.com/articles/watching-repositories/), 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. 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.
+
+### ein Pull Request erstellen
+
+In den folgenden Situationen sollten Sie in der Regel ein 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.
+
+Ein 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 ein Pull Request stellen:
+
+* **[Forken Sie das Repository](https://guides.github.com/activities/forking/)** 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](https://help.github.com/articles/syncing-a-fork/).)
+* **[Erstellen Sie einen Branch](https://guides.github.com/introduction/flow/)** 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 erstes Pull Request ist, sehen Sie sich [Make a Pull Request](http://makeapullrequest.com/) an, die @kentcdodds als Video-Tutorial erstellt hat. Sie können auch üben, ein Pull Request in @Roshanjossey\s "[First Contributions](https://github.com/Roshanjossey/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](#eine-checkliste-bevor-sie-einen-beitrag-leisten), 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. Ein 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.
diff --git a/_articles/de/index.html b/_articles/de/index.html
new file mode 100644
index 00000000000..81728ad404f
--- /dev/null
+++ b/_articles/de/index.html
@@ -0,0 +1,5 @@
+---
+layout: index
+lang: de
+permalink: /de/
+---
diff --git a/_articles/de/leadership-and-governance.md b/_articles/de/leadership-and-governance.md
new file mode 100644
index 00000000000..f6130ba555f
--- /dev/null
+++ b/_articles/de/leadership-and-governance.md
@@ -0,0 +1,188 @@
+---
+lang: de
+title: Führung und Lenkung
+description: Wachsende Open-Source-Projekte können von formellen Entscheidungsfindungsregeln profitieren.
+class: leadership
+toc:
+ welche-formalen-rollen-kann-es-in-open-source-projekten-geben: "Welche formalen Rollen kann es in Open-Source-Projekten geben?"
+ wie-formalisiere-ich-diese-führungsrollen: "Wie formalisiere ich diese Führungsrollen?"
+ wann-sollte-ich-jemandem-commit-rechte-geben: "Wann sollte ich jemandem Commit-Rechte geben?"
+ welche-lenkungsstrukturen-nutzen-open-source-projekte-häufiger: "Welche Lenkungsstrukturen nutzen Open-Source-Projekte häufiger?"
+ muss-ich-projektleitung-und--steuerung-schon-zum-projektstart-dokumentieren: "Muss ich Projektleitung und -Steuerung schon zum Projektstart dokumentieren?"
+ was-passiert-wenn-firmenangehörige-beiträge-einreichen: "Was passiert, wenn Firmenangehörige Beiträge einreichen?"
+ brauche-ich-für-mein-projekt-eine-juristische-person: "Brauche ich für mein Projekt eine juristische Person?"
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+ - best-practices
+ - metrics
+---
+
+## Die Lenkungen eines wachsenden Projektes verstehen
+
+Ihr Projekt wächst, Leute sind engagiert und Sie setzen sich dafür ein, dass alles _läuft_. In diesem Stadium fragen Sie sich vielleicht, wie Sie regelmäßig Mitwirkende in Ihren Arbeitsprozess einbinden können? Sei es durch die Gewährung von direktem Commit-Zugang oder durch die Führung von Debatten in der Gemeinschaft. Wir liefern Antworten auf Ihre Fragen.
+
+## Welche formalen Rollen kann es in Open-Source-Projekten geben?
+
+Viele Projekte folgen einer ähnlichen Struktur hinsichtlich Mitwirkung und Anerkennung.
+
+Was diese Rollen aber tatsächlich bedeuten, liegt ganz bei Ihnen. Nachfolgend sind einige Arten von Rollen aufgeführt, die Sie vielleicht schon kennen:
+
+* **Maintainer\*in**
+* **Kontributor\*in**
+* **Committer\*in**
+
+**Bei einigen Projekten sind "Maintainer\*innen"** die einzigen Personen mit Commit-Rechten. In anderen Projekten sind es einfach die Leute, die in der README als Maintainer\*innen aufgelistet sind.
+
+Ein\*e Maintainer\*in muss in Ihrem Projekt nicht zwangsläufig Code schreiben. Es kann auch eine Person sein, die viel Öffentlichkeitsarbeit für Ihr Projekt geleistet hat, viel Dokumentation geschrieben hat, oder das Projekt für andere zugänglicher gemacht hat. Unabhängig davon, was sie tagtäglich tun, fühlen sich Maintainer\*innen wahrscheinlich für die Richtung des Projekts verantwortlich und setzen sich für dessen Verbesserung ein.
+
+"Kontributor\*innen" könnten alle Menschen sein, die ein Issue oder Pull Request kommentiert, die dem Projekt einen Mehrwert verleihen (sei es durch Problembehebungen, das Schreiben von Code oder die Veranstaltungsorganisation) oder alle, deren Pull Requests akzeptiert wurden (vielleicht die engste Definition für Kontribution).
+
+
+
+**Der Begriff "Committer\*in"** könnte verwendet werden, um die höhere Verantwortung des Commit-Rechtes zu unterscheiden von anderen Formen der Mitarbeit.
+
+Sie können Ihre Projektrollen zwar nach Belieben definieren, aber Sie sollten die Verwendung von [breiteren Definitionen in Betracht ziehen](../how-to-contribute/#was-einen-beitrag-leisten-bedeutet), um mehr Beitragsformen zu fördern. Mit Hilfe von Führungsrollen können Sie Personen, die unabhängig von ihren fachlichen Fähigkeiten herausragende Leistungen für Ihr Projekt erbracht haben, formell auszeichnen.
+
+
+
+## Wie formalisiere ich diese Führungsrollen?
+
+Führungsrollen zu formalisieren, hilft den Menschen, ein eigenes Verantwortungsbewusstsein zu entwickeln und zeigt anderen Mitwirkenden, wen sie um Hilfe bitten sollen.
+
+In einem kleineren Projekt kann die Ernennung von Verantwortlichen einfach durch Hinzufügen Ihrer Namen zur README- oder CONTRIBUTORS-Datei geschehen.
+
+Für ein größeres Projekt mit einer Website, erstellen Sie eine Teamseite und listen die Verantwortlichen dort auf. Zum Beispiel hat [Postgres](https://github.com/postgres/postgres/) eine [umfassende Teamseite](https://www.postgresql.org/community/contributors/) mit Kurzprofilen aller Mitwirkenden.
+
+Wenn Ihr Projekt eine sehr aktive Gemeinschaft von Mitwirkenden hat, können Sie ein Maintainer\*innen-"Kernteam" bilden oder sogar Gremien, welche die Verantwortung für verschiedene Themengebiete übernehmen (z.B. Sicherheit, Issue-Bearbeitung oder Community-Management). Lassen Sie die Leute sich selbst organisieren! Anstatt ihnen Rollen zuzuweisen, lassen Sie Freiwillige das übernehmen, was diese am meisten begeistert.
+
+
+
+Führungsteams können einen Kommunikationskanal einrichten (z.B. im IRC) oder sich regelmäßig treffen, um das Projekt zu besprechen (z.B. in Gitter oder Google Hangout). Sie können diese Meetings sogar öffentlich machen, damit andere Leute zuhören können. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) zum Beispiel, [lädt zu wöchentlichen Sprechstunden ein](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs).
+
+Vergessen Sie nicht, nach der Festlegung von Führungsrollen zu dokumentieren, wie Menschen diese erreichen können! Richten Sie einen klaren Prozess ein, wie Leute Maintainer\*in werden oder einem Gremium in Ihrem Projekt beitreten können, und beschreiben Sie diesen Prozess in einer GOVERNANCE.md.
+
+Tools wie [Vossibility](https://github.com/icecrime/vossibility-stack) können Ihnen dabei helfen, öffentlich zu verfolgen, wer zum Projekt beiträgt (oder nicht). Die Dokumentation dieser Informationen beugt dem Eindruck vor, dass eine Maintainer\*innen-Clique ihre Privatinteressen durchsetzen würde.
+
+Wenn sich Ihr Projekt auf GitHub befindet, können Sie Ihr Projekt von Ihrem persönlichen Konto in eine Organisation verschieben und mindestens einen Backup-Administrator einrichten. [GitHub-Organisationen](https://help.github.com/articles/creating-a-new-organization-account/) erleichtern die Verwaltung von mehreren Repositories und Berechtigungen, und schützen ihr Projektarchiv durch [gemeinsame Verantwortung](../building-community/#teilen-sie-die-eigentümerschaft-an-ihrem-projekt).
+
+## Wann sollte ich jemandem Commit-Rechte geben?
+
+Einige Leute denken, dass Sie allen Commit-Zugang geben sollten, die einen Beitrag geleistet haben. Dies könnte dazu führen, dass sich mehr Menschen für Ihr Projekt interessieren.
+
+Andererseits, besonders bei größeren, komplexeren Projekten, möchten Sie vielleicht nur Personen zu Commits berechtigen, die ihr Engagement unter Beweis gestellt haben. Es gibt hier nicht _den einen_ richtigen Weg. Tun Sie, was Ihnen behagt!
+
+Wenn sich Ihr Projekt auf GitHub befindet, können Sie unter [protected branches](https://help.github.com/articles/about-protected-branches/) verwalten, wer unter welchen Umständen auf einen bestimmten Branch committen darf.
+
+
+
+## Welche Lenkungsstrukturen nutzen Open-Source-Projekte häufiger?
+
+Es gibt drei Lenkungsstrukturen, die häufig bei Open-Source-Projekten vorkommen.
+
+* * **BDFL:** BDFL steht für "Benevolent Dictator for Life" (gutmütige\*r Diktator\*in auf Lebenszeit). Bei dieser Struktur hat eine Person (in der Regel die oder der Erstautor\*in des Projekts) das letzte Wort bei allen wichtigen Projektentscheidungen. [Python](https://github.com/python) ist ein klassisches Beispiel. Kleinere Projekte haben wahrscheinlich standardmäßig ein\*e BDFL, da es nur einen oder zwei Maintainer\*innen gibt. Aus Unternehmen stammende Projekte können ebenfalls in die Kategorie BDFL fallen.
+
+* **Meritokratie:** **(Hinweis: Der Begriff "Meritokratie" ist bei einigen Communities negativ konnotiert und hat eine [komplexe soziale und politische Geschichte](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Unter einer Meritokratie erhalten aktive Projektmitarbeiter\*innen (diejenigen, die "sich die Meriten angelesen" haben) eine formelle Entscheidungsrolle. Entscheidungen werden in der Regel auf der Grundlage eines reinen Abstimmungskonsenses getroffen. Das Konzept der Meritokratie wurde von der [Apache Foundation](http://www.apache.org/) entwickelt; [alle Apache-Projekte](http://www.apache.org/index.html#projects-list) sind Meritokratien. Beiträge können nur von Personen geleistet werden, die sich selbst vertreten, nicht von einem Unternehmen.
+
+* **Liberales Beitragsmodell:** Nach einem liberalen Beitragsmodell werden die Menschen, die aktuell die meiste Arbeit leisten, als die einflussreichsten anerkannt. Dabei wird aber ihre frühere Beitragshistorie außer Acht gelassen. Wichtige Projektentscheidungen werden auf der Grundlage eines Konsensfindungsprozesses (Besprechen der wichtigsten Missstände) und nicht auf Grundlage reiner Abstimmung getroffen. Dabei streben solche Projekte nach Einbeziehung möglichst vieler Perspektiven der Gemeinschaft. Beliebte Beispiele für Projekte, die ein liberales Beitragsmodell verwenden, sind [Node.js](https://foundation.nodejs.org/) und [Rust](https://www.rust-lang.org/de-DE/).
+
+Welches Modell sollten Sie verwenden? Das obliegt Ihnen! Jedes Modell hat Vor- und Nachteile. Und obwohl sie zunächst sehr unterschiedlich erscheinen mögen, haben alle drei Modelle mehr gemeinsam als zu vermuten wäre. Wenn Sie daran interessiert sind, eines dieser Modelle zu übernehmen, schauen Sie sich diese Vorlagen an (alle Englisch):
+
+* [BDFL-Modellvorlage](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Meritokratische Modellvorlage](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js's liberale Beitragspolitik](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+
+## Muss ich Projektleitung und -Steuerung schon zum Projektstart dokumentieren?
+
+Es gibt nicht den einen richtigen Zeitpunkt, um die Leitungs- und Steuerungsrichtlinien Ihres Projekts aufzuschreiben. Allerdings sind sie einfacher zu definieren, sobald Sie die Entwicklung von Community-Dynamiken gesehen haben. Das Beste (und Schwierigste) an Open-Source-Projektsteuerung ist, dass sie von der Gemeinschaft geprägt wird!
+
+Frühzeitige Dokumentationen wird selbst auch dazu beitragen, wie sich Ihr Projekt entwickelt, also schreiben Sie ruhig früh auf, was Sie früh wissen. So können Sie beispielsweise schon zum Projektstart klare Erwartungen an die Funktionsweise Ihres Mitwirkungsprozesses definieren.
+
+Wenn Sie Teil eines Unternehmens sind, das ein Open-Source-Projekt startet, lohnt sich eine interne Diskussion vor dem Start. Wie erwartet Ihr Unternehmen, dass es das Projekt aufrechterhält und Entscheidungen trifft? Möglicherweise möchten Sie auch öffentlich erklären, wie oder ob Ihr Unternehmen in das Projekt eingebunden wird.
+
+
+
+## Was passiert, wenn Firmenangehörige Beiträge einreichen?
+
+Erfolgreiche Open-Source-Projekte werden von vielen Menschen und Unternehmen genutzt, und einige davon verfügen möglicherweise über Einnahmen, die letztendlich durch das Projekt generiert wurden. Beispielsweise kann eine Firma den Projektcode als eine Komponente eines kommerziellen Serviceangebots verwenden.
+
+Mit zunehmender Verbreitung des Projekts werden Menschen, die über Fachwissen verfügen, immer gefragter (Sie könnten eine\*r davon sein!) und wird manchmal für die Arbeit bezahlt, die sie im Projekt leisten.
+
+Es ist wichtig, kommerzielle Aktivitäten als normal und als eine weitere Motivation für die Entwicklungsarbeit zu betrachten. Bezahlte Entwickler\*innen sollten natürlich keine Sonderbehandlung gegenüber Unbezahlten erhalten. Jeder Beitrag muss nach seinen technischen Eigenschaften bewertet werden. Allerdings sollten die Leute zu kommerziellen Aktivitäten bereit sein, und sich damit wohl fühlen, wenn sie ihre Anwendungsfälle angeben oder sich für eine bestimmte Verbesserung oder Funktion aussprechen.
+
+"Kommerziell" ist vollständig kompatibel mit "Open Source". "Kommerziell" bedeutet nur, dass irgendwo Geld im Spiel ist, z.B. dass die Software unternehmerisch eingesetzt wird. Dies wird umso wahrscheinlicher, je weiter sich ein Projekt verbreitet. Wenn Open-Source-Software als Teil eines Nicht-Open-Source-Produkts verwendet wird, ist das Gesamtprodukt immer noch "proprietäre" Software, obwohl sie (wie Open Source!) für kommerzielle oder nicht-kommerzielle Zwecke verwendet werden kann.
+
+Wie jede\*r Andere auch, gewinnen kommerziell motivierte Entwickler\*innen durch die Qualität und Quantität ihrer Beiträge Einfluss auf das Projekt. Natürlich kann ein\*e Entwickler\*in, die oder der für die Arbeitszeit bezahlt wird, mehr tun als unbezahlte Beitragende, aber das ist in Ordnung: Bezahlung beeinflusst nur als einer von vielen möglichen Faktoren, was jemand tut. Halten Sie Ihre Projektdiskussionen auf den Inhalt der Beiträge fokussiert, nicht auf die externen Faktoren, die es den Menschen ermöglichen, diese Beiträge zu leisten.
+
+## Brauche ich für mein Projekt eine juristische Person?
+
+Sie benötigen keine juristische Person, um Ihr Open-Source-Projekt zu verwalten. Es sei denn, es kommt Geld ins Spiel.
+
+Wenn Sie beispielsweise ein kommerzielles Unternehmen gründen möchten, sollten Sie eine GmbH oder UG gründen (wenn Sie in Deutschland ansässig sind). Wenn Sie nur Auftragsarbeiten im Zusammenhang mit Ihrem Open-Source-Projekt durchführen, können Sie Geld als (Einzel)Unternehmergesellschaft akzeptieren oder eine GmbH gründen.
+
+Wenn Sie Spenden für Ihr Open-Source-Projekt annehmen möchten, können Sie einen Spendenkanal einrichten (z.B. über PayPal oder Stripe), aber das Geld ist nicht steuerlich absetzbar. Es sei denn, über einen anerkannt gemeinnütziger Verein.
+
+Viele Projekte wollen sich nicht die Mühe machen, einen gemeinnützigen Verein zu gründen, also finden sie stattdessen einen gemeinnützigen, steuerrechtlichen Sponsor. Ein solcher Sponsor nimmt Spenden in Ihrem Namen entgegen (teilweise im Austausch gegen einen prozentualen Anteil der Spende). [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects), [Open Collective](https://opencollective.com/opensource), und das deutsche [Center for the Cultivation of Technology](https://techcultivation.org/) sind Beispiele für Organisationen, die als steuerrechtliche Sponsoren für Open-Source-Projekte fungieren.
+
+
+
+Wenn Ihr Projekt spezifisch für eine bestimmte Programmiersprache oder ein bestimmtes Ökosystem gedacht ist, kann es auch eine entsprechende Software-Stiftung geben, mit der Sie zusammenarbeiten können. So unterstützt beispielsweise die [Python Software Foundation](https://www.python.org/psf/) den Paketmanager [PyPI](https://pypi.org/), und die [Node.js-Foundation](https://foundation.nodejs.org/) unterstützt das Node-basierte Framework [Express.js](https://expressjs.com/).
diff --git a/_articles/de/legal.md b/_articles/de/legal.md
new file mode 100644
index 00000000000..48d7bbbcc1c
--- /dev/null
+++ b/_articles/de/legal.md
@@ -0,0 +1,181 @@
+---
+lang: de
+title: Rechtliche Aspekte von Open-Source-Projekten
+description: Alle Rechtsfragen zu Open-Source-Projekten, über die Sie sich jemals Gedanken gemacht haben, und einige, über die nicht.
+class: legal
+toc:
+ warum-sorgen-sich-leute-so-um-rechtsfragen-im-open-source-bereich: "Warum sorgen sich Leute so um Rechtsfragen im Open-Source-Bereich?"
+ sind-publizierte-github-projekte-open-source: "Sind publizierte GitHub-Projekte Open Source?"
+ sag-mir-nur-kurz-wie-ich-mein-projekt-schützen-kann: "Sag mir nur kurz, wie ich mein Projekt schützen kann"
+ welche-open-source-lizenz-passt-zu-meinem-projekt: "Welche Open-Source-Lizenz passt zu meinem Projekt?"
+ was-wenn-ich-die-lizenz-meines-projektes-ändern-möchte: "Was, wenn ich die Lizenz meines Projektes ändern möchte?"
+ benötigt-mein-projekt-eine-zusätzliche-kontributionsvereinbarung: "Benötigt mein Projekt eine zusätzliche Kontributionsvereinbarung?"
+ was-muss-die-rechtsabteilung-meines-unternehmens-wissen: "Was muss die Rechtsabteilung meines Unternehmens wissen?"
+order: 10
+image: /assets/images/cards/legal.png
+related:
+ - contribute
+ - leadership
+---
+
+## Die rechtlichen Implikationen von offenem Quellcode verstehen
+
+Ihr kreatives Werk mit der Welt zu teilen, ist eine anregende und erfüllende Erfahrung. Jedoch können auch unerwartete Rechtsfragen auftreten. Dankenswerterweise müssen Sie bei deren Beantwortung nicht von Null anfangen. Wir decken Sie hier mit Hinweise ein, aber bitte beachten Sie unseren [Haftungsausschluss](/notices/).
+
+## Warum sorgen sich Leute so um Rechtsfragen im Open-Source-Bereich?
+
+Danke, dass Sie fragen! Wenn Sie ein kreatives Werk erarbeiten (bspw. einen Text, ein Bild, oder eben Code) fällt es standardmäßig und automatisch unter das Urheberrecht. Das bedeutet, das von Rechts wegen Sie, der/die Autor\*in des Werkes bestimmen dürfen, was andere damit tun dürfen.
+
+Generell gilt, dass Niemand sonst Ihr Werk nutzen, kopieren, verbreiten, oder modifizieren darf, ohne Abmahnungen oder Klagen zu riskieren.
+
+Open Source ist diesbezüglich natürlich anders, denn die/der Autor\*in erwartet ja, dass andere das Werk nutzen, modifizieren und teilen. Aber weil der Rechtsgrundsatz zunächst "exklusives Urheberrecht" lautet, benötigen Sie eine Lizenz, die klare Erlaubnisse verteilt.
+
+Wenn Sie keine Open-Source-Lizenz einsetzen, erhält zudem jede\*r ebenfalls das ausschließliche Urheberrechts, der/die zu Ihrem Projekt beiträgt. Das würde bedeuten, dass wirklich Niemand die Beiträge nutzen, kopieren, verbreiten, oder modifizieren dürfte. Selbst Sie nicht.
+
+Schlussendlich könnte Ihr Projekt auch von anderen abhängen, die wiederum Lizenzbedingungen haben, derer Sie sich nicht bewusst waren. Die Gemeinschaft um Ihr Projekt und/oder Regelungen Ihrer Arbeitsstelle können auch bestimmte Open-Source-Lizenzen bedingen. Diese Fälle behandeln wir weiter unten.
+
+## Sind publizierte GitHub-Projekte Open Source?
+
+Wenn Sie [ein neues Projekt auf GitHub erstellen](https://help.github.com/articles/creating-a-new-repository/), können Sie dies **öffentlich** oder **privat** tun.
+
+
+
+**Ihr GitHub-Projekt öffentlich zu machen, ist nicht dasselbe, wie eine Lizenz zu vergeben.** Öffentliche Projekte unterliegen [GitHubs Servicebedingungen](https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership), die Anderen das Ansehen und Forken Ihres Projektes erlauben. Dies bringt allerdings keine weiteren Erlaubnisse für Ihr Werk mit sich.
+
+Wenn Sie anderen die Nutzung, Verbreitung, Modifikation Ihres Projektes erlauben möchten, sowie zu ihm beizutragen, müssen Sie eine Open-Source-Lizenz vergeben. Beispielsweise darf legalerweise kein Mensch irgendeinen Teil Ihres GitHub-Projektes in seinen/ihren eigenen Code nutzen (selbst wenn es öffentlich ist) solange Sie nicht das Recht dazu explizit eingeräumt haben.
+
+## Sag mir nur kurz, wie ich mein Projekt schützen kann.
+
+Sie haben Glück, denn Open-Source-Lizenzen sind heutzutage standardisiert und einfach zu nutzen. Sie können eine existierende Lizenz direkt in ihr Projekt kopieren.
+
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), und [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) sind die populärsten Open-Source-Lizenzen, aber es gibt auch andere zur Auswahl. Sie finden deren Volltexte, sowie Anleitungen zur deren Nutzung auf [choosealicense.com](https://choosealicense.com/), sowie eine Gruppierung nach Lizenztyp auf [ifrOSS.org/lizenz-center](http://www.ifross.org/lizenz-center).
+
+Wenn Sie ein neues Projekt auf GitHub anlegen, wird Ihnen [die Nutzung einer Lizenz vorgeschlagen](https://help.github.com/articles/open-source-licensing/).
+
+
+
+## Welche Open-Source-Lizenz passt zu meinem Projekt?
+
+Wenn Sie ein komplett neues Projekt starten, können Sie mit der [MIT-Lizenz](https://choosealicense.com/licenses/mit/) nichts falsch machen. Sie ist kurz, verständlich, und erlaubt allen alles, solange sie eine Lizenzkopie und Ihren Urheberrechtshinweis beibehalten.
+
+Ansonsten hängt die korrekte Lizenzwahl von den Zielen Ihres Projektes ab.
+
+Wahrscheinlich hat Ihr Projekt externe Abhängigkeiten (oder wird diese haben). Beispielsweise wenn Sie ein Node.js-Projekt veröffentlichen, werden Sie vermutlich Bibliotheken vom Node Package Manager (npm) nutzen. Jede dieser Bibliotheken ist eine Abhängigkeiten von Ihrem Projekt und hat ihre eigene Open-Source-Lizenz. Wenn jede dieser Lizenzen "permissiv" ist (also der Öffentlichkeit die Nutzung, Modifikation, und das Teilen bedingungslos erlaubt), können _Sie_ jede Lizenz verwenden, die sie möchten. Weit verbreitete permissive Lizenzen sind z.B. MIT, Apache 2.0, ISC und BSD.
+
+Wenn allerdings irgendeine der Bibliotheken, von denen Ihr Projekt abhängt, ein "starkes Copyleft" hat (also der Öffentlichkeit die Nutzung, Modifikation, und das Teilen ebenso erlaubt, aber unter der Bedingung, die selbe Lizenz zu nutzen), dann wird Ihr Projekt diese Lizenz auch verwenden (müssen). Weit verbreitete Copyleft-Lizenzen sind z.B. die GPLv2, GPLv3, sowie die AGPLv3.
+
+Sie sollten auch die **Gemeinschaften** beachten, von denen Sie sich Nutzung und Beiträge Ihres Projektes erhoffen.
+
+* **Möchten Sie Ihr Projekt in anderen nachgenutzt wissen?** Am Besten nutzen Sie dann die populärste Lizenz im Umfeld ihres Projektes. Beispielsweise ist die [MIT-Lizenz](https://choosealicense.com/licenses/mit/) für [npm-Bibliotheken](https://libraries.io/npm) am populärsten.
+* **Soll Ihr Projekt auch große Firmen anziehen?** Große Firmen möchten sich vermutlich Patentrechte sichern, auch von allen Kontributor\*innen. Diesen Fall deckt [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) ab.
+* **Soll Ihr Projekt Kontributor\*innen anziehen, die ihre Beiträge aus Closed-Source-Software raushalten möchten?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) oder (wenn sie auch nicht zu Closed-Source-Diensten beitragen möchten) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) würden dazu passen.
+
+Ihre **Firma** hat evtl. spezifische Lizenzanforderungen für ihre Open-Source-Projekte. Beispielsweise fordert sie eine permissive Lizenz, sodass sie Ihr Projekt in firmeneigener Closed-Source-Software nutzen kann. Oder, Ihre Firma könnte eine starke Copyleft-Lizenz und eine zusätzliche Kontributionsvereinbarung nutzen (siehe unten). Sodann kann nur sie und keine andere Firma, Ihr Projekt in einer Closed-Source-Software nutzen. Oder, Ihre Firma könnte spezielle Standards technischer Art haben, oder bezogen auf soziale Verantwortung, oder an Transparenz. All dies könnte eine spezifische Lizenzstrategie bedingen. Sprechen Sie mit der [Rechtsabteilung Ihrer Firma](#was-muss-die-rechtsabteilung-meines-unternehmens-wissen).
+
+Wenn Sie ein GitHub-Projekt erstellen, wird Ihnen die Lizenzwahl vorgeschlagen. Dabei eine der oben genannten Lizenzen auszuwählen, "open-sourced" ihr Projekt. Wenn Sie aus weiteren Möglichkeiten die richtige Lizenz finden möchten, bitte schauen Sie sich [choosealicense.com](https://choosealicense.com) an, auch wenn Ihr Projekt [keine Software](https://choosealicense.com/non-software/) an sich ist.
+
+## Was, wenn ich die Lizenz meines Projektes ändern möchte?
+
+Die meisten Projekte müssen ihre Lizenz nie ändern. Aber manchmal kommen andere Umstände.
+
+Zum Beispiel: Während des Wachstums Ihres Projektes bindet es weitere externe Bibliotheken ein oder gewinnt Nutzer\*innen hinzu. Oder, Ihre Firma ändert die Strategie. All dies kann (oder muss sogar) eine andere Lizenzentscheidung nach sich ziehen. Außerdem: Falls Sie zu Beginn keine Lizenz vergeben haben, ist dies nachzuholen effektiv dasselbe wie eine Lizenzänderung. Die folgenden drei Dinge sind grundsätzlich zu beachten, wenn Sie die Lizenzvergabe oder -änderung für Ihr Projekt in Betracht ziehen:
+
+**Es ist kompliziert** Lizenzkompatibilitäten und deren Befolgung zu ermitteln. Auch die Urheberrechtsinhaber\*in(nen) herauszufinden, kann schnell kompliziert und verwirrend werden. Auf eine andere aber kompatible Lizenz für einen neue Release-Version und neue Beiträge zu wechseln, funktioniert anders als alle existierenden Beiträge zu relizenzieren. Ziehen Sie Ihre Kolleg\*innen von der Rechtsabteilung beim ersten Anflug des Verlangens nach Relizenzierung hinzu. Selbst wenn Sie die Erlaubnisse der Urheberrechtsinhaber\*innen für eine Lizenzänderung haben oder bekommen können: Bedenken Sie den Umbruch, den dies für Ihre Projekt und seine Nutzer\*innen bedeutet. Behandeln Sie eine Lizenzänderung als eine Richtungsentscheidung, die geschmeidiger über die Bühne gehen kann, wenn Sie mit allen Projektteilnehmer\*innen klar kommunizieren und alle konsultieren. All dies sind zudem gute Gründe, schon zu Beginn eines Projektes eine passende Lizenz zu wählen.
+
+**Die vorhandene Lizenz Ihres Projektes.** Wenn diese kompatibel mit der gewünschten neuen Lizenz ist, können Sie die neue einfach anfangen zu verwenden. Dies funktioniert, da eine Kompatibilität von Lizenz A mit Lizenz B bedeutet, dass Sie die Bedingungen von Lizenz A auch erfüllen, wenn Sie sich an Lizenz B halten (Umgekehrt gilt dies allerdings nicht notwendigerweise ebenso). Wenn Sie z.B. eine permissive Lizenz nutzen (wie MIT), können Sie auf eine Lizenz mit mehr Bedingungen wechseln, solange Sie die Kopie des MIT-Lizenztextes und die assoziierten Urheberrechtshinweise beibehalten (also die MIT-Minimalbedingungen erfüllen). Wenn allerdings Ihre aktuelle Lizenz nicht-permissiv ist (sondern z.B. copyleft, oder wenn Sie keine Lizenz nutzen), und Sie nicht der oder die einzige Urheberrechtsinhaber\*in sind, können Sie Ihr Projekt nicht einfach auf MIT umstellen. Im Kern bedeutet eine permissive Lizenz auch, dass ein\*e Urheberrechtsinhaber\*in schon im Vorhinein die Erlaubnis zur Lizenzänderung gegeben hat.
+
+**Die bestehenden Urheber\*innen Ihres Projekts.** Wenn Sie die oder der einzige Mitwirkende an Ihrem Projekt sind, dann sind entweder Sie oder Ihr Unternehmen der/die einzige Rechteinhaber\*in des Projekts. Sie können die Lizenz hinzufügen oder ändern, die Sie oder Ihr Unternehmen haben möchten. Andernfalls kann es andere Urheberrechtsinhaber\*innen geben, von denen Sie die Zustimmung benötigen, um die Lizenzen zu ändern. Wer sind sie? Menschen, die sich in Ihrem Projekt engagieren, kommen infrage. Aber in manchen Fällen werden die Verwertungsrechte von den Arbeitgeber\*innen dieser Leute gehalten, in anderen Fällen haben die Leute nur minimale Beiträge geleistet, aber es gibt keine exakte Regel, dass Beiträge unter einer bestimmten Anzahl von Code-Zeilen nicht dem Urheberrecht unterliegen. Was tun? Das kommt darauf an. Für ein relativ kleines und junges Projekt kann es möglich sein, alle existierenden Mitwirkenden dazu zu bringen, einer Lizenzänderung in einem Issue oder einem Pull-Antrag zuzustimmen. Für große und langlebige Projekte müssen Sie möglicherweise viele Mitwirkende und sogar deren Erben suchen. Mozilla brauchte Jahre (2001-2006), um Firefox, Thunderbird und verwandte Software neu zu lizenzieren.
+
+Alternativ können Sie auch im Voraus bestimmte Lizenzänderungen unter bestimmten Bedingungen vereinbaren, die über die von Ihrer bestehenden Open-Source-Lizenz hinausgehen. Solche zusätzlichen Vereinbarungen, auch "contributor (license) agreements" genannt, werden unten weiter erklärt. Sie verschieben die Komplexität des Lizenzwechsels etwas: Sie brauchen mehr Hilfe von Ihren Anwälten im Vorfeld, und Sie werden trotzdem mit den Beteiligten Ihres Projekts kommunizieren wollen, wenn Sie eine Lizenzänderung durchführen.
+
+## Benötigt mein Projekt eine zusätzliche Kontributionsvereinbarung?
+
+Wahrscheinlich nicht. Für die überwiegende Mehrheit der Open-Source-Projekte gilt eine Open-Source-Lizenz implizit sowohl für reinkommende Beiträge als auch ausgehend an andere Mitwirkende und Benutzer\*innen. Wenn Ihr Projekt auf GitHub steht, machen GitHubs Terms of Service diese "inbound=outbound" genannte Praxis zum [expliziten Standard](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license).
+
+Eine zusätzliche Kontributionsvereinbarung - oft auch Contributor License Agreement (CLA) genannt - kann Verwaltungsarbeit für die Projektbetreuer\*in schaffen. Hierbei hängt der Umfang der zusätzlichen Arbeit vom Projekt und der Implementierung ab. Eine einfache Vereinbarung erfordert, dass die Kontributor\*innen mit einem Klick bestätigen, dass sie die erforderlichen Rechte innehaben, um zum Projekts im Rahmen dessen Open-Source-Lizenz beizutragen.
+
+Durch das Hinzufügen von "Papierkram", den einige für unnötig, schwer verständlich oder ungerecht halten (wenn der/die Empfänger\*in der Vereinbarung mehr Rechte erhält als die Mitwirkenden oder die Öffentlichkeit über die Open-Source-Lizenz des Projekts erhält), kann eine zusätzliche Kontributionsvereinbarung als unfreundlich für die Gemeinschaft des Projekts empfunden werden.
+
+
+
+Einige Situationen, in denen Sie eine zusätzliche Kontributionsvereinbarung für Ihr Projekt in Betracht ziehen sollten, sind z.B:
+
+* Ihre Anwälte wollen, dass alle Mitwirkenden ausdrücklich die Kontributionsbedingungen akzeptieren (_unterschreiben_, on- oder off-line), vielleicht weil sie der Meinung sind, dass die Open-Source-Lizenz selbst nicht ausreicht (obwohl sie ausreicht!). Wenn dies die einzige Sorge ist, sollte eine Kontributionsvereinbarung, welche die Open-Source-Lizenz des Projekts bestätigt, ausreichen. Das [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) ist ein gutes Beispiel für eine leichtgewichtige, zusätzliche Kontributionsvereinbarung. Für manche Projekte kann ein [Developer Certificate of Origin](https://github.com/probot/dco) eine Alternative sein.
+* Ihr Projekt verwendet eine Open-Source-Lizenz, die keine ausdrückliche Patenterteilung enthält (z.B. MIT), die Sie aber von allen Mitwirkenden benötigen. Von denen können Einige für Unternehmen mit großen Patentportfolios arbeiten, die gegen Sie oder die anderen Mitwirkenden und Benutzer\*innen des Projekts verwendet werden könnten. Die [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) ist eine häufig verwendete zusätzliche Kontributionsvereinbarung mit einer der Apache License 2.0 entsprechenden Patenterteilung.
+* Ihr Projekt steht unter einer Copyleft-Lizenz, aber Sie müssen auch eine proprietäre Version des Projekts verbreiten. Sie werden von allen Kontributor\*innen eine Rechteverwertungsvereinbarung einholen müssen, die Ihnen (aber nicht der Öffentlichkeit) eine permissive Lizenz gewährt. Das [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) ist ein Beispiel für eine solche Vereinbarungen.
+* Sie sind der Meinung, dass Ihr Projekt im Laufe seiner Laufzeit seine Lizenz wechseln muss und möchten, dass die Mitwirkenden dieser Änderungen im Voraus zustimmen.
+
+Wenn Sie mit Ihrem Projekt wirklich eine zusätzliche Kontributionsvereinbarung verwenden müssen, sollten Sie eine Integration wie den [CLA-Assistenten](https://github.com/cla-assistant/cla-assistant) verwenden, um Mitwirkende nur minimalstmöglich abzulenken.
+
+## Was muss die Rechtsabteilung meines Unternehmens wissen?
+
+Wenn Sie ein Open-Source-Projekt als Mitarbeiter\*in eines Unternehmens veröffentlichen, sollte die Rechtsabteilung zunächst wissen, dass Sie ein Open-Source-Projekt durchführen.
+
+Ungeachtet der möglichen Vor- oder Nachteile sollten Sie es mitteilen, auch wenn es sich um ein persönliches Projekt handelt. Sie haben wahrscheinlich eine "Rechteübertragungsvereinbarung" mit ihrer Firma, die ihr einen gewissen Grad an Kontrolle über ihre Projekte gibt. Insbesondere, wenn diese irgendwie mit dem Geschäft des Unternehmens zu tun haben oder Sie die Ressourcen des Unternehmens für die Entwicklung des Projekts nutzen. Ihr Unternehmen _sollte_ Ihnen problemlos die Erlaubnis erteilen, und hat vielleicht schon eine mitarbeiterfreundliche Rechtevereinbarung oder Firmenpolitik. Wenn nicht, können Sie verhandeln (z.B. erklären, dass Ihr Projekt den beruflichen Lern- und Entwicklungszielen des Unternehmens dient), oder vermeiden, an Ihrem Projekt zu arbeiten, bis Sie ein besseres Unternehmen gefunden haben.
+
+**Wenn Sie ein Projekt im Namen Ihrer Firma öffnen möchten,** teilen Sie dies definitiv mit. Ihre Rechtsabteilung hat wahrscheinlich bereits Richtlinien für eine Open-Source-Lizenz (und vielleicht eine zusätzliche Kontributionsvereinbarung), die auf den geschäftlichen Anforderungen des Unternehmens basieren und die sicherstellen, dass Ihr Projekt mit den Lizenzen seiner Dependencies übereinstimmt - wenn nicht, dann haben Sie und Ihre Rechtsabteilung Glück! Letztere dürfte erpicht darauf sein, mit Ihnen zusammenzuarbeiten, um folgende Dinge herauszufinden:
+
+* **Material Dritter:** Hängt Ihr Projekt von Software ab, die von anderen erstellt wurden, oder enthält oder verwendet es anderweitig den Code Dritter? Wenn ja und diese Open-Source-lizenziert sind, müssen Sie diese einhalten. Dies beginnt mit der Wahl einer Lizenz für Ihr Projekt, die mit den Open-Source-Lizenzen der Drittanbieter kompatibel ist (siehe oben). Wenn Ihr Projekt Open-Source-Material Dritter modifiziert oder verbreitet, wird Ihre Rechtsabteilung auch sicher sein wollen, dass Sie Zusatzbedingungen der Drittanbieterlizenzen erfüllen, wie z.B. die Beibehaltung von Urheberrechtsvermerken. Wenn Ihr Projekt anderen Code verwendet, der nicht unter einer Open-Source-Lizenz steht, müssen Sie wahrscheinlich die Drittanbieter bitten, eine [Open-Source-Lizenz hinzuzufügen](https://choosealicense.com/no-license/#for-users). Wenn dies nicht erfolgreich ist, müssen Sie aufhören, deren Code in Ihrem Projekt zu verwenden.
+
+* **Geschäftsgeheimnisse:** Überlegen Sie, ob Teile des Projektes Ihres Unternehmen nicht der Öffentlichkeit zugänglich gemacht werden sollten. Solches Material können Sie aus Ihrem Projekt extrahieren, privat halten, und den Rest veröffentlichen.
+
+* **Patente:** Wenn Ihr Unternehmen ein Patent anmeldet, für das die Veröffentlichung Ihres Projekt eine [Offenlegung](https://en.wikipedia.org/wiki/Public_disclosure) darstellen würde, werden Sie evtl. gebeten zu warten (oder vielleicht wird das Unternehmen überdenken, ob die Patentanmeldung sinnvoll ist). Wenn Sie Beiträge von Mitarbeiter\*innen von Unternehmen mit großen Patentportfolios erwarten, könnte Ihre Rechtsabteilung sich eine Lizenz mit einer ausdrücklichen Patenterteilung von Kontributor\*innen wünschen (z.B. die Apache 2.0 oder GPLv3), oder eine zusätzliche Kontributionsvereinbarung (siehe oben).
+
+* **Marken- und Warenzeichen:** Vergewissern Sie sich, dass Ihr Projektname [nicht im Widerspruch zu bestehenden Marken steht](../starting-a-project/#namenskonflikte-vermeiden). Wenn Sie Ihre eigenen Firmenmarken im Projekt verwenden, stellen Sie sicher, dass diese keine Konflikte verursachen. [FOSSmarks](http://fossmarks.org/) ist ein praktischer Leitfaden, um Marken im Rahmen von freien und Open-Source-Projekten zu verstehen.
+
+* **Privatsphäre:** Sammelt Ihr Projekt Daten über Benutzer\*innen? Sendet sie zurück an Firmenserver? Ihre Rechtsabteilung kann Sie bei der Einhaltung von Unternehmensrichtlinien und externen Vorschriften unterstützen.
+
+Wenn Sie das erste Open-Source-Projekt Ihres Unternehmens veröffentlichen, ist das mehr als genug, um durchzukommen (aber keine Sorge, die meisten Projekte sollten keine größeren Bedenken aufwerfen).
+
+Längerfristig kann Ihre Rechtsabteilung mehr tun, um dem Unternehmen zu helfen, von seinem Engagement für Open Source zu profitieren, und auf der sicheren Seite zu bleiben:
+
+* **Richtlinie für Beiträge von Angestellten:** Erwägen Sie die Entwicklung einer Unternehmenspolitik, die festlegt, wie Ihre Mitarbeiter\*innen zu Open-Source-Projekten beitragen. Eine klare Richtlinie verringert die Verwirrung unter Ihren Mitarbeiter\*innen und hilft ihnen dabei, Open-Source-Projekte im besten Interesse des Unternehmens zu unterstützen, sei es als Teil ihrer Arbeit oder in ihrer Freizeit. Ein gutes Beispiel von Rackspace ist deren [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+
+
+
+* **Was veröffentlichen?** [(Fast) alles?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html). Wenn Ihre Rechtsabteilung die Open-Source-Strategie Ihres Unternehmens versteht und in sie investiert, kann sie Ihnen am besten helfen, anstatt Ihre Bemühungen zu behindern.
+* **Compliance:** Auch wenn Ihr Unternehmen keine Open-Source-Projekte veröffentlicht, verwendet es die Open-Source-Software von anderen. [Bewusstsein darüber und Prozesse dafür](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) helfen, Kopfschmerzen, Produktverzögerungen und Klagen zu vermeiden.
+
+
+
+* **Patente:** Ihr Unternehmen kann dem [Open Invention Network](https://www.openinventionnetwork.com/) beitreten: Einem gemeinsamen defensiven Patent-Pool, um die Nutzung großer Open-Source-Projekte durch Mitglieder zu schützen, oder kann andere [alternative Patentlizenzen](https://www.eff.org/document/hacking-patent-system-2016) in Betracht ziehen.
+* **Governance:** Vor allem, wenn es sinnvoll ist, ein Projekt in eine [juristische Person außerhalb des Unternehmens](../leadership-and-governance/#brauche-ich-für-mein-projekt-eine-juristische-person) zu verlegen.
diff --git a/_articles/de/metrics.md b/_articles/de/metrics.md
new file mode 100644
index 00000000000..5faff34356a
--- /dev/null
+++ b/_articles/de/metrics.md
@@ -0,0 +1,138 @@
+---
+lang: de
+title: Open-Source-Metriken
+description: Treffen Sie fundierte Entscheidungen und helfen Sie Ihrem Open-Source-Projekt, indem Sie dessen Erfolg messen und verfolgen.
+class: metrics
+toc:
+ warum-überhaupt-etwas-messen: "Warum überhaupt etwas messen?"
+ entdeckt-werden: "Entdeckt werden"
+ benutzung: "Benutzung"
+ nachhaltigkeit: "Nachhaltigkeit"
+ betreuerinnen-aktivität: "Betreuer*innen-Aktivität"
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+ - finding
+ - best-practices
+---
+
+## Warum überhaupt etwas messen?
+
+Daten können Open-Source-Betreuer\*innen helfen, bessere Entscheidungen zu treffen, wenn sie mit Bedacht verwendet werden.
+
+Mit mehr Informationen können Sie:
+
+* Verstehen, wie Benutzer\*innen auf eine neue Funktion reagieren
+* Herausfinden, woher neue Nutzer\*innen kommen
+* Identifizieren und entscheiden, ob ein Anwendungsfall oder eine Funktionalität für Randfälle unterstützt wird
+* Die Beliebtheit Ihres Projekts quantifizieren
+* Verstehen, wie Ihr Projekt verwendet wird
+* Geld durch Sponsoring und Zuschüsse erhalten
+
+[Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) z.B. fand heraus, dass Google Analytics ihnen half, Arbeit zu priorisieren:
+
+> Homebrew wird kostenlos zur Verfügung gestellt und ausschließlich von Freiwilligen in ihrer Freizeit betrieben. Daher verfügen wir nicht über die Ressourcen, um detaillierte Benutzerstudien von Homebrew-Benutzern durchzuführen, um zu entscheiden, wie zukünftige Features am besten gestaltet und die aktuelle Arbeit priorisiert werden können. Mit anonymen aggregierten Benutzeranalysen können wir Korrekturen und neue Funktionen basierend darauf priorisieren, wie, wo und wann Menschen Homebrew verwenden.
+>
+> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+
+Popularität ist nicht alles. Jeder kommt aus verschiedenen Gründen auf Open Source. Wenn Ihr Ziel als Open-Source-Betreuer\*in darin besteht, Ihre Arbeit zu präsentieren, Ihren Code transparent zu machen oder einfach nur um Spaß zu haben, sind Metriken für Sie möglicherweise nicht wichtig.
+
+Wenn Sie daran interessiert sind, Ihr Projekt auf einer tieferen Ebene zu verstehen, lesen Sie weiter, um die Aktivitäten Ihres Projekts zu analysieren.
+
+## Entdeckt werden
+
+Bevor Leute Ihr Projekt nutzen oder zu ihm beitragen können, müssen sie wissen, dass es existiert. Fragen Sie sich selbst: _Finden Leute dieses Projekt?_
+
+
+
+Wenn Ihr Projekt auf GitHub gehostet wird, [können Sie sich ansehen](https://help.github.com/articles/about-repository-graphs/#traffic), wie viele Personen Ihr Projekt finden und wie sie es gefunden haben. Im Repo Ihres Projektes, klicken Sie "Insights" und dann "Traffic". Auf der Seite sehen Sie:
+
+* **Views** zeigen an, wie oft Ihr Projekt angesehen wurde.
+
+* **Unique visitors** zeigt, wie viele Personen Ihr Projekt angesehen haben.
+
+* **Referring sites:** Diese Metrik kann Ihnen helfen, herauszufinden, wo Sie Ihr Publikum erreichen und ob Ihre Werbekampagnen funktionieren.
+
+* **Popular content** zeigt, wohin Besucher\*innen auf Ihrer Projektseite gehen, aufgeschlüsselt nach Seitenaufrufen und einzelnen Besucher\*innen.
+
+[GitHub-Stern](https://help.github.com/articles/about-stars/) korrelieren nicht unbedingt mit Downloads und Nutzung, aber zeigen Ihnen, wie viele Menschen Ihre Arbeit schätzen.
+
+Vielleicht möchten Sie auch [die Auffindbarkeit an bestimmten Orten verfolgen](https://opensource.com/business/16/6/pirate-metrics): z.B. Google PageRank, von Ihrer Projektwebsite ausgehende Empfehlungen, oder eingehende Empfehlungen anderer Open-Source-Projekte oder -Webseiten.
+
+## Benutzung
+
+Leute finden Ihr Projekt auf dieser wilden und verrückten Sache, die wir das Internet nennen. Wenn sie Ihr Projekt sehen, werden sie sich im Idealfall angespornt fühlen, etwas zu tun. Die zweite Frage, die Sie sich stellen sollten, lautet: _Nutzen Leute dieses Projekt?_
+
+Wenn Sie einen Paketmanager wie [npm](https://www.npmjs.com/) oder [RubyGems.org](https://rubygems.org/) verwenden, um Ihr Projekt zu verteilen, können Sie vielleicht die Downloads Ihres Projekts verfolgen.
+
+Paketmanager verwenden leicht unterschiedliche "Download"-Definitionen, und Downloads korrelieren nicht unbedingt mit "Installation" oder "Verwendung", aber sie bieten eine Basislinie für Vergleiche: Probieren Sie [Libraries.io](https://libraries.io/) aus, um Nutzungsstatistiken über viele populäre Paketmanager hinweg zu verfolgen.
+
+Wenn sich Ihr Projekt auf GitHub befindet, navigieren Sie erneut zur Traffic-Seite. Aus [dem clone-Diagramm](https://github.com/blog/1873-clone-graphs) können Sie ablesen, wie oft Ihr Projekt an einem bestimmten Tag heruntergeladen wurde, aufgeschlüsselt nach Gesamtzahl und Nutzer\*innen.
+
+
+
+Wenn die Nutzung im Vergleich zur Anzahl der Personen, die Ihr Projekt entdecken, gering ist, gibt es zwei Punkte zu beachten:
+
+* Entweder schafft es Ihr Projekt nicht, Besucher\*innen zu Nutzer\*innen zu konvertieren,
+* oder Sie ziehen die falsche Zielgruppe an.
+
+Wenn Ihr Projekt z.B. auf der Titelseite von [Hacker News](https://news.ycombinator.com/) landet, werden Sie wahrscheinlich eine Steigerung der Entdeckungsrate (Traffic) sehen, aber eine niedrigere Konversionsrate, weil Sie alle auf Hacker News erreichen. Wenn Ihr Ruby-Projekt jedoch auf einer Ruby-Konferenz vorgestellt wird, ist es wahrscheinlicher, dass Sie eine hohe Konversionsrate von einem Zielpublikum sehen.
+
+Versuchen Sie herauszufinden woher Ihr Publikum kommt, und bitten Sie auf Ihrer Projektseite um Feedback der Besucher\*innen, um herauszufinden, welche dieser beiden Effekte Ihr Projekt betrifft.
+
+Sobald Sie wissen, dass Leute Ihr Projekt benutzen, möchten Sie vielleicht versuchen, herauszufinden, was sie damit machen. Bauen sie darauf auf, indem sie Ihren Code forken und Funktionen hinzufügen? Nutzen sie es für wissenschaftliche oder gewerbsmäßige Zwecke?
+
+## Nachhaltigkeit
+
+Leute finden Ihr Projekt und benutzen es. Sie sollten sich nun die Frage stellen: _Wird auch wieder an das Projekt zurückgegeben?_
+
+Es ist nie zu früh, um über Mitwirkende nachzudenken: Ohne andere Leute, die mitmachen, riskieren Sie, dass Sie sich in eine ungesunde Situation begeben, in der Ihr Projekt _populär_ ist (viele Leute benutzen es), aber nicht _unterstützt_ (nicht genug Zeit, um die Nachfrage zu befriedigen).
+
+Nachhaltigkeit setzt auch [die Gewinnung neuer Mitwirkender](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2) voraus, da zuvor Aktive auch mit der Zeit sich anderen Themen zuwenden werden.
+
+Beispiele für Community-Metriken, die Sie regelmäßig verfolgen möchten, sind unter anderem:
+
+* **Gesamtzahl der Mitwirkenden und Anzahl der Commits pro Mitwirkenden:** Sagt Ihnen, wie viele Leute an Ihrem Projekt mitwirken, und wer mehr oder weniger aktiv ist. Auf GitHub können Sie dies unter "Insights" -> "Contributors" einsehen. Dieses Diagramm zeigt momentan nur die Mitwirkenden, die zum Default-Branch des Repositories beigetragen haben.
+
+
+
+* **Erstmalige, gelegentliche und regelmäßige Mitwirkende:** Hilft Ihnen nachzuvollziehen, ob Sie neue Mitwirkende hinzugewinnen können, und ob sie auch wiederholt mithelfen. (Gelegentlich Mitwirkende sind solche mit geringer Commit-Anzahl. Ob es sich dabei um einen, weniger als fünf Commits oder um andere Zahlen handelt, sei Ihnen überlassen). Ohne neue Helfer\*innen kann die Community Ihres Projekts stagnieren.
+
+* **Anzahl der offenen Issues und Pull Requests:** Wenn diese Zahlen zu hoch werden, benötigen Sie vielleicht Hilfe beim Sichten der Issues und bei Code-Reviews.
+
+* **Anzahl der _eröffneten_ Issues und Pull Requests:** Issues aufzumachen bedeutet, dass sich jemand genug für Ihr Projekt interessiert, um ein Problem lösen zu wollen. Wenn sich diese Zahl im Laufe der Zeit erhöht, dann zeigt dies wachsendes Interesse an Ihrem Projekt.
+
+* **Arten der Mithilfe:** Zum Beispiel Commits, das Beheben von Tippfehlern oder Bugs oder das Kommentieren eines Issues.
+
+
+
+## Betreuer\*innen-Aktivität
+
+Schließlich möchten Sie den Kreis schließen, indem Sie sicherstellen, dass die Maintainer\*innen Ihres Projekts in der Lage sind, das Volumen der erhaltenen Beiträge zu bewältigen. Die letzte Frage, die Sie sich stellen sollten, ist: _Antworte ich (oder antworten wir) auf unsere Community?_
+
+Unresponsive Betreuer\*innen werden zum Flaschenhals für Open-Source-Projekte. Wenn jemand einen Beitrag einreicht, der aber nie beantwortet wird, wird sich die Person entmutigt fühlen und sich abwenden.
+
+[Untersuchungen von Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) deuten darauf hin, dass eine schnelle und freundliche Reaktion der Maintainer\*innen Mitwirkende zu weiteren Beiträgen ermutigt.
+
+Überlegen Sie, wie lange es dauert, bis Sie (oder ein anderer Betreuer) auf Beiträge reagieren, egal ob es sich um ein Issue oder ein Pull Request handelt. Die Reaktion muss keine Maßnahme sein; Auch ein einfaches : _"Vielen Dank für diesen Beitrag! Ich werde ihn innerhalb einer Woche überprüfen."_ zählt.
+
+Sie können auch die Zeit messen, die benötigt wird, um zwischen den einzelnen Phasen des Beitragsprozesses zu wechseln, wie z.B:
+
+* Die durchschnittliche Dauer, die ein Issue offen bleibt
+* Ob Issues durch PRs geschlossen werden
+* Ob veraltete Issues geschlossen werden
+* Die Durchschnittliche Zeit für den Merge eines Pull Requests
+
+## Nutzen Sie 📊 um die Helfer\*innen besser zu verstehen
+
+Selbst wenn Sie nicht alle Metriken auf einem Dashboard verfolgen, können Sie mit Hilfe der obigen Hinweise Ihre Aufmerksamkeit auf die Art des Verhaltens lenken, die Ihrem Projekt zum Erfolg verhelfen wird.
diff --git a/_articles/de/starting-a-project.md b/_articles/de/starting-a-project.md
new file mode 100644
index 00000000000..9c0ab7a586a
--- /dev/null
+++ b/_articles/de/starting-a-project.md
@@ -0,0 +1,395 @@
+---
+lang: de
+title: Ein Open-Source-Projekt anfangen
+description: Erfahren Sie mehr über die Open-Source-Welt und machen Sie sich bereit, Ihr eigenes Projekt zu starten.
+class: beginners
+toc:
+ was-ist-open-source-und-warum: "Was ist Open Source, und warum?"
+ sollte-ich-mein-eigenes-open-source-projekt-starten: "Sollte ich mein eigenes Open-Source-Projekt starten?"
+ ein-eigenes-open-source-projekt-starten: "Ein eigenes Open-Source-Projekt starten"
+ ihr-projekt-benennen-und-zur-marke-machen: "Ihr Projekt benennen und zur Marke machen"
+ ihre-checkliste-zur-startvorbreitung: "Ihre Checkliste zur Startvorbreitung"
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+ - finding
+ - building
+---
+
+## Was ist Open Source, und warum?
+
+Sie denken also über einen Sprung in die Open-Source-Welt nach? Herzlichen Glückwunsch, die Welt weiß Ihren Beitrag zu schätzen! Lassen Sie uns darüber sprechen, was Open Source ist und warum sich Leute dafür engagieren.
+
+### Was genau bedeutet "Open Source"?
+
+Ein Open-Source-Projekt kann von **jedem Menschen für jeden Zweck verwendet, inspiziert, modifiziert und weiterverbreitet werden.** Diese Rechte werden [mittels einer Open-Source-Lizenz durchgesetzt](https://opensource.org/licenses).
+
+Open Source ist leistungsstark, weil es Akzeptanzbarrieren senkt und Ideen schneller verbreiten lässt.
+
+Um zu verstehen, wie es funktioniert, stellen Sie sich vor, eine Freundin von Ihnen lädt zur Grillparty ein und Sie bringen einen Kartoffelsalat mit.
+
+* Alle probiere den Salat (_verwenden_)
+* Er ist der Hit! Andere Gäste fragen Sie nach dem Rezept, das Sie auch gerne nennen (_inspizieren_)
+* Ihr süddeutscher Freund Alex schlägt vor, weniger Majo zu nehmen (_modifizieren_)
+* Eine andere Freundin, Lisa, möchte den Salat für ein Abendessen nächste Woche selbst ausprobieren (_weiterverbreiten_)
+
+Zum Vergleich: Closed-Source entspricht einem Restaurantbesuch mit der Bestellung einer Portion Kartoffelsalat. Sie müssen eine Gebühr zahlen, um ihn zu essen, und das Restaurant wird Ihnen das Rezept wahrscheinlich nicht geben. Wenn Sie den Salat genau kopieren und unter Ihrem eigenen Namen verkaufen würden, könnte das Restaurant gegen Sie vorgehen.
+
+### Warum öffnen Menschen den Quellcode ihrer Software?
+
+
+
+[Es gibt viele Gründe](https://ben.balter.com/2015/11/23/why-open-source/) warum eine Person oder Organisation ein Projekt open-sourcen wollen würde. Beispielsweise:
+
+* **Zusammenarbeit:** Open-Source-Projekte nehmen Beiträge aus der ganzen Welt an. [Exercism](https://github.com/exercism/) beispielsweise ist eine Programmierübungsplatform mit über 350 Kontributor\*innen.
+
+* **Anpassungen:** Open-Source-Projekte können von jedem Menschen für fast jeden Zweck benutzt werden. Leute können daraus sogar andere Dinge bauen. [WordPress](https://github.com/WordPress) beispielsweise begann als ein Fork eines existierenden Projekts namens [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md).
+
+* **Transparenz:** In einem Open-Source-Projekt können Fehler oder Ungereimtheiten von jedem behoben werden. Transparenz ist sowohl für Regierungen in [Bulgarien](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) oder den [Vereinigten Staaten](https://web.archive.org/web/20180306072551/https://sourcecode.cio.gov/), für regulierte Industrien wie den Banken- oder Gesundheitssektor, und für Sicherheitssoftware wie [Let's Encrypt](https://github.com/letsencrypt) gleichermaßen wichtig.
+
+Open Source ist nicht nur für Software, sondern auch für alle anderen Bereiche geeignet, von Datensätzen bis hin zu Büchern. Stöbern Sie durch [GitHub Explore](https://github.com/explore), um einen Eindruck der thematischen Breite von Open-Source-Projekten zu bekommen.
+
+### Bedeutet Open Source auch "gratis"?
+
+Einer der größten Vorteile von Open Source ist, dass es kein Geld kostet. "Gratis" dagegen ist nur ein Nebenprodukt des Gesamtwertes.
+
+Weil [eine Open-Source-Lizense bedingt](https://opensource.org/osd-annotated), dass jede\*r die Software nutzen, modifizieren, und weiterverbreiten darf (für nahezu jeden Zweck), nehmen die Projekte selbst meist kein Geld dafür. Wenn sie es täten, könnte jede\*r ganz legal das Projekte kopieren und die dann freie Version nutzen.
+
+Daher sind die meisten Open-Source-Projekte kostenlos, aber das ist kein Teil der Open-Source-Definition. Es gibt für Open-Source-Projekte Möglichkeiten, sich indirekt bezahlen zu lassen (z.B. über Doppellizenzierung oder eingeschränkte Funktionen) und dabei trotzdem die offizielle Definition von Open-Source weiterhin einzuhalten.
+
+## Sollte ich mein eigenes Open-Source-Projekt starten?
+
+Die kurze Antwort ist "Ja!", denn egal wie das Ergebnis aussieht: Ein eigenes Projekt zu starten, ist eine großartige Möglichkeit zu lernen, wie Open Source funktioniert.
+
+Wenn Sie noch nie den Quellcode eines Projektes geöffnet haben, werden Sie vielleicht nervös darüber sein, was die Leute sagen werden, oder ob es jemandem auffallen wird. Mit diesen Bedenken wären Sie nicht allein!
+
+Open-Source-Arbeit ist eine kreative Aktivität wie Schreiben oder Malen, oder anderes. Es kann beängstigend sein, seine Arbeit mit der Welt zu teilen, aber der einzige Weg besser zu werden, ist zu üben - auch wenn man kein Publikum hat.
+
+Wenn Sie noch nicht überzeugt sind, nehmen Sie sich einen Moment Zeit, um darüber nachzudenken, was Ihre Ziele sein könnten.
+
+### Ihre Ziele definieren
+
+Ziele können Ihnen helfen, herauszufinden, woran Sie arbeiten sollen, was Sie ablehnen sollen und wo Sie Hilfe von anderen brauchen. Fragen Sie sich zuerst: _Warum öffne ich dieses Projekt?_
+
+Es gibt keine richtige Antwort auf diese Frage. Vielleicht haben Sie mehrere Ziele für ein einzelnes Projekt oder verschiedene Projekte mit unterschiedlichen Zielen.
+
+Wenn es Ihr einziges Ziel ist, Ihre Arbeit zu zeigen, wollen Sie vielleicht nicht einmal Beiträge, und sagen dies sogar in Ihrer README. Andererseits, wenn Sie sich Beiträge wünschen: Investieren Sie Zeit in eine klare Dokumentation, damit sich Neuankömmlinge willkommen fühlen.
+
+
+
+Wenn Ihr Projekt wächst, braucht Ihre Community mehr als nur Code von Ihnen. Die Reaktion auf Probleme, die Überprüfung von Code und das Anpreisen Ihres Projekts sind alles wichtige Aufgaben in einem Open-Source-Projekt.
+
+Während die Zeit, die Sie für nicht-Programmieraufgaben aufwenden, von der Größe und dem Umfang Ihres Projekts abhängt, sollten Sie als Betreuer\*in darauf vorbereitet sein, diese selbst anzugehen oder jemanden zu finden, der Ihnen hilft.
+
+**Wenn Sie Teil eines Unternehmens sind, das ein Projekt öffnet**, stellen Sie sicher, dass Ihr Projekt über die internen Ressourcen verfügt, die es braucht, um zu gedeihen: Sie wollen klarstellen, wer für die Wartung des Projekts nach dem Start verantwortlich ist und wie Sie diese Aufgaben mit Ihrer Community teilen.
+
+Wenn Sie ein dediziertes Budget oder Personal für Werbung, Betrieb und Wartung des Projekts benötigen, planen Sie dies frühzeitig.
+
+
+
+### Zu anderen Projekten beitragen
+
+Wenn Ihr Ziel das Lernen ist, wie man mit anderen zusammenarbeitet oder wie Open Source funktioniert, sollten Sie in Erwägung ziehen, zu einem bestehenden Projekt beizutragen. Dies kann so einfach sein wie die Korrektur von Tippfehlern oder das Aktualisieren der Dokumentation.
+
+Wenn Sie sich nicht sicher sind, wie Sie als Mitwirkende\*r anfangen können, schauen Sie sich unseren Artikel "[Wie zu Open Source beitragen?](../how-to-contribute/)" an.
+
+## Ein eigenes Open-Source-Projekt starten
+
+Es gibt keine perfekte Zeit, um Ihre Arbeit zu veröffentlichen. Sie können eine Idee, ein in Arbeit befindliches Projekt, oder ein Jahre altes Closed-Source-Pröjekt öffnen.
+
+Im Prinzip immer, wenn Sie sich sicher sind, dass andere Ihre Arbeit sehen sollten, und Feedback dazu geben.
+
+Unabhängig davon, in welcher Phase Sie sich für Open Source entscheiden, sollte jedes Projekt die folgende Dokumentation enthalten:
+
+* [Eine Open-Source-Lizenz](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository)
+* [Eine README](https://help.github.com/articles/create-a-repo/#commit-your-first-change)
+* [Beitragsrichtlinien](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [einen Verhaltenskodex](../code-of-conduct/)
+
+Als Maintainer\*in helfen Ihnen diese Komponenten, Erwartungen zu kommunizieren, Beiträge zu verwalten und die gesetzlichen Rechte aller (einschließlich Ihrer eigenen) zu schützen. Sie tragen zudem zu einer positiven Erfahrungen in Ihrem Projekt bei.
+
+Wenn sich Ihr Projekt auf GitHub befindet, können Sie diese Dateien mit den empfohlenen Dateinamen in Ihrem Stammverzeichnis ablegen, damit GitHub sie erkennt und automatisch an Ihre Leser\*innen weitergeben kann.
+
+### Eine Lizenz auswählen
+
+Eine Open-Source-Lizenz garantiert, dass andere Ihr Projekt ohne Nebenwirkungen nutzen, kopieren, modifizieren und wieder einbringen können, und schützt Sie vor unangenehmen rechtlichen Situationen. **Wenn Sie ein Open-Source-Projekt starten, müssen Sie eine Lizenz angeben.**
+
+Rechtsangelegenheiten sind kein Spaß. Die gute Nachricht ist, dass Sie eine bestehende Lizenz kopieren und in Ihr Repository einfügen können. Es dauert also nur eine Minute, Ihre harte Arbeit zu schützen.
+
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), und [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) sind die populärsten Open-Source-Lizenzen, aber [es gibt viele andere](https://choosealicense.com) zur Auswahl.
+
+Wenn Sie ein neues Projekt auf GitHub erstellen, haben Sie die Möglichkeit, eine Lizenz auszuwählen. Mit einer Open-Source-Lizenz wird Ihr GitHub-Projekt auch wirklich zum Open-Source-Projekt.
+
+
+
+Wenn Sie weitere Fragen oder Bedenken bezüglich der rechtlichen Aspekte der Verwaltung eines Open-Source-Projekts haben, [können Sie sich an uns wenden](../legal/).
+
+### Eine README schreiben
+
+READMEs erklären nicht nur, wie Sie Ihr Projekt verwenden, sondern auch, warum Ihr Projekt wichtig ist und was Ihre Benutzer\*innen damit machen können.
+
+Versuchen Sie in Ihrer README folgende Fragen zu beantworten:
+
+* Was macht dieses Projekt?
+* Wozu nützt es?
+* Wie kann ich anfangen, es zu nutzen oder etwas beizutragen?
+* Wo wird mir geholfen, wenn ich Hilfe benötige?
+
+Sie können Ihre README verwenden, um andere Fragen zu beantworten: z.B. wie Sie mit Beiträgen handhaben, welche Ziele das Projekt verfolgt, oder wie es um Lizenzen und Zuschreibungen steht. Wenn Sie keine Beiträge annehmen wollen oder Ihr Projekt noch nicht produktionsreif ist, schreiben Sie auch diese Informationen auf.
+
+
+
+Manchmal vermeiden es Leute, eine README zu schreiben, weil sie das Gefühl haben, das Projekt sei unvollendet, oder weil sie keine Beiträge wollen. Aber auch dies sind gute Gründe, eine zu schreiben.
+
+Weitere Inspirationen zum Schreiben einer README finden Sie in @18F's ["Making READMEs Readable"](https://pages.18f.gov/open-source-guide/making-readmes-readable/) oder in @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2).
+
+Wenn Sie eine README-Datei im Hauptordner Ihres Projektes anlegen, zeigt GitHub diese automatisch auf der Homepage des Repos an.
+
+### Ihre Beitragsrichtlinien aufschreiben
+
+Eine CONTRIBUTING-Datei erklärt Ihrem Publikum, wie es zu Ihrem Projekt beitragen kann. Beispielsweise können Sie informieren über:
+
+* Wie eine Fehlerbericht eingereicht werden kann (probieren Sie hierfür die [Issue- und Pull-Request-Vorlagen](https://github.com/blog/2111-issue-and-pull-request-templates))
+* Wie neue Funktionen vorgeschlagen werden sollten
+* Wie die Entwicklungsumgebung eingerichtet wird, und wie getestet wird
+
+Neben thematischen Details präsentiert die CONTRIBUTING-Datei auch Ihre Erwartungen an Beiträge, z.B:
+
+* Die Beitragsarten, die Sie gerne hätten
+* Ihre Planungen und Ziele für das Projekt
+* Wie Beitragseinreicher\*innen Sie kontaktieren sollten (oder auch nicht)
+
+Mit einem warmen, freundlichen Ton und spezifischen Vorschlägen für Beiträge (wie z.B. "Dokumentationen verfassen" oder "eine Website erstellen") können Sie dazu beitragen, dass sich Neuankömmlinge willkommen und begeistert fühlen.
+
+Beispielsweise leitet [Active Admin](https://github.com/activeadmin/activeadmin/) [ihre Beitragsrichtlinien](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) ein mit:
+
+> Zuerst einmal vielen Dank, dass Sie überlegt haben, einen Beitrag zu Active Admin zu leisten, denn es sind Menschen wie Sie, die Active Admin so großartig machen.
+>
+> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+
+In der Anfangsphase Ihres Projekts kann Ihre CONTRIBUTING-Datei einfach sein. Sie sollten immer erklären, wie Fehler oder Probleme gemeldet werden können und welche technischen Anforderungen (z.B. Tests) Leute erfüllen müssen, um einen Beitrag zu leisten.
+
+Im Laufe der Zeit können Sie weitere häufig gestellte Fragen zu Ihrer CONTRIBUTING-Datei hinzufügen. Diese Informationen aufzuschreiben verhindert, dass weniger Leute die immer wieder gleichen Fragen stellen werden.
+
+@nayafia's [CONTRIBUTING-Vorlage](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) oder @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) helfen Ihnen, Ihre Beitragsrichtlinien zu entwerfen.
+
+Verlinken Sie Ihre CONTRIBUTING-Datei in Ihrer README, sodass mehr Leute sie bemerken. Wenn Sie sie zudem [in Ihr Repo einchecken](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), wird GitHub automatisch auf sie aufmerksam machen, wenn jemand ein Issue oder Pull Request erstellt.
+
+
+
+### Einen Verhaltenskodex etablieren
+
+
+
+Letztendlich hilft ein Verhaltenskodex, Grundregeln für das Verhalten der Projektbeteiligten festzulegen. Insbesondere wenn Sie ein Open-Source-Projekt für eine Community oder ein Unternehmen starten. Ein Verhaltenskodex hilft Ihnen, ein gesundes, konstruktives Gemeinschaftsverhalten zu fördern, das Ihnen als Maintainer\*in Stress erspart.
+
+Weitere Information finden Sie in unserer [Anleitung für Verhaltenskodices](../code-of-conduct/).
+
+Neben der Klarstellung _welches_ Verhalten Sie von den Teilnehmer\*innen erwarten, beschreibt ein Verhaltenskodex auch, auf wen sich diese Erwartungen beziehen, wann sie gelten und was zu tun ist, wenn ein Verstoß vorliegt.
+
+Ähnlich zu Open-Source-Lizenzen, kommen auch Standards für Verhaltenskodices auf, sodass Sie keinen komplett eigenen schreiben müssen. Der [Contributor Covenant](https://contributor-covenant.org/) ist ein einsatzbereiter Verhaltenskodex, der von [über 40'000 Open-Source-Projekten](http://contributor-covenant.org/adopters/) verwendet wird, einschließlich Kubernetes, Rails und Swift. Egal welchen Text Sie nutzen, Sie sollten vorbereitet sein, ihn wenn nötig auch durchzusetzen.
+
+Fügen Sie den Text direkt in eine CODE_OF_CONDUCT-Datei in Ihrem Repository ein. Halten Sie die Datei im Stammverzeichnis Ihres Projekts, damit sie leicht zu finden ist, und verlinken Sie sie von Ihrer README.
+
+## Ihr Projekt benennen und zur Marke machen
+
+Eine Marke besteht aus mehr als einem auffälligen Logo oder einem einprägsamem Projektnamen. Es geht darum, wie Sie über Ihr Projekt sprechen und wen Sie mit Ihrer Botschaft erreichen.
+
+### Den richtigen Namen auswählen
+
+Wählen Sie einen Namen, der leicht zu merken ist und im Idealfall eine Vorstellung davon vermittelt, was das Projekt bewirkt. Beispielsweise:
+
+* [Sentry](https://github.com/getsentry/sentry) überwacht Apps und meldet Abstürze
+* [Thin](https://github.com/macournoyer/thin) ist ein schneller, einfacher Web-Server in Ruby
+
+Wenn Sie auf einem bestehenden Projekt aufbauen, kann die Verwendung des Namens als Präfix helfen, zu klären, was Ihr Projekt tut ([node-fetch](https://github.com/bitinn/node-fetch) z.B. implementiert `window.fetch` für Node.js).
+
+Denken Sie vor allem an die Klarheit. Wortspiele machen Spaß, aber denken Sie daran, dass manche Witze nicht in andere Kulturen oder für Menschen mit anderen Erfahrungen als Ihren, übersetzt werden können. Einige Ihrer potenziellen Nutzer\*innen könnten Mitarbeiter\*innen in Unternehmen sein: Sie wollen es ihnen nicht unangenehm machen, wenn sie Ihr Projekt bei der Arbeit erklären müssen!
+
+### Namenskonflikte vermeiden
+
+[Prüfen Sie, ob es Open-Source-Projekte mit ähnlichem Namen gibt](http://ivantomic.com/projects/ospnc/), insb. in der selben Sprache oder demselben Ökosystem. Wenn Ihr Projektname mit einem existierenden, populären Projekt überlappt, könnte das Ihr Publikum verwirren.
+
+Wenn Sie möchten, dass eine Website, ein Twitter-Handle, o.Ä. Ihr Projekt repräsentieren, stellen Sie sicher, dass Sie die von Ihnen gewünschten Namen erhalten können. Um auf Nummer sicher zu gehen, können Sie [diese Namen jetzt reservieren](https://instantdomainsearch.com/), auch wenn Sie sie noch nicht verwenden möchten.
+
+Achten Sie darauf, dass der Name Ihres Projekts keine Marken verletzt, denn ein Unternehmen könnte Sie auffordern, Ihr Projekt zu einem späteren Zeitpunkt abzubrechen oder sogar rechtliche Schritte gegen Sie einzuleiten. Dieses Risiko einzugehen, ist es einfach nicht wert.
+
+Nutzen Sie die [WIPO Global Brand Database](http://www.wipo.int/branddb/en/), um auf Namenskonflikte zu prüfen. Wenn Sie in einer Firma sind, ist dies eine der Aufgaben, bei denen [Ihr Justiziariat Sie unterstützen kann](../legal/).
+
+Zum Schluss noch eine schnelle Google-Suche nach Ihrem Projektnamen: Werden die Leute Ihr Projekt leicht finden können, oder erscheint etwas anderes in den Suchergebnissen, das Sie nicht sehen möchten?
+
+### Auch den Schreib- und Programmierstil beeinflussen Ihre Marke!
+
+Während der Lebenszeit Ihres Projektes werden Sie eine Menge schreiben: README, Anleitungen, Dokumentation, Antworten auf Anfragen, vielleicht sogar Newsletter und auf einer Mailingliste.
+
+Egal ob offizielle Dokumentation oder informelle E-Mail: Ihr Schreibstil ist ein Markenzeichen Ihres Projektes. Bedenken Sie, wie er bei Ihrem Publikum ankommt, und ob dies dem Tonfall entspricht, den Sie rüberbringen möchten.
+
+
+
+Freundliche, [inklusive Sprache](https://fairlanguage.com/service/) kann Ihr Projekt einladender für neue Helfer\*innen machen. Bleiben Sie auch bei einfacher/leichter Sprache, denn nicht alle Ihrer Leser\*innen sind Muttersprachler\*innen.
+
+Neben Wortwahl und Schreibstil, wird auch Ihr Programmierstil Teil der Marke Ihres Projekts. [Angular](https://github.com/johnpapa/angular-styleguide) und [jQuery](https://contribute.jquery.org/style-guide/js/) beispielsweise haben strenge Richtlinien dafür.
+
+Eine Stilrichtlinie ist nicht sofort zum Start Ihres Projekts nötig, und vielleicht genießen Sie es auch, unterschiedliche Programmierstile in Ihr Projekt zu integrieren. Allerdings sollten Sie davon ausgehen, dass verschiedene Schreib- und Programmierstile verschiedene Leute anziehen oder abstoßen. Die Weichen für die Gemeinschaft, die Sie letztendlich aufbauen möchten, werden schon in frühen Projektphasen gelegt.
+
+## Ihre Checkliste zur Startvorbreitung
+
+Bereit für den Start Ihres Open-Source-Projektes? Diese Checkliste hilft Ihnen dabei. Alle Stationen bereit? Dann los! [Klicken Sie auf "publish"](https://help.github.com/articles/making-a-private-repository-public/) und klopfen Sie sich auf die Schulter.
+
+**Dokumentation**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+**Code**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+**Menschen**
+
+Wenn Sie als Einzelperson arbeiten:
+
+
+
+
+
+
+Wenn Sie als Firma oder Organisation arbeiten:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## Sie haben's geschafft!
+
+Herzlichen Glückwunsch zu Ihrem ersten Open-Source-Projekt! Egal was hinten raus kommt, öffentlich zu arbeiten, ist ein Geschenk an die Gemeinschaft. Sie erschaffen mit jedem Commit, jedem Kommentar und jedem Pull Request eine Gelegenheit für sich selbst und andere, etwas zu lernen und intellektuell zu wachsen.
diff --git a/_data/locales/de.yml b/_data/locales/de.yml
new file mode 100644
index 00000000000..18399935054
--- /dev/null
+++ b/_data/locales/de.yml
@@ -0,0 +1,31 @@
+de:
+ locale_name: Deutsch
+ nav:
+ about: Über
+ contribute: Mitarbeiten
+ index:
+ lead: Open-Source-Software wird von Menschen wie Ihnen gemacht. Lernen Sie, wie Sie Ihr Projekt anfangen und ausbauen können.
+ opensourcefriday: Es ist Freitag! Investieren Sie ein paar Stunden in die Software, die Sie verwenden und lieben.
+ article:
+ table_of_contents: Inhaltsverzeichnis
+ back_to_all_guides: Zurück zur Übersicht
+ related_guides: Verwandte Anleitungen
+ footer:
+ contribute:
+ heading: Mitmachen
+ description: Möchten Sie etwas vorschlagen? Unsere Anleitungen sind quelloffen. Helfen Sie uns, sie zu verbessern.
+ button: Mitmachen
+ subscribe:
+ heading: Bleiben Sie in Kontakt
+ description: Erfahren Sie als Erste*r von GitHubs neuesten Open-Source-Tipps und -Ressourcen.
+ label: E-Mail-Adresse
+ button: Abonnieren
+ byline:
+ # [code], [love], und [github] werden mit Octicons ersetzt.
+ format: "[code] mit [love] von [github] und [friends]"
+ # Label für das Code-Octicon
+ code_label: code
+ # Label für das Herz-Octicon
+ love_label: love
+ # Label für das Octicon der Mitwirkenden
+ friends_label: friends