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