Створення нового контенту
Цей розділ містить інформацію, яку слід знати перед тим, як створювати новий контент.
Також є спеціальні сторінки для подання прикладів використання та статей для блогу.
Схема — Підготовка до створення нового контенту
Вище показана інформація, яку слід знати перед надсиланням нового контенту. Деталі наведені нижче.
Основи участі
- Пишіть документацію Kubernetes у Markdown та збирайте сайт Kubernetes за допомогою Hugo.
- Документація Kubernetes використовує CommonMark варіант Markdown.
- Сирці знаходяться на GitHub. Ви можете знайти документацію Kubernetes в
/content/en/docs/. Частина довідкової документації автоматично генерується зі скриптів у теціupdate-imported-docs/. - Типи вмісту сторінок описують вигляд вмісту документації в Hugo.
- Ви можете використовувати Docsy shortcodes або власні Hugo shortcodes, щоб зробити внесок у документацію Kubernetes.
- Крім стандартних Hugo shortcodes, ми використовуємо кілька власних Hugo shortcodes у нашій документації для керування процесом обробки вмісту.
- Сирці документації доступні кількома мовами в
/content/. Кожна мова має свою теку з дволітерним кодом, визначеним ISO 639-1 стандартом. Наприклад, сирці документації англійською мовою зберігається в/content/en/docs/, української —/content/uk/docs/, відповідно. - Для отримання додаткової інформації про роботу з документацією кількома мовами або початку нової локалізації, див. локалізація.
Перш ніж розпочати
Підпишіть CNCF CLA
Усі учасники Kubernetes повинні ознайомитись з Настановами для учасників та підписати Угоду про ліцензування внесків (CLA, Contributor License Agreement).
Pull requests від учасників, які не підписали CLA, не пройдуть автоматизовані
тести. Імʼя та електронна адреса, які ви надаєте, повинні збігатися з тими, що знаходяться у вашій конфігурації git config, а ваше імʼя та електронна адреса в git повинні збігатися з тими, що використовуються для CNCF CLA.
Оберіть гілку Git для використання
Відкриваючи pull request, ви повинні заздалегідь знати, яку гілку взяти за основу для своєї роботи.
| Сценарій | Гілка |
|---|---|
| Поточний або новий контент англійською мовою для поточного випуску | main |
| Контент для випуску змін функцій | Гілка, яка відповідає основній та мінорній версії, у якій відбувається зміна функцій, використовуючи шаблон dev-<version>. Наприклад, якщо функція змінюється у випуску v1.34, то додайте зміни до документації у гілку dev-1.34. |
| Контент іншими мовами (локалізація) | Використовуйте домовленості локалізації. Див. Стратегію створення гілок локалізації для отримання додаткової інформації. |
Якщо ви все ще не впевнені, яку гілку обрати, запитайте у #sig-docs в Slack.
Примітка:
Якщо ви вже подали свій pull request і знаєте, що базова гілка була неправильною, ви (і тільки ви, відправник) можете змінити її.Мови в одному PR
Обмежуйте pull requests однією мовою на PR. Якщо вам потрібно внести однакові зміни до одного і того ж зразка коду кількома мовами, відкрийте окремий PR для кожної мови.
Інструменти
Тека інструменти для учасників в репозиторії kubernetes/website містить інструменти, які допоможуть зробити вашу участь в створенні документації простішою.
Що далі
- Прочитайте про подання статей до блогу.