本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
为开发指南做贡献
当大多数人想到为开源项目做贡献时，我猜他们可能会想到贡献代码更改、新功能和错误修复。作为一名软件工程师和资深的开源用户和贡献者，这确实是我的想法。尽管我在不同的工作流程中编写了大量的文档，但Kubernetes社区的庞大规模是一种全新的“客户”。当Google要求我和我的同事在Lion's Way对Kubernetes开发指南进行急需的更新时，我不知道会发生什么。
本文最初发表于Kubernetes贡献者社区博客。
与社区合作的乐趣
作为专业作家，我们习惯于受雇撰写非常具体的作品。我们专注于技术服务和产品的营销、培训和文档，这可以涵盖从相对轻松的营销电子邮件到面向IT和开发人员的深度技术白皮书。对于这种专业的服务，每个可交付成果都倾向于有可衡量的投资回报。我知道在处理开源文档时不会出现这个指标，但我无法预测它会如何改变我与项目的关系。
我们写作与传统客户关系的主要特点之一是，我们公司内部始终有一到两个主要联系人。这些联系人负责审查我们的作品，并确保它符合公司的口吻，并针对他们所寻找的受众。这可能会很有压力——这就是为什么我很高兴我的写作伙伴、眼光敏锐的审阅者和铁腕编辑Joel处理了大部分客户联系。
与Kubernetes社区合作时，所有客户联系的压力都烟消云散了，这让我感到惊讶和高兴。
“我必须多么小心？如果我搞砸了怎么办？如果我惹恼了开发者怎么办？如果我树敌了怎么办？”当我第一次加入Kubernetes Slack上的#sig-contribex频道并宣布我将致力于开发指南时，这些问题都在我脑海中飞快闪过，让我感觉像是在走钢丝。
“Kubernetes行为准则生效中，请大家互相尊重。”——Jorge Castro，SIG ContribEx 联席主席
我的担心是没有根据的。我立刻感受到了欢迎。我想这不仅仅是因为我正在做一项急需的任务，更是因为Kubernetes社区充满了友好、热情的人。在每周的SIG ContribEx会议上，我们关于开发指南进展的报告立即被纳入。此外，会议主席总是强调Kubernetes行为准则是有效的，我们应该像比尔和特德一样，互相尊重。
这并不意味着一切都很容易
《开发指南》需要进行一次相当彻底的修订。当我们拿到它时，它已经包含了大量信息和新开发者需要经历的许多步骤，但它已经因年久失修而积满了灰尘。文档真的需要全局性的审视，而不仅仅是零星的修复。结果，我最终向社区仓库提交了一个庞大的拉取请求：增加了267行，删除了88行。
拉取请求的生命周期要求一定数量的Kubernetes组织成员在合并更改之前对其进行审查和批准。这是一个很好的做法，因为它使文档和代码都保持良好状态，但说服合适的人花时间进行如此重要的审查可能会很困难。结果，那个庞大的PR从我第一次提交到最终合并花了26天。但最终，它成功了。
由于 Kubernetes 是一个快速发展的项目，并且开发人员通常对编写文档不那么热衷，我还遇到了一个问题：有时，描述 Kubernetes 子系统工作原理的秘密宝藏深埋在一位杰出工程师迷宫般的思维中，而不是以通俗易懂的英语写在 Markdown 文件里。当需要更新端到端 (e2e) 测试的入门文档时，我直接遇到了这个问题。
我旅程的这一部分将我带出了文档编写领域，进入了全新用户使用未完成软件的角色。我最终与新的kubetest2 框架的开发人员之一合作，记录了 e2e 测试的最新启动和运行过程，但这需要我挠头苦思。您可以查看我已完成的拉取请求，自行判断结果。
没有人是老板，每个人都提供反馈
尽管我暗地里预料到会一片混乱，但为Kubernetes开发指南做贡献以及与令人惊叹的Kubernetes社区互动过程却异常顺利。没有争议。我没有树敌。每个人都非常友好和热情。这非常愉快。
在一个开源项目中，没有一个老板。庞大的Kubernetes项目被分为许多不同的特别兴趣小组（SIGs）、工作组和社区。每个都有自己定期安排的会议、分配的职责和选举出的主席。我的工作与SIG ContribEx（负责监督和改善贡献者体验）和SIG Testing（负责测试）的努力相交叉。这两个SIG都证明了易于合作，渴望贡献，并且充满了非常友好和热情的人。
在一个像Kubernetes这样活跃的、有生命力的项目中，文档与代码库一样，持续需要维护、修订和测试。《开发指南》将继续对新贡献者加入Kubernetes代码库至关重要，正如我们的努力所表明的那样，这份指南与Kubernetes项目的发展保持同步非常重要。
乔尔和我非常喜欢与Kubernetes社区互动，并为《开发指南》做出贡献。我真的很期待继续贡献更多，并继续在这庞大的开源社区中，与我在过去几个月里结识的新朋友们建立友谊。