From 6b196a152b3ac5de4f9d549c578ac790e93adf90 Mon Sep 17 00:00:00 2001
From: Qiming Teng <tengqim@cn.ibm.com>
Date: Tue, 23 Jun 2020 10:48:33 +0800
Subject: [PATCH] [zh] Sync contribution guides (4)

This PR is about the new contents
---
 .../zh/docs/contribute/new-content/_index.md  |   4 +
 .../new-content/blogs-case-studies.md         | 108 +++
 .../contribute/new-content/new-features.md    | 267 ++++++
 .../docs/contribute/new-content/open-a-pr.md  | 883 ++++++++++++++++++
 .../docs/contribute/new-content/overview.md   | 122 +++
 5 files changed, 1384 insertions(+)
 create mode 100644 content/zh/docs/contribute/new-content/_index.md
 create mode 100644 content/zh/docs/contribute/new-content/blogs-case-studies.md
 create mode 100644 content/zh/docs/contribute/new-content/new-features.md
 create mode 100644 content/zh/docs/contribute/new-content/open-a-pr.md
 create mode 100644 content/zh/docs/contribute/new-content/overview.md

diff --git a/content/zh/docs/contribute/new-content/_index.md b/content/zh/docs/contribute/new-content/_index.md
new file mode 100644
index 0000000000..e498891fa9
--- /dev/null
+++ b/content/zh/docs/contribute/new-content/_index.md
@@ -0,0 +1,4 @@
+---
+title: 贡献新内容
+weight: 20
+---
diff --git a/content/zh/docs/contribute/new-content/blogs-case-studies.md b/content/zh/docs/contribute/new-content/blogs-case-studies.md
new file mode 100644
index 0000000000..6a77064953
--- /dev/null
+++ b/content/zh/docs/contribute/new-content/blogs-case-studies.md
@@ -0,0 +1,108 @@
+---
+title: 提交博客和案例分析
+linktitle: 博客和案例分析
+slug: blogs-case-studies
+content_type: concept
+weight: 30
+---
+<!--
+title: Submitting blog posts and case studies
+linktitle: Blogs and case studies
+slug: blogs-case-studies
+content_type: concept
+weight: 30
+-->
+
+<!-- overview -->
+<!--
+Anyone can write a blog post and submit it for review.
+Case studies require extensive review before they're approved.
+-->
+任何人都可以撰写博客并提交评阅。
+案例分析则在被批准之前需要更多的评阅。
+
+<!-- body -->
+<!--
+## Write a blog post
+
+Blog posts should not be
+vendor pitches. They must contain content that applies broadly to
+the Kubernetes community. The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post).
+-->
+## 撰写博文 {#write-a-blog-post}
+
+博客内容不可以是销售用语。
+其中的内容必须是对整个 Kubernetes 社区中很多人都有参考意义。
+SIG Docs [blog 子项目](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject)
+负责管理博客的评阅过程。
+更多信息可参考[提交博文](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post)。
+
+<!--
+To submit a blog post, you can either:
+
+- Use the
+[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform)
+- [Open a pull request](/docs/contribute/new-content/new-content/#fork-the-repo) with a new blog post. Create new blog posts in the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory.
+
+If you open a pull request, ensure that your blog post follows the correct naming conventions and frontmatter information:
+
+- The markdown file name must follow the format `YYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
+- The front matter must include the following:
+-->
+要提交博文，你可以：
+
+- 使用 [Kubernetes 博客提交表单](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform)
+- [发起一个包含博文的 PR](/zh/docs/contribute/new-content/new-content/#fork-the-repo)。
+  新博文要创建于 [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) 目录下。
+
+如果你要发起一个 PR，请确保所提交的博文遵从正确的命名规范和前言信息：
+
+- Markdown 文件名必须遵从 `YYY-MM-DD-Your-Title-Here.md` 格式。
+  例如，`2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
+- 前言部分必须包含以下内容：
+
+<!--
+```yaml
+---
+layout: blog
+title: "Your Title Here"
+date: YYYY-MM-DD
+slug: text-for-URL-link-here-no-spaces
+---
+```
+-->
+```yaml
+---
+layout: blog
+title: "博文标题"
+date: YYYY-MM-DD
+slug: text-for-URL-link-here-no-spaces
+---
+```
+
+<!--
+## Submit a case study
+
+Case studies highlight how organizations are using Kubernetes to solve
+real-world problems. The Kubernetes marketing team and members of the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} collaborate with you on all case studies.
+
+Have a look at the source for the
+[existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies).
+
+Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) and submit your request as outlined in the guidelines. 
+-->
+## 提交案例分析
+
+案例分析用来概述组织如何使用 Kubernetes 解决现实世界的问题。
+Kubernetes 市场化团队和 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 成员
+会与你一起工作，撰写所有的案例分析。
+
+请查看
+[现有案例分析](https://github.com/kubernetes/website/tree/master/content/en/case-studies)
+的源码。
+
+参考[案例分析指南](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md)
+根据指南中的注意事项提交你的 PR 请求。
+
+## {{% heading "whatsnext" %}}
+
diff --git a/content/zh/docs/contribute/new-content/new-features.md b/content/zh/docs/contribute/new-content/new-features.md
new file mode 100644
index 0000000000..5979fcef0b
--- /dev/null
+++ b/content/zh/docs/contribute/new-content/new-features.md
@@ -0,0 +1,267 @@
+---
+title: 为发行版本撰写功能特性文档
+linktitle: 为发行版本撰写文档
+content_type: concept
+main_menu: true
+weight: 20
+card:
+  name: 贡献
+  weight: 45
+  title: 为发行版本撰写功能特性文档 
+---
+<!--
+title:  Documenting a feature for a release
+linktitle: Documenting for a release
+content_type: concept
+main_menu: true
+weight: 20
+card:
+  name: contribute
+  weight: 45
+  title:  Documenting a feature for a release
+-->
+
+<!-- overview -->
+
+<!--
+Each major Kubernetes release introduces new features that require documentation.
+New releases also bring updates to existing features and documentation (such as upgrading a feature from alpha to beta).
+
+Generally, the SIG responsible for a feature submits draft documentation of the
+feature as a pull request to the appropriate development branch of the
+`kubernetes/website` repository, and someone on the SIG Docs team provides
+editorial feedback or edits the draft directly. This section covers the branching
+conventions and process used during a release by both groups.
+-->
+Kubernetes 的每个主要版本发布都会包含一些需要文档说明的新功能。
+新的发行版本也会对已有功能特性和文档（例如将某功能特性从 alpha 升级为
+beta）进行更新。
+
+通常，负责某功能特性的 SIG 要为功能特性的文档草拟文档，并针对 `kubernetes/website`
+仓库的合适的开发分支发起拉取请求。
+SIG Docs 团队会提供文字方面的反馈意见，或者直接编辑文档草稿。
+本节讨论两个小组在分支方面和发行期间所遵从的流程方面的约定。
+
+<!-- body -->
+<!--
+## For documentation contributors
+
+In general, documentation contributors don't write content from scratch for a release.
+Instead, they work with the SIG creating a new feature to refine the draft documentation and make it release ready.
+
+After you've chosen a feature to document or assist, ask about it in the `#sig-docs`
+Slack channel, in a weekly SIG Docs meeting, or directly on the PR filed by the
+feature SIG. If you're given the go-ahead, you can edit into the PR using one of
+the techniques described in
+[Commit into another person's PR](/docs/contribute/review/for-approvers/#commit-into-another-persons-pr).
+-->
+## 对于文档贡献者
+
+一般而言，文档贡献者不会为某个发行版本从头撰写文档。
+相反，他们会与开发该功能特性的 SIG 团队一起，对文档草稿进行润色，
+使之符合发布条件。
+
+在你选定了某个功能特性，为其撰写文档（主笔或辅助），请在 `#sig-docs` Slack 频道、SIG Docs 的每周例会上，
+或者在功能特性对应的 PR 上提出咨询。
+如果继续工作是没有问题的，你可以使用
+[向他人的 PR 中提交](/zh/docs/contribute/review/for-approvers/#commit-into-another-persons-pr)
+中描述的技术之一，参与 PR 的编辑工作。
+
+<!--
+### Find out about upcoming features
+
+To find out about upcoming features, attend the weekly SIG Release meeting (see
+the [community](https://kubernetes.io/community/) page for upcoming meetings)
+and monitor the release-specific documentation
+in the [kubernetes/sig-release](https://github.com/kubernetes/sig-release/)
+repository. Each release has a sub-directory in the [/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases)
+directory. The sub-directory contains a release schedule, a draft of the release
+notes, and a document listing each person on the release team.
+-->
+### 了解即将发布的功能特性
+
+要了解即将发布的功能特性，可以参加每周的 SIG Release 例会
+（参考[社区](https://kubernetes.io/community/)页面，了解即将召开的会议），
+监视 [kubernetes/sig-release](https://github.com/kubernetes/sig-release/)
+中与发行相关的文档。
+每个发行版本在
+[/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases)
+下都有一个对应的子目录。
+该子目录包含了发行版本的时间计划、发行公告的草稿以及列举发行团队名单的文档。
+
+<!--
+The release schedule contains links to all other documents, meetings,
+meeting minutes, and milestones relating to the release. It also contains
+information about the goals and timeline of the release, and any special
+processes in place for this release. Near the bottom of the document, several
+release-related terms are defined.
+
+This document also contains a link to the **Feature tracking sheet**, which is
+the official way to find out about all new features scheduled to go into the
+release.
+-->
+发行时间计划文件中包含到所有其他文档、会议、会议记录及发行相关的里程碑的链接。
+其中也包含关于发行版本的目标列表、时间线，以及当前发行版本中就绪的特殊流程的信息。
+文档末尾附近定义了若干与该发行版本有关的术语。
+
+此文档也包含到 **功能特性跟踪清单** 的链接。
+这一清单是了解哪些功能特性计划进入某发行版本的正式途径。
+
+<!--
+The release team document lists who is responsible for each release role. If
+it's not clear who to talk to about a specific feature or question you have,
+either attend the release meeting to ask your question, or contact the release
+lead so that they can redirect you.
+
+The release notes draft is a good place to find out about
+specific features, changes, deprecations, and more about the release. The
+content is not finalized until late in the release cycle, so use caution.
+-->
+发行团队文档列举了哪些人扮演着各个发行版本的不同角色。
+如果不清楚要联系谁来讨论特定的功能特性或者回答你的问题，
+你可以参加发行团队的会议，提出你的问题，或者联系发行团队的牵头人，
+这样他们就可以帮你找到正确的联系人。
+
+发行说明草稿是用来发现与特定发行版本相关的功能特性、变更、废弃以及其他信息的好来源。
+由于在发行周期的后段该文档的内容才会最终定稿，参考其中的信息时请谨慎。
+
+<!--
+### Feature tracking sheet
+
+The feature tracking sheet [for a given Kubernetes release](https://github.com/kubernetes/sig-release/tree/master/releases)
+lists each feature that is planned for a release.
+Each line item includes the name of the feature, a link to the feature's main
+GitHub issue, its stability level (Alpha, Beta, or Stable), the SIG and
+individual responsible for implementing it, whether it
+needs docs, a draft release note for the feature, and whether it has been
+merged. Keep the following in mind:
+-->
+### 特性跟踪清单 {#feature-tracking-sheet}
+
+针对[给定 Kubernetes 发行版本](https://github.com/kubernetes/sig-release/tree/master/releases)
+特性跟踪清单中列举的是计划包含于该版本中的每个功能特性。
+每一行中都包含特性的名称、特性对应的主要 GitHub Issue，其稳定性级别（ALpha、
+Beta 或 Stable）、负责实现该特性的 SIG 和个人、是否该特性需要文档、该特性的
+发行说明草稿以及该特性是否已经被合并等等。阅读此清单时请注意：
+
+<!--
+- Beta and Stable features are generally a higher documentation priority than
+  Alpha features.
+- It's hard to test (and therefore to document) a feature that hasn't been merged,
+  or is at least considered feature-complete in its PR.
+- Determining whether a feature needs documentation is a manual process and
+  just because a feature is not marked as needing docs doesn't mean it doesn't
+  need them.
+-->
+- Beta 和 Stable 功能特性通常比 Alpha 特性更为需要文档支持。
+- 如果某功能特性尚未被合并，就很难测试或者为其撰写文档。
+  对于对应的 PR 而言，也很难讲特性是否完全实现。
+- 确定某个功能特性是否需要对应的文档的过程是一个手动的过程。
+  即使某个功能特性没有标记需要文档，并不意味着该功能真的不需要任何文档。
+
+<!--
+## For developers or other SIG members
+
+This section is information for members of other Kubernetes SIGs documenting new features
+for a release.
+
+If you are a member of a SIG developing a new feature for Kubernetes, you need
+to work with SIG Docs to be sure your feature is documented in time for the
+release. Check the
+[feature tracking spreadsheet](https://github.com/kubernetes/sig-release/tree/master/releases)
+or check in the `#sig-release` Kubernetes Slack channel to verify scheduling details and
+deadlines.
+-->
+## 针对开发人员或其他 SIG 成员
+
+本节中的信息是针对为发行版本中新功能特性撰写文档的来自其他 Kubernetes SIGs
+的成员。
+
+如果你是某个 SIG 的成员，负责为 Kubernetes 开发某一项新的功能特性，你需要与
+SIG Docs 一起工作，确保这一新功能在发行之前已经为之撰写文档。
+请参考[特性跟踪清单](https://github.com/kubernetes/sig-release/tree/master/releases)
+或者 Kubernetes Slack 上的 `#sig-release` 频道，检查时间安排的细节以及截止日期。
+
+<!--
+### Open a placeholder PR
+
+1. Open a pull request against the
+`dev-{{< skew nextMinorVersion >}}` branch in the `kubernetes/website` repository, with a small
+commit that you will amend later.
+2. Use the Prow command `/milestone {{< skew nextMinorVersion >}}` to
+assign the PR to the relevant milestone. This alerts the docs person managing
+this release that the feature docs are coming.
+-->
+### 提交占位 PR {#open-a-placeholder-pr}
+
+1. 在 `kubernetes/website` 仓库上针对 `dev-{{< skew nextMinorVersion >}}`
+   分支提交一个 PR，其中包含较少的、待以后慢慢补齐的提交内容。
+1. 使用 Prow 命令  `/milestone {{< skew nextMinorVersion >}}` 将 PR
+   指派到对应的里程碑。这样做会提醒负责管理对应发行版本的文档团队成员，有
+   新的功能特性要合并到将来版本。
+
+<!--
+If your feature does not need
+any documentation changes, make sure the sig-release team knows this, by
+mentioning it in the `#sig-release` Slack channel. If the feature does need
+documentation but the PR is not created, the feature may be removed from the
+milestone.
+-->
+如果对应的功能特性不需要任何类型的文档变更，请通过在 `#sig-release` Slack
+频道声明这一点以确保 sig-release 团队了解。
+如果功能特性确实需要文档，而没有对应的 PR
+提交，该功能特性可能会被从里程碑中移除。
+
+<!--
+### PR ready for review
+
+When ready, populate your placeholder PR with feature documentation.
+
+Do your best to describe your feature and how to use it. If you need help
+structuring your documentation, ask in the `#sig-docs` slack channel.
+
+When you complete your content, the documentation person assigned to your
+feature reviews it. Use their suggestions to get the content to a release
+ready state.
+
+If your feature needs documentation and the first draft content is not
+received, the feature may be removed from the milestone.
+-->
+### PR 准备好评阅
+
+时机成熟时，你可以在你的占位 PR 中完成功能特性文档。
+
+尽可能为功能特性提供详尽文档以及使用说明。如果你需要文档组织方面的帮助，请
+在 `#sig-docs` Slack 频道中提问。
+
+当你已经完成内容撰写，指派给你的功能特性的文档贡献者会去评阅文档。
+尽量利用他们所给出的建议，改进文档内容以达到发布就绪状态。
+
+如果你的功能特性需要文档，而一直没有关于该特性的文档提交评阅，
+该特性可能会被从里程碑中移除。
+
+<!--
+### All PRs reviewed and ready to merge
+
+If your PR has not yet been merged into the `dev-{{< skew nextMinorVersion >}}` branch by the release deadline, work with the
+docs person managing the release to get it in by the deadline. If your feature needs
+documentation and the docs are not ready, the feature may be removed from the
+milestone.
+
+If your feature is an Alpha feature and is behind a feature gate, make sure you
+add it to [Alpha/Beta Feature gates](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) table
+as part of your pull request. If your feature is moving out of Alpha, make sure to
+remove it from that table.
+-->
+### 所有 PRs 均经过评审且合并就绪
+
+如果你的 PR 在发行截止日期之前尚未合并到 `dev-{{< skew nextMinorVersion >}}` 分支，
+请与负责管理该发行版本的文档团队成员一起合作，在截止期限之前将其合并。
+如果功能特性需要文档，而文档并未就绪，该特性可能会被从里程碑中去除。
+
+如果你的功能特性是 Alpha 阶段，并且受到某个特性门控的保护，在你的 PR 中，请确保将
+该特性门控添加到
+[Alpha/Beta 特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features)
+表格中。
+如果你的功能特性不再是 Alpha 阶段，请确保特性门控状态得到更新。
+
diff --git a/content/zh/docs/contribute/new-content/open-a-pr.md b/content/zh/docs/contribute/new-content/open-a-pr.md
new file mode 100644
index 0000000000..c20b36d560
--- /dev/null
+++ b/content/zh/docs/contribute/new-content/open-a-pr.md
@@ -0,0 +1,883 @@
+---
+title: 发起拉取请求（PR）
+slug: new-content
+content_type: concept
+weight: 10
+card:
+  name: 贡献
+  weight: 40
+---
+<!--
+title: Opening a pull request
+slug: new-content
+content_type: concept
+weight: 10
+card:
+  name: contribute
+  weight: 40
+-->
+
+<!-- overview -->
+<!--
+{{< note >}}
+**Code developers**: If you are documenting a new feature for an
+upcoming Kubernetes release, see
+[Document a new feature](/docs/contribute/new-content/new-features/).
+{{< /note >}}
+
+To contribute new content pages or improve existing content pages, open a pull request (PR). Make sure you follow all the requirements in the [Before you begin](/docs/contribute/new-content/overview/#before-you-begin) section.
+-->
+{{< note >}}
+**代码开发者们**：如果你在为下一个 Kubernetes 发行版本中的某功能特性
+撰写文档，请参考[为新功能撰写文档](/zh/docs/contribute/new-content/new-features/)。
+{{< /note >}}
+
+要贡献新的内容页面或者改进已有内容页面，请发起拉取请求（PR）。
+请确保你满足了[开始之前](/zh/docs/contribute/new-content/overview/#before-you-begin)
+节中所列举的所有要求。
+
+<!--
+If your change is small, or you're unfamiliar with git, read [Changes using
+GitHub](#changes-using-github) to learn how to edit a page.
+
+If your changes are large, read [Work from a local fork](#fork-the-repo) to
+learn how to make changes locally on your computer.
+-->
+如果你所提交的变更足够小，或者你对 git 工具不熟悉，可以阅读
+[使用 GitHub 提交变更](#changes-using-github)以了解如何编辑页面。
+
+如果所提交的变更较大，请阅读[基于本地克隆副本开展工作](#fork-the-repo)以学习
+如何在你本地计算机上构造变更。
+
+<!-- body -->
+
+<!--
+## Changes using GitHub
+
+If you're less experienced with git workflows, here's an easier method of
+opening a pull request.
+
+1.  On the page where you see the issue, select the pencil icon at the top right.
+    You can also scroll to the bottom of the page and select **Edit this page**.
+2.  Make your changes in the GitHub markdown editor.
+3.  Below the editor, fill in the **Propose file change**
+    form. In the first field, give your commit message a title. In
+    the second field, provide a description.
+-->
+## 使用 GitHub 提交变更 {#changes-using-github}
+
+如果你在 git 工作流方面欠缺经验，这里有一种发起拉取请求的更为简单的方法。
+
+1. 在你发现问题的网页，选择右上角的铅笔图标。你也可以滚动到页面底端，选择
+   **编辑此页面**。
+2. 在 GitHub 的 Markdown 编辑器中修改内容。
+3. 在编辑器的下方，填写 **建议文件变更** 表单。
+   在第一个字段中，为你的提交消息取一个标题。
+   在第二个字段中，为你的提交写一些描述文字。
+
+   {{< note >}}
+   不要在提交消息中使用 [GitHub 关键词](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)
+   你可以在后续的 PR 描述中使用这些关键词。
+   {{< /note >}}
+<!--
+4.  Select **Propose file change**.
+
+5.  Select **Create pull request**.
+
+6.  The **Open a pull request** screen appears. Fill in the form:
+
+    - The **Subject** field of the pull request defaults to the commit summary.
+    You can change it if needed.
+    - The **Body** contains your extended commit message, if you have one,
+    and some template text. Add the
+    details the template text asks for, then delete the extra template text.
+    - Leave the **Allow edits from maintainers** checkbox selected.
+-->
+4. 选择 **Propose File Change**.
+5. 选择 **Create pull request**.
+6. 在 **Open a pull request** 屏幕上填写表单：
+
+    - **Subject** 字段默认为提交的概要信息。你可以根据需要修改它。
+    - **Body** 字段包含更为详细的提交消息，如果你之前有填写过的话，以及一些模板文字。
+      填写模板所要求的详细信息，之后删除多余的模板文字。
+    - 确保 **Allow edits from maintainers** 复选框被勾选。
+
+   <!--
+   PR descriptions are a great way to help reviewers understand your change. For
+   more information, see [Opening a PR](#open-a-pr).
+   -->
+   {{< note >}}
+   PR 描述信息是帮助 PR 评阅人了解你所提议的变更的重要途径。
+   更多信息请参考[发起一个 PR](#open-a-pr).
+   {{< /note >}}
+
+<!-- 7.  Select **Create pull request**.  -->
+7. 选择 **Create pull request**.
+
+<!--
+### Addressing feedback in GitHub
+
+Before merging a pull request, Kubernetes community members review and
+approve it. The `k8s-ci-robot` suggests reviewers based on the nearest
+owner mentioned in the pages. If you have someone specific in mind,
+leave a comment with their GitHub username in it.
+-->
+### 在 GitHub 上处理反馈意见
+
+在合并 PR 之前，Kubernetes 社区成员会评阅并批准它。
+`k8s-ci-robot` 会基于页面中最近提及的属主来建议评阅人（reviewers）。
+如果你希望特定某人来评阅，可以留下评论，提及该用户的 GitHub 用户名。
+
+<!--
+If a reviewer asks you to make changes:
+
+1. Go to the **Files changed** tab.
+2. Select the pencil (edit) icon on any files changed by the
+pull request.
+3. Make the changes requested.
+4. Commit the changes.
+
+If you are waiting on a reviewer, reach out once every 7 days. You can also post a message in the `#sig-docs` Slack channel.
+
+When your review is complete, a reviewer merges your PR and your changes go live a few minutes later.
+-->
+如果某个评阅人请你修改 PR：
+
+1. 前往 **Files changed** Tab 页面；
+1. 选择 PR 所修改的任何文件所对应的铅笔（edit）图标；
+1. 根据建议作出修改；
+1. 提交所作修改。
+
+如果你希望等待评阅人的反馈，可以每 7 天左右联系一次。
+你也可以在 `#sig-docs` Slack 频道发送消息。
+
+当评阅过程结束，某个评阅人会合并你的 PR。
+几分钟之后，你所做的变更就会上线了。
+
+<!--
+## Work from a local fork {#fork-the-repo}
+
+If you're more experienced with git, or if your changes are larger than a few lines,
+work from a local fork.
+
+Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed on your computer. You can also use a git UI application.
+-->
+## 基于本地克隆副本开展工作 {#work-from-a-local-fork}
+
+如果你有 git 的使用经验，或者你要提议的修改不仅仅几行，请使用本地克隆副本
+来开展工作。
+
+首先要确保你在本地计算机上安装了 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)。
+你也可以使用 git 的带用户界面的应用。
+
+<!--
+### Fork the kubernetes/website repository
+
+1. Navigate to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
+2. Select **Fork**.
+-->
+### 派生 kubernetes/website 仓库
+
+1. 前往 [`kubernetes/website`](https://github.com/kubernetes/website/) 仓库；
+2. 选择 **Fork**.
+
+<!--
+### Create a local clone and set the upstream
+
+3. In a terminal window, clone your fork:
+-->
+### 创建一个本地克隆副本并指定 upstream 仓库
+
+3. 打开终端窗口，克隆你所派生的副本：
+
+    ```bash
+    git clone git@github.com/<github_username>/website
+    ```
+
+<!--
+4. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote:
+-->
+4. 前往新的 `website` 目录，将 `kubernetes/website` 仓库设置为 `upstream`
+   远端：
+
+      ```bash
+      cd website
+      git remote add upstream https://github.com/kubernetes/website.git
+      ```
+
+<!--
+5. Confirm your `origin` and `upstream` repositories:
+-->
+5. 确认你现在有两个仓库，`origin` 和 `upstream`：
+
+    ```bash
+    git remote -v
+    ```
+
+    <!-- Output is similar to: -->
+    输出类似于：
+
+    ```bash
+    origin	git@github.com:<github_username>/website.git (fetch)
+    origin	git@github.com:<github_username>/website.git (push)
+    upstream	https://github.com/kubernetes/website (fetch)
+    upstream	https://github.com/kubernetes/website (push)
+    ```
+<!--
+6. Fetch commits from your fork's `origin/master` and `kubernetes/website`'s `upstream/master`:
+-->
+6. 从你的克隆副本取回 `origin/master` 分支，从 `kubernetes/website` 取回 `upstream/master`：
+
+    ```bash
+    git fetch origin
+    git fetch upstream
+    ```
+   <!--
+   This makes sure your local repository is up to date before you start making changes.
+   -->
+   这样可以确保你本地的仓库在开始工作前是最新的。
+
+   <!--
+    This workflow is different than the [Kubernetes Community GitHub Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). You do not need to merge your local copy of `master` with `upstream/master` before pushing updates to your fork.
+   -->
+    {{< note >}}
+    此工作流程与 [Kubernetes 社区 GitHub 工作流](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)有所不同。在推送你的变更到你的远程派生副本库之前，你不需要将你本地的 `master` 与 `upstream/master` 合并。
+    {{< /note >}}
+
+<!--
+### Create a branch
+
+1. Decide which branch base to your work on:
+
+  - For improvements to existing content, use `upstream/master`.
+  - For new content about existing features, use `upstream/master`.
+  - For localized content, use the localization's conventions. For more information, see [localizing Kubernetes documentation](/docs/contribute/localization/).
+  - For new features in an upcoming Kubernetes release, use the feature branch. For more information, see [documenting for a release](/docs/contribute/new-content/new-features/).
+  - For long-running efforts that multiple SIG Docs contributors collaborate on,
+    like content reorganization, use a specific feature branch created for that
+    effort.
+
+    If you need help choosing a branch, ask in the `#sig-docs` Slack channel.
+-->
+### 创建一个分支
+
+1. 决定你要基于哪个分支来开展工作：
+
+   - 针对已有内容的改进，请使用 `upstream/master`；
+   - 针对已有功能特性的新文档内容，请使用 `upstream/master`；
+   - 对于本地化内容，请基于本地化的约定。
+     可参考[对 Kubernetes 文档进行本地化](/zh/docs/contribute/localization/)了解详细信息。
+   - 对于在下一个 Kubernetes 版本中新功能特性的文档，使用独立的功能特性分支。
+     参考[为发行版本功能特性撰写文档](/zh/docs/contribute/new-content/new-features/)了解更多信息。
+   - 对于很多 SIG Docs 共同参与的，需较长时间才完成的任务，例如内容的重构，
+     请使用为该任务创建的特性分支。
+
+   如果你在选择分支上需要帮助，请在 `#sig-docs` Slack 频道提问。
+
+<!--
+2. Create a new branch based on the branch identified in step 1. This example assumes the base branch is `upstream/master`:
+-->
+2. 基于第一步中选定的分支，创建新分支。
+   下面的例子假定基础分支是 `upstream/master`：
+
+    ```bash
+    git checkout -b <my_new_branch> upstream/master
+    ```
+<!--
+3.  Make your changes using a text editor.
+-->
+3. 使用文本编辑器开始构造变更。
+
+<!--
+At any time, use the `git status` command to see what files you've changed.
+-->
+在任何时候，都可以使用 `git status` 命令查看你所改变了的文件列表。
+
+<!--
+### Commit your changes
+
+When you are ready to submit a pull request, commit your changes.
+-->
+### 提交你的变更
+
+当你准备好发起拉取请求（PR）时，提交你所做的变更。
+
+<!--
+1. In your local repository, check which files you need to commit:
+
+    ```bash
+    git status
+    ```
+
+    Output is similar to:
+
+    ```bash
+    On branch <my_new_branch>
+    Your branch is up to date with 'origin/<my_new_branch>'.
+
+    Changes not staged for commit:
+    (use "git add <file>..." to update what will be committed)
+    (use "git checkout -- <file>..." to discard changes in working directory)
+
+    modified:   content/en/docs/contribute/new-content/contributing-content.md
+
+    no changes added to commit (use "git add" and/or "git commit -a")
+    ```
+-->
+1. 在你的本地仓库中，检查你要提交的文件：
+
+    ```bash
+    git status
+    ```
+
+    输出类似于：
+
+    ```bash
+    On branch <my_new_branch>
+    Your branch is up to date with 'origin/<my_new_branch>'.
+
+    Changes not staged for commit:
+    (use "git add <file>..." to update what will be committed)
+    (use "git checkout -- <file>..." to discard changes in working directory)
+
+    modified:   content/en/docs/contribute/new-content/contributing-content.md
+
+    no changes added to commit (use "git add" and/or "git commit -a")
+    ```
+
+<!--
+2. Add the files listed under **Changes not staged for commit** to the commit:
+
+    ```bash
+    git add <your_file_name>
+    ```
+
+    Repeat this for each file.
+-->
+2. 将 **Changes not staged for commit** 下列举的文件添加到提交中：
+
+    ```bash
+    git add <your_file_name>
+    ```
+
+    针对每个文件重复此操作。
+<!--
+3.  After adding all the files, create a commit:
+
+    ```bash
+    git commit -m "Your commit message"
+    ```
+
+    {{< note >}}
+    Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request
+    description later.
+    {{< /note >}}
+-->
+3. 添加完所有文件之后，创建一个提交（commit）：
+
+    ```bash
+    git commit -m "Your commit message"
+    ```
+
+    {{< note >}}
+    不要在提交消息中使用任何 [GitHub 关键字](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)。
+    你可以在后面创建 PR 时使用这些关键字。
+    {{< /note >}}
+<!--
+4. Push your local branch and its new commit to your remote fork:
+
+    ```bash
+    git push origin <my_new_branch>
+    ```
+-->
+4. 推送你本地分支及其中的新提交到你的远程派生副本库：
+
+    ```bash
+    git push origin <my_new_branch>
+    ```
+
+<!--
+### Preview your changes locally {#preview-locally}
+
+It's a good idea to preview your changes locally before pushing them or opening a pull request. A preview lets you catch build errors or markdown formatting problems.
+
+You can either build the website's container image or run Hugo locally. Building the container image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging.
+-->
+### 在本地预览你的变更 {#preview-locally}
+
+在推送变更或者发起 PR 之前在本地查看一下预览是个不错的注意。
+通过预览你可以发现构建错误或者 Markdown 格式问题。
+
+你可以构造网站的容器镜像或者在本地运行 Hugo。
+构造容器镜像的方式比较慢，不过能够显示 [Hugo 短代码（shortcodes）](/zh/docs/contribute/style/hugo-shortcodes/)，
+因此对于调试是很有用的。
+
+{{< tabs name="tab_with_hugo" >}}
+{{% tab name="在容器内执行 Hugo" %}}
+
+<!--
+The following commmand uses Docker as the default container engine.
+You can set up the `CONTAINER_ENGINE` to override this behavior.
+-->
+{{< note >}}
+下面的命令中使用 Docker 作为默认的容器引擎。
+如果需要重载这一行为，可以设置 `CONTAINER_ENGINE`。
+{{< /note >}}
+
+<!--
+1.  Build the image locally:
+-->
+1. 在本地构造镜像；
+
+      ```bash
+      # 使用 docker (默认)
+      make container-image
+
+      ### 或 ###
+
+      # 使用 podman
+      CONTAINER_ENGINE=podman make container-image
+      ```
+
+<!--
+2. After building the `kubernetes-hugo` image locally, build and serve the site:
+-->
+2. 在本地构造了 `kubernetes-hugo` 镜像之后，可以构造并启动网站：
+
+      ```bash
+      # 使用 docker (默认)
+      make container-serve
+
+      ### 或 ###
+
+      # 使用 podman
+      CONTAINER_ENGINE=podman make container-serve
+      ```
+<!--
+3.  In a web browser, navigate to `https://localhost:1313`. Hugo watches the
+    changes and rebuilds the site as needed.
+4.  To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
+    or close the terminal window.
+-->
+3. 启动浏览器，浏览 `https://localhost:1313`。
+   Hugo 会监测文件的变更并根据需要重新构建网站。
+
+4. 要停止本地 Hugo 实例，可返回到终端并输入 `Ctrl+C`，或者关闭终端窗口。
+
+{{% /tab %}}
+{{% tab name="在命令行执行 Hugo" %}}
+
+<!--
+Alternately, install and use the `hugo` command on your computer:
+-->
+另一种方式是，在你的本地计算机上安装并使用 `hugo` 命令：
+
+<!--
+1.  Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml).
+2.  In a terminal, go to your Kubernetes website repository and start the Hugo server:
+-->
+1. 安装 [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml)
+   文件中指定的 [Hugo](https://gohugo.io/getting-started/installing/) 版本。
+
+2. 启动一个终端窗口，进入 Kubernetes 网站仓库目录，启动 Hugo 服务器：
+
+      ```bash
+      cd <path_to_your_repo>/website
+      hugo server
+      ```
+<!--
+3.  In your browser’s address bar, enter `https://localhost:1313`.
+4.  To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
+    or close the terminal window.
+-->
+3. 在浏览器的地址栏输入： `https://localhost:1313`。
+4. 要停止本地 Hugo 实例，返回到终端窗口并输入 `Ctrl+C` 或者关闭终端窗口。
+{{% /tab %}}
+{{< /tabs >}}
+
+<!--
+### Open a pull request from your fork to kubernetes/website {#open-a-pr}
+-->
+### 从你的克隆副本向 kubernetes/website 发起拉取请求（PR） {#open-a-pr}
+
+<!--
+1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
+2. Select **New Pull Request**.
+3. Select **compare across forks**.
+4. From the **head repository** drop-down menu, select your fork.
+5. From the **compare** drop-down menu, select your branch.
+6. Select **Create Pull Request**.
+7. Add a description for your pull request:
+    - **Title** (50 characters or less): Summarize the intent of the change.
+    - **Description**: Describe the change in more detail.
+      - If there is a related GitHub issue, include `Fixes #12345` or `Closes #12345` in the description. GitHub's automation closes the mentioned issue after merging the PR if used. If there are other related PRs, link those as well.
+      - If you want advice on something specific, include any questions you'd like reviewers to think about in your description.
+8. Select the **Create pull request** button.
+
+   Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls).
+-->
+1. 在 Web 浏览器中，前往 [`kubernetes/website`](https://github.com/kubernetes/website/) 仓库；
+2. 点击 **New Pull Request**；
+3. 选择 **compare across forks**；
+4. 从 **head repository** 下拉菜单中，选取你的派生仓库；
+5. 从 **compare** 下拉菜单中，选择你的分支；
+6. 点击 **Create Pull Request**；
+7. 为你的拉取请求添加一个描述：
+    - **Title** （不超过 50 个字符）：总结变更的目的；
+    - **Description**：给出变更的详细信息；
+      - 如果存在一个相关联的 GitHub Issue，可以在描述中包含 `Fixes #12345` 或
+        `Closes #12345`。GitHub 的自动化设施能够在当前 PR 被合并时自动关闭所提及
+        的 Issue。如果有其他相关联的 PR，也可以添加对它们的链接。
+      - 如果你尤其希望获得某方面的建议，可以在描述中包含你希望评阅人思考的问题。
+8. 点击 **Create pull request** 按钮。
+
+   祝贺你! 你的拉取请求现在出现在 [Pull Requests](https://github.com/kubernetes/website/pulls) 列表中了！
+
+<!--
+After opening a PR, GitHub runs automated tests and tries to deploy a preview using [Netlify](https://www.netlify.com/).
+
+  - If the Netlify build fails, select **Details** for more information.
+  - If the Netlify build succeeds, select **Details** opens a staged version of the Kubernetes website with your changes applied. This is how reviewers check your changes.
+
+GitHub also automatically assigns labels to a PR, to help reviewers. You can add them too, if needed. For more information, see [Adding and removing issue labels](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels).
+-->
+在发起 PR 之后，GitHub 会执行一些自动化的测试，并尝试使用
+[Netlify](https://www.netlify.com/) 部署一个预览版本。
+
+  - 如果 Netlify 构建操作失败，可选择 **Details** 了解详细信息。
+  - 如果 Netlify 构建操作成功，选择 **Details** 会打开 Kubernetes 的一个预览
+    版本，其中包含了你所作的变更。评阅人也使用这一功能来检查你的变更。
+
+GitHub 也会自动为 PR 分派一些标签，以帮助评阅人。
+如果有需要，你也可以向 PR 添加标签。
+欲了解相关详细信息，可以参考
+[添加和删除 Issue 标签](/zh/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels)。
+
+<!--
+### Addressing feedback locally
+
+1. After making your changes, amend your previous commit:
+-->
+### 在本地处理反馈
+
+1. 在本地完成修改之后，可以修补（amend）你之前的提交：
+
+    ```bash
+    git commit -a --amend
+    ```
+
+    <!--
+    - `-a`: commits all changes
+    - `--amend`: amends the previous commit, rather than creating a new one
+    -->
+    - `-a`：提交所有修改
+    - `--amend`：对前一次提交进行增补，而不是创建新的提交
+
+<!--
+2. Update your commit message if needed.
+3. Use `git push origin <my_new_branch>` to push your changes and re-run the Netlify tests.
+-->
+2. 如果有必要，更新你的提交消息；
+3. 使用 `git push origin <my_new_branch>` 来推送你的变更，重新出发 Netlify 测试。
+
+   <!--
+   If you use `git commit -m` instead of amending, you must
+   [squash your commits](#squashing-commits) before merging.
+   -->
+   {{< note >}}
+   如果你使用 `git commit -m` 而不是增补参数，在 PR 最终合并之前你必须
+   [squash 你的提交](#squashing-commits)。
+   {{< /note >}}
+
+<!--
+#### Changes from reviewers
+
+Sometimes reviewers commit to your pull request. Before making any other changes, fetch those commits.
+
+1. Fetch commits from your remote fork and rebase your working branch:
+-->
+#### 来自评阅人的修改
+
+有时评阅人会向你的 PR 中提交修改。在作出其他修改之前，请先取回这些提交。
+
+1. 从你的远程派生副本仓库取回提交，让你的工作分支基于所取回的分支：
+
+    ```bash
+    git fetch origin
+    git rebase origin/<your-branch-name>
+    ```
+<!--
+2. After rebasing, force-push new changes to your fork:
+-->
+2. 变更基线（rebase）操作完成之后，强制推送本地的新改动到你的派生仓库：
+
+    ```bash
+    git push --force-with-lease origin <your-branch-name>
+    ```
+
+<!--
+#### Merge conflicts and rebasing
+
+{{< note >}}
+For more information, see [Git Branching - Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [Advanced Merging](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging), or ask in the `#sig-docs` Slack channel for help.
+{{< /note >}}
+-->
+#### 合并冲突和重设基线
+
+{{< note >}}
+要了解更多信息，可参考
+[Git 分支管理 - 基本分支和合并](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts)、
+[高级合并](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)、
+或者在 `#sig-docs` Slack 频道寻求帮助。
+{{< /note >}}
+
+<!--
+If another contributor commits changes to the same file in another PR, it can create a merge conflict. You must resolve all merge conflicts in your PR.
+
+1. Update your fork and rebase your local branch:
+-->
+如果另一个贡献者在别的 PR 中提交了对同一文件的修改，这可能会造成合并冲突。
+你必须在你的 PR 中解决所有合并冲突。
+
+1. 更新你的派生副本，重设本地分支的基线：
+
+   ```bash
+   git fetch origin
+   git rebase origin/<your-branch-name>
+   ```
+
+   <!-- Then force-push the changes to your fork:-->
+   之后强制推送修改到你的派生副本仓库：
+
+   ```bash
+   git push --force-with-lease origin <your-branch-name>
+   ```
+<!--
+2. Fetch changes from `kubernetes/website`'s `upstream/master` and rebase your branch:
+-->
+2. 从 `kubernetes/website` 的 `upstream/master` 分支取回更改，然后重设本地分支的基线：
+
+   ```bash
+   git fetch upstream
+   git rebase upstream/master
+   ```
+<!--
+3. Inspect the results of the rebase:
+-->
+3. 检查重设基线操作之后的状态：
+
+   ```bash
+   git status
+   ```
+
+   <!-- This results in a number of files marked as conflicted. -->
+   你会看到一组存在冲突的文件。
+
+<!--
+4. Open each conflicted file and look for the conflict markers: `>>>`, `<<<`, and `===`. Resolve the conflict and delete the conflict marker.
+-->
+4. 打开每个存在冲突的文件，查找冲突标记：`>>>`、`<<<` 和 `===`。
+   解决完冲突之后删除冲突标记。
+
+    <!--
+    For more information, see [How conflicts are presented](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented).
+    -->
+    {{< note >}}
+    进一步的详细信息可参见
+    [冲突是怎样表示的](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented).
+    {{< /note >}}
+
+<!--
+5. Add the files to the changeset:
+-->
+5. 添加文件到变更集合：
+
+    ```bash
+    git add <filename>
+    ```
+<!--
+6.  Continue the rebase:
+-->
+6. 继续执行基线变更（rebase）操作：
+
+    ```bash
+    git rebase --continue
+    ```
+
+<!--
+7.  Repeat steps 2 to 5 as needed.
+
+    After applying all commits, the `git status` command shows that the rebase is complete.
+-->
+7. 根据需要重复步骤 2 到 5。
+
+   在应用完所有提交之后，`git status` 命令会显示 rebase 操作完成。
+
+<!--
+8. Force-push the branch to your fork:
+-->
+8. 将分支强制推送到你的派生仓库：
+
+    ```bash
+    git push --force-with-lease origin <your-branch-name>
+    ```
+
+    <!-- The pull request no longer shows any conflicts. -->
+    PR 不再显示存在冲突。
+
+<!--
+### Squashing commits
+-->
+### 压缩（Squashing）提交 {#squashing-commits}
+
+<!--
+For more information, see [Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History), or ask in the `#sig-docs` Slack channel for help.
+-->
+{{< note >}}
+要了解更多信息，可参看
+[Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)，
+或者在 `#sig-docs` Slack 频道寻求帮助。
+{{< /note >}}
+
+<!--
+If your PR has multiple commits, you must squash them into a single commit before merging your PR. You can check the number of commits on your PR's **Commits** tab or by running the `git log` command locally.
+-->
+如果你的 PR 包含多个提交（commits），你必须将其压缩成一个提交才能被合并。
+你可以在 PR 的 **Commits** Tab 页面查看提交个数，也可以在本地通过
+`git log` 命令查看提交个数。
+
+<!-- This topic assumes `vim` as the command line text editor.-->
+{{< note >}}
+本主题假定使用 `vim` 作为命令行文本编辑器。
+{{< /note >}}
+
+<!--
+1. Start an interactive rebase:
+-->
+1. 启动一个交互式的 rebase 操作：
+
+    ```bash
+    git rebase -i HEAD~<number_of_commits_in_branch>
+    ```
+
+    <!--
+    Squashing commits is a form of rebasing. The `-i` switch tells git you want to rebase interactively. `HEAD~<number_of_commits_in_branch` indicates how many commits to look at for the rebase.
+    -->
+    压缩提交的过程也是一种重设基线的过程。
+    这里的 `-i` 开关告诉 git 你希望交互式地执行重设基线操作。
+    `HEAD~<number_of_commits_in_branch` 表明在 rebase 操作中查看多少个提交。
+
+    <!--Output is similar to:-->
+    输出类似于；
+
+    ```bash
+    pick d875112ca Original commit
+    pick 4fa167b80 Address feedback 1
+    pick 7d54e15ee Address feedback 2
+
+    # Rebase 3d18sf680..7d54e15ee onto 3d183f680 (3 commands)
+
+    ...
+
+    # These lines can be re-ordered; they are executed from top to bottom.
+    ```
+
+    <!--
+    The first section of the output lists the commits in the rebase. The second section lists the options for each commit. Changing the word `pick` changes the status of the commit once the rebase is complete.
+
+    For the purposes of rebasing, focus on `squash` and `pick`.
+    -->
+    输出的第一部分列举了重设基线操作中的提交。
+    第二部分给出每个提交的选项。
+    改变单词 `pick` 就可以改变重设基线操作之后提交的状态。
+
+    就重设基线操作本身，我们关注 `squash` 和 `pick` 选项。
+
+    <!--
+    For more information, see [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode).
+    -->
+    {{< note >}}
+    进一步的详细信息可参考 [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode)。
+    {{< /note >}}
+
+<!--
+2. Start editing the file.
+    Change the original text:
+-->
+
+2. 开始编辑文件。
+
+    修改原来的文本：
+
+    ```bash
+    pick d875112ca Original commit
+    pick 4fa167b80 Address feedback 1
+    pick 7d54e15ee Address feedback 2
+    ```
+
+    <!-- To: -->
+    使之成为：
+
+    ```bash
+    pick d875112ca Original commit
+    squash 4fa167b80 Address feedback 1
+    squash 7d54e15ee Address feedback 2
+    ```
+
+    <!--
+    This squashes commits `4fa167b80 Address feedback 1` and `7d54e15ee Address feedback 2` into `d875112ca Original commit`, leaving only `d875112ca Original commit` as a part of the timeline.
+    -->
+    以上编辑操作会压缩提交 `4fa167b80 Address feedback 1` 和 `7d54e15ee Address feedback 2`
+    到 `d875112ca Original commit` 中，只留下 `d875112ca Original commit` 成为时间线中的一部分。
+
+<!--
+3. Save and exit your file.
+4. Push your squashed commit:
+-->
+3. 保存文件并退出编辑器。
+
+4. 推送压缩后的提交：
+
+    ```bash
+    git push --force-with-lease origin <branch_name>
+    ```
+
+<!--
+## Contribute to other repos
+
+The [Kubernetes project](https://github.com/kubernetes) contains 50+ repositories. Many of these repositories contain documentation: user-facing help text, error messages, API references or code comments.
+
+If you see text you'd like to improve, use GitHub to search all repositories in the Kubernetes organization.
+This can help you figure out where to submit your issue or PR.
+-->
+## 贡献到其他仓库
+
+[Kubernetes 项目](https://github.com/kubernetes)包含大约 50 多个仓库。
+这些仓库中很多都有文档：提供给最终用户的帮助文本、错误信息、API 参考或者代码注释等。
+
+如果你发现有些文本需要改进，可以使用 GitHub 来搜索 Kubernetes 组织下的所有仓库。
+这样有助于发现要在哪里提交 Issue 或 PR。
+
+<!--
+Each repository has its own processes and procedures. Before you file an
+issue or submit a PR, read that repository's `README.md`, `CONTRIBUTING.md`, and
+`code-of-conduct.md`, if they exist.
+
+Most repositories use issue and PR templates. Have a look through some open
+issues and PRs to get a feel for that team's processes. Make sure to fill out
+the templates with as much detail as possible when you file issues or PRs.
+-->
+每个仓库有其自己的流程和过程。在登记 Issue 或者发起 PR 之前，记得阅读仓库的
+`README.md`、`CONTRIBUTING.md` 和 `code-of-conduct.md` 文件，如果有的话。
+
+大多数仓库都有自己的 Issue 和 PR 模版。通过查看一些待解决的 Issues 和
+PR，也可以添加对它们的链接。你可以多少了解该团队的流程。
+在登记 Issue 或提出 PR 时，务必尽量填充所给的模版，多提供详细信息。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+- Read [Reviewing](/docs/contribute/reviewing/revewing-prs) to learn more about the review process.
+-->
+- 阅读[评阅](/zh/docs/contribute/review/revewing-prs)节，学习评阅过程。
+
diff --git a/content/zh/docs/contribute/new-content/overview.md b/content/zh/docs/contribute/new-content/overview.md
new file mode 100644
index 0000000000..0deead5b8d
--- /dev/null
+++ b/content/zh/docs/contribute/new-content/overview.md
@@ -0,0 +1,122 @@
+---
+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 | `master`
+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.
+-->
+### 选择要使用的分支
+
+在发起拉取请求时，你需要预先知道要基于哪个分支来开展工作。
+
+场景      | 分支
+:---------|:------------
+针对当前发行版本的，对现有英文内容的修改或新的英文内容 | `master`
+针对功能特性变更的内容 | 功能特性所对应的版本所对应的分支，分支名字模式为 `dev-release-<version>`。例如，如果某功能特性在 `{{< latest-version >}}` 版本发生变化，则对应的文档变化要添加到 `dev-{{< release-branch >}}` 分支。
+其他语言的内容（本地化）| 基于本地化团队的约定。参见[本地化分支策略](/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/master/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/master/content/en/docs/doc-contributor-tools)
+目录中包含了一些工具，能够助你的贡献过程更为顺畅。
+