whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #22245 from tengqm/sync-zh-contrib-4

Browse Source 
[zh] Sync contribution guides (4)
This commit is contained in:
Kubernetes Prow Robot
2020-07-03 00:10:48 -07:00
committed by GitHub
parent 915cd026dc 6b196a152b
commit 3f8c9fe65d
5 changed files with 1384 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/contribute/new-content/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: 贡献新内容
weight: 20
---
content/zh/docs/contribute/new-content/blogs-case-studies.md
+108
View File
@@ -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" %}}
content/zh/docs/contribute/new-content/new-features.md
+267
View File
@@ -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 阶段，请确保特性门控状态得到更新。
content/zh/docs/contribute/new-content/open-a-pr.md
+883
View File
@@ -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)节，学习评阅过程。
content/zh/docs/contribute/new-content/overview.md
+122
View File
@@ -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)
目录中包含了一些工具，能够助你的贡献过程更为顺畅。