原標(biāo)題：TensorFlow團隊如何管理和支持開源項目——在開源社區(qū)幫助下改進軟件需要耐心和良好的組織 編者注：更多關(guān)于TensorFlow近兩年的進展及未來展望可以參考Strata倫敦2017的相關(guān)議題。 開源不僅僅是把代碼共享到網(wǎng)絡(luò)上，而是希望有人能使用它。從理論上講我知道怎么做，但是作為Google TensorFlow團隊的一員，我對圍繞一個軟件構(gòu)建開源社區(qū)所需的各種不同的元素已大開眼界。 當(dāng)一個新項目在全球發(fā)布時，該項目獨有的專家就是開發(fā)這個項目的人。他們是唯一可以撰寫文檔和回答問題的人，也是能最有效地改進軟件的人。但與此同時，TensorFlow核心團隊的我們卻成為了這個項目擴展的瓶頸：我們無法同時完成所有事情。我們確實知道如何編寫代碼和文檔，因為這些任務(wù)是我們在Google日常工作的一部分。而另一方面，盡管我們知道回答大型開發(fā)者社區(qū)的問題對項目的成功至關(guān)重要，但這并不是我們習(xí)慣處理的事情。 為了確保用戶獲得所需的答案，核心工程團隊的都要輪流值班負責(zé)開源項目。團隊可以選擇解決Stack Overflow上標(biāo)記為#tensorflow的問題，在GitHub上查看提交代碼的請求，分類GitHub問題，處理外部和內(nèi)部代碼的同步問題，或者是測試失敗的原因。 從事這些的工程師可以選擇如何分工。通常每個工程師每次會對某個特定領(lǐng)域負責(zé)一個星期，所有可工作的工程師輪流循環(huán)負責(zé)。因此負責(zé)的工程師在那周的日常工作中的生產(chǎn)力要低得多，但每個人至少每隔幾個月才會遇到一次這樣的打擾。 我們開源TensorFlow項目的部分原因是為了讓社區(qū)貢獻者來改善它。到目前為止，我們已經(jīng)有超過400個外部貢獻者添加了代碼，從小的文檔修復(fù)到大的諸如OS X GPU支持、OpenCL實現(xiàn)或InfiniBand RDMA等的代碼添加。整個流程如下。首先，輪流負責(zé)開源項目的核心工程師必須對每項貢獻進行審查以確定它是否有意義。如果貢獻通過初始審查，則會啟動一組Jenkins測試以確保其不會導(dǎo)致任何錯誤。一旦這些都通過了，值班工程師可能會將其轉(zhuǎn)交給另外一個更熟悉該領(lǐng)域的核心工程師進行進一步審查。 GitHub新的詳細代碼審查工具在這個過程中起到了很大的幫助作用。在這之前，處理所有的個人意見對工程師來說是件痛苦的事情。通常越大的代碼提交請求在這個過程中持續(xù)的時間會越長，雖然會有一個核心工程師和一個或多個外部貢獻者在協(xié)同工作。一旦每個人都認同該請求，這個提交請求將會合并到Github上項目的樹頂部，并在下次運行同步時合并到我們的內(nèi)部代碼庫中。 作為我們自動提交請求過程的一部分，我們可以通過將貢獻者的GitHub帳戶名稱與我們在的記錄相匹配來確保任何外部貢獻都遵循代碼許可協(xié)議（CLA）。 我們的目標(biāo)是確認整個代碼庫的發(fā)布可以完全符合Apache 2.0許可證。如果電子郵件地址與提交請求中的登記信息不同，或者如果貢獻者需要以公司身份登錄時可能會很棘手。然而負責(zé)提交請求的工程師會來處理任何出現(xiàn)的問題。 TensorFlow項目已經(jīng)收到了5000多個的問題提交。這可能看起來令人沮喪，但這正是我最喜歡的指標(biāo)，因為這說明人們真正地在使用我們的軟件！為了確保我們對每個提交的問題都有回復(fù)，值班工程師在看到他們提交的消息時會嘗試使用標(biāo)簽進行分類。如果這是一個我們不太可能短期內(nèi)在內(nèi)部實現(xiàn)的功能，我們會將其標(biāo)記為“歡迎貢獻”。而對于程序缺陷，我們會考慮其優(yōu)先級�，F(xiàn)在我們越來越多地看到問題無需我們的幫助就能得到解決。因為外部用戶自己已經(jīng)慢慢成為專家，特別是像在Windows這樣我們并不是每天都在使用的平臺上。 如果開源社區(qū)沒有答案或解決方案，并且這是一個有足夠高優(yōu)先級的問題，值班工程師會將其分配給熟悉該領(lǐng)域的工程師。整個TensorFlow團隊都有GitHub帳戶，所以我們可以使用正常的GitHub問題系統(tǒng)來分配問題。我們確實考慮過在我們的內(nèi)部系統(tǒng)中問題，但同步兩個相同信息的成本太高了。因此我們要求我們的工程師打開GitHub上的問題電子郵件通知，以便他們除了關(guān)注我們的內(nèi)部系統(tǒng)以外還可以看到他們在GitHub上被分配到的問題。 Derek Murray是Stack Overflow輪流值班的負責(zé)人，我深深他回答問題的能力。根據(jù)他的個人資料頁面，他的帖子已經(jīng)影響和幫助了130多萬人。他還設(shè)法建立了一個由RSS源驅(qū)動的自動化電子表格，以便我們可以使用#tensorflow標(biāo)簽來站點上的所有問題。剛開始的時候我們每周輪流一次，但后來發(fā)現(xiàn)問題數(shù)量變得太大以至于一個人處理不了了。而現(xiàn)在我們按照多人循環(huán)處理的方式自動分配提交上來的問題。 當(dāng)我在值班時，每天早上我會查看我的郵件并會查看電子表格分配給我什么問題。不幸的是，我們自己無法回答所有的Stack Overflow上的問題，但是我們會查看所有的問題。如果某個問題比較簡單，我們會嘗試自己來回答。 值班工程師戰(zhàn)斗在處理提交上來的問題的前線，但有時候回答問題需要更多的時間或?qū)I(yè)知識。如果問題看上去是可以回答的，但開源社區(qū)中沒有人主動回答，我們會在代碼中做一些查詢工作（通常使用“git blame”）來確定團隊中誰可能會有一些想法。然后值班工程師會發(fā)送一封電子郵件給我們識別出的該內(nèi)部專家來詢問是否可以提供幫助。 我們有設(shè)置一個郵件列表，但是起初我們不太清楚它應(yīng)該用來做什么。很快我們就發(fā)現(xiàn)它并不是一種問題或回答普通問題的好方法。 盡管如此，我們?nèi)匀粚⑧]件列表用在不適合其他任何方式的討論中。然而在實踐中我們發(fā)現(xiàn)即使對于架構(gòu)問題的討論，GitHub可能更合適�，F(xiàn)在我們使用郵件列表來發(fā)送信息并分享公告，這還是值得訂閱的。 很多人都驚訝地發(fā)現(xiàn)我們在Google內(nèi)部使用的代碼庫與Github上共享的幾乎完全相同。不過還是有一些區(qū)別的：例如對 Google獨有的基礎(chǔ)架構(gòu)的支持是不同的并且包含徑是不同的，但是同步過程是完全一致的。我們每周至少進行一次內(nèi)部變更推送，而從Github上拉取代碼則更頻繁。 棘手的部分是我們需要做雙向同步。在GitHub公共項目上和我們的內(nèi)部版本中都有很多同時進行的更改，我們需要將它們?nèi)亢喜⒃谝黄�。我們沒有現(xiàn)成的基礎(chǔ)架構(gòu)可以使用，所以我們創(chuàng)建了一組Python腳本來處理這個問題。腳本將GitHub的更改導(dǎo)入到我們的內(nèi)部資源倉庫中，轉(zhuǎn)換所有標(biāo)題徑和其他小的更改，并將其與最新的內(nèi)部代碼合并創(chuàng)建一個內(nèi)部副本。然后我們從另一個方向，將所有內(nèi)部代碼轉(zhuǎn)換為外部格式，并使用該腳本將轉(zhuǎn)換結(jié)果與GitHub上最新的代碼進行合并。 對于內(nèi)部更改，我們也盡力確保每個提交都顯示為單個git提交，并包括作者的GitHub帳戶和更改注釋。我們在GitHub上有一個特殊的“tensorflow-gardener”帳戶用于管理此過程。您可以在這里看到一個內(nèi)部提交在遷移到GitHub之后的樣子。 確保轉(zhuǎn)換過程在代碼發(fā)生變化時仍能正常工作是一項具有挑戰(zhàn)性的任務(wù)。為了驗證其功能，我們要確保每個內(nèi)部更改都可以通過運行該腳本轉(zhuǎn)換到外部版本，同時能再反方向轉(zhuǎn)換回內(nèi)部版本，并且與原始內(nèi)部版本沒有任何差別。該測試運行在涉及TensorFlow代碼庫的每個內(nèi)部變化上，并任何未通過測試的提交。對于那些發(fā)送來的提交請求，我們有時會要求作者進行一些奇怪的更改，這通常是因為我們必須確保他們的代碼能適用于這一同步基礎(chǔ)架構(gòu)。 我們不可能讓每個開發(fā)人員在進行代碼更改時手動測試所有的這些組合，因此我們運行了一套支持大多數(shù)平臺的自動化測試程序，所有這些都由Jenkins自動化系統(tǒng)控制。這一系統(tǒng)的運作需要大量的時間和精力，因為總是存在操作系統(tǒng)更新、硬件問題以及與TensorFlow無關(guān)的可能導(dǎo)致測試失敗的其他問題。我們有一個工程師團隊致力于整個測試過程。這個團隊使我們的工作免遭潛在問題的，所以對這個團隊的投資是值得的。 我們在Google從事開源工作并不孤單，我們也從其他諸如Kubernetes和Open Source Program Office項目（他們也有一套很好的文檔）中學(xué)到了很多。我們有一個非常努力的開發(fā)人員關(guān)系專家團隊來協(xié)助我們，他們處理了大量繁重的文檔、代碼示例以及開發(fā)人員體驗的其他重要部分。我們的長期目標(biāo)是將關(guān)鍵專業(yè)知識轉(zhuǎn)移到核心開發(fā)人員之外，以便更多的Google員工和Google外部人員可以幫助到社區(qū)。 讓核心工程師兼職參與客戶服務(wù)的一大好處就是讓我們直接了解用戶所遇到的問題。參與客戶服務(wù)也促使我們可以改進常見的程序缺陷并添加文檔，所以我們可以直觀地看到這些工作所帶來的客戶支持工作量的減少。 在不久的將來，我們希望隨著更多的人熟悉Tensorflow框架的內(nèi)部細節(jié)、文檔質(zhì)量的不斷提高以及我們?yōu)樘幚沓Ｒ娙蝿?wù)（如程序缺陷分類）創(chuàng)建更多的“指南”，我們的工作量能更多地被分配出去。至此我很幸運有機會能與這么多的外部開發(fā)人員進行互動，希望對其中的一些人產(chǎn)生積極的影響，幫助其創(chuàng)造激動的基于機器學(xué)習(xí)的新應(yīng)用程序。
Pete Warden是TensorFlow Mobile團隊的技術(shù)主管。他之前是Jetpac的首席技術(shù)官。Jetpac于2014年被Google收購，以優(yōu)化Google在移動和嵌入式設(shè)備上的深入學(xué)習(xí)技術(shù)。他以前曾在蘋果從事用于圖像處理的GPU的優(yōu)化工作，并為OReilly撰寫了幾本關(guān)于數(shù)據(jù)處理的書籍。返回搜狐，查看更多 推薦：
|
