唐旭 编译自 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分类、同步外部和内部代码，或是找到那些失败测试的原因。

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

　　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这类我们不会每天都用的平台上。

　　如果一个issue没能在社区中找到回答或修复，而它的优先级又足够高时，值班的人就会把它分配给团队里一个了解此类问题的工程师。整个TensorFlow团队的成员都有自己的GitHub账号，因此我们可以用正常的GitHub issue追踪器来实现任务的分配。我们确实考虑过把GitHub上提交的bug复制到我们的内部系统中，但要为相同信息同步两份副本，代价太高了。最后，我们让工程师们除了留意内部系统的追踪器之外，也要打开邮件通知，以便能够及时看到自己被分配了哪些GitHub上的问题。

　　Stack Overflow

　　Derek Murray是Stack Overflow值班小组的带头大哥，我觉得他回答问题的技能真是碉堡了。根据他的资料页，这个人发过的帖子已经触及到了130万人；为了让我们能够及时追踪网站上那些带有#TensorFlow标签的问题，他还设法创建了一个RSS驱动的自动化电子表格。起初我们采取每周轮班制，但发现要处理问题的量对于一个人来讲实在是太大了；后来我们采用了自动分配系统，情况变得好多了。

　　我本人就在这个轮班小组里，因此每天早上我浏览完自己的邮件后，我都会查看电子表格来弄清楚自己被分配到了哪些问题。很遗憾，我们没法自己回答全部的问题，但每一个新进来的问题我们都会看。如果问题相对简单的话，我们就自己把它答了。

　　当然，值班的工程师得顶到被问题轰炸的前线去，但有些时候，回答某些问题需要更多的时间和专业知识。如果某个问题看上去能被答出来，但社区里却没看见站出来的英雄，我们就会研究一下代码，扒一下团队里有谁可能会对这个问题有些想法（通常是用git blame）。然后值班工程师就会向我们找到的人发封邮件，看其是否能提供一点帮助。

　　邮件列表

　　我们设置了一个邮件列表，但起初却并不知道该怎么用它。我们很快就看出来，用这种方法来追踪issue和回答一般问题有多辣鸡。

　　后来，我们把它当成讨论区来用，GitHub和Stackoverflow都不合适的话题，就发到邮件列表，但是在实际操作中我们发现，即便是架构问题，用GitHub issue来讨论也比邮件列表合适。

　　现在我们用这个邮件列表来发送信息和贴通知，还算是值得订阅的。

　　代码同步

转载请注明出处。