TensorFlow技術主管詳解技術社區運營的九大心法

Pete Warden是TensorFlow Mobile團隊的技術主管，之前是Jetpac的首席技術官，該公司於2014年被Google收購，研發用於在移動和嵌入式設備上優化的深度學習技術。他以前曾在蘋果公司處理GPU優化圖像處理方面的工作。

開源不是把一堆代碼扔出去給大家用就算了，作為Google的TensorFlow團隊成員之一，開源真的開闊了我的眼界，也了解到要圍繞一個技術框架建立一個社區需要多少付出。

▍冷啟動

當一個新項目面世，唯一了解它的專家就只有那些開發它的人。他們既是唯一能夠編寫文檔和解答相關問題的人，也是能最快使系統迭代的人。我們這個TensorFlow的核心團隊成為系統更新的瓶頸，因為我們無法一勞永逸。 我們知道如何編寫代碼和文檔，因為這些都是Google日常工作的一部分，但回復社區用戶的問題則不是我們以往的日工作內容，儘管我們很清楚這對系統來說有多重要。

為了確保用戶得到及時有用的回復，核心團隊的成員都加入「輪班」。 團隊成員可以根據帶有#tensorflow標記的堆棧問題篩出，在GitHub上查看修改意見，分類GitHub問題，處理同步外部和內部代碼，或者追查測試失敗的原因。每個工程師在某特定領域負責一個星期，大家輪班負責。 因此，組織工程師可能某一周在他本職工作方面的生產力要低一些，但也就每隔幾個月才有這麼一周。

▍用戶回復

我們把TensorFlow開源，是為了使系統在參與者的使用下得到更好的提升。目前為止，我們已經把超過400個外部貢獻者的修改意見添加到代碼中，小到文檔修復，大到諸如OS X GPU支持，OpenCL實現或InfiniBand RDMA之類的大量添加。

首先，「值班」核心工程師會對每項「貢獻」進行審查，確定意見是否有用。通過初始審查後，則會啟動一組Jenkins測試，以確保它不會導致系統發生任何故障。通過測試後，值班工程師可能會把意見轉交給其他在該領域更擅長的核心工程師進行審查。

GitHub最新的代碼審查工具對這個審查過程非常有幫助；在還沒使用這個工具之前，處理如此大量的個人意見，真的太痛苦了……通常，更重要的網頁級別（PR）會在系統中保持一段時間，核心工程師和和外部貢獻者一起協同工作。如果大家都對結果很滿意，就會將網頁級別在GitHub上置頂，然後在下次運行時，同步合并到我們的內部代碼庫中。

▍代碼許可協議

▍GitHub問題

已經有超過5000個問題是關於TensorFlow，雖然數字看起來不算漂亮，但我超喜歡這個數據，因為這說明人們真的在用這個軟體系統！

為了確保我們對每個問題都作出及時回應，當值班的工程師收到新消息的時候，會嘗試對它們進行標籤分類。如果問題的特徵不夠明顯以至於無法快速分類，我們會將其標記為「貢獻歡迎」，如果是關於漏洞的，我們會優先處理。近日，我們發現越來越多的問題在沒有我們的幫助下也得到了有效的解決，這得益於外部用戶在逐漸成為TensorFlow的專家，尤其是在Windows這樣我們不是每天都在用的系統。

如果沒有來自社區其他用戶的回復或解決方案，而這個問題又具有高優先度，值班人員就會將其分配給我們當中對這一領域比較了解的工程師。整個TensorFlow團隊都有GitHub帳戶，所以我們可以使用的GitHub問題跟蹤器來分配問題。

我們也考慮了內部系統的跟蹤缺陷，但是同步信息至兩個平台的成本太高了。我們不得不打開GitHub上的電子郵件通知，以便他們除了關注我們的內部跟蹤器，還能及時看到關於漏洞的反饋和分配情況。

▍堆棧溢出問題

Derek Murray是Stack Overflow輪班的負責人，我十分敬佩他解決問題的能力！根據他的個人資料頁面，他已經解答了130多萬人的問題。他還搭建了一個由RSS源驅動的自動化電子表格，我們可以使用#tensorflow標籤在站點上跟蹤所有問題。我們每周開始輪班的時候，都會發現問題數量變得超級大，一個人根本處理不完。所以，我們現在用循環的方式自動分配問題。

我最近正在輪值，所以每天早上我看完自己的電子郵箱，就會去看看電子表格里我被分配到什麼問題。惱火的是，我們自己沒法解答所有問題，但我們會檢查每一個新收到的問題。如果是比較簡單的話，我們會自己解決。

