摘要：更進一步當你完成上面這些步驟的之后，恭喜你已經跨過第一個門檻，正式進入了開源社區(qū)，開始參與項目開發(fā)，成為。目前社區(qū)的還非常少，我們希望今后能出現(xiàn)更多的甚至是。目前社區(qū)中還有幾位貢獻者正走在從到的道路上。

作者：申礫

本系列文章旨在幫助社區(qū)開發(fā)者了解 TiDB 項目的全貌，更好的參與 TiDB 項目開發(fā)。大致會分兩個角度進行描述：

從社區(qū)參與者的角度描述如何更好的參與 TiDB 項目開發(fā)；

從 PingCAP 內部團隊的角度展示 TiDB 的開發(fā)流程，包括版本規(guī)劃、開發(fā)流程、Roadmap 制定等。

希望通過一內一外兩條線的描述，讀者能在技術之外對 TiDB 有更全面的了解。本篇將聚焦在社區(qū)參與者的角度進行描述，也就是“外線”。

參與一個開源項目第一步總是了解它，特別是對 TiDB 這樣一個大型的項目，了解的難度比較高，這里列出一些相關資料，幫助 newcomers 從架構設計到工程實現(xiàn)細節(jié)都能有所了解：

Overview

How we build TiDB

TiDB 源碼閱讀系列文章

Deep Dive TiKV (Work-In-Process)

當然，最高效地熟悉 TiDB 的方式還是使用它，在某些場景下遇到了問題或者是想要新的 feature，去跟蹤代碼，找到相關的代碼邏輯，在這個過程中很容易對相關模塊有了解，不少 Contributor 就是這樣完成了第一次貢獻。?

我們還有一系列的 Infra Meetup，大約兩周一次，如果方便到現(xiàn)場的同學可以聽到這些高質量的 Talk。除了北京之外，其他的城市（上海、廣州、成都、杭州）也開始組織 Meetup，方便更多的同學到現(xiàn)場來面基。

對 TiDB 有基本的了解之后，就可以選一個入手點。在 TiDB repo 中我們給一些簡單的 issue 標記了 for-new-contributors?標簽，這些 issue 都是我們評估過容易上手的事情，可以以此為切入點。另外我們也會定期舉行一些活動，把框架搭好，教程寫好，新 Contributor 按照固定的模式即可完成某一特性開發(fā)。

當然除了那些標記為 for-new-contributors 的 issue 之外，也可以考慮其他的 issue，標記為?help-wanted?標簽的 issue 可以優(yōu)先考慮。除此之外的 issue 可能會比較難解決，需要對 TiDB 有較深入的了解或者是對完成時間有較高的要求，不適合第一次參與的同學。

當然除了現(xiàn)有的 issue 之外，也歡迎將自己發(fā)現(xiàn)的問題或者是想要的特性提為新的 issue，然后自投自搶 :) 。?

當你已經對 TiDB 有了深入的了解，那么可以嘗試從?Roadmap?上找到感興趣的事項，和我們討論一下如何參與。

找到一個感興趣的點之后，可以在 issue 中進行討論，如果是一個小的 bug-fix 或者是小的功能點，可以簡單討論之后開工。即使再簡單的問題，也建議先進行討論，以免出現(xiàn)解決方案有問題或者是對問題的理解出了偏差，做了無用功。

但是如果要做的事情比較大，可以先寫一個詳細的設計文檔，提交到?docs/design?目錄下面，這個目錄下有設計模板以及一些已有的設計方案供你參考。一篇好的設計方案要寫清楚以下幾點：

背景知識

解決什么問題

方案詳細設計

對方案的解釋說明，證明正確性和可行性

和現(xiàn)有系統(tǒng)的兼容性

方案的具體實現(xiàn)?

用一句話來總結就是寫清楚“你做了什么，為什么要做這個，怎么做的，為什么要這樣做”。如果對自己的方案不太確定，可以先寫一個 Google Doc，share 給我們簡單評估一下，再提交 PR。

