幸好，這些issues上面都標記有難度Label。上圖中的issues標記的是D: Easy，這是專門給新手準備的。D: Easy標記的意義：

• 有人指導
• 上下文依賴最少
• 任務量不太多
• 懂Rust即可參與

所以，不管你Rust水平高低，選擇這個應該是最好的。因為TiKV屬於一個比較大型的項目了，業務邏輯相當複雜，對於新人來說，最好是選擇依賴業務上下文最少的那些issues來解決。

Fork項目提交PR

選擇好issues之後，接下來不要馬上動手。你首先需要搞清楚問題所在，想清楚如何解決，再動手。但是你可以先fork一個自己的分支。對issues有任何問題，可以通過GitHub提問，每個issues應該有一個主要的負責人，他會指導你。

在修改代碼的時候需要注意，TiKV默認是使用Nightly Rust，在項目的根目錄下有一個`rust-toolchain`文件，裡面指定了相關的版本。在你使用cargo build的時候，如果你本地沒有這個版本的Rust，則會自動安裝。

找到解決問題的思路，順利寫完代碼之後，先別著急Commit代碼。需要注意下面三點：

• 執行cargo fmt，把代碼風格統一標準。
• 執行cargo test，跑一遍單元測試看是否有問題。這裡有一個坑需要注意：單元測試是並行跑的，最好把你本地機器ulimit設置一下，ulimit -n 1000。否則測試跑一半可能會報too many files的錯誤。
• 使用git commit -s命令來Commit代碼，因為TiKV要求遵循DCO（Developer Certification of Origin）。有人因為這個原因修改commit信息就浪費了不少時間。

然後順利Push代碼之後，發起Pull Request要注意，寫清楚這次PR的詳細信息，這些TiKV的模板有描述，注意查看。

等待Review

提交PR以後，就安心等待Review吧。並不是你剛提交就會馬上有人來幫你review，所以不要心急。

Review也是分批次，主要負責人過來review之後，給出一些修改意見，然後也可能會有業務相關的人員過來再次Review，給出其他意見。但這裡面需要注意：

• 只關注這個PR要解決的核心問題
• 對於一些次要的review請求，可以拒絕

TiKV代碼太多，並不是每個review人員都看過完整代碼，他們也許只是對他負責的那一塊熟悉。當他幫同事負責的那一塊review的時候，他並不能分清，哪些代碼是已經存在的，哪些是你新加上去的。所以，很可能會給你提出一些修改意見，包含了修復「他們曾經沒有發現，review的時候剛發現的代碼中早已包含的一些問題」。對於這些問題，你可以選擇拒絕，另開issues去處理。 因為這些代碼並不是你寫的，上下文你也不清楚，如果冒然修改，可能會引起未知的連鎖問題，那麼你這個PR就休想完成了。

修改Review請求

對於Review之後的修改請求，經過你的過濾和判斷之後，選擇真正需要修復的代碼進行修改即可。這期間還要注意，CI中的測試是否通過。如果沒有通過，需要你點擊details鏈接過去看看測試是什麼原因出錯了。

測試沒有通過，會有很多原因：

• 可能沒有排上隊，超時了
• 其他一些詭異的問題，但是和你修改的代碼沒有關係

對於你理解不了的問題，你可以另外發起一個issues來報告給TiKV團隊。然後你就可以重新提交一下代碼來觸發測試，沒準就能過。

合併代碼

代碼合併之後，你就是一個貢獻者了。但是，這可以是結束，也可以是一個好的開始。

你能以這個PR涉及的業務為中心，然後逐漸輻射到與之相關的更多issues，繼續去提交貢獻，那麼肯定會一次比一次嫻熟。

小結

現在Rust的職位確實很少，但是Rust又是那麼有魅力，幾乎有80%的開發者想用Rust。如何是好呢？ 給開源項目做貢獻就是一個好的方法，在實踐中學習Rust。

給TiKV做貢獻有什麼好處呢？眾所周知，TiKV最近從Rust官方招攬了幾員猛將，比如brson和nrc。我給TiKV提交的PR是由brson負責的，所以我有幸領略了brson的做事風格：

• 完全溝通。對於一個很小的問題，都可以很詳細的給你回復，不會讓你有理解上的盲點。這是遠程溝通的典範。
• 對代碼精益求精。從代碼的簡潔性、可讀性、架構上都會考量，並且給出指導意見。
• 系統性思維。從一個細微的Bug出發，放眼整個項目，從而找出代碼結構的不合理性，而不是簡單的修復Bug。

給TiKV做貢獻讓我學到不少東西。除了brson，Tikv團隊中其他成員也非常棒，給我的代碼也提出了不少修改意見，讓我學到了不少技巧。當然，你如果想給其他開源項目做貢獻，我想也會有相同的收穫的。只不過本文是侷限於了TiKV，僅供參考。

更多閱讀： 如何為Rust語言做貢獻