值班工程師是接收問題的最前線，但有時候解答這些問題需要更多的時間和專業知識。如果有些問題看起來是（社區的用戶）可以解答但是沒人出來解決的，我們就會用代碼做簡單的調查（通常使用「git blame」）來看看團隊中誰能解決這些問題。然後，值班工程師會發送電子郵件來詢問內部專家能否提供幫助。

▍郵件列表

我們設置了一個郵件列表，但是起初我們不太明確它能用來做什麼。很快我們就發現了，如果用來追蹤問題和解答一般問題，這是個很糟糕的辦法。然而，我們保留了這個方法，用於討論一些特殊問題。實際上，我們發現即使像架構問題，GitHub問題能更好地擬合。現在我們使用郵件列表發送信息和發布公告，還是值得訂閱的。

▍代碼同步

很多人驚訝於，我們在Google內部使用的代碼庫，和我們在GitHub上公開的幾乎完全相同。但其實還是有一些區別的：例如，僅支持Google的基礎架構是分開的，包括路徑也是不同的，但同步過程是完全機械自動的。我們至少每周進行一次內部迭代，在GitHub上就更頻繁了。

最棘手的是，我們在進行雙向同步。GitHub公開項目和我們的內部版本有很多同步的更改，我們需要來回整合這些改動。現在還沒有我們可以使用的現成基礎架構，所以只能用一組我們創建的Python腳本來處理。腳本會將GitHub上的更改引入到內部源存儲庫中，轉換所有標題路徑和其他次要更改，並把它們與最新的內部代碼合并，創建新的內部副本。然後我們還要完成反方向的工作，將所有內部代碼轉換為外部格式，並使用相同的腳本將結果整合至最新的GitHub。

處理內部更改時，我們也盡量確保每個改動都以單獨git提交，並包括作者的GitHub賬號和解釋更改的注釋。我們在GitHub上有一個專門的「tensorflow-gardener」賬號，用來完成這個流程，你也可以查看到內部更改整合到GitHub上的效果。

確保轉換過程在代碼更改過程中繼續運行是一個高難度動作。為了確保這個運作可行，我們要確保每個內部變化都可以通過腳本在一個外部版本上運行，然後再回到內部版本，並且與原來的內部版本沒有區別。每個觸及TensorFlow代碼庫的內部更改都要運行此測試，並阻止任何未通過的提交。對於某些修改意見，我們有時會要求其作奇怪的改動，這是為了確保他們的代碼能與基礎架構一起運作。

▍詹金斯（Jenkins）測試

我們希望搭建一個廣泛的測試基礎架構，以此來支持眾多平台。TensorFlow可在Linux，Windows和OS X筆記本上運行，也可用於iOS，Android，Android Things和Raspberry Pi等移動和嵌入式系統。我們還有不同的GPUs代碼路徑，支持包括CUDA和OpenCL，以及Bazel，cmake和plain makefile構建過程。

每個開發人員不可能在每次更改時手動測試所有的這些組合，為此，我們在大多數平台上都有一套由Jenkins自動系統控制的自動化測試系統。要維護這麼一個系統需要耗費大量的時間和精力，因為操作系統在不斷更新，還有硬體問題以及與TensorFlow無關可能導致測試失敗的問題。而這個專門保障整個測試過程的工程師團隊，使我們免受許多破壞，所以這筆投資是值得的。

▍開發者關係

在谷歌開源工作中，我們並非孤軍作戰，我們從其他項目如Kubernetes和Office開放源代碼計劃（也有一套很好的文檔）學到了很多。我們有一支超刻苦的專家開發團隊協助我們，他們處理了大量文檔，代碼示例以及其他重要部分。我們的願景是發展更多核心開發人員以外的「專家」，使Google內部和外部能有更多人幫助社區的運營。

讓核心工程師們輪班當「客服」的好處在於，我們能得到用戶使用時遇到的問題的第一手消息。參與「客服」工作也促使我們修復常見的漏洞並添加進文檔，我們能直觀地感受到運維工作量在減少。

希望隨著更多人熟悉框架的內部細節，文檔的改進，以及我們為處理日常問題（如錯誤分類）創建的「劇本」，我們能使工作內容和範圍覆蓋更廣。到目前為止，能和這麼多外部開發人員溝通交流，真的太開心了，希望能幫助他們通過機器學習開發一些酷炫的新產品！

作者：Pete Warden

整理：珊珊

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！