如何從零開始參與大型開源項目

寫在前面的話

n

上世紀 70 年代,IBM n發明了關係型資料庫。但是隨著現在移動互聯網的發展,接入設備越來越多,數據量越來越大,業務越來越複雜,傳統的資料庫顯然已經不能滿足海量數據存儲的需求。雖然目前市場上也不乏分散式資料庫模型,但沒有品位的文藝青年不是好工程師,我們覺得,不,這些方案都不是我們想要的,它們不夠美,鮮少能夠把分散式事務與彈性擴展做到完美。

n

受 Google Spanner/F1 的啟發,一款從一開始就選擇了開源道路的 TiDB 誕生了。 它是一款代表未來的新型分散式 nNewSQL n資料庫,它可以隨著數據增長而無縫水平擴展,只需要通過增加更多的機器來滿足業務增長需求,應用層可以不用關心存儲的容量和吞吐,用東旭的話說就是「他自己會生長」。

n

在開源的世界裡,TiDB 和 TiKV 吸引了更多的具有極客氣質的開發者,目前已經擁有超過 9000 個 star 和 100 個 contributor,這已然是一個世界頂級開源項目的水準。而成就了這一切的,則是來自社區的力量。

n

最近我們收到了很多封這樣的郵件和留言,大家說:

n

  • 謝謝你們,使得旁人也能接觸大型開源項目。本身自己是DBA,對資料庫方面較干興趣,也希望自己能逐步深入資料庫領域,深入 TiDB,為 TiDB 社區貢獻更多、更有價值的力量。

    n

  • 我是一個在校學生,剛剛收到郵件說我成為了 TiDB 的 Contributor,這讓我覺得當初沒聽父母的話堅持了自己喜歡的計算機技術,是個正確的選擇,但我還需要更多的歷練,直到能完整地展現、表達我的思維。

    n

這讓我感觸頗多,因為,應該是我們感謝你們才是啊,沒有社區,一個開源項目就成不了一股清泉甚至一汪海洋。

n公司的小姑娘說,她覺得還有很多的人想要參與進來的,可工程師團隊欠缺平易近人的表達,這個得改。

n

於是便有了這篇文章以及未來的多篇文章和活動,我們歡迎所有的具有氣質的開發者能和 TiDB 一起成長,一起見證資料庫領域的革新,改變世界這事兒有時候也不那麼難。

n

我要重點感謝今天這篇文章的作者,來自社區的朱武(GitHub ID:viile )、小盧(GitHub ID:lwhhhh n)和楊文(GitHub ID: yangwenmai),當在 TiDB Contributor Club n里提到想要做這件事的時候,是他們踴躍地加入了 TiDB Tech Writer 的隊伍,高效又專業地完成了下文的編輯,謝謝你們。

n

一個典型的開源項目是由什麼組成的

n

The Community(社區)

n

  • 一個項目經常會有一個圍繞著它的社區,這個社區由各個承擔不同角色的用戶組成。

    n
  • 項目的擁有者:在他們賬號中創建項目並擁有它的用戶或者組織。

    n
  • 維護者和合作者:主要做項目相關的工作和推動項目發展,通常情況下擁有者和維護者是同一個人,他們擁有倉庫的寫入許可權。

    n
  • 貢獻者:發起拉取請求 (pull request) 並且被合併到項目裡面的人。

    n
  • 社區成員:對項目非常關心,並且在關於項目的特性以及 pull requests 的討論中非常活躍的人。

    n

The Docs(文檔)

n

項目中經常出現的文件有:

n

  • Readme:幾乎所有的 Github 項目都包含一個 README.md 文件,readme 文件提供了一些項目的詳細信息,包括如何使用,如何構建。有時候也會告訴你如何成為貢獻者。
  • TiDB Readme pingcap/tidb

    n
  • Contributing:項目以及項目的維護者各式各樣,所以參與貢獻的最佳方式也不盡相同。如果你想成為貢獻者的話,那麼你要先閱讀那些有 CONTRIBUTING 標籤的文檔。Contributing 文檔會詳細介紹了項目的維護者希望得到哪些補丁或者是新增的特性。

    n 文件里也可以包含需要寫哪些測試,代碼風格,或者是哪些地方需要增加補丁之類的內容。

    n
  • TiDB Contributing 文檔 pingcap/tidb

    n
  • License:LICENSE 文件就是這個開源項目的許可證。一個開源項目會告知用戶他們可以做什麼,不可做什麼(比如:使用,修改,重新分發),以及貢獻者允許其他人做哪些事。開源許可證有多種,你可以在認識各種開源協議及其關係了解更多關於開源許可證的信息。

    n
  • TiDB 遵循 Apache-2.0 Lincense

    pingcap/tidb
  • TiKV 遵循 Apache-2.0 Lincense pingcap/tikv

    n
  • Documentation:許多大型項目不會只通過自述文件去引導用戶如何使用。在這些項目中你經常可以找到通往其他文件的超鏈接,或者是在倉庫中找到一個叫做 docs 的文件夾.

    n
  • TiDB Docs pingcap/tidb

    nn

齊步走成為 Contributor

n

Create an Issue

n

