Zur Kubernetes-Dokumentation beitragen

Wenn Sie an der Dokumentation oder der Website von Kubernetes mitwirken möchten, freuen wir uns über Ihre Hilfe! Jeder kann seinen Beitrag leisten, unabhängig davon ob Sie neu im Projekt sind oder schon lange dabei sind, und ob Sie sich als Entwickler, Endbenutzer oder einfach jemanden, der es einfach nicht aushält, Tippfehler zu sehen sehen ;)

Weitere Möglichkeiten, sich in der Kubernetes-Community zu engagieren oder mehr über uns zu erfahren, finden Sie auf der Kubernetes-Community-Seite. Informationen zum Handbuch zur Dokumentation von Kubernetes finden Sie im Gestaltungshandbuch.

Arten von Mitwirkenden

Möglichkeiten, einen Beitrag zu leisten

Diese Liste ist in Funktionen unterteilt, die jeder tun kann, die von Mitgliedern der Kubernetes-Organisation durchgeführt werden können, und Dinge, die ein höheres Maß an Zugriff und eine bessere Kenntnis der SIG Docs-Prozesse erfordern. Wenn Sie im Laufe der Zeit einen konstanten Beitrag leisten, können Sie einige der bereits getroffenen Tools und organisatorischen Entscheidungen nachvollziehen.

Dies ist keine vollständige Liste von Möglichkeiten, wie Sie zur Kubernetes-Dokumentation beitragen können, aber sie sollte Ihnen den Einstieg erleichtern.

1 - Lokalisierung der Kubernetes Dokumentation

Diese Seite zeigt dir wie die Dokumentation für verschiedene Sprachen lokalisiert wird.

Erste Schritte

Da Mitwirkende nicht ihren eigenen Pull Request freigeben können, brauchst du mindestens zwei Mitwirkende um mit der Lokalisierung anfangen zu können.

Alle Lokalisierungsteams müssen sich mit ihren eigenen Ressourcen selbst tragen. Die Kubernetes-Website ist gerne bereit, deine Arbeit zu beherbergen, aber es liegt an dir, sie zu übersetzen.

Ermittlung deines Zwei-Buchstaben-Sprachcodes

Rufe den ISO 639-1 Standard auf und finde deinen Zwei-Buchstaben-Ländercode zur Lokalisierung. Zum Beispiel ist der Zwei-Buchstaben-Code für Korea ko.

Duplizieren und Klonen des Repositories

Als erstes erstellst du dir deine eigenes Duplikat vom [kubernetes/website] Repository.

Dann klonst du das Duplikat und wechselst in das neu erstellte Verzeichnis:

git clone https://github.com/<username>/website
cd website

Eröffnen eines Pull Requests

Als nächstes eröffnest du einen Pull Request (PR) um eine Lokalisierung zum kubernetes/website Repository hinzuzufügen.

Der PR muss die minimalen Inhaltsanforderungen erfüllen, bevor dieser genehmigt werden kann.

Wie der PR für eine neue Lokalisierung aussieht, kannst du dir an dem PR für die Französische Dokumentation ansehen.

Tritt der Kubernetes GitHub Organisation bei

Sobald du eine Lokalisierungs-PR eröffnet hast, kannst du Mitglied der Kubernetes GitHub Organisation werden. Jede Person im Team muss einen eigenen Antrag auf Mitgliedschaft in der Organisation im kubernetes/org-Repository erstellen.

Lokalisierungs-Team in GitHub hinzufügen

Im nächsten Schritt musst du dein Kubernetes Lokalisierungs-Team in die sig-docs/teams.yaml eintragen.

Der PR des Spanischen Lokalisierungs-Teams kann dir hierbei eine Hilfestellung sein.

Mitglieder der @kubernetes/sig-docs-**-owners können nur PRs freigeben die innerhalb deines Lokalisierungs-Ordners Änderungen vorgenommen haben: /content/**/.