按照方案完成代碼編寫后，就可以提交 PR。當然如果開發(fā)尚未完成，在某些情況下也可以先提交 PR，比如希望先讓社區(qū)看一下大致的解決方案，這個時候請將 PR 標記為 WIP。

對于 PR 我們有一些要求：

需要能通過 make dev 的測試，跑過基本的單元測試；

必須有測試，除非只是改動文檔或者是依賴包，其他情況需要有充足的理由說明沒有測試的原因；

代碼以及注釋的質量需要足夠高，這里 有一些關于編碼風格和 commit message 的 guide；

請盡可能詳細的填寫 PR 的描述，并打上合適的 label。

對于 PR 的描述，我們提供了一個模板，希望大家能夠認真填寫，一個好的描述能夠加速 PR 的 review 過程。通過這個模板能夠向 reviewers 以及社區(qū)講明白：

這個PR 解決什么問題：相關的問題描述或者是 issue 鏈接；

如何解決：具體的解決方法，reviewers 會根據(jù)這里的描述去看代碼變動，所以請將這一段寫的盡可能詳細且有幫助；

測試的情況；

其他相關信息（如果需要）：benchmark 結果、兼容性問題、是否需要更新文檔。

最后再說幾句測試，正確性是數(shù)據(jù)庫安身立命之本，怎么強調測試都不為過。PR 中的測試不但需要充足，覆蓋到所做的變動，還需要足夠清晰，通過代碼或者注釋來表達測試的目的，幫助 reviewer 以及今后可能變動/破壞相關邏輯的人能夠容易的理解這段測試。一段完善且清晰的測試也有利于讓 reviewer 相信這個 Patch 是正確的。

PR review 的過程就是 reviewer 不斷地提出 comment，PR 作者持續(xù)解決 comment 的過程。

每個 PR 在合并之前都需要至少得到兩個 Committer/Maintainer 的 LGTM，一些重要的 PR 需要得到三個，比如對于 DDL 模塊的修改，默認都需要得到三個 LGTM。

提了PR 之后，可以 at 一下相關的同學來 review；

Address comment 之后可以 at 一下之前提過 comment 的同學，標準做法是 comment 一下 “PTAL @xxx”，這樣我們內部的 Slack 中可以得到通知，相關的同學會受到提醒，讓整個流程更緊湊高效。

目前標準的交流渠道是 GitHub issue，請大家優(yōu)先使用這個渠道，我們有專門的同學來維護這個渠道，其他渠道不能保證得到研發(fā)同學的及時回復。這也是開源項目的標準做法。

無論是遇到 bug、討論具體某一功能如何做、提一些建議、產品使用中的疑惑，都可以來提 issue。在開發(fā)過程中遇到了問題，也可以在相關的 issue 中進行討論，包括方案的設計、具體實現(xiàn)過程中遇到的問題等等。

最后請大家注意一點，除了 pingcap/docs-cn 這個 repo 之外，請大家使用英文。

當你完成上面這些步驟的之后，恭喜你已經跨過第一個門檻，正式進入了 TiDB 開源社區(qū)，開始參與 TiDB 項目開發(fā)，成為?TiDB Contributor。

如果想更進一步，深入了解 TiDB 的內部機制，掌握一個分布式數(shù)據(jù)庫的核心模塊，并能做出改進，那么可以了解更多的模塊，提更多的 PR，進一步向?Committer 發(fā)展（這里?解釋了什么是 Committer）。目前 TiDB 社區(qū)的 Committer 還非常少，我們希望今后能出現(xiàn)更多的 Committer 甚至是 Maintainer。

從 Contributor 到 Committer 的門檻比較高，比如今年的新晉 Committer 杜川同學，在成為 Committer 的道路上給 tidb/tikv 項目提交了大約 80 個 PR，并且對一些模塊有非常深入的了解。當然，成為 Committer 之后，會有一定的權利，比如對一些 PR 點 LGTM 的權利，參加 PingCAP 內部的技術事項、開發(fā)規(guī)劃討論的權利，參加定期舉辦的 TechDay/DevCon 的權利。目前社區(qū)中還有幾位貢獻者正走在從 Contributor 到 Committer 的道路上。