Switch language name 'zh' to 'zh-cn'

This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name. - The upstream docsy theme changed the language name, leading to many warnings during site build; The side-effect is that the i18n strings are no longer working. - We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc. There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc. We will lock up changes to zh/zh-cn pages for the moment, until this one gets in. This PR is based on commit cdad0a7342.
2022-06-10 20:25:27 +08:00
parent 3d345b1816
commit c52818c03d
1347 changed files with 8 additions and 6 deletions
@@ -0,0 +1,225 @@
+---
+title: 参与 SIG Docs
+content_type: concept
+weight: 60
+card:
+  name: contribute
+  weight: 60
+---
+<!--
+title: Participating in SIG Docs
+content_type: concept
+weight: 60
+card:
+  name: contribute
+  weight: 60
+-->
+
+<!-- overview -->
+
+<!--
+SIG Docs is one of the
+[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md)
+within the Kubernetes project, focused on writing, updating, and maintaining
+the documentation for Kubernetes as a whole. See
+[SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs)
+for more information about the SIG.
+-->
+SIG Docs 是 Kubernetes 项目
+[特别兴趣小组](https://github.com/kubernetes/community/blob/master/sig-list.md)
+中的一个，负责编写、更新和维护 Kubernetes 的总体文档。
+参见[社区 GitHub 仓库中 SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs)
+以进一步了解该 SIG。
+
+<!--
+SIG Docs welcomes content and reviews from all contributors. Anyone can open a
+pull request (PR), and anyone is welcome to file issues about content or comment
+on pull requests in progress.
+-->
+SIG Docs 欢迎所有贡献者提供内容和审阅。任何人可以提交拉取请求（PR）。
+欢迎所有人对文档内容创建 Issue 和对正在处理中的 PR 进行评论。
+
+<!--
+You can also become a [member](/docs/contribute/participating/roles-and-responsibilities/#members),
+[reviewer](/docs/contribute/participating/roles-and-responsibilities/#reviewers), or [approver](/docs/contribute/participating/roles-and-responsibilities/#approvers). These roles require greater
+access and entail certain responsibilities for approving and committing changes.
+See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
+for more information on how membership works within the Kubernetes community.
+
+The rest of this document outlines some unique ways these roles function within
+SIG Docs, which is responsible for maintaining one of the most public-facing
+aspects of Kubernetes - the Kubernetes website and documentation.
+-->
+你也可以成为[成员（member）](/docs/contribute/participating/roles-and-responsibilities/#members)、
+[评阅人（reviewer）](/docs/contribute/participating/roles-and-responsibilities/#reviewers) 或者
+[批准人（approver）](/docs/contribute/participating/roles-and-responsibilities/#approvers)。
+这些角色拥有更高的权限，且需要承担批准和提交变更的责任。
+有关 Kubernetes 社区中的成员如何工作的更多信息，请参见
+[社区成员身份](https://github.com/kubernetes/community/blob/master/community-membership.md)。
+
+本文档的其余部分概述了这些角色在 SIG Docs 中发挥作用的一些独特方式。
+SIG Docs 负责维护 Kubernetes 最面向公众的方面之一 —— Kubernetes 网站和文档。
+
+<!-- body -->
+
+<!--
+#### SIG Docs chairperson
+
+Each SIG, including SIG Docs, selects one or more SIG members to act as
+chairpersons. These are points of contact between SIG Docs and other parts of
+the Kubernetes organization. They require extensive knowledge of the structure
+of the Kubernetes project as a whole and how SIG Docs works within it. See
+[Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)
+for the current list of chairpersons.
+-->
+## SIG Docs 主席
+
+每个 SIG，包括 SIG Docs，都会选出一位或多位成员作为主席。
+主席会成为 SIG Docs 和其他 Kubernetes 组织的联络接口人。
+他们需要了解整个 Kubernetes 项目的架构，并明白 SIG Docs 如何在其中运作。
+如需查询当前的主席名单，请查阅
+[领导人员](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)。
+
+<!--
+## SIG Docs teams and automation
+
+Automation in SIG Docs relies on two different mechanisms for automation:
+GitHub groups and OWNERS files.
+-->
+## SIG Docs 团队和自动化 {#sig-docs-teams-and-automation}
+
+SIG 文档中的自动化服务依赖于两种不同的自动化机制:
+GitHub 组和 OWNERS 文件。
+
+<!--
+### GitHub teams
+
+There are two categories of SIG Docs [teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) on GitHub:
+
+- `@sig-docs-{language}-owners` are approvers and leads
+- `@sig-docs-{language}-reviewers` are reviewers
+
+Each can be referenced with their `@name` in GitHub comments to communicate with
+everyone in that group.
+
+Sometimes Prow and GitHub teams overlap without matching exactly. For assignment of issues, pull requests, and to support PR approvals,
+the automation uses information from `OWNERS` files.
+-->
+### GitHub 团队 {#github-teams}
+
+GitHub 上有两类 SIG Docs 团队：
+
+- `@sig-docs-{language}-owners` 包含批准人和牵头人
+- `@sig-docs-{language}-reviewers` 包含评阅人
+
+可以在 GitHub 的评论中使用团队的名称 `@name` 来与团队成员沟通。
+
+有时候 Prow 所定义的团队和 GitHub 团队有所重叠，并不完全一致。
+对于指派 Issue、PR 和批准 PR，自动化工具使用来自 `OWNERS` 文件的信息。
+
+<!--
+### OWNERS files and front-matter
+
+The Kubernetes project uses an automation tool called prow for automation
+related to GitHub issues and pull requests. The
+[Kubernetes website repository](https://github.com/kubernetes/website) uses
+two [prow plugins](https://github.com/kubernetes/test-infra/blob/master/prow/plugins):
+-->
+### OWNERS 文件和扉页
+
+Kubernetes 项目使用名为 prow 的自动化工具来自动处理 GitHub issue 和 PR。
+[Kubernetes website 仓库](https://github.com/kubernetes/website) 使用了两个
+[prow 插件](https://github.com/kubernetes/test-infra/blob/master/prow/plugins)：
+
+- blunderbuss
+- approve
+
+<!--
+These two plugins use the
+[OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) and
+[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES)
+files in the top level of the `kubernetes/website` GitHub repository to control
+how prow works within the repository.
+-->
+这两个插件使用位于 `kubernetes/website` 仓库顶层的
+[OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) 文件和
+[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES)
+文件来控制 prow 在仓库范围的工作方式。 
+
+<!--
+An OWNERS file contains a list of people who are SIG Docs reviewers and
+approvers. OWNERS files can also exist in subdirectories, and can override who
+can act as a reviewer or approver of files in that subdirectory and its
+descendents. For more information about OWNERS files in general, see
+[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md).
+-->
+OWNERS 文件包含 SIG Docs 评阅人和批准人的列表。 
+OWNERS 文件也可以存在于子目录中，可以在子目录层级重新设置哪些人可以作为评阅人和
+批准人，并将这一设定传递到下层子目录。 
+关于 OWNERS 的更多信息，请参考
+[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)
+文档。
+
+<!--
+In addition, an individual Markdown file can list reviewers and approvers in its
+front-matter, either by listing individual GitHub usernames or GitHub groups.
+
+The combination of OWNERS files and front-matter in Markdown files determines
+the advice PR owners get from automated systems about who to ask for technical
+and editorial review of their PR.
+-->
+此外，每个独立的 Markdown 文件都可以在其前言部分列出评阅人和批准人，
+每一项可以是 GitHub 用户名，也可以是 GitHub 组名。
+
+结合 OWNERS 文件及 Markdown 文件的前言信息，自动化系统可以给 PR 作者可以就应该
+向谁请求技术和文字评阅给出建议。
+
+<!--
+## How merging works
+
+When a pull request is merged to the branch used to publish content, that content
+is published to http://kubernetes.io. To ensure that
+the quality of our published content is high, we limit merging pull requests to
+SIG Docs approvers. Here's how it works.
+
+- When a pull request has both the `lgtm` and `approve` labels, has no `hold`
+  labels, and all tests are passing, the pull request merges automatically.
+- Kubernetes organization members and SIG Docs approvers can add comments to
+  prevent automatic merging of a given pull request (by adding a `/hold` comment
+  or withholding a `/lgtm` comment).
+- Any Kubernetes member can add the `lgtm` label by adding a `/lgtm` comment.
+- Only SIG Docs approvers can merge a pull request
+  by adding an `/approve` comment. Some approvers also perform additional
+  specific roles, such as [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) or
+  [SIG Docs chairperson](#sig-docs-chairperson).
+-->
+## PR 是怎样被合并的 {#how-merging-works}
+
+当某个拉取请求（PR）被合并到用来发布内容的分支，对应的内容就会被发布到 http://kubernetes.io。
+为了确保我们所发布的内容的质量足够好，合并 PR 的权限仅限于
+SIG Docs 批准人。下面是合并的工作机制：
+
+- 当某个 PR 同时具有 `lgtm` 和 `approve` 标签，没有 `hold` 标签且通过所有测试时，
+  该 PR 会被自动合并。
+- Kubernetes 组织的成员和 SIG Docs 批准人可以添加评论以阻止给定 PR 的自动合并，
+  即通过 `/hold` 评论或者收回某个 `/lgtm` 评论实现这点。
+- 所有 Kubernetes 成员可以通过 `/lgtm` 评论添加 `lgtm` 标签。
+- 只有 SIG Docs 批准人可以通过评论 `/approve` 合并 PR。
+  某些批准人还会执行一些其他角色，例如
+  [PR 管理者](/zh/docs/contribute/participate/pr-wranglers/) 或
+  [SIG Docs 主席](#sig-docs-chairperson)等。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+For more information about contributing to the Kubernetes documentation, see:
+
+- [Contributing new content](/docs/contribute/overview/)
+- [Reviewing content](/docs/contribute/review/reviewing-prs)
+- [Documentation style guide](/docs/contribute/style/)
+-->
+关于贡献 Kubernetes 文档的更多信息，请参考：
+
+- [贡献新内容](/zh/docs/contribute/new-content/overview/)
+- [评阅内容](/zh/docs/contribute/review/reviewing-prs)
+- [文档样式指南](/zh/docs/contribute/style/)
@@ -0,0 +1,224 @@
+---
+title: PR 管理者
+content_type: concept
+weight: 20
+---
+<!--
+title: PR wranglers
+content_type: concept
+weight: 20
+-->
+
+<!-- overview -->
+<!--
+SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers) take week-long shifts [managing pull requests](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository.
+
+This section covers the duties of a PR wrangler. For more information on giving good reviews, see [Reviewing changes](/docs/contribute/review/).
+-->
+SIG Docs 的[批准人（Approvers）](/zh/docs/contribute/participate/roles-and-responsibilities/#approvers)们每周轮流负责
+[管理仓库的 PR](https://github.com/kubernetes/website/wiki/PR-Wranglers)。
+
+本节介绍 PR 管理者的职责。关于如何提供较好的评审意见，
+可参阅[评审变更](/zh/docs/contribute/review/)。
+
+
+<!-- body -->
+<!--
+## Duties
+
+Each day in a week-long shift as PR Wrangler:
+
+- Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata.
+- Review [open pull requests](https://github.com/kubernetes/website/pulls) for quality and adherence to the [Style](/docs/contribute/style/style-guide/) and [Content](/docs/contribute/style/content-guide/) guides.
+    - Start with the smallest PRs (`size/XS`) first, and end with the largest (`size/XXL`). Review as many PRs as you can.
+-->
+## 职责 {#duties}
+在为期一周的轮值期内，PR 管理者要：
+
+- 每天对新增的 Issues 判定和打标签。参见
+  [对 Issues 进行判定和分类](/zh/docs/contribute/review/for-approvers/#triage-and-categorize-issues)
+  以了解 SIG Docs 如何使用元数据的详细信息。
+- 检查[悬决的 PR](https://github.com/kubernetes/website/pulls) 的质量并确保它们符合
+  [样式指南](/zh/docs/contribute/style/style-guide/)和
+  [内容指南](/zh/docs/contribute/style/content-guide/)要求。
+
+  - 首先查看最小的 PR（`size/XS`），然后逐渐扩展到最大的
+    PR（`size/XXL`），尽可能多地评审 PR。
+<!-- 
+- Make sure PR contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md).
+    - Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to remind contributors that haven't signed the CLA to do so.
+- Provide feedback on changes and ask for technical reviews from members of other SIGs.
+    - Provide inline suggestions on the PR for the proposed content changes.
+    - If you need to verify content, comment on the PR and request more details.
+    - Assign relevant `sig/` label(s).
+    - If needed, assign reviewers from the `reviewers:` block in the file's front matter.
+    - You can also tag a [SIG](https://github.com/kubernetes/community/blob/master/sig-list.md) for a review by commenting `@kubernetes/<sig>-pr-reviews` on the PR.
+-->
+- 确保贡献者完成 [CLA](https://github.com/kubernetes/community/blob/master/CLA.md) 签署。
+  - 使用[此脚本](https://github.com/zparnold/k8s-docs-pr-botherer)自动提醒尚未签署
+    CLA 的贡献者签署 CLA。
+- 针对提供提供反馈，请求其他 SIG 的成员进行技术审核。
+  - 为 PR 所建议的内容更改提供就地反馈。
+  - 如果你需要验证内容，请在 PR 上发表评论并要求贡献者提供更多细节。
+  - 设置相关的 `sig/` 标签。
+  - 如果需要，根据文件开头的 `reviewers:` 块来指派评审人。
+  - 你也可以通过在 PR 上作出 `@kubernetes/<sig>-pr-reviews` 的评论以标记需要某个
+    [SIG](https://github.com/kubernetes/community/blob/master/sig-list.md) 来评审。
+<!-- 
+- Use the `/approve` comment to approve a PR for merging. Merge the PR when ready.
+    - PRs should have a `/lgtm` comment from another member before merging.
+    - Consider accepting technically accurate content that doesn't meet the
+      [style guidelines](/docs/contribute/style/style-guide/). As you approve the change,
+      open a new issue to address the style concern. You can usually write these style fix
+      issues as [good first issues](https://kubernetes.dev/docs/guide/help-wanted/#good-first-issue).
+    - Using style fixups as good first issues is a good way to ensure a supply of easier tasks
+      to help onboard new contributors.
+-->
+- 使用 `/approve` 评论来批准可以合并的 PR，在 PR 就绪时将其合并。
+  - PR 在被合并之前，应该有来自其他成员的 `/lgtm` 评论。
+  - 可以考虑接受那些技术上准确，但文风上不满足
+    [风格指南](/zh/docs/contribute/style/style-guide/)要求的 PR。
+    批准变更时，可以登记一个新的 Issue 来解决文档风格问题。
+    你通常可以将这些风格修复问题标记为 `good first issue`。
+  - 将风格修复事项标记为 `good first issue` 可以很好地确保向新加入的贡献者分派一些比较简单的任务，
+    这有助于接纳新的贡献者。
+
+<!--
+### Helpful GitHub queries for wranglers
+
+The following queries are helpful when wrangling.
+After working through these queries, the remaining list of PRs to review is usually small.
+These queries exclude localization PRs. All queries are against the main branch except the last one.
+-->
+### 对管理者有用的 GitHub 查询
+
+执行管理操作时，以下查询很有用。完成以下这些查询后，剩余的要审阅的 PR 列表通常很小。
+这些查询都不包含本地化的 PR，并仅包含主分支上的 PR（除了最后一个查询）。
+
+<!--
+- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3Alanguage%2Fen):
+  Remind the contributor to sign the CLA. If both the bot and a human have reminded them, close
+  the PR and remind them that they can open it after signing the CLA.
+  **Do not review PRs whose authors have not signed the CLA!**
+- [Needs LGTM](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm):
+  Lists PRs that need an LGTM from a member. If the PR needs technical review, loop in one of the reviewers suggested by the bot. If the content needs work, add suggestions and feedback in-line.
+- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+):
+  Lists PRs that need an `/approve` comment to merge.
+- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amain+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]).
+- [Not against the primary branch](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amain): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @<manager's_github-username>`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch.
+-->
+- [未签署 CLA，不可合并的 PR](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3Alanguage%2Fen)：
+  提醒贡献者签署 CLA。如果机器人和审阅者都已经提醒他们，请关闭 PR，并提醒他们在签署 CLA 后可以重新提交。
+
+  **在作者没有签署 CLA 之前，不要审阅他们的 PR！**
+
+- [需要 LGTM](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm)：
+  列举需要来自成员的 LGTM 评论的 PR。
+  如果需要技术审查，请告知机器人所建议的审阅者。
+  如果 PR 继续改进，就地提供更改建议或反馈。
+
+- [已有 LGTM标签，需要 Docs 团队批准](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+)：
+  列举需要 `/approve` 评论来合并的 PR。
+
+- [快速批阅](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amain+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22)：
+  列举针对主分支的、没有明确合并障碍的 PR。
+  在浏览 PR 时，可以将 "XS" 尺寸标签更改为 "S"、"M"、"L"、"XL"、"XXL"。
+
+- [非主分支的 PR](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amain): 
+  如果 PR 针对 `dev-` 分支，则表示它适用于即将发布的版本。
+  请添加带有 `/assign @<负责人的 github 账号>`，将其指派给 
+  [发行版本负责人](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles)。
+  如果 PR 是针对旧分支，请帮助 PR 作者确定是否所针对的是最合适的分支。
+
+<!--
+### Helpful Prow commands for wranglers
+-->
+### 对管理者有用的 Prow 命令  {#helpful-prow-commands-for-wranglers}
+
+```
+# 添加 English 标签
+/language en
+
+# 如果 PR 包含多个提交（commits），添加 squash 标签
+/label tide/merge-method-squash
+
+# 使用 Prow 来为 PR 重设标题（例如一个正在处理 [WIP] 的 PR 或为 PR 提供更好的细节信息）
+/retitle [WIP] <TITLE>
+```
+
+<!--
+### When to close Pull Requests
+
+Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure.
+
+Close PRs where:
+- The author hasn't signed the CLA for two weeks.
+
+    Authors can reopen the PR after signing the CLA. This is a low-risk way to make sure nothing gets merged without a signed CLA.
+
+- The author has not responded to comments or feedback in 2 or more weeks.
+
+Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Often a closure notice is what spurs an author to resume and finish their contribution.
+
+To close a pull request, leave a `/close` comment on the PR.
+-->
+### 何时关闭 PR     {#when-to-close-pull-requests}
+
+审查和批准是缩短和更新我们的 PR 队列的一种方式；另一种方式是关闭 PR。
+
+当以下条件满足时，可以关闭 PR：
+
+- 作者两周内未签署 CLA。
+  PR 作者可以在签署 CLA 后重新打开 PR，因此这是确保未签署 CLA 的 PR 不会被合并的一种风险较低的方法。
+
+- 作者在两周或更长时间内未回复评论或反馈。
+
+不要害怕关闭 PR。贡献者可以轻松地重新打开并继续工作。
+通常，关闭通知会激励作者继续完成其贡献。
+
+要关闭 PR，请在 PR 上输入 `/close` 评论。
+
+<!--
+The [`k8s-ci-robot`](https://github.com/k8s-ci-robot) bot marks issues as stale after 90 days of inactivity. After 30 more days it marks issues as rotten and closes them.  PR wranglers should close issues after 14-30 days of inactivity.
+-->
+{{< note >}}
+一个名为 [`k8s-ci-robot`](https://github.com/k8s-ci-robot) 的自动服务会在 Issue 停滞 90
+天后自动将其标记为过期；然后再等 30 天，如果仍然无人过问，则将其关闭。
+PR 管理者应该在 issues 处于无人过问状态 14-30 天后关闭它们。
+{{< /note >}}
+
+<!--
+## PR Wrangler shadow program
+
+In late 2021, SIG Docs introduced the PR Wrangler Shadow Program. The program was introduced to help new contributors understand the PR wrangling process.
+-->
+## PR 管理者影子计划
+
+2021 下半年，SIG Docs 推出了 PR 管理者影子计划（PR Wrangler Shadow Program）。
+该计划旨在帮助新的贡献者们了解 PR 管理流程。
+
+<!-- 
+### Become a shadow
+
+- If you are interested in shadowing as a PR wrangler, please visit the [PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers) to see the PR wrangling schedule for this year and sign up.
+
+- Kubernetes org members can edit the [PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers) and sign up to shadow an existing PR Wrangler for a week.
+
+- Others can reach out on the [#sig-docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) for requesting to shadow an assigned PR Wrangler for a specific week. Feel free to reach out to Brad Topol (`@bradtopol`) or one of the [SIG Docs co-chairs/leads](https://github.com/kubernetes/community/tree/master/sig-docs#leadership).
+
+- Once you've signed up to shadow a PR Wrangler, introduce yourself to the PR Wrangler on the [Kubernetes Slack](https://slack.k8s.io).
+-->
+### 成为一名影子
+
+- 如果你有兴趣成为一名 PR 管理者的影子，请访问 [PR 管理者维基页面](https://github.com/kubernetes/website/wiki/PR-Wranglers)查看今年的 
+  PR 管理轮值表，然后注册报名。
+
+- Kubernetes 组织成员可以编辑 [PR 管理者维基页面](https://github.com/kubernetes/website/wiki/PR-Wranglers)，
+  注册成为一名现有 PR 管理者一周内的影子。
+
+- 其他人可以通过 [#sig-docs Slack 频道](https://kubernetes.slack.com/messages/sig-docs)申请成为指定 
+  PR 管理者某一周的影子。可以随时咨询 (`@bradtopol`) 或某一位
+  [SIG Docs 联席主席/主管](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)。
+
+- 注册成为一名 PR 管理者的影子时，
+  请你在 [Kubernetes Slack](https://slack.k8s.io) 向这名 PR 管理者做一次自我介绍。
@@ -0,0 +1,418 @@
+---
+title: 角色与责任
+content_type: concept
+weight: 10
+---
+
+<!-- overview -->
+
+<!--
+Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow, you can apply for different levels of membership in the community.
+These roles allow you to take on more responsibility within the community.
+Each role requires more time and commitment. The roles are:
+
+- Anyone: regular contributors to the Kubernetes documentation
+- Members: can assign and triage issues and provide non-binding review on pull requests
+- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality
+- Approvers: can lead reviews on documentation and  merge changes
+-->
+任何人都可以为 Kubernetes 作出贡献。随着你对 SIG Docs 的贡献增多，你可以申请
+社区内不同级别的成员资格。
+这些角色使得你可以在社区中承担更多的责任。
+每个角色都需要更多的时间和投入。具体包括：
+
+- 任何人（Anyone）：为 Kubernetes 文档作出贡献的普通贡献者。
+- 成员（Members）：可以对 Issue 进行分派和判别，对 PR 提出无约束性的评审意见。
+- 评审人（Reviewers）：可以领导对文档 PR 的评审，可以对变更的质量进行判别。
+- 批准人（Approvers）：可以领导对文档的评审并合并变更。
+
+<!-- body -->
+
+<!--
+## Anyone
+
+Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors!
+
+Anyone can:
+
+- Open an issue in any [Kubernetes](https://github.com/kubernetes/) repository, including [`kubernetes/website`](https://github.com/kubernetes/website)
+- Give non-binding feedback on a pull request
+- Contribute to a localization
+- Suggest improvements on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+
+After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also:
+
+- Open a pull request to improve existing content, add new content, or write a blog post or case study
+- Create diagrams, graphics assets, and embeddable screencasts and videos
+
+For more information, see [contributing new content](/docs/contribute/new-content/).
+-->
+## 任何人（Anyone）  {#anyone}
+
+任何拥有 GitHub 账号的人都可以对 Kubernetes 作出贡献。SIG Docs
+欢迎所有新的贡献者。
+
+任何人都可以：
+
+- 在任何 [Kubernetes](https://github.com/kubernetes/) 仓库，包括
+  [`kubernetes/website`](https://github.com/kubernetes/website) 上报告 Issue。
+- 对某 PR 给出无约束力的反馈信息
+- 为本地化提供帮助
+- 在 [Slack](https://slack.k8s.io/) 或
+  [SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+  上提出改进建议。
+
+在[签署了 CLA](/zh/docs/contribute/new-content/overview/#sign-the-cla) 之后，任何人还可以：
+
+- 发起拉取请求（PR），改进现有内容、添加新内容、撰写博客或者案例分析
+- 创建示意图、图形资产或者嵌入式的截屏和视频内容
+
+进一步的详细信息，可参见[贡献新内容](/zh/docs/contribute/new-content/)。
+
+<!--
+## Members
+
+A member is someone who has submitted multiple pull requests to `kubernetes/website`. Members are a part of the [Kubernetes GitHub organization](https://github.com/kubernetes).
+
+Members can:
+
+- Do everything listed under [Anyone](#anyone)
+- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request
+
+    {{< note >}}
+    Using `/lgtm` triggers automation. If you want to provide non-binding approval, commenting "LGTM" works too!
+    {{< /note >}}
+- Use the `/hold` comment to block merging for a pull request
+- Use the `/assign` comment to assign a reviewer to a pull request
+- Provide non-binding review on pull requests
+- Use automation to triage and categorize issues
+- Document new features
+-->
+## 成员（Members）  {#members}
+
+成员是指那些对 `kubernetes/website` 提交很多拉取请求（PR）的人。
+成员都要加入 [Kubernetes GitHub 组织](https://github.com/kubernetes)。
+
+成员可以：
+
+- 执行[任何人](#anyone)节区所列举操作
+- 使用 `/lgtm` 评论添加 LGTM (looks good to me（我觉得可以）) 标签到某个 PR
+
+  {{< note >}}
+  使用 `/lgtm` 会触发自动化机制。如果你希望提供非约束性的批准意见，
+  直接回复 "LGTM" 也是可以的。
+  {{< /note >}}
+
+- 利用 `/hold` 评论来阻止某个 PR 被合并
+- 使用 `/assign` 评论为某个 PR 指定评审人
+- 对 PR 提供非约束性的评审意见
+- 使用自动化机制来对 Issue 进行判别和分类
+- 为新功能特性撰写文档
+
+<!--
+### Becoming a member
+
+After submitting at least 5 substantial pull requests and meeting the other [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member):
+-->
+### 成为一个成员 {#becoming-a-member}
+
+在你成功地提交至少 5 个 PR 并满足
+[相关条件](https://github.com/kubernetes/community/blob/master/community-membership.md#member)
+之后：
+
+<!--
+1.  Find two [reviewers](#reviewers) or [approvers](#approvers) to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your membership.
+
+    Ask for sponsorship in the [#sig-docs channel on Slack](https://kubernetes.slack.com) or on the
+    [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+
+    {{< note >}}
+    Don't send a direct email or Slack direct message to an individual
+    SIG Docs member. You must request sponsorship before submitting your application.
+    {{< /note >}}
+
+2.  Open a GitHub issue in the [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the **Organization Membership Request** issue template.
+-->
+1. 找到两个[评审人](#reviewers)或[批准人](#approvers)为你的成员身份提供
+   [担保](/zh/docs/contribute/advanced#sponsor-a-new-contributor)。
+
+   通过 [Kubernetes Slack 上的 #sig-docs 频道](https://kubernetes.slack.com) 或者
+   [SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+   来寻找为你担保的人。
+
+   {{< note >}}
+   不要单独发送邮件给某个 SIG Docs 成员或在 Slack 中与其私聊。
+   在提交申请之前，一定要先确定担保人。
+   {{< /note >}}
+
+2. 在 [`kubernetes/org`](https://github.com/kubernetes/org/) 仓库
+   使用 **Organization Membership Request** Issue 模板登记一个 Issue。
+
+<!--
+3.  Let your sponsors know about the GitHub issue. You can either:
+  - Mention their GitHub username in an issue (`@<GitHub-username>`)
+  - Send them the issue link using Slack or email.
+
+    Sponsors will approve your request with a `+1` vote. Once your sponsors approve the request, a Kubernetes GitHub admin adds you as a member. Congratulations!
+
+    If your membership request is not accepted you will receive feedback. After addressing the feedback, apply again.
+
+4. Accept the invitation to the Kubernetes GitHub organization in your email account.
+
+    {{< note >}}
+    GitHub sends the invitation to the default email address in your account.
+    {{< /note >}}
+-->
+3. 告知你的担保人你所创建的 Issue，你可以：
+
+   - 在 Issue 中 `@<GitHub-username>` 提及他们的 GitHub 用户名
+   - 通过 Slack 或 email 直接发送给他们 Issue 链接
+ 
+   担保人会通过 `+1` 投票来批准你的请求。一旦你的担保人批准了该请求，
+   某个 Kubernetes GitHub 管理员会将你添加为组织成员。恭喜！
+
+   如果你的成员请求未被接受，你会收到一些反馈。
+   当处理完反馈意见之后，可以再次发起申请。
+
+4. 登录你的邮件账户，接受来自 Kubernetes GitHub 组织发出的成员邀请。
+
+    {{< note >}}
+    GitHub 会将邀请发送到你的账户中所设置的默认邮件地址。
+    {{< /note >}}
+
+<!--
+## Reviewers
+
+Reviewers are responsible for reviewing open pull requests. Unlike member feedback, you must address reviewer feedback. Reviewers are members of the [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub team.
+
+Reviewers can:
+
+- Do everything listed under [Anyone](#anyone) and [Members](#members)
+- Review pull requests and provide binding feedback
+
+    {{< note >}}
+    To provide non-binding feedback, prefix your comments with a phrase like "Optionally: ".
+    {{< /note >}}
+
+- Edit user-facing strings in code
+- Improve code comments
+
+You can be a SIG Docs reviewer, or a reviewer for docs in a specific subject area.
+-->
+## 评审人（Reviewers）  {#reviewers}
+
+评审人负责评审悬决的 PR。
+与成员所给的反馈不同，你必须处理评审人的反馈。
+评审人是 [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub 团队的成员。
+
+评审人可以：
+
+- 执行[任何人](#anyone)和[成员](#members)节区所列举的操作
+- 评审 PR 并提供具约束性的反馈信息
+
+    {{< note >}}
+    要提供非约束性的反馈，可以在你的评语之前添加 "Optionally: " 这样的说法。
+    {{< /note >}}
+
+- 编辑代码中用户可见的字符串
+- 改进代码注释
+
+你可以是 SIG Docs 的评审人，也可以是某个主题领域的文档的评审人。
+
+<!--
+### Assigning reviewers to pull requests
+
+Automation assigns reviewers to all pull requests. You can request a
+review from a specific person by commenting: `/assign
+[@_github_handle]`.
+
+If the assigned reviewer has not commented on the PR, another reviewer can step in. You can also assign technical reviewers as needed.
+
+### Using `/lgtm`
+
+LGTM stands for "Looks good to me" and indicates that a pull request is technically accurate and ready to merge. All PRs need a `/lgtm` comment from a reviewer and a `/approve` comment from an approver to merge.
+
+A `/lgtm` comment from reviewer is binding and triggers automation that adds the `lgtm` label.
+-->
+### 为 PR 指派评审人  {#assigning-reviewers-to-pull-requests}
+
+自动化引擎会为每个 PR 自动指派评审人。
+你可以通过为 PR 添加评论 `/assign [@_github_handle]` 来请求某个特定评审人来评审。
+
+如果所指派的评审人未能及时评审，其他的评审人也可以参与进来。
+你可以根据需要指派技术评审人。
+
+### 使用 `/lgtm`
+
+LGTM 代表的是 “Looks Good To Me （我觉得可以）”，用来标示某个 PR
+在技术上是准确的，可以被合并。
+所有 PR 都需要来自某评审人的 `/lgtm` 评论和来自某批准人的 `/approve`
+评论。
+
+来自评审人的 `/lgtm` 评论是具有约束性的，会触发自动化引擎添加 `lgtm` 标签。
+
+<!--
+### Becoming a reviewer
+
+When you meet the
+[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), you can become a SIG Docs reviewer. Reviewers in other SIGs must apply separately for reviewer status in SIG Docs.
+
+To apply:
+-->
+### 成为评审人   {#becoming-a-reviewer}
+
+当你满足[相关条件](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)时，
+你可以成为一个 SIG Docs 评审人。
+来自其他 SIG 的评审人必须为 SIG Docs 单独申请评审人资格。
+
+申请流程如下：
+
+<!--
+1. Open a pull request that adds your GitHub user name to a section of the
+[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) file
+in the `kubernetes/website` repository.
+
+  {{< note >}}
+  If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`.
+  {{< /note >}}
+
+2. Assign the PR to one or more SIG-Docs approvers (user names listed under `sig-docs-{language}-owners`).
+
+If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added,
+[@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests.
+-->
+1. 发起 PR，将你的 GitHub 用户名添加到 `kubernetes/website` 仓库中
+   [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES)
+   文件的对应节区。
+
+   {{< note >}}
+   如果你不确定要添加到哪个位置，可以将自己添加到 `sig-docs-en-reviews`。
+   {{< /note >}}
+
+2. 将 PR 指派给一个或多个 SIG Docs 批准人（`sig-docs-{language}-owners`
+   下列举的用户名）。
+
+申请被批准之后，SIG Docs Leads 之一会将你添加到合适的 GitHub 团队。
+一旦添加完成， [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
+会在处理未来的 PR 时，将 PR 指派给你或者建议你来评审某 PR。
+
+<!--
+## Approvers
+
+Approvers review and approve pull requests for merging. Approvers are members of the
+[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub teams.
+
+-->
+## 批准人（Approvers）   {#approvers}
+
+批准人负责评审和批准 PR 以将其合并。
+批准人是 [@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub 团队的成员。
+
+<!--
+Approvers can do the following:
+
+- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers)
+- Publish contributor content by approving and merging pull requests using the `/approve` comment
+- Propose improvements to the style guide
+- Propose improvements to docs tests
+- Propose improvements to the Kubernetes website or other tooling
+
+If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on a change that doesn't need additional technical review.
+-->
+批准人可以执行以下操作：
+
+- 执行列举在[任何人](#anyone)、[成员](#members)和[评审人](#reviewers)节区的操作
+- 通过使用 `/approve` 评论来批准、合并 PR，发布贡献者所贡献的内容。
+- 就样式指南给出改进建议
+- 对文档测试给出改进建议
+- 对 Kubernetes 网站或其他工具给出改进建议
+
+如果某个 PR 已有 `/lgtm` 标签，或者批准人再回复一个 `/lgtm` ，则这个 PR 会自动合并。
+SIG Docs 批准人应该只在不需要额外的技术评审的情况下才可以标记 `/lgtm`。
+
+<!--
+### Approving pull requests
+
+Approvers and SIG Docs leads are the only ones who can merge pull requests into the website repository. This comes with certain responsibilities.
+
+- Approvers can use the `/approve` command, which merges PRs into the repo.
+
+    {{< warning >}}
+    A careless merge can break the site, so be sure that when you merge something, you mean it.
+    {{< /warning >}}
+
+- Make sure that proposed changes meet the [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content).
+
+    If you ever have a question, or you're not sure about something, feel free to call for additional review.
+-->
+### 批准 PR   {#approving-pull-requests}
+
+只有批准人和 SIG Docs Leads 可以将 PR 合并到网站仓库。
+这意味着以下责任：
+
+- 批准人可以使用 `/approve` 命令将 PR 合并到仓库中。
+
+    {{< warning >}}
+    不小心的合并可能会破坏整个站点。在执行合并操作时，务必小心。
+    {{< /warning >}}
+
+- 确保所提议的变更满足[贡献指南](/zh/docs/contribute/style/content-guide/#contributing-content)要求。
+
+    如果有问题或者疑惑，可以根据需要请他人帮助评审。
+
+- 在 `/approve` PR 之前，须验证 Netlify 测试是否正常通过。
+
+    <img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="批准之前必须通过 Netlify 测试" />
+
+- 在批准之前，请访问 Netlify 的页面预览来确保变更内容可正常显示。
+
+- 参与 [PR 管理者轮值排班](https://github.com/kubernetes/website/wiki/PR-Wranglers)
+  执行时长为一周的 PR 管理。SIG Docs 期望所有批准人都参与到此轮值工作中。
+  更多细节可参见 [PR 管理者](/zh/docs/contribute/participate/pr-wranglers/)。
+
+<!--
+### Becoming an approver
+
+When you meet the [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), you can become a SIG Docs approver. Approvers in other SIGs must apply separately for approver status in SIG Docs.
+-->
+### 成为批准人  {#becoming-an-approver}
+
+当你满足[一定条件](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)时，可以成为一个 SIG Docs 批准人。
+来自其他 SIG 的批准人也必须在 SIG Docs 独立申请批准人资格。
+
+<!--
+To apply:
+
+1. Open a pull request adding yourself to a section of the [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) file in the `kubernetes/website` repository.
+
+    {{< note >}}
+    If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`.
+    {{< /note >}}
+
+2. Assign the PR to one or more current SIG Docs approvers.
+
+If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests.
+-->
+申请流程如下：
+
+1. 发起一个 PR，将自己添加到 `kubernetes/website` 仓库中
+   [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES)
+   文件的对应节区。
+
+   {{< note >}}
+   如果你不确定要添加到哪个位置，可以将自己添加到 `sig-docs-en-owners` 中。
+   {{< /note >}}
+
+2. 将 PR 指派给一个或多个 SIG Docs 批准人。
+
+请求被批准之后，SIG Docs Leads 之一会将你添加到对应的 GitHub 团队。
+一旦添加完成， [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
+会在处理未来的 PR 时，将 PR 指派给你或者建议你来评审某 PR。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+- Read about [PR wrangling](/docs/contribute/participating/pr-wranglers), a role all approvers take on rotation.
+-->
+- 阅读 [PR 管理者](/zh/docs/contribute/participate/pr-wranglers/)，了解所有批准人轮值的角色。
+