记一次10人跨组织、跨地域的开源协作经历

本文为腾讯作者投稿。创作人：陈伟嘉，腾讯云IDaaS技术专家。

PART ONE

前 言

近期，我在CNCF的官方开源项目中（https://github.com/cncf/tag-security）发起了一项“云原生安全白皮书”协同翻译的工作——通过开源项目协同的方式，征集了来自不同地域、不同企业的译者10人，组成了一支项目小组，并合作完成了PR被合并。

这次新鲜的开源协作经历不同于之前个人提代码PR的方式，作为组织者（小组leader），我需要考虑大量和中立、跨组织协作相关的问题。因此，这次完整的经历，让我对开源精神的内核有了更清晰认识，也让我深刻感悟到开源的精神——“开源即中立，开源即民主，开源即自由”。

今天，我也将这次经历做一个简单的回忆和总结，以和“腾源会”的读者朋友们共享与交流：）

PART TWO

发起起源与Team up

“云原生安全”是最近几年云原生落地过程中的热门话题之一。在当前分布式云原生架构越来越流行的背景下，云原生安全态势愈发凸显和严峻。

基于对全球云原生安全发展趋势和概况的梳理、总结，云原生计算基金会（CNCF）“安全兴趣小组”（Security Special Interest Group (SIG)）在2020年11月对外发布了《云原生安全白皮书》（“Cloud Native Security White Paper”），该白皮书介绍了针对云原生架构的安全指南和新的控制方式。

基于自身对该领域的兴趣，腾讯云在云原生安全领域的持续关注与投入，以及云原生安全问题需要在国内得到更多的正视，因此，我于今年年初在CNCF官方国区大使协助下，在官方项目中发起了issue，召集组织该白皮书的中文翻译小组。

报名过程异常火爆，最终我们从来自国内各个厂商（包括很多友商）的30多个报名的小伙伴中，选出了10位组成了一个跨组织队伍。

挑选原则是中立与开放多样，覆盖更多的公司与行业，所以在报名的友商都至少有一位入选。

PART THREE

分工与协作

在跨组织队伍真正开始协作之前，需要对分工、模式、流程等建议一套共识。

因此，我们建立了沟通群，并将第一次动员组织会议放在了元旦假期的一个晚上。

在动员会上，为破除大家的不信任感和让大家认知到该小组的“中立”属性，我先和大家同步了小组的定位：虽然成员们来自不同企业或组织，但是在非工作组中，需要大家卸下各种组织角色，以开放、中立的心态参与其中。

有了明确的定位之后，第二步则是分工协作方式的确立。为了继续保证中立性，我们做了一些跟日常工作不同的分工设计：

• 每2个人随机分组，工作量均分为5份（提前做预估）；
• 组内工作内容输出前互相批改，初步确保正确与中立性；
• 各组完成工作后，会再随机互相批改一次，再次确保正确与中立性；
• 任何批改意见争议，在我们沟通群讨论并表决（组织者输出共识）。

这些分工方式本身并没有其他项目/社区的经验可借鉴，大多都是动员会期间小组成员讨论共创出来的。在这个过程中，随着我们共创出更多的可执行的流程和规则，我也逐步打消了之前的担忧点——友商是否会有偏见？配合度是不是会较低？事实是，我感受到了来自友商小伙伴的热情与善意，想必除了开源的协作，我们很少能被这种浓厚的开放和中立氛围感染了。

而整个白皮书翻译PR被合并的产出流程，我们也最终达成一致意见——使用多人在线文辑和表格作为在线协作工具，并规范其使用。我们用在线文档记录大家的翻译原稿和所有的批改意见，也会做开会记录，同时使用在线表格做流程追踪管理，实时更新进度和补充TODO项。

PART FOUR

出现的问题与对应解决方案

然而，在协作启动之初，我们就遇到了第一个难题——首先是在翻译专有名词上，我们就出现了不同领域专有名词翻译各异的问题。

小组的每一个人来自不同的行业或公司，对于专有名词的称谓、定义均会有所不同。虽然译者小队只有10人，且来自不同的组织和背景，但我们不希望官方白皮书因为文字风格各异、语言习惯不同、翻译水平参差不齐等问题，而变得非常难以阅读或者产生歧义。

