Допомога у написанні блогу
Існує два офіційні блоги Kubernetes, і CNCF має власний блог, де ви також можете писати про Kubernetes. Прочитайте як робити внесок у створення дописів у блоги Kubernetes, щоб дізнатися про ці два блоги.
Коли людина робить внесок у будь-який з блогів як автор, проєкт Kubernetes обʼєднує авторів у пари як колег по написанню. Ця сторінка пояснює, як виконувати роль такого партнера.
Вам слід переконатися, що ви принаймні ознайомилися з правилами подання статті перед тим, як читати далі на цій сторінці.
Обовʼязки учасників групи
Як колега по написанню статей, ви:
- допомагаєте команді блогу готувати статті до обʼєднання та публікації
- підтримувати свого колегу у створенні контенту, який добре підходить для обʼєднання
- надавати рецензію на статтю, яку написав ваш напарник
Коли команда обʼєднує вас в пару з іншим автором, ідея полягає в тому, що ви обидва підтримуєте один одного, рецензуючи чернетку статті іншого автора. Більшість людей, які читають статті в блозі Kubernetes, не є експертами; контент повинен бути зрозумілим для цієї аудиторії або принаймні належним чином підтримувати читачів, які не є експертами.
Команда блогу також готова допомогти вам обом на шляху від чернетки до публікації. Вони можуть або безпосередньо схвалити вашу статтю для публікації, або організувати її схвалення.
Підтримка команди блогу
Ваш головний обовʼязок тут — повідомляти про свої можливості, доступність і прогрес у розумні терміни. Якщо минає багато тижнів, а ваш приятель нічого не чує від вас, це призводить до того, що загальна робота займає більше часу.
Підтримка вашого колеги
Процес складається з двох частин
(Це рекомендований варіант).
Команда блогу рекомендує головному автору статті налаштувати спільне редагування за допомогою Google Doc або HackMD (на вибір). Потім головний автор ділиться цим документом з наступними людьми:
- Будь-яким зі співавторів
- Вами (їх колегою по написанню статті)
- В ідеалі, з призначеною особою з команди блогу.
Ви, як колега по написанню, читаєте чернетку тексту і або безпосередньо вносите пропозиції, або надаєте відгук в інший спосіб. Автор блогу дуже часто також є вашим партнером по написанню, тому вони надаватимуть такі ж самі відгуки на чернетку вашої статті в блозі.
Ваша роль тут полягає в тому, щоб порекомендувати найменший набір змін, які зроблять статтю придатною для публікації. Якщо є діаграма, яка дійсно не має сенсу, або написання дійсно незрозуміле: надайте свій відгук. Якщо у вас є невелика розбіжність у думках щодо формулювань або пунктуації, пропустіть це. Дозвольте автору(ам) статті писати у власному стилі, за умови, що вони дотримуватимуться правил ведення блогу.
Після того, як все буде готово, основний автор відкриє pull request і використає Markdown, щоб подати статтю. Потім ви надаєте рецензію.
Деякі автори вважають за краще починати з спільного редагування; іншим подобається одразу переходити до GitHub.
Який би шлях вони не обрали, ваша роль полягає у наданні відгуків, які дозволять команді блогу надати просте підтвердження і підтвердити, що стаття може бути обʼєднана як чернетка. Що потрібно зробити авторам, див. у статті Подання статей до блогів Kubernetes.
Використовуйте функцію пропозицій GitHub, щоб вказати на будь-які необхідні зміни.
Після того, як розмітка та інший контент (наприклад, зображення) будуть виглядати правильно, ви надасте офіційну рецензію.
Рецензування pull request
Слідкуйте за розділом blog у Рецензуванні pull request'ів.
Якщо ви вважаєте, що відкритий запит до блогу достатньо хороший для злиття, додайте до нього коментар /lgtm.
Це вкаже інструменту автоматизації репозиторію (Prow), що вміст «виглядає добре для мене». Prow просуває роботу далі. Команда /lgtm дозволяє вам додати свою думку до запису, незалежно від того, чи є ви формально учасником проєкту Kubernetes, чи ні.
Ви або автор(и) статті повинні повідомити команду блогу про те, що стаття готова до підписання. Вона вже має бути позначена як draft: true у front matter, як пояснюється в інструкції з подання.
Наступні кроки
Для вас, як для колеги-автора, четвертого кроку не існує. Після того, як pull request буде готовий до злиття, команда блогу (або, для сайту учасників, команда учасників) візьметься за роботу далі. Можливо, вам доведеться повернутися до попереднього кроку на основі відгуків, але зазвичай ви можете розраховувати на те, що ваша робота в статусі колеги буде завершена.