zh-trans: /docs/contribute/advanced.md (#11358)
Signed-off-by: 李元10098251 <li.yuan4@zte.com.cn> zh-trans: /docs/contribute/advanced.md; Fix some errors Signed-off-by: 李元10098251 <li.yuan4@zte.com.cn> zh-trans: /docs/contribute/advanced.md; Fix some errors 2 Signed-off-by: 李元10098251 <li.yuan4@zte.com.cn>
This commit is contained in:
Li Yuan
@@ -0,0 +1,232 @@
|
||||
<!--
|
||||
---
|
||||
title: Advanced contributing
|
||||
slug: advanced
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
-->
|
||||
|
||||
---
|
||||
title: 高级贡献
|
||||
slug: advanced
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
This page assumes that you've read and mastered the
|
||||
[Start contributing](/docs/contribute/start/) and
|
||||
[Intermediate contributing](/docs/contribute/intermediate/) topics and are ready
|
||||
to learn about more ways to contribute. You need to use the Git command line
|
||||
client and other tools for some of these tasks.
|
||||
-->
|
||||
|
||||
如果你已经阅读并掌握 [开始贡献](/docs/contribute/start/)和 [中级贡献](/docs/contribute/intermediate/)，并准备了解更多贡献的途径，请阅读此文。
|
||||
您需要使用 Git 命令行工具和其他工具做这些工作。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Be the PR Wrangler for a week
|
||||
-->
|
||||
|
||||
## 做一周的 PR 管理者
|
||||
|
||||
<!--
|
||||
SIG Docs [approvers](/docs/contribute/participating/#approvers) can be PR
|
||||
wranglers.
|
||||
-->
|
||||
|
||||
SIG Docs 的[审批者](/docs/contribute/participating/#approvers)可以成为 PR 管理者。
|
||||
|
||||
<!--
|
||||
SIG Docs approvers are added to the
|
||||
[PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers)
|
||||
for weekly rotations. The PR wrangler's duties include:
|
||||
-->
|
||||
|
||||
SIG Docs 的审批者会每周轮换地加入到 [PR 管理者轮换日程](https://github.com/kubernetes/website/wiki/PR-Wranglers)中。
|
||||
PR 管理者的工作职责包括：
|
||||
|
||||
<!--
|
||||
- Review incoming pull requests daily.
|
||||
- Help new contributors sign the CLA, and close any PR where the CLA hasn't
|
||||
been signed for two weeks. PR authors can reopen the PR after signing the
|
||||
CLA, so this is a low-risk way to make sure nothing gets merged without a
|
||||
signed CLA.
|
||||
- Provide feedback on proposed changes, including helping facilitate technical
|
||||
review from members of other SIGs.
|
||||
- Merge PRs when they are ready, or close PRs that shouldn't be accepted.
|
||||
- Triage and tag incoming issues daily. See
|
||||
[Intermediate contributing](/docs/contribute/intermediate/) for guidelines
|
||||
about how SIG Docs uses metadata.
|
||||
-->
|
||||
|
||||
- 每天评审新增的 PR
|
||||
- 指导新的贡献者签署 CLA，关闭两周都没有签署 CLA 的提交人的 PR。
|
||||
PR 提交人在签署 CLA 之后可以重启 PR，所以 PR 管理者需要保证这段时间内相关文件没有合入。
|
||||
- 对改进建议的更新提供反馈信息，包括促成其他 SIG 成员的技术性评审。
|
||||
- 合入符合要求的 PR，关闭不符合要求的 PR。
|
||||
- 每天筛选和标记新增的 issue。参见 [中级贡献](/docs/contribute/intermediate/)中有关 SIG Docs 成员使用 metadata 的指南。
|
||||
|
||||
<!--
|
||||
## Propose improvements
|
||||
-->
|
||||
|
||||
## 提出改进建议
|
||||
|
||||
<!--
|
||||
SIG Docs
|
||||
[members](/docs/contribute/participating/#members) can propose improvements.
|
||||
-->
|
||||
|
||||
SIG Docs 的[成员](/docs/contribute/participating/#members)可以提出改进建议。
|
||||
|
||||
<!--
|
||||
After you've been contributing to the Kubernetes documentation for a while, you
|
||||
may have ideas for improvement to the style guide, the toolchain used to build
|
||||
the documentation, the website style, the processes for reviewing and merging
|
||||
pull requests, or other aspects of the documentation. For maximum transparency,
|
||||
these types of proposals need to be discussed in a SIG Docs meeting or on the
|
||||
[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
|
||||
In addition, it can really help to have some context about the way things
|
||||
currently work and why past decisions have been made before proposing sweeping
|
||||
changes. The quickest way to get answers to questions about how the documentation
|
||||
currently works is to ask in the `#sig-docs` Slack channel on
|
||||
[kubernetes.slack.com](https://kubernetes.slack.com)
|
||||
-->
|
||||
|
||||
在对 Kubernetes 文档贡献了一段时间后，你可能会对样式指南、用于构建文档的工具链、网页样式、评审和合入 PR 的流程，或者文档的其他方面产生改进的想法。为了尽可能透明化，这些提议都需要在 SIG Docs 会议或 [kubernetes-sig-docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)上讨论。此外，在提出全面的改进之前，它能真正帮助我们了解有关“当前工作如何运作”和“以往的决定是为何做出”的背景。想了解文档的当前运作方式，最快的途径是咨询 [kubernetes.slack.com](https://kubernetes.slack.com) 中的 `#sig-docs` 聊天群组。
|
||||
|
||||
<!--
|
||||
After the discussion has taken place and the SIG is in agreement about the desired
|
||||
outcome, you can work on the proposed changes in the way that is the most
|
||||
appropriate. For instance, an update to the style guide or the website's
|
||||
functionality might involve opening a pull request, while a change related to
|
||||
documentation testing might involve working with sig-testing.
|
||||
-->
|
||||
|
||||
在进行了讨论并且 SIG 就期望的结果达成一致之后，你就能以最合理的方式处理改进建议了。例如，样式指南或网站功能的更新可能涉及 PR 的新增，而与文档测试相关的更改可能涉及 sig-testing。
|
||||
|
||||
<!--
|
||||
## Coordinate docs for a Kubernetes release
|
||||
-->
|
||||
|
||||
## 为 Kubernetes 版本发布协调文档
|
||||
|
||||
<!--
|
||||
SIG Docs [approvers](/docs/contribute/participating/#approvers) can coordinate
|
||||
docs for a Kubernetes release.
|
||||
-->
|
||||
|
||||
SIG Docs 的[审批者](/docs/contribute/participating/#approvers)可以为 Kubernetes 版本发布协调文档。
|
||||
|
||||
<!--
|
||||
Each Kubernetes release is coordinated by a team of people participating in the
|
||||
sig-release Special Interest Group (SIG). Others on the release team for a given
|
||||
release include an overall release lead, as well as representatives from sig-pm,
|
||||
sig-testing, and others. To find out more about Kubernetes release processes,
|
||||
refer to
|
||||
[https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release).
|
||||
-->
|
||||
|
||||
每一个 Kubernetes 版本都是由参与 sig-release 的 SIG（特别兴趣小组）的一个团队协调的。指定版本的发布团队中还包括总体发布牵头人，以及来自 sig-pm、sig-testing 的代表等。了解更多关于 Kubernetes 版本发布的流程，请参考 [https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release)。
|
||||
|
||||
<!--
|
||||
The SIG Docs representative for a given release coordinates the following tasks:
|
||||
-->
|
||||
|
||||
SIG Docs 团队的代表需要为一个指定的版本协调以下工作：
|
||||
|
||||
<!--
|
||||
- Monitor the feature-tracking spreadsheet for new or changed features with an
|
||||
impact on documentation. If documentation for a given feature won't be ready
|
||||
for the release, the feature may not be allowed to go into the release.
|
||||
-->
|
||||
|
||||
- 通过特性跟踪表来监视新功能特性或现有功能特性的修改。如果版本的某个功能特性的文档没有为发布做好准备，那么该功能特性不允许进入发布版本。
|
||||
|
||||
<!--
|
||||
- Attend sig-release meetings regularly and give updates on the status of the
|
||||
docs for the release.
|
||||
-->
|
||||
|
||||
- 定期参加 sig-release 会议并对文档状态进行更新。
|
||||
|
||||
<!--
|
||||
- Review and copyedit feature documentation drafted by the SIG responsible for
|
||||
implementing the feature.
|
||||
-->
|
||||
|
||||
- 评审和修改由负责实现某功能特性的 SIG 起草的功能特性文档。
|
||||
|
||||
<!--
|
||||
- Merge release-related pull requests and maintain the Git feature branch for
|
||||
the release.
|
||||
-->
|
||||
|
||||
- 合入版本发布相关的 PR，并为对应发布版本维护 Git 特性分支。
|
||||
|
||||
<!--
|
||||
- Mentor other SIG Docs contributors who want to learn how to do this role in
|
||||
the future. This is known as "shadowing".
|
||||
-->
|
||||
|
||||
- 指导那些想学习并有意愿担当该角色的 SIG Docs 贡献者。这就是我们常说的“实习”。
|
||||
|
||||
<!--
|
||||
- Publish the documentation changes related to the release when the release
|
||||
artifacts are published.
|
||||
-->
|
||||
|
||||
- 发布版本的制品发布时，相关的文档更新也需要发布。
|
||||
|
||||
<!--
|
||||
Coordinating a release is typically a 3-4 month commitment, and the duty is
|
||||
rotated among SIG Docs approvers.
|
||||
-->
|
||||
|
||||
协调一个版本发布通常需要 3-4 个月的时间投入，该任务由 SIG Docs 审批者轮流承担。
|
||||
|
||||
<!--
|
||||
## Sponsor a new contributor
|
||||
-->
|
||||
|
||||
## 保荐新的贡献者
|
||||
|
||||
<!--
|
||||
SIG Docs [reviewers](/docs/contribute/participating/#reviewers) can sponsor
|
||||
new contributors.
|
||||
-->
|
||||
|
||||
SIG Docs 的[评审者](/docs/contribute/participating/#reviewers)可以保荐新的贡献者。
|
||||
|
||||
<!--
|
||||
After a new contributor has successfully submitted 5 substantive pull requests
|
||||
to one or more Kubernetes repositiries, they are eligible to apply for
|
||||
[membership](/docs/contribute/participating#members) in the Kubernetes
|
||||
organization. The contributor's membership needs to be backed by two sponsors
|
||||
who are already reviewers.
|
||||
-->
|
||||
|
||||
新的贡献者针对一个或多个 Kubernetes 项目仓库成功提交了 5 个实质性 PR 之后，就有资格申请 Kubernetes 组织[成员](/docs/contribute/participating#members)。贡献者的成员资格需要同时得到两位评审者的保荐。
|
||||
|
||||
<!--
|
||||
New docs contributors can request sponsors by asking in the #sig-docs channel
|
||||
on the [Kubernetes Slack instance](https://kubernetes.slack.com) or on the
|
||||
[SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
|
||||
If you feel confident about the applicant's work, you volunteer to sponsor them.
|
||||
When they submit their membership application, reply to the application with a
|
||||
"+1" and include details about why you think the applicant is a good fit for
|
||||
membership in the Kubernetes organization.
|
||||
-->
|
||||
|
||||
新的文档贡献者可以通过咨询 [Kubernetes Slack instance](https://kubernetes.slack.com) 上的 #sig-docs 或 [SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 来请求评审者保荐。如果你对申请人的工作充满信心，你自愿保荐他们。当他们提交成员资格申请时，回复“+1”并详细说明为什么你认为申请人适合加入 Kubernetes 组织。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
Reference in New Issue
Block a user