為審批者和審閱者進行審閱

SIG Docs 的審閱者和審批者在審閱更改時會做一些額外的操作。

每週，一位指定的文件審批者會自願負責分類和審閱 pull requests。這個人是本週的“PR 整理者”。有關更多資訊，請參閱 PR 整理者排程表。要成為 PR 整理者，請參加每週的 SIG Docs 會議並報名。即使您本週不在計劃中，您仍然可以審閱尚未被積極審閱的 pull requests (PR)。

除了輪換之外，一個機器人會根據受影響檔案的所有者為 PR 分配審閱者和審批者。

審閱 PR

Kubernetes 文件遵循 Kubernetes 程式碼審閱流程。

《審閱 pull request》中描述的所有內容都適用，但審閱者和審批者還應該執行以下操作：

根據需要，使用 Prow 的 /assign 命令將特定審閱者分配給 PR。這對於請求程式碼貢獻者的技術審閱尤為重要。
注意
檢視 Markdown 檔案頂部 front-matter 中的 reviewers 欄位，以瞭解誰可以提供技術審閱。
確保 PR 符合內容和風格指南；如果 PR 不符合要求，請將作者連結到相關指南部分。
在適用時，使用 GitHub 的 **Request Changes** 選項向 PR 作者建議更改。
如果您的建議已實施，請使用 Prow 的 /approve 或 /lgtm 命令更改您在 GitHub 中的審閱狀態。

提交到另一個人的 PR

留下 PR 評論很有幫助，但有時您可能需要提交到另一個人的 PR。

除非另一方明確要求，或者您想重新啟用一個長期被放棄的 PR，否則請勿“接管”他人的工作。雖然短期內可能更快，但這剝奪了對方貢獻的機會。

您使用的流程取決於您是需要編輯 PR 範圍內的檔案，還是 PR 尚未觸及的檔案。

如果出現以下任一情況，您將無法提交到他人的 PR：

如果 PR 作者直接將其分支推送到 https://github.com/kubernetes/website/ 儲存庫。只有具有推送訪問許可權的審閱者才能提交到另一個使用者的 PR。
注意
鼓勵作者下次在開啟 PR 之前，先將其分支推送到他們的 fork。
PR 作者明確不允許審批者進行編輯。

審閱的 Prow 命令

Prow 是基於 Kubernetes 的 CI/CD 系統，它針對 pull requests (PR) 執行作業。Prow 啟用類似聊天機器人的命令，以處理 Kubernetes 組織中的 GitHub 操作，例如新增和刪除標籤、關閉問題以及分配審批者。使用 /<command-name> 格式在 GitHub 註釋中輸入 Prow 命令。

審閱者和審批者最常用的 Prow 命令是：

審閱的 Prow 命令
Prow 命令	角色限制	描述
`/lgtm`	組織成員	表示您已完成 PR 的審閱，並對更改感到滿意。
`/approve`	審批者	批准 PR 以便合併。
`/assign`	任何人	將某人分配給 PR 以進行審閱或批准
`/close`	組織成員	關閉問題或 PR。
`/hold`	任何人	新增 `do-not-merge/hold` 標籤，表示 PR 不能自動合併。
`/hold cancel`	任何人	移除 `do-not-merge/hold` 標籤。

要檢視您可以在 PR 中使用的命令，請參閱 Prow 命令參考。

分類和歸類問題

總的來說，SIG Docs 遵循 Kubernetes 問題分類流程，並使用相同的標籤。

此 GitHub 問題過濾器會查詢可能需要分類的問題。

對問題進行分類

驗證問題
- 確保問題與網站文件相關。有些問題可以透過回答問題或指向報告者資源來快速關閉。有關詳細資訊，請參閱支援請求或程式碼 Bug 報告部分。
- 評估問題是否有價值。
- 如果問題沒有足夠的細節以便採取行動，或者模板沒有充分填寫，則新增 triage/needs-information 標籤。
- 如果問題同時帶有 lifecycle/stale 和 triage/needs-information 標籤，則關閉該問題。
新增優先順序標籤（問題分類指南詳細定義了優先順序標籤）。

問題標籤
標籤	描述
`priority/critical-urgent`	立即處理。
`priority/important-soon`	在 3 個月內處理。
`priority/important-longterm`	在 6 個月內處理。
`priority/backlog`	可無限期推遲。有資源可用時處理。
`priority/awaiting-more-evidence`	佔位符，用於可能的好問題，以免丟失。
`help` 或 `good first issue`	適合對 Kubernetes 或 SIG Docs 經驗非常少的人。有關更多資訊，請參閱 Help Wanted 和 Good First Issue 標籤。

根據您的判斷，負責一個問題，併為此提交一個 PR（特別是如果它很快或與您正在進行的工作相關）。

如果您對分類問題有疑問，請在 Slack 的 #sig-docs 頻道或 kubernetes-sig-docs 郵件列表中提問。

