為版本特性撰寫文件
每次 Kubernetes 主要版本釋出都會引入需要文件的新功能。新版本還會帶來現有功能和文件的更新（例如，將功能從 Alpha 升級到 Beta）。
通常，負責某功能的 SIG 會將其功能的草稿文件透過 pull request 提交到 `kubernetes/website` 倉庫的相應開發分支，SIG Docs 團隊的某成員會提供編輯反饋或直接編輯草稿。本節介紹兩個團隊在釋出期間使用的分支約定和流程。
要了解如何在部落格上宣佈功能，請閱讀 釋出後溝通。
面向文件貢獻者
一般來說，文件貢獻者不會為某個版本從頭開始編寫內容。相反，他們會與建立新功能的 SIG 合作，完善草稿文件，使其達到釋出就緒狀態。
選擇要編寫文件或協助的功能後，請在 `#sig-docs` Slack 頻道、每週 SIG Docs 會議或功能 SIG 提交的 PR 上詢問。如果獲得批准，您可以使用 提交到他人 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.35` 分支上開啟一個 **草稿** pull request，包含一個稍後會修改的小提交。要建立草稿 pull request，請使用 **Create Pull Request** 下拉選單，選擇 **Create Draft Pull Request**，然後點選 **Draft Pull Request**。
- 編輯 pull request 描述，加入指向 kubernetes/kubernetes PR(s) 和 kubernetes/enhancements issue(s) 的連結。
- 在相關的 kubernetes/enhancements issue 上留下一條評論，附上 PR 的連結，以通知負責此版本文件的人員，功能文件即將到來，應被跟蹤以用於釋出。
如果您的功能不需要任何文件更改，請在 `#sig-release` Slack 頻道中提及，以告知 sig-release 團隊。如果功能需要文件但 PR 未建立，該功能可能會從里程碑中移除。
PR 已準備好進行稽核
準備就緒後，用功能文件填充您的佔位符 PR，並將 PR 的狀態從草稿更改為 **準備稽核**。要將 pull request 標記為準備稽核，請導航至合併框並點選 **Ready for review**。
盡力描述您的功能以及如何使用它。如果您在組織文件方面需要幫助，請在 `#sig-docs` Slack 頻道中提問。
完成內容後，分配給您功能的文件人員會進行稽核。為確保技術準確性，內容可能還需要相應 SIG 的技術稽核。根據他們的建議，使內容達到釋出就緒狀態。
如果您的功能需要文件但未收到初稿內容，該功能可能會從里程碑中移除。
功能門控
如果您的功能是 Alpha 或 Beta 功能，並且受功能門控 (feature gate) 的約束，您需要在 `content/en/docs/reference/command-line-tools-reference/feature-gates/` 目錄下為其提供一個功能門控檔案。檔名應為功能門控的名稱，字尾為 `.md`。您可以檢視同一目錄中的其他檔案，以獲取關於您的檔案應該是什麼樣子的提示。通常一段文字就足夠了；對於更長的解釋，請在其他地方新增文件並連結到那裡。
此外，為了確保您的功能門控出現在 Alpha/Beta 功能門控 表中，請在 Markdown 描述檔案的 **front matter** 中包含以下詳細資訊：
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（通用可用）或已棄用，請在描述檔案中 `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.35` 分支，請與負責該版本文件的人員合作，確保在截止日期前完成。如果您的功能需要文件但文件尚未準備好，該功能可能會從里程碑中移除。