Дописи у блог Kubernetes

• 1: Публікація статей у блогах Kubernetes
• 2: Правила створення постів у блозі
• 3: Віддзеркалення статті в блозі
• 4: Комунікація після випуску
• 5: Допомога у написанні блогу

1 - Публікація статей у блогах Kubernetes

Є два офіційні блоги Kubernetes, а CNCF має власний блог, де ви також можете писати про Kubernetes. У головному блозі Kubernetes ми (проєкт Kubernetes) радо публікуємо статті з різними поглядами та особливими акцентами, що мають стосунок до Kubernetes.

За кількома винятками для особливих випадків, ми публікуємо лише вміст, який ще ніде не подавався й не публікувався.

Написання статей для блогу(ів) Kubernetes

Як автор, ви маєте три різні шляхи до публікації.

Рекомендований шлях

Проєкт Kubernetes рекомендує такий підхід: запропонуйте свою статтю, звʼязавшись із командою блогу. Це можна зробити в Kubernetes Slack (#sig-docs-blog). Статті, які ви хочете опублікувати лише в блозі учасників, можна також запропонувати безпосередньо SIG ContribEx comms.

Якщо з вашою заявкою не буде проблем, команда блогу / SIG ContribEx обʼєднає вас у пару з:

• редактором блогу
• вашим помічником з написання (writing buddy, іншим автором блогу)

Коли команда обʼєднує вас у пару з іншим автором, ідея в тому, що ви підтримуєте одне одного, рецензуючи чернетку статті іншого автора. Вам не потрібно бути експертом у темі; більшість читачів статті теж не будуть експертами. Ми, команда блогу Kubernetes, називаємо іншого автора помічником з написання (writing buddy).

Редактор супроводжуватиме вас на шляху від чернетки до публікації. Він або може безпосередньо затвердити вашу статтю для публікації, або організує затвердження.

Докладніше про процес див. Написання статті.

Почати з pull request

Другий шлях до написання для наших блогів — почати безпосередньо з pull request на GitHub. Насправді команда блогу цього не рекомендує: GitHub дуже зручний для спільної роботи над кодом, але не ідеально підходить для прозових текстів.

Цілком нормально відкрити placeholder pull request лише з порожнім комітом, а потім працювати деінде, перш ніж повернутися до свого placeholder PR.

Як і в рекомендованому шляху, ми спробуємо обʼєднати вас у пару з помічником з написання та редактором блогу. Вони допоможуть вам підготувати статтю до публікації.

Процес створення статті у блозі після випуску

Третій шлях призначено для статей блогу про зміни в Kubernetes, повʼязані з випуском. Щоразу, коли відбувається випуск, команда Release Comms бере на себе графік публікацій у блозі. Люди, які додають можливості до випуску або планують інші зміни, про які проєкт має оголосити, можуть домовитися з Release Comms, щоб їхню статтю запланували, написали, відредагували й зрештою опублікували.

Планування статей

У блозі Kubernetes команда блогу зазвичай планує публікацію статей у будні дні (за григоріанським календарем, який використовується у США та інших країнах). Якщо важливо опублікувати статтю у певну дату, яка припадає на вихідні, команда блогу намагається це врахувати.

У розділі Написання статті пояснено, що робити:

• спочатку не вказуйте дату для статті
• однак позначте статтю як чернетку (додайте draft: true у front matter)

Коли бот Prow зіллє ваш PR, стаття буде чернеткою і не буде запланована до публікації. Потім учасник Kubernetes (ви, ваш помічник з написання або хтось із команди блогу) відкриває невеликий подальший PR, який позначає її для публікації. Злиття цього другого PR вивільняє статтю, що доти була чернеткою, і її може бути автоматично опубліковано.

У день, на який заплановано публікацію статті, автоматизація запускає збирання вебсайту, і ваша стаття стає видимою.

Написання статті

Після того як ви запропонуєте статтю, ми заохочуємо вас використовувати HackMD (вебредактор Markdown) або Google Doc, щоб поділитися версією тексту статті, яку можна редагувати. Ваш помічник з написання може прочитати чернетку, а потім або безпосередньо запропонувати зміни, або надати інший відгук. Він також має повідомити вас, якщо ваша чернетка не відповідає настановам щодо блогу.

Водночас ви зазвичай будете його помічником з написання і можете скористатися нашим посібником щодо підтримки його роботи.

Початкові адміністративні кроки

Вам слід підписати CLA, якщо ви ще цього не зробили. Найкраще подбати про це якомога раніше; якщо ви пишете в межах своєї роботи, можливо, доведеться погодити це з юридичним відділом роботодавця або з керівником, щоб переконатися, що вам дозволено підписати.

Початкова чернетка

Команда блогу рекомендує використовувати HackMD (вебредактор Markdown) або Google doc, щоб підготувати й поширити початкову версію тексту статті, яку можна редагувати наживо.

Ваш помічник з написання може коментувати та/або давати відгуки на вашу чернетку і перевірятиме (або має перевіряти), чи відповідає вона настановам. Водночас ви будете його помічником з написання і можете скористатися посібником, який пояснює, як підтримувати його роботу.

Однак на цьому етапі не надто переймайтеся точним форматуванням Markdown.

Якщо у вас є зображення, ви можете вставити растрову копію для отримання перших відгуків. Команда блогу може допомогти вам (пізніше) підготувати ілюстрації до остаточної публікації.

Markdown для публікації

Перегляньте формат Markdown наявних дописів блогу в репозиторії вебсайту на GitHub.

Якщо ви ще не знайомі з ними, прочитайте основи участі. Цей розділ сторінки передбачає, що у вас немає локального клону вашого форку і ви працюєте у вебінтерфейсі GitHub. Проте вам потрібно створити віддалений форк репозиторію вебсайту, якщо ви ще цього не зробили.

У репозиторії GitHub натисніть кнопку Create new file. Назвіть файл допису у форматі /content/en/blog/_posts/YYYY/abbreviated-post-title.md, де …/YYYY/… — підтека з дописами за відповідний рік. Якщо до допису потрібно додати зображення, діаграми тощо, створіть теку /content/blog/en/blog/_posts/YYYY/abbreviated-post-title/ з файлом index.md та додатковими файлами для вашого допису.

Скопіюйте наявний вміст з HackMD або Google Docs і вставте його в редактор. Далі в цьому розділі докладніше описано, що має бути в цьому файлі. Назвіть файл відповідно до запропонованого заголовка допису, але не додавайте дату в назву файлу. Рецензенти блогу разом із вами визначать остаточну назву файлу та дату публікації статті.

1. Коли ви збережете файл, GitHub проведе вас через процес створення pull request.

2. Ваш помічник з написання може рецензувати подання й працювати з вами над відгуками та остаточними деталями. Редактор блогу затверджує злиття вашого pull request як чернетки, яку ще не заплановано.

Front matter

Файл Markdown, який ви пишете, має використовувати Hugo front matter у форматі YAML.

Ось приклад:

---
layout: blog
title: "Your Title Here"
draft: true # буде змінено на "date: YYYY-MM-DD" перед публікацією
slug: lowercase-text-for-link-goes-here-no-spaces # необовʼязково
author: >
  Author-1 (Affiliation),
  Author-2 (Affiliation),
  Author-3 (Affiliation)
---

• спочатку не вказуйте дату для статті та не вставляйте замість неї будь-який замінник дати у front matter (НЕ РОБІТЬ ТАК date: XXXX-XX-XX)
• однак позначте статтю як чернетку (додайте draft: true у front matter статті)

Вміст статті

Як найвищий рівень заголовків у статті використовуйте заголовки Markdown другого рівня (##, а не #). Значення title, яке ви задаєте у front matter, стає заголовком першого рівня цієї сторінки.

Дотримуйтеся посібника зі стилю, але з такими винятками:

• ми не проти того, щоб автори писали статті у власному стилі, якщо більшість читачів зрозуміють суть викладеного матеріалу
• можна використовувати «ми» у статтях блогу, які мають кількох авторів, або якщо у вступі до статті чітко вказано, що автор пише від імені певної групи. Як ви помітите з цього розділу, хоча ми уникаємо використання «ми» у нашій документації, можна робити виправдані винятки.
• ми не використовуємо shortcodes Kubernetes для виносок (callouts), як-от {{< caution >}}. Це тому, що виноски призначені для читачів документації, а статті блогу — не документація.
• твердження про майбутнє допустимі, хоча в офіційних оголошеннях від імені Kubernetes ми використовуємо їх обережно
• прикладам коду в статтях блогу не потрібно використовувати shortcode {{< code_sample >}}, і часто краще (легше підтримувати), якщо вони його не використовують

Схеми та ілюстрації

Для ілюстрацій, діаграм або графіків за можливості використовуйте shortcode figure. Для доступності слід задати атрибут alt.

Для ілюстрацій і технічних схем намагайтеся використовувати векторну графіку. Команда блогу рекомендує SVG замість растрових (bitmap / піксельних) форматів діаграм, а також SVG замість Mermaid (джерело Mermaid можна зберегти в коментарі). Перевагу SVG над Mermaid пояснює те, що коли супровідники оновлюють Mermaid або змінюють відображення діаграм, вони можуть не мати простого способу звʼязатися з автором оригінальної статті, щоб перевірити, чи зміни прийнятні.

Посібник з діаграм призначено для документації Kubernetes, а не для статей блогу. Узгоджуватися з ним все одно добре, але:

• немає потреби підписувати діаграми як «Схема 1», «Схема 2» тощо.

Вимога щодо масштабованих (векторних) зображень ускладнює подання статей для менш досвідчених людей; Kubernetes SIG Docs і далі шукає способи знизити цей поріг. Якщо у вас є ідеї, як знизити барʼєр, зголошуйтеся допомогти.

Для інших зображень (наприклад, фотографій) команда блогу наполегливо рекомендує використовувати атрибути alt. Можна використати порожній атрибут alt, якщо засоби доступності взагалі не мають згадувати зображення, але це рідкісна ситуація.

Повідомлення комітів

Коли ви позначаєте pull request як готовий до рецензування, кожне повідомлення коміту має коротко підсумовувати виконану роботу. Перше повідомлення коміту має бути зрозумілим як загальний опис допису в блозі.

Приклади хороших повідомлень комітів:

• Add blog post on the foo kubernetes feature
• blog: foobar announcement

Приклади поганих повідомлень комітів:

• Placeholder commit for announcement about foo
• Add blog post
• asdf
• initial commit
• draft post

Обʼєднання комітів (squashing)

Коли ви вважатимете, що стаття готова до злиття, слід виконати squash комітів у вашому pull request; якщо ви не знаєте, як це зробити, можна попросити допомоги в команди блогу.

2 - Правила створення постів у блозі

Ці настанови стосуються головного блогу Kubernetes і блогу учасників Kubernetes.

Весь вміст блогів також має відповідати загальній політиці, викладеній у посібнику з вмісту.

Перш ніж ви розпочнете

Переконайтеся, що ви ознайомилися зі вступними розділами сторінки Дописи у блог Kubernetes, не лише щоб дізнатися про два офіційні блоги та відмінності між ними, а й щоб отримати загальне уявлення про процес.

Оригінальний вміст

Проєкт Kubernetes приймає лише оригінальний вміст англійською мовою.

Це обмеження поширюється навіть на просування інших проєктів Linux Foundation і CNCF. Багато проєктів CNCF мають власні блоги. Для дописів про певний проєкт вони часто є кращим вибором, навіть якщо цей проєкт створено спеціально для роботи з Kubernetes (або з Linux тощо).

Релевантний вміст

Статті мають містити вміст, який широко стосується спільноти Kubernetes. Наприклад, стаття має зосереджуватися на upstream Kubernetes, а не на конфігураціях конкретного постачальника. Для статей до головного блогу, які не є дзеркальними статтями, гіперпосилання в статті зазвичай мають вести на офіційну документацію Kubernetes. Зовнішні посилання мають бути різноманітними — наприклад, стаття не повинна містити посилань лише на блог однієї компанії.

Офіційні блоги Kubernetes — це не місце для реклами постачальників або для статей, які просувають конкретні рішення з-поза меж Kubernetes.

Іноді тут потрібен делікатний баланс. Ви можете запитати в Slack (#sig-docs-blog), чи підходить допис для блогу Kubernetes та/або блогу учасників, — не соромтеся звертатися.

Посібник з вмісту беззастережно застосовується до статей блогу і PR, які їх додають. Майте на увазі, що деякі обмеження в посібнику прямо зазначають, що стосуються лише документації; такі позначені обмеження не застосовуються до статей блогу.

Локалізація

Сайт локалізовано багатьма мовами; англійська є «upstream» для всіх інших локалізацій. Навіть якщо ви володієте іншою мовою і хотіли б надати локалізацію, вона має бути в окремому pull request (див. мови в PR).

Авторське право та повторне використання

Ви маєте писати оригінальний вміст і мати дозвіл ліцензувати цей вміст для Cloud Native Computing Foundation (щоб проєкт Kubernetes міг легально його опублікувати). Це означає, що заборонено не лише прямий плагіат: ви не можете писати статтю для блогу, якщо не маєте дозволу виконати умови ліцензії авторського права CNCF (наприклад, якщо ваш роботодавець має політику щодо інтелектуальної власності, яка обмежує, що вам дозволено робити).

Ліцензія блогу дозволяє комерційне використання вмісту в комерційних цілях, але не навпаки.

Групи за інтересами та робочі групи

Теми, повʼязані з участю в діяльності SIG Kubernetes або її результатами, завжди доречні (підтримку для таких дописів див. у роботі Contributor Comms Team).

Проєкт зазвичай віддзеркалює ці статті в обох блогах.

Національні обмеження щодо вмісту

Вебсайт Kubernetes має ліцензію постачальника інтернет-контенту (ICP) від уряду Китаю. Хоча це навряд чи стане проблемою, Kubernetes не може публікувати статті, які були б заблоковані офіційною фільтрацією інтернет-контенту урядом Китаю.

Рекомендації щодо вмісту для блогу

Крім загального посібника зі стилю, статтям блогу варто (а не обовʼязково) дотримуватися рекомендацій зі стилю для блогу.

Решта цієї сторінки — додаткові настанови; це не суворі правила, яких мають дотримуватися статті, але рецензенти, імовірно, попросять (і мають просити) відредагувати статті, які явно не відповідають наведеним тут рекомендаціям.

Схеми та ілюстрації

Для ілюстрацій, зокрема схем і діаграм, за можливості використовуйте shortcode figure. Для доступності слід задати атрибут alt.

Для ілюстрацій, технічних схем і подібної графіки використовуйте векторні зображення; рекомендовано надавати перевагу формату SVG.

Статті, які використовують растрові зображення для ілюстрацій, складніше підтримувати, і в деяких випадках команда блогу може попросити авторів доопрацювати статтю, перш ніж вона буде опублікована.

Позачасовість

Дописи в блозі мають бути розраховані на майбутнє

• З огляду на швидкість розвитку проєкту SIG Docs надає перевагу позачасовим текстам: вмісту, який не потребуватиме оновлень, щоб лишатися точним для читача.
• Додати підручник або оновити офіційну документацію може бути кращим вибором, ніж писати високорівневий огляд у вигляді допису в блозі.
• Подумайте про те, щоб винести довгий технічний вміст як заклик до дії в дописі, а зосередитися на проблемній області або на тому, чому читачам це має бути важливо.

Приклади вмісту

Ось кілька прикладів вмісту, який підходить для головного блогу Kubernetes:

• Оголошення про нові можливості Kubernetes
• Пояснення того, як досягти результату за допомогою Kubernetes; наприклад, розкажіть про ваше вдосконалення базової ідеї rolling deploy, яке зменшує рутинну роботу
• Порівняння кількох різних варіантів програмного забезпечення, повʼязаних з Kubernetes і cloud native. Можна посилатися на один із цих варіантів, якщо ви повністю розкриваєте свій конфлікт інтересів / звʼязок із ним.
• Історії про проблеми або інциденти, а також про те, як ви їх вирішили
• Статті про створення cloud native платформи для конкретних сценаріїв використання
• Ваша думка про хороші та погані сторони Kubernetes
• Оголошення та історії про частини Kubernetes поза ядром, як-от Gateway API
• Оголошення та оновлення після випуску
• Повідомлення про важливі вразливості у безпеці Kubernetes
• Оновлення проєктів Kubernetes
• Підручники та покрокові інструкції
• Експертні погляди (thought leadership) щодо Kubernetes і cloud native
• Компоненти Kubernetes навмисно модульні, тож писати про наявні точки інтеграції, як-от CNI і CSI, доречно. Якщо ваш допис не є рекламою постачальника, ви також можете писати про те, що розташоване по інший бік цих інтеграцій.

Ось кілька прикладів вмісту, який підходить для блогу учасників Kubernetes:

• статті про те, як протестувати ваші зміни у коді Kubernetes
• матеріали, що стосуються внеску, який не повʼязаний з кодом
• обговорення альфа-можливостей, дизайн яких ще обговорюється
• «Знайомство з командою»: статті про робочі групи, групи за інтересами тощо
• посібник про те, як писати безпечний код, який стане частиною самого Kubernetes
• статті про зустрічі супровідників та результати цих зустрічей

Приклади вмісту, який не буде прийнято

Однак проєкт не публікуватиме:

• рекламу постачальників
• статтю, яку ви опублікували в інших місцях, навіть якщо це лише ваш власний блог з низьким трафіком
• великі шматки вихідного коду прикладу з мінімальними поясненнями
• новини про зовнішній проєкт, який працює з Kubernetes або залежить від нього (публікуйте їх у власному блозі зовнішнього проєкту)
• статті про використання Kubernetes з конкретним хмарним провайдером
• статті, які критикують конкретних людей, групи людей або компанії
• статті, які містять важливі технічні помилки або деталі, що вводять в оману (наприклад: якщо ви рекомендуєте вимкнути важливий контроль безпеки у промислових кластерах, тому що це може бути незручно, проєкт Kubernetes, швидше за все, відхилить цю статтю).

3 - Віддзеркалення статті в блозі

Є два офіційні блоги Kubernetes, а CNCF має власний блог, де ви також можете писати про Kubernetes. У головному блозі Kubernetes ми (проєкт Kubernetes) радо публікуємо статті з різними поглядами та особливими акцентами, що мають стосунок до Kubernetes.

Деякі статті зʼявляються в обох блогах: є основна версія статті та дзеркальна стаття в іншому блозі.

На цій сторінці описано критерії віддзеркалення, його причини, а також що потрібно зробити, щоб стаття була опублікована в обох блогах.

Перш ніж ви розпочнете

Переконайтеся, що ви ознайомилися зі вступними розділами сторінки Дописи у блог Kubernetes, не лише щоб дізнатися про два офіційні блоги та відмінності між ними, а й щоб отримати загальне уявлення про процес.

Чому ми робимо віддзеркалення

Віддзеркалення майже завжди відбувається з блогу учасників до головного блогу. Проєкт робить це для статей, які стосуються спільноти учасників або її частини, але також цікаві ширшому колу читачів головного блогу Kubernetes.

Як автор (або рецензент), зважте на цільову аудиторію і на те, чи підходить допис для головного блогу. Наприклад, якщо цільова аудиторія — лише учасники Kubernetes, доречнішим може бути блог учасників; якщо допис стосується відкритого коду загалом, він може краще підійти для іншого сайту поза проєктом Kubernetes.

Це міркування про цільову аудиторію однаково стосується як оригінальних, так і дзеркальних статей.

Проєкт Kubernetes готовий віддзеркалити будь-яку статтю блогу, опубліковану на https://kubernetes.dev/blog/ (блог учасників), якщо виконано всі такі критерії:

• Віддзеркалена стаття має ту саму дату публікації, що й оригінал (вона також має мати той самий час публікації, але для особливих випадків можна встановити позначку часу до 12 годин пізніше)

• Для PR, які додають дзеркальну статтю до головного блогу після того, як оригінальну статтю злито в блог учасників, переконайтеся, що виконано всі такі критерії:

  • Жодної статті не було опубліковано в головному блозі після того, як оригінальна стаття була опублікована в блозі учасників.
  • У головному блозі не заплановано публікацій статей між часом публікації оригінальної статті та часом публікації вашої дзеркальної статті.

  Це повʼязано з тим, що проєкт Kubernetes не бажає додавати статті до стрічок користувачів, таких як RSS, окрім як у самому кінці стрічки.

• Оригінальна стаття не порушує жодних наполегливо рекомендованих настанов рецензування чи норм спільноти

• У віддзеркаленій статті буде правильно вказано canonicalUrl у її front matter

• Аудиторія оригінальної статті вважатиме її доречною

• Вміст статті не виходить за межі тематики цільового блогу, де зʼявиться дзеркальна стаття

Віддзеркалення з головного блогу в блог учасників трапляється рідко, але цілком можливе.

Як віддзеркалити

Ви створюєте PR до іншого Git-репозиторію (зазвичай https://github.com/kubernetes/website), який додає статтю. Це потрібно зробити до злиття статей.

Як автор статті, ви маєте встановити для віддзеркаленої статті канонічну URL-адресу — URL-адресу оригінальної статті (можна скористатися попереднім переглядом, щоб передбачити URL-адресу і заповнити її до фактичної публікації). Для цього використовуйте поле canonicalUrl у front matter.

4 - Комунікація після випуску

Команда Release Comms Kubernetes (частина SIG Release) займається анонсами випусків, які публікуються у головному блозі проєкту.

Після кожного випуску команда Release Comms на певний час бере на себе головний блог і публікує серію додаткових статей, щоб пояснити або оголосити зміни, повʼязані з цим випуском. Ці додаткові статті називають post-release comms (комунікаціями після випуску).

Участь у комунікаціях після випуску

Під час циклу випуску ви як учасник можете долучитися до комунікацій після випуску щодо майбутньої зміни в Kubernetes.

Щоб долучитися, відкрийте чернетку placeholder pull request (PR) до k/website. Спочатку це може бути порожній коміт. Згадайте тікет KEP або інший тікет щодо покращення Kubernetes в описі вашого placeholder PR.

Коли ви відкриваєте чернетку pull request, ви відкриваєте її з main як базовою гілкою, а не з гілкою dev-1.38. Це відрізняється від процесу для змін майбутнього випуску та нових можливостей.

Також слід залишити коментар у відповідному тікеті kubernetes/enhancements з посиланням на PR, щоб повідомити команду Release Comms, яка керує цим випуском. Ваш коментар допоможе команді побачити, що зміну потрібно анонсувати і що ваша SIG вирішила долучитися.

Крім того, в ідеалі слід звʼязатися з командою Release Comms через Slack (канал #release-comms), щоб повідомити, що ви це зробили й хочете долучитися.

Підготовка вмісту статті

Щоб перетворити ваш placeholder PR на щось готове до рецензування, дотримуйтеся звичайного процесу подання статті. Однак для комунікацій після випуску у вас може не бути writing buddy (помічника з написання); натомість команда Release Comms може призначити члена команди, який допоможе спрямовувати вашу роботу.

Слід виконати squash комітів у вашому pull request; якщо ви не знаєте, як це зробити, цілком нормально попросити допомоги в Release Comms або команди блогу.

За умови, що вашу статтю позначено як чернетку (draft: true) у front matter, PR можна злити в будь-який час протягом циклу випуску.

Публікація

Перед самим випуском команда Release Comms перевіряє, який вміст готовий (якщо його не готово до встановленого терміну і ви не отримали винятку, анонс не буде включено). Вона складає графік статей, які вийдуть, і відкриває нові pull request, щоб перевести ці статті з чернеток в опубліковані.

Затверджувачі команди блогу все одно дають остаточну згоду на переведення вмісту з чернетки до прийнятого для публікації. Напередодні дня випуску PR (або кілька PR) для публікації цих анонсів мають мати мітки LGTM (“looks good to me”, «на мою думку, усе добре») та approved, а також мітку do-not-merge/hold, щоб PR не злили зарано.

Після цього Release Comms / команда випуску може зняти hold з цього PR (або набору PR), щойно Git-репозиторій вебсайту буде розморожено після фактичного випуску.

У день, коли кожна стаття запланована до публікації, автоматизація запускає збірку вебсайту, і стаття стає видимою.

5 - Допомога у написанні блогу

Є два офіційні блоги Kubernetes, а CNCF має власний блог, де ви також можете писати про Kubernetes. Щоб дізнатися про ці два блоги, прочитайте Дописи у блог Kubernetes.

Коли люди роблять внесок у будь-який із блогів як автори, проєкт Kubernetes обʼєднує авторів у пари як помічників з написання (writing buddies). На цій сторінці пояснено, як виконувати роль помічника.

Перш ніж читати далі, переконайтеся, що ви принаймні ознайомилися із загальним описом подання статті.

Обовʼязки помічника

Як помічник з написання, ви:

• допомагаєте команді блогу підготувати статті до злиття та публікації
• підтримуєте свого напарника у створенні вмісту, придатного для злиття
• рецензуєте статтю, яку написав ваш напарник

Коли команда обʼєднує вас у пару з іншим автором, ідея в тому, що ви підтримуєте одне одного, рецензуючи чернетку статті іншого автора. Більшість людей, які читають статті в блозі Kubernetes, не є експертами; вміст має бути зрозумілим для цієї аудиторії або принаймні належним чином допомагати читачам, які не є експертами.

Команда блогу також допомагає вам обом на шляху від чернетки до публікації. Вона або може безпосередньо затвердити вашу статтю для публікації, або може організувати затвердження.

Підтримка команди блогу

Ваш головний обовʼязок тут — вчасно повідомляти про свої можливості, доступність і прогрес. Якщо минає багато тижнів, а ваш напарник нічого від вас не чує, уся робота триває довше.

Підтримка вашого напарника

Процес складається з двох частин

• Спільне редагування
• Редагування Markdown / Git

Рецензування pull request

Дотримуйтеся розділу Блог сторінки Рецензування pull request.

Коли ви вважаєте, що відкритий pull request до блогу достатньо добрий для злиття, додайте до нього коментар /lgtm.

Це вказує інструменту автоматизації репозиторію (Prow), що вміст «looks good to me» (на мою думку, усе добре). Prow просуває справу далі. Команда /lgtm дає змогу зафіксувати вашу думку незалежно від того, чи є ви формально членом проєкту Kubernetes.

Ви або автор (автори) статті маєте повідомити команду блогу, що стаття готова до погодження. Її вже має бути позначено як draft: true у front matter, як пояснено в настановах щодо подання.

Наступні кроки

Для вас як помічника з написання четвертого кроку немає. Щойно pull request буде готовий до злиття, далі все бере на себе команда блогу (або, для сайту учасників, команда contributor comms). Можливо, за результатами відгуків вам доведеться повернутися до попереднього кроку, але зазвичай можна вважати, що ваша робота як помічника завершена.