如何成為一個committer,你真的需要它嗎?

你好! 我的名字是德米特里‧巴甫洛夫,我在 網格增益,也是 Apache Ignite 的提交者和 PMC 參與者以及 Apache Training 的貢獻者。 我最近在 Sberbank 開源聚會上介紹了一位提交者的工作。 隨著開源社群的發展,越來越多的人開始產生疑問:如何成為committer,承擔哪些任務,需要寫多少行程式碼才能獲得這個角色。 當我們想到提交者時,我們立即想到的是無所不能、無所不知的人,頭上戴著王冠,拿著一本《乾淨代碼》而不是權杖。 是這樣嗎? 在我的帖子中,我將嘗試回答有關提交者的所有重要問題,以便您了解您是否真的需要它。

如何成為一個committer,你真的需要它嗎?

所有開源社群的新人都認為他們永遠不會成為提交者。 畢竟,對許多人來說,這是一個享有盛譽的角色,只有透過編寫大量程式碼才能獲得特殊的功績。 但事情沒那麼簡單。 讓我們從社區的角度來看看committer。

誰是提交者?為什麼需要提交者?

當我們創建一個新的開源產品時,我們總是允許用戶使用和探索它,以及修改和分發修改後的副本。 但是,當發生帶有更改的軟體副本不受控制的分發時,我們不會收到對主程式碼庫的貢獻,專案也不會開發。 這就是需要提交者的地方,提交者有權收集使用者對專案的貢獻。

為什麼要成為提交者?

讓我們從這樣一個事實開始:承諾對於簡歷來說是一個加分項,對於程式設計領域的初學者來說,這是一個更大的加分項,因為在申請工作時他們通常會要求提供程式碼範例。

提交的第二個毫無疑問的優勢是有機會與頂級專家進行交流,並將一些很酷的想法從開源中引入到您的專案中。 此外,如果你很了解某個開源產品,你就可以在支援或使用它的公司找到工作。 甚至有一種觀點認為,如果不參與開源,就無法獲得較高的職業職位。

除了事業和就業方面的好處之外,承諾本身也是令人愉快的。 您受到專業界的認可,您清楚地看到自己的工作成果。 與某些公司開發不同,有時您甚至不明白為什麼要在 XML 中來回移動欄位。

在開源社群中,您可以遇到 Linus Torvalds 等頂尖專家。 但如果你不是這樣,你就不應該認為那裡沒有什麼可做的——有不同層次的任務。

嗯,還有額外的好處:例如,Apache 提交者可以獲得免費的 IntelliJ Idea Ultimate 授權(儘管有一些限制)。

怎樣才能成為提交者?

這很簡單——你只需要承諾。

如何成為一個committer,你真的需要它嗎?

如果您認為專案中沒有任務給您,那您就錯了。 只需加入您感興趣的社區並做它需要做的事情。 Apache 軟體基金會有一個單獨的 指導 對提交者有要求。

你需要解決什麼問題?

種類最多-從開發到編寫測試和文件。 是的,是的,社群中測試人員和文件人員的貢獻與開發人員的貢獻受到同等重視。 有一些非標準任務 - 例如,運行 YouTube 頻道並告訴其他用戶您如何使用開源產品。 例如,Apache 軟體基金會有一個單獨的 страница,其中指示需要什麼幫助。  

我需要編寫一個大功能才能成為提交者嗎?

不。 這完全沒有必要。 提交者不必編寫大量程式碼。 但如果你寫了一個大功能,專案管理委員會會更容易評估你。 對社群的貢獻不僅僅是功能、程式設計和測試。 如果你寫信談論一個問題,提供一個合理的解決方案——這也是一種貢獻。

重要的是要明白,承諾與信任有關。 是否讓你成為提交者是由像你這樣的人根據他們對你作為一個給產品帶來好處的人的看法來決定的。 因此,您需要透過您在社區中的行動和行為來贏得這種信任。

如何表現?

要有建設性、積極、禮貌和耐心。 請記住,在開源中,每個人都是志願者,沒有人欠任何人任何東西。 他們不會回答您 - 等待並在 3-4 天內提醒您問題。 他們並不總是回答你——好吧,開源是自願的。

如何成為一個committer,你真的需要它嗎?

不要要求別人為你或為你做某事。 經驗豐富的社區成員對這類「乞丐」有一種本能,並立即對那些想把工作推給他們的人過敏。

如果你得到幫助,那很好,但不要濫用它。 你不應該寫:“夥計們,解決這個問題,否則我將失去年度獎金。” 最好詢問您下一步應該去哪裡,並告訴我們您已經發現了有關此錯誤的內容。 而且如果你承諾根據解決問題的結果更新 wiki,那麼他們回答你的可能性就會大大增加。

最後,閱讀 行為守則 並學習 去問問題.

如果你不是committer,如何貢獻?

專案通常使用 RTC 方案,首先對所有內容進行審查,然後將變更合併到主版本中。 透過這個計劃,絕對每個人都會接受審查,甚至提交者也是如此。 因此,您無需成為提交者即可成功為專案做出貢獻。 為了更容易被選為新的提交者,您可以指導新的參與者、分享知識並創建新材料。

多元性-好處還是壞處?

多樣性—根據 Apache 軟體基金會的理解,這尤其是指由多家公司組成的開源專案參與者的從屬關係。 如果每個人都只隸屬於一個組織,那麼隨著對專案失去興趣,所有參與者都會很快逃離它。 多元化提供了長期、穩定的計畫、參與者的多元經驗和廣泛的意見。

為了愛情還是為了方便?

在開源專案中,有兩種​​類型的人:在為該產品做出貢獻的組織中工作的人,以及為愛而在這裡工作的人,即志工。 哪一個更有生產力? 通常,支援來自貢獻組織的產品的參與者。 他們只是有更多的時間和明確的動機來探究真相,他們專注於任務並更接近使用者。

那些「出於愛」而這樣做的人也有動力,但方式不同——他們渴望研究這個項目,讓世界變得更美好。 而正是這樣的參與者更穩定、更長遠,因為那些主動來到社區的人不太可能有一天離開社區。

如何在生產力和穩定性之間找到平衡? 有兩種選擇。 第一種選擇:當參與者在正式參與該開源專案的公司工作時,並出於自己的興趣在其中做一些額外的事情 - 例如,支持新人。 第二個選擇是已經進行開源轉型的公司。 例如,當員工每週四天從事主要業務專案時,其餘時間則從事開源工作。

提交者-存在還是不存在?

如何成為一個committer,你真的需要它嗎?

提交是一個很好且有用的主題,但您不應該專門努力成為提交者。 該角色不是基於程式碼的角色,並且不會展示您的知識。 唯一重要的是專業知識,也就是你透過研究專案、鑽研專案、幫助別人解決問題所獲得的知識和經驗。

來源: www.habr.com

添加評論