Команда Release Comms Kubernetes (частина SIG Release) займається анонсами випусків, які публікуються у головному блозі проєкту.
Після кожного випуску команда Release Comms на певний час бере на себе головний блог і публікує серію додаткових статей, щоб пояснити або оголосити зміни, повʼязані з цим випуском. Ці додаткові статті називають post-release comms (комунікаціями після випуску).
Під час циклу випуску ви як учасник можете долучитися до комунікацій після випуску щодо майбутньої зміни в Kubernetes.
Щоб долучитися, відкрийте чернетку placeholder pull request (PR) до k/website. Спочатку це може бути порожній коміт. Згадайте тікет KEP або інший тікет щодо покращення Kubernetes в описі вашого placeholder PR.
Коли ви відкриваєте чернетку pull request, ви відкриваєте її з main як базовою гілкою, а не з гілкою dev-1.38. Це відрізняється від процесу для змін майбутнього випуску та нових можливостей.
Також слід залишити коментар у відповідному тікеті kubernetes/enhancements з посиланням на PR, щоб повідомити команду Release Comms, яка керує цим випуском. Ваш коментар допоможе команді побачити, що зміну потрібно анонсувати і що ваша SIG вирішила долучитися.
Крім того, в ідеалі слід звʼязатися з командою Release Comms через Slack (канал #release-comms), щоб повідомити, що ви це зробили й хочете долучитися.
Щоб перетворити ваш placeholder PR на щось готове до рецензування, дотримуйтеся звичайного процесу подання статті. Однак для комунікацій після випуску у вас може не бути writing buddy (помічника з написання); натомість команда Release Comms може призначити члена команди, який допоможе спрямовувати вашу роботу.
Слід виконати squash комітів у вашому pull request; якщо ви не знаєте, як це зробити, цілком нормально попросити допомоги в Release Comms або команди блогу.
За умови, що вашу статтю позначено як чернетку (draft: true) у front matter, PR можна злити в будь-який час протягом циклу випуску.
Перед самим випуском команда Release Comms перевіряє, який вміст готовий (якщо його не готово до встановленого терміну і ви не отримали винятку, анонс не буде включено). Вона складає графік статей, які вийдуть, і відкриває нові pull request, щоб перевести ці статті з чернеток в опубліковані.
/hold), доки випуск фактично не відбудеться.Затверджувачі команди блогу все одно дають остаточну згоду на переведення вмісту з чернетки до прийнятого для публікації. Напередодні дня випуску PR (або кілька PR) для публікації цих анонсів мають мати мітки LGTM (“looks good to me”, «на мою думку, усе добре») та approved, а також мітку do-not-merge/hold, щоб PR не злили зарано.
Після цього Release Comms / команда випуску може зняти hold з цього PR (або набору PR), щойно Git-репозиторій вебсайту буде розморожено після фактичного випуску.
У день, коли кожна стаття запланована до публікації, автоматизація запускає збірку вебсайту, і стаття стає видимою.