原標題：TensorFlow團隊如何管理和支持開源項目——在開源社區幫助下改進軟件需要耐心和良好的組織 編者注：更多關于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）。 我們的目標是確認整個代碼庫的發布可以完全符合Apache 2.0許可證。如果電子郵件地址與提交請求中的登記信息不同，或者如果貢獻者需要以公司身份登錄時可能會很棘手。然而負責提交請求的工程師會來處理任何出現的問題。 TensorFlow項目已經收到了5000多個的問題提交。這可能看起來令人沮喪，但這正是我最喜歡的指標，因為這說明人們真正地在使用我們的軟件！為了確保我們對每個提交的問題都有回復，值班工程師在看到他們提交的消息時會嘗試使用標簽進行分類。如果這是一個我們不太可能短期內在內部實現的功能，我們會將其標記為“歡迎貢獻”。而對于程序缺陷，我們會考慮其優先級。現在我們越來越多地看到問題無需我們的幫助就能得到解決。因為外部用戶自己已經慢慢成為專家，特別是像在Windows這樣我們并不是每天都在使用的平臺上。 如果開源社區沒有答案或解決方案，并且這是一個有足夠高優先級的問題，值班工程師會將其分配給熟悉該領域的工程師。整個TensorFlow團隊都有GitHub帳戶，所以我們可以使用正常的GitHub問題系統來分配問題。我們確實考慮過在我們的內部系統中問題，但同步兩個相同信息的成本太高了。因此我們要求我們的工程師打開GitHub上的問題電子郵件通知，以便他們除了關注我們的內部系統以外還可以看到他們在GitHub上被分配到的問題。 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無關的可能導致測試失敗的其他問題。我們有一個工程師團隊致力于整個測試過程。這個團隊使我們的工作免遭潛在問題的，所以對這個團隊的投資是值得的。 我們在Google從事開源工作并不孤單，我們也從其他諸如Kubernetes和Open Source Program Office項目（他們也有一套很好的文檔）中學到了很多。我們有一個非常努力的開發人員關系專家團隊來協助我們，他們處理了大量繁重的文檔、代碼示例以及開發人員體驗的其他重要部分。我們的長期目標是將關鍵專業知識轉移到核心開發人員之外，以便更多的Google員工和Google外部人員可以幫助到社區。 讓核心工程師兼職參與客戶服務的一大好處就是讓我們直接了解用戶所遇到的問題。參與客戶服務也促使我們可以改進常見的程序缺陷并添加文檔，所以我們可以直觀地看到這些工作所帶來的客戶支持工作量的減少。 在不久的將來，我們希望隨著更多的人熟悉Tensorflow框架的內部細節、文檔質量的不斷提高以及我們為處理常見任務（如程序缺陷分類）創建更多的“指南”，我們的工作量能更多地被分配出去。至此我很幸運有機會能與這么多的外部開發人員進行互動，希望對其中的一些人產生積極的影響，幫助其創造激動的基于機器學習的新應用程序。
Pete Warden是TensorFlow Mobile團隊的技術主管。他之前是Jetpac的首席技術官。Jetpac于2014年被Google收購，以優化Google在移動和嵌入式設備上的深入學習技術。他以前曾在蘋果從事用于圖像處理的GPU的優化工作，并為OReilly撰寫了幾本關于數據處理的書籍。返回搜狐，查看更多 推薦：
|
