TiDB 開源社群指南（上）
作者：申礫
本系列文章旨在幫助社群開發者瞭解 TiDB 專案的全貌，更好的參與 TiDB 專案開發。大致會分兩個角度進行描述：
-
從社群參與者的角度描述如何更好的參與 TiDB 專案開發；
-
從 PingCAP 內部團隊的角度展示 TiDB 的開發流程，包括版本規劃、開發流程、Roadmap 制定等。
希望通過一內一外兩條線的描述，讀者能在技術之外對 TiDB 有更全面的瞭解。本篇將聚焦在社群參與者的角度進行描述，也就是“外線”。
瞭解 TiDB
參與一個開源專案第一步總是瞭解它，特別是對 TiDB 這樣一個大型的專案，瞭解的難度比較高，這裡列出一些相關資料，幫助 newcomers 從架構設計到工程實現細節都能有所瞭解：
當然，最高效地熟悉 TiDB 的方式還是使用它，在某些場景下遇到了問題或者是想要新的 feature，去跟蹤程式碼，找到相關的程式碼邏輯，在這個過程中很容易對相關模組有了解，不少 Contributor 就是這樣完成了第一次貢獻。
我們還有一系列的 Infra Meetup，大約兩週一次，如果方便到現場的同學可以聽到這些高質量的 Talk。除了北京之外，其他的城市（上海、廣州、成都、杭州）也開始組織 Meetup，方便更多的同學到現場來面基。
發現可以參與的事情
對 TiDB 有基本的瞭解之後，就可以選一個入手點。在 TiDB repo 中我們給一些簡單的 issue 標記了 for-new-contributors
當然除了那些標記為 for-new-contributors 的 issue 之外，也可以考慮其他的 issue，標記為 help-wanted 標籤的 issue 可以優先考慮。除此之外的 issue 可能會比較難解決，需要對 TiDB 有較深入的瞭解或者是對完成時間有較高的要求，不適合第一次參與的同學。
當然除了現有的 issue 之外，也歡迎將自己發現的問題或者是想要的特性提為新的 issue，然後自投自搶 ? 。
當你已經對 TiDB 有了深入的瞭解，那麼可以嘗試從 Roadmap 上找到感興趣的事項，和我們討論一下如何參與。
討論方案
找到一個感興趣的點之後，可以在 issue 中進行討論，如果是一個小的 bug-fix 或者是小的功能點，可以簡單討論之後開工。即使再簡單的問題，也建議先進行討論，以免出現解決方案有問題或者是對問題的理解出了偏差，做了無用功。
但是如果要做的事情比較大，可以先寫一個詳細的設計文件，提交到 docs/design 目錄下面，這個目錄下有設計模板以及一些已有的設計方案供你參考。一篇好的設計方案要寫清楚以下幾點：
-
背景知識
-
解決什麼問題
-
方案詳細設計
-
對方案的解釋說明，證明正確性和可行性
-
和現有系統的相容性
-
方案的具體實現
用一句話來總結就是寫清楚“你做了什麼，為什麼要做這個，怎麼做的，為什麼要這樣做”。如果對自己的方案不太確定，可以先寫一個 Google Doc，share 給我們簡單評估一下，再提交 PR。
提交 PR
按照方案完成程式碼編寫後，就可以提交 PR。當然如果開發尚未完成，在某些情況下也可以先提交 PR，比如希望先讓社群看一下大致的解決方案，這個時候請將 PR 標記為 WIP。
對於 PR 我們有一些要求：
-
需要能通過
make dev的測試，跑過基本的單元測試； -
必須有測試，除非只是改動文件或者是依賴包，其他情況需要有充足的理由說明沒有測試的原因；
-
程式碼以及註釋的質量需要足夠高，這裡 有一些關於編碼風格和 commit message 的 guide；
-
請儘可能詳細的填寫 PR 的描述，並打上合適的 label。
對於 PR 的描述，我們提供了一個模板，希望大家能夠認真填寫，一個好的描述能夠加速 PR 的 review 過程。通過這個模板能夠向 reviewers 以及社群講明白：
-
這個PR 解決什麼問題：相關的問題描述或者是 issue 連結；
-
如何解決：具體的解決方法，reviewers 會根據這裡的描述去看程式碼變動，所以請將這一段寫的儘可能詳細且有幫助；
-
測試的情況；
-
其他相關資訊（如果需要）：benchmark 結果、相容性問題、是否需要更新文件。
最後再說幾句測試，正確性是資料庫安身立命之本，怎麼強調測試都不為過。PR 中的測試不但需要充足，覆蓋到所做的變動，還需要足夠清晰，通過程式碼或者註釋來表達測試的目的，幫助 reviewer 以及今後可能變動/破壞相關邏輯的人能夠容易的理解這段測試。一段完善且清晰的測試也有利於讓 reviewer 相信這個 Patch 是正確的。
PR review
PR review 的過程就是 reviewer 不斷地提出 comment，PR 作者持續解決 comment 的過程。
每個 PR 在合併之前都需要至少得到兩個 Committer/Maintainer 的 LGTM，一些重要的 PR 需要得到三個，比如對於 DDL 模組的修改，預設都需要得到三個 LGTM。
Tips：
-
提了PR 之後，可以 at 一下相關的同學來 review；
-
Address comment 之後可以 at 一下之前提過 comment 的同學，標準做法是 comment 一下 “PTAL @xxx”，這樣我們內部的 Slack 中可以得到通知，相關的同學會受到提醒，讓整個流程更緊湊高效。
與專案維護者之間的交流
目前標準的交流渠道是 GitHub issue，請大家優先使用這個渠道，我們有專門的同學來維護這個渠道，其他渠道不能保證得到研發同學的及時回覆。這也是開源專案的標準做法。
無論是遇到 bug、討論具體某一功能如何做、提一些建議、產品使用中的疑惑，都可以來提 issue。在開發過程中遇到了問題，也可以在相關的 issue 中進行討論，包括方案的設計、具體實現過程中遇到的問題等等。
最後請大家注意一點，除了 pingcap/docs-cn 這個 repo 之外，請大家使用英文。
更進一步
當你完成上面這些步驟的之後，恭喜你已經跨過第一個門檻，正式進入了 TiDB 開源社群，開始參與 TiDB 專案開發，成為 TiDB Contributor。
如果想更進一步，深入瞭解 TiDB 的內部機制，掌握一個分散式資料庫的核心模組，並能做出改進，那麼可以瞭解更多的模組，提更多的 PR，進一步向 Committer 發展（這裡 解釋了什麼是 Committer）。目前 TiDB 社群的 Committer 還非常少，我們希望今後能出現更多的 Committer 甚至是 Maintainer。
從 Contributor 到 Committer 的門檻比較高，比如今年的新晉 Committer 杜川同學，在成為 Committer 的道路上給 tidb/tikv 專案提交了大約 80 個 PR，並且對一些模組有非常深入的瞭解。當然，成為 Committer 之後，會有一定的權利，比如對一些 PR 點 LGTM 的權利，參加 PingCAP 內部的技術事項、開發規劃討論的權利，參加定期舉辦的 TechDay/DevCon 的權利。目前社群中還有幾位貢獻者正走在從 Contributor 到 Committer 的道路上。
