為核准者和審閱者審閱
SIG Docs 審閱者 和 核准者 在審閱變更時會執行一些額外的事情。
每週都會有一位特定的文件核准者自願分類和審閱提取請求。這個人是當週的「PR 管理員」。請參閱 PR 管理員排程器 以取得更多資訊。若要成為 PR 管理員，請參加每週的 SIG Docs 會議並自願。即使您不在當週的排程中，您仍然可以審閱尚未處於活躍審閱中的提取請求 (PR)。
除了輪換之外，機器人還會根據受影響檔案的擁有者為 PR 指派審閱者和核准者。
審閱 PR
Kubernetes 文件遵循 Kubernetes 程式碼審閱程序。
審閱提取請求 中描述的所有內容都適用，但審閱者和核准者也應執行以下操作
視需要使用
/assignProw 命令將特定審閱者指派給 PR。當需要從程式碼貢獻者請求技術審閱時，這尤其重要。注意
查看 Markdown 檔案頂部前言中的reviewers欄位，以查看誰可以提供技術審閱。適用時使用 GitHub 請求變更 選項來建議 PR 作者進行變更。
如果您的建議已實作，請使用
/approve或/lgtmProw 命令在 GitHub 中變更您的審閱狀態。
提交到其他人的 PR
留下 PR 評論很有幫助，但有時您可能需要提交到其他人的 PR 中。
除非他們明確要求您接管，或者您想要復活長期被放棄的 PR，否則請勿「接管」其他人的工作。雖然短期內可能會更快，但這剝奪了該人貢獻的機會。
您使用的程序取決於您是否需要編輯已在 PR 範圍內的文件，或 PR 尚未觸及的文件。
如果以下任何一項為真，您就無法提交到其他人的 PR 中
如果 PR 作者將他們的分支直接推送到 https://github.com/kubernetes/website/ 儲存庫。只有具有推送存取權限的審閱者才能提交到其他使用者的 PR。
注意
鼓勵作者在下次開啟 PR 之前將他們的分支推送到他們的分支。PR 作者明確禁止核准者編輯。
用於審閱的 Prow 命令
Prow 是基於 Kubernetes 的 CI/CD 系統，針對提取請求 (PR) 執行作業。Prow 啟用聊天機器人樣式的命令來處理整個 Kubernetes 組織的 GitHub 動作，例如 新增和移除標籤、關閉 issue 以及指派核准者。以 GitHub 評論的形式輸入 Prow 命令，使用 /<command-name> 格式。
審閱者和核准者最常使用的 prow 命令是
| Prow 命令 | 角色限制 | 描述 |
|---|---|---|
/lgtm | 組織成員 | 表示您已完成審閱 PR，並對變更感到滿意。 |
/approve | 核准者 | 核准要合併的 PR。 |
/assign | 任何人 | 指派人員審閱或核准 PR |
/close | 組織成員 | 關閉 issue 或 PR。 |
/hold | 任何人 | 新增 do-not-merge/hold 標籤，表示 PR 無法自動合併。 |
/hold cancel | 任何人 | 移除 do-not-merge/hold 標籤。 |
若要檢視您可以在 PR 中使用的命令，請參閱 Prow 命令參考。
分類和分類 issue
一般來說，SIG Docs 遵循 Kubernetes issue 分類 程序，並使用相同的標籤。
這個 GitHub Issue 篩選器 尋找可能需要分類的 issue。
分類 issue
驗證 issue
- 確保 issue 是關於網站文件。有些 issue 可以透過回答問題或將報告者指向資源來快速關閉。請參閱 支援請求或程式碼錯誤報告 區段以取得詳細資訊。
- 評估 issue 是否有價值。
- 如果 issue 沒有足夠的詳細資訊來執行，或者範本未充分填寫，請新增
triage/needs-information標籤。 - 如果 issue 同時具有
lifecycle/stale和triage/needs-information標籤，請關閉 issue。
新增優先順序標籤（Issue 分類指南 詳細定義了優先順序標籤）
| 標籤 | 描述 |
|---|---|
priority/critical-urgent | 立即執行此操作。 |
priority/important-soon | 在 3 個月內執行此操作。 |
priority/important-longterm | 在 6 個月內執行此操作。 |
priority/backlog | 無限期延遲。在資源可用時執行。 |
priority/awaiting-more-evidence | 潛在良好 issue 的佔位符，使其不會遺失。 |
help 或 good first issue | 適合 Kubernetes 或 SIG Docs 經驗很少的人。請參閱 徵求協助和良好的首個 Issue 標籤 以取得更多資訊。 |
您可以自行決定取得 issue 的所有權並為其提交 PR（尤其是在 issue 快速或與您已在進行的工作相關時）。
如果您對問題分類有疑問，請在 Slack 的 #sig-docs 頻道或 kubernetes-sig-docs 郵件論壇中提問。
新增與移除 Issue 標籤
若要新增標籤，請以以下其中一種格式留下評論
/<要新增的標籤>(例如，/good-first-issue)/<標籤類別> <要新增的標籤>(例如，/triage needs-information或/language ja)
若要移除標籤，請以以下其中一種格式留下評論
/remove-<要移除的標籤>(例如，/remove-help)/remove-<標籤類別> <要移除的標籤>(例如，/remove-triage needs-information)
在以上兩種情況下，標籤都必須已存在。如果您嘗試新增不存在的標籤，指令將會被靜默忽略。
如需所有標籤的清單，請參閱網站儲存庫的 Labels 區段。並非所有標籤都由 SIG Docs 使用。
Issue 生命週期標籤
Issue 通常會快速地被開啟和關閉。然而，有時 Issue 在開啟後會變得不活躍。其他時候，Issue 可能需要保持開啟超過 90 天。
| 標籤 | 描述 |
|---|---|
lifecycle/stale | 若 Issue 在 90 天內沒有任何活動，將會自動標記為 stale。如果沒有使用 /remove-lifecycle stale 指令手動回復生命週期，Issue 將會自動關閉。 |
lifecycle/frozen | 帶有此標籤的 Issue 在不活動 90 天後不會變成 stale。使用者會手動將此標籤新增至需要保持開啟遠超過 90 天的 Issue，例如帶有 priority/important-longterm 標籤的 Issue。 |
處理特殊的 Issue 類型
SIG Docs 經常遇到以下類型的 Issue，並記錄了處理它們的方式。
重複 Issue
如果單一問題有多個已開啟的 Issue，請將它們合併為單一 Issue。您應該決定要保留哪個 Issue (或開啟一個新的 Issue)，然後將所有相關資訊移過去並連結相關的 Issue。最後，將所有描述相同問題的其他 Issue 標記為 triage/duplicate 並關閉它們。只保留單一 Issue 處理可以減少混亂，並避免在同一個問題上重複工作。
失效連結 Issue
如果失效連結 Issue 出現在 API 或 kubectl 文件中，請將它們指派 /priority critical-urgent 優先級，直到問題完全被理解。將所有其他失效連結 Issue 指派 /priority important-longterm 優先級，因為它們必須手動修復。
部落格 Issue
我們預期 Kubernetes 部落格文章會隨著時間過時。因此，我們僅維護發布未滿一年的部落格文章。如果 Issue 與發布超過一年的部落格文章相關，請關閉 Issue 而不進行修復。
支援請求或程式碼錯誤報告
有些文件 Issue 實際上是底層程式碼的問題，或是針對某些問題 (例如教學範例無法運作) 的協助請求。對於與文件無關的 Issue，請使用 kind/support 標籤關閉 Issue，並留下評論引導請求者前往支援管道 (Slack、Stack Overflow)，並且如果相關，也引導他們前往儲存庫提交功能錯誤的 Issue (kubernetes/kubernetes 是一個很好的起點)。
支援請求的回應範例
This issue sounds more like a request for support and less
like an issue specifically for docs. I encourage you to bring
your question to the `#kubernetes-users` channel in
[Kubernetes slack](https://slack.k8s.io/). You can also search
resources like
[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
for answers to similar questions.
You can also open issues for Kubernetes functionality in
https://github.com/kubernetes/kubernetes.
If this is a documentation issue, please re-open this issue.
程式碼錯誤報告的回應範例
This sounds more like an issue with the code than an issue with
the documentation. Please open an issue at
https://github.com/kubernetes/kubernetes/issues.
If this is a documentation issue, please re-open this issue.
合併提交 (Squashing)
身為核准者，當您審閱 Pull Request (PR) 時，在各種情況下您可能會執行以下操作
- 建議貢獻者合併他們的提交。
- 為貢獻者合併提交。
- 建議貢獻者暫時不要合併。
- 防止合併。
建議貢獻者合併提交：新的貢獻者可能不知道他們應該在 Pull Request (PR) 中合併提交。如果是這種情況，請建議他們這樣做，提供有用的資訊連結，並表示如果他們需要協助，可以安排協助。一些有用的連結
- 開啟 Pull Request 並合併您的提交，適用於文件貢獻者。
- GitHub 工作流程，包含圖表，適用於開發人員。
為貢獻者合併提交：如果貢獻者可能難以合併提交，或者有時間壓力需要合併 PR，您可以為他們執行合併
- kubernetes/website 儲存庫已配置為允許 Pull Request 合併時進行合併提交。只需選擇合併提交 (Squash commits) 按鈕即可。
- 在 PR 中，如果貢獻者啟用維護者管理 PR，您可以合併他們的提交，並使用結果更新他們的分支 (fork)。在您合併之前，建議他們儲存並推送他們最新的變更到 PR。在您合併之後，建議他們將合併後的提交拉取 (pull) 到他們的本地副本。
- 您可以讓 GitHub 使用標籤來合併提交，以便 Tide / GitHub 執行合併，或者在您合併 PR 時點擊合併提交 (Squash commits) 按鈕。
建議貢獻者避免合併提交
- 如果某個提交做了錯誤或不明智的事情，而最後一個提交還原了這個錯誤，請不要合併提交。即使 GitHub 上 PR 中的「檔案變更 (Files changed)」標籤和 Netlify 預覽看起來都沒問題，合併這個 PR 可能會為其他人造成 rebase 或合併衝突。請根據您的判斷介入以避免其他貢獻者面臨這種風險。
永遠不要合併
- 如果您要啟動本地化或發布新版本的文件，您正在合併一個不是來自使用者分支 (fork) 的分支，永遠不要合併提交。不合併提交至關重要，因為您必須維護這些檔案的提交歷史記錄。