如果你在使用項目中發現了一個 bug,而且你不知道怎麼解決這個 bug。或者使用文檔時遇到了麻煩。或者有關於這個項目的問題。你可以創建一個 issue。

n不管你有什麼 bug,你提出 bug 後,會對那些和你有同樣 bug 的人提供幫助。

n更多關於 issue 如何工作的信息,請點擊 Issues guide。

n

Issues Pro Tips

n

  • 檢查你的問題是否已經存在 重複的問題會浪費大家的時間,所以請先搜索打開和已經關閉的問題,來確認你的問題是否已經提交過了。
  • 清楚描述你的問題

TiDB Issue 模版如下

nn

TiKV Issue 模版如下

  • 給出你的代碼鏈接 使用像 JSFiddle 或者 CodePen 等工具,貼出你的代碼,好幫助別人復現你的問題
  • 詳細的系統環境介紹 例如使用什麼版本的瀏覽器,什麼版本的庫,什麼版本的操作系統等其他你運行環境的介紹。

    ngo 版本: go version

    nLinux 版本: uname -a

    n
  • 詳細的錯誤輸出或者日誌 使用 Gist 貼出你的錯誤日誌。如果你在 issue 中附帶錯誤日誌,請使用```來標記你的日誌。以便更好的顯示。

    n

Pull Request

n

如果你能解決這個 bug,或者你能夠添加其他的功能。並且知道如何成為貢獻者,理解 license,已經簽過 Contributor Licence Agreement (CLA) 後,請發起 Pull Request。這樣維護人員可以將你的分支與現有分支進行比較,來決定是否合併你的更改。

n

Pull Request Pro Tips

n

  • Fork 代碼並且 clone 到你本地 通過將項目的地址添加為一個 remote,並且經常從 remote 合併更改來保持你的代碼最新,以便在提交你的 pull 請求時,儘可能少的發生衝突。詳情請參閱這裡
  • 創建 branch 來修改你的代碼,目前 TiDB 相關的項目默認的 branch 命名規則是 user/name。例如 disksing/grpc,簡單明確,一目了然。
  • 描述清楚你的問題 方便其他人能夠復現。或者說明你添加的功能有什麼作用,並且清楚描述你做了哪些更改。
  • 注意測試 如果項目中包含邏輯修改,那麼必須包含相應的測試,在 CI 中會包含測試覆蓋率的檢測,如果測試覆蓋率下降,那麼是不可以合併到 master 的。
  • 包含截圖 如果您的更改包含 HTML/CSS 中的差異,請添加前後的屏幕截圖。將圖像拖放到您的 pull request 的正文中。
  • 保持良好的代碼風格這意味著使用與你自己的代碼風格中不同的縮進,分號或注釋,但是使維護者更容易合併,其他人將來更容易理解和維護。目前 TiDB 項目的 CI 檢測包含代碼風格的檢查,如果代碼風格不符合要求,那麼是不可以合併到 master 的。

Open Pull Requests

n

一旦你新增一個 pull nrequest,討論將圍繞你的更改開始。其他貢獻者和用戶可能會進入討論,但最終決定是由維護者決定的。你可能會被要求對你的 pull nrequest 進行一些更改,如果是這樣,請向你的 branch 添加更多代碼並推送它們,它們將自動進入現有的 pull request。

n如果你的 pull request 被合併,這會非常棒。如果沒有被合併,不要灰心。也許你的更改不是項目維護者需要的。或者更改已經存在了。發生這種情況時,我們建議你根據收到的任何反饋來修改代碼,並再次提出 pull request。或創建自己的開源項目。

n

TiDB 合併流程

n

PR 提交之後,請耐心等待維護者進行 Review。

n目前一般在一到兩個工作日內都會進行 Review,如果當前的 PR 堆積數量較多可能回復會比較慢。

n代碼提交後 CI 會執行我們內部的測試,你需要保證所有的單元測試是可以通過的。期間可能有其它的提交會與當前 PR 衝突,這時需要修復衝突。

n維護者在 Review 過程中可能會提出一些修改意見。修改完成之後如果 reviewer 認為沒問題了,你會收到 LGTM(looks good to me) 的回復。當收到兩個及以上的 LGTM 後,該 PR 將會被合併。

n

標註:本文「一個典型的開源項目是由什麼組成的」及「起步走成為 Contributor」參考自英文 GitHub nGuide,由社區成員朱武(GitHub ID: viile)、小盧(GitHub nID:lwhhhh)著手翻譯並替換部分原文中的截圖。GitHub Guides:如何參與一個 GitHub 開源項目英文原文地址: guides.github.com/activ

n

加入 TiDB Contributor Club

n

為更好地促進 Contributor 間的交流,便於隨時提出好的想法和反饋,我們創建了一個 Contributor Club n微信群,對成為 TiDB Contributor 有興趣的同學可以添加 TiDB Robot n微信號,它會在後台和你打招呼,並積極招募你成為開源社區的一員。

nn

歡迎加入 TiDB Tech Writer 計劃,讓我們一起用文字的力量推動開源項目的發展。


推薦閱讀:

十七年的潤乾,壯士斷腕的變革,報表到計算的轉身
為什麼我們需要區塊鏈
Revit數據導出到資料庫
矽谷之路29:如何設計用戶系統(三)

TAG:开源项目 | 数据库 |