TensorFlow團隊如何管理和支援開源專案——在開源社群幫助下改進軟體需要耐心和良好的組織

---

Strata Data Conference早期門票優惠價格今天即將截止！

有需求的同學還請抓緊時間，

點選二維碼即可登入會議官網報名。

---

編者注：更多關於TensorFlow近兩年的進展及未來展望可以參考Strata倫敦2017的相關議題。

開源不僅僅是把程式碼共享到網路上，而是希望有人能使用它。從理論上講我知道怎麼做，但是作為Google TensorFlow團隊的一員，我對圍繞一個軟體構建開源社群所需的各種不同的元素已大開眼界。

社群服務

當一個新專案在全球釋出時，該專案獨有的專家就是開發這個專案的人。他們是唯一可以撰寫文件和回答問題的人，也是能最有效地改進軟體的人。但與此同時，TensorFlow核心團隊的我們卻成為了這個專案擴充套件的瓶頸：我們無法同時完成所有事情。我們確實知道如何編寫程式碼和文件，因為這些任務是我們在Google日常工作的一部分。而另一方面，儘管我們知道回答大型開發者社群的問題對專案的成功至關重要，但這並不是我們習慣處理的事情。

為了確保使用者獲得所需的答案，核心工程團隊的成員都要輪流值班負責開源專案。團隊成員可以選擇解決Stack Overflow上標記為#tensorflow的問題，在GitHub上檢視提交程式碼的請求，分類GitHub問題，處理外部和內部程式碼的同步問題，或者是追查測試失敗的原因。

從事這些的工程師可以選擇如何分工。通常每個工程師每次會對某個特定領域負責一個星期，所有可工作的工程師輪流迴圈負責。因此負責的工程師在那周的日常工作中的生產力要低得多，但每個人至少每隔幾個月才會遇到一次這樣的打擾。

程式碼提交請求

我們開源TensorFlow專案的部分原因是為了讓社群貢獻者來改善它。到目前為止，我們已經有超過400個外部貢獻者新增了程式碼，從小的文件修復到大的諸如OS X GPU支援、OpenCL實現或InfiniBand RDMA等的程式碼新增。整個流程如下。首先，輪流負責開源專案的核心工程師必須對每項貢獻進行審查以確定它是否有意義。如果貢獻通過初始審查，則會啟動一組Jenkins測試以確保其不會導致任何錯誤。一旦這些都通過了，值班工程師可能會將其轉交給另外一個更熟悉該領域的核心工程師進行進一步審查。

GitHub新的詳細程式碼審查工具在這個過程中起到了很大的幫助作用。在這之前，處理所有的個人意見對工程師來說是件痛苦的事情。通常越大的程式碼提交請求在這個過程中持續的時間會越長，雖然會有一個核心工程師和一個或多個外部貢獻者在協同工作。一旦每個人都認同該請求，這個提交請求將會合併到Github上專案的樹頂部，並在下次執行同步時合併到我們的內部程式碼庫中。

程式碼許可協議

作為我們自動提交請求過程的一部分，我們可以通過將貢獻者的GitHub帳戶名稱與我們在cla.developers.google.com上的記錄相匹配來確保任何外部貢獻都遵循程式碼許可協議（CLA）。 我們的目標是確認整個程式碼庫的釋出可以完全符合Apache 2.0許可證。如果電子郵件地址與提交請求中的登記資訊不同，或者如果貢獻者需要以公司身份登入時可能會很棘手。然而負責提交請求的工程師會來處理任何出現的問題。

GitHub上關於TensorFlow的問題

TensorFlow專案已經收到了5000多個的問題提交。這可能看起來令人沮喪，但這正是我最喜歡的指標，因為這說明人們真正地在使用我們的軟體！為了確保我們對每個提交的問題都有回覆，值班工程師在看到他們提交的訊息時會嘗試使用標籤進行分類。如果這是一個我們不太可能短期內在內部實現的功能，我們會將其標記為“歡迎貢獻”。而對於程式缺陷，我們會考慮其優先順序。現在我們越來越多地看到問題無需我們的幫助就能得到解決。因為外部使用者自己已經慢慢成為專家，特別是像在Windows這樣我們並不是每天都在使用的平臺上。

如果開源社群沒有答案或解決方案，並且這是一個有足夠高優先順序的問題，值班工程師會將其分配給熟悉該領域的工程師。整個TensorFlow團隊都有GitHub帳戶，所以我們可以使用正常的GitHub問題跟蹤系統來分配問題。我們確實考慮過在我們的內部系統中跟蹤問題，但同步兩個相同資訊的成本太高了。因此我們要求我們的工程師開啟GitHub上的問題電子郵件通知，以便他們除了關注我們的內部跟蹤系統以外還可以看到他們在GitHub上被分配到的問題。

Stack Overflow

Derek Murray是Stack Overflow輪流值班的負責人，我深深佩服他回答問題的能力。根據他的個人資料頁面，他的帖子已經影響和幫助了130多萬人。他還設法建立了一個由RSS源驅動的自動化電子表格，以便我們可以使用#tensorflow標籤來跟蹤站點上的所有問題。剛開始的時候我們每週輪流一次，但後來發現問題數量變得太大以至於一個人處理不了了。而現在我們按照多人迴圈處理的方式自動分配提交上來的問題。

