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