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

Ці настанови стосуються основного блогу 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, швидше за все, відхилить цю статтю).