Дописи у блог 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 зʼєднає вас з

• редактором блогу
• вашим партнером по написанню статей (іншим автором блогу)

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

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

Прочитайте розділ написання статті в блозі, щоб дізнатися більше про цей процес.

Створення pull request

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

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

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

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

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

Планування розміщення статей

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

У розділі про написання статті в блозі пояснюється, що для цього потрібно зробити:

• спочатку не вказуйте дату для статті
• однак, позначте статтю як чернетку (поставте draft: true на титульному аркуші).

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

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

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

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

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

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

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

Початкова редакція

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

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

На цьому етапі не хвилюйтеся надто сильно про правильність форматування Markdown.

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

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

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

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

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

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

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

Front matter

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

Ось приклад:

---
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)  
---

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

Зміст статті

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

Ви повинні слідувати посібнику зі стилів, але з наступними винятками:

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

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

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

Для ілюстрацій та технічних схем намагайтеся використовувати векторну графіку. Команда блогу рекомендує SVG замість растрових (растрових / піксельних) форматів діаграм, а також рекомендує 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

Стискання комітів

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Локалізація

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Оголошення про нові можливості Kubernetes
• Пояснення того, як досягти результату за допомогою Kubernetes; наприклад, розкажіть нам про те, як ви без особливих зусиль покращили основну ідею rolling deploy.
• Порівняння декількох різних варіантів програмного забезпечення, які повʼязані з Kubernetes та хмарними технологіями. Це нормально, якщо ви посилаєтесь на один з цих варіантів, якщо ви повністю розкриваєте свій конфлікт інтересів/відносин.
• Історії про проблеми або інциденти, а також про те, як ви їх вирішили
• Статті, в яких обговорюється створення хмарної нативної платформи для конкретних випадків використання
• Ваша думка про хороші та погані сторони Kubernetes
• Оголошення та історії про неосновні можливості Kubernetes, такі як API Gateway
• Оголошення та оновлення після випуску
• Повідомлення про важливі вразливості у безпеці Kubernetes
• Оновлення проєктів Kubernetes
• Підручники та інструкції
• Поради щодо Kubernetes та нативних хмарних технологій
• Компоненти 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 на певний час перебирає на себе ведення головного блогу і публікує серію додаткових статей, щоб пояснити або оголосити про зміни, повʼязані з цим випуском. Ці додаткові статті називаються пост-релізними коментарями.

Підписка на розсилку після випуску

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

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

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

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

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

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

Вам слід дотримуватися звичайного процесу подання статті, щоб перетворити ваш PR-заповнювач на щось готове для рецензування. Однак, для коментарів після релізу у вас може не бути друга по написанню; натомість, команда Release Comms може призначити члена команди, який допоможе вам керувати тим, що ви робите.

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

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

Публікація

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

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

Реліз-команда/команда релізу може потім «розблокувати» цей PR (або набір PRʼів), як тільки Git-репозиторій вебсайту буде розморожено після фактичного релізу.

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

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

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

Коли люди роблять внесок у будь-який з блогів як автор, проєкт Kubernetes обʼєднує авторів у пари як колег по написанню. Ця сторінка пояснює, як виконувати роль такого партнера.

Вам слід переконатися, що ви принаймні ознайомилися з правилами подання статті перед тим, як читати далі на цій сторінці.

Обовʼязки учасників групи

Як колега по написанню статей, ви:

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

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

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

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

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

Підтримка вашого колеги

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

• Колективне редагування
• Редагування markdown / Git

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

Слідкуйте за розділом blog у Рецензуванні pull request'ів.

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

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

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

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

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