Merge branch 'master' of github.com:kubernetes/community

16 files changed, 1159 insertions, 87 deletions

diff --git a/contributors/guide/README.md b/contributors/guide/README.md
index 9c2fcb80..d6040224 100644
--- a/contributors/guide/README.md
+++ b/contributors/guide/README.md
@@ -66,7 +66,7 @@ If you haven’t set up your environment, check the [developer resources](/contr
 Kubernetes is a community project.
 Consequently, it is wholly dependent on its community to provide a productive, friendly and collaborative environment.
 
-- Read and review the [Community Expectations](community-expectations.md) for an understanding of code and review expectations.
+- Read and review the [Community Expectations](expectations.md) for an understanding of code and review expectations.
 - See [Community Membership](/community-membership.md) for a list the various responsibilities of contributor roles. You are encouraged to move up this contributor ladder as you gain experience.  
 
 # Your First Contribution
@@ -103,8 +103,8 @@ Another good strategy is to find a documentation improvement, such as a missing/
 
 #### Issue Assignment in Github
 
-Often, new contributors ask to be assigned an issue they are willing to take on. Unfortunately, due to GitHub limitations we can only assign issues to [org members](#community) or repo collaborators. 
-Instead, please state in a comment that you intend to work on this issue and it will be assumed to be yours.
+When you are willing to take on an issue, you can assign it to yourself. Just reply with `/assign` or `/assign @yourself` on an issue, 
+then the robot will assign the issue to you and your name will present at `Assignees` list.
 
 ### Learn about SIGs
 
@@ -213,7 +213,7 @@ Common new contributor PR issues are:
 
 ## Code Review
 
-For a brief description of the importance of code review, please read [On Code Review](/contributors/guide/community-expectations.md#code-review).  
+For a brief description of the importance of code review, please read [On Code Review](/contributors/guide/expectations.md#code-review).  
 There are two aspects of code review: giving and receiving.
 
 To make it easier for your PR to receive reviews, consider the reviewers will need you to:
@@ -223,7 +223,7 @@ To make it easier for your PR to receive reviews, consider the reviewers will ne
 * break large changes into a logical series of smaller patches which individually make easily understandable changes, and in aggregate solve a broader issue
 * label PRs with appropriate SIGs and reviewers: to do this read the messages the bot sends you to guide you through the PR process
 
-Reviewers, the people giving the review, are highly encouraged to revisit the [Code of Conduct](/code-of-conduct.md) and must go above and beyond to promote a collaborative, respectful community.  
+Reviewers, the people giving the review, are highly encouraged to revisit the [Code of Conduct](/code-of-conduct.md) as well as [community expectations](./expectations.md#expectations-of-reviewers-review-latency) and must go above and beyond to promote a collaborative, respectful community.
 When reviewing PRs from others [The Gentle Art of Patch Review](http://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/) suggests an iterative series of focuses which is designed to lead new contributors to positive collaboration without inundating them initially with nuances:
 
 * Is the idea behind the contribution sound?
diff --git a/contributors/guide/contributor-cheatsheet.md b/contributors/guide/contributor-cheatsheet.md
deleted file mode 100644
index 1a1feb68..00000000
--- a/contributors/guide/contributor-cheatsheet.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/guide/contributor-cheatsheet/README.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-08-01 or the release of kubernetes 1.15, whichever comes first.
\ No newline at end of file
diff --git a/contributors/guide/contributor-cheatsheet/README-de.md b/contributors/guide/contributor-cheatsheet/README-de.md
new file mode 100644
index 00000000..ae742810
--- /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 @<username>`][assign] 
+  oder [`/cc @<username>`][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 @<username>`][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 
+  `@<github username>` 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 <sig name>`][kind] Fügt eine [SIG][SIGs] als Eigentümer des Issues oder PRs hinzu.
+- [`/area <area name>`][kind] Verknüpft den Issue oder PR mit einem bestimmten [Bereich][labels].
+- [`/kind <category>`][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 <upstream git repo> mit der Upstreamrepo-URL
+# Beispiel:
+#  https://github.com/kubernetes/kubernetes.git
+#  git@github.com/kubernetes/kubernetes.git
+
+git remote add upstream <upstream git repo>
+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-fr.md b/contributors/guide/contributor-cheatsheet/README-fr.md
new file mode 100644
index 00000000..73175a91
--- /dev/null
+++ b/contributors/guide/contributor-cheatsheet/README-fr.md
@@ -0,0 +1,330 @@
+# Cheat Sheet pour contributeur Kubernetes
+
+Une liste des ressources communes pour contribuer à Kubernetes, des trucs, des astuces et des bonnes pratiques communes utilisées dans le projet Kubernetes.
+C'est un "TL;DR" ou une référence rapide d'informations utiles pour améliorer votre expérience de contribution sur GitHub.
+
+**Table des matières**
+
+- [Ressources utiles](#Ressources-utiles)
+  - [Commencer](#Commencer)
+  - [SIGs et autres groupes](#SIGs-et-autres-groupes)
+  - [Communauté](#Communauté)
+  - [Alias de messagerie importants](#Alias-de-messagerie-importants)
+  - [Workflow](#Workflow)
+  - [Tests](#Tests)
+  - [Autres liens utiles](#Autres-liens-utiles)
+- [Communiquer efficacement sur GitHub](#Communiquer-efficacement-sur-GitHub)
+  - [Comment être excellent les uns envers les autres](#Comment-être-excellent-les-uns-envers-les-autres)
+    - [Exemples de bonne mauvaise communication](#Exemples-de-bonne-mauvaise-communication)
+- [Soumettre une contribution](#Soumettre-une-contribution)
+  - [Signature de la CLA](#Signature-de-la-CLA)
+  - [Ouverture et réponse aux Issues](#Ouverture-et-réponse-aux-Issues)
+    - [Créer une Issue](#Créer-une-Issue)
+    - [Répondre à une Issue](#Répondre-à-une-Issue)
+  - [Ouverture d'une Pull Request](#Ouverture-d-une-Pull-Request)
+    - [Créer une Pull Request](#Créer-une-Pull-Request)
+    - [Exemple d'une description de Pull Request](#Exemple-d'une-description-de-Pull-Request)
+    - [Dépannage d'une Pull Request](#Dépannage-d'une-Pull-Request)
+  - [Labels](#Labels)
+- [Travailler localement](#Travailler-localement)
+  - [Stratégie de branche](#Stratégie-de-branche)
+    - [Ajouter Upstream](#Ajouter-Upstream)
+    - [Garder votre Fork synchronisé](#Garder-votre-Fork-synchronisé)
+  - [Squashing Commits](#Squashing-Commits)
+
+---
+
+## Ressources utiles
+
+### Commencer
+
+- [Contributor Guide] - Guide sur la façon de commencer à contribuer au projet Kubernetes.
+- [Developer Guide] - Guide pour contribuer du code directement au projet Kubernetes.
+
+### SIGs et autres groupes
+
+- [Liste principale des groupes][sigs]
+
+### Communauté
+
+- [Calendar] - Voir tous les événements de la communauté Kubernetes (réunions SIG / WG, événements, etc.)
+- [kubernetes-dev] - La liste de diffusion sur le développement de Kubernetes
+- [Kubernetes Forum] - Forum officiel de Kubernetes.
+- [Slack channels] - Slack officiel de Kubernetes.
+- [StackOverflow] - Un endroit pour poser vos questions d'utilisateur final de Kubernetes.
+- [YouTube Channel] - Chaine officielle de la communauté Kubernetes.
+
+### Workflow
+
+- [Gubernator Dashboard] - Voir les Pull Requests entrantes et sortantes qui nécessitent votre attention.
+- [Prow] - Kubernetes CI/CD System.
+- [Tide] - Prow plugin that manages merges and tests. [Tide Dashboard]
+- [Bot commands] - Commands used to interact with Kubernetes Bots (examples:
+  `/cc`, `/lgtm`, and `/retest`)
+- [GitHub labels] - Liste des labels utilisées dans le projet Kubernetes
+- [Kubernetes Code Search], maintenu par [@dims]
+
+### Tests
+
+- [Prow] - Kubernetes CI/CD System.
+- [Test Grid] - Afficher les tests historiques et leurs informations associées.
+- [Triage Dashboard] - Regroupe les défaillances similaires pour un meilleur dépannage.
+- [Velodrome] - Tableau de bord pour suivre le travail et tester la santé.
+
+### Alias de messagerie importants
+
+| Alias                          | Description                                                                                                                     |   |
+|--------------------------------|---------------------------------------------------------------------------------------------------------------------------------|---|
+| community@kubernetes.io        | Envoyez un courrier électronique à l’équipe de la communauté (SIG Contributor Experience) au sujet d’un problème de communauté. |   |
+| conduct@kubernetes.io          | Contactez le comité du code de conduite, liste de diffusion privée.                                                             |   |
+| steering@kubernetes.io         | Postez le comité de pilotage. Adresse publique avec archive publique.                                                           |   |
+| steering-private@kubernetes.io | Contacter le steering comité en privé, pour les sujets sensibles.                                                               |   |
+| social@cncf.io                 | Contacter l'équipe sociale de la CNCF; blog, compte twitter et autres réseaux sociaux.                                          |   |
+
+### Autres liens utiles
+
+- [Statistiques de développeur] - Consultez les statistiques des développeurs pour tous les projets gérés par le CNCF.
+
+---
+
+## Communiquer efficacement sur GitHub
+
+### Comment être excellent les uns envers les autres
+
+Dans un premier temps, familiarisez-vous avec le [code de conduite].
+
+#### Exemples de bonne / mauvaise communication
+
+Quand on ouvre une issue, ou si vous avez besoin d’aide, soyez poli avec votre demande:
+
+  🙂 "X ne compile pas quand je fais le Y, avez-vous des suggestions?"
+
+  😞 «X ne marche pas! Réparez-ça, s'il vous plait!"
+
+Lors de la fermeture d'une PR, transmettez un message explicatif et cordial expliquant pourquoi elle ne remplit pas les conditions requises pour être mergé.
+
+🙂 «Je ferme ce PR car cette fonctionnalité ne peut pas prendre en charge le cas d’utilisation X. Dans le contexte proposé, il serait préférable de l’implémenter avec l’outil Y. Merci d'avoir travaillé sur cela. "
+
+😞 «Pourquoi cela ne suit-il pas les conventions de l’API? Cela devrait être fait ailleurs!
+
+---
+
+## Soumettre une contribution
+
+### Signature de la CLA
+
+Avant de pouvoir soumettre une contribution, vous devez [signer le Contributor License Agreement(CLA)][cla].
+Le projet Kubernetes ne peut accepter une contribution que si vous ou votre entreprise avez signé le CLA.
+
+Si vous rencontrez des problèmes pour signer le CLA, suivez les [consignes de dépannage du CLA].
+
+### Ouverture et réponse aux Issues
+
+Les GitHub Issues sont le principal moyen de suivre des éléments tels que les rapports de bogues, les demandes d'amélioration ou de signaler d'autres problèmes tels que l'échec des tests.
+Les issues ne sont **pas** destinées à être des [demandes de support utilisateur].
+Pour ceux-ci, veuillez consulter le [guide de dépannage], signaler le problème à [stackOverflow] ou faire un suivi sur le [forum Kubernetes].
+
+**References:**
+
+- [Labels]
+- [Prow commands][commands]
+
+#### Créer un Issue
+
+- Utilisez un Issuee template s'il en existe un. Utiliser le bon aidera d'autres contributeurs à répondre à votre problème.
+  - Suivez les instructions décrites dans le template d'issue lui-même.
+- Soyez descriptif avec la question que vous soulevez.
+- Attribuer les [labels] appropriés. Si vous n'êtes pas sûr, le [k8s-ci-robot][prow] bot ([Kubernetes CI bot][prow]) répondra à votre problème avec les étiquettes nécessaires à son tri efficace.
+- Soyez sélectif lorsque vous attribuez des Issues à l'aide de [`/assign @<username>`][assign] ou
+  [`/cc @<username>`][cc]. Votre Issue sera triée plus efficacement en appliquant les labels corrects sur l'affectation de plus de personnes à la question.
+
+#### Responding to an Issue
+
+- Lorsque vous abordez un problème, laissez-le savoir aux autres sur lesquels vous travaillez cela pour éviter le travail en double.
+- Lorsque vous avez résolu quelque chose par vous-même à un moment ultérieur, commentez la question de faire savoir aux gens avant de la fermer.
+- Inclure des références à d’autres demandes PullRequests ou Issues (ou à tout matériel accessible),
+  Exemple: _"ref: #1234"_. Il est utile d’identifier que des travaux connexes ont été résolu quelque part ailleurs.
+
+### Ouverture d'une Pull Request
+
+Les Pull requests (PR) sont les principaux moyens de contribuer au code, à la documentation ou à d’autres formes de travail qui seraient stockés dans un dépôt git.
+
+**References:**
+
+- [Labels]
+- [Prow commands][commands]
+- [Pull request process]
+- [Github workflow]
+
+#### Création d'une Pull Request
+
+- Follow the directions of the pull request template if one is available. Cela aidera ceux qui répondent à votre PullRequest.
+- Si un [correctif trivial] tel qu'un lien brisé, une faute de frappe ou une faute de grammaire, examinez l'ensemble du document pour rechercher d'autres erreurs potentielles. Ne pas ouvrir plusieurs PullRequests pour les petites corrections dans le même document.
+- Référencez tous les problèmes liés à votre PullRequest ou les problèmes que PullRequest peut résoudre.
+- Évitez de créer des modifications trop volumineuses dans un seul commit. Au lieu de cela, divisez votre PullRequest en plusieurs petits commits logiques. Cela facilite la révision de votre PullRequest.
+- Commentez votre propre PullRequest lorsque vous pensez que quelque chose peut nécessiter une explication.
+- Soyez sélectif lorsque vous affectez votre PullRequest avec [`/assign @<username>`][assign].
+  L'affectation d'un nombre excessif de réviseurs ne donnera pas une révision plus rapide de PullRequest.
+- Si votre PR est considéré comme un _"Work in progress"_ ajoutez un prefixe dans son nom avec `[WIP]` ou utilisez la commande [`/hold`][hold]. Ceci empêchera le merge de la PR jusqu'à la levée du `[WIP]` ou le retrait du hold.
+- Si votre demande PullRequest n'a pas été relue, ne la fermez pas et n'ouvrez pas une nouvelle demande PullRequest avec les mêmes modifications. Notifiez les relecteurs dans un commentaire avec `@<github username>`.
+
+#### Example PR Description
+
+```text
+Ref. #3064 #3097
+All files owned by SIG testing were moved from `/devel` to the new folder `/devel/sig-testing`.
+
+/sig contributor-experience
+/cc @stakeholder1 @stakeholder2
+/kind cleanup
+/area developer-guide
+/assign @approver1 @approver2 @approver3
+```
+
+Quel est le contenu de cette PR:
+
+- **Line 1** - Référence à d'autres issues ou PRs (#3064 #3097).
+- **Line 2** - Une brève description de ce qui se fait dans la PR.
+- **Line 4** - Assignement au [SIG][sigs] avec la [commande][commands]
+  `/sig contributor-experience`..
+- **Line 5** - Les examinateurs qui peuvent avoir un intérêt sur cette issue ou PR sont spécifiés avec la commande [`/cc`][cc].
+- **Line 6** - La commande [`/kind cleanup`][kind] ajoute un [label][labels] qui catégorise l'issue ou la PR en rapport avec le nettoyage du code, du processus ou de la dette technique.
+- **Line 7** - La commande [`/area developer-guide`][kind] catégorise une issue ou PR en relation avec le guide du développeur.
+- **Line 8** - La commande [`/assign`][assign] assigne un approbateur à la PR.
+  Un approbateur sera suggéré par le [k8s-ci-robot][prow] est sélectionné dans la liste des propriétaires définis dans le fichier [OWNERS]. Ils vont ajouter le label [`/approve`][approve] à la PR après l'avoir passé en revue.
+
+#### Troubleshooting a Pull Request
+
+Après la proposition de votre PR, une série de tests est exécutée par la plateforme Kubernetes CI, [Prow].
+Si l’un des tests échoue, le [k8s-ci-robot][prow] répondra à la PR avec des liens vers les tests ayant échoué et les journaux disponibles.
+
+Pousser de nouveaux commits vers votre PR va automatiquement déclencher la ré-exécution des tests.
+
+Il peut parfois y avoir des problèmes avec la plate-forme Kubernetes CI.
+Celles-ci peuvent survenir pour diverses raisons même si votre contribution réussit tous les tests locaux.
+Vous pouvez déclencher une nouvelle exécution des tests avec la commande `/retest`.
+
+Pour plus d'informations sur le dépannage de tests spécifiques, voir le [Guide de test].
+
+### Labels
+
+Kubernetes utilise [étiquettes] pour catégoriser et trier les Issues et PullRequests.
+L'application de labels appropriées aidera votre Issue ou PullRequest à être triée plus efficacement.
+
+**References:**
+
+- [Labels]
+- [Prow commands][commands]
+
+Labels fréquemment utilisés:
+
+- [`/sig <sig name>`][kind] Attribuer un [SIG][SIGs] à la propriété de l'issue ou de la PR.
+- [`/area <area name>`][kind] Associate the issue or PRs to a specific [area][labels].
+- [`/kind <category>`][kind] [Categorizes][labels] the issue or PR.
+
+---
+
+## Travailler localement
+
+Avant d'ouvrir une Pull Request, vous devrez effectuer préparer votre travail localement.
+Si vous êtes nouveau sur git, le [tutoriel Atlassian git] est un bon point de départ.
+En guise d'alternative, le didacticiel [Git magic] de Stanford est une bonne option multilingue.
+
+**References:**
+
+- [Atlassian git tutorial]
+- [Git magic]
+- [Github workflow]
+- [Testing locally]
+- [Developer guide]
+
+### Stratégie de branche
+
+Le projet Kubernetes utilise un workflow _"Fork and Pull"_ standard pour GitHub.
+Dans le vocabulaire de git, votre fork personnel est appellée _"`origin`"_ et le dépôt git de référence du projet est appellé _"`upstream`"_.
+Garder votre branche personnelle (`origin`) à jour avec le projet (`upstream`), il doit être configuré dans votre dépôt local.
+
+#### Ajouter Upstream
+
+Ajoutez `upstream` en tant que remote et configurez-le afin que vous ne puissiez pas y accéder.
+
+```shell
+# replace <upstream git repo> with the upstream repo url
+# example:
+#  https://github.com/kubernetes/kubernetes.git
+#  git@github.com/kubernetes/kubernetes.git
+
+git remote add upstream <upstream git repo>
+git remote set-url --push upstream no_push
+```
+
+Cela peut être vérifié en exécutant `git remote -v` qui listera vos remotes configurées.
+
+#### Garder votre dépôt synchronisé
+
+Récupérez toutes les modifications de `upstream` et _"rebase"_ sur votre branche `master` locale.
+Cela synchronisera votre dépôt local avec le projet `upstream`.
+
+```text
+git fetch upstream
+git checkout master
+git rebase upstream/master
+```
+
+Effectuez cette opération au minimum avant de créer une nouvelle branche pour travailler sur votre fonctionnalité ou votre correctif.
+
+```text
+git checkout -b myfeature
+```
+
+#### Squashing Commits
+
+Le but principal de [squashing commits] est de créer un historique git lisible.
+Cela se fait généralement dans la dernière phase d'une PullRequest.
+Si vous ne savez pas si vous devez faire un squash de vos commits, il est préférable de préférer avoir plus de commits et de laisser le soin aux autres contributeurs de réviser et d’approuver vos PullRequests.
+
+[guide du contributeur]: /contributors/guide/README.md
+[guide du développeur]: /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 commands]: 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
+[calendar]: 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/
+[stackOverflow]: 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
+[statistiques de développeur]: https://k8s.devstats.cncf.io
+[code of conduct]: /code-of-conduct.md
+[user support request]: /contributors/guide/issue-triage.md#determine-if-its-a-support-request
+[troubleshooting guide]: https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/
+[stack overflow]: https://stackoverflow.com/questions/tagged/kubernetes
+[kubernetes forum]: https://discuss.kubernetes.io/
+[pull request process]: /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#hold
+[hold]: https://prow.k8s.io/command-help#hold
+[assign]: https://prow.k8s.io/command-help#assign
+[SIGs]: /sig-list.md
+[Guide de test]: /contributors/devel/sig-testing/testing.md
+[labels]: https://git.k8s.io/test-infra/label_sync/labels.md
+[solution triviale]: /contributors/guide/pull-requests.md#10-trivial-edits
+[Github workflow]: /contributors/guide/github-workflow.md#3-branch
+[squashing commits]: /contributors/guide/pull-requests.md#6-squashing-and-commit-titles
+[owners]: /contributors/guide/owners.md
+[tester localement]: /contributors/guide/README.md#testing
+[developer guide]: /contributors/devel/README.md
+[Atlassian git tutorial]: https://www.atlassian.com/git/tutorials
+[git magic]: http://www-cs-students.stanford.edu/~blynn/gitmagic/
diff --git a/contributors/guide/contributor-cheatsheet/README-id.md b/contributors/guide/contributor-cheatsheet/README-id.md
index 94e0247b..04628dcd 100644
--- a/contributors/guide/contributor-cheatsheet/README-id.md
+++ b/contributors/guide/contributor-cheatsheet/README-id.md
@@ -7,32 +7,33 @@ yang bermanfaat untuk meningkatkan pengalaman kamu ketika berkontribusi
 di GitHub menjadi lebih baik.
 
 **Daftar Isi**
-- [_Resources_](#Resources)
-  - [Mulai Berkontribusi](#Mulai-Berkontribusi)
-  - [_SIG_ dan Grup Lainnya](#SIG-dan-Grup-lainnya)
-  - [Komunitas](#Komunitas)
-  - [Alamat Email Penting](#Alamat-Email-Penting)
-  - [_Workflow_](#Workflow)
-  - [Tes](#Testing)
-  - [Tautan Lain](#Tautan-Lain)
-- [Berkomunikasi Secara Efektif di GitHub](#Berkomunikasi-Secara-Efektif-di-GitHub)
-  - [Bagaimana Cara Bekerja Sama dengan Baik](#Bagaimana-Cara-Bekerja-Sama-dengan-Baik)
-    - [Contoh Komunikasi Yang Baik/Buruk](#Contoh-Komunikasi-yang-BaikBuruk)
-- [Langkah Berkontribusi](#Langkah-Berkontribusi)
-  - [Menyetujui CLA](#Menyetujui-CLA)
-  - [Membuka dan Menanggapi Isu](#Membuka-dan-Menanggapi-Isu)
-    - [Membuat sebuah Isu](#Membuat-sebuah-Isu)
-    - [Menanggapi sebuah Isu](#Menaggapi-sebuah-Isu)
-  - [Membuka _Pull Request_](#Membuka-Pull-Request)
-    - [Membuat a _Pull Request_](#Membuat-Pull-Request)
-    - [Contoh Deskripsi _Pull Request_](#Contoh-Deskripsi-Pull-Request)
-    - [_Troubleshoot_ sebuah _Pull Request_](#Troubleshooting-sebuah-Pull-Request)
-  - [Label](#Label)
-- [Mekanisme Pengerjaan Lokal](#Mekanisme-Pengerjaan-Lokal)
-  - [Mekanisme Penggunaan _Branch_](#Mekanisme-Penggunaan-Branch)
-    - [Menambahkan _Upstream_](#Menambahkan-Upstream)
-    - [Memastikan _Fork_ Kamu tetap Sinkron](#Memastikan-Fork-Kamu-Tetap-Sinkron)
-  - [Melakukan _Commit_ _Squashing_](#Squashing-Commits)
+- [_Cheat Sheet_ Kontributor Kubernetes](#cheat-sheet-kontributor-kubernetes)
+  - [_Resources_](#resources)
+    - [Mulai Berkontribusi](#mulai-berkontribusi)
+    - [_SIG_ dan Grup Lainnya](#sig-dan-grup-lainnya)
+    - [Komunitas](#komunitas)
+    - [_Workflow_](#workflow)
+    - [_Testing_](#testing)
+    - [Alamat Email Penting](#alamat-email-penting)
+    - [Tautan Lain](#tautan-lain)
+  - [Berkomunikasi Secara Efektif di GitHub](#berkomunikasi-secara-efektif-di-github)
+    - [Bagaimana Cara Bekerja Sama dengan Baik](#bagaimana-cara-bekerja-sama-dengan-baik)
+      - [Contoh Komunikasi Yang Baik/Buruk](#contoh-komunikasi-yang-baikburuk)
+  - [Mengumpulkan Kontribusi](#mengumpulkan-kontribusi)
+    - [Signing the CLA](#signing-the-cla)
+    - [Membuka dan Menanggapi Isu](#membuka-dan-menanggapi-isu)
+      - [Membuat Sebuah Isu](#membuat-sebuah-isu)
+      - [Menanggapi sebuah Isu](#menanggapi-sebuah-isu)
+    - [Membuka sebuah Pull Request (PR)](#membuka-sebuah-pull-request-pr)
+      - [Membuat sebuah Pull Request (PR)](#membuat-sebuah-pull-request-pr)
+      - [Contoh Deskripsi PR](#contoh-deskripsi-pr)
+      - [_Troubleshooting_ sebuah PR](#troubleshooting-sebuah-pr)
+    - [Label](#label)
+  - [Bekerja pada Mesin Lokal](#bekerja-pada-mesin-lokal)
+    - [Mekanisme _Branch_](#mekanisme-branch)
+      - [Menambahkan _Upstream_](#menambahkan-upstream)
+      - [Menjaga agar _Fork_ Kamu tetap Sinkron](#menjaga-agar-fork-kamu-tetap-sinkron)
+      - [Melakukan _Commit_ _Squashing_](#melakukan-commit-squashing)
 
 
 ---
@@ -68,10 +69,9 @@ di GitHub menjadi lebih baik.
 - [Tide] - _Plugin_ Prow yang melakukan manajemen _merge_ dan _test_. [Dashbor Tide]
 - [Perintah Bot] - Perintah yang dapat kamu gunakan untuk berinteraksi dengan Bot Kubernetes (contoh:
   `/cc`, `/lgtm`, dan `/retest`)
-- [_Label_ GitHub] - _List_ _label_ yang digunakan pada proyek Kubernetes
+- [Label GitHub] - _List_ _label_ yang digunakan pada proyek Kubernetes
 - [Pencarian Kode Kubernetes], di-_maintain_ oleh [@dims]
 
-
 ### _Testing_
 
 - [Prow] - Mekanisme CI/CD Kubernetes.
@@ -95,6 +95,7 @@ di GitHub menjadi lebih baik.
 ### Tautan Lain
 
 - [Statistik Pengembang] - Melihat statistik pengembang untuk semua proyek yang dikelola oleh CNCF.
+- [Rilis Patch Kubernetes] Jadwal dan informasi kontak tim untuk rilis _patch_ Kubernetes
 
 ---
 
@@ -150,7 +151,7 @@ atau ikuti [forum Kubernetes].
 - [Perintah Prow][perintah bot]
 
 
-#### Mmebuat Sebuah Isu
+#### Membuat Sebuah Isu
 
 - Gunakan templat isu (jika tersedia). Menggunakan templat yang tersedia akan 
   memudahkan kontributor lain ketika menanggapi isu yang kamu buat.
@@ -288,7 +289,7 @@ pembelajaran yang baik. Sebagai alternatif lain, juga terdapat tutorial [_Stanfo
 - [Git magic]
 - [GitHub workflow]
 - [Testing locally]
-- [Developer guide]
+- [Panduan Pengembang]
 
 
 ### Mekanisme _Branch_
@@ -353,8 +354,8 @@ _squashing_ perlu dilakukan atau tidak.
 [tide]: http://git.k8s.io/test-infra/prow/cmd/tide/pr-authors.md
 [asbor tide]: https://prow.k8s.io/tide
 [perintah bot]: https://go.k8s.io/bot-commands
-[gitHub labels]: https://go.k8s.io/github-labels
-[Kubernetes Code Search]: https://cs.k8s.io/
+[Label GitHub]: https://go.k8s.io/github-labels
+[Pencarian Kode Kubernetes]: 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
@@ -364,7 +365,7 @@ _squashing_ perlu dilakukan atau tidak.
 [dasbor triase]: https://go.k8s.io/triage
 [test grid]: https://testgrid.k8s.io
 [velodrome]: https://go.k8s.io/test-health
-[developer statistics]: https://k8s.devstats.cncf.io
+[Statistik Pengembang]: https://k8s.devstats.cncf.io
 [code of conduct]: /code-of-conduct.md
 [_user support request_]: /contributors/guide/issue-triage.md#determine-if-its-a-support-request
 [petunjuk _troubleshooting_]: https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/
@@ -390,3 +391,5 @@ _squashing_ perlu dilakukan atau tidak.
 [Tutorial git Atlassian]: https://www.atlassian.com/git/tutorials
 [git magic]: http://www-cs-students.stanford.edu/~blynn/gitmagic/
 [_Security_ dan _Disclosure_ Informasi]: https://kubernetes.io/docs/reference/issues-security/security/
+[approve]: https://prow.k8s.io/command-help#approve
+[Rilis Patch Kubernetes]: https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md
\ No newline at end of file
diff --git a/contributors/guide/contributor-cheatsheet/README-ja.md b/contributors/guide/contributor-cheatsheet/README-ja.md
new file mode 100644
index 00000000..ab39c1c1
--- /dev/null
+++ b/contributors/guide/contributor-cheatsheet/README-ja.md
@@ -0,0 +1,339 @@
+# Kubernetesコントリビューターチートシート
+
+Kubernetesにコントリビュートする際のtipsや、Kubernetesプロジェクト内で使用されているベストプラクティスなどの共通リソースのリストです。
+これらのまとめや便利な情報へのクイックリファレンスはGitHubでのコントリビューションの体験をよりよいものにすることでしょう。
+
+**目次**
+- [便利なリソース](#便利なリソース)
+  - [はじめに](#はじめに)
+  - [SIGとその他のグループ](#SIGとその他のグループ)
+  - [コミュニティ](#コミュニティ)
+  - [重要なEメールエイリアス](#重要なEメールエイリアス)
+  - [ワークフロー](#ワークフロー)
+  - [テスト](#テスト)
+  - [その他の便利なリンク](#その他の便利なリンク)
+- [GitHub上での効率的なコミュニケーション](#GitHub上での効率的なコミュニケーション)
+  - [お互いに良くあるためにはどうしたらよいか](#お互いに良くあるためにはどうしたらよいか)
+    - [良いまたは悪いコミュニケーションの例](#良いまたは悪いコミュニケーションの例)
+- [貢献する](#貢献する)
+  - [CLAにサインする](#CLAにサインする)
+  - [Issueを開いたり返事をしたりする](#Issueを開いたり返事をしたりする)
+    - [Issueを作る](#Issueを作る)
+    - [Issueに返事をする](#Issueに返事をする)
+  - [Pull Requestを開く](#Pull-Requestを開く)
+    - [Pull Requestを作成する](#Pull-Requestを作成する)
+    - [PRの説明文の例](#PRの説明文の例)
+    - [Pull Requestのトラブルシューティング](#Pull-Requestのトラブルシューティング)
+  - [ラベル](#ラベル)
+- [ローカルでの作業](#ローカルでの作業)
+  - [ブランチ戦略](#ブランチ戦略)
+    - [Upstreamを追加する](#Upstreamを追加する)
+    - [フォークを最新に保つ](#フォークを最新に保つ)
+  - [コミットをまとめる](#コミットをまとめる)
+
+---
+
+## 便利なリソース
+
+### はじめに
+
+- [コントリビューターガイド] - Kubernetesプロジェクトへコントリビュートする方法のガイド
+- [開発者ガイド] - Kubernetesプロジェクトへコードを直接コントリビュートする方法のガイド
+- [セキュリティと情報開示] - 脆弱性の報告とセキュリティリリースプロセスのガイド
+
+### SIGとその他のグループ
+
+- [グループのリスト][sigs]
+
+### コミュニティ
+
+- [カレンダー] - Kubernetesコミュニティでのイベントの一覧(SIG/WGのミーティングやイベントなど)
+- [kubernetes-dev] - Kubernetes開発メーリングリスト
+- [Kubernetesフォーラム] - Kubernetesの公式フォーラム
+- [Slackチャンネル] - Kubernetesの公式Slack
+- [Stack Overflow] - Kubernetesのエンドユーザーとしての質問を聞く場所
+- [YouTubeチャンネル] - Kubernetesコミュニティの公式チャンネル
+
+
+### ワークフロー
+
+- [Gubernatorダッシュボード] - 注意して見ておくべきPull Requests
+- [Prow] - KubernetesのCI/CDシステム
+- [Tide] - mergeやtestを管理するためのProw用プラグイン [Tideダッシュボード]
+- [Botコマンド] - KubernetesのBotとコミュニケーションをとるためのコマンド (例: `/cc`、`/lgtm`や`/retest`)
+- [GitHubラベル] - Kubernetesプロジェクトで使用されるラベルのリスト
+- [@dims]によって保守されている[Kubernetes Code Search]
+
+
+### テスト
+
+- [Prow] - KubernetesのCI/CDシステム
+- [Test Grid] - 歴史的なテストや関連した情報を見る
+- [Triageダッシュボード] - よりよくトラブルシューティングをするために、似たような失敗をまとめる
+- [Velodrome] - ジョブやテスト結果を追跡するためのダッシュボード
+
+
+### 重要なEメールエイリアス
+
+- community@kubernetes.io - コミュニティの問題について、コミュニティチーム(SIG Contributor Experience)の誰かにメールするアドレス
+- conduct@kubernetes.io - 行動規範委員会へ連絡を取るためのプライベートメーリングリスト
+- steering@kubernetes.io - 運営委員会へメールするアドレスで、公開アーカイブのある公開アドレス
+- steering-private@kubernetes.io - 運営委員会へセンシティブなことを伝えるためのプライベートアドレス
+- social@cncf.io - CNCFソーシャルチームへの連絡先(blogやtwitterアカウントなど)
+
+
+### その他の便利なリンク
+
+- [開発者統計] - CNCFが管理するプロジェクトの開発者統計情報
+
+---
+
+## GitHub上での効率的なコミュニケーション
+
+
+### お互いに良くあるためにはどうしたらよいか
+
+まず最初に[Code of Conduct]をよく読んでください。
+
+
+#### 良いまたは悪いコミュニケーションの例
+
+issueをあげる時や助けを求める時、礼儀正しくしてください:
+
+  🙂 「Yをやった時にXがコンパイルできませんでした。なにかいい方法はありませんか？」
+
+  😞 「Xが動かない！直して！」
+
+PRを閉じるとき、どうしてmergeできないのか、誠心誠意説明し、伝えてください。
+
+🙂 「この機能はXというユースケースをサポートしていないのでこのPRを閉じます。提案された形であれば、Yツールで実装される方がよりよいと思います。」
+
+😞 「どうしてAPI規約に従っていないんですか？これは他でやるべきです！」
+
+---
+
+## 貢献する
+
+### CLAにサインする
+
+コントリビューションを提出する前に、[Contributor License Agreement(CLA)にサインする](cla)必要があります。Kubernetesプロジェクトは、あなたもしくはあなたの会社がCLAにサイン済みの場合にのみコントリビューションの受け入れを行います。
+
+CLAのサインで何か問題があった場合、[CLAトラブルシューティングガイドライン]を参照してください。
+
+
+### Issueを開いたり返事をしたりする
+
+GitHub Issueはバグレポートや改善要求、あるいはテスト失敗のようなその他の問題を追跡するための最初の手段です。[ユーザーによるサポート要求]の方法としては使用**されていません**。そのような場合は[トラブルシューティングガイド]をみて、[Stack Overflow]や[Kubernetesフォーラム]に問題を報告してください。
+
+**参考:**
+- [ラベル]
+- [Prowコマンド][コマンド]
+
+
+#### Issueを作る
+
+- もし用意されているなら、Issue templateを使用してください。適切なテンプレートを使用することで、他のコントリビューターが返信しやすくなります。
+  - Issue template自体に書かれている手順に従ってください。
+- 詳細な説明をIssueに記述してください。
+- 適切な[ラベル]を設定してください。よくわからなければ、[k8s-ci-robot][prow]([Kubernetes CI bot][prow])というボットが、重要度を適切に判断するために必要なラベルを提案します。
+- [`/assign @<username>`][assign]か[`/cc @<username>`][cc]を使用して担当者をアサインする場合は選択的に行ってください。より多くの人にアサインをするより、適切なラベルを付ける方が効果的です。
+
+
+#### Issueに返事をする
+
+- Issueに取り組む時は、他の人とバッティングしないように、コメントを残してください。
+- 自己解決した場合には、Issueを閉じる前に他の人にわかるようコメントしてください。
+- 他のPRやIssue(あるいはその他アクセス可能なもの)への参照を含めてください(例えば、 _"ref: #1234"_ のように)。他の場所にある関連した作業を特定するのに便利です。
+
+
+### Pull Requestを開く
+
+Pull request(PR)はコード、ドキュメント、あるいはgitリポジトリに格納されているその他のものに対してコントリビュートする際の主な手段です。
+
+**参考:**
+- [ラベル]
+- [Prowコマンド][コマンド]
+- [Pull request process]
+- [GitHub workflow]
+
+
+#### Pull Requestを作成する
+
+- 利用可能な場合、Pull Requestテンプレートの指示に従います。 それはあなたのPRに対応する人々の助けになります。
+- リンク切れやタイプミス、文法の間違いなどの[簡単な修正]の場合、他の可能性のある間違いについてドキュメント全体を見直してください。
+  同じドキュメントの小さな修正で複数のPRを作成しないでください。
+- PRに関連するIssueやPRで解決する可能性があるIssueを参照してください。
+- 一度のコミットで過大な変更を加えないでください。代わりに、PRを複数の小さなコミットに分割してください。
+  これによりPRのレビューが容易になります。
+- 何か説明を加える必要があると思われる場合は、PRにコメントしてください。
+- [`/assign @<username>`][assign]でPRに割り当てるときは選択的にしてください。
+  過剰なレビュー担当者を割り当てたからといって、 迅速なレビューが得られるわけではありません。
+- あなたのPRが _"進行中"_ とされる場合、名前の前に `[WIP]` を付けるか、[`/hold`][hold]コマンドを使用してください。これは `[WIP]` またはHoldが解除されるまでPRがマージされるのを防ぎます。
+- あなたのPRがレビューされてない場合に、閉じて同じ変更のPRを新しく作成しないでください。`@<github username>` とコメントでレビュアーにPingしてください。
+
+
+
+#### PRの説明文の例
+
+```
+Ref. #3064 #3097
+All files owned by SIG testing were moved from `/devel` to the new folder `/devel/sig-testing`.
+
+/sig contributor-experience
+/cc @stakeholder1 @stakeholder2
+/kind cleanup
+/area developer-guide
+/assign @approver1 @approver2 @approver3
+```
+
+PRの内容:
+- **1行目** - 他のIssueやPRへの参照(#3064 #3097)
+- **2行目** - PRで行われていることの簡単な説明
+- **4行目** - `/sig contributor-experience` [コマンド]での[SIG][sigs]の割り当て
+- **5行目** - この特定のIssueやPRに関心があるレビュアーを[`/cc`][cc]コマンドで指定
+- **6行目** - [`/kind cleanup`][kind]コマンドでコードやプロセス、技術的負債の整理に関してIssueやPRを分類する[ラベル][ラベル]を追加
+- **7行目** - [`/area developer-guide`][kind]コマンドで開発者ガイドに関してIssueやPRを分類
+- **8行目** - [`/assign`][assign]コマンドでPRにApproverを割り当て。
+  Approverは[k8s-ci-robot][prow]によって提案され、[OWNERS]ファイルのオーナーのリストから選択されます。
+  Approverはレビューされた後のPRに[`/approve`][approve]ラベルを追加します
+
+#### Pull Requestのトラブルシューティング
+
+PRが作成された後、KubernetesのCIプラットフォームの[Prow]によって一連のテスト
+が実行されます。テストのいずれかが失敗した場合、[k8s-ci-robot][prow]は
+失敗したテストへのリンクと有効なログをPRに返信します。
+
+新しいコミットをPRにがプッシュすると、自動的にテストが再実行されます。
+
+時折KubernetesのCIプラットフォームに問題がある場合があります。
+あなたの貢献が全てのローカルテストに合格したとしても、
+これらは様々な理由で発生する場合があります。`/retest` コマンドでテストを
+再実行することができます。
+
+特定のテストのトラブルシューティングの詳細については[テストガイド]を参照してください。
+
+### ラベル
+
+KubernetesはIssueとPull Requestを分類し、優先順位を付けるために[ラベル]を使用します。
+正しいラベルを付けることであなたのIssueやPRをより効果的に処理することができます。
+
+
+**参考:**
+- [ラベル]
+- [Prowコマンド][コマンド]
+
+よく使われるラベル:
+- [`/sig <sig name>`][kind]はIssueやPRのアサインを[SIG][SIGs]に割り当てます。
+- [`/area <area name>`][kind]はIssueやPRを特定の[分野][ラベル]に関連付けます。
+- [`/kind <category>`][kind]はIssueやPRを[分類][ラベル]します。
+
+---
+
+## ローカルでの作業
+
+Pull Requestを作成する前に、ローカルである程度の作業を行う必要があります。
+もしあなたがgitに慣れていない場合、[Atlassian gitチュートリアル]は良い出発点です。
+他に、Stanfordの[Git magic]チュートリアルは多言語に対応しています。
+
+**参考:**
+- [Atlassian gitチュートリアル]
+- [Git magic]
+- [GitHub workflow]
+- [ローカルでのテスト]
+- [開発者ガイド]
+
+
+### ブランチ戦略
+
+KubernetesプロジェクトはGitHubの標準である _"Fork and Pull"_ ワークフローを使います。
+gitの用語で、あなたの個人的なフォークは _"`origin`"_ と呼ばれ、実際のプロジェクトの
+gitリポジトリのことを _"`upstream`"_ と呼ばれます。
+あなたの個人的なブランチ(`origin`)をプロジェクト(`upstream`)の最新に保つために、
+ローカルの作業コピー内で設定されてなければなりません。
+
+
+#### Upstreamを追加する
+
+`upstream` をリモートとして追加し、プッシュできないように設定してください。
+
+```
+# replace <upstream git repo> with the upstream repo url
+# example:
+#  https://github.com/kubernetes/kubernetes.git
+#  git@github.com/kubernetes/kubernetes.git
+
+git remote add upstream <upstream git repo>
+git remote set-url --push upstream no_push
+```
+
+これは設定したリモートを一覧表示する `git remote -v` を実行して確認することができます。
+
+
+#### フォークを最新に保つ
+
+`upstream` から全ての変更を取得し、ローカルの `master` ブランチに _"rebase"_ します。
+これはローカルのリポジトリを `upstream` プロジェクトと同期させます。
+
+```
+git fetch upstream
+git checkout master
+git rebase upstream/master
+```
+
+あなたは機能への取り組みや修正をするためにブランチを作成する前に、最低限これをやるべきです。
+
+```
+git checkout -b myfeature
+```
+
+#### コミットをまとめる
+
+[スカッシュコミット]の主な目的はきれいに読めるgitの履歴や加えられた変更のログを作成することです。通常これはPRの改定の最終段階に行われます。
+コミットをスカッシュするべきかわからない場合は、作業を止めてPRのレビューと承認を担当する他のコントリビューターの判断に任せることをおすすめします。
+
+
+[コントリビューターガイド]: /contributors/guide/README.md
+[開発者ガイド]: /contributors/devel/README.md
+[gubernatorダッシュボード]: https://gubernator.k8s.io/pr
+[prow]: https://prow.k8s.io
+[tide]: http://git.k8s.io/test-infra/prow/cmd/tide/pr-authors.md
+[tideダッシュボード]: https://prow.k8s.io/tide
+[botコマンド]: https://go.k8s.io/bot-commands
+[GitHubラベル]: https://go.k8s.io/github-labels
+[Kubernetes Code Search]: https://cs.k8s.io/
+[@dims]: https://github.com/dims
+[カレンダー]: https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com
+[kubernetes-dev]: https://groups.google.com/forum/#!forum/kubernetes-dev
+[slackチャンネル]: http://slack.k8s.io/
+[Stack Overflow]: https://stackoverflow.com/questions/tagged/kubernetes
+[youtubeチャンネル]: https://www.youtube.com/c/KubernetesCommunity/
+[triageダッシュボード]: https://go.k8s.io/triage
+[test grid]: https://testgrid.k8s.io
+[velodrome]: https://go.k8s.io/test-health
+[開発者統計]: https://k8s.devstats.cncf.io
+[code of conduct]: /code-of-conduct.md
+[ユーザーによるサポート要求]: /contributors/guide/issue-triage.md#determine-if-its-a-support-request
+[トラブルシューティングガイド]: https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/
+[kubernetesフォーラム]: https://discuss.kubernetes.io/
+[pull request process]: /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トラブルシューティングガイドライン]: /CLA.md#troubleshooting
+[コマンド]: 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
+[テストガイド]: /contributors/devel/sig-testing/testing.md
+[ラベル]: https://git.k8s.io/test-infra/label_sync/labels.md
+[簡単な修正]: /contributors/guide/pull-requests.md#10-trivial-edits
+[GitHub workflow]: /contributors/guide/github-workflow.md#3-branch
+[スカッシュコミット]: /contributors/guide/pull-requests.md#6-squashing-and-commit-titles
+[owners]: /contributors/guide/owners.md
+[ローカルでのテスト]: /contributors/guide/README.md#testing
+[Atlassian gitチュートリアル]: https://www.atlassian.com/git/tutorials
+[git magic]: http://www-cs-students.stanford.edu/~blynn/gitmagic/
+[セキュリティと情報開示]: https://kubernetes.io/docs/reference/issues-security/security/
+[approve]: https://prow.k8s.io/command-help#approve
diff --git a/contributors/guide/contributor-cheatsheet/README-ko.md b/contributors/guide/contributor-cheatsheet/README-ko.md
index 2d33bda9..9a541dd5 100644
--- a/contributors/guide/contributor-cheatsheet/README-ko.md
+++ b/contributors/guide/contributor-cheatsheet/README-ko.md
@@ -394,3 +394,4 @@ PR을 검토하고 승인하도록 지정된 다른 참여자의 판단에 맡�
 [Atlassian git 튜토리얼]: https://www.atlassian.com/git/tutorials
 [git magic]: http://www-cs-students.stanford.edu/~blynn/gitmagic/
 [보안과 정보 공개]: https://kubernetes.io/docs/reference/issues-security/security/
+[approve]: https://prow.k8s.io/command-help#approve
diff --git a/contributors/guide/contributor-cheatsheet/README-pt.md b/contributors/guide/contributor-cheatsheet/README-pt.md
index a66ffaa0..1388f404 100644
--- a/contributors/guide/contributor-cheatsheet/README-pt.md
+++ b/contributors/guide/contributor-cheatsheet/README-pt.md
@@ -375,3 +375,4 @@ fase de uma revisão do PR. Se você não tem certeza se deve efetuar o squashin
 [Tutorial git Atlassian]: https://www.atlassian.com/git/tutorials
 [Tutorial git magic]: http://www-cs-students.stanford.edu/~blynn/gitmagic/
 [Informações de Segurança e Divulgações]: https://kubernetes.io/docs/reference/issues-security/security/
+[approve]: https://prow.k8s.io/command-help#approve
diff --git a/contributors/guide/contributor-cheatsheet/README-zh.md b/contributors/guide/contributor-cheatsheet/README-zh.md
index 8c86dfcb..65ef556e 100644
--- a/contributors/guide/contributor-cheatsheet/README-zh.md
+++ b/contributors/guide/contributor-cheatsheet/README-zh.md
@@ -326,3 +326,4 @@ git checkout -b myfeature
 [Atlassian git 教程]: https://www.atlassian.com/git/tutorials
 [git 魔法]: http://www-cs-students.stanford.edu/~blynn/gitmagic/
 [安全和披露信息]: https://kubernetes.io/docs/reference/issues-security/security/
+[approve]: https://prow.k8s.io/command-help#approve
diff --git a/contributors/guide/contributor-cheatsheet/README.md b/contributors/guide/contributor-cheatsheet/README.md
index bef061d0..d5e2f460 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-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
@@ -8,32 +8,33 @@ quick reference of useful information to make your GitHub contribution experienc
 better.
 
 **Table of Contents**
-- [Helpful Resources](#Helpful-Resources)
-  - [Getting Started](#Getting-Started)
-  - [SIGs and other Groups](#SIGS-and-Other-Groups)
-  - [Community](#Community)
-  - [Important Email Aliases](#Important-Email-Aliases)
-  - [Workflow](#Workflow)
-  - [Tests](#Tests)
-  - [Other Useful Links](#Other-Useful-Links)
-- [Communicating effectively on GitHub](#Communicating-Effectively-on-GitHub)
-  - [How to be Excellent to Each Other](#How-to-be-Excellent-to-Each-Other)
-    - [Examples of Good/Bad Communication](#Examples-of-GoodBad-Communication)
-- [Submitting a Contribution](#Submitting-a-Contribution)
-  - [Signing the CLA](#signing-the-CLA)
-  - [Opening and Responding to Issues](#Opening-and-Responding-to-Issues)
-    - [Creating an Issue](#Creating-an-Issue)
-    - [Responding to an Issue](#Responding-to-an-Issue)
-  - [Opening a Pull Request](#Opening-a-pull-Request)
-    - [Creating a Pull Request](#Creating-a-Pull-Request)
-    - [Example PR Description](#Example-PR-Description)
-    - [Troubleshooting a Pull Request](#Troubleshooting-a-Pull-Request)
-  - [Labels](#Labels)
-- [Working Locally](#Working-Locally)
-  - [Branch Strategy](#Branch-Strategy)
-    - [Adding Upstream](#Adding-Upstream)
-    - [Keeping Your Fork in Sync](#Keeping-Your-Fork-in-Sync)
-  - [Squashing Commits](#Squashing-Commits)
+- [Kubernetes Contributor Cheat Sheet](#kubernetes-contributor-cheat-sheet)
+  - [Helpful Resources](#helpful-resources)
+    - [Getting Started](#getting-started)
+    - [SIGs and Other Groups](#sigs-and-other-groups)
+    - [Community](#community)
+    - [Workflow](#workflow)
+    - [Tests](#tests)
+    - [Important Email Aliases](#important-email-aliases)
+    - [Other Useful Links](#other-useful-links)
+  - [Communicating Effectively on GitHub](#communicating-effectively-on-github)
+    - [How to be Excellent to Each Other](#how-to-be-excellent-to-each-other)
+      - [Examples of Good/Bad Communication](#examples-of-goodbad-communication)
+  - [Submitting a Contribution](#submitting-a-contribution)
+    - [Signing the CLA](#signing-the-cla)
+    - [Opening and Responding to Issues](#opening-and-responding-to-issues)
+      - [Creating an Issue](#creating-an-issue)
+      - [Responding to an Issue](#responding-to-an-issue)
+    - [Opening a Pull Request](#opening-a-pull-request)
+      - [Creating a Pull Request](#creating-a-pull-request)
+      - [Example PR Description](#example-pr-description)
+      - [Troubleshooting a Pull Request](#troubleshooting-a-pull-request)
+    - [Labels](#labels)
+  - [Working Locally](#working-locally)
+    - [Branch Strategy](#branch-strategy)
+      - [Adding Upstream](#adding-upstream)
+      - [Keeping Your Fork in Sync](#keeping-your-fork-in-sync)
+      - [Squashing Commits](#squashing-commits)
 
 ---
 
@@ -90,6 +91,8 @@ better.
   Experience) about a community issue.
 - conduct@kubernetes.io - Contact the Code of Conduct committee, private mailing
   list.
+- github@kubernetes.io - Mail the [GitHub Administration Team] privately,
+  for sensitive items.
 - steering@kubernetes.io - Mail the steering committee. Public address with
   public archive.
 - steering-private@kubernetes.io - Mail the steering committee privately, for
@@ -102,6 +105,7 @@ better.
 
 - [Developer Statistics] - View developer statistics for all CNCF managed
   projects.
+- [Kubernetes Patch Release] Schedule and team contact information for Kubernetes patch releases.
 
 ---
 
@@ -395,3 +399,6 @@ the other contributors assigned to review and approve your PR.
 [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
+[Kubernetes Patch Release]: https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md
\ No newline at end of file
diff --git a/contributors/guide/community-expectations.md b/contributors/guide/expectations.md
index 6a7922fc..dabbb248 100644
--- a/contributors/guide/community-expectations.md
+++ b/contributors/guide/expectations.md
@@ -54,6 +54,8 @@ to them.  Reviewers are expected to respond to an *active* PRs with reasonable
 latency, and if reviewers fail to respond, those PRs may be assigned to other
 reviewers.
 
+If reviewers are unavailable to review for some time, they are expected to set their [user status](https://help.github.com/en/articles/personalizing-your-profile#setting-a-status) to "busy" so that the bot will not request reviews from them on new PRs automatically. If they are unavailable for a longer period of time, they are expected to remove themselves from the OWNERS file and potentially nominate someone else.
+
 *Active* PRs are considered those which have a proper CLA (`cla:yes`) label
 and do not need rebase to be merged.  PRs that do not have a proper CLA, or
 require a rebase are not considered active PRs.
diff --git a/contributors/guide/github-workflow.md b/contributors/guide/github-workflow.md
index 48a67fa3..8174aaf8 100644
--- a/contributors/guide/github-workflow.md
+++ b/contributors/guide/github-workflow.md
@@ -107,7 +107,7 @@ in a few cycles.
 
 ### 6 Push
 
-When ready to review (or just to establish an offsite backup or your work),
+When ready to review (or just to establish an offsite backup of your work),
 push your branch to your fork on `github.com`:
 
 ```sh
diff --git a/contributors/guide/issue-triage.md b/contributors/guide/issue-triage.md
index 04f30950..cbd18677 100644
--- a/contributors/guide/issue-triage.md
+++ b/contributors/guide/issue-triage.md
@@ -71,8 +71,8 @@ If you see support questions on kubernetes-dev@googlegroups.com or issues asking
 support try to redirect them to Stack Overflow. Example response:
 
 ```code
-Please re-post your question to [Stack Overflow]
-(http://stackoverflow.com/questions/tagged/kubernetes).
+Please re-post your question to [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+or our [Discussion Forums](https://discuss.kubernetes.io).
 
 We are trying to consolidate the channels to which questions for help/support
 are posted so that we can improve our efficiency in responding to your requests,
@@ -84,8 +84,8 @@ thread only in one place or, worse, spread across multiple forums. Also, the
 large volume of support issues on GitHub is making it difficult for us to use
 issues to identify real bugs.
 
-Members of the Kubernetes community use Stack Overflow to field support
-requests. Before posting a new question, please search Stack Overflow for answers
+Members of the Kubernetes community use Stack Overflow and Discussion Forums to field
+support requests. Before posting a new question, please search these for answers
 to similar questions, and also familiarize yourself with:
 
   * [user documentation](https://kubernetes.io/docs/home/)
diff --git a/contributors/guide/non-code-contributions.md b/contributors/guide/non-code-contributions.md
index a110090a..43fd10e2 100644
--- a/contributors/guide/non-code-contributions.md
+++ b/contributors/guide/non-code-contributions.md
@@ -14,7 +14,7 @@ slug: "non-code"
 
 The list below is meant to help non-code contributors find areas of the Kubernetes project where their expertise can be best utilized. The goal of this is to both provide a starting guide for anyone looking to become a contributor not necessarily writing code, and also to fill any needs that the SIGs have that might not currently be filled by code-focused contributors.
 
-This list is meant to be used by both new contributors looking for a good entrance into the project, and current contributors who would live to do something different.
+This list is meant to be used by both new contributors looking for a good entrance into the project, and current contributors who would like to do something different.
 
 Are you interested in any of the roles below? Come chat with us [on Slack](https://kubernetes.slack.com/messages/sig-contribex)!
 
diff --git a/contributors/guide/pull-requests.md b/contributors/guide/pull-requests.md
index 1b5f6fc7..d2e252c8 100644
--- a/contributors/guide/pull-requests.md
+++ b/contributors/guide/pull-requests.md
@@ -1,10 +1,10 @@
 ---
 title: "Pull Request Process"
 weight: 1
-slug: "pull-requests" 
+slug: "pull-requests"
 ---
 
-This doc explains the process and best practices for submitting a pull request to the [Kubernetes project](https://github.com/kubernetes/kubernetes) and its associated subrepositories. It should serve as a reference for all contributors, and be useful especially to new and infrequent submitters.
+This doc explains the process and best practices for submitting a pull request to the [Kubernetes project](https://github.com/kubernetes/kubernetes) and its associated sub-repositories. It should serve as a reference for all contributors, and be useful especially to new and infrequent submitters.
 
 - [Before You Submit a Pull Request](#before-you-submit-a-pull-request)
   * [Run Local Verifications](#run-local-verifications)
@@ -33,7 +33,7 @@ This doc explains the process and best practices for submitting a pull request t
 
 This guide is for contributors who already have a pull request to submit. If you're looking for information on setting up your developer environment and creating code to contribute to Kubernetes, see the [development guide](/contributors/devel/development.md).
 
-First time contributors should head to the [Contributor Guide](/contributors/guide/README.md) to get started.
+First-time contributors should head to the [Contributor Guide](/contributors/guide/README.md) to get started.
 
 **Make sure your pull request adheres to our best practices. These include following project conventions, making small pull requests, and commenting thoroughly. Please read the more detailed section on [Best Practices for Faster Reviews](#best-practices-for-faster-reviews) at the end of this doc.**
 
@@ -54,7 +54,7 @@ Merging a pull request requires the following steps to be completed before the p
 - [Open a pull request](https://help.github.com/articles/about-pull-requests/)
   - *For kubernetes/kubernetes repository only:* Add [release notes](/contributors/guide/release-notes.md) if needed.
 - Pass all e2e tests
-- Get all necessary approvals from reviewers and code owners 
+- Get all necessary approvals from reviewers and code owners
 
 ## The Testing and Merge Workflow
 
@@ -82,7 +82,7 @@ Here's the process the pull request goes through on its way from submission to m
 
 1. Reviewer suggests edits
 1. Push edits to your pull request branch
-1. Repeat the prior two steps as needed until reviewer(s) add `/lgtm` label. The `/lgtm` label, when applied by someone listed as an `reviewer` in the corresponding project `OWNERS` file, is a signal that the code has passed review from one or more trusted reviewers for that project
+1. Repeat the prior two steps as needed until the reviewer(s) add `/lgtm` label. The `/lgtm` label, when applied by someone listed as a `reviewer` in the corresponding project `OWNERS` file, is a signal that the code has passed review from one or more trusted reviewers for that project
 1. (Optional) Some reviewers prefer that you squash commits at this step
 1. Follow the bot suggestions to assign an OWNER who will add the `/approve` label to the pull request. The `/approve` label, when applied by someone listed as an `approver` in the corresponding project `OWNERS`, is a signal that the code has passed final review and is ready to be automatically merged
 
@@ -119,7 +119,7 @@ The GitHub robots will add and remove the `do-not-merge/hold` label as you use t
 
 ## Pull Requests and the Release Cycle
 
-If a pull request has been reviewed, but held or not approved, it might be due to the current phase in the [Release Cycle](/contributors/devel/sig-release/release.md). Occasionally, a SIG may freeze their own code base when working towards a specific feature or goal that could impact other development. During this time, your pull request could remain unmerged while their release work is completed.
+If a pull request has been reviewed but held or not approved, it might be due to the current phase in the [Release Cycle](/contributors/devel/sig-release/release.md). Occasionally, a SIG may freeze their own code base when working towards a specific feature or goal that could impact other development. During this time, your pull request could remain unmerged while their release work is completed.
 
 If you feel your pull request is in this state, contact the appropriate [SIG](https://git.k8s.io/community/sig-list.md) or [SIG-Release](https://git.k8s.io/sig-release) for clarification.
 
@@ -167,7 +167,7 @@ things you can do to move the process along:
 
    * Ping the assignee by email (many of us have publicly available email addresses).
 
-   * If you're a member of the organization ping the [team](https://github.com/orgs/kubernetes/teams) (via @team-name) that works in the area you're submitting code.
+   * If you're a member of the organization ping the [team](https://github.com/orgs/kubernetes/teams) (via @team-name) that works in the area you're submitting code to.
 
    * If you have fixed all the issues from a review, and you haven't heard back, you should ping the assignee on the comment stream with a "please take another look" (`PTAL`) or similar comment indicating that you are ready for another review.
 
@@ -193,7 +193,7 @@ Are you sure Feature-X is something the Kubernetes team wants or will accept? Is
 
 It's better to get confirmation beforehand.
 
-When you want to make a large or otherwise significant change, you should follow the [Kubernetes Enhancement Proposal process](/keps/0001-kubernetes-enhancement-proposal-process.md).
+When you want to make a large or otherwise significant change, you should follow the [Kubernetes Enhancement Proposal process](https://git.k8s.io/enhancements/keps/0001-kubernetes-enhancement-proposal-process.md).
 
 Even for small changes, it is often a good idea to gather feedback on an issue you filed, or even simply ask in the appropriate SIG's Slack channel to invite discussion and feedback from code owners. Here's a [list of SIGs](/sig-list.md).
 
@@ -253,7 +253,7 @@ Read up on [GoDoc](https://blog.golang.org/godoc-documenting-go-code) - follow t
 
 ## 5. Test
 
-Nothing is more frustrating than starting a review, only to find that the tests are inadequate or absent. Very few pull requests can touch code and NOT touch tests.
+Nothing is more frustrating than starting a review, only to find that the tests are inadequate or absent. Very few pull requests can touch the code and NOT touch tests.
 
 If you don't know how to test Feature-X, please ask!  We'll be happy to help you design things for easy testing or to suggest appropriate test cases.
 
@@ -302,10 +302,9 @@ Each incoming Pull Request needs to be reviewed, checked, and then merged.
 
 While automation helps with this, each contribution also has an engineering cost. Therefore it is appreciated if you do NOT make trivial edits and fixes, but instead focus on giving the entire file a review.
 
-If you find one grammatical or spelling error, it is likely there are more in that file, you can really make your Pull Request count by checking formatting, checking for broken links, and fixing errors and then submitting all the fixes at once to that file.
+If you find one grammatical or spelling error, it is likely there are more in that file, you can really make your Pull Request count by checking the formatting, checking for broken links, and fixing errors and then submitting all the fixes at once to that file.
 
 **Some questions to consider:**
 
 * Can the file be improved further?
 * Does the trivial edit greatly improve the quality of the content?
-
diff --git a/contributors/guide/style-guide.md b/contributors/guide/style-guide.md
index babb8eb3..38acb36c 100644
--- a/contributors/guide/style-guide.md
+++ b/contributors/guide/style-guide.md
@@ -21,7 +21,7 @@ These are **guidelines**, not rules. Use your best judgement.
   - [Punctuation](#punctuation)
   - [Quotation](#quotation)
 - [Markdown formatting](#markdown-and-formatting)
-  - [Code Blocks](code-blocks)
+  - [Code Blocks](#code-blocks)
   - [Emphasis](#emphasis)
   - [Headings](#headings)
   - [Horizontal Lines](#horizontal-lines)
@@ -176,7 +176,7 @@ These are **guidelines**, not rules. Use your best judgement.
 - When inserting a code block into an ordered list, indent (space) an additional
   two times.
 
-**[Metadata:](metadata)**
+**[Metadata:](#metadata)**
 - If the document is intended to be surfaced on the Contributor Site; include a
   yaml metadata header at the beginning of the document.
 - Metadata must include the `title` attribute.