摘要：原文地址作者超級(jí)賬本如何貢獻(xiàn)個(gè)人感受，文檔看的再多，學(xué)習(xí)的速度也不如參與到項(xiàng)目中去，深入了解實(shí)現(xiàn)原理和設(shè)計(jì)的初衷。維護(hù)者負(fù)責(zé)評(píng)審和合并提交評(píng)審的所有布丁，并在超級(jí)賬本技術(shù)委員會(huì)的方針下指導(dǎo)項(xiàng)目的技術(shù)發(fā)展路線。

原文地址：https://www.xuanzhangjiong.to...
作者：TopJohn

個(gè)人感受，文檔看的再多，學(xué)習(xí)的速度也不如參與到項(xiàng)目中去，深入了解實(shí)現(xiàn)原理和設(shè)計(jì)的初衷。文檔只能讓我們對(duì)Fabric的整體運(yùn)行機(jī)制有一個(gè)宏觀的認(rèn)識(shí)，要進(jìn)一步深入，就需要從源代碼入手，而貢獻(xiàn)代碼則是一個(gè)自然而然的事情，學(xué)習(xí)的過程中總會(huì)發(fā)現(xiàn)一些問題和值得優(yōu)化的地方。所以前陣子順手翻譯了一下Fabric如何貢獻(xiàn)相關(guān)的官方文檔。這篇文章講解，其中的整體流程和所需用到的工具。如需詳細(xì)學(xué)習(xí)，請(qǐng)參考官方文檔：

官方文檔原版

官方文檔中文版

下面是我個(gè)人的官方文檔中文版本翻譯的GitHub倉(cāng)庫(kù)，歡迎大家star：

https://github.com/TopJohn/fa...

同時(shí)我會(huì)將已經(jīng)完成的部分同步發(fā)Pull Request到hyperledger-labs組織下的fabric-docs-cn倉(cāng)庫(kù)中：

https://github.com/hyperledge...

有興趣的朋友也可以一起參與超級(jí)賬本國(guó)際化相關(guān)的工作中來。

不管作為普通用戶還是開發(fā)者，這里都有很多為Hyperledger Fabric做貢獻(xiàn)的方法。

作為普通用戶：

提出功能-改進(jìn)建議

反饋錯(cuò)誤

幫助測(cè)試在release roadmap上即將發(fā)布的史詩(shī)。將問題通過Jira或者RocketChat反饋給開發(fā)者。

作為開發(fā)者：

如果你的時(shí)間不多，可以考慮選擇一些想要幫助的任務(wù)，參考修復(fù)問題和認(rèn)領(lǐng)正在進(jìn)行的任務(wù) 。

如果你可以全職開發(fā)，可以提一個(gè)新的特性（參考提出功能-改進(jìn)建議）帶領(lǐng)一個(gè)團(tuán)隊(duì)來實(shí)現(xiàn)它，或者加入在已經(jīng)存在的史詩(shī)中的團(tuán)隊(duì)。如果你在release roadmap發(fā)現(xiàn)了一個(gè)你感興趣的史詩(shī)，請(qǐng)及時(shí)通過Jira或者RocketChat聯(lián)系分配到任務(wù)的人，和他們一起完成這個(gè)史詩(shī)。

為了參與到Hyperledger Fabric項(xiàng)目的開發(fā)中來，你首先需要一個(gè)Linux Foundation賬號(hào)。你需要使用你的LF ID來訪問所有的Hyperledger社區(qū)的工具，包括 Gerrit，Jira，RocketChat，和Wiki (僅用于編輯)。

正如我們的章程中描述的那樣，Hyperledger Fabric是在一個(gè)開放治理的模型下管理的。項(xiàng)目和子項(xiàng)目由一系列維護(hù)者主導(dǎo)。一個(gè)新的子項(xiàng)目可以指定一些初始的維護(hù)者，當(dāng)項(xiàng)目第一次被批準(zhǔn)的時(shí)候，由頂級(jí)項(xiàng)目的現(xiàn)有維護(hù)者所批準(zhǔn)。

Fabric項(xiàng)目由項(xiàng)目的頂級(jí)維護(hù)者領(lǐng)導(dǎo)。維護(hù)者負(fù)責(zé)評(píng)審和合并提交評(píng)審的所有布丁，并在超級(jí)賬本技術(shù)委員會(huì)的方針下指導(dǎo)項(xiàng)目的技術(shù)發(fā)展路線。

