From 9f3bd17a088d54cff6a0de1c6630d50f9bca50ca Mon Sep 17 00:00:00 2001 From: Charlotte Date: Tue, 27 Aug 2019 18:14:30 +0200 Subject: [PATCH] Add German translation of contributor cheatsheet --- .../guide/contributor-cheatsheet/README-de.md | 392 ++++++++++++++++++ .../guide/contributor-cheatsheet/README.md | 2 +- hack/.spelling_failures | 1 + 3 files changed, 394 insertions(+), 1 deletion(-) create mode 100644 contributors/guide/contributor-cheatsheet/README-de.md diff --git a/contributors/guide/contributor-cheatsheet/README-de.md b/contributors/guide/contributor-cheatsheet/README-de.md new file mode 100644 index 000000000..ae7428109 --- /dev/null +++ b/contributors/guide/contributor-cheatsheet/README-de.md @@ -0,0 +1,392 @@ +# Cheat-Sheet für Kubernetes-Beitragende + + +Eine Liste von oft-genutzten Ressourcen zum Beitragen zu Kubernetes; Tipps, Tricks +und allgemeine Best-Practices innerhalb des Kubernetes-Projekts. +Es ist als "TL;DR" (too long, didn't read - zu lang, nicht gelesen) oder Schnellreferenz +nützlicher Informationen gedacht, um deine Beitragserfahrung auf GitHub besser zu machen. + +**Inhaltsverzeichnis** +- [Hilfreiche Ressourcen](#Hilfreiche-Ressourcen) + - [Wie man anfängt](#Wie-man-anfängt) + - [SIGs und andere Gruppen](#SIGS-und-andere-Gruppen) + - [Community](#Community) + - [Important Email Aliases](#Important-Email-Aliases) + - [Ablauf](#Ablauf) + - [Tests](#Tests) + - [Wichtige Email-Adressen](#Wichtige-Email-Adressen) + - [Andere nützliche Links](#Andere-Nützliche-Links) +- [Effektive Kommunikation auf GitHub](#Effektive-Kommunikation-auf-GitHub) + - [Seid exzellent zueinander](#Seid-exzellent-zueinander) + - [Beispiele für gute/schlechte Kommunikation](#Beispiele-für-guteschlechte-Kommunikation) +- [Einen Beitrag einreichen](#Einen-Beitrag-einreichen) + - [Das CLA unterzeichnen](#Das-CLA-unterzeichnen) + - [Erstellen von und Antworten auf Issues](#Erstellen-von-und-Antworten-auf-Issues) + - [Erstellen eines Issues](#Erstellen-eines-Issues) + - [Antworten auf Issues](#Antworten-auf-Issues) + - [Öffnen eines Pull-Requests](#Öffnen-eines-Pull-Requests) + - [Erstellen eines Pull-Requests](#Erstellen-eines-Pull-Requests) + - [Beispiel PR-Beschreibung](#Beispiel-PR-Beschreibung) + - [Troubleshooting eines Pull-Requests](#Troubleshooting-eines-Pull-Requests) + - [Labels](#Labels) +- [Lokal arbeiten](#Lokal-arbeiten) + - [Branch-Strategie](#Branch-Strategie) + - [Upstream-hinzufügen](#Upstream-hinzufügen) + - [Synchron halten von Forks](#Synchron-halten-von-Forks) + - [Commits squashen](#Commits-squashen) + +--- + +## Hilfreiche Ressourcen + +### Wie man anfängt + +- [Contributor Guide] - Anleitung zum Beginn des Beitragens zum Kubernetes-Projekt. +- [Developer Guide] - Anleitung zum Beitragen von Code direkt zum Kubernetes-Projekt. +- [Security and Disclosure Information] - Anleitung zum Melden von Schwachstellen und + zur Sicherheit des Release-Prozesses. + +### SIGs und andere Gruppen + +- [Gruppenliste][SIGs] + +### Community + +- [Kalender] - Alle Kubernetes-Community-Events (SIG/WG Treffen, Events, usw.). +- [kubernetes-dev] - Kubernetesentwicklung-Mailingliste. +- [Kubernetes Forum] - Offizielles Kubernetes-Forum. +- [Slack Channels] - Offizieller Kubernetes-Slackchannel. +- [Stack-Overflow] - Zum Stellen von Kubernetes-Nutzerfragen. +- [YouTube Channel] - Offizieller Kubernetes-Youtubechannel. + + +### Ablauf + +- [Gubernator Dashboard] - Eingehende und Ausgehende Pull-Requests, die Aufmerksamkeit erfordern. +- [Prow] - Kubernetes CI/CD-System. +- [Tide] - Prow-Plugin das Merges und Tests verwaltet. [Tide Dashboard] +- [Bot-Befehle] - Befehle zur Interaktion mit Kubernetes-Bots (zum Beispiel: `/cc`, `/lgtm`, und `/retest`) +- [GitHub Labels] - Liste an Labels des ganzen Kubernets-Projekts. +- [Kubernetes Code Search], von [@dims] maintained. + + +### Tests + +- [Prow] - Kubernetes CI/CD-System. +- [Test Grid] - Ansicht historischer Tests und den zugehörigen Informationen. +- [Triage Dashboard] - Aggregiert ähnliche Fehler zur besseren Fehlerbehandlung. +- [Velodrome] - Dashboard zur Überwachung der Job- und Testgesundheit. + + +### Wichtige Email-Adressen + +- community@kubernetes.io - Maile jemandem im Community-Team (SIG Contributor + Experience) über ein Problem in der Community. +- conduct@kubernetes.io - Kontaktiere das Code-of-Conduct-Board, private Mailingliste. +- github@kubernetes.io - Maile dem [GitHub Administration Team] privat, + für heikle Themen. +- steering@kubernetes.io - Maile der Leitungsgruppe. Öffentliche Adresse mit + öffentlichem Archiv. +- steering-private@kubernetes.io - Maile der Leitungsgruppe private, für heikle Themen. +- social@cncf.io - Kontaktiere das CNCF Socal Media Team; Blog, Twitteraccount, und + andere soziale Bereiche. + + +### Andere nützliche Links + +- [Developer Statistiken] - Entwicklerstatistiken für alle von CNCF gemanagten Projekte. + +--- + +## Effektive Kommunikation auf GitHub + + +### Seid exzellent zueinander + +Als ersten Schritt sollte man sich mit dem [Code of Conduct] bekannt machen. + + +#### Beispiele für gute/schlechte Kommunikation + +Wenn man ein Problem anspricht, oder Hilfe sucht, sollte man die Anfrage höflich +formulieren: + + 🙂 “X kompiliert nicht, wenn ich Y mache, habt ihr Vorschläge dazu? + + 😞 “X geht nicht, fixt das!" + +Beim Schließen eines PRs ist es sinnvoll eine freundliche und erklärende Nachricht +hinzuzufügen weshalb dieser nicht die Mergeanforderungen erfüllt. + +🙂 “Ich schließe diesen PR, da dieses Feature nicht den Use-Case X unterstützt. In + der forgeschlagenen Form wäre es besser dies mit Y umzusetzen. Danke für deine + Mitarbeit daran." + +😞 “Warum folgt das nicht den API-Konventionen? Das sollte woanders gemacht werden!" + +--- + +## Einen Beitrag einreichen + +### Das CLA unterzeichnen + +Bevor man einen Beitrag einreichen kann, muss das [Contributor License Agreement (CLA) unterzeichnet][cla] +werden. Das Kubernetes-Projekt kann _nur_ einen Beitrag annehmen, wenn du oder deine Firma +das CLA unterzeichnet haben. + +Solltest du Probleme beim Unterzeichnen des CLAs haben, folge den [CLA Troubleshooting Guidelines][CLA +troubleshooting guidelines]. + + +### Erstellen von und Antworten auf Issues + +GitHub Issues sind der meistgenutzte Weg um Dinge wie Bugreports und Enhancementrequests +zu verfolgen, oder andere Probleme wie fehlschlagende Tests zu melden. +Sie sind **nicht** als [Anfragen für Usersupport][user support requests] gedacht. Für diese +gibt es den [Troubleshooting Guide][troubleshooting guide], [Stack-Overflow] oder das +[Kubernetes-Forum][Kubernetes Forum]. + +**Referenzen:** +- [Labels] +- [Prow Commands][commands] + + +#### Erstellen eines Issues + +- Nutze ein Issue-Template, wenn eines zur Verfügung steht. Das korrekte Template + hilft anderen Beitragenden auf deinen Issue zu antworten. + - Folge allen Anweisungen im Template selbst. +- Beschreibe den Issue detailliert. +- Füge sinnvolle [Labels][Labels] hinzu. Wenn du dir nicht sicher bist, hilft + der [K8s-ci-robot][Prow] Bot ([Kubernetes CI bot][Prow]) mit Antworten auf Issues, + damit diese effektive verwaltet werden. +- Sei selektiv beim Zuweisen von Issues zu Nutzern mit [`/assign @`][assign] + oder [`/cc @`][cc]. Der Issue wird effektiver verwaltet, wenn sinnvolle + Labels zugewiesen werden und weniger Menschen. + + +#### Antworten auf Issues + +- Wenn du an einem Issue arbeitest, hinterlasse einen Kommentar damit andere + wissen, dass du daran arbeitest und doppelte Arbeit vermieden wird. +- Falls du selbst eine Lösung findest, kommentiere den Issue mit einer Erklärung + bevor du ihn schließt. +- Referenzen auf andere PRs und Issues (oder andere Materialen) mit zum Beispiel: + _"ref: #1234"_ sind sinnvoll. Diese helfen Bezüge darauf zu finden, die an + anderer Stelle bearbeitet wurden. + + +### Öffnen eines Pull-Requests + +Pull-Requests (PR) sind die meistgenutzte Variante um Code, Dokumentation oder andere Arten +von Arbeit beizutragen, die in einem Git-Repository gespeichert werden können. + +**Referenzen:** +- [Labels] +- [Prow Commands][commands] +- [Pull-Request Prozess] +- [GitHub Workflow] + + +#### Erstellen eines Pull-Requests + +- Folge den Anweisungen des Pull-Request-Templates, falls eines zur Verfügung steht. + Es wird denen helfen, die auf den PR antworten. +- Für [triviale Fixes][trivial fix] wie kaputte Links, Schreib- oder Grammatikfehler + durchsuche das gesamte Dokument für andere potentielle Fehler. Mehrere PRs für kleine + Fixes im gleichen Dokument sind unnötig. +- Füge Referenzen auf verwandte Issues oder Issues die der PR lösen könnte hinzu. +- Vermeide unnötig große Änderungen in einem einzelnen Commit. Zerteile stattdessen + den PR in mehrere kleine, logische Commits. Das erleichter Reviews. +- Kommentiere deinen eigenen PR wenn du meinst weitere Erklärungen sind nötig. +- Sei selektiv beim Erstellen des PRs mit [`/assign @`][assign]. + Zu viele Reviewer garantieren keinen schnelleren PR-Review. +- Wenn der PR als _"Work in progress"_ angesehen wird, füge ein `[WIP]` am Anfang des + Titels hinzu oder nutze den [`/hold`][hold] Befehl. Das stellt sicher, dass der PR + nicht gemerged wird bis das `[WIP]` oder hold aufgehoben worden sind. +- Falls dein PR noch nicht reviewed wurde, bitte schließe ihn nicht und öffne einen Neuen + mit den gleichen Änderungen. Pinge deine Reviewer stattdessen in einem Kommentar mit + `@` an. + + +#### Beispiel PR-Beschreibung + +``` +Ref. #3064 #3097 +Alle Dateien im Besitz von SIG testing wurden von `/devel` zum neuen Ordner `/devel/sig-testing` +verschoben. + +/sig contributor-experience +/cc @stakeholder1 @stakeholder2 +/kind cleanup +/area developer-guide +/assign @approver1 @approver2 @approver3 +``` + +Was steht in diesem PR: +- **Zeile 1** - Referenzen auf andere Issues oder PRs (#3064 #3097). +- **Zeile 2** - Eine kurze Beschreibung was in diesem PR getan wird. +- **Zeile 4** - [SIG][SIGs] Zuweisung mit dem [Befehl][commands] + `/sig contributor-experience`.. +- **Zeile 5** - Reviewer die Interesse an diesem spezifischen Issue oder PR + haben könnten, werden mit [`/cc`][cc] markiert. +- **Zeile 6** - Der [`/kind cleanup`][kind] Befehl fügt ein [Label][Labels] hinzu, das + Issues oder PRs als Aufräumen von Code, Prozessen oder technologischer Schuld kategorisiert. +- **Zeile 7** - Der [`/area developer-guide`][kind] Befehl kategorisiert Issues oder PRs im Bezug + zum Developerguide. +- **Zeile 9** - Der Befehl [`/assign`][assign] fügt einen Approver zum PR hinzu. Ein Approver + wird vom [k8s-ci-robot][Prow] vorgeschlagen und wird von der Liste der Eingentümer in der + [OWNERS] Datei ausgewählt. file. Der Approver fügt das [`/approve`][approve] Label zum PR + hinzu nachdem dieser reviewed wurde. + + +#### Troubleshooting eines Pull-Requests + +Nachdem ein PR vorgeschlagen wurde, wird eine Reihe an Test von der Kubernetes +CL-Plattform [Prow] ausgeführt. Fall einer der Tests fehlschlägt, antwortet +der [K8s-ci-robot][Prow] auf den PR mit Links zu den fehlgeschlagenen Tests und +verfügbaren Logs. + +Neue Commits zu diesem PR sorgen dafür dass diese Tests erneut ausgeführt werden. + +Gelegentlich gibt es Probleme mit der Kubernetes CI-Plattform. Diese können aus +verschiedenen Gründen auftreten, selbst wenn der Beitrag alle lokalen Tests besteht. +Man kann einen neuen Testdurchlauf mit dem `/retest` Befehl auslösen. + +Für mehr Informationen zum Troubleshooting von spezifischen Test, siehe den [Testing Guide]. + + +### Labels + +Kubernetes nutzt [Labels][Labels] zum sichten und kategorisieren von Issues und Pull Requests. +Die richtigen Labels helfen dabei den Issue oder PR sinnvoller einzusortieren. + +**Referenzen:** +- [Labels] +- [Prow Commands][commands] + +Oft genutzte Labels: +- [`/sig `][kind] Fügt eine [SIG][SIGs] als Eigentümer des Issues oder PRs hinzu. +- [`/area `][kind] Verknüpft den Issue oder PR mit einem bestimmten [Bereich][labels]. +- [`/kind `][kind] [Kategorisiert][labels] den Issue oder PR. + +--- + +## Lokal arbeiten + +Bevor man einen Pull-Request vorschlagen kann, muss man lokal etwas Arbeit leisten. +Für Neueinsteiger zu git ist das [Atlassian Git-Tutorial][Atlassian git tutorial] +ein guter Einstiegspunkt. Alternativ ist das [Git Magic Tutorical][Git magic] der +Standford Uni eine gute multi-linguale Option. + +**Referenzen:** +- [Atlassion Git-Tutorial][Atlassian git tutorial] +- [Git magic] +- [GitHub Workflow] +- [Lokakes Testen][Testing locally] +- [Developer guide] + + +### Branch-Strategie + +Das Kubernetes-Projekt nutzt den Standardworkflow von GitHub, der sich _"Fork and Pull"_ +(auf Deutsch "abzweigen und ziehen") nennt. +In Begriffen aus der Git-Welt wird dein persönlicher Fork als _"`origin`"_ +(auf Deutsch "Ursprung") und das eigentliche Projekt-Gitrepository als _"`upstream`"_ +(wörtlich "flussaufwärts") bezeichnet. +Um deinen persönlichen Branch (`origin`) mit dem Projekt (`upstream`) aktuell zu halten, +muss das innerhalb der lokalen Kopie konfiguriert werden. + + +#### Upstream hinzufügen + +Füge `upstream` als sogenanntes remote hinzu und konfiguriere es so, dass man nicht dorthin +pushen kann. + +``` +# Ersetze mit der Upstreamrepo-URL +# Beispiel: +# https://github.com/kubernetes/kubernetes.git +# git@github.com/kubernetes/kubernetes.git + +git remote add upstream +git remote set-url --push upstream no_push +``` + +Das kann via `git remote -v` verifiziert werden, indem alle konfigurierten Remote-Repos +aufgelistet werden. + + +#### Synchron halten von Forks + +Hole alle Änderungen von `upstream` ab und _"rebase"_ diese auf deinem lokalen +`Master` Branch. Das wird dein lokales Repo mit dem `upstream` Projekt synchronisieren. + +``` +git fetch upstream +git checkout master +git rebase upstream/master +``` + +Das sollte minimal bevor der Erstellung eines neuen Branches für ein Feature oder +einen Fix passieren. + +``` +git checkout -b myfeature +``` + +#### Commits squashen + +Der Hauptzweck von [Commits squashen]("Commits zerquetschen") ist die Erstellung +einer sauberen, lesbaren Githistorie oder eines Logs der Änderungen die gemacht wurden. +Normal wird das in der letzten Phase einer PR Revision getan. Wenn du dir unsicher bist, +ob du deine Commits squashen solltest, ist es besser mehrere zu lassen und es dem Urteil +anderer Beitragenden zu überlassen, die als Reviewer und Approver für den PR zugeteilt wurden. + + +[Contributor Guide]: /contributors/guide/README.md +[Developer Guide]: /contributors/devel/README.md +[Gubernator Dashboard]: https://gubernator.k8s.io/pr +[Prow]: https://prow.k8s.io +[Tide]: http://git.k8s.io/test-infra/prow/cmd/tide/pr-authors.md +[Tide Dashboard]: https://prow.k8s.io/tide +[Bot-Befehle]: https://go.k8s.io/bot-commands +[GitHub Labels]: https://go.k8s.io/github-labels +[Kubernetes Code Search]: https://cs.k8s.io/ +[@dims]: https://github.com/dims +[Kalender]: https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com +[kubernetes-dev]: https://groups.google.com/forum/#!forum/kubernetes-dev +[Slack Channels]: http://slack.k8s.io/ +[Stack-Overflow]: https://stackoverflow.com/questions/tagged/kubernetes +[Youtube Channel]: https://www.youtube.com/c/KubernetesCommunity/ +[Triage Dashboard]: https://go.k8s.io/triage +[Test Grid]: https://testgrid.k8s.io +[Velodrome]: https://go.k8s.io/test-health +[Developer Statistiken]: https://k8s.devstats.cncf.io +[Code of Conduct]: /code-of-conduct.md +[user support requests]: /contributors/guide/issue-triage.md#determine-if-its-a-support-request +[troubleshooting guide]: https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/ +[Kubernetes Forum]: https://discuss.kubernetes.io/ +[Pull-Request Prozess]: /contributors/guide/pull-requests.md +[GitHub Workflow]: /contributors/guide/github-workflow.md +[Prow]: https://git.k8s.io/test-infra/prow#prow +[cla]: /CLA.md#how-do-i-sign +[CLA troubleshooting guidelines]: /CLA.md#troubleshooting +[commands]: https://prow.k8s.io/command-help +[kind]: https://prow.k8s.io/command-help#kind +[cc]: https://prow.k8s.io/command-help#cc +[hold]: https://prow.k8s.io/command-help#hold +[assign]: https://prow.k8s.io/command-help#assign +[SIGs]: /sig-list.md +[Testing Guide]: /contributors/devel/sig-testing/testing.md +[Labels]: https://git.k8s.io/test-infra/label_sync/labels.md +[trivial fix]: /contributors/guide/pull-requests.md#10-trivial-edits +[GitHub Workflow]: /contributors/guide/github-workflow.md#3-branch +[Commits squashen]: /contributors/guide/pull-requests.md#6-squashing-and-commit-titles +[OWNERS]: /contributors/guide/owners.md +[Testing locally]: /contributors/guide/README.md#testing +[Atlassian git tutorial]: https://www.atlassian.com/git/tutorials +[Git magic]: http://www-cs-students.stanford.edu/~blynn/gitmagic/ +[Security and Disclosure Information]: https://kubernetes.io/docs/reference/issues-security/security/ +[approve]: https://prow.k8s.io/command-help#approve +[GitHub Administration Team]: /github-management#github-administration-team diff --git a/contributors/guide/contributor-cheatsheet/README.md b/contributors/guide/contributor-cheatsheet/README.md index fc017e035..194b42518 100644 --- a/contributors/guide/contributor-cheatsheet/README.md +++ b/contributors/guide/contributor-cheatsheet/README.md @@ -1,6 +1,6 @@ # Kubernetes Contributor Cheat Sheet -[Bahasa Indonesia](README-id.md) | [日本語](README-ja.md) | [한국어](README-ko.md) | [Português](README-pt.md) | [中文](README-zh.md) +[Deutsch](README-de.md) | [Français](README-fr.md) | [Bahasa Indonesia](README-id.md) | [日本語](README-ja.md) | [한국어](README-ko.md) | [Português](README-pt.md) | [中文](README-zh.md) A list of common resources when contributing to Kubernetes, tips, tricks, and common best practices used within the Kubernetes project. It is a "TL;DR" or diff --git a/hack/.spelling_failures b/hack/.spelling_failures index 528c772dc..22fdbb0a7 100644 --- a/hack/.spelling_failures +++ b/hack/.spelling_failures @@ -4,3 +4,4 @@ sig-contributor-experience/contribex-survey-2018.csv events/2014 contributors/guide/contributor-cheatsheet/README-fr.md contributors/guide/contributor-cheatsheet/README-pt.md +contributors/guide/contributor-cheatsheet/README-de.md