Thursday, November 08, 2018
Kubernetes Docs Updates, International Edition
Author: Zach Corleissen (Linux Foundation)
As a co-chair of SIG Docs, I’m excited to share that Kubernetes docs have a fully mature workflow for localization (l10n).
Abbreviations galore
L10n is an abbreviation for localization.
I18n is an abbreviation for internationalization.
I18n is what you do to make l10n easier. L10n is a fuller, more comprehensive process than translation (t9n).
Why localization matters
The goal of SIG Docs is to make Kubernetes easier to use for as many people as possible.
One year ago, we looked at whether it was possible to host the output of a Chinese team working independently to translate the Kubernetes docs. After many conversations (including experts on OpenStack l10n), much transformation, and renewed commitment to easier localization, we realized that open source documentation is, like open source software, an ongoing exercise at the edges of what’s possible.
Consolidating workflows, language labels, and team-level ownership may seem like simple improvements, but these features make l10n scalable for increasing numbers of l10n teams. While SIG Docs continues to iterate improvements, we’ve paid off a significant amount of technical debt and streamlined l10n in a single workflow. That’s great for the future as well as the present.
Consolidated workflow
Localization is now consolidated in the kubernetes/website repository. We’ve configured the Kubernetes CI/CD system, Prow, to handle automatic language label assignment as well as team-level PR review and approval.
Language labels
Prow automatically applies language labels based on file path. Thanks to SIG Docs contributor June Yi, folks can also manually assign language labels in pull request (PR) comments. For example, when left as a comment on an issue or PR, this command assigns the label language/ko (Korean).
/language ko
These repo labels let reviewers filter for PRs and issues by language. For example, you can now filter the k/website dashboard for PRs with Chinese content.
Team review
L10n teams can now review and approve their own PRs. For example, review and approval permissions for English are assigned in an OWNERS file in the top subfolder for English content.
Adding OWNERS files to subdirectories lets localization teams review and approve changes without requiring a rubber stamp approval from reviewers who may lack fluency.
What’s next
We’re looking forward to the doc sprint in Shanghai to serve as a resource for the Chinese l10n team.
We’re excited to continue supporting the Japanese and Korean l10n teams, who are making excellent progress.
If you’re interested in localizing Kubernetes for your own language or region, check out our guide to localizing Kubernetes docs and reach out to a SIG Docs chair for support.
Get involved with SIG Docs
If you’re interested in Kubernetes documentation, come to a SIG Docs weekly meeting, or join #sig-docs in Kubernetes Slack.
2018.10.04
非代码类贡献者指南介绍
作者: Noah Abrahams (InfoSiftr)，Jonas Rosland (VMware), Ihor Dvoretskyi (CNCF)
2018 年 5 月 Kubernetes 社区在哥本哈根 KubeCon/CloudNativeCon 期间组织了贡献者峰会，并完成了首次新贡献者研讨会。 在贡献者们大力协作下，讨论的主题既包含如何签署 CLA，也包含深入的技术对话。 在大家广泛交流信息和思想的同时，也再次出现了对手头的主题的批评，其目的是确保社区尽可能具有接纳性和包容性。 在那个春天的一周时间里，被详细讨论的既有许多主题以及它们是如何呈现的，也包括人们贡献的总体特征和所涉及的技能。 基于随后的讨论和分析，大家得到的一个结论是社区并未因为有许多人想要参与并贡献而获益，相反，社区获益最多之处是另外一些人，这些人的优势并不是编写代码。
在上述诸多因素的推动下，非代码贡献指南出现了。
现在，重要的是要了解 Kubernetes 在很早就被定义为是既是一个项目也是一个社区，这在开源界即便不是独一无二的，也是不常见的。 作为一个项目，其自身聚焦于代码库；而作为一个社区，是其中的人们推动着它使它成功。 社区基于一组明确的社区价值观共同协作。 这些价值观既体现在 GitHub、Slack、演讲形式的交流上, 也体现在坐在一起喝咖啡或喝茶时，它们指导着贡献者们日常的行为。
通过建造一个以人为本的社区，并重视人群的多元化，Kubernetes 项目正在建造一个服务于需求各异的人群的产品。 不同背景的贡献者带来了解决问题的不同方法以及进行协作的多种方式，所有这些不同的视角最终共同使这个项目变得更好。
非代码贡献者指南旨在使任何人都能以合理的方式轻松地为 Kubernetes 项目作出贡献。 贡献可以有多种形式，可以是技术的也可以是非技术的，完全取决于个人对项目的了解和他们可用的时间。 大部分人都不是开发者，并且大部分的开发者都不是受雇佣的全职开源项目开发人员。 基于这种情况，我们已经有了一个不断增长的列表，列出了以非代码形式为 Kubernetes 项目做出贡献的可能途径！
参与其中
下面是一些可以参与 Kubernetes 社区贡献，而不用写任何一行代码的方法：
- 社区教育，在 Discuss，StackOverflow，和 Slack 上回答问题
- 对外的面对面社区工作，比如 主持 meetup 和各类活动
- 撰写项目文档
- 撰写操作手册，帮助用户理解如何运行 Kubernetes
- 帮助交付 Kubernetes，作为发布团队的一部分
- 项目、编码和产品管理
- 还有更多！
Kubernetes 项目贡献的起步指南在 Github 上。 由于非代码贡献指南是贡献者指南的一部分，内容同样可以在这里找到。 如前所述，该清单并非详尽无遗，它会是一项持续继续进行的工作。
迄今为止，典型的非代码贡献分为以下几类：
- 基于“软件开发人员”以外的技能组合的角色
- 主要基于代码的角色中的非代码贡献
- “代码提交”角色，它不是基于代码的，但需要知道代码库或代码库的管理
亲爱的读者，如果您对非代码方式的贡献有任何其他想法，无论它是否适合现有类别，团队将始终感谢您如果可以帮助我们扩展列表。
如果非代码性质的贡献对您有吸引力，请阅读非代码贡献文档，然后查阅贡献角色面板看看是否有任何空缺职位可以最好地利用您的专业知识！如果列表中没有与您的技能组合匹配的职位，请加入 Slack 上的 #sig-contribex 频道，我们会为您指明正确的方向。
我们希望很快能见到您对 Kubernetes 社区对贡献！