釋出後通訊

Kubernetes *版本溝通*團隊（屬於SIG Release）負責版本公告，這些公告會發布在主專案部落格上。

每次釋出後，版本溝通團隊會接管主部落格一段時間，併發布一系列額外的文章來解釋或公告與該版本相關的更改。這些額外的文章被稱為*版本後溝通*。

選擇加入版本後溝通

在釋出週期中，作為貢獻者，您可以選擇就即將釋出的 Kubernetes 更改進行版本後溝通。

要選擇加入，您需要針對k/website倉庫開啟一個草稿、*佔位符*拉取請求（PR）。最初，這可以是一個空的提交。在您的佔位符 PR 的描述中提及 KEP 問題或其他 Kubernetes 改進問題。

當您開啟*草稿*拉取請求時，請針對 `main` 分支作為基礎分支開啟，而不是針對 `dev-1.35` 分支。這與釋出前更改和新功能的流程不同。

您還應該在相關的kubernetes/enhancements問題上留下評論，並附上 PR 的連結，以通知負責此次釋出的版本溝通團隊。您的評論有助於團隊瞭解該更改需要公告，並且您的 SIG 已選擇加入。

除了以上內容，您最好透過 Slack（頻道`#release-comms`）聯絡版本溝通團隊，告知他們您已完成此操作並希望選擇加入。

準備文章內容

您應遵循通常的文章提交流程，將您的佔位符 PR 轉換為可供審查的內容。但是，對於版本後溝通，您可能沒有*寫作夥伴*；取而代之的是，版本溝通團隊可能會指派一名團隊成員來幫助指導您的工作。

您應該壓縮（squash）您的拉取請求中的提交；如果您不確定如何操作，完全可以向版本溝通團隊或部落格團隊尋求幫助。

前提是您的文章在前端設定（front matter）中被標記為草稿（`draft: true`），PR 可以在釋出週期中的任何時間合併。

釋出

在實際釋出之前，版本溝通團隊會檢查哪些內容已準備就緒（如果在截止日期前未準備好，且未獲得豁免，則公告將不包含在內）。他們會為將要釋出的文章制定時間表，並開啟新的拉取請求，將這些文章從草稿狀態變為已釋出。

部落格團隊的批准者仍然會對內容從草稿到接受釋出的推廣提供最終批准。在釋出日期之前，用於釋出這些公告的 PR（或 PR 組）應具有 LGTM（“看起來不錯”）和已批准標籤，以及*do-not-merge/hold*標籤，以確保 PR 不會被過早合併。

版本溝通團隊/版本團隊隨後可以在網站 Git 倉庫解凍後（釋出實際發生後）立即*取消暫掛*該 PR（或 PR 組）。

在每篇文章計劃釋出的當天，自動化會觸發一次網站構建，該文章就會變得可見。