當我在值班時，每天早上我會檢視我的郵件並會檢視電子表格分配給我什麼問題。不幸的是，我們自己無法回答所有的Stack Overflow上的問題，但是我們會檢視所有的問題。如果某個問題比較簡單，我們會嘗試自己來回答。

值班工程師戰鬥在處理提交上來的問題的前線，但有時候回答問題需要更多的時間或專業知識。如果問題看上去是可以回答的，但開源社群中沒有人主動回答，我們會在程式碼中做一些查詢工作（通常使用“git blame”）來確定團隊中誰可能會有一些想法。然後值班工程師會傳送一封電子郵件給我們識別出的該內部專家來詢問是否可以提供幫助。

郵件列表

我們有設定一個郵件列表，但是起初我們不太清楚它應該用來做什麼。很快我們就發現它並不是一種跟蹤問題或回答普通問題的好方法。

儘管如此，我們仍然將郵件列表用在不適合其他任何方式的討論中。然而在實踐中我們發現即使對於架構問題的討論，GitHub可能更合適。現在我們使用郵件列表來傳送資訊並分享公告，這還是值得訂閱的。

程式碼同步

很多人都驚訝地發現我們在Google內部使用的程式碼庫與Github上共享的幾乎完全相同。不過還是有一些區別的：例如對 Google獨有的基礎架構的支援是不同的並且包含路徑是不同的，但是同步過程是完全一致的。我們每週至少進行一次內部變更推送，而從Github上拉取程式碼則更頻繁。

棘手的部分是我們需要做雙向同步。在GitHub公共專案上和我們的內部版本中都有很多同時進行的更改，我們需要將它們全部合併在一起。我們沒有現成的基礎架構可以使用，所以我們建立了一組Python指令碼來處理這個問題。指令碼將GitHub的更改匯入到我們的內部資源倉庫中，轉換所有標題路徑和其他小的更改，並將其與最新的內部程式碼合併建立一個內部副本。然後我們從另一個方向，將所有內部程式碼轉換為外部格式，並使用該指令碼將轉換結果與GitHub上最新的程式碼進行合併。

對於內部更改，我們也盡力確保每個提交都顯示為單個git提交，幷包括作者的GitHub帳戶和更改註釋。我們在GitHub上有一個特殊的“tensorflow-gardener”帳戶用於管理此過程。您可以在這裡看到一個內部提交在遷移到GitHub之後的樣子。

確保轉換過程在程式碼發生變化時仍能正常工作是一項具有挑戰性的任務。為了驗證其功能，我們要確保每個內部更改都可以通過執行該指令碼轉換到外部版本，同時能再反方向轉換回內部版本，並且與原始內部版本沒有任何差別。該測試執行在涉及TensorFlow程式碼庫的每個內部變化上，並阻止任何未通過測試的提交。對於那些傳送來的提交請求，我們有時會要求作者進行一些奇怪的更改，這通常是因為我們必須確保他們的程式碼能適用於這一同步基礎架構。

Jenkins測試

由於TensorFlow需要支援很多平臺，因此我們希望擁有涉及面廣泛的測試基礎框架。TensorFlow需要能夠執行在Linux、Windows和OS X的桌面作業系統以及在iOS、Android、Android Things和Raspberry Pi的移動和嵌入式系統上。我們針對GPU還有不同的程式碼路徑，包括對CUDA和OpenCL的支援，以及Bazel、cmake和簡單的makefile的構建過程。

我們不可能讓每個開發人員在進行程式碼更改時手動測試所有的這些組合，因此我們執行了一套支援大多數平臺的自動化測試程式，所有這些都由Jenkins自動化系統控制。維護這一系統的運作需要大量的時間和精力，因為總是存在作業系統更新、硬體問題以及與TensorFlow無關的可能導致測試失敗的其他問題。我們有一個工程師團隊致力於維護整個測試過程。這個團隊使我們的工作免遭潛在問題的破壞，所以對這個團隊的投資是值得的。

開發人員關係

我們在Google從事開源工作並不孤單，我們也從其他諸如Kubernetes和Open Source Program Office專案（他們也有一套很好的文件）中學到了很多。我們有一個非常努力的開發人員關係專家團隊來協助我們，他們處理了大量繁重的文件、程式碼示例以及開發人員體驗的其他重要部分。我們的長期目標是將關鍵專業知識轉移到核心開發人員之外，以便更多的Google員工和Google外部人員可以幫助到社群。

讓核心工程師兼職參與客戶服務的一大好處就是讓我們直接瞭解使用者所遇到的問題。參與客戶服務也促使我們可以改進常見的程式缺陷並新增文件，所以我們可以直觀地看到這些工作所帶來的客戶支援工作量的減少。

在不久的將來，我們希望隨著更多的人熟悉Tensorflow框架的內部細節、文件質量的不斷提高以及我們為處理常見任務（如程式缺陷分類）建立更多的“指南”，我們的工作量能更多地被分配出去。至此我很幸運有機會能與這麼多的外部開發人員進行互動，希望對其中的一些人產生積極的影響，幫助其創造激動人心的基於機器學習的新應用程式。

This article originally appeared in English: "How the TensorFlow team handles open source support".

Pete Warden

Pete Warden是TensorFlow Mobile團隊的技術主管。他之前是Jetpac的技術長。Jetpac於2014年被Google收購，以優化Google在移動和嵌入式裝置上的深入學習技術。他以前曾在蘋果從事用於影象處理的GPU的優化工作，併為O'Reilly撰寫了幾本關於資料處理的書籍。