审批者和审核者审查

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 之前将他们的分支推送到他们的 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 经验很少的人。有关更多信息，请参阅 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 经常遇到以下类型的问题，足以记录如何处理它们。

重复问题

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

死链接问题

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

博客问题

我们预计 Kubernetes 博客条目会随着时间的推移而过时。因此，我们仅维护一年以下的博客条目。如果问题与一年以上的博客条目相关，您通常应该关闭问题而不进行修复。

您可以将链接发送到文章更新和维护作为您在关闭 PR 时发送的消息的一部分。

如果适用，可以例外。

支持请求或代码错误报告

一些文档问题实际上是底层代码的问题，或者当某个东西（例如教程）无法工作时寻求帮助。对于与文档无关的问题，请使用 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.

Squashing（合并提交）

作为审核者，在审查拉取请求 (PR) 时，您可能会遇到以下各种情况

建议贡献者合并他们的提交。
为贡献者合并提交。
建议贡献者暂时不要合并提交。
阻止合并提交。

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

打开拉取请求和合并您的提交，适用于文档贡献者。
GitHub 工作流程，包括图表，适用于开发者。

为贡献者合并提交：如果贡献者可能难以合并提交，或者合并 PR 有时间压力，您可以为他们执行合并操作

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

建议贡献者避免合并提交

如果一个提交做了破坏性或不明智的事情，而最后一个提交撤消了此错误，请不要合并提交。尽管 GitHub 上 PR 中的“文件更改”选项卡和 Netlify 预览都将显示正常，但合并此 PR 可能会为其他用户创建 rebase 或合并冲突。根据需要进行干预，以避免对其他贡献者的风险。

绝不允许合并提交

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

最后修改时间：2025 年 3 月 13 日上午 10:41 PST：添加博客贡献指南 (815a75d025)