kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #22246 from tengqm/sync-zh-contrib-5 

[zh] Sync contribution guidelines (5)
pull/22467/head
Kubernetes Prow Robot 2020-07-12 02:50:01 -07:00 committed by GitHub
parent 38d8c863c3 7eef8e73ba
commit b3c4441f13
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 651 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
content/zh/docs/contribute/review/_index.md Normal file
View File

@ -0,0 +1,17 @@
---
title: 评阅变更
weight: 30
---
<!--
title: Reviewing changes
weight: 30
-->
<!-- overview -->
<!--
This section describes how to review content.
-->
本节描述如何对内容进行评阅。
<!-- body -->

432
content/zh/docs/contribute/review/for-approvers.md Normal file
View File

@ -0,0 +1,432 @@
---
title: 评阅人和批准人文档
linktitle: 评阅人和批准人
slug: for-approvers
content_type: concept
weight: 20
---
<!--
title: Reviewing for approvers and reviewers
linktitle: For approvers and reviewers
slug: for-approvers
content_type: concept
weight: 20
-->
<!-- overview -->
<!--
SIG Docs [Reviewers](/docs/contribute/participating/#reviewers) and [Approvers](/docs/contribute/participating/#approvers) do a few extra things when reviewing a change.
Every week a specific docs approver volunteers to triage
and review pull requests. This
person is the "PR Wrangler" for the week. See the
[PR Wrangler scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers) for more information. To become a PR Wrangler, attend the weekly SIG Docs meeting and volunteer. Even if you are not on the schedule for the current week, you can still review pull
requests (PRs) that are not already under active review.
In addition to the rotation, a bot assigns reviewers and approvers
for the PR based on the owners for the affected files.
-->
SIG Docs [评阅人（Reviewers）](/docs/contribute/participating/#reviewers)
和[批准人（Approvers）](/docs/contribute/participating/#approvers)
在对变更进行评审时需要做一些额外的事情。
每周都有一个特定的文档批准人自愿负责对 PR 进行分类和评阅。
此角色称作该周的“PR 管理者（PR Wrangler）”。
相关信息可参考 [PR Wrangler 排班表](https://github.com/kubernetes/website/wiki/PR-Wranglers)。
要成为 PR Wangler，需要参加每周的 SIG Docs 例会，并自愿报名。
即使当前这周排班没有轮到你，你仍可以评阅那些尚未被积极评阅的 PRs。
除了上述的轮值安排，后台机器人也会为基于所影响的文件来为 PR
指派评阅人和批准人。
<!-- body -->
<!--
## Reviewing a PR
Kubernetes documentation follows the [Kubernetes code review process](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process).
Everything described in [Reviewing a pull request](/docs/contribute/review/reviewing-prs) applies, but Reviewers and Approvers should also do the following:
-->
## 评阅 PR
Kubernetes 文档遵循 [Kubernetes 代码评阅流程](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process)。
[评阅 PR](/docs/contribute/review/reviewing-prs) 文档中所描述的所有规程都适用，
不过评阅人和批准人还要做以下工作：
<!--
- Using the `/assign` Prow command to assign a specific reviewer to a PR as needed. This is extra important
when it comes to requesting technical review from code contributors.
{{< note >}}
Look at the `reviewers` field in the front-matter at the top of a Markdown file to see who can
provide technical review.
{{< /note >}}
- Making sure the PR follows the [Content](/docs/contribute/style/content-guide/) and [Style](/docs/contribute/style/style-guide/) guides; link the author to the relevant part of the guide(s) if it doesn't.
- Using the GitHub **Request Changes** option when applicable to suggest changes to the PR author.
- Changing your review status in GitHub using the `/approve` or `/lgtm` Prow commands, if your suggestions are implemented.
-->
- 根据需要使用 Prow 命令 `/assign` 指派特定的评阅人。如果某个 PR
需要来自代码贡献者的技术审核时，这一点非常重要。
{{< note >}}
你可以查看 Markdown 文件的文件头，其中的 `reviewers` 字段给出了哪些人可以为文档提供技术审核。
{{< /note >}}
- 确保 PR 遵从[内容指南](/docs/contribute/style/content-guide/)和[样式指南](/docs/contribute/style/style-guide/)；
如果 PR 没有达到要求，指引作者阅读指南中的相关部分。
- 适当的时候使用 GitHub **Request Changes** 选项，建议 PR 作者实施所建议的修改。
- 当你所提供的建议被采纳后，在 GitHub 中使用 `/approve` 或 `/lgtm` Prow 命令，改变评审状态。
<!--
## Commit into another person's PR
Leaving PR comments is helpful, but there might be times when you need to commit
into another person's PR instead.
Do not "take over" for another person unless they explicitly ask
you to, or you want to resurrect a long-abandoned PR. While it may be faster
in the short term, it deprives the person of the chance to contribute.
The process you use depends on whether you need to edit a file that is already
in the scope of the PR, or a file that the PR has not yet touched.
-->
## 提交到他人的 PR
为 PR 留下评语是很有用的，不过有时候你需要向他人的 PR 提交内容。
除非他人明确请求你的帮助或者你希望重启一个被放弃很久的 PR，不要“接手”他人的工作。
尽管短期看来这样做可以提高效率，但是也剥夺了他人提交贡献的机会。
你所要遵循的流程取决于你需要编辑已经在 PR 范畴的文件，还是 PR 尚未触碰的文件。
<!--
You can't commit into someone else's PR if either of the following things is
true:
- If the PR author pushed their branch directly to the
[https://github.com/kubernetes/website/](https://github.com/kubernetes/website/)
repository. Only a reviewer with push access can commit to another user's PR.
{{< note >}}
Encourage the author to push their branch to their fork before
opening the PR next time.
{{< /note >}}
- The PR author explicitly disallows edits from approvers.
-->
如果处于下列情况之一，你不可以向别人的 PR 提交内容：
- 如果 PR 作者是直接将自己的分支提交到
[https://github.com/kubernetes/website/](https://github.com/kubernetes/website/)
仓库。只有具有推送权限的评阅人才可以向他人的 PR 提交内容。
{{< note >}}
我们应鼓励作者下次将分支推送到自己的克隆副本之后再发起 PR。
{{< /note >}}
- PR 作者明确地禁止批准人编辑他/她的 PR。
<!--
## Prow commands for reviewing
[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md) is
the Kubernetes-based CI/CD system that runs jobs against pull requests (PRs). Prow
enables chatbot-style commands to handle GitHub actions across the Kubernetes
organization, like [adding and removing labels](#adding-and-removing-issue-labels), closing issues, and assigning an approver. Enter Prow commands as GitHub comments using the `/<command-name>` format.
The most common prow commands reviewers and approvers use are:
-->
## 评阅用的 Prow 命令
[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md)
是基于 Kubernetes 的 CI/CD 系统，基于拉取请求（PR）的触发运行不同任务。
Prow 使得我们可以使用会话机器人一样的命令跨整个 Kubernetes 组织处理 GitHub
动作，例如[添加和删除标签](#adding-and-removing-issue-labels)、关闭 Issues
以及指派批准人等等。你可以使用 `/<命令名称>` 的形式以 GitHub 评论的方式输入
Prow 命令。
评阅人和批准人最常用的 Prow 命令有：
<!--
{{< table caption="Prow commands for reviewing" >}}
Prow Command | Role Restrictions | Description
:------------|:------------------|:-----------
`/lgtm` | Anyone, but triggers automation if a Reviewer or Approver uses it | Signals that you've finished reviewing a PR and are satisfied with the changes.
`/approve` | Approvers | Approves a PR for merging.
`/assign` | Reviewers or Approvers | Assigns a person to review or approve a PR
`/close` | Reviewers or Approvers | Closes an issue or PR.
`/hold` | Anyone | Adds the `do-not-merge/hold` label, indicating the PR cannot be automatically merged.
`/hold cancel` | Anyone | Removes the `do-not-merge/hold` label.
{{< /table >}}
See [the Prow command reference](https://prow.k8s.io/command-help) to see the full list
of commands you can use in a PR.
-->
{{< table caption="评阅用 Prow 命令" >}}
Prow 命令 | 角色限制 | 描述
:------------|:------------------|:-----------
`/lgtm` | 任何人均可使用，但只有评阅人和批准人使用此命令的时候才会触发自动化操作 | 用来表明你已经完成 PR 的评阅并对其所作变更表示满意
`/approve` | 批准人 | 批准某 PR 可以合并
`/assign` |评阅人或批准人 | 指派某人来评阅或批准某 PR
`/close` | 评阅人或批准人 | 关闭 Issue 或 PR
`/hold` | 任何人 | 添加 `do-not-merge/hold` 标签，用来表明 PR 不应被自动合并
`/hold cancel` | 任何人 | 去掉 `do-not-merge/hold` 标签
{{< /table >}}
请参考 [Prow 命令指南](https://prow.k8s.io/command-help)，了解你可以在 PR
中使用的命令的完整列表。
<!--
## Triage and categorize issues
In general, SIG Docs follows the [Kubernetes issue triage](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md) process and uses the same labels.
This GitHub Issue [filter](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc)
finds issues that might need triage.
-->
## 对 Issue 进行诊断和分类
一般而言，SIG Docs 遵从 [Kubernetes issue 判定](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md) 流程并使用相同的标签。
此 GitHub Issue
[过滤器](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc)
可以用来查找需要评判的 Issues。
<!--
### Triaging an issue
1. Validate the issue
- Make sure the issue is about website documentation. Some issues can be closed quickly by
answering a question or pointing the reporter to a resource. See the
[Support requests or code bug reports](#support-requests-or-code-bug-reports) section for details.
- Assess whether the issue has merit.
- Add the `triage/needs-information` label if the issue doesn't have enough
detail to be actionable or the template is not filled out adequately.
- Close the issue if it has both the `lifecycle/stale` and `triage/needs-information` labels.
-->
### 评判 Issue {#triaging-an-issue}
1. 验证 Issue 的合法性
- 确保 Issue 是关于网站文档的。某些 Issue 可以通过回答问题或者为报告者提供
资源链接来快速关闭。
参考[请求支持或代码缺陷报告](#support-requests-or-code-bug-reports)
节以了解详细信息。
- 评估该 Issue 是否有价值。
- 如果 Issue 缺少足够的细节以至于无法采取行动，或者报告者没有通过模版提供
足够信息，可以添加 `triage/needs-information` 标签。
- 如果 Issue 同时标注了 `lifecycle/stale` 和 `triage/needs-information`
标签，可以直接关闭。
<!--
2. Add a priority label (the
[Issue Triage Guidelines](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority) define priority labels in detail)
< table caption="Issue labels" >
Label | Description
:------------|:------------------
`priority/critical-urgent` | Do this right now.
`priority/important-soon` | Do this within 3 months.
`priority/important-longterm` | Do this within 6 months.
`priority/backlog` | Deferrable indefinitely. Do when resources are available.
`priority/awaiting-more-evidence` | Placeholder for a potentially good issue so it doesn't get lost.
`help` or `good first issue` | Suitable for someone with very little Kubernetes or SIG Docs experience. See [Help Wanted and Good First Issue Labels](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md) for more information.
At your discretion, take ownership of an issue and submit a PR for it
(especially if it's quick or relates to work you're already doing).
If you have questions about triaging an issue, ask in `#sig-docs` on Slack or
the [kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-->
2. 添加优先级标签（
[Issue 判定指南](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority)中有优先级标签的详细定义)
{{< table caption="Issue 标签" >}}
标签 | 描述
:------------|:------------------
`priority/critical-urgent` | 应马上处理
`priority/important-soon` | 应在 3 个月内处理
`priority/important-longterm` | 应在 6 个月内处理
`priority/backlog` | 可无限期地推迟，可在人手充足时处理
`priority/awaiting-more-evidence` | 占位符，标示 Issue 可能是一个不错的 Issue，避免该 Issue 被忽略或遗忘
`help` or `good first issue` | 适合对 Kubernetes 或 SIG Docs 经验较少的贡献者来处理。更多信息可参考[需要帮助和入门候选 Issue 标签](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md)。
{{< /table >}}
基于你自己的判断，你可以选择某 Issue 来处理，为之发起 PR
（尤其是那些可以很快处理或与你已经在做的工作相关的 Issue）。
如果你对 Issue 评判有任何问题，可以在 `#sig-docs` Slack 频道或者
[kubernetes-sig-docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
中提问。
<!--
## Adding and removing issue labels
To add a label, leave a comment in one of the following formats:
- `/<label-to-add>` (for example, `/good-first-issue`)
- `/<label-category> <label-to-add>` (for example, `/triage needs-information` or `/language ja`)
To remove a label, leave a comment in one of the following formats:
- `/remove-<label-to-remove>` (for example, `/remove-help`)
- `/remove-<label-category> <label-to-remove>` (for example, `/remove-triage needs-information`)`
-->
## 添加和删除 Issue 标签 {#adding-and-removing-issue-labels}
要添加标签，可以用以下形式对 PR 进行评论：
- `/<要添加的标签>` （例如, `/good-first-issue`）
- `/<标签类别> <要添加的标签>` （例如，`/triage needs-information` 或 `/language ja`）
要移除某个标签，可以用以下形式对 PR 进行评论：
- `/remove-<要移除的标签>` （例如，`/remove-help`）
- `/remove-<标签类别> <要移除的标签>` （例如，`/remove-triage needs-information`）
<!--
In both cases, the label must already exist. If you try to add a label that does not exist, the command is
silently ignored.
For a list of all labels, see the [website repository's Labels section](https://github.com/kubernetes/website/labels). Not all labels are used by SIG Docs.
-->
在以上两种情况下，标签都必须合法存在。如果你尝试添加一个尚不存在的标签，
对应的命令会被悄悄忽略。
关于所有标签的完整列表，可以参考
[Website 仓库的标签节](https://github.com/kubernetes/website/labels)。
实际上，SIG Docs 并没有使用全部标签。
<!--
### Issue lifecycle labels
Issues are generally opened and closed quickly.
However, sometimes an issue is inactive after its opened.
Other times, an issue may need to remain open for longer than 90 days.
{{< table caption="Issue lifecycle labels" >}}
Label | Description
:------------|:------------------
`lifecycle/stale` | After 90 days with no activity, an issue is automatically labeled as stale. The issue will be automatically closed if the lifecycle is not manually reverted using the `/remove-lifecycle stale` command.
`lifecycle/frozen` | An issue with this label will not become stale after 90 days of inactivity. A user manually adds this label to issues that need to remain open for much longer than 90 days, such as those with a `priority/important-longterm` label.
{{< /table >}}
-->
### Issue 生命周期标签
Issues 通常都可以快速创建并关闭。
不过也有些时候，某个 Issue 被创建之后会长期处于非活跃状态。
也有一些时候，即使超过 90 天，某个 Issue 仍应保持打开状态。
{{< table caption="Issue 生命周期标签" >}}
标签 | 描述
:------------|:------------------
`lifecycle/stale` | 过去 90 天内某 Issue 无人问津，会被自动标记为停滞状态。如果 Issue 没有被 `/remove-lifecycle stale` 命令重置生命期，就会被自动关闭。
`lifecycle/frozen` | 对应的 Issue 即使超过 90 天仍无人处理也不会进入停滞状态。用户手动添加此标签给一些需要保持打开状态超过 90 天的 Issue，例如那些带有 `priority/important-longterm` 标签的 Issue。
{{< /table >}}
<!--
## Handling special issue types
SIG Docs encounters the following types of issues often enough to document how
to handle them.
### Duplicate issues
If a single problem has one or more issues open for it, combine them into a single issue.
You should decide which issue to keep open (or
open a new issue), then move over all relevant information and link related issues.
Finally, label all other issues that describe the same problem with
`triage/duplicate` and close them. Only having a single issue to work on reduces confusion
and avoids duplicate work on the same problem.
-->
## 处理特殊的 Issue 类型 {#handling-special-issue-types}
SIG Docs 常常会遇到以下类型的 Issue，因此对其处理方式描述如下。
### 重复的 Issue {#duplicate-issues}
如果针对同一个问题有不止一个打开的 Issue，可以将其合并为一个 Issue。
你需要决定保留哪个 Issue 为打开状态（或者重新登记一个新的 Issue），
然后将所有相关的信息复制过去并提供对关联 Issues 的链接。
最后，将所有其他描述同一问题的 Issue 标记为 `triage/duplicate` 并关闭之。
保持只有一个 Issue 待处理有助于减少困惑，避免在同一问题上发生重复劳动。
<!--
### Dead link issues
If the dead link issue is in the API or `kubectl` documentation, assign them `/priority critical-urgent` until the problem is fully understood. Assign all other dead link issues `/priority important-longterm`, as they must be manually fixed.
### Blog issues
We expect [Kubernetes Blog](https://kubernetes.io/blog/) entries to become
outdated over time. Therefore, we only maintain blog entries less than a year old.
If an issue is related to a blog entry that is more than one year old,
close the issue without fixing.
-->
### 失效链接 Issues {#dead-link-issues}
如果失效链接是关于 API 或者 `kubectl` 文档的，可以将其标记为
`/priority critical-urgent`，直到问题原因被弄清楚为止。
对于其他的链接失效问题，可以标记 `/priority important-longterm`，
因为这些问题都需要手动处理。
### 博客问题 {#blog-issues}
我们预期 [Kubernetes 博客](https://kubernetes.io/blog/)条目随着时间推移都会过期。
因此，我们只维护一年内的博客条目。
如果某个 Issue 是与某个超过一年的博客条目有关的，可以直接关闭
Issue，不必修复。
<!--
### Support requests or code bug reports
Some docs issues are actually issues with the underlying code, or requests for
assistance when something, for example a tutorial, doesn't work.
For issues unrelated to docs, close the issue with the `triage/support` label and a comment
directing the requester to support venues (Slack, Stack Overflow) and, if
relevant, the repository to file an issue for bugs with features (`kubernetes/kubernetes`
is a great place to start).
Sample response to a request for support:
-->
### 请求支持或代码缺陷报告 {#support-requests-or-code-bug-reports}
某些文档 Issues 实际上是关于底层代码的 Issue 或者在某方面请求协助的问题，
例如某个教程无法正常工作。
对于与文档无关的 Issues，关闭它并打上标签 `triage/support`，可以通过评论
告知请求者其他支持渠道（Slack、Stack Overflow）。
如果有相关的其他仓库，可以告诉请求者应该在哪个仓库登记与功能特性相关的 Issues
（通常会是 `kubernetes/kubernetes`）。
下面是对支持请求的回复示例：
```none
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](http://slack.k8s.io/). You can also search
resources like
[Stack Overflow](http://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.
```
<!--
Sample code bug report response:
-->
对代码缺陷 Issue 的回复示例：
```none
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.
```

202
content/zh/docs/contribute/review/reviewing-prs.md Normal file
View File

@ -0,0 +1,202 @@
---
title: 评阅 PRs
content_type: concept
main_menu: true
weight: 10
---
<!--
title: Reviewing pull requests
content_type: concept
main_menu: true
weight: 10
-->
<!-- overview -->
<!--
Anyone can review a documentation pull request. Visit the [pull requests](https://github.com/kubernetes/website/pulls) section in the Kubernetes website repository to see open pull requests.
Reviewing documentation pull requests is a
great way to introduce yourself to the Kubernetes community.
It helps you learn the code base and build trust with other contributors.
Before reviewing, it's a good idea to:
- Read the [content guide](/docs/contribute/style/content-guide/) and
[style guide](/docs/contribute/style/style-guide/) so you can leave informed comments.
- Understand the different [roles and responsibilities](/docs/contribute/participating/#roles-and-responsibilities) in the Kubernetes documentation community.
-->
任何人均可评阅文档的拉取请求。访问 Kubernetes 网站仓库的
[pull requests](https://github.com/kubernetes/website/pulls)
部分可以查看所有待处理的拉取请求（PRs）。
评阅文档 PR 是将你自己介绍给 Kubernetes 社区的一种很好的方式。
它将有助于你学习代码库并与其他贡献者之间建立相互信任关系。
在评阅之前，可以考虑：
- 阅读[内容指南](/docs/contribute/style/content-guide/)和
[样式指南](/docs/contribute/style/style-guide/)以便给出有价值的评论。
- 了解 Kubernetes 文档社区中不同的[角色和职责](/docs/contribute/participating/#roles-and-responsibilities)。
<!-- body -->
<!--
## Before you begin
Before you start a review:
- Read the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) and ensure that you abide by it at all times.
- Be polite, considerate, and helpful.
- Comment on positive aspects of PRs as well as changes.
- Be empathetic and mindful of how your review may be received.
- Assume good intent and ask clarifying questions.
- Experienced contributors, consider pairing with new contributors whose work requires extensive changes.
-->
## 准备工作 {#before-you-begin}
在你开始评阅之前：
- 阅读 [CNCF 行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)
确保你会始终遵从其中约定；
- 保持有礼貌、体谅他人，怀助人为乐初心；
- 评论时若给出修改建议，也要兼顾 PR 的积极方面
- 保持同理心，多考虑他人收到评阅意见时的可能反应
- 假定大家都是好意的，通过问问题澄清意图
- 如果你是有经验的贡献者，请考虑和新贡献者一起合作，提高其产出质量
<!--
## Review process
In general, review pull requests for content and style in English.
1. Go to
[https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls).
You see a list of every open pull request against the Kubernetes website and
docs.
2. Filter the open PRs using one or all of the following labels:
- `cncf-cla: yes` (Recommended): PRs submitted by contributors who have not signed the CLA cannot be merged. See [Sign the CLA](/docs/contribute/new-content/overview/#sign-the-cla) for more information.
- `language/en` (Recommended): Filters for english language PRs only.
- `size/<size>`: filters for PRs of a certain size. If you're new, start with smaller PRs.
Additionally, ensure the PR isn't marked as a work in progress. PRs using the `work in progress` label are not ready for review yet.
-->
## 评阅过程 {#review-process}
一般而言，应该使用英语来评阅 PR 的内容和样式。
1. 前往 [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)，
你会看到所有针对 Kubernetes 网站和文档的待处理 PRs。
2. 使用以下标签（组合）对待处理 PRs 进行过滤：
- `cncf-cla: yes` （建议）：由尚未签署 CLA 的贡献者所发起的 PRs 不可以合并。
参考[签署 CLA](/docs/contribute/new-content/overview/#sign-the-cla) 以了解更多信息。
- `language/en` （建议）：仅查看英语语言的 PRs。
- `size/<尺寸>`：过滤特定尺寸（规模）的 PRs。如果你刚入门，可以从较小的 PR 开始。
此外，确保 PR 没有标记为尚未完成（Work in Progress）。
包含 `work in progress` 的 PRs 通常还没准备好被评阅。
<!--
3. Once you've selected a PR to review, understand the change by:
- Reading the PR description to understand the changes made, and read any linked issues
- Reading any comments by other reviewers
- Clicking the **Files changed** tab to see the files and lines changed
- Previewing the changes in the Netlify preview build by scrolling to the PR's build check section at the bottom of the **Conversation** tab and clicking the **deploy/netlify** line's **Details** link.
4. Go to the **Files changed** tab to start your review.
1. Click on the `+` symbol beside the line you want to comment on.
2. Fill in any comments you have about the line and click either **Add single comment** (if you have only one comment to make) or **Start a review** (if you have multiple comments to make).
3. When finished, click **Review changes** at the top of the page. Here, you can add
add a summary of your review (and leave some positive comments for the contributor!),
approve the PR, comment or request changes as needed. New contributors should always
choose **Comment**.
-->
3. 选定 PR 评阅之后，可以通过以下方式理解所作的变更：
- 阅读 PR 描述以理解所作变更，并且阅读所有关联的 Issues
- 阅读其他评阅人给出的评论
- 点击 **Files changed** Tab 页面，查看被改变的文件和代码行
- 滚动到 **Conversation** Tab 页面下端的 PR 构建检查节区，点击
**deploy/netlify** 行的 **Details** 链接，预览 Netlify
预览构建所生成的结果
4. 前往 **Files changed** Tab 页面，开始你的评阅工作
1. 点击你希望评论的行旁边的 `+` 号
2. 填写你对该行的评论，之后或者选择**Add single comment** （如果你只有一条评论）
或者 **Start a review** （如果你还有其他评论要添加）
3. 评论结束时，点击页面顶部的 **Review changes**。这里你可以添加你的评论结语
（记得留下一些正能量的评论！）、根据需要批准 PR、请求作者进一步修改等等。
新手应该选择 **Comment**。
<!--
## Reviewing checklist
When reviewing, use the following as a starting point.
### Language and grammar
- Are there any obvious errors in language or grammar? Is there a better way to phrase something?
- Are there any complicated or archaic words which could be replaced with a simpler word?
- Are there any words, terms or phrases in use which could be replaced with a non-discriminatory alternative?
- Does the word choice and its capitalization follow the [style guide](/docs/contribute/style/style-guide/)?
- Are there long sentences which could be shorter or less complex?
- Are there any long paragraphs which might work better as a list or table?
-->
## 评阅清单 {#reviewing-checklist}
评阅 PR 时可以从下面的条目入手。
### 语言和语法 {#language-and-grammar}
- 是否存在明显的语言或语法错误？对某事的描述有更好的方式？
- 是否存在一些过于复杂晦涩的用词，本可以用简单词汇来代替？
- 是否有些用词、术语或短语可以用不带歧视性的表达方式代替？
- 用词和大小写方面是否遵从了[样式指南](/docs/contribute/style/style-guide/)？
- 是否有些句子太长，可以改得更短、更简单？
- 是否某些段落过长，可以考虑使用列表或者表格来表达？
<!--
### Content
- Does similar content exist elsewhere on the Kubernetes site?
- Does the content excessively link to off-site, individual vendor or non-open source documentation?
-->
### 内容 {#content}
- Kubernetes 网站上是否别处已经存在类似的内容？
- 内容本身是否过度依赖于网站范畴之外、独立供应商或者非开源的文档？
<!--
### Website
- Did this PR change or remove a page title, slug/alias or anchor link? If so, are there broken links as a result of this PR? Is there another option, like changing the page title without changing the slug?
- Does the PR introduce a new page? If so:
- Is the page using the right [page content type](/docs/contribute/style/page-content-types/) and associated Hugo shortcodes?
- Does the page appear correctly in the section's side navigation (or at all)?
- Should the page appear on the [Docs Home](/docs/home/) listing?
- Do the changes show up in the Netlify preview? Be particularly vigilant about lists, code blocks, tables, notes and images.
### Other
For small issues with a PR, like typos or whitespace, prefix your comments with `nit:`. This lets the author know the issue is non-critical.
-->
### 网站 {#Website}
- PR 是否改变或者删除了某页面的标题、slug/别名或者链接锚点？
如果是这样，PR 是否会导致出现新的失效链接？
是否有其他的办法，比如改变页面标题但不改变其 slug？
- PR 是否引入新的页面？如果是：
- 该页面是否使用了正确的[页面内容类型](/docs/contribute/style/page-content-types/)
及相关联的 Hugo 短代码（shortcodes）？
- 该页面能否在对应章节的侧面导航中显示？显示得正确么？
- 该页面是否应出现在[网站主页面](/docs/home/)的列表中？
- 变更是否正确出现在 Netlify 预览中了？
要对列表、代码段、表格、注释和图像等元素格外留心
### 其他 {#other}
对于 PR 中的小问题，例如拼写错误或者空格问题，可以在你的评论前面加上 `nit:`。
这样做可以让作者知道该问题不是一个不得了的大问题。