Współtworzenie nowych treści

Ta sekcja zawiera informacje, które powinieneś znać przed dodaniem nowej treści.

Istnieją również dedykowane strony dotyczące pisania studiów przypadków oraz artykułów na bloga.

Proces tworzenia nowej treści

flowchart LR subgraph second[Zanim zaczniesz] direction TB S[ ] -.- A[Podpisz CNCF CLA] --> B[Wybierz gałąź Git] B --> C[Jeden język na PR] C --> F[Sprawdź
narzędzia dla współtwórców] end subgraph first[Podstawy współtworzenia] direction TB T[ ] -.- D[Pisz dokumentację w Markdown
i buduj stronę za pomocą Hugo] --- E[Kod źródłowy w GitHub] E --- G[Folder '/content/../docs' zawiera dokumentację
w wielu językach] G --- H[Zapoznaj się z typami stron
i shortcode'ami w Hugo] end first ----> second classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,C,D,E,F,G,H grey class S,T spacewhite class first,second white

Rysunek - Przygotowanie nowej treści

Powyższy rysunek przedstawia informacje, które powinieneś znać przed przesłaniem nowej treści. Szczegóły znajdują się poniżej.

Podstawy kontrybucji

  • Napisz dokumentację Kubernetesa w formacie Markdown i zbuduj stronę Kubernetesa za pomocą Hugo.
  • Dokumentacja Kubernetesa używa CommonMark jako swojej wersji Markdown.
  • Źródło znajduje się na GitHub. Dokumentację Kubernetesa można znaleźć w /content/en/docs/. Część dokumentacji referencyjnej jest automatycznie generowana ze skryptów w katalogu update-imported-docs/.
  • Typy zawartości strony opisują sposób prezentacji treści dokumentacji w Hugo.
  • Możesz użyć kodów Docsy lub niestandardowych skrótów Hugo, aby wspierać dokumentację Kubernetes.
  • Oprócz standardowych kodów Hugo, w naszej dokumentacji używamy wielu niestandardowych kodów Hugo, aby kontrolować prezentację treści.
  • Dokumentacja jest dostępna w wielu językach w katalogu /content/. Każdy język ma własny folder z dwuliterowym kodem określonym przez standard ISO 639-1 . Na przykład, źródło dokumentacji angielskiej jest przechowywane w /content/en/docs/.
  • Aby uzyskać więcej informacji na temat wnoszenia wkładu do dokumentacji w wielu językach lub rozpoczęcia nowego tłumaczenia, zobacz Lokalizowanie.

Zanim zaczniesz

Podpisz CNCF CLA

Wszyscy współtwórcy Kubernetesa muszą przeczytać Przewodnik dla Współtwórców i podpisać Umowę Licencyjną Współtwórcy (CLA) .

Pull requesty od autorów, którzy nie podpisali umowy CLA, nie przechodzą testów automatycznych. Imię i adres e-mail, które podasz, muszą zgadzać się z tymi ustawionymi w twoim git config, a twoje imię i adres e-mail w git muszą być takie same jak te używane dla CNCF CLA.

Wybierz gałąź w Git

Podczas otwierania pull requesta musisz wiedzieć z góry, na której gałęzi oprzeć swoją pracę.

ScenariuszGałąź
Istniejąca lub nowa treść w języku angielskim dla bieżącego wydaniamain
Treść dla wydania zmiany funkcjiGałąź, która odpowiada głównej i mniejszej wersji, w której znajduje się zmiana funkcji, używając wzorca dev-<version>. Na przykład, jeśli funkcja zmienia się w wydaniu v1.36, należy dodać zmiany w dokumentacji do gałęzi dev-1.36.
Treść w innych językach (lokalizacje)Użyj konwencji danej lokalizacji. Zobacz Strategia rozgałęzień lokalizacji po więcej informacji.

Jeśli nadal nie masz pewności, którą gałąź wybrać, zapytaj na #sig-docs na Slacku.

Informacja:

Jeśli już zgłosiłeś swoj pull request i wiesz, że była to niepoprawna gałąź bazowa, możesz ją zmienić (ty i tylko ty, zgłaszający).

Języki na PR

Ogranicz żądania pull request do jednego języka na PR. Jeśli musisz wprowadzić identyczną zmianę w tym samym fragmencie kodu w wielu językach, otwórz osobne PR dla każdego języka.

Narzędzia dla współtwórców

Katalog narzędzi dla współtwórców dokumentacji w repozytorium kubernetes/website zawiera narzędzia, wspierające proces współtworzenia dokumentacji.

Co dalej?


Ostatnia modyfikacja May 24, 2025 at 7:18 PM PST: [pl] sync with PR 50092 (56469cb960)