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.
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.
Automatyzacja w SIG Docs opiera się na dwóch różnych mechanizmach: zespołach GitHub i plikach OWNERS.
Istnieją dwie kategorie zespołów SIG Docs na GitHubie:
@sig-docs-{language}-owners są zatwierdzającymi i liderami@sig-docs-{language}-reviews są recenzentamiKaż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.
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:
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.
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.
lgtm, jak i approve, nie ma etykiet
hold, i wszystkie testy przechodzą pomyślnie, pull request łączy się automatycznie./hold lub wstrzymanie komentarza /lgtm).lgtm, dodając komentarz /lgtm./approve. Niektórzy zatwierdzający pełnią również dodatkowe specyficzne
role, takie jak PR Wrangler
lub przewodniczący SIG Docs.Więcej informacji na temat wnoszenia wkładu w dokumentację Kubernetesa można znaleźć w: