Дописи в блог та приклади використань

Кожен може зробити допис в блог та подати його на рецензію. Дописі в Приклади використань потребують ретельного перегляду перед затвердженням.

Блог Kubernetes

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

Кожен може написати блог і подати його на рецензію.

Створення публікації

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

Нові можливості Kubernetes
Оновлення проєктів Kubernetes
Оновлення від робочих груп (Special Interest Groups, SIGs)
Підручники та керівництва
Роздуми щодо Kubernetes
Інтеграція з Kubernetes Partner OSS
Тільки оригінальний контент

Непридатний контент:

Комерційні презентації продуктів
Оновлення від партнерів без інтеграції та історії клієнтів
Синдиковані пости (переклади різними мовами дозволені)

Щоб подати блог-пост, дотримуйтеся наступних кроків:

Підпишіть CLA, якщо ви цього ще не зробили.
Ознайомтесь з форматом Markdown для наявних блог-постів у репозиторії вебсайту.
Напишіть свій блог у текстовому редакторі за вашим вибором.
На тому ж посиланні з кроку 2, натисніть кнопку Створити новий файл. Вставте свій контент у редактор. Назвіть файл відповідно до запропонованої назви блог-посту, але не вказуйте дату у назві файлу. Рецензенти блогу працюватимуть з вами над остаточною назвою файлу та датою публікації блогу.
Коли ви збережете файл, GitHub проведе вас через процес pull request.
Рецензент блогів перегляне вашу подачу та працюватиме з вами з відгуками та остаточними деталями. Коли блог-пост буде затверджений, блог буде запланований до публікації.

Технічні міркування щодо розміщення допису в блозі

Дописи повинні бути у форматі Markdown, щоб використовуватись генератором Hugo для блогу. Є багато ресурсів з використання цього технологічного стека.

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

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

Підпроєкт блогу керує процесом рецензування блог-постів. Для отримання додаткової інформації дивіться Submit a post.

Щоб створити блог-пост, дотримуйтеся цих вказівок:

Відкрийте pull request з новим блог-постом. Нові блог-пости розміщуються у теці content/en/blog/_posts.
Переконайтеся, що ваш блог-пост відповідає чинним домовленостям та містить таку інформацію у frontmatter (метадані):
- Назва файлу Markdown повинна відповідати формату YYYY-MM-DD-Your-Title-Here.md. Наприклад, 2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md.
- Не включайте крапки в назву файлу. Назва, як-от 2020-01-01-whats-new-in-1.19.md, викликає помилки під час збірки.
- Front matter повинен включати наступне:
```
---
layout: blog
title: "Your Title Here"
date: YYYY-MM-DD
slug: text-for-URL-link-here-no-spaces
author: >
  Author-1 (Affiliation),
  Author-2 (Affiliation),
  Author-3 (Affiliation)  
---
```
- Перше або початкове повідомлення коміту повинно бути коротким підсумком виконаної роботи та повинно самостійно описувати блог-пост. Зверніть увагу, що наступні правки вашого блогу будуть обʼєднані в цей основний коміт, тому він повинен бути якомога інформативнішим.
  - Приклади хорошого опису коміту:
    - Add blog post on the foo kubernetes feature
    - blog: foobar announcement
  - Приклади поганого опису коміту:
    - Add blog post
    - .
    - initial commit
    - draft post
- Команда блогу потім перегляне ваш PR і надасть вам коментарі щодо речей, які потрібно виправити. Після цього бот обʼєднає ваш PR і ваш блог-пост буде опубліковано.
- Якщо вміст блог-посту містить лише такий контент, який не потребуватиме оновлень, щоб залишатися актуальним для читача, його можна позначити як вічнозелений і звільнити від автоматичного попередження про застарілий контент, що додається до блог-постів старше одного року.
  - Щоб позначити блог-пост як вічнозелений, додайте це до front matter:
```
evergreen: true
```
  - Приклади контенту, який не слід позначати вічнозеленим:
    - Підручники, які застосовуються лише до конкретних випусків або версій, а не до всіх майбутніх версій
    - Посилання на API або функції pre-GA

Віддзеркалення з блогу учасників Kubernetes

Щоб віддзеркалити блог-пост з блогу учасників Kubernetes, дотримуйтеся цих рекомендацій:

Залиште вміст блогу таким самим. Якщо є зміни, їх слід внести спочатку до оригінальної статті, а потім до віддзеркаленої статті.
Віддзеркалений блог-пост повинен мати canonicalUrl, тобто фактично URL оригінального посту після його публікації.
Так само як і в блогу учасників Kubernetes, дописи в блогах Kubernetes також згадують авторів у заголовку YAML згідно з новими настановами. Потрібно переконатись в їх наявності.
Дати публікації залишаються такими ж, як в оригінальному блозі.

Усі інші рекомендації та очікування, викладені вище, також застосовуються.

Дописи у Приклади використання

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

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

Зверніться до керівництва з підготовки прикладу використання і подайте свій запит, як зазначено в керівництві.

Змінено September 19, 2024 at 6:45 PM PST: upstream sync (5177b0dd6f)