针对审批者和审阅者进行审查

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

每周，特定的文档审批者会自愿对拉取请求进行分类和审查。这个人是本周的“PR 处理者”。有关更多信息，请参阅 PR 处理者调度程序。要成为 PR 处理者，请参加每周的 SIG 文档会议并自愿参加。即使你不在本周的日程安排中，你仍然可以审查尚未被积极审查的拉取请求 (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 中

如果 PR 作者将他们的分支直接推送到 https://github.com/kubernetes/website/ 存储库。只有具有推送访问权限的审阅者才能提交到其他用户的 PR。
注意
鼓励作者在下次打开 PR 之前将他们的分支推送到他们的 fork 中。
PR 作者明确禁止审批者进行编辑。

用于审查的 Prow 命令

Prow 是基于 Kubernetes 的 CI/CD 系统，它针对拉取请求 (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 问题过滤器查找可能需要分类的问题。

分类问题

验证问题
- 确保问题与网站文档有关。某些问题可以通过回答问题或将报告者指向资源来快速关闭。有关详细信息，请参阅支持请求或代码错误报告部分。
- 评估问题是否有意义。
- 如果问题没有足够的细节无法执行，或者模板没有充分填写，请添加 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，您可以压缩他们的提交并将结果更新到他们的 fork。在压缩之前，请建议他们将最新的更改保存并推送到 PR。压缩后，请建议他们将压缩后的提交拉取到他们的本地克隆。
您可以通过使用标签让 GitHub 压缩提交，以便 Tide/GitHub 执行压缩，或者在合并 PR 时单击压缩提交按钮。

建议贡献者避免压缩。

如果某个提交导致了错误或不合理的更改，而最后一个提交撤销了此错误，请不要压缩这些提交。即使 GitHub 上的 PR 中的“已修改文件”选项卡和 Netlify 预览都显示正常，合并此 PR 可能会为其他用户创建变基或合并冲突。请根据需要进行干预以避免对其他贡献者造成此风险。

永远不要压缩。

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

上次修改时间：2023 年 3 月 27 日下午 8:43 PST：调整行并修复 for-approvers.md 中的缩进 (0bc196344b)