項(xiàng)目的維護(hù)者會(huì)時(shí)不時(shí)地考慮添加或者刪除維護(hù)者。現(xiàn)有的維護(hù)者可以提交變更到MAINTAINERS.rst文件中。一個(gè)提名的維護(hù)者可以由大多數(shù)現(xiàn)有的維護(hù)者批準(zhǔn)通過成為正式的維護(hù)者。一旦批準(zhǔn)通過，變更就會(huì)被合并同時(shí)個(gè)體就會(huì)在維護(hù)者的組中被添加（或者移除）。維護(hù)者可能會(huì)因?yàn)槊鞔_的辭職、長(zhǎng)時(shí)間的不活動(dòng)（超過3個(gè)月或者更長(zhǎng)的時(shí)間），或者因?yàn)檫`反相關(guān)的行為準(zhǔn)則或則持續(xù)表現(xiàn)出糟糕的判斷而被移出維護(hù)者的隊(duì)列。

Fabric的維護(hù)者已經(jīng)確定了每個(gè)季度大致的發(fā)布節(jié)奏（請(qǐng)參考 releases。我們也在積極考慮采用LTS（long term support）的發(fā)布過程，雖然這些細(xì)節(jié)需要由具體的維護(hù)者決定。相關(guān)細(xì)節(jié)請(qǐng)參考在Chat的#fabric-maintainers中的討論。

首先，請(qǐng)回顧一下JIRA確保之前沒有已經(jīng)開啟或者關(guān)閉的相同功能的提案。如果沒有，為了開啟一個(gè)提案，我們建議創(chuàng)建一個(gè)Jira的Epic或者Story，選擇一個(gè)最合適的環(huán)境，并附上一個(gè)鏈接或者內(nèi)嵌一個(gè)提案的頁面，說明這個(gè)特性是做什么的，如果可能的話，描述一下它應(yīng)該如何實(shí)現(xiàn)。這有助于說明為什么應(yīng)該添加這個(gè)特性，例如確定需要該特性的特定用例，以及如果實(shí)現(xiàn)該特性的好處。一旦Jira的issue被創(chuàng)建了，并且描述中添加了附加的或者內(nèi)嵌的頁面或者一個(gè)公開的可訪問的文檔鏈接，就可以向 [email protected] 郵件列表發(fā)送介紹性的電子郵件，郵件中附上Jira issue的鏈接，并等待反饋。

對(duì)建議性的特性的討論應(yīng)該在JIRA issue本身中進(jìn)行，這樣我們就可以在社區(qū)中有一個(gè)統(tǒng)一的方式來找到這個(gè)設(shè)計(jì)的討論。

獲得3個(gè)或者更多的維護(hù)者對(duì)新特性的支持將會(huì)大大提高該特性相關(guān)的變更申請(qǐng)被合并到下一次發(fā)布的可能性。

維護(hù)者會(huì)在每隔一周的周三的東部時(shí)間9點(diǎn)舉行雙周會(huì)議在 Zoom上。請(qǐng)參考community calendar獲取具體信息。

維護(hù)者的會(huì)議的目的是為了計(jì)劃以及審查發(fā)布的進(jìn)度，同時(shí)討論項(xiàng)目或者子項(xiàng)目的技術(shù)以及操作方向上的事宜。

如上所述的新特性/增強(qiáng)建議應(yīng)該在維護(hù)者的會(huì)議上進(jìn)行探討，反饋和接受。

Fabric相關(guān)的發(fā)布路線的史詩(shī)維護(hù)在JIRA上。

我們使用 RocketChat來進(jìn)行交流或者實(shí)用 Google Hangouts? 進(jìn)行屏幕分享。我們的開發(fā)計(jì)劃和優(yōu)先級(jí)在JIRA上進(jìn)行發(fā)布，同時(shí)我們也花大量的時(shí)間在mailing list上進(jìn)行討論才做決定。

在我們開始之前，如果你還沒有這樣做那你可能需要檢查一下您是否已經(jīng)在將要開發(fā)區(qū)塊鏈應(yīng)用或者運(yùn)行Hyperledger Fabric的平臺(tái)上是否安裝了運(yùn)行所需的環(huán)境。

如果你試圖尋找一種途徑來尋找專家援助或者解決一些問題，我們的 社區(qū)總是會(huì)為您提供幫助的。我們?cè)贑hat，IRC(#hyperledger on freenode.net) 以及 mailing lists中都可以找到。我們大多數(shù)人都很樂意提供幫助。唯一愚蠢的是你不去問。問題實(shí)際上是幫助改進(jìn)項(xiàng)目的很好的方法，因?yàn)樗鼈兪刮覀兊奈臋n更加清晰。

如果你是一個(gè)用戶，并且發(fā)現(xiàn)了錯(cuò)誤，請(qǐng)使用JIRA來提交問題。在您創(chuàng)建新的JIRA問題之前，請(qǐng)嘗試搜索是否有人已經(jīng)提過類似的問題，確保之前沒有人報(bào)告過。如果之前有人報(bào)告過，那么你可以添加評(píng)論表明你也期望這個(gè)問題被修復(fù)。

如果缺陷與安全相關(guān)，請(qǐng)遵循Hyperledger安全問題處理流程

如果以前沒有報(bào)告過，請(qǐng)創(chuàng)建一個(gè)新的JIRA。請(qǐng)嘗試為其他人提供足夠多的信息以重現(xiàn)該問題。該項(xiàng)目的維護(hù)人員應(yīng)該在24小時(shí)之內(nèi)回復(fù)您的問題。如果沒有，請(qǐng)通過評(píng)論提出問題，并要求對(duì)其進(jìn)行評(píng)審。您還可以在Hyperledger Chat中將問題發(fā)布到相關(guān)的相關(guān)的Hyperledger Fabric的頻道中。比如，可以將一個(gè)文檔問題在
#fabric-documentation中進(jìn)行廣播，一個(gè)數(shù)據(jù)存儲(chǔ)問題可以在#fabric-ledger中廣播，以此類推。

如果你在JIRA上提交了你剛剛發(fā)現(xiàn)的問題，并希望修復(fù)它，我們很樂意并且非常歡迎。請(qǐng)將JIRA問題分配給自己，然后您可以提交變更請(qǐng)求（CR）。

如果你在提交第一個(gè)CR的時(shí)候需要幫助，我們已經(jīng)為你創(chuàng)建了一個(gè)簡(jiǎn)短的教程。

查看問題列表找到你感興趣的內(nèi)容。您也可以從求助 列表中尋找。明智的做法是從相對(duì)直接和可實(shí)現(xiàn)的任務(wù)開始，并且這個(gè)任務(wù)是未被分配的。如果沒有分配給別人，，請(qǐng)將問題分配給自己。如果你無法在合理的時(shí)間內(nèi)完成，請(qǐng)加以考慮并且取消認(rèn)領(lǐng)，如果你需要更多的時(shí)間，請(qǐng)?zhí)砑釉u(píng)論加以說明，你正在積極處理問題。

另一種貢獻(xiàn)和了解Hyperledger Fabric的方法是幫助維護(hù)人員審查開放的CR。實(shí)際上維護(hù)者是相對(duì)困難的，他們需要審查所有正在提交的CR并且評(píng)估他們是否應(yīng)該被合并。您可以查看代碼或則文檔修改，測(cè)試更改的內(nèi)容，并告知提交者和維護(hù)者您的想法。完成審核或測(cè)試后，只需要添加評(píng)論和投票，即可完成回復(fù)CR。評(píng)論“我在系統(tǒng)X上嘗試過這個(gè)CR，是正確的”或者“我在系統(tǒng)X上運(yùn)行這個(gè)CR發(fā)現(xiàn)了一些錯(cuò)誤”將幫助維護(hù)者進(jìn)行評(píng)估。因此，維護(hù)人員也能夠更快地處理CR，并且每個(gè)人都能從中獲益。

瀏覽 Gerrit上開放的CRs開始你的貢獻(xiàn)。

接下來，在本地開發(fā)環(huán)境中構(gòu)建項(xiàng)目，以確保所有配置都是正確的。

一次只包含一個(gè)變更。不是五個(gè)，3個(gè)，或者10個(gè)。僅僅一個(gè)變更。為什么呢？因?yàn)樗兏挠绊懛秶?。如果我們有一輪回歸，那么將更容易證明一次影響較廣的組合提交將是一個(gè)罪魁禍?zhǔn)住?/p>

在JIRA的故事中包含一個(gè)鏈接。為什么？因?yàn)?a) 我們希望追蹤你的速度以便更好地判斷我們可以傳遞什么信息。b) 因?yàn)槲覀兛梢宰C明這次變更是有效的。在很多情況下，會(huì)有很多討論圍繞提交的變更，我們希望將它鏈接到它的本身。

每次變更都包含單元或者集成測(cè)試（或者對(duì)已有測(cè)試的修改）。這不僅僅意味著正確的測(cè)試。同樣包括一些異常測(cè)試來捕獲錯(cuò)誤。在你寫代碼的時(shí)候，你有責(zé)任去測(cè)試它并且證明你的變更是正確的。為什么呢？因?yàn)闆]有這些，我們無法知道你的代碼是否真的正確地工作。

單元測(cè)試需要沒有額外的依賴。你應(yīng)該使用 go test 或者等價(jià)的語言的測(cè)試方式來運(yùn)行單元測(cè)試。任何需要額外依賴的測(cè)試（例如需要用腳本來運(yùn)行另一個(gè)組件）需要適當(dāng)?shù)膍ocking。任何除了單元測(cè)試以外的測(cè)試根據(jù)定義都是集成測(cè)試。為什么？因?yàn)楹芏嚅_源軟件開發(fā)者都實(shí)用測(cè)試驅(qū)動(dòng)的開發(fā)方式。他們關(guān)注一個(gè)目錄下的測(cè)試用例，一旦代碼變更了他們采用測(cè)試去判斷他們的代碼是否正確。這是非常高效的，相比當(dāng)代碼變更后運(yùn)行整個(gè)項(xiàng)目來說。請(qǐng)參考單元測(cè)試的定義在腦海中建立單元測(cè)試的標(biāo)準(zhǔn)，以此來寫出高效的單元測(cè)試。

每個(gè)CR的最小代碼行數(shù)。為什么？因?yàn)榫S護(hù)者每天同樣也有工作。如果你發(fā)送1000或者2000行的代碼，你認(rèn)為維護(hù)者需要多久才能審查完你的代碼？保證你的變更在200-300行左右，盡可能地。如果你有一個(gè)比較大的變更，可以將它分解為比較小的幾個(gè)無關(guān)的變更。如果要添加一組新功能來滿足一個(gè)需求，請(qǐng)?jiān)跍y(cè)試中分別添加它們，然后編寫滿足需求的代碼。當(dāng)然，總會(huì)有以外。如果你增加一些小變動(dòng)然后添加了300行測(cè)試，你將會(huì)被寬恕;-)如果你需要做一個(gè)變更，而且影響比較廣或者生成了很多代碼（protobufs等）。同樣也是個(gè)例外。

大的變更，例如那些大于300行的CR將更有可能收到-2，并且你可能被要求重構(gòu)以符合本指南。

不要堆疊你的變更請(qǐng)求（例如在先前的變更請(qǐng)求的本地分支提交你的變更）除非它們是相關(guān)聯(lián)的。這將最大幅度減少合并沖突，并且更快地合并。如果你堆疊你的變更請(qǐng)求，由于前面的請(qǐng)求中的審核注釋，你后續(xù)的請(qǐng)求將被擱置。

寫一個(gè)有意義的提交信息。包括55個(gè)或者更少字符的標(biāo)題，后面跟一行空行，然后跟上更全面的關(guān)于變更的描述。每個(gè)變更必須包括對(duì)應(yīng)的變更的JIRA標(biāo)識(shí)號(hào)(例如[FAB-1234])。這個(gè)可以在標(biāo)題中，但是同樣需要包括在消息正文中。

Gerrit會(huì)自動(dòng)創(chuàng)建超級(jí)鏈接到JIRA的條目。例如


    [FAB-1234] fix foobar() panic

    Fix [FAB-1234] added a check to ensure that when foobar(foo string)
    is called, that there is a non-empty string argument.

最后，要有回應(yīng)。不要讓一個(gè)變更請(qǐng)求因?yàn)閼?yīng)為評(píng)審意見而不了了之，這樣會(huì)導(dǎo)致它需要進(jìn)行rebase。這只會(huì)進(jìn)一步延遲合并，給你帶來更多的工作-以修復(fù)合并沖突。

注意: 每一個(gè)源文件必須包括Apache Software License 2.0?？梢詤⒖?license header。

我們盡可能努力讓貢獻(xiàn)邊等簡(jiǎn)單。這個(gè)協(xié)議為我們提供了貢獻(xiàn)相關(guān)的法律相關(guān)的知識(shí)。我們使用和Linux? Kernel社區(qū)一樣的管理貢獻(xiàn)的方法Developer"s Certificate of Origin 1.1 (DCO)來管理Hyperledger Fabric。

我們只要求在提交要審查的補(bǔ)丁時(shí)，開發(fā)者在commit消息中帶上他們的sign-off簽名即可。

這里是一個(gè)Signed-off-by line的簽名例子，指示了提交者接受DCO約定：

    Signed-off-by: John Doe 

你可以使用 git commit -s 在提交的時(shí)候來自動(dòng)帶上你的簽名。

維護(hù)者

使用Jira來了解當(dāng)前的工作流項(xiàng)

設(shè)置開發(fā)環(huán)境

構(gòu)建Hyperledger Fabric

配置

申請(qǐng)一個(gè)Linux Foundation賬號(hào)

使用Gerrit進(jìn)行工作

使用Gerrit進(jìn)行審核

查看待定的更改

提交一個(gè)變更到Gerrit

審查變更

Gerrit 最佳實(shí)踐

編程指南

生成 gRPC 代碼

添加或者更新Go第三方包

如果需要查看上述相關(guān)的文檔，我也已經(jīng)為大家做了翻譯，需要詳細(xì)查看每個(gè)細(xì)節(jié)的朋友可以查看中文文檔，或者點(diǎn)擊我博客右側(cè)的ARCHIEVEMENT之Fabric官方文檔中文版。