TensorFlow 技術主管在這篇文章中和我們分享了他們團隊管理開源專案的經驗。
開源不僅僅是把程式碼貢獻出來，然後希望有人來使用它。我也知道這一點，不過在成為 Google TensorFlow 團隊的成員後，我才認識到圍繞一個軟體構建一個社群所需要考慮的因素實在是很多。
社群服務
當一個新專案釋出出來時，該專案唯一的專家就是編寫這個專案的人。他們是唯一可以撰寫文件和回答問題的人，而且他們可以最有效地改進軟體。因此，我們這些 TensorFlow 團隊中的核心成員也成為了專案擴大的瓶頸：畢竟我們無法馬上完成任何事情。我們知道如何編寫程式碼和文件，因為這些任務是我們日常工作的一部分。但另一方面，回答大量來自社群開發者的問題不是我們應該做的事，儘管我們也知道這對於專案的成功至關重要。
為了保證使用者可以獲得所需要的答案，核心工程師團隊的所有人都加入了輪流回答問題。團隊成員可以選擇解決 Stack Overflow 上帶有 #tensorflow 標記的問題、在 GitHub 上審查 pull requests，分類 GitHub issues，處理同步外部和內部程式碼或追查測試失敗的原因。
通常，每個工程師每次對一個特定領域負責一個星期，以迴圈的方式輪流負責。因此，輪值的工程師在本週正常工作中的生產力會低很多，不過至少每個人工作被打斷的頻率降到了幾個月一次。
Pull requests
我們開源 TensorFlow 部分的目的是希望通過社群的貢獻來改進它。到目前為止，我們已經擁有超過 400 個外部貢獻者新增了程式碼，從小的文件修復到大型的新增，如支援 OS X GPU、OpenCL 的實現或 InfiniBand RDMA。首先，輪值的核心工程師必須對每項貢獻都進行審查，以確定是否有價值。如果貢獻通過初始審查，會觸發一組 Jenkins 測試，以確保其不會導致任何故障。如果這些行為也通過審查後，值班的工程師可能會希望其他對這個領域更瞭解的工程師來看一看，所以這將會被轉交給該專家進行審查。
GitHub 全新的詳細的程式碼審查工具在這個過程中提供了很大的幫助；沒有它們之前，處理所有的個人意見是一件痛苦的事情。通常，大的 PRs 會在工作中保持一段時間，核心工程師會和一個或多個外部貢獻者協同工作，在大家都滿意後，PR 將會在 GitHub 中被合併，然後在下次執行同步時合併到我們的內部程式碼庫中。
程式碼許可協議
作為我們自動的 pull request 的一部分，我們會將貢獻者的 GitHub 賬號與我們在 cla.developers.google.com 上的記錄相匹配，以確保任何的外部貢獻者都擁有程式碼許可協議（CLA）。我們的目標是確保整個程式碼庫可在 Apache 2.0 協議下準確無誤地分發。當 pull request 的輪值工程師要對出現的所有問題進行整理時，如果一個 pull request 內部關聯了不同的郵箱，或是貢獻者需要以公司的身份登入，情況可能會變得複雜。
GitHub issues
目前已經有超過 5000 個 issues 提交到 TensorFlow，對於有些人來說，這看起來似乎有點讓人沮喪。但這是我最喜歡的指標 —— 它說明了使用者有在真正使用這個專案！為了確保能對每個提交的 issue 都進行回應，值班的工程師會時刻關注新出現的資訊，並嘗試使用標籤對它們進行分類。如果是一個我們內部不太可能在短期時間內實現的特性，我們會將其標記為“Contributions Welcome（歡迎貢獻）”，對於 bug，我們會嘗試優先考慮。這段時間以來，隨著外部使用者自己也成了某些領域的專家，我們看到越來越多的問題無需我們的幫助也能夠被解決了。特別是在像 Windows 這些我們不是每天都使用的平臺上。
如果某個 issue 通過社群沒能找到答案或者解決方案，而且它的優先順序也比較高，值班工程師會將其分配給對這個領域更瞭解的工程師。整個 TensorFlow 團隊都有 GitHub 賬號，所以我們可以使用常規的 GitHUb issue 跟蹤器來分配問題。我們考慮過把使用者提交的 bug 複製到我們的內部系統，但為相同的資訊同步兩份副本的代價實在是太高了。因此，我們的工程師除了要關注內部的跟蹤器之外，還需要開啟 GitHub 上有人提交了 bug 的郵件通知，以便及時看到屬於自己的分配。
Stack Overflow
Derek Murray 是 Stack Overflow 值班小組的負責人。我十分敬畏他回答問題的能力，根據他的個人資料頁，他發表過的帖子已經被超過 130 萬人瀏覽。他還設法建了一個由 RSS 源驅動的自動化電子表格。開始的時候，我們每週輪流負責，但後來需要處理的問題的數量變得十分龐大，一個人難以處理。所以後來在輪流的基礎上，我們採用了自動分配問題的方式來代替之前的做法。
目前我在這個小組裡，因此每天早上瀏覽完自己的的郵件後，我會通過檢視電子表格來看一下自己被分配到了什麼問題。很遺憾，我們做不到自己回答所有的問題，但我們會審查每一個進來的問題。如果問題相對比較簡單，我們會自己回答。
值班的工程師是一個“前線”的角色，但有時候回答問題需要更多的時間或專業知識。如果問題看上能被解答，但社群裡卻沒人回答，我們就會研究一下程式碼（通常使用‘git blame’）來看一下團隊裡有誰可能會對這個問題有一些想法。然後值班工程師會傳送一封電子郵件，詢問我們找到的內部專家是否可以提供幫助。
郵件列表
我們設定了一個郵件列表，起初我們不太清楚該用它做什麼。但很顯然，用它來跟蹤問題或回答一般的問題是十分糟糕的方式。
後來，我們把它當做討論區來使用。但在實際使用中我們發現，即使對於架構問題，GitHub issue 也比它更適合。
因此現在我們使用郵件列表來傳送資訊和分享通知，這還是值得訂閱的。
程式碼同步
很多和我聊過天的人都會對這樣一件事感到驚訝：我們在谷歌內部使用的程式碼庫和我們在 GitHub 上提供的幾乎完全相同。然而它們之間還是有一些區別的：例如，對谷歌專用的基礎設施的支援是分開的，路徑也不一樣。但同步過程是完全機械化的。我們至少每週推送一次內部變更，並且也會經常從 GitHub 上拉取。
棘手的問題是我們要進行雙向同步。在 GitHub 公共專案和我們的內部版本中，有很多更改是同時發生的，我們需要反覆把它們全部進行合併。由於沒有現成的基礎設施可供使用，我們建立了一系列的 Python 指令碼來處理這些問題。指令碼可將 GitHub 上的改動拉取到我們內部的資源儲存庫，並轉換所有的頭部路徑（header paths）和其他小的更改，將它們與最新的內部程式碼合併並建立一個內部副本。然後我們就可以進行另一方向的同步，我們會將所有內部程式碼裝換成外部格式，並使用相同的指令碼將結果合併到最新的 GitHub 上。
對於內部的更改，我們也會盡力確保每次check-in 都會以單個的 git commit 呈現，並把作者的 GitHub 賬戶和對這些更改的註釋也包括在內。我們在 GitHub 上有一個特別的“tensorflow-gardener”賬號用於管理這個流程，點此檢視一個內部的 commit 遷移到 GitHub 會變成怎樣。
確保在程式碼更改的情況下，轉換流程依然有效是十分具有挑戰性的。為了驗證有效性，每個內部改動通過指令碼轉換成外部版本後仍可執行，而且與初始的內部版本沒有任何差別。在任何涉及到 TensorFlow 程式碼庫的每個內部更改上，都需要執行這個測試，不能通過測試的修改將被拒絕。對於那些傳送 pull request 的人，我們有時候會要求他們進行奇怪的更改。通常，這樣做的原因是我們必須確保他們的程式碼能與這個同步基礎設施正常執行。
測試
因為我們需要支援很多平臺，所以我們希望擁有一個適用範圍廣的測試基礎設施。TensorFlow 在 Linux, Windows, OS X 桌面, 和 iOS, Android, Android Things, 以及 Raspberry Pi 上執行。同時我們還有為 GPU 提供不同的程式碼路徑，包括 CUDA 和 OpenCL 支援，以及 Bazel, cmake, 和 plain makefile 構建過程。
讓每個開發者在更改後把上面這些東西手動測試一遍是不可能的，因此我們有一套能在大多數受支援的平臺上執行的自動化測試系統，所有這些都由 Jenkins 自動化系統控制著。保持這樣的工作需要大量的時間和精力，因為總是會存在作業系統更新、硬體問題以及其他一些與 TensorFlow 無關的問題導致測試失敗。我們有一個工程師團隊，專門負責保證整個測試系統正常執行，這個團隊曾多次幫助我們，讓我們倖免於難，所以這個投資是值得的。
開發者關係
在谷歌，我們在開源領域工作不孤單。我們從像 Kubernetes 和 開源計劃辦公室”（Open Source Program Office）這樣的專案中學到過很多東西。我們還有一支非常努力的開發者關係專家團隊來協助我們，他們還處理了很多圍繞文件、程式碼示例以及其他一些開發者經驗問題而產生的體力活。我們的長期目標是將關鍵的專業知識傳遞到核心開發者之外，以便更多 Google 內部和外部的人員能對社群做出貢獻。
讓核心工程師“兼職”承擔客戶服務工作的一大好處是可以直接瞭解使用者所遇到的問題。參與客戶服務也驅動著我們去改進常見的錯誤並增加文件，因為它在減少工作量方面讓我們看到了直接的回報。
展望未來，我們希望可以將這項工作更廣泛地進行下去，也希望更多人可以熟悉框架的細節、文件的改進，我們建立了更多的“指導手冊”以幫助人們處理常見任務（如錯誤分類）。在此之前，我為有機會和如此多的外部開發者進行互動而感到幸運，也希望通過幫助他們使用機器學習創造新的令人驚歎的應用，從而產生積極的影響。
關於作者：
Pete Warden 是 TensorFlow Mobile 團隊的技術主管，之前是 Jetpac 的技術長，該公司於 2014 年被 Google 收購，主要工作是優化其在移動和嵌入式裝置上的深度學習技術。他曾在蘋果公司工作，負責影像處理的 GPU 優化，併為 O’Reilly 撰寫過關於資料處理的書籍。