Für jede Lokalisierung automatisiert das Team @kubernetes/sig-docs-**-reviews die Review-Zuweisung für neue PRs.

Mitglieder von @kubernetes/website-maintainers können neue Entwicklungszweige schaffen, um die Übersetzungsarbeiten zu koordinieren.

Mitglieder von @kubernetes/website-milestone-maintainers können den Befehl /milestone Prow Kommando verwenden, um Themen oder PRs einen Meilenstein zuzuweisen.

Workflow konfigurieren

Als nächstes fügst du ein GitHub-Label für deine Lokalisierung im kubernetes/test-infra-Repository hinzu. Mit einem Label kannst du Aufgaben filtern und Anfragen für deine spezifische Sprache abrufen.

Schau dir den PR zum Hinzufügen der Labels für die [Italienischen Sprachen-Labels](https://github.com/kubernetes/test-infra/pull/11316 an.

Finde eine Gemeinschaft

Lasse die Kubernetes SIG Docs wissen, dass du an der Erstellung einer Lokalisierung interessiert bist! Trete dem SIG Docs Slack-Kanal bei. Andere Lokalisierungsteams helfen dir gerne beim Einstieg und beantworten deine Fragen.

Du kannst auch einen Slack-Kanal für deine Lokalisierung im kubernetes/community-Repository erstellen. Ein Beispiel für das Hinzufügen eines Slack-Kanals findest du im PR für Kanäle für Indonesisch und Portugiesisch hinzufügen.

Mindestanforderungen

Ändere die Website-Konfiguration

Die Kubernetes-Website verwendet Hugo als Web-Framework. Die Hugo-Konfiguration der Website befindet sich in der Datei hugo.toml. Um eine neue Lokalisierung zu unterstützen, musst du die Datei hugo.toml modifizieren.

Dazu fügst du einen neuen Block für die neue Sprache unter den bereits existierenden [languages] Block in das hugo.toml ein, wie folgendes Beispiel zeigt:

[languages.de]
title = "Kubernetes"
description = "Produktionsreife Container-Verwaltung"
languageName = "Deutsch"
contentDir = "content/de"
weight = 3

Wenn du deinem Block einen Parameter weight zuweist, suche den Sprachblock mit dem höchsten Gewicht und addiere 1 zu diesem Wert.

Weitere Informationen zu Hugos multilingualem Support findest du unter "Multilingual Mode" auf in der Hugo Dokumentation.

Neuen Lokalisierungsordner erstellen

Füge eine sprachspezifisches Unterverzeichnis zum Ordner content im Repository hinzu. Der Zwei-Buchstaben-Code für Deutsch ist zum Beispiel de:

mkdir content/de

Lokalisiere den Verhaltenscodex

Öffne einen PR gegen das cncf/foundation Repository, um den Verhaltenskodex in deiner Sprache hinzuzufügen.

Lokalisierungs README Datei hinzufügen

Um andere Lokalisierungsmitwirkende anzuleiten, füge eine neue README-**.md auf der obersten Ebene von kubernetes/website hinzu, wobei ** der aus zwei Buchstaben bestehende Sprachcode ist. Eine deutsche README-Datei wäre zum Beispiel README-de.md.

Gebe den Lokalisierungsmitwirkende in der lokalisierten README-**.md-Datei Anleitung zum Mitwirken. Füge dieselben Informationen ein, die auch in README.md enthalten sind, sowie:

Nachdem du das lokalisierte README erstellt hast, füge der Datei einen Link aus der englischen Hauptdatei README.md hinzu und gebe die Kontaktinformationen auf Englisch an. Du kannst eine GitHub-ID, eine E-Mail-Adresse, Slack-Kanal oder eine andere Kontaktmethode angeben. Du musst auch einen Link zu deinem lokalisierten Verhaltenskodex der Gemeinschaft angeben.

Richte eine OWNERS Datei ein

Um die Rollen der einzelnen an der Lokalisierung beteiligten Benutzer festzulegen, erstelle eine OWNERS-Datei innerhalb des sprachspezifischen Unterverzeichnisses mit:

Weitere Informationen über die Datei OWNERS findest du unter go.k8s.io/owners.

Die Datei Spanish OWNERS file, mit dem Sprachcode es, sieht wie folgt aus:

# See the OWNERS docs at https://go.k8s.io/owners

# This is the localization project for Spanish.
# Teams and members are visible at https://github.com/orgs/kubernetes/teams.

reviewers:
- sig-docs-es-reviews

approvers:
- sig-docs-es-owners

labels:
- language/es

Nachdem du die sprachspezifische Datei OWNERS hinzugefügt hast, aktualisiere die root Datei OWNERS_ALIASES mit den neuen Kubernetes-Teams für die Lokalisierung, sig-docs-**-owners und sig-docs-**-reviews.

Füge für jedes Team die Liste der unter Ihr Lokalisierungsteam in GitHub hinzufügen angeforderten GitHub-Benutzer in alphabetischer Reihenfolge hinzu.

--- a/OWNERS_ALIASES
+++ b/OWNERS_ALIASES
@@ -48,6 +48,14 @@ aliases:
     - stewart-yu
     - xiangpengzhao
     - zhangxiaoyu-zidif
+  sig-docs-es-owners: # Admins for Spanish content
+    - alexbrand
+    - raelga
+  sig-docs-es-reviews: # PR reviews for Spanish content
+    - alexbrand
+    - electrocucaracha
+    - glo-pena
+    - raelga
   sig-docs-fr-owners: # Admins for French content
     - perriea
     - remyleone

Inhalte übersetzen

Die Lokalisierung aller Dokumentationen des Kubernetes ist eine enorme Aufgabe. Es ist in Ordnung, klein anzufangen und mit der Zeit zu erweitern.

Alle Lokalisierungen müssen folgende Inhalte enthalten:

Beschreibung URLs
Startseite Alle Überschriften und Untertitel URLs
Einrichtung Alle Überschriften und Untertitel URLs
Tutorials Kubernetes Grundlagen, Hello Minikube
Site strings Alle Website-Zeichenfolgen in einer neuen lokalisierten TOML-Datei

Übersetzte Dokumente müssen sich in ihrem eigenen Unterverzeichnis content/**/ befinden, aber ansonsten dem gleichen URL-Pfad wie die englische Quelle folgen. Um z.B. das Tutorial Kubernetes Grundlagen für die Übersetzung ins Deutsche vorzubereiten, erstelle einen Unterordner unter dem Ordner content/de/ und kopiere die englische Quelle:

mkdir -p content/de/docs/tutorials
cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md

Übersetzungswerkzeuge können den Übersetzungsprozess beschleunigen. Einige Redakteure bieten beispielsweise Plugins zur schnellen Übersetzung von Text an.

Achtung:

Maschinelle Übersetzung allein reicht nicht aus. Die Lokalisierung erfordert eine umfassende menschliche Überprüfung, um Mindestqualitätsstandards zu erfüllen.

Um die Genauigkeit in Grammatik und Bedeutung zu gewährleisten, sollten die Mitglieder deines Lokalisierungsteams alle maschinell erstellten Übersetzungen vor der Veröffentlichung sorgfältig überprüfen.

Quelldaten

Lokalisierungen müssen auf den englischen Dateien der neuesten Version basieren, v1.35.

Um die Quelldatei für das neueste Release führe folgende Schritte durch:

  1. Navigiere zum Repository der Website Kubernetes unter https://github.com/kubernetes/website.
  2. Wähle den release-1.X-Zweig für die aktuellste Version.

Die neueste Version ist v1.35, so dass der neueste Versionszweig release-1.35 ist.

Seitenverlinkung in der Internationalisierung

Lokalisierungen müssen den Inhalt von i18n/de.toml in einer neuen sprachspezifischen Datei enthalten. Als Beispiel: i18n/de.toml.

Füge eine neue Lokalisierungsdatei zu i18n/ hinzu. Zum Beispiel mit Deutsch (de):

cp i18n/en.toml i18n/de.toml

Übersetze dann den Wert jeder Zeichenfolge:

[docs_label_i_am]
other = "ICH BIN..."

Durch die Lokalisierung von Website-Zeichenfolgen kannst du Website-weiten Text und Funktionen anpassen: z. B. den gesetzlichen Copyright-Text in der Fußzeile auf jeder Seite.

Sprachspezifischer Styleguide

Einige Sprachteams haben ihren eigenen sprachspezifischen Styleguide und ihr eigenes Glossar. Siehe zum Beispiel den Leitfaden zur koreanischen Lokalisierung.

Informale Schreibweise

Für die deutsche Übersetzungen verwenden wir eine informelle Schreibweise und der Ansprache per Du. Allerdings werden keine Jargon, Slang, Wortspiele, Redewendungen oder kulturspezifische Bezüge eingebracht.

Datums und Maßeinheiten

Wenn notwendig sollten Datumsangaben in das in Deutschland übliche dd.mm.yyyy überführt werden. Alternativ können diese auch in den Textfluss eingebunden werden: "... am 24. April ....".

Abkürzungen

Abkürzungen sollten nach Möglichkeit nicht verwendet werden und entweder ausgeschrieben oder anderweitig umgangen werden.

Zusammengesetzte Wörter

Durch die Übersetzung werden oft Nomen aneinandergereiht, diese Wortketten müssen durch Bindestriche verbunden werden. Dies ist auch möglich wenn ein Teil ins Deutsche übersetzt wird ein weiterer jedoch im Englischen bestehen bleibt. Als Richtlinie gilt hier der Duden.

Anglizismen

Die Verwendung von Anglizismen ist dann wünschenswert, wenn die Verwendung eines deutschen Wortes, vor allem für technische Begriffe, nicht eindeutig ist oder zu Unklarheiten führt.

Branching Strategie

Da Lokalisierungsprojekte in hohem Maße gemeinschaftliche Bemühungen sind, ermutigen wir Teams, in gemeinsamen Entwicklungszweigen zu arbeiten.

In einem Entwicklungszweig zusammenzuarbeiten:

  1. Ein Teammitglied von @kubernetes/website-maintainers eröffnet einen Entwicklungszweig aus einem Quellzweig auf https://github.com/kubernetes/website.

    Deine Genehmiger sind dem @kubernetes/website-maintainers-Team beigetreten, als du dein Lokalisierungsteam zum Repository kubernetes/org hinzugefügt hast.

    Wir empfehlen das folgende Zweigbenennungsschema:

    dev-<Quellversion>-<Sprachcode>.<Team-Meilenstein>

    Beispielsweise öffnet ein Genehmigender in einem deutschen Lokalisierungsteam den Entwicklungszweig dev-1.12-de.1 direkt gegen das kubernetes/website-Repository, basierend auf dem Quellzweig für Kubernetes v1.12.

  2. Einzelne Mitwirkende öffnen Feature-Zweige, die auf dem Entwicklungszweig basieren.

    Zum Beispiel öffnet ein deutscher Mitwirkende eine Pull-Anfrage mit Änderungen an kubernetes:dev-1.12-de.1 von Benutzername:lokaler-Zweig-Name.

  3. Genehmiger Überprüfen und führen die Feature-Zweigen in den Entwicklungszweig zusammen.

  4. In regelmäßigen Abständen führt ein Genehmiger den Entwicklungszweig mit seinem Ursprungszweig zusammen, indem er eine neue Pull-Anfrage eröffnet und genehmigt. Achtet darauf, die Commits zusammenzuführen (squash), bevor die Pull-Anfrage genehmigt wird.

Wiederhole die Schritte 1-4 nach Bedarf, bis die Lokalisierung abgeschlossen ist. Zum Beispiel würden nachfolgende deutsche Entwicklungszweige sein: dev-1.12-de.2, dev-1.12-de.3, usw.

Die Teams müssen den lokalisierten Inhalt in demselben Versionszweig zusammenführen, aus dem der Inhalt stammt. Beispielsweise muss ein Entwicklungszweig, der von release-1.35 ausgeht, auf {{release-1.35} basieren.

Ein Genehmiger muss einen Entwicklungszweig aufrechterhalten, indem er seinen Quellzweig auf dem aktuellen Stand hält und Merge-Konflikte auflöst. Je länger ein Entwicklungszweig geöffnet bleibt, desto mehr Wartung erfordert er in der Regel. Ziehe in Betracht, regelmäßig Entwicklungszweige zusammenzuführen und neue zu eröffnen, anstatt einen extrem lang laufenden Entwicklungszweig zu unterhalten.

Zu Beginn jedes Team-Meilensteins ist es hilfreich, ein Problem Vergleich der Upstream-Änderungen zwischen dem vorherigen Entwicklungszweig und dem aktuellen Entwicklungszweig zu öffnen.

Während nur Genehmiger einen neuen Entwicklungszweig eröffnen und Pull-Anfragen zusammenführen können, kann jeder eine Pull-Anfrage für einen neuen Entwicklungszweig eröffnen. Es sind keine besonderen Genehmigungen erforderlich.

Weitere Informationen über das Arbeiten von Forks oder direkt vom Repository aus findest du unter "fork and clone the repo".

Am Upstream Mitwirken

SIG Docs begrüßt Upstream Beiträge, also auf das englische Original, und Korrekturen an der englischen Quelle.

Unterstütze bereits bestehende Lokalisierungen

Du kannst auch dazu beitragen, Inhalte zu einer bestehenden Lokalisierung hinzuzufügen oder zu verbessern. Trete dem Slack-Kanal für die Lokalisierung bei und beginne mit der Eröffnung von PRs, um zu helfen. Bitte beschränke deine Pull-Anfragen auf eine einzige Lokalisierung, da Pull-Anfragen, die Inhalte in mehreren Lokalisierungen ändern, schwer zu überprüfen sein könnten.

Nächste Schritte

Sobald eine Lokalisierung die Anforderungen an den Arbeitsablauf und die Mindestausgabe erfüllt, wird SIG docs:

2 - Bei SIG Docs mitmachen

Die SIG Docs ist eine der Special Interest Groups (Fachspezifischen Interessengruppen) innerhalb des Kubernetes-Projekts, die sich auf das Schreiben, Aktualisieren und Pflegen der Dokumentation für Kubernetes als Ganzes konzentriert. Weitere Informationen über die SIG findest du unter SIG Docs im GitHub Repository der Community.

SIG Docs begrüßt Inhalte und Bewertungen von allen Mitwirkenden. Jeder kann einen Pull Request (PR) eröffnen, und jeder ist willkommen, Fragen zum Inhalt zu stellen oder Kommentare zu laufenden Pull Requests abzugeben.

Du kannst dich ausserdem als Member, Reviewer, oder Approver beteiligen. Diese Rollen erfordern einen erweiterten Zugriff und bringen bestimmte Verantwortlichkeiten zur Genehmigung und Bestätigung von Änderungen mit sich. Unter community-membership findest du weitere Informationen darüber, wie die Mitgliedschaft in der Kubernetes-Community funktioniert.

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.

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. Hier findest alle weiteren Informationen zu den aktuellen Vorsitzenden und der Leitung.

SIG Docs-Teams und Automatisierung

Die Automatisierung in SIG Docs stützt sich auf zwei verschiedene Mechanismen: GitHub-Teams und OWNERS-Dateien.

GitHub Teams

Es gibt zwei Kategorien von SIG Docs Teams auf GitHub:

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 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

Das Kubernetes-Projekt verwendet ein Automatisierungstool namens prow für die Automatisierung im Zusammenhang mit GitHub-Issues und Pull-Requests. Das Kubernetes-Website-Repository verwendet zwei prow-Plugins:

Diese beiden Plugins nutzen die OWNERS und 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 Gutachter oder Genehmiger bestätigen darf. Weitere Informationen über OWNERS-Dateien im Allgemeinen findest du unter OWNERS.

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 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 bereitgestellt werden soll, wird dieser Inhalt auf https://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:

Nächste Schritte

Weitere Informationen über die Mitarbeit an der Kubernetes-Dokumentation findest du unter:

2.1 - Rollen und Verantwortlichkeiten

Jeder kann zu Kubernetes beitragen. Wenn deine Beiträge zu SIG Docs wachsen, kannst du dich für verschiedene Stufen der Mitgliedschaft in der Community bewerben. Diese Rollen ermöglichen es dir, mehr Verantwortung innerhalb der Gemeinschaft zu übernehmen. Jede Rolle erfordert mehr Zeit und Engagement. Die Rollen sind:

Jeder

Jeder mit einem GitHub-Konto kann zu Kubernetes beitragen. SIG Docs heißt alle neuen Mitwirkenden willkommen!

Jeder kann:

Nach dem Signieren des CLA kann jeder auch:

Weitere Informationen findest du unter neue Inhalte beisteuern.

Member

Ein Member (Mitglied) ist jemand, der bereits mehrere Pull Requests an kubernetes/website eingereicht hat. Mitglieder sind ein Teil der Kubernetes GitHub Organisation.

Member können:

Mitglied werden

Du kannst ein Mitglied werden, nachdem du mindestens 5 substantielle Pull Requests eingereicht hast und die anderen Anforderungen erforderst:

  1. Finde zwei Reviewer oder Approver, die deine Mitgliedschaft sponsern.

    Bitte um Sponsoring im #sig-docs channel on Slack oder auf der SIG Docs Mailingliste.

    Hinweis:

    Schicke keine direkte E-Mail oder Slack-Direktnachricht an ein einzelnes SIG Docs-Mitglied. Du musst das Sponsoring beantragen, bevor du deine Bewerbung einreichst.

  2. Eröffne ein GitHub-Issue im kubernetes/org Repository. Verwende dabei das Organization Membership Request issue template.

  3. Informiere deine Sponsoren über das GitHub-Issue. Du kannst entweder:

  4. Nimm die Einladung zur Kubernetes GitHub Organisation in deinem E-Mail-Konto an.

    Hinweis:

    GitHub sendet die Einladung an die Standard-E-Mail-Adresse in deinem Konto.

Reviewer

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 GitHub-Teams.

Gutachteren können:

Zuweisung von Reviewern zu Pull Requests

Die Automatisierung weist allen Pull Requests Reviewer zu. Du kannst eine Review von einer bestimmten Person anfordern, indem du einen Kommentar schreibst: /assign [@_github_handle].

Wenn der zugewiesene Prüfer den PR nicht kommentiert hat, kann ein anderer Prüfer einspringen. Du kannst bei Bedarf auch technische Prüfer zuweisen.

Verwendung von /lgtm

LGTM steht für "Looks good to me" und zeigt an, dass ein Pull Request technisch korrekt und bereit zum Zusammenführen ist. Alle PRs brauchen einen /lgtm Kommentar von einem Reviewer und einen /approve Kommentar von einem Approver, um zusammengeführt zu werden.

Ein /lgtm-Kommentar vom Reviewer ist verbindlich und löst eine Automatisierung aus, die das lgtm-Label hinzufügt.

Reviewer werden

Wenn du die Anforderungen erfüllst, kannst du ein SIG Docs-Reviewer werden. Reviewer in anderen SIGs müssen sich gesondert für den Reviewer-Status in SIG Docs bewerben.

So bewirbst du dich:

  1. Eröffne einen Pull Request, in dem du deinen GitHub-Benutzernamen in einen Abschnitt der OWNERS_ALIASES Datei im kubernetes/website Repository hinzufügt.

    Hinweis:

    Wenn du dir nicht sicher bist, wo du dich hinzufügen sollst, füge dich zu sig-docs-de-reviews hinzu.

  2. Weise den PR einem oder mehreren SIG-Docs-Genehmigern zu (Benutzernamen, die unter sig-docs-{language}-owners aufgelisted sind). Wenn der PR genehmigt wurde, fügt dich ein SIG Docs-Lead dem entsprechenden GitHub-Team hinzu. Sobald du hinzugefügt bist, wird @k8s-ci-robot dich als Reviewer für neue Pull Requests vorschlagen und zuweisen.

Approver

Approver (Genehmiger) prüfen und genehmigen Pull Requests zum Zusammenführen. Genehmigende sind Mitglieder des @kubernetes/sig-docs-{language}-owners GitHub-Teams.

Genehmigende können Folgendes tun:

Wenn der PR bereits einen /lgtm hat, oder wenn der Genehmigende ebenfalls mit /lgtm kommentiert, wird der PR automatisch zusammengeführt. Ein SIG Docs-Genehmiger sollte nur ein /lgtm für eine Änderung hinterlassen, die keine weitere technische Überprüfung erfordert.

Pull Requests genehmigen

Genehmiger und SIG Docs-Leads sind die Einzigen, die Pull Requests in das Website-Repository aufnehmen. Damit sind bestimmte Verantwortlichkeiten verbunden.

Approver werden

Wenn du die Anforderungen erfüllst, kannst du ein SIG Docs Approver werden. Genehmigende in anderen SIGs müssen sich separat für den Approver-Status in SIG Docs bewerben.

So bewirbst du dich:

  1. Eröffne eine Pull-Anfrage, in der du dich in einem Abschnitt der OWNERS_ALIASES Datei im kubernetes/website Repository hinzuzufügen.

    Hinweis:

    Wenn du dir nicht sicher bist, wo du dich hinzufügen sollst, füge dich zu `sig-docs-de-owners` hinzu.

  2. Weise den PR einem oder mehreren aktuellen SIG Docs Genehmigern zu.

Wenn der PR genehmigt wurde, fügt dich ein SIG Docs-Lead dem entsprechenden GitHub-Team hinzu. Sobald du hinzugefügt bist, wird @k8s-ci-robot dich als Reviewer für neue Pull Requests vorschlagen und zuweisen.

Nächste Schritte

2.2 - PR Wranglers

SIG Docs approvers übernehmen einwöchige Schichten um die Pull Requests des Repositories zu verwalten.

Dieser Abschnitt behandelt die Aufgaben eines PR-Wranglers. Weitere Informationen über gute Reviews findest du unter Überprüfen von Änderungen.

Aufgaben

Tägliche Aufgaben in einer einwöchigen Schicht als PR Wrangler:

Hilfreiche GitHub-Anfragen für Wranglers

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 main-Branch, außer der letzten.

Hilfreiche Prow-Befehle für Wranglers

# Englisches Label hinzufügen
/language en

# füge dem PR ein Squash-Label hinzu, wenn es mehr als einen Commit gibt
/label tide/merge-method-squash

# einen PR ueber Prow neu betiteln (z.B. als Work-in-Progress [WIP])
/retitle [WIP] <TITLE>

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.

PRs werden geschlossen, wenn:

Hab keine Angst, Pull Requests zu schließen. Mitwirkende können sie leicht wieder öffnen und die laufenden Arbeiten fortsetzen. Oft ist es die Nachricht über die Schließung, die einen Autor dazu anspornt, seinen Beitrag wieder aufzunehmen und zu beenden.

Um eine Pull-Anfrage zu schließen, hinterlasse einen /close-Kommentar zu dem PR.

Hinweis:

Der k8s-ci-robot Bot markiert Themen nach 90 Tagen Inaktivität als veraltet. Nach weiteren 30 Tagen markiert er Issues als faul und schließt sie. PR-Beauftragte sollten Themen nach 14-30 Tagen Inaktivität schließen.