|
唐旭 编译自 O’reilly 量子位 出品 | 公众号 QbitAITensorFlow开源一年半败兴，在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归类、同步外边和内部代码，或是找到哪些失败测试的原由。
怎样分配这些工作由大伙自己决定。通常来讲，倘若每一个工程师每次在一个特定行业负责1星期的话， 咱们勉强能让这个轮班机制循环起来。这个机制实行之后，工程师们在她们值班当周的本职工作产出会大大降低——不外最少，每一个人的工作被打断的频率降到了几个月一次。
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来讨论亦比邮件列表合适。
此刻咱们用这个邮件列表来发送信息和贴通告，还算是值得订阅的。
代码同步
和我聊过的许多人都对一件事暗示非常吃惊——那便是在谷歌内部，咱们运用的代码库和咱们在GitHub上所开放的几乎完全相同。不外，两者间还是存在一点区别的，比对谷歌专用基本设备的支持是独立的，路径亦和GitHub版不同样，但同步的过程是完全机械的。咱们最少每周推出一次内部更新，更加多时候是下载GitHub版本。
麻烦的是，咱们要进行双向同步。在GitHub的公共项目和咱们的内部版本上，有非常多变动是同期出现的，而咱们需要反反复复地把它们所有进行合并。无现成的基本架构可供利用，因此呢咱们运用了自己创造的一套Python脚本来处理这些问题。这些脚本能够将GitHub上所有的变动拉进咱们的内部资源库里，转换所有的header path和其他细微的变化，将它们和最新内部版代码合并，并在内部创建一个副本。随后就能够进行另一个方向的同步了，咱们会将所有的内部代码转换成外边的格式，并用相同的脚本把这些结果合并到最新的GitHub版上。
针对内部的修改，咱们一样会尽力让每次check-in都呈现为单独的git commit，同期把作者的GitHub账号和解释这些变动的评论包含在内。咱们在GitHub上有一个尤其的“TensorFlow园丁”账号来完成以上过程，一个内部的commit被转移到GitHub上之后，是这般的：
要保证即使代码变了，这个转换流程依然有效，是特别有挑战性的。为了验证这种有效性，咱们需求把内部代码经过这个脚本转换成外边版本，再转换回来之后，和最初的内部版一模同样。在任何接触到TensorFlow代码库的内部更改上，咱们都会运行这个测试，通不外测试的修改会被拒绝。
针对哪些提交pull request的人，咱们常常会提有些奇怪的变更需求，一般，这般做的原由是咱们必须保证她们的代码能适用于这个同步流程。
Jenkins测试
由于要支持非常多区别的平台，咱们期盼有一个适用范围很广的测试工具。TensorFlow会在Linux、Windows、OS X、iOS、Android、Android Things、以及树莓派上运行，同期咱们还有为GPU准备的区别代码路径，包含CUDA和OpenCL支持、以及Bazel、cmake，和无格式makefile的构建进程。
让每一位研发者都在做了变更时手动把上面这些东西全都测试一遍，是不可能的。因此呢，咱们有一套能在绝大部分支持平台上运行的自动化测试系统，这些系统全都处在Jenkins自动化系统的掌控之下。始终让它们发挥功效亦不是件容易事，由于总会存在操作系统更新、硬件问题以及其他有些与TensorFlow关联的问题能让测试失败。咱们有一个工程师团队，专门负责让全部测试系统正常运行，这个团队曾经在系统出问题的时候救过咱们非常多次。因此呢在这方面的投入亦是值得的。
研发者关系
在开源行业，咱们在谷歌并不孤独：咱们曾经在Kubernetes和“ 开源计划办公室”（Open Source Program Office）这般的项目上学到过非常多东西。有一支非常勤奋的研发者关系专家团队帮助咱们处理这些事务，她们还承担了非常多围绕文档、代码示例以及其他有些研发者经验方面问题而产生的体力活。咱们的长时间目的是，将关键的专业知识传递到核心研发者之外的范围，以便更加多的人能够对社区有所贡献。
让这些核心工程师在部分时间内去承担客户服务工作的一大好处是，它给了咱们关于用户所遇到问题的直接洞见。参与客户服务一样驱动着我们去修复哪些平常的bug和弥补文档，由于它在减少工作量方面让咱们看见了直接的报答。
将来，咱们期盼将这项工作更广泛地进行下去。同期，咱们亦设计了更加多的“战术指点手册”以帮忙人们处理平常任务。能有机会同如此多的外边研发者互动，我感觉非常幸运；我亦期盼，自己能对她们产生积极的影响，帮忙她们用设备学习创造新的神奇应用。
关于作者
Pete Warden是TensorFlow Mobile团队技术主管。在加入Google之前，他曾任Jetpac CTO，该机构供给为手机和嵌入式设备而优化的深度学习技术，2014年被Google收购。他还曾在苹果工作，负责图像处理的GPU优化。（完）
招聘
量子位正在招募编辑记者、运营、制品等岗位，工作地点在北京中关村。关联细节，请在公众号对话界面，回复：“招聘”。
One More Thing…
今天AI界还有那些事值得关注？在量子位（QbitAI）公众号会话界面回复“今天”，看咱们全网搜罗的AI行业和科研动态。笔芯~
另一，欢迎加量子位小助手的微X：qbitbot，倘若你科研或从事AI行业，小助手会把你带入量子位的交流群里。 
△ 扫码强行关注『量子位』
跟踪人工智能行业最劲内容
| 
发表于 2024-7-28 01:20:00