Współpraca z SIG Docs

SIG Docs jest jedną z special interest group w ramach projektu Kubernetes, skoncentrowaną na pisaniu, aktualizowaniu i utrzymywaniu dokumentacji dla całego Kubernetesa. Zobacz SIG Docs z repozytorium społeczności na GitHubie aby uzyskać więcej informacji o SIG.

SIG Docs zaprasza do współpracy nad treścią i recenzjami wszystkich współtwórców. Każdy może otworzyć pull request (PR) i każdy jest mile widziany do zgłaszania problemów dotyczących treści lub komentowania pull requestów w trakcie ich realizacji.

Możesz również zostać członkiem, recenzentem lub zatwierdzającym. Te role wymagają większego dostępu i wiążą się z pewnymi obowiązkami w zakresie zatwierdzania i wprowadzania zmian. Zobacz community-membership, aby uzyskać więcej informacji na temat tego, jak działa członkostwo w społeczności Kubernetesa.

Reszta tego dokumentu przedstawia unikalne sposoby, w jakie te role funkcjonują w ramach SIG Docs, które odpowiada za utrzymanie jednego z najbardziej widocznych publicznie aspektów Kubernetesa -- strony internetowej i dokumentacji Kubernetes.

SIG Docs przewodniczący

Każda SIG, w tym SIG Docs, wybiera jednego lub więcej członków SIG do pełnienia roli przewodniczących. Są oni punktami kontaktowymi pomiędzy SIG Docs a innymi częściami organizacji Kubernetesa. Wymagają szerokiej wiedzy na temat struktury projektu Kubernetes jako całości oraz tego, jak SIG Docs działa w jej ramach. Zobacz Kierownictwo z aktualną listą przewodniczących.

Zespoły i automatyzacja SIG Docs

Automatyzacja w SIG Docs opiera się na dwóch różnych mechanizmach: zespołach GitHub i plikach OWNERS.

Zespoły GitHub

Istnieją dwie kategorie zespołów SIG Docs na GitHubie:

  • @sig-docs-{language}-owners są zatwierdzającymi i liderami
  • @sig-docs-{language}-reviews są recenzentami

Każdy z nich może być przywoływany za pomocą @nazwa w komentarzach na GitHubie, aby komunikować się z wszystkimi w tej grupie.

Czasami zespoły Prow i GitHub nakładają się na siebie, ale nie dokładnie pasują. W celu przypisywania problemów, pull requestów i wsparcia zatwierdzeń PR, automatyzacja korzysta z informacji z plików OWNERS.

pliki OWNERS i front-matter

Projekt Kubernetesa wykorzystuje narzędzie automatyzacji o nazwie prow do automatyzacji związanej z problemami i pull requestami w GitHub. Repozytorium strony internetowej Kubernetesa używa dwóch wtyczek prow:

  • blunderbuss
  • approve

Te dwie wtyczki używają plików OWNERS i OWNERS_ALIASES w głównym katalogu repozytorium kubernetes/website na GitHubie, aby kontrolować jak prow działa w ramach tego repozytorium.

Plik OWNERS zawiera listę osób, które są recenzentami i zatwierdzającymi SIG Docs. Pliki OWNERS mogą również istnieć w podkatalogach i mogą nadpisywać osoby, które mogą działać jako recenzent lub zatwierdzający dla plików w tym podkatalogu i jego potomnych. Więcej informacji na temat plików OWNERS można znaleźć w OWNERS.

Ponadto, pojedynczy plik Markdown może wymieniać osoby przeglądające i zatwierdzające w swojej sekcji front-matter, albo poprzez wymienienie indywidualnych nazw użytkowników GitHub, albo grup GitHub.

Połączenie plików OWNERS i danych front-matter w plikach Markdown determinuje porady, jakie właściciele PR otrzymują od zautomatyzowanych systemów, dotyczące tego, kogo poprosić o techniczny i redakcyjny przegląd ich PR.

Jak działa scalanie (ang. merging)

Kiedy pull request zostanie scalony z gałęzią używaną do publikowania treści, ta treść jest publikowana na https://kubernetes.io. Aby zapewnić wysoką jakość naszych publikowanych treści, ograniczamy scalanie pull requestów do zatwierdzających SIG Docs. Oto jak to działa.

  • Gdy pull request ma zarówno etykiety lgtm, jak i approve, nie ma etykiet hold, i wszystkie testy przechodzą pomyślnie, pull request łączy się automatycznie.
  • Członkowie organizacji Kubernetesa i zatwierdzający z SIG Docs mogą dodawać komentarze w celu wstrzymania automatycznemu scaleniu danego pull requesta (poprzez dodanie komentarza /hold lub wstrzymanie komentarza /lgtm).
  • Każdy członek Kubernetesa może dodać etykietę lgtm, dodając komentarz /lgtm.
  • Tylko zatwierdzający SIG Docs mogą scalić pull request dodając komentarz /approve. Niektórzy zatwierdzający pełnią również dodatkowe specyficzne role, takie jak PR Wrangler lub przewodniczący SIG Docs.

Co dalej?

Więcej informacji na temat wnoszenia wkładu w dokumentację Kubernetesa można znaleźć w:

Ostatnia modyfikacja February 05, 2025 at 10:54 AM PST: [pl] docs/contribute/participate/_index.md (733e7871a4)