前言
為開源專案做出貢獻可能令人生畏——PostgreSQL也不例外。作為PostgreSQL的長期貢獻者，Aleks分享了他來之不易的技巧，以幫助您做出第一次貢獻，或做出更多貢獻。
PostgreSQL是世界上最受歡迎的資料庫之一。
我們是PostgreSQL的Timescale擴充套件功能的忠實粉絲，這已經不是什麼秘密了：我們已經在它的基礎上構建了TimescaleDB，還聘請了開源PostgreSQL貢獻者（像我一樣！）。同時，我們開發了一些功能來讓 PostgreSQL更好地應用於時序場景（例如Skip Scan，它使PostgreSQL中的某些查詢速度提高8000倍）。
除了改進資料庫本身，我們還致力於PostgreSQL社群的成功。
開源不僅僅是我的熱情，也是我的職業。自2016年以來，我一直是PostgreSQL貢獻者，最近加入Timescale作為全職開源PostgreSQL貢獻者。我不僅為PostgreSQL做過貢獻，還為Insolar、Sigrok和其他開源專案做過貢獻。我是PostgreSQL的pg_protobuf和ZSON擴充套件和幾個STM32微控制器的開源庫的作者。
我喜歡開源，因為它能夠使我們看到軟體的內部，並從中學習改進它。開源軟體的質量標準高於專有軟體，因為您無法做隱藏和偷工減料。最後但同樣重要的是，開源軟體不會因為地緣政治事件或諸如此類的事情而拒絕出售或延長許可。（在我的職業生涯中，我至少遇到過兩次這種情況。）
今年早些時候，我們開展了“PostgreSQL現狀”調查，以瞭解人們如何使用PostgreSQL，從他們的社群經驗到流行的工具和需要改進的領域。
您可以檢視2021年PostgreSQL現狀報告來探索所有發現和趨勢——但有一個結果對我來說很有感觸：
85%的受訪者沒有貢獻PostgreSQL的程式碼庫、文件或提交，只有4%的人貢獻過幾次。
該調查還強調了作為PostgreSQL社群我們可以更歡迎新開發人員，幫助他們使用PostgreSQL和為PostgreSQL做貢獻。
例如，一位受訪者說：“第一個程式碼貢獻可能會帶來創傷……有時我們不太歡迎新開發人員［原文如此］。
我們應該改進……
”
在2021年PostgreSQL現狀調查中，85%的受訪者沒有為PostgreSQL程式碼庫、文件或提交做出貢獻。
這讓我開始思考，該如何讓人們更輕鬆地克服最初的恐懼和其他障礙
——無論是技術的困難、流程的困惑，還是缺乏資訊——這些障礙經常圍繞著開源專案。畢竟，我們希望更多的人成為PostgreSQL社群的一份子並做出貢獻；這就促使我們思考如何讓它變得更好。
為了幫助更多想要貢獻的人參與，我將分享我的觀察、過去5年多學到的東西、希望在開始時就知道的東西，以及給新貢獻者的一些建議。
我將使用PostgreSQL作為特定的例子，無論你是想為PostgreSQL做第一次(或第二次，或第三次)的貢獻，還是有另一個開源專案的想法，下面的指導是非常通用的。
還介紹了一些回饋社群或程式碼之外的貢獻方法以及建立一個可持續、健康的開源社群的容易被忽視的重要元素。
第1步：確定你的動機
要問的最重要的問題之一是：“你為什麼想成為開源貢獻者？”
除非你認識到並理解你的動機，否則你很難為專案安排時間，尤其是隨著時間的推移。
以下是您可能想要開始從事開源專案的潛在原因列表：
1。
獲得獨特的體驗：
如果您是一位有經驗的編寫微服務後端開發人員，可能會尋找新的挑戰。開源軟體提出了很多這樣的挑戰和需要學習的新技術。
2。
瞭解您最喜歡的作業系統/資料庫/語言/編譯器的內部結構：
通過了解您最喜歡的開源專案的內部結構可以讓您更有效地使用它，並瞭解其侷限性。例如，沒有多少使用者知道執行SELECT查詢可能會導致PostgreSQL寫磁碟。或者建立多個臨時表可能會顯著影響整個資料庫的效能。或者synchronous_commit = remote_apply在提交事務之前實際上並不等待副本的反饋。（事務是即時提交的。只是沒有通知使用者這一點，這可能會導致問題。）
3。
與優秀的人一起工作：
開源吸引了來自世界各地的一些最有才華的人。總有一些你可以從他們身上學到的東西，無論大小。ZSON擴充套件的最初想法來自Alexander Korotkov和Teodor Sigaev，我很幸運能作為PostgreSQL提交者與他們一起合作。現在，ZSON是我在GitHub 上最受歡迎的專案（在撰寫本文時有390多個星）——並有可能會隨PostgreSQL一起釋出。
4。
為了讓使用者更滿意：
假設您貢獻了幾行程式碼，使PostgreSQL速度在某些情況下提高了10%。PostgreSQL被數千家公司使用，其產品被數百萬客戶使用。令人欣慰的是，您的小補丁讓所有這些使用者都更快樂了一點，雖然你沒有收到他們寄來的感謝信。
5。
提升你的簡歷：
為著名的開源軟體做出幾年的貢獻，無論是技術積累還是社群人脈都能幫你找到更適合的工作，
公平地說，您可能想要開始為開源專案做出貢獻的原因可能有很多。這個列表並不詳盡，每個案例都是獨一無二的，但我試圖提煉出我一次又一次看到的一些原因。
一旦你花了一些時間來思考，明確為什麼想貢獻，下一步就是熟悉該專案的開發過程。
第2步：瞭解開發過程
在開始新補丁的開發之前，先了解以下內容：
1。如何編譯程式碼
2。如何執行測試
3。如何構建文件
4。如何除錯/分析/基準測試程式碼
5。如何格式化程式碼
6。如何提交補丁
您通常可以在專案的GitHub README文件中的找到大部分資訊。對於PostgreSQL，請檢視安裝文件。
PostgreSQL是用C編寫的，使用GNU Autotools構建系統，並依賴Perl指令碼語言進行測試，使用SGML進行文件處理。使用Git作為版本控制系統，並且儲存庫是自託管的（儘管GitHub上有一個映象）。
PostgreSQL可以這樣編譯和測試：
git clone http：//git。postgresql。org/git/postgresql。gitcd postgresql。/configure ——prefix=/home/user/pginstall ——enable-tap-tests ——enable-cassert ——enable-debugmake worldmake check-world
不過細節有點複雜。首先，必須安裝幾個依賴項，這取決於作業系統。
例如，在Ubuntu 20。04 LTS上，您將需要：
# for basic buildsudo apt install gcc make flex bison libreadline-dev zlib1g-dev# to build the documentation as wellsudo apt install docbook docbook-dsssl docbook-xsl libxml2-utils \openjade opensp xsltproc
其次，您可能會犯一些常見錯誤，例如，make distclean更改標頭檔案後忘記執行。
GitHub上有一組指令碼可以幫助您避免這些錯誤。
以下是使用說明：
# where to install Postgres （you can add this line to your ~/。bash_profile）export PGINSTALL=“/home/user/pginstall”# build and test Postgres。/full-build。sh# install it to $PGINSTALL。/single-install。sh# execute a little more tests on running Postgresmake installcheck-world# check the documentation：open ~/pginstall/share/doc/postgresql/html/index。html
此外，PostgreSQL社群使用郵件列表作為討論、提交和審查補丁的主要溝通渠道。
要了解訊息型別，請訂閱pgsql-hackers@（請注意，此郵件列表上每天有許多訊息）。另外兩個重要的郵件列表是pgsql-general@和pgsql-bugs@，還有許多其它的分離主題的郵件列表。
順便說一句：在瀏覽PostgreSQL現狀調查的匿名調查資料時，許多回復提到郵件列表不是跟蹤錯誤的最友好方式，還可能是參與的障礙。例如，“現在人們認為郵件列表是“困難”的。我認為這不是與社群互動最友好的介面。”
在您熟悉了開發過程之後，是時候開始考慮您的第一個補丁的想法了。
第3步：確定您的第一個補丁
你的第一個補丁不必很花哨。以下是我認為可以作為PostgreSQL第一個補丁的示例：
1。
查詢並修復註釋和文件中的錯誤：
從簡單的事情開始。根據我的經驗，專案在程式碼註釋和文件中肯定會有錯別字和錯誤。使用您最喜歡的文字編輯器和拼寫檢查器來查詢它們。這是一個非常好的開始和克服對貢獻恐懼的地方：沒有破壞任何東西的風險。有趣的是，這正是我向Linux核心提交第一個（也是目前唯一的）補丁的方式。（我對PostgreSQL的第一個補丁相當複雜，因此不是很有代表性。）
2。
參與程式碼審查、測試和討論：
許多軟體開發人員喜歡編寫程式碼，但很少有人喜歡審查和測試它。對PostgreSQL做出的最有價值的貢獻之一就是成為一名審閱者。作為審閱者，您的主要任務是檢查補丁是否編譯、透過測試、實現宣告的功能並記錄在文件中。當然，檢查它是否有明顯的錯誤會很有價值。
3。
查詢並修復錯誤：
檢查bugtracker，或者檢查pgsql-bugs@郵件列表的存檔。嘗試重現該錯誤。如果不能重現，可能已經被另一個補丁修復了，或者重現它的步驟不是很清楚。無論如何，回覆郵件列表讓社群知道你發現了什麼。如果您能夠設法重現該錯誤，從出錯的地方更改程式碼，然後編寫相應的測試，使其透過驗證。
4。
找到瓶頸並最佳化程式碼：
使用某個軟體一段時間後，您會發現其效能遠非理想的情況。使用合適的工具（例如perf和eBPF）找到瓶頸，然後消除它。在提交補丁之前，請確保在其它一些場景中不會導致效能下降。
5。
編寫測試：
使用合適的工具來測試程式碼覆蓋率。對於PostgreSQL（C或C++），該工具是lcov。手頭如果有程式碼覆蓋率報告，編寫一個增加程式碼覆蓋率的測試。
6。
改進文件：
理想情況下，文件的結構應該允許使用者將其作為PDF下載，並像閱讀書籍一樣閱讀。PostgreSQL文件非常好，涵蓋了很多主題內容，但仍然可以受益於更有經驗/專注的技術作者（例如，可以新增更多示例場景和插圖，以幫助新使用者理解抽象的概念）。PostgreSQL共有71章2300+頁，主要描述了配置引數和查詢語法。如果考慮內容描述如何解決具體任務。FreeBSD手冊是一個很好的的例子。
7。
重構程式碼：
重構有一個明確的目標是重寫程式碼，讓它做同樣的事情，但更具可讀性。值得注意的是，有時PostgreSQL社群可能會對此類補丁的價值持懷疑態度。原因是社群支援PostgreSQL的最後5個主要版本。因此，重構會使bug修復的反向移植變得更加複雜。
我建議積累一些小的勝利，在你轉向更雄心勃勃的補丁之前，先提交幾個“補丁”之類的貢獻。將幫助您熟悉貢獻流程、工具和社群——更能增加您的信心。
一旦你確定了第一個補丁的想法，就可以開始投入工作了！（我建議先閱讀下面關於常見錯誤的章節：）
第4步：如何避免常見錯誤
人們在加入開源專案時會犯一些常見的“錯誤”，因此我整理了以下建議幫助您來避免。
1。從簡單的事情開始
2。你的補丁越小，它被接受的機會就越大
3。仔細聆聽對補丁的反饋
4。始終保持禮貌（包括：永遠不要諷刺，拖釣等……）
5。並非所有補丁都被接受，不要太在意
6。貢獻者也是人；大多數人在業餘時間從事開源工作
7。Grammarly對我們這些以英語為第二語言的人有很大幫助
到目前為止，我的討論主要集中在提供新程式碼或錯誤修正的補丁上。但是，提交補丁並不是為開源專案做出貢獻的全部內容和最終目的。
接下來，我們將看看如何在不編寫程式碼的情況下為開源專案和周邊社群做出貢獻。
第5步：考慮在程式碼之外做出貢獻
除了編寫程式碼和文件之外，還有很多方法可以為專案做出貢獻——這些非程式碼貢獻是無價的。
以下是我最喜歡的幾個想法，儘管該列表並不完整：
1。
幫助新人：
總有人最近開始使用某個開源專案（作為參考，在PostgreSQL現狀調查中，幾乎50%的受訪者表示他們是該專案的新手，有0-5年的經驗。）通常，有一個郵件列表或Slack（聊天群組），他們可以在那裡提問。加入相應頻道，幫助新人。
2。
參加會議：
就你最近使用、學習或一直在做的事情做一個演示，分享知識。對於PostgreSQL，有幾個流行的會議，如PGconf。asia、Postgres London和PGconf。us，以及許多本地聚會。
3。
建立部落格/播客/YouTube頻道：
例如，這篇文章可以被視為對開源的一個小貢獻。確保將您的部落格、播客等新增到著名的社群新聞聚合器中，以便人們可以瞭解它。對於PostgreSQL，是PostgreSQL Planet。
4。
寫一本書：
寫一本書是一個雄心勃勃且非常耗時的目標，但有很多方法可以做到。例如，Manning是一家以幫助新技術作家出版他們第一本書而聞名的出版商；或者只是在Google Docs中製作PDF並免費分發。
5。
參加Google Summer of Code或Google Season of Docs：
Google Summer of Code（GSoC）是一個專注於讓學生軟體開發人員參與開源開發的計劃。以學生或導師的身份參與。如果您是技術作家，請考慮參加Google文件季（GSoD）。有關更多資訊，請參閱PostgreSQL Wiki 上的GSoC和GSoD頁面。
6。
為CI系統捐贈硬體。
CI代表持續整合——在PostgreSQL世界中，它被稱為Buildfarm。社群有興趣向Buildfarm新增不尋常的平臺或架構、作業系統和編譯器的組合。例如，目前還沒有采用RISC-V架構的伺服器。RISC-V是一種開放指令集架構（ISA），得到了許多領先硬體製造商的支援，尤其是在發現Meltdown和Spectre漏洞之後。有關更多詳細資訊，請參閱加入PostgreSQL Buildfarm的申請。
瞭解更多資訊資源
在為PostgreSQL做貢獻的背景下，推薦以下材料用於自學：
C in a Nutshell，第2版by Peter Prinz， Tony Crawford
Autotools Mythbuster by Diego Elio Pettenò， David J。 Cozatt
Randal L。 Schwartz等人的《學習Perl和中級Perl》。
Martin Fowler等人的重構。
系統性能，第二版Brendan Gregg
Brendan Gregg的BPF效能工具
Hector Garcia-Molina等人的資料庫系統實現。
培養新的PostgreSQL開發人員，作者是Anastasia Lubennikova和我自己。請參閱附有推薦白皮書的附贈幻燈片。
以下資料為了容易檢索保留原文或相關連結
C in a Nutshell， 2nd Edition by Peter Prinz， Tony Crawford
Autotools Mythbuster by Diego Elio Pettenò， David J。 Cozatt
Learning Perl and Intermediate Perl by Randal L。 Schwartz， et al。
Refactoring by Martin Fowler， et al。
Systems Performance， 2nd Edition by Brendan Gregg
BPF Performance Tools by Brendan Gregg
Database System Implementation by Hector Garcia-Molina， et al。
Growing up new PostgreSQL developers， by Anastasia Lubennikova and myself。 See the bonus slides with recommended white papers。
最後的想法
這篇文章只是我多年來觀察到的建議、最佳實踐和其他各種事情的集合，以幫助潛在的貢獻者從“從不貢獻”到“貢獻一兩次”（最終，希望有些人讓它“多次貢獻”）。
還有更多的技術和社群體驗的話題，沒有在這裡介紹。如果您想了解更多有關內容（例如，除錯、分析和基準測試，或者關於編寫擴充套件），請聯絡我和團隊：aleksander@timescale。com。
我們也在尋找方法來幫助社群、分享知識併為社群成員已經在做的事情做出貢獻。
最後，如果我沒有提到我們正在透過多個團隊招聘人才，那就是我的失職了。
TimescaleDB是領先的時間序列資料開源關係資料庫。它被打包為PostgreSQL擴充套件（類似於CREATE EXTENSION的擴充套件，不是分叉，也不是一組補丁）。
如果您瞭解C和SQL，有使用PostgreSQL的經驗，並且想成為一名全職資料庫開發人員，我鼓勵您考慮加入Timescale作為核心資料庫開發人員。
Timescale是一家偏遠地區人才優先的公司，員工分佈在各大洲（南極洲除外——但如果是您，我們很樂意為您的家庭辦公室配備空間加熱器）。
如果您想與我、Timescale工程師以及其他開發人員和社群成員討論技術主題，您可以在TimescaleDB Slack（6K+成員）中找到我們。
我們正在愉快的貢獻中……
作者：亞歷山大·阿列克謝耶夫（Aleksander Alekseev）
自2016年以來，Aleksander專門從事開源專案。他是PostgreSQL的pg_protobuf和ZSON擴充套件的作者。Aleksander於2021年作為PostgreSQL貢獻者加入Timescale。
譯者：魏波
多年的資料庫技術從業經驗，曾服務於中國移動、中央電視臺、民生銀行的資料庫管理專案；自2017以來，一直致力於PostgreSQL在中國的推廣與發展，是中國PostgreSQL培訓認證專案負責者。
原文
https：//blog。timescale。com/blog/how-and-why-to-become-a-postgresql-contributor/？utm_source=pg-weekly-sponsor&utm_medium=email&utm_campaign=pg-weekly-sponsor-aug-2021&utm_content=pg-contribute-blog
