为审批者和审阅者进行审阅

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）