唐旭 編譯自 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來討論也比郵件列表合適。
現在我們用這個郵件列表來發送信息和貼通知，還算是值得訂閱的。
代碼同步
和我聊過的許多人都對一件事表示十分吃驚——那就是在谷歌內部，我們使用的代碼庫和我們在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行業和研究動態。筆芯~
另外，歡迎加量子位小助手的微信：qbitbot，如果你研究或者從事AI領域，小助手會把你帶入量子位的交流群里。
追蹤人工智能領域最勁內容
京公網安備 11010502049343號