新增和刪除問題標籤

要新增標籤，請留下以下格式的註釋：

/<label-to-add>（例如，/good-first-issue）
/<label-category> <label-to-add>（例如，/triage needs-information 或 /language ja）

要移除標籤，請留下以下格式的註釋：

/remove-<label-to-remove>（例如，/remove-help）
/remove-<label-category> <label-to-remove>（例如，/remove-triage needs-information）

在這兩種情況下，標籤必須已存在。如果您嘗試新增不存在的標籤，該命令將被靜默忽略。

有關所有標籤的列表，請參閱網站儲存庫的“標籤”部分。並非所有標籤都由 SIG Docs 使用。

問題生命週期標籤

問題通常會快速開啟和關閉。但是，有時一個問題在開啟後處於不活動狀態。其他時候，一個問題可能需要保持開啟狀態超過 90 天。

問題生命週期標籤
標籤	描述
`lifecycle/stale`	在 90 天內沒有活動後，問題會自動標記為 stale。如果未透過 `/remove-lifecycle stale` 命令手動撤銷生命週期，該問題將自動關閉。
`lifecycle/frozen`	帶有此標籤的問題在 90 天不活動後不會變 stale。使用者手動將此標籤新增到需要比 90 天更長開放時間的問題，例如帶有 `priority/important-longterm` 標籤的問題。

處理特殊型別的問題

SIG Docs 經常遇到以下型別的問題，因此記錄瞭如何處理它們。

重複問題

如果一個問題有多個開放的 issue，請將它們合併為一個 issue。您應該決定保留哪個 issue（或開啟一個新 issue），然後遷移所有相關資訊並連結相關的 issue。最後，為描述相同問題的所有其他 issue 標記 triage/duplicate 並關閉它們。只有一個 issue 要處理可以減少混淆並避免對同一問題進行重複工作。

死連結問題

如果死連結問題位於 API 或 kubectl 文件中，請將其分配 /priority critical-urgent，直到完全理解問題。為所有其他死連結問題分配 /priority important-longterm，因為它們必須手動修復。

部落格問題

我們期望 Kubernetes Blog 中的條目隨著時間的推移而過時。因此，我們只維護一年內的新部落格條目。如果一個問題與一年以上的部落格條目相關，您通常應該關閉該問題而不進行修復。

在關閉 PR 時傳送的訊息中，您可以傳送一個連結到文章更新和維護。

如果有相關的理由，允許例外。

支援請求或程式碼 Bug 報告

一些文件問題實際上是底層程式碼的問題，或者是在教程等內容不起作用時請求幫助。對於與文件無關的問題，使用 kind/support 標籤關閉該問題，並附上一個註釋，將請求者引導至支援渠道（Slack、Stack Overflow），如果相關，則指導他們前往相應儲存庫提交 Bug 報告（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.

程式碼 Bug 報告的示例回覆

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.

合併提交

作為審批者，當您審閱 pull requests (PR) 時，在以下各種情況下，您可能會執行以下操作：

建議貢獻者合併他們的提交。
為貢獻者合併提交。
建議貢獻者暫時不要合併。
阻止合併。

建議貢獻者合併提交：新貢獻者可能不知道他們應該合併 pull requests (PR) 中的提交。如果是這種情況，請建議他們這樣做，提供有用資訊的連結，並在他們需要時提供幫助。一些有用的連結：

文件貢獻者開啟 pull requests 和合並您的提交。
開發者的 GitHub 工作流，包括圖表。

為貢獻者合併提交：如果貢獻者在合併提交方面可能遇到困難，或者合併 PR 有時間壓力，您可以替他們執行合併：

kubernetes/website 倉庫已配置為允許合併 PR 時進行合併提交。只需選擇 Squash commits 按鈕。
在 PR 中，如果貢獻者允許維護者管理 PR，您可以合併他們的提交併將結果更新到他們的 fork。在合併之前，建議他們儲存並推送到 PR 的最新更改。合併後，建議他們將合併的提交拉取到他們的本地克隆。
您可以使用標籤讓 Tide / GitHub 執行合併，或者在合併 PR 時單擊 Squash commits 按鈕，讓 GitHub 合併提交。

建議貢獻者避免合併

如果一個提交做了錯誤或不明智的事情，而最後一個提交撤銷了這個錯誤，那麼不要合併這些提交。即使 GitHub 上的 PR 和 Netlify 預覽中的“Files changed”選項卡看起來都 OK，合併此 PR 也可能為其他人造成 rebase 或 merge conflicts。請根據情況進行干預，以避免給其他貢獻者帶來風險。

絕不合並

如果您要啟動本地化或釋出新版本的文件，您正在合併一個非使用者 fork 的分支，*切勿合併提交*。不合並至關重要，因為您必須保留這些檔案的提交歷史。

最後修改時間：2025 年 3 月 13 日上午 10:41 PST：新增部落格貢獻指南（815a75d025）