為版本發行編寫功能文件
每個 Kubernetes 主要版本都會引入需要文件的全新功能。新版本也會為現有功能與文件帶來更新（例如將功能從 Alpha 升級到 Beta）。
一般而言，負責功能的 SIG 會將功能的文件草稿作為提取請求提交到 kubernetes/website 儲存庫的適當開發分支，而 SIG Docs 團隊的成員會提供編輯回饋或直接編輯草稿。本節涵蓋發行期間兩個群組使用的分支慣例與流程。
適用於文件貢獻者
一般而言，文件貢獻者不會從頭開始為版本撰寫內容。相反地，他們會與建立新功能的 SIG 合作，以完善文件草稿並使其準備好發行。
在您選擇要編寫文件或協助的功能後，請在 #sig-docs Slack 頻道、每週 SIG Docs 會議中或直接在功能 SIG 提交的 PR 上詢問。如果您獲得許可，您可以使用Commit into another person's PR中描述的技術之一編輯 PR。
瞭解即將推出的功能
若要瞭解即將推出的功能，請參加每週 SIG Release 會議（請參閱社群頁面以瞭解即將舉行的會議）並監控 kubernetes/sig-release 儲存庫中特定版本的發行文件。每個版本在 /sig-release/tree/master/releases/ 目錄中都有一個子目錄。子目錄包含發行排程、發行注意事項草稿以及列出發行團隊中每個人的文件。
發行排程包含所有其他文件、會議、會議記錄與與發行相關的里程碑連結。它也包含有關發行目標與時間軸的資訊，以及此版本的任何特殊流程。文件底部附近定義了幾個與發行相關的術語。
本文件也包含功能追蹤表的連結，這是找出排程納入發行的所有新功能的官方方式。
發行團隊文件列出誰負責每個發行角色。如果不清楚該與誰談論您有的特定功能或問題，請參加發行會議提出您的問題，或聯絡發行負責人，以便他們可以重新導向您。
發行注意事項草稿是瞭解特定功能、變更、棄用以及更多關於發行的好地方。內容在發行週期後期才會定稿，因此請謹慎使用。
功能追蹤表
給定 Kubernetes 版本的功能追蹤表列出計劃用於發行的每個功能。每個行項目都包含功能名稱、功能主要 GitHub 問題的連結、其穩定性層級（Alpha、Beta 或 Stable）、負責實作它的 SIG 與個人、是否需要文件、功能的發行注意事項草稿以及是否已合併。請記住以下幾點
- Beta 與 Stable 功能通常比 Alpha 功能具有更高的文件優先順序。
- 很難測試（因此也很難編寫文件）尚未合併或至少在其 PR 中被視為功能完整的功能。
- 判斷功能是否需要文件是一個手動過程。即使功能未標記為需要文件，您可能仍需要為該功能編寫文件。
適用於開發人員或其他 SIG 成員
本節是針對其他 Kubernetes SIG 成員為版本編寫新功能文件的資訊。
如果您是為 Kubernetes 開發新功能的 SIG 成員，您需要與 SIG Docs 合作，以確保您的功能在發行前及時編寫文件。請檢查 功能追蹤試算表或查看 #sig-release Kubernetes Slack 頻道，以驗證排程詳細資訊與截止期限。
開啟預留位置 PR
- 針對
kubernetes/website儲存庫中的dev-1.33分支開啟草稿提取請求，其中包含稍後您將修改的小型提交。若要建立草稿提取請求，請使用建立提取請求下拉式選單並選取建立草稿提取請求，然後按一下草稿提取請求。 - 編輯提取請求描述，以包含 kubernetes/kubernetes PR 與 kubernetes/enhancements 問題的連結。
- 在相關的 kubernetes/enhancements 問題上留下評論，並附上 PR 的連結，以通知管理此版本的 Docs 人員即將推出功能文件，並且應該針對版本進行追蹤。
如果您的功能不需要任何文件變更，請務必透過在 #sig-release Slack 頻道中提及來讓 sig-release 團隊知道。如果功能確實需要文件，但未建立 PR，則功能可能會從里程碑中移除。
PR 準備好審閱
準備就緒時，請使用功能文件填入您的預留位置 PR，並將 PR 的狀態從草稿變更為準備好審閱。若要將提取請求標記為準備好審閱，請導覽至合併方塊並按一下準備好審閱。
盡力描述您的功能以及如何使用它。如果您需要有關組織文件結構的協助，請在 #sig-docs Slack 頻道中詢問。
當您完成內容時，指派給您功能的 Docs 人員會審閱它。為了確保技術準確性，內容也可能需要來自相應 SIG 的技術審閱。使用他們的建議使內容達到準備好發行的狀態。
如果您的功能需要文件，但未收到第一份草稿內容，則功能可能會從里程碑中移除。
功能閘道
如果您的功能是 Alpha 或 Beta 功能，並且位於功能閘道後面，則您需要一個功能閘道檔案，該檔案位於 content/en/docs/reference/command-line-tools-reference/feature-gates/ 內。檔案名稱應該是功能閘道，從 UpperCamelCase 轉換為 kebab-case，並以 .md 作為後綴。您可以查看同一目錄中已有的其他檔案，以獲取有關您的檔案外觀的提示。通常一個段落就足夠了；對於較長的說明，請在其他地方新增文件並連結到該文件。
此外，為了確保您的功能閘道出現在Alpha/Beta 功能閘道表中，請在 Markdown 描述檔案的前言中包含以下詳細資訊
stages:
- stage: <alpha/beta/stable/deprecated> # Specify the development stage of the feature gate
defaultValue: <true or false> # Set to true if enabled by default, false otherwise
fromVersion: <Version> # Version from which the feature gate is available
toVersion: <Version> # (Optional) The version until which the feature gate is available
對於全新的功能閘道，也需要單獨的功能閘道描述；在 content/en/docs/reference/command-line-tools-reference/feature-gates/ 內建立新的 Markdown 檔案（使用其他檔案作為範本）。
當您將功能閘道從預設停用變更為預設啟用時，您可能還需要變更其他文件（而不僅僅是功能閘道列表）。請注意諸如「exampleSetting 欄位是 Beta 欄位，預設為停用。您可以透過啟用 ProcessExampleThings 功能閘道來啟用它」之類的語言。
如果您的功能已正式發布 (GA'ed) 或已棄用 (deprecated)，請在描述檔的 stages 區塊中加入額外的 stage 條目。請確保 Alpha 和 Beta 階段保持不變。此步驟會將功能閘道從Alpha/Beta 功能的功能閘道表格轉換到已畢業或已棄用功能的功能閘道表格。例如：
stages:
- stage: alpha
defaultValue: false
fromVersion: "1.12"
toVersion: "1.12"
- stage: beta
defaultValue: true
fromVersion: "1.13"
# Added a `toVersion` to the previous stage.
toVersion: "1.18"
# Added 'stable' stage block to existing stages.
- stage: stable
defaultValue: true
fromVersion: "1.19"
toVersion: "1.27"最終，Kubernetes 將完全移除功能閘道。為了標示功能閘道的移除，請在各自描述檔的 front matter 中加入 removed: true。進行此變更意味著功能閘道資訊會從移除功能的功能閘道區段移動到標題為功能閘道（已移除）的專門頁面，包括其描述。
所有 PR 皆已審閱並準備合併
如果您的 PR 尚未在發布截止日期前合併到 dev-1.33 分支，請與負責管理發布文件的文件人員合作，以便在截止日期前完成。如果您的功能需要文件，且文件尚未準備就緒，該功能可能會從里程碑中移除。