面向审批人和审查人的审查
SIG Docs 审查人 和 审批人 在审查变更时会做一些额外的事情。
每周都会有一位特定的文档审批人自愿对拉取请求进行分类和审查。此人就是本周的“拉取请求管理员”。有关更多信息，请参阅拉取请求管理员调度表。要成为拉取请求管理员，请参加每周的 SIG Docs 会议并自愿报名。即使您不在本周的日程安排中，您仍然可以审查尚未进行积极审查的拉取请求 (PR)。
除了轮换之外，机器人还会根据受影响文件的负责人为拉取请求分配审查人和审批人。
审查拉取请求
Kubernetes 文档遵循Kubernetes 代码审查流程。
审查拉取请求中描述的所有内容均适用，但审查人和审批人也应执行以下操作
根据需要，使用
/assignProw 命令将特定的审查人分配给拉取请求。在请求代码贡献者进行技术审查时，这一点尤为重要。注意
查看 Markdown 文件顶部前言中的reviewers字段，以了解谁可以提供技术审查。在适用时使用 GitHub 的**请求更改**选项，向拉取请求作者建议更改。
如果您的建议得到实施，请使用
/approve或/lgtmProw 命令更改您在 GitHub 中的审查状态。
提交到他人的拉取请求中
留下拉取请求评论很有帮助，但有时您可能需要提交到他人的拉取请求中。
除非他人明确要求您这样做，或者您想恢复一个长期被遗弃的拉取请求，否则不要“接管”他人的工作。虽然这在短期内可能更快，但它会剥夺他人贡献的机会。
您使用的流程取决于您是需要编辑拉取请求范围内已有的文件，还是需要编辑拉取请求尚未触及的文件。
如果满足以下任一条件，您将无法提交到他人的拉取请求中
如果拉取请求作者将其分支直接推送到https://github.com/kubernetes/website/ 存储库。只有具有推送权限的审查人才可以提交到其他用户的拉取请求。
注意
鼓励作者在下一次打开拉取请求之前将其分支推送到他们的分支。拉取请求作者明确禁止审批人进行编辑。
用于审查的 Prow 命令
Prow 是基于 Kubernetes 的 CI/CD 系统，它针对拉取请求 (PR) 运行作业。Prow 支持聊天机器人风格的命令来处理 Kubernetes 组织中的 GitHub 操作，例如添加和删除标签、关闭问题和分配审批人。使用 /<命令名称> 格式将 Prow 命令作为 GitHub 评论输入。
审查人和审批人最常用的 prow 命令是
| Prow 命令 | 角色限制 | 描述 |
|---|---|---|
/lgtm | 组织成员 | 表示您已完成对拉取请求的审查，并对更改感到满意。 |
/approve | 审批人 | 批准合并拉取请求。 |
/assign | 任何人 | 分配人员来审查或批准拉取请求 |
/close | 组织成员 | 关闭问题或拉取请求。 |
/hold | 任何人 | 添加 do-not-merge/hold 标签，表示无法自动合并拉取请求。 |
/hold cancel | 任何人 | 删除 do-not-merge/hold 标签。 |
要查看您可以在拉取请求中使用的命令，请参阅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 经验很少的人。有关更多信息，请参阅需要帮助和良好的第一个问题标签。 |
您可以自行决定接手某个问题并为其提交拉取请求（特别是如果它很快或与您已经在做的工作相关）。
如果您对问题的分类有任何疑问，请在 Slack 上的 #sig-docs 或kubernetes-sig-docs 邮件列表中提问。
添加和删除问题标签
要添加标签，请使用以下格式之一发表评论
/<要添加的标签>（例如，/good-first-issue）/<标签类别> <要添加的标签>（例如，/triage needs-information或/language ja）
要删除标签，请使用以下格式之一发表评论
/remove-<要删除的标签>（例如，/remove-help）/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 可能会为其他人创建变基或合并冲突。请根据您的判断进行干预，以避免对其他贡献者造成风险。
永远不要压缩
- 如果您正在启动本地化或发布新版本的文档，并且您正在合并的不是来自用户分支的分支，请*永远不要压缩提交*。不压缩至关重要，因为您必须维护这些文件的提交历史记录。