唐旭 编译自 O’reilly

　　量子位 出品 | 公众号 QbitAI

　　TensorFlow开源一年半以来，在GitHub上已经有了820位贡献者，close了5192条issue，还有1033条开放着。

　　同时，如果所有TensorFlow团队成员都在GitHub上，而且属于这个组织的话，它在Google内部还有着一支75人的团队。

　　一支人数不算少的全职团队，是如何和数量众多的开源贡献者共同改进TensorFlow的呢？团队的技术主管Pete Warden带着深深的怨念，在O’reilly网站上发表文章，讲述了他们是如何维护TensorFlow开源社区的。

　　以下内容编译自Warden的文章：

　　开源可不只是把代码往GitHub上一扔，然后等着别人去用它就完事了。道理我都懂，可直到在谷歌成为TensorFlow团队的一员，我才真正开了眼：要围绕一个软件打造出一个社区，要考虑的因素实在是太多太多了。

　　社区服务

　　当一个新的项目刚刚诞生时，在这个项目上能被称作专家的，就只有那些把它写出来的人。他们是仅有的能够撰写文档和解答问题的人，同时，在对软件的改进方面，他们也是最佳人选。

　　但结果，我们这类TensorFlow团队中的核心成员反倒成为了项目成长的瓶颈。原因其实很简单：我们没法一次性把所有的事情都干完。是，我们确实知道该怎么腾出时间去写代码和文档，因为这本来就是我们在谷歌日常工作的一部分；但要给一个超大社区里的众多开发者解答问题，我们就有点懵比了——尽管我们知道，这对于项目的成功十分重要。

　　为了确保用户们能够得到他们需要的答案，核心工程团队的全体成员开始轮班。每个人可以从以下几个活里自己挑：处理Stack Overflow上带有#tensorflow标签的问题、检查一遍GitHub上的pull request、给GitHub上的issue分类、同步外部和内部代码，或是找到那些失败测试的原因。

　　如何分配这些工作由大伙自己决定。一般来讲，如果每个工程师每次在一个特定领域负责一周的话，atv， 我们勉强能让这个轮班机制循环起来。这个机制实行之后，工程师们在他们值班当周的本职工作产出会大大降低——不过至少，atv直播，每个人的工作被打断的频率降到了几个月一次。

　　Pull request

　　我们将TensorFlow开源来让社区能够对其贡献力量。到目前为止，已经有超过400人从外部为我们贡献了代码，这其中既包括简单的文档修复，也包括像OS X的GPU支持、OpenCL的执行、InfiniBand架构下RDMA这样的大输血。首先，每次贡献都会先从轮值核心工程师那里审一遍，以确定其是否真的管用；如果方案通过了最初的审核，我们会对它进行一组Jenkins测试来确保它不会引发任何故障；如果以上两道程序都被通过了，轮值工程师会将方案交给另一位更加擅长相关领域的核心工程师再次进行审核。

　　在这一过程中，GitHub全新的精细代码审核工具能够为我们提供极大的帮助。而在它出现之前，要把所有人的评价都处理一遍是个十分痛苦的事情。当一名核心工程师与一位或更多的外部贡献者协作时，经常会有更大的pull request会被放入正在进行的工作中。直到每个人都满意之后，PR就会被合并到GitHub上的树顶，并在下一次同步运行时被合并进我们的内部代码库。

　　代码许可协议

　　作为自动化pull request程序的一部分，我们会将贡献者的GitHub账号与我们在谷歌开发者网站上的代码许可协议（CLA）记录相匹配，以确保每个外部贡献者都拿到了CLA。我们的目标是是确保整个代码库都在阿帕奇2.0协议下准确无误地得到了分配。当pull request的轮值工程师要对出现的全部问题进行归类的时候，如果一个pull request的内部关联了多个邮箱，或是贡献者需要以团体名义登录，情况就会变得十分麻烦。

　　GitHub issue

　　GitHub用户们已经提交了5000多个关于TensorFlow的issue。对于有些人来说，这可能有点让人沮丧；但对我来说，issue却是个最棒的单位——因为它证明，人们是真的在使用这个软件。

　　为了确保我们回应了每个存档的issue，轮值工程师会时刻查看新出现的信息并试着用标签对其进行分类。如果那是个我们在短期内无法在内部搞定的问题，它就会被标记成“欢迎贡献”；对于一些待处理的bug，我们会给他们按轻重缓急排个次序。这些天来，随着一些外部用户自己变成了某些问题的专家，越来越多的问题没有借助我们的力量就被解决掉了，特别是在像Windows这类我们不会每天都用的平台上。