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

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