面向审批者和审查者的审查

SIG Docs 审查者和审批者在审查变更时会做一些额外的事情。

每周都会有一位指定的文档审批者自愿对拉取请求进行分类和审查。此人就是本周的“PR 管理员”。有关更多信息，请参阅 PR 管理员调度程序。要成为 PR 管理员，请参加 SIG Docs 每周会议并自愿报名。即使您不在本周的日程安排中，您仍然可以审查尚未进行主动审查的拉取请求 (PR)。

除了轮换之外，机器人还会根据受影响文件的所有者为 PR 分配审查者和审批者。

审查 PR

Kubernetes 文档遵循 Kubernetes 代码审查流程。

审查拉取请求中描述的所有内容均适用，但审查者和审批者还应执行以下操作

根据需要使用 /assign Prow 命令将特定审查者分配给 PR。在请求代码贡献者进行技术审查时，这一点尤其重要。
注意
查看 Markdown 文件顶部前言中的 reviewers 字段，以了解谁可以提供技术审查。
确保 PR 遵循内容和样式指南；如果 PR 不符合指南，请将作者链接到指南的相关部分。
在适用的情况下使用 GitHub **请求更改** 选项向 PR 作者建议更改。
如果您的建议已实施，请使用 /approve 或 /lgtm Prow 命令更改您在 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 操作，例如添加和删除标签、关闭问题和分配审批者。使用 /<command-name> 格式将 Prow 命令作为 GitHub 评论输入。

审查者和审批者最常用的 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 Issue 过滤器可查找可能需要分类的问题。

问题分类

验证问题
- 确保问题与网站文档相关。通过回答问题或将报告者指向资源可以快速关闭某些问题。有关详细信息，请参阅支持请求或代码错误报告部分。
- 评估问题是否有价值。
- 如果问题没有足够的详细信息可操作或模板未充分填写，请添加 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 经验很少的人。有关更多信息，请参阅需要帮助和良好的首个问题标签。

您可以自行决定负责某个问题并为此提交 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 天无活动后，问题将自动标记为陈旧。如果未使用 `/remove-lifecycle stale` 命令手动恢复生命周期，则该问题将自动关闭。
`lifecycle/frozen`	具有此标签的问题在 90 天不活动后不会变为陈旧。用户手动将此标签添加到需要保持打开状态超过 90 天的问题，例如带有 `priority/important-longterm` 标签的问题。

处理特殊问题类型

SIG Docs 经常遇到以下类型的问题，足以记录如何处理它们。

重复问题

如果单个问题有多个未解决的问题，请将它们合并成一个问题。您应该决定保留哪个问题打开（或打开一个新问题），然后移至所有相关信息并链接相关问题。最后，使用 triage/duplicate 标记描述相同问题的所有其他问题并将其关闭。只处理一个问题可以减少混淆并避免对同一问题进行重复工作。

死链接问题

如果死链接问题出现在 API 或 kubectl 文档中，请为其分配 /priority critical-urgent，直到问题完全理解为止。将所有其他死链接问题分配给 /priority important-longterm，因为它们必须手动修复。

博客问题

我们预计 Kubernetes 博客条目会随着时间的推移而过时。因此，我们只维护不到一年的博客条目。如果问题与一年以上的博客条目相关，请在不修复的情况下关闭该问题。

支持请求或代码错误报告

某些文档问题实际上是底层代码的问题，或者是在某些内容（例如教程）不起作用时请求帮助。对于与文档无关的问题，请使用 kind/support 标签关闭问题，并使用注释将请求者定向到支持场所（Slack、Stack Overflow），并在相关时定向到用于提交功能错误问题的存储库（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.

压缩

作为审批者，当您审查拉取请求 (PR) 时，在各种情况下您可能会执行以下操作

建议贡献者压缩他们的提交。
为贡献者压缩提交。
建议贡献者暂时不要压缩。
防止压缩。

建议贡献者压缩提交： 新的贡献者可能不知道应该在他们的拉取请求 (PR) 中压缩提交。如果是这种情况，建议他们这样做，提供有用信息的链接，并在他们需要时提供帮助。一些有用的链接：

针对文档贡献者的打开拉取请求并压缩提交。
针对开发人员的GitHub 工作流程，包括图表。

为贡献者压缩提交：如果贡献者在压缩提交方面遇到困难，或者合并 PR 有时间压力，您可以为他们执行压缩。

kubernetes/website 仓库已配置为允许在拉取请求合并时压缩提交。只需选择“压缩提交”按钮即可。
在 PR 中，如果贡献者允许维护者管理 PR，您可以压缩他们的提交并使用结果更新他们的分支。在压缩之前，建议他们保存并将最新的更改推送到 PR。压缩后，建议他们将压缩后的提交拉取到他们的本地克隆。
您可以通过使用标签让 GitHub 压缩提交，以便 Tide / GitHub 执行压缩，或者在合并 PR 时单击“压缩提交”按钮。

建议贡献者避免压缩提交的情况：

如果一个提交做了错误或不明智的事情，而最后一个提交回滚了这个错误，请不要压缩提交。即使 GitHub 上 PR 中的“已更改文件”选项卡和 Netlify 预览看起来都没问题，合并此 PR 也可能会为其他人创建变基或合并冲突。在您认为合适的情况下进行干预，以避免其他贡献者面临这种风险。

永远不要压缩提交的情况：

如果您正在启动本地化或发布新版本的文档，并且您正在合并的不是来自用户分支的分支，则*永远不要压缩提交*。不压缩提交至关重要，因为您必须维护这些文件的提交历史记录。

上次修改时间：2023 年 3 月 27 日晚上 8:43（太平洋标准时间）：调整 for-approvers.md 中的行和缩进 (0bc196344b)