剛開始工作的時候總覺得,可以做出一個很多人使用的Third party library 真的很酷,如果有一天自己也可以做出一些,那會是一件多棒的事。

其實,2016 年的我曾期許2017 年的自己,可以嘗試對開源社群做出貢獻,無奈2017 年的我,對於自己不夠有信心也不夠積極,始終沒做出什麼來 😅

這篇文章將會分享我對開源社群的貢獻過程,以及我的小小心得 🤘

第一次

沒想到在今年,無意間在看Facebook/Yoga 的 Doc. 時發現,疑?這文件是不是錯字拉?

無標題

就這樣,我完成了我人生第一個Pull request 🤣

無標題

關注開源社群

自此,我感覺從開源貢獻得到 虛榮心 成就感,於是我開始透過GitHawk 關注一些活躍的開源社群。

GitHawk 是一個透過SwiftIGListKit 實作的GitHub iOS Client,特別的是他完全開源,所以針對一些我們好奇別人的App 怎麼時做的,都可以從他身上挖寶。

此外,GitHawk 成立了另一個GitHawkApp 社群,裡面將許多GitHawk 本身用到的component 做成獨立的library,讓我們可以更彈性便利的用在專案上。

Starter task

也因為有了關注一些Repo. 的習慣後,我開始會翻一翻我感興趣的Repo. 的issue 當中,有沒有一些事我可以去實作的。

在活躍的Repo. 中,常常會將一些issue 標記成good first issueStarter task… 等等的分類,大神們有時會很慷慨(我自己認為)的讓新手們可以對社群貢獻,讓大家更有參與感。

因此我在GitHawkApp/ContextMenu 找到了一個非常簡單的工作,就是幫已經存在的method 加一個參數 🙃

無標題

沒錯,又改了五行,與其說有什麼巨大的貢獻,更不如說是運氣好,但也因為這兩次的pull request 都被接受,讓我在那個月卯起勁來貢獻開源社群。

一個踏實的貢獻

一樣的循環,我翻找著我很喜歡的Instagram/IGListKit 當中,有沒有什麼我能解決的問題,我找到了這個,他是IGListKit 當中,所沒有實作的功能。

於是我開始trace IGListCollectionViewLayout,這個相較之下,比前兩個PR 複雜得多的class。

第一次被公開Review

在健康的專案中,Code review 肯定是不能免得,每個PR 都會被維護者們細心檢視,再加上自動化單元測試的庇佑,對於我的PR 還算是有信心.我就這樣送出了第一版改動。

Review 的過程很有趣,有些效能、變數命名的問題,都可以學到很多東西,不過,在Review 的過程中,大神問了我一個問題:

無標題

因為這一問,我特地去試著重現會遇到什麼問題,結果悲劇發生了,我發現了其他 Bug 😱

忽略的Test case

我在同一個PR 下紀錄我發現的一切,用最快的速度確認Bug 是不是我造成的,深怕自己一個疏忽這個千載難逢的機會就這樣被拒絕 😆

當時,我鎖定了release 版與尚未出版的master latest,都有著Bug 但問題不同,我後來順便修正了這個問題,但這個Bug 卻沒有被我第一版unit test 所發現。

原因是,我測試的case 只針對了兩個section 的狀況下做測試,剛好在大於兩個的狀況下會出問題,於是我修改了Test case,並順便修復了問題。

漫長的等待

開源專案或許總是如此,在PR 被tag 上下一版的Milestone 之後,一直等到3.3.0 版的Release. XD

無標題

無標題

我很興奮,我好似成為了三年前的自己所崇拜的 大神 一樣,或許有些不切實際,但也給了此時此刻的自己多一些肯定。

結語

其實,有過第一次後,我自己感覺回饋開源社群這件事不難,找到自己熟悉的框架、找個簡單的Starter task 、工作上使用的框架卻找到Bug 我們自己修,都可能成為第一次的開源貢獻。

大多數的人懂的用,卻害怕回饋(?),深怕把熟悉的框架搞壞,其實不然,在CI 的環境與Reviewer 的監督下,我倒認為框架的健康度大可放心。

然而,我們不再只是說嘴某某框架又疏於維護,某某框架有Bug 而不修了,身為使用框架的一員,我們都可以再次成為凋零框架的新維護者(自己Fork 嘛!)

加油,未來的自己,期許可以再回饋給更多人👍