updated 3 files in content/zh/docs/contribute/new-content

content/zh/docs/contribute/new-content/_index.md

@@ -1,4 +1,200 @@
 ---
 title: 贡献新内容
+content_type: 概念
+main_menu: true
 weight: 20
 ---
+<!-- 
+title: Contributing new content
+content_type: concept
+main_menu: true
+weight: 20
+-->
+
+<!-- overview -->
+
+<!-- 
+This section contains information you should know before contributing new
+content. 
+-->
+
+本节包含你在贡献新内容之前需要知晓的信息。
+
+<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
+<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
+
+{{< mermaid >}}
+flowchart LR 
+    subgraph second[开始之前]
+    direction TB
+    S[ ] -.-
+    A[签署 CNCF CLA] --> B[选择 Git 分支]
+    B --> C[每个 PR 一种语言]
+    C --> F[检查贡献者工具]
+    end
+    subgraph first[基本知识]
+    direction TB
+       T[ ] -.-
+       D[用 markdown 编写文档<br>并用 Hugo 构建网站] --- E[GitHub 源代码]
+       E --- G['/content/../docs' 文件夹包含<br>多语言文档]
+       G --- H[评审 Hugo 页面内容<br>类型和短代码]
+    end
+    
+
+    first ----> second
+
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
+class A,B,C,D,E,F,G,H grey
+class S,T spacewhite
+class first,second white
+{{</ mermaid >}}
+
+<!--
+***Figure - Contributing new content preparation***
+
+The figure above depicts the information you should know
+prior to submitting new content. The information details follow.
+-->
+
+***插图 - 贡献新内容准备工作***
+
+上图描述了你在提交新内容之前需要知晓的信息。
+详细信息见下文。
+
+<!-- body -->
+<!-- 
+## Contributing basics
+
+- Write Kubernetes documentation in Markdown and build the Kubernetes site
+  using [Hugo](https://gohugo.io/).
+- Kubernetes documentation uses [CommonMark](https://commonmark.org/) as its flavor of  Markdown. 
+- The source is in [GitHub](https://github.com/kubernetes/website). You can find
+  Kubernetes documentation at `/content/en/docs/`. Some of the reference
+  documentation is automatically generated from scripts in
+  the `update-imported-docs/` directory.
+- [Page content types](/docs/contribute/style/page-content-types/) describe the
+  presentation of documentation content in Hugo.
+  -->
+
+## 基本知识
+
+- 使用 Markdown 编写 Kubernetes 文档并使用 [Hugo](https://gohugo.io/) 构建网站。
+- Kubernetes 文档使用 [CommonMark](https://commonmark.org/) 作为 Markdown 的风格。
+- 源代码位于 [GitHub](https://github.com/kubernetes/website) 仓库中。
+  你可以在 `/content/zh/docs/` 目录下找到 Kubernetes 文档。
+  某些参考文档是使用位于 `update-imported-docs/` 目录下的脚本自动生成的。
+- [页面内容类型](/zh/docs/contribute/style/page-content-types/)使用 Hugo 描述文档内容的呈现。
+
+<!-- 
+- You can use [Docsy shortcodes](https://www.docsy.dev/docs/adding-content/shortcodes/) or [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) to contribute to Kubernetes documentation.
+- In addition to the standard Hugo shortcodes, we use a number of
+  [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our
+  documentation to control the presentation of content.
+- Documentation source is available in multiple languages in `/content/`. Each
+  language has its own folder with a two-letter code determined by the
+  [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php)
+  . For example, English documentation source is stored in `/content/en/docs/`.
+- For more information about contributing to documentation in multiple languages
+  or starting a new translation,
+  see [localization](/docs/contribute/localization).
+-->
+
+- 你可以使用 [Docsy 短代码](https://www.docsy.dev/docs/adding-content/shortcodes/)
+  或[定制的 Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/)贡献 Kubernetes 文档。
+- 除了标准的 Hugo 短代码外，
+  我们还在文档中使用一些[定制的 Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/)来控制内容的呈现。
+- 文档的源代码有多种语言形式，位于 `/content/` 目录下。
+  每种语言都有一个自己的目录，用两个字母表示，这两个字母是基于
+  [ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)来确定的。
+  例如，英语文档的源代码位于 `/content/en/docs/` 目录下。
+- 关于为多语言文档做贡献以及如何开始新翻译的详细信息，
+  可参考[本地化文档](/zh/docs/contribute/localization)。
+
+<!-- 
+## Before you begin {#before-you-begin}
+### Sign the CNCF CLA {#sign-the-cla}
+All Kubernetes contributors **must** read
+the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)
+and [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md).
+Pull requests from contributors who haven't signed the CLA fail the automated
+tests. The name and email you provide must match those found in
+your `git config`, and your git name and email must match those used for the
+CNCF CLA.
+-->
+
+## 开始之前 {#before-you-begin}
+
+### 签署 CNCF CLA {#sign-the-cla}
+
+所有 Kubernetes 贡献者**必须**阅读[贡献者指南](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)
+并[签署贡献者授权同意书 (Contributor License Agreement, CLA)](https://github.com/kubernetes/community/blob/master/CLA.md)。  
+
+若贡献者尚未签署 CLA，其发起的 PR 将无法通过自动化测试。
+你所提供的姓名和邮件地址必须与 `git config` 中配置的完全相同，
+而且你的 git 用户名和邮件地址必须与用来签署 CNCF CLA 的信息一致。
+
+<!-- 
+### Choose which Git branch to use
+
+When opening a pull request, you need to know in advance which branch to base
+your work on.
+
+Scenario | Branch
+:---------|:------------
+Existing or new English language content for the current release | `main`
+Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-<version>`. For example, if a feature changes in the `v{{< skew nextMinorVersion >}}` release, then add documentation changes to the ``dev-{{< skew nextMinorVersion >}}`` branch.
+Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.
+
+If you're still not sure which branch to choose, ask in `#sig-docs` on Slack.
+-->
+
+### 选择要使用的 Git 分支
+
+在发起 PR 时，你需要预先知道基于哪个分支来开展工作。
+
+场景 | 分支
+:---------|:------------
+针对当前发行版本的，对现有英文内容的修改或新的英文内容 | `main`
+ 针对功能特性变更的内容 | 分支对应于功能特性变更的主要和次要版本，分支名称采用 `dev-<version>` 的模式。例如，如果某功能特性在 `v{{< skew nextMinorVersion >}}` 版本发生变化，则对应的文档变化要添加到 `dev-{{< skew nextMinorVersion >}}` 分支。
+ 其他语言的内容（本地化） | 基于本地化团队的约定。参见[本地化分支策略](/zh/docs/contribute/localization/#branching-strategy)了解更多信息。 
+
+如果你仍不能确定要选择哪个分支，请在 Slack 的 `#sig-docs` 频道上提出问题。  
+
+<!-- 
+{{< note >}} If you already submitted your pull request and you know that the
+base branch was wrong, you (and only you, the submitter) can change it. {{<
+/note >}}
+-->
+
+{{< note >}}
+如果你已经提交了 PR，并且发现所针对的分支选错了，你（且只有作为提交人的你）可以更改分支。
+{{< /note >}}
+
+<!-- 
+### Languages per PR
+
+Limit pull requests to one language per PR. If you need to make an identical
+change to the same code sample in multiple languages, open a separate PR for
+each language.
+-->
+
+### 每个 PR 牵涉的语言
+
+请确保每个 PR 仅涉及一种语言。
+如果你需要对多种语言下的同一代码示例进行相同的修改，也请为每种语言发起一个独立的 PR。
+
+<!-- 
+## Tools for contributors
+
+The [doc contributors tools](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools)
+directory in the `kubernetes/website` repository contains tools to help your
+contribution journey go more smoothly.
+-->
+
+## 为贡献者提供的工具
+
+`kubernetes/website` 仓库的[文档贡献者工具](https://github.com/kubernetes/website/tree/main/content/zh/docs/doc-contributor-tools)目录中包含了一些工具，
+有助于使你的贡献过程更为顺畅。

content/zh/docs/contribute/new-content/overview.md

@@ -1,122 +0,0 @@
----
-title: 贡献新内容概述
-linktitle: 概述
-content_type: concept
-main_menu: true
-weight: 5
----
-<!--
-title: Contributing new content overview
-linktitle: Overview
-content_type: concept
-main_menu: true
-weight: 5
--->
-
-<!-- overview -->
-<!--
-This section contains information you should know before contributing new content.
--->
-本节包含贡献新内容之前你需要知晓的一些信息。
-
-<!-- body -->
-
-<!--
-## Contributing basics
-
-- Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/).
-- The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
-- [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo.
-- In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
-- Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`.
-- For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization).
--->
-## 基本知识
-
-- 使用 Markdown 来编写 Kubernetes 文档并使用 [Hugo](https://gohugo.io/) 来构建网站
-- 源代码位于 [GitHub](https://github.com/kubernetes/website) 仓库中。
-  你可以在 `/content/en/docs/` 目录下找到 Kubernetes 文档。
-  某些参考文档是使用位于 `update-imported-docs/` 目录下的脚本自动生成的。
-- [页面内容类型](/zh/docs/contribute/style/page-content-types/)使用 Hugo 描述文档内容的表现。
-- 除了基本的 Hugo 短代码（shortcodes）外，我们还在文档中使用一些
-  [定制的 Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/)以控制内容的表现。
-- 文档的源代码有多种语言形式，位于`/content/` 目录下。
-  每种语言都有自己的由两个字母代表的目录，这两个字母是基于
-  [ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)来确定的。
-  例如，英语文档源码位于`/content/en/docs/` 目录下。
-- 关于在多种语言中为文档做贡献的详细信息，以及如何启动一种新的语言翻译，
-  可参考[本地化](/zh/docs/contribute/localization)文档。
-
-<!--
-## Before you begin {#before-you-begin}
-### Sign the CNCF CLA {#sign-the-cla}
-
-All Kubernetes contributors **must** read the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md).
-
-Pull requests from contributors who haven't signed the CLA fail the automated tests. The name and email you provide must match those found in your `git config`, and your git name and email must match those used for the CNCF CLA.
--->
-## 开始之前 {#before-you-begin}
-
-### 签署 CNCF CLA {#sign-the-cla}
-
-所有 Kubernetes 贡献者 **必须** 阅读
-[贡献者指南](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)
-并[签署贡献者授权同意书（Contributor License Agreement，CLA）](https://github.com/kubernetes/community/blob/master/CLA.md)。
-
-来自尚未签署 CLA 的贡献者的 PR 无法通过自动化服务的测试。
-你所提供的姓名和邮件地址必须与 `git config` 中所找到的完全相同，
-而且你的 git 用户名和邮件地址必须与用来签署 CNCF CLA 的一致。
-
-<!--
-### Choose which Git branch to use
-
-When opening a pull request, you need to know in advance which branch to base your work on.
-
-Scenario | Branch
-:---------|:------------
-Existing or new English language content for the current release | `main`
-Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-release-<version>`. For example, if a feature changes in the `{{< latest-version >}}` release, then add documentation changes to the ``dev-{{< release-branch >}}`` branch.
-Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.
-
-If you're still not sure which branch to choose, ask in `#sig-docs` on Slack.
--->
-### 选择要使用的分支
-
-在发起拉取请求时，你需要预先知道要基于哪个分支来开展工作。
-
-场景      | 分支
-:---------|:------------
-针对当前发行版本的，对现有英文内容的修改或新的英文内容 | `main`
-针对功能特性变更的内容 | 功能特性所对应的版本所对应的分支，分支名字模式为 `dev-<version>`。例如，如果某功能特性在 `v{{< skew nextMinorVersion >}}` 版本发生变化，则对应的文档变化要添加到 ``dev-{{< skew nextMinorVersion >}}`` 分支。
-其他语言的内容（本地化）| 基于本地化团队的约定。参见[本地化分支策略](/zh/docs/contribute/localization/#branching-strategy)了解更多信息。
-
-如果你仍不能确定要选择哪个分支，请在 `#sig-docs` Slack 频道上提问。
-
-<!--
-If you already submitted your pull request and you know that the base branch
-was wrong, you (and only you, the submitter) can change it.
--->
-{{< note >}}
-如果你已经提交了你的 PR，并且你发现所针对的分支选错了，你（且只能是你）可以重新选择分支。
-{{< /note >}}
-
-<!--
-### Languages per PR
-Limit pull requests to one language per PR. If you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language.
--->
-### 每个 PR 牵涉的语言
-
-请限制每个 PR 仅涉及一种语言。
-如果你需要对多种语言下的同一代码示例进行相同的修改，也请为每种语言发起一个独立的 PR。
-
-<!--
-## Tools for contributors
-The [doc contributors tools](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) directory in the `kubernetes/website` repository contains tools to help your contribution journey go more smoothly.
--->
-
-## 为贡献者提供的工具
-
-`kubernetes/website` 仓库的
-[文档贡献者工具](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools)
-目录中包含了一些工具，能够助你的贡献过程更为顺畅。
-

content/zh/docs/contribute/participate/pr-wranglers.md

@@ -16,10 +16,10 @@ SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilites/#app
 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-responsibilites/#approvers)们每周轮流负责
-[管理仓库的 PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers)。
+[管理仓库的 PR](https://github.com/kubernetes/website/wiki/PR-Wranglers)。
 
-本节介绍 PR 管理者的职责。关于如何提供较好的评审意见，可参阅
+本节介绍 PR 管理者的职责。关于如何提供较好的评审意见，
-[评审变更](/zh/docs/contribute/review/).
+可参阅[评审变更](/zh/docs/contribute/review/)。
 
 
 <!-- body -->
@@ -31,16 +31,6 @@ 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.
-- 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.
-- 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/). Open a new issue with the label `good first issue` to address style concerns.
 -->
 ## 职责 {#duties}
 在为期一周的轮值期内，PR 管理者要：
@@ -54,19 +44,44 @@ Each day in a week-long shift as PR Wrangler:
 
   - 首先查看最小的 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 上发表评论并要求贡献者提供更多细节。
+  - 如果你需要验证内容，请在 PR 上发表评论并要求贡献者提供更多细节。
   - 设置相关的 `sig/` 标签。
-  - 如果需要，从文件开头的 `reviewers:` 块中指派评阅人。
+  - 如果需要，根据文件开头的 `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`。
+    批准变更时，可以登记一个新的 Issue 来解决文档风格问题。
+    你通常可以将这些风格修复问题标记为 `good first issue`。
+  - 将风格修复事项标记为 `good first issue` 可以很好地确保向新加入的贡献者分派一些比较简单的任务，
+    这有助于接纳新的贡献者。
 
 <!--
 ### Helpful GitHub queries for wranglers
@@ -75,7 +90,7 @@ 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 查询
+### 对管理者有用的 GitHub 查询
 
 执行管理操作时，以下查询很有用。完成以下这些查询后，剩余的要审阅的 PR 列表通常很小。
 这些查询都不包含本地化的 PR，并仅包含主分支上的 PR（除了最后一个查询）。
@@ -172,3 +187,38 @@ The [`fejta-bot`](https://github.com/fejta-bot) bot marks issues as stale after
 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](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](slack.k8s.io) 向这名 PR 管理者做一次自我介绍。