fix typos and wording review

content/de/docs/contribute/participate/_index.md

@@ -18,19 +18,18 @@ zu laufenden Pull Requests abzugeben.
 Du kannst dich ausserdem als [Member](/de/docs/contribute/participate/roles-and-responsibilities/#member),
 [Reviewer](/de/docs/contribute/participate/roles-and-responsibilities/#reviewer), oder
 [Approver](/de/docs/contribute/participate/roles-and-responsibilities/#approver) beteiligen.
-Diese Rollen erfordern einen erweiterten Zugriff und bringen bestimmte Verantwortlichkeiten für
-Änderungen zu genehmigen und zu bestätigen.
+Diese Rollen erfordern einen erweiterten Zugriff und bringen bestimmte Verantwortlichkeiten zur Genehmigung und Bestätigung von Änderungen mit sich.
 Unter [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) findest du weitere Informationen darüber, wie die Mitgliedschaft in der Kubernetes-Community funktioniert.
 
-Der Rest dieses Dokuments umrei&szlig,t einige spezielle Vorgehensweisen dieser Rollen innerhalb von SIG Docs, die für die Pflege eines der öffentlichsten Aushängeschilder von Kubernetes verantwortlich ist - die Kubernetes-Website und die Dokumentation.
+Der Rest dieses Dokuments umreißt einige spezielle Vorgehensweisen dieser Rollen innerhalb von SIG Docs, die für die Pflege eines der öffentlichsten Aushängeschilder von Kubernetes verantwortlich ist - die Kubernetes-Website und die Dokumentation.
 
 <!-- body -->
 ## SIG Docs Vorstand
 
 Jede SIG, auch die SIG Docs, wählt ein oder mehrere SIG-Mitglieder, die als
 Vorstand fungieren. Sie sind die Kontaktstellen zwischen der SIG Docs und anderen Teilen der
 der Kubernetes-Organisation. Sie benötigen umfassende Kenntnisse über die Struktur
-des Kubernetes-Projekts als Ganzes und wie SIG Docs darin arbeitet. Informationen zur [Leitung](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) und den aktuellen Vorsitzenden.
+des Kubernetes-Projekts als Ganzes und wie SIG Docs darin arbeitet. Hier findest zu alle weiteren Informationen zu den aktuellen Vorsitzenden und der [Leitung](https://github.com/kubernetes/community/tree/master/sig-docs#leadership).
 ## SIG Docs-Teams und Automatisierung
 
 Die Automatisierung in SIG Docs stützt sich auf zwei verschiedene Mechanismen:
@@ -43,11 +42,9 @@ Es gibt zwei Kategorien von SIG Docs [Teams](https://github.com/orgs/kubernetes/
 - `@sig-docs-{language}-owners` sind Genehmiger und Verantwortliche
 - `@sig-docs-{language}-reviewers` sind Reviewer
 
-Jede Gruppe kann in GitHub-Kommentaren mit ihrem `@name` referenziert werden, um mit
-mit allen Mitgliedern dieser Gruppe zu kommunizieren.
+Jede Gruppe kann in GitHub-Kommentaren mit ihrem `@name` referenziert werden, um mit allen Mitgliedern dieser Gruppe zu kommunizieren.
 
-Manchmal überschneiden sich Prow- und GitHub-Teams, ohne genau übereinzustimmen. Für
-Zuordnung von Issues, Pull-Requests und zur Unterstützung von PR-Genehmigungen verwendet die
+Manchmal überschneiden sich Prow- und GitHub-Teams, ohne eine genaue Übereinstimmung. Für die Zuordnung von Issues, Pull-Requests und zur Unterstützung von PR-Genehmigungen verwendet die
 Automatisierung die Informationen aus den `OWNERS`-Dateien.
 
 ### OWNERS Dateien und Front-Matter
@@ -58,33 +55,32 @@ Das [Kubernetes-Website-Repository](https://github.com/kubernetes/website) verwe
 - blunderbuss
 - approve
 
-Diese beiden Plugins verwenden die
+Diese beiden Plugins nutzen die
 [OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) und
 [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES)
 Dateien auf der obersten Ebene des GitHub-Repositorys `kubernetes/website`, um zu steuern
 wie prow innerhalb des Repositorys arbeitet.
 
 Eine OWNERS-Datei enthält eine Liste von Personen, die SIG Docs-Reviewer und
 Genehmiger sind. OWNERS-Dateien können auch in Unterverzeichnissen existieren und bestimmen, wer
-Dateien in diesem Unterverzeichnis und seinen Unterverzeichnissen als Rezensent oder
-Genemiger bestätigen darf. Weitere Informationen über OWNERS-Dateien im Allgemeinen findest du unter
+Dateien in diesem Unterverzeichnis und seinen Unterverzeichnissen als Gutachter oder
+Genehmiger bestätigen darf. Weitere Informationen über OWNERS-Dateien im Allgemeinen findest du unter
 [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md).
 
-Au&szlig,erdem kann eine einzelne Markdown-Datei in ihrem Front-Matter (Vorspann) Reviewer und Genehmiger auflisten.
+Außerdem kann eine einzelne Markdown-Datei in ihrem Front-Matter (Vorspann) Reviewer und Genehmiger auflisten.
 Entweder durch Auflistung einzelner GitHub-Benutzernamen oder GitHub-Gruppen.
 
-Die Kombination aus OWNERS-Dateien und Front-Matter in Markdown-Dateien bestimmt, welche Ratschläge PR-Eigentümer von automatisierten Systemen erhalten, und wen sie um eine technische und redaktionelle Überprüfung ihres PRs bitten sollen.
+Die Kombination aus OWNERS-Dateien und Front-Matter in Markdown-Dateien bestimmt, welche Empfehlungen PR-Eigentümer von automatisierten Systemen erhalten, und wen sie um eine technische und redaktionelle Überprüfung ihres PRs bitten sollen.
 ## So funktioniert das Zusammenführen
 
-Wenn ein Pull Request mit der Branch (Ast) zusammengeführt wird, in dem der Inhalt veröffentlicht werden soll, wird dieser Inhalt auf http://kubernetes.io veröffentlicht. Um sicherzustellen, dass die Qualität der veröffentlichten Inhalte hoch ist, beschränken wir das Zusammenführen von Pull Requests auf
+Wenn ein Pull Request mit der Branch (Ast) zusammengeführt wird, in dem der Inhalt bereitgestellt werden soll, wird dieser Inhalt auf http://kubernetes.io veröffentlicht. Um sicherzustellen, dass die Qualität der veröffentlichten Inhalte hoch ist, beschränken wir das Zusammenführen von Pull Requests auf
 SIG Docs Freigabeberechtigte. So funktioniert es:
 
 - Wenn eine Pull-Anfrage sowohl das `lgtm`- als auch das `approve`-Label hat, kein `hold`-Label hat, 
   und alle Tests bestanden sind, wird der Pull Request automatisch  zusammengeführt.
-- Mitglieder der Kubernetes-Organisation und SIG Docs-Genehmiger können Kommentare hinzufügen, um
-  Kommentare hinzufügen, um das automatische Zusammenführen eines Pull Requests zu verhindern (durch Hinzufügen eines `/hold`-Kommentars
-  kann ein vorheriger `/lgtm`-Kommentar zurückgehalten werden).
 - Jedes Kubernetes-Mitglied kann das `lgtm`-Label hinzufügen, indem es einen `/lgtm`-Kommentar hinzufügt.
+- Mitglieder der Kubernetes-Organisation und SIG Docs-Genehmiger können kommentieren, um das automatische Zusammenführen eines Pull Requests zu verhindern (durch Hinzufügen eines `/hold`-Kommentars
+  kann ein vorheriger `/lgtm`-Kommentar zurückgehalten werden).
 - Nur SIG Docs-Genehmiger können einen Pull Request zusammenführen indem sie einen `/approve` Kommentar hinzufügen. 
   Einige Genehmiger übernehmen auch weitere spezielle Rollen, wie zum Beispiel [PR Wrangler](/docs/contribute/participate/pr-wranglers/) oder [SIG Docs Vorsitzende](#sig-docs-chairperson).
 

content/de/docs/contribute/participate/pr-wranglers.md

@@ -33,7 +33,7 @@ Tägliche Aufgaben in einer einwöchigen Schicht als PR Wrangler:
 
 Die folgenden Anfragen sind beim Wrangling hilfreich.
 Wenn du diese Anfragen abgearbeitet hast, ist die verbleibende Liste der zu prüfenden PRs meist klein.
-Diese Anfragen schließen Lokalisierungs-PRs aus. Alle Anfragen beziehen sich auf den Hauptast, außer der letzten.
+Diese Anfragen schließen Lokalisierungs-PRs aus. Alle Anfragen beziehen sich auf den `main`-Branch, außer der letzten.
 
 - [Kein CLA, nicht zusammenfürbar](https://github.com/kubernetes/website/pulls?q=is%3Aopen+ist%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3Alanguage%2Fen):
   Erinnere den Beitragenden daran, den CLA zu unterschreiben. Wenn sowohl der Bot als auch ein Mensch sie daran erinnert haben, schließe
@@ -44,12 +44,12 @@ Diese Anfragen schließen Lokalisierungs-PRs aus. Alle Anfragen beziehen sich au
 - [Hat LGTM, braucht die Zustimmung von Docs](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+):
   Listet PRs auf, die einen `/approve`-Kommentar benötigen, um zusammengeführt zu werden.
 - [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amain+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): Listet PRs gegen den Hauptzweig auf, die nicht eindeutig blockiert sind. (ändere "XS" in der Größenbezeichnung, wenn du dich durch die PRs arbeitest [XS, S, M, L, XL, XXL]).
-- [Nicht gegen den Hauptast](https://github.com/kubernetes/website/pulls?q=is%3Aopen+ist%3Apr+label%3Alanguage%2Fen+-base%3Amain): Wenn der PR gegen einen `dev-`Ast gerichtet ist, ist er für eine kommende Veröffentlichung. Weise diesen dem [Docs Release Manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) zu: `/assign @<manager's_github-username>`. Wenn der PR gegen einen alten Ast gerichtet ist, hilf dem Autor herauszufinden, ob er auf den richtigen Ast gerichtet ist.
+- [Nicht gegen den `main`-Branch](https://github.com/kubernetes/website/pulls?q=is%3Aopen+ist%3Apr+label%3Alanguage%2Fen+-base%3Amain): Wenn der PR gegen einen `dev-`Ast gerichtet ist, ist er für eine kommende Veröffentlichung. Weise diesen dem [Docs Release Manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) zu: `/assign @<manager's_github-username>`. Wenn der PR gegen einen alten Ast gerichtet ist, hilf dem Autor herauszufinden, ob er auf den richtigen Ast gerichtet ist.
 
 ### Hilfreiche Prow-Befehle für Wranglers
 
 ```
-# Englisches Label hinzufuegen
+# Englisches Label hinzufügen
 /language en
 
 # füge dem PR ein Squash-Label hinzu, wenn es mehr als einen Commit gibt
@@ -59,7 +59,7 @@ Diese Anfragen schließen Lokalisierungs-PRs aus. Alle Anfragen beziehen sich au
 /retitle [WIP] <TITLE>
 ```
 
-### Wann Pull Requests schließen
+### Wann sind Pull Requests zu schließen
 
 Reviews und Genehmigungen sind ein Mittel, um unsere PR-Warteschlange kurz und aktuell zu halten. Ein weiteres Mittel ist das Schließen.
 

content/de/docs/contribute/participate/roles-and-responsibilities.md

@@ -98,12 +98,12 @@ Du kannst ein Mitglied werden, nachdem du mindestens 5 substantielle Pull Reques
 
 ## Reviewer
 
-Reviewer (Rezensenten) sind dafür verantwortlich, offene Pull Requests zu überprüfen. Anders als bei den Mitgliedern
+Reviewer (Gutachteren) sind dafür verantwortlich, offene Pull Requests zu überprüfen. Anders als bei den Mitgliedern
 musst du auf das Feedback der Prüfer eingehen. Reviewer sind Mitglieder des
 [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs)
 GitHub-Teams.
 
-Rezensenten können:
+Gutachteren können:
 
 - Alles tun, was unter [Jeder](#jeder) und [Member](#member) aufgeführt ist
 - Pull Requests überprüfen und verbindliches Feedback geben