对此，我们采取的解决方案便是用在线表格将专有名词做了映射，大家会先在表格中填写翻译名称，如果有多种意见的话就会发起民主投票。实践过程中大家都非常认可这种方式，并能尊重投票结果。

在后期交叉评审阶段，另一个新的问题又出现了——由于大家语言习惯不同，导致白皮书的整体翻译风格仍然非常零散割裂。

当然，为了确保内容的统一性、准确性，我们在校对修改过程中使用了二次交叉评审的方式。但即使这项工作万无一失，但仍在阅读上存有比较明显的突兀感。

于是，我组织了一个小短会邀请大家商讨解决方案。通过群策群力，小组成员最后商讨并决定遴选出之前翻译效果较好的同学执行、把关风格终审和批改，并提交首次PR，收集社区反馈。

在进行了多轮交叉审批后，我们输出了第一个PR到项目，在PR Review过程中，我们也获得了很多修改建议和补充，例如一些笔误、更好的中英文混合排版，针对这些社区建议我们也对内容进行了后续的进一步完善并完成最终修改。最后，翻译版的《云原生安全白皮书》得到了官方author的审批通过Approved。

（点击「阅读原文」进入GitHub PR链接，或复制https://github.com/cncf/tag-security/pull/471 打开）

PART FIVE

开源即中立，开源即民主，开源即自由

互联网发展至今已经让信息越来越民主化、让每个人触手可及，同时让开源项目的门槛在快速降低，很多从未贡献过中立项目的开发者也能轻松参与到云原生计算基金会的官方项目中，得益于越来越多的远程协作工具、互联网公共服务。

我相信开源协作这种神奇的、新的社会生产方式一定会成为新的主流，允许来自世界各地、完全不相识的开发者，在无组织结构的前提下完成高效协作。

通过这次开源协作经历，我也感受到开源的强大、来自群众的巨大力量——整个过程就像一场大型的民主众筹，自下而上地推动某一个产物的诞生。相信这种开源力量在未来可以真正推动更多技术、生产方式的变革。

作为组织者，我在这个过程中与大家一起共同投票与决策，感受到每个人之间的公平对待与尊重。

这种开源文化背后的“公平”很可贵。因为“公平”则意味着开源贡献应是开放的、平等的，没有任何等级和所谓权威的。这样的协作方式也受到大家的欢迎，可以看到了一种新的趋势：工程师开源文化正向主流文化进行延伸。

最后，远程协作是自由的。

每个人都可以选择任意地点和时间进行。大家所有人都是利用个人的自由业余时间在完成生产贡献，大部分产出发生在春节假期，有的人甚至在沙滩边、古城脚进行着他的贡献。这样的自由，让人跳出日常的工作状态，更多激发创造力与想象力。不难理解，近年来，很多绝佳的想法和创新都来自这样的团队。

PART SIX

给开源新手的建议

虽然同是开源新手，但基于这次的经历，我也想给其他希望参与开源的新人几点简单的建议：

1. Pick interesting ones: 挑选感兴趣的项目。不管你是否擅长这方面的编程，只要有兴趣就有可能贡献，就是合适自己的项目。
2. Find your edge: 找一个切入点先参与，根据自己的优势（例如我自认英语读写还行），从浅到深参与到项目贡献。
3. Keep an open mind: 保持开放、中立的心态。

我的下一步计划是能够继续在国内外社区参与到云原生，尤其是云原生安全相关的布道和推广中。同时我也会继续推进云原生安全白皮书国内的改进和落地，争取成为企业采纳云原生方案过程的最佳实践，并参与到更多云原生项目中，体验到开源另一个核心文化“Code is the law”。

参考资料：

1. CNCF发布云原生安全白皮书的官方通知：https://www.cncf.io/blog/2020/11/18/announcing-the-cloud-native-security-white-paper/
2. 云原生安全白皮书英文原版GitHub链接： https://github.com/cncf/tag-security/blob/main/security-whitepaper/CNCF_cloud-native-security-whitepaper-Nov2020.pdf

关于作者

陈伟嘉，腾讯云IDaaS技术专家，腾讯云TVP，负责腾讯云IDaaS架构设计和安全落地。此前参与过React等开源项目贡献，并作为官方贡献者。

欢迎关注「腾源会」公众号，期待你的「在看」哦～👇