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

[zh] Sync contribution changes (1)

Browse Source 
There have been some significant changes to the contribution guide.
This PR is one of the series that sync the changes to Chinese
localization.
This commit is contained in:
Qiming Teng
2020-06-23 10:44:07 +08:00
parent 33f6fd9aa4
commit 7fd6907362
9 changed files with 992 additions and 2996 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/contribute/advanced.md
+86 -58
View File
@@ -2,29 +2,28 @@
title: 高级贡献
slug: advanced
content_type: concept
weight: 30
weight: 98
---
<!--
---
title: Advanced contributing
slug: advanced
content_type: concept
weight: 30
---
weight: 98
-->
<!-- 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
This page assumes that you understand how to
[contribute to new content](/docs/contribute/new-content/overview) and
[review others' work](/docs/contribute/review/reviewing-prs/), 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 命令行工具和其他工具做这些工作。
如果你已经了解如何[贡献新内容](/zh/docs/contribute/new-content/overview/)和
[评阅他人工作](/zh/docs/contribute/review/reviewing-prs/)，并准备了解更多贡献的途径，
请阅读此文。您需要使用 Git 命令行工具和其他工具做这些工作。
<!-- body -->
@@ -34,13 +33,13 @@ client and other tools for some of these tasks.
## 做一周的 PR 管理者
<!--
SIG Docs [approvers](/docs/contribute/participating/#approvers) take regular turns as the PR wrangler for the repository and are added to the [PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers#2019-schedule-q1q2) for weekly rotations.
-->
SIG Docs 的 [approvers](/docs/contribute/participating/#approvers) 可以成为 PR 管理者。SIG Docs approvers 会每周轮换地加入到 [PR 管理者轮换日程](https://github.com/kubernetes/website/wiki/PR-Wranglers#2019-schedule-q1q2)中。
SIG Docs [approvers](/docs/contribute/participating/#approvers) take week-long turns [wrangling PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository.
<!--
The PR wrangler’s duties include:
-->
SIG Docs 的[批准人（Approvers）](/zh/docs/contribute/participating/#approvers)们每周轮流负责
[管理仓库的 PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers)。
PR 管理者的工作职责包括：
<!--
@@ -62,7 +61,7 @@ PR 管理者的工作职责包括：
- 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 on how SIG Docs uses metadata.
-->
- 每天检查[悬决的 PR](https://github.com/kubernetes/website/pulls) 的质量并确保它们遵守[风格指南]](/docs/contribute/style/style-guide/)。
- 每天检查[悬决的 PR](https://github.com/kubernetes/website/pulls) 的质量并确保它们遵守[样式指南](/zh/docs/contribute/style/style-guide/)和[内容指南](/zh/docs/contribute/style/content-guide/)。
- 首先查看最小的 PR（`size/XS`），然后逐渐扩展到最大的 PR（`size/XXL`）。
- 尽可能多地审阅 PR。
- 确保每个贡献者完成 CLA 签署。
@@ -78,7 +77,8 @@ PR 管理者的工作职责包括：
- 为已审阅的但在合并前需要更多信息的或采取措施的 PR 设置 `Doc Review: Open Issues` 或者 `Tech Review: Open Issues` 标签。
- 为可以合并的 PR 添加 `/lgtm` 和 `/approve` 标签。
- 合并已经就绪的，或关闭不应该接受的 PR。
- 每天对新增的 issues 进行分类和标记。有关 SIG 文档如何使用 metadata 的准则，请参见[中级贡献](/docs/contribute/intermediate/)。
- 每天对新增的 Issue 报告进行分类和判别。有关 SIG 文档如何使用 metadata 的准则，请参见
[对 Issue 进行分类](/zh/docs/contribute/review/for-approvers/#triage-and-categorize-issues)。
<!--
### Helpful GitHub queries for wranglers
@@ -86,9 +86,10 @@ PR 管理者的工作职责包括：
The following queries are helpful when wrangling. After working through these three queries, the remaining list of PRs to be
reviewed is usually small. These queries specifically exclude localization PRs, and only include the `master` branch (except for the last one).
-->
### 对于负责人有用的 GitHub 查询
### 对于管理人有用的 GitHub 查询
执行管理操作时，以下查询很有用。完成以下三个查询后，剩余的要审阅的 PR 列表通常很小。
这些查询都排除了本地化的 PR，并仅包含 `master` 分支上的 PR（除了最后一个查询）。
<!--
- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
@@ -102,13 +103,15 @@ reviewed is usually small. These queries specifically exclude localization PRs,
Determine whether any additional changes or updates need to be made for the PR to be merged. If you think the PR is ready to be merged, comment `/approve`.
- [Not against master](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If it's against a `dev-` branch, it's for an upcoming release. Make sure the [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) knows about it by adding a comment with `/assign @<meister's_github-username>`. If it's against an old branch, help the PR author figure out whether it's targeted against the best branch.
-->
- [没有签署 CLA, 不能 merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
- [没有签署 CLA, 不能合并](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
提醒贡献者签署 CLA。如果机器人和审阅者都已经提醒他们，请关闭 PR，并提醒他们在签署 CLA 后可以重新提交。
**在作者没有签署 CLA 之前，不要审阅他们的 PR！**
- [需要 LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
如果需要技术审查，请告知机器人所建议的审阅者。如果 PR 需要文档审查或复制编辑，提交更改建议或向 PR 提交一个 copyedit 以使之进入下一步。
- [有 LGTM ，需要批准](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
确定 PR 是否需要进行其他更改或更新才能合并。如果您认为 PR 已准备好合并，请输入 `/approve`。
- [快速批阅](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+)：对于针对 master 分支的小规模 PR，可以快速审阅。
在浏览 PR 时，可以注意到 size 标签为 "XS" 的 PRs。
- [非 master 分支的 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster)：
如果 PR 针对 `dev-` 分支，则表示它适用于即将发布的版本。请添加带有 `/assign @<负责人的 github 账号>` 的注释，确保[发行版本负责人](https://github.com/kubernetes/sig-release/tree/master/release-team)注意到该 PR。如果 PR 是针对旧分支，请帮助 PR 作者确定是否所针对的是最合适的分支。
@@ -132,7 +135,7 @@ Don't be afraid to close pull requests. Contributors can easily reopen and resum
To close a pull request, leave a `/close` comment on the PR.
-->
- 关闭两个星期未签署 CLA 的 PR。
PR 作者可以在签署 CLA 后重新打开 PR，因此这是确保未签署 CLA 的 PR 不会被合并的一种风险较低的方法。
PR 作者可以在签署 CLA 后重新打开 PR，因此这是确保未签署 CLA 的 PR 不会被合并的一种风险较低的方法。
- 如果作者在两周或更长时间内未回复评论或反馈，请关闭 PR。
@@ -140,28 +143,29 @@ PR 作者可以在签署 CLA 后重新打开 PR，因此这是确保未签署 CL
要关闭 PR，请在 PR 上输入 `/close`。
{{< note >}}
<!--
An automated service, [`fejta-bot`](https://github.com/fejta-bot) automatically marks issues as stale after 90 days of inactivity, then closes them after an additional 30 days of inactivity when they become rotten. PR wranglers should close issues after 14-30 days of inactivity.
-->
一项名为 [`fejta-bot`](https://github.com/fejta-bot) 的自动服务会在 issues 停滞 90 天后会自动将其标记为过期；然后再等 30 天，如果仍然无人过问，则将其关闭。PR 管理者应该在 issues 处于无人过问状态 14-30 天后关闭它们。
{{< note >}}
一项名为 [`fejta-bot`](https://github.com/fejta-bot) 的自动服务会在 Issue 停滞 90
天后自动将其标记为过期；然后再等 30 天，如果仍然无人过问，则将其关闭。
PR 管理者应该在 issues 处于无人过问状态 14-30 天后关闭它们。
{{< /note >}}
<!--
## Propose improvements
SIG Docs
[members](/docs/contribute/participating/#members) can propose improvements.
SIG Docs [members](/docs/contribute/participating/#members) can propose improvements.
-->
## 提出改进建议
SIG Docs 的 [成员](/docs/contribute/participating/#members) 可以提出改进建议。
SIG Docs 的 [成员](/zh/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
may have ideas for improving the [Style Guide](/docs/contribute/style/style-guide/)
, the [Content Guide](/docs/contribute/style/content-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
@@ -172,7 +176,14 @@ changes. The quickest way to get answers to questions about how the documentatio
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` 聊天群组。
在对 Kubernetes 文档贡献了一段时间后，你可能会对[样式指南](/zh/docs/contribute/style/style-guide/)、
[内容指南](/zh/docs/contribute/style/content-guide/)、用于构建文档的工具链、网站样式、
评审和合并 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
@@ -185,14 +196,14 @@ documentation testing might involve working with 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 的[批准者（approvers）](/docs/contribute/participating/#approvers) 可以为 Kubernetes 版本发布协调文档。
## 为 Kubernetes 版本发布协调文档工作
SIG Docs 的[批准者（approvers）](/zh/docs/contribute/participating/#approvers) 可以为
Kubernetes 版本发布协调文档工作。
<!--
Each Kubernetes release is coordinated by a team of people participating in the
@@ -202,14 +213,14 @@ 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)。
每一个 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.
@@ -224,7 +235,11 @@ SIG Docs 团队的代表需要为一个指定的版本协调以下工作：
- Publish the documentation changes related to the release when the release
artifacts are published.
-->
- 通过特性跟踪表来监视新功能特性或现有功能特性的修改。如果版本的某个功能特性的文档没有为发布做好准备，那么该功能特性不允许进入发布版本。
SIG Docs 团队的代表需要为一个指定的版本协调以下工作：
- 通过特性跟踪表来监视新功能特性或现有功能特性的修改。
如果版本的某个功能特性的文档没有为发布做好准备，那么该功能特性不允许进入发布版本。
- 定期参加 sig-release 会议并汇报文档的发布状态。
- 评审和修改由负责实现某功能特性的 SIG 起草的功能特性文档。
- 合入版本发布相关的 PR，并为对应发布版本维护 Git 特性分支。
@@ -235,14 +250,11 @@ SIG Docs 团队的代表需要为一个指定的版本协调以下工作：
Coordinating a release is typically a 3-4 month commitment, and the duty is
rotated among SIG Docs approvers.
-->
协调一个版本发布通常需要 3-4 个月的时间投入，该任务由 SIG Docs approvers 轮流承担。
协调一个版本发布通常需要 3-4 个月的时间投入，该任务由 SIG Docs 批准人轮流承担。
<!--
## Serve as a New Contributor Ambassador
-->
## 担任新的贡献者大使
<!--
SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve as
New Contributor Ambassadors.
@@ -252,9 +264,14 @@ few PR submissions.
Responsibilities for New Contributor Ambassadors include:
-->
SIG Docs [approvers](/docs/contribute/participating/#approvers) 可以担任新的贡献者大使。
新的贡献者大使共同努力欢迎 SIG-Docs 的新贡献者，对新贡献者的 PR 提出建议，以及在前几份 PR 提交中指导新贡献者。
## 担任新的贡献者大使
SIG Docs [批准人（Approvers）](/zh/docs/contribute/participating/#approvers)
可以担任新的贡献者大使。
新的贡献者大使共同努力欢迎 SIG-Docs 的新贡献者，对新贡献者的 PR 提出建议，
以及在前几份 PR 提交中指导新贡献者。
新的贡献者大使的职责包括：
@@ -265,11 +282,11 @@ SIG Docs [approvers](/docs/contribute/participating/#approvers) 可以担任新
- Helping new contributors create the more complex PRs they need to become Kubernetes members.
- [Sponsoring contributors](/docs/contribute/advanced/#sponsor-a-new-contributor) on their path to becoming Kubernetes members.
-->
- 可在 [Kubernetes #sig-docs 频道](https://kubernetes.slack.com) 上回答新贡献者的问题。
- 监听 [Kubernetes #sig-docs 频道](https://kubernetes.slack.com) 上新贡献者的 Issue。
- 与 PR 管理者合作为新参与者寻找合适的第一个 issues。
- 通过前几个 PR 指导新贡献者到文档存储库。
- 通过前几个 PR 指导新贡献者为文档存储库作贡献。
- 帮助新的贡献者创建成为 Kubernetes 成员所需的更复杂的 PR。
- [为贡献者提供担保](/docs/contribute/advanced/#sponsor-a-new-contributor)，使其成为 Kubernetes 成员。
- [为贡献者提供保荐](#sponsor-a-new-contributor)，使其成为 Kubernetes 成员。
<!--
Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and in the [Kubernetes #sig-docs channel](https://kubernetes.slack.com).
@@ -278,14 +295,13 @@ Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and
<!--
## Sponsor a new contributor
-->
## 为新的贡献者提供担保
<!--
SIG Docs [reviewers](/docs/contribute/participating/#reviewers) can sponsor
new contributors.
-->
SIG Docs 的 [reviewers](/docs/contribute/participating/#reviewers) 可以为新的贡献者提供担保。
## 为新的贡献者提供保荐 {#sponsor-a-new-contributor}
SIG Docs 的[评审人（Reviewers）](/zh/docs/contribute/participating/#reviewers) 可以为新的贡献者提供保荐。
<!--
After a new contributor has successfully submitted 5 substantive pull requests
@@ -294,7 +310,9 @@ to one or more Kubernetes repositories, they are eligible to apply for
organization. The contributor's membership needs to be backed by two sponsors
who are already reviewers.
-->
新的贡献者针对一个或多个 Kubernetes 项目仓库成功提交了 5 个实质性 PR 之后，就有资格申请 Kubernetes 组织 [成员身份](/docs/contribute/participating#members)。贡献者的成员资格需要同时得到两位 reviewers 的保荐。
新的贡献者针对一个或多个 Kubernetes 项目仓库成功提交了 5 个实质性 PR 之后，
就有资格申请 Kubernetes 组织的[成员身份](/zh/docs/contribute/participating#members)。
贡献者的成员资格需要同时得到两位评审人的保荐。
<!--
New docs contributors can request sponsors by asking in the #sig-docs channel
@@ -305,7 +323,10 @@ 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 实例](https://kubernetes.slack.com) 上的 #sig-docs 频道或者 [SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)来请求评审者保荐。如果你对申请人的工作充满信心，你自愿保荐他们。当他们提交成员资格申请时，回复 “+1” 并详细说明为什么你认为申请人适合加入 Kubernetes 组织。
新的文档贡献者可以通过咨询 [Kubernetes Slack 实例](https://kubernetes.slack.com)
上的 #sig-docs 频道或者 [SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
来请求评审者保荐。如果你对申请人的工作充满信心，你自愿保荐他们。
当他们提交成员资格申请时，回复 “+1” 并详细说明为什么你认为申请人适合加入 Kubernetes 组织。
<!--
## Serve as a SIG Co-chair
@@ -316,7 +337,8 @@ SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve a term
-->
## 担任 SIG 联合主席
SIG Docs [approvers](/docs/contribute/participating/#approvers) 可以担任 SIG Docs 的联合主席。
SIG Docs [批准人（Approvers）](/zh/docs/contribute/participating/#approvers)
可以担任 SIG Docs 的联合主席。
### 前提条件
@@ -332,9 +354,14 @@ Approvers must meet the following requirements to be a co-chair:
Approvers 必须满足以下要求才能成为联合主席：
- 已维持 SIG Docs approver 身份至少 6 个月
- [曾领导 Kubernetes 文档发布](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) 或者在两个版本发布中有实习经历
- [曾领导 Kubernetes 文档发布](/zh/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release)
或者在两个版本发布中有实习经历
- 理解 SIG Docs 工作流程和工具：git、Hugo、本地化、博客子项目
- 理解其他 Kubernetes SIG 和仓库会如何影响 SIG Docs 工作流程，包括：[k/org 中的团队](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml)、[k/community 中的流程](https://github.com/kubernetes/community/tree/master/sig-docs)、[k/test-infra](https://github.com/kubernetes/test-infra/) 中的插件、[SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture) 中的角色。
- 理解其他 Kubernetes SIG 和仓库会如何影响 SIG Docs 工作流程，包括：
[k/org 中的团队](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml)、
[k/community 中的流程](https://github.com/kubernetes/community/tree/master/sig-docs)、
[k/test-infra](https://github.com/kubernetes/test-infra/) 中的插件、
[SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture) 中的角色。
- 在至少 6 个月的时段内，确保每周至少投入 5 个小时（通常更多）
<!--
@@ -361,11 +388,13 @@ Responsibilities include:
- Keep the SIG running smoothly
-->
- 保持 SIG Docs 专注于通过出色的文档最大限度地提高开发人员的满意度
- 以身作则，践行[社区行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) 并要求 SIG 成员对自身行为负责
- 通过更新贡献准则，为 SIG 学习并设置最佳实践
- 以身作则，践行[社区行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)，
并要求 SIG 成员对自身行为负责
- 通过更新贡献指南，为 SIG 学习并设置最佳实践
- 安排和举行 SIG 会议：每周状态更新，每季度回顾/计划会议以及其他需要的会议
- 在 KubeCon 活动和其他会议上安排和负责文档工作
- 与 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 及其尊贵合作伙伴（包括 Google、Oracle、Azure、IBM 和华为）一起以 SIG Docs 的身份招募和宣传
- 与 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 及其尊贵合作伙伴
（包括 Google、Oracle、Azure、IBM 和华为）一起以 SIG Docs 的身份招募和宣传
- 负责 SIG 正常运行
<!--
@@ -379,7 +408,7 @@ To schedule and run effective meetings, these guidelines show what to do, how to
-->
### 召开高效的会议
为了安排和召开高效的会议，这些准则说明了如何做、怎样做以及原因。
为了安排和召开高效的会议，这些指南说明了如何做、怎样做以及原因。
**坚持[社区行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)**：
@@ -470,4 +499,3 @@ The video uploads automatically to YouTube.
视频会自动上传到 YouTube。