Skip to content

Commit 3f8c9fe

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request #22245 from tengqm/sync-zh-contrib-4
[zh] Sync contribution guides (4)
2 parents 915cd02 + 6b196a1 commit 3f8c9fe

File tree

5 files changed

+1384
-0
lines changed

5 files changed

+1384
-0
lines changed

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

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
---
2+
title: 贡献新内容
3+
weight: 20
4+
---

‎content/zh/docs/contribute/new-content/blogs-case-studies.md

Lines changed: 108 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,108 @@
1+
---
2+
title: 提交博客和案例分析
3+
linktitle: 博客和案例分析
4+
slug: blogs-case-studies
5+
content_type: concept
6+
weight: 30
7+
---
8+
<!--
9+
title: Submitting blog posts and case studies
10+
linktitle: Blogs and case studies
11+
slug: blogs-case-studies
12+
content_type: concept
13+
weight: 30
14+
-->
15+
16+
<!-- overview -->
17+
<!--
18+
Anyone can write a blog post and submit it for review.
19+
Case studies require extensive review before they're approved.
20+
-->
21+
任何人都可以撰写博客并提交评阅。
22+
案例分析则在被批准之前需要更多的评阅。
23+
24+
<!-- body -->
25+
<!--
26+
## Write a blog post
27+
28+
Blog posts should not be
29+
vendor pitches. They must contain content that applies broadly to
30+
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).
31+
-->
32+
## 撰写博文 {#write-a-blog-post}
33+
34+
博客内容不可以是销售用语。
35+
其中的内容必须是对整个 Kubernetes 社区中很多人都有参考意义。
36+
SIG Docs [blog 子项目](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject)
37+
负责管理博客的评阅过程。
38+
更多信息可参考[提交博文](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post)。
39+
40+
<!--
41+
To submit a blog post, you can either:
42+
43+
- Use the
44+
[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform)
45+
- [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.
46+
47+
If you open a pull request, ensure that your blog post follows the correct naming conventions and frontmatter information:
48+
49+
- 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`.
50+
- The front matter must include the following:
51+
-->
52+
要提交博文，你可以：
53+
54+
- 使用 [Kubernetes 博客提交表单](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform)
55+
- [发起一个包含博文的 PR](/zh/docs/contribute/new-content/new-content/#fork-the-repo)。
56+
新博文要创建于 [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) 目录下。
57+
58+
如果你要发起一个 PR，请确保所提交的博文遵从正确的命名规范和前言信息：
59+
60+
- Markdown 文件名必须遵从 `YYY-MM-DD-Your-Title-Here.md` 格式。
61+
例如，`2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
62+
- 前言部分必须包含以下内容：
63+
64+
<!--
65+
```yaml
66+
---
67+
layout: blog
68+
title: "Your Title Here"
69+
date: YYYY-MM-DD
70+
slug: text-for-URL-link-here-no-spaces
71+
---
72+
```
73+
-->
74+
```yaml
75+
---
76+
layout: blog
77+
title: "博文标题"
78+
date: YYYY-MM-DD
79+
slug: text-for-URL-link-here-no-spaces
80+
---
81+
```
82+
83+
<!--
84+
## Submit a case study
85+
86+
Case studies highlight how organizations are using Kubernetes to solve
87+
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.
88+
89+
Have a look at the source for the
90+
[existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies).
91+
92+
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.
93+
-->
94+
## 提交案例分析
95+
96+
案例分析用来概述组织如何使用 Kubernetes 解决现实世界的问题。
97+
Kubernetes 市场化团队和 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 成员
98+
会与你一起工作，撰写所有的案例分析。
99+
100+
请查看
101+
[现有案例分析](https://github.com/kubernetes/website/tree/master/content/en/case-studies)
102+
的源码。
103+
104+
参考[案例分析指南](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md)
105+
根据指南中的注意事项提交你的 PR 请求。
106+
107+
## {{% heading "whatsnext" %}}
108+

‎content/zh/docs/contribute/new-content/new-features.md

Lines changed: 267 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,267 @@
1+
---
2+
title: 为发行版本撰写功能特性文档
3+
linktitle: 为发行版本撰写文档
4+
content_type: concept
5+
main_menu: true
6+
weight: 20
7+
card:
8+
name: 贡献
9+
weight: 45
10+
title: 为发行版本撰写功能特性文档
11+
---
12+
<!--
13+
title: Documenting a feature for a release
14+
linktitle: Documenting for a release
15+
content_type: concept
16+
main_menu: true
17+
weight: 20
18+
card:
19+
name: contribute
20+
weight: 45
21+
title: Documenting a feature for a release
22+
-->
23+
24+
<!-- overview -->
25+
26+
<!--
27+
Each major Kubernetes release introduces new features that require documentation.
28+
New releases also bring updates to existing features and documentation (such as upgrading a feature from alpha to beta).
29+
30+
Generally, the SIG responsible for a feature submits draft documentation of the
31+
feature as a pull request to the appropriate development branch of the
32+
`kubernetes/website` repository, and someone on the SIG Docs team provides
33+
editorial feedback or edits the draft directly. This section covers the branching
34+
conventions and process used during a release by both groups.
35+
-->
36+
Kubernetes 的每个主要版本发布都会包含一些需要文档说明的新功能。
37+
新的发行版本也会对已有功能特性和文档（例如将某功能特性从 alpha 升级为
38+
beta）进行更新。
39+
40+
通常，负责某功能特性的 SIG 要为功能特性的文档草拟文档，并针对 `kubernetes/website`
41+
仓库的合适的开发分支发起拉取请求。
42+
SIG Docs 团队会提供文字方面的反馈意见，或者直接编辑文档草稿。
43+
本节讨论两个小组在分支方面和发行期间所遵从的流程方面的约定。
44+
45+
<!-- body -->
46+
<!--
47+
## For documentation contributors
48+
49+
In general, documentation contributors don't write content from scratch for a release.
50+
Instead, they work with the SIG creating a new feature to refine the draft documentation and make it release ready.
51+
52+
After you've chosen a feature to document or assist, ask about it in the `#sig-docs`
53+
Slack channel, in a weekly SIG Docs meeting, or directly on the PR filed by the
54+
feature SIG. If you're given the go-ahead, you can edit into the PR using one of
55+
the techniques described in
56+
[Commit into another person's PR](/docs/contribute/review/for-approvers/#commit-into-another-persons-pr).
57+
-->
58+
## 对于文档贡献者
59+
60+
一般而言，文档贡献者不会为某个发行版本从头撰写文档。
61+
相反，他们会与开发该功能特性的 SIG 团队一起，对文档草稿进行润色，
62+
使之符合发布条件。
63+
64+
在你选定了某个功能特性，为其撰写文档（主笔或辅助），请在 `#sig-docs` Slack 频道、SIG Docs 的每周例会上，
65+
或者在功能特性对应的 PR 上提出咨询。
66+
如果继续工作是没有问题的，你可以使用
67+
[向他人的 PR 中提交](/zh/docs/contribute/review/for-approvers/#commit-into-another-persons-pr)
68+
中描述的技术之一，参与 PR 的编辑工作。
69+
70+
<!--
71+
### Find out about upcoming features
72+
73+
To find out about upcoming features, attend the weekly SIG Release meeting (see
74+
the [community](https://kubernetes.io/community/) page for upcoming meetings)
75+
and monitor the release-specific documentation
76+
in the [kubernetes/sig-release](https://github.com/kubernetes/sig-release/)
77+
repository. Each release has a sub-directory in the [/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases)
78+
directory. The sub-directory contains a release schedule, a draft of the release
79+
notes, and a document listing each person on the release team.
80+
-->
81+
### 了解即将发布的功能特性
82+
83+
要了解即将发布的功能特性，可以参加每周的 SIG Release 例会
84+
（参考[社区](https://kubernetes.io/community/)页面，了解即将召开的会议），
85+
监视 [kubernetes/sig-release](https://github.com/kubernetes/sig-release/)
86+
中与发行相关的文档。
87+
每个发行版本在
88+
[/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases)
89+
下都有一个对应的子目录。
90+
该子目录包含了发行版本的时间计划、发行公告的草稿以及列举发行团队名单的文档。
91+
92+
<!--
93+
The release schedule contains links to all other documents, meetings,
94+
meeting minutes, and milestones relating to the release. It also contains
95+
information about the goals and timeline of the release, and any special
96+
processes in place for this release. Near the bottom of the document, several
97+
release-related terms are defined.
98+
99+
This document also contains a link to the **Feature tracking sheet**, which is
100+
the official way to find out about all new features scheduled to go into the
101+
release.
102+
-->
103+
发行时间计划文件中包含到所有其他文档、会议、会议记录及发行相关的里程碑的链接。
104+
其中也包含关于发行版本的目标列表、时间线，以及当前发行版本中就绪的特殊流程的信息。
105+
文档末尾附近定义了若干与该发行版本有关的术语。
106+
107+
此文档也包含到 **功能特性跟踪清单** 的链接。
108+
这一清单是了解哪些功能特性计划进入某发行版本的正式途径。
109+
110+
<!--
111+
The release team document lists who is responsible for each release role. If
112+
it's not clear who to talk to about a specific feature or question you have,
113+
either attend the release meeting to ask your question, or contact the release
114+
lead so that they can redirect you.
115+
116+
The release notes draft is a good place to find out about
117+
specific features, changes, deprecations, and more about the release. The
118+
content is not finalized until late in the release cycle, so use caution.
119+
-->
120+
发行团队文档列举了哪些人扮演着各个发行版本的不同角色。
121+
如果不清楚要联系谁来讨论特定的功能特性或者回答你的问题，
122+
你可以参加发行团队的会议，提出你的问题，或者联系发行团队的牵头人，
123+
这样他们就可以帮你找到正确的联系人。
124+
125+
发行说明草稿是用来发现与特定发行版本相关的功能特性、变更、废弃以及其他信息的好来源。
126+
由于在发行周期的后段该文档的内容才会最终定稿，参考其中的信息时请谨慎。
127+
128+
<!--
129+
### Feature tracking sheet
130+
131+
The feature tracking sheet [for a given Kubernetes release](https://github.com/kubernetes/sig-release/tree/master/releases)
132+
lists each feature that is planned for a release.
133+
Each line item includes the name of the feature, a link to the feature's main
134+
GitHub issue, its stability level (Alpha, Beta, or Stable), the SIG and
135+
individual responsible for implementing it, whether it
136+
needs docs, a draft release note for the feature, and whether it has been
137+
merged. Keep the following in mind:
138+
-->
139+
### 特性跟踪清单 {#feature-tracking-sheet}
140+
141+
针对[给定 Kubernetes 发行版本](https://github.com/kubernetes/sig-release/tree/master/releases)
142+
特性跟踪清单中列举的是计划包含于该版本中的每个功能特性。
143+
每一行中都包含特性的名称、特性对应的主要 GitHub Issue，其稳定性级别（ALpha、
144+
Beta 或 Stable）、负责实现该特性的 SIG 和个人、是否该特性需要文档、该特性的
145+
发行说明草稿以及该特性是否已经被合并等等。阅读此清单时请注意：
146+
147+
<!--
148+
- Beta and Stable features are generally a higher documentation priority than
149+
Alpha features.
150+
- It's hard to test (and therefore to document) a feature that hasn't been merged,
151+
or is at least considered feature-complete in its PR.
152+
- Determining whether a feature needs documentation is a manual process and
153+
just because a feature is not marked as needing docs doesn't mean it doesn't
154+
need them.
155+
-->
156+
- Beta 和 Stable 功能特性通常比 Alpha 特性更为需要文档支持。
157+
- 如果某功能特性尚未被合并，就很难测试或者为其撰写文档。
158+
对于对应的 PR 而言，也很难讲特性是否完全实现。
159+
- 确定某个功能特性是否需要对应的文档的过程是一个手动的过程。
160+
即使某个功能特性没有标记需要文档，并不意味着该功能真的不需要任何文档。
161+
162+
<!--
163+
## For developers or other SIG members
164+
165+
This section is information for members of other Kubernetes SIGs documenting new features
166+
for a release.
167+
168+
If you are a member of a SIG developing a new feature for Kubernetes, you need
169+
to work with SIG Docs to be sure your feature is documented in time for the
170+
release. Check the
171+
[feature tracking spreadsheet](https://github.com/kubernetes/sig-release/tree/master/releases)
172+
or check in the `#sig-release` Kubernetes Slack channel to verify scheduling details and
173+
deadlines.
174+
-->
175+
## 针对开发人员或其他 SIG 成员
176+
177+
本节中的信息是针对为发行版本中新功能特性撰写文档的来自其他 Kubernetes SIGs
178+
的成员。
179+
180+
如果你是某个 SIG 的成员，负责为 Kubernetes 开发某一项新的功能特性，你需要与
181+
SIG Docs 一起工作，确保这一新功能在发行之前已经为之撰写文档。
182+
请参考[特性跟踪清单](https://github.com/kubernetes/sig-release/tree/master/releases)
183+
或者 Kubernetes Slack 上的 `#sig-release` 频道，检查时间安排的细节以及截止日期。
184+
185+
<!--
186+
### Open a placeholder PR
187+
188+
1. Open a pull request against the
189+
`dev-{{< skew nextMinorVersion >}}` branch in the `kubernetes/website` repository, with a small
190+
commit that you will amend later.
191+
2. Use the Prow command `/milestone {{< skew nextMinorVersion >}}` to
192+
assign the PR to the relevant milestone. This alerts the docs person managing
193+
this release that the feature docs are coming.
194+
-->
195+
### 提交占位 PR {#open-a-placeholder-pr}
196+
197+
1. 在 `kubernetes/website` 仓库上针对 `dev-{{< skew nextMinorVersion >}}`
198+
分支提交一个 PR，其中包含较少的、待以后慢慢补齐的提交内容。
199+
1. 使用 Prow 命令 `/milestone {{< skew nextMinorVersion >}}` 将 PR
200+
指派到对应的里程碑。这样做会提醒负责管理对应发行版本的文档团队成员，有
201+
新的功能特性要合并到将来版本。
202+
203+
<!--
204+
If your feature does not need
205+
any documentation changes, make sure the sig-release team knows this, by
206+
mentioning it in the `#sig-release` Slack channel. If the feature does need
207+
documentation but the PR is not created, the feature may be removed from the
208+
milestone.
209+
-->
210+
如果对应的功能特性不需要任何类型的文档变更，请通过在 `#sig-release` Slack
211+
频道声明这一点以确保 sig-release 团队了解。
212+
如果功能特性确实需要文档，而没有对应的 PR
213+
提交，该功能特性可能会被从里程碑中移除。
214+
215+
<!--
216+
### PR ready for review
217+
218+
When ready, populate your placeholder PR with feature documentation.
219+
220+
Do your best to describe your feature and how to use it. If you need help
221+
structuring your documentation, ask in the `#sig-docs` slack channel.
222+
223+
When you complete your content, the documentation person assigned to your
224+
feature reviews it. Use their suggestions to get the content to a release
225+
ready state.
226+
227+
If your feature needs documentation and the first draft content is not
228+
received, the feature may be removed from the milestone.
229+
-->
230+
### PR 准备好评阅
231+
232+
时机成熟时，你可以在你的占位 PR 中完成功能特性文档。
233+
234+
尽可能为功能特性提供详尽文档以及使用说明。如果你需要文档组织方面的帮助，请
235+
在 `#sig-docs` Slack 频道中提问。
236+
237+
当你已经完成内容撰写，指派给你的功能特性的文档贡献者会去评阅文档。
238+
尽量利用他们所给出的建议，改进文档内容以达到发布就绪状态。
239+
240+
如果你的功能特性需要文档，而一直没有关于该特性的文档提交评阅，
241+
该特性可能会被从里程碑中移除。
242+
243+
<!--
244+
### All PRs reviewed and ready to merge
245+
246+
If your PR has not yet been merged into the `dev-{{< skew nextMinorVersion >}}` branch by the release deadline, work with the
247+
docs person managing the release to get it in by the deadline. If your feature needs
248+
documentation and the docs are not ready, the feature may be removed from the
249+
milestone.
250+
251+
If your feature is an Alpha feature and is behind a feature gate, make sure you
252+
add it to [Alpha/Beta Feature gates](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) table
253+
as part of your pull request. If your feature is moving out of Alpha, make sure to
254+
remove it from that table.
255+
-->
256+
### 所有 PRs 均经过评审且合并就绪
257+
258+
如果你的 PR 在发行截止日期之前尚未合并到 `dev-{{< skew nextMinorVersion >}}` 分支，
259+
请与负责管理该发行版本的文档团队成员一起合作，在截止期限之前将其合并。
260+
如果功能特性需要文档，而文档并未就绪，该特性可能会被从里程碑中去除。
261+
262+
如果你的功能特性是 Alpha 阶段，并且受到某个特性门控的保护，在你的 PR 中，请确保将
263+
该特性门控添加到
264+
[Alpha/Beta 特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features)
265+
表格中。
266+
如果你的功能特性不再是 Alpha 阶段，请确保特性门控状态得到更新。
267+

0 commit comments

Comments
 (0)