歡迎光臨
每天分享高質量文章

一位開源專案維護者的 5 個決心 | Linux 中國

不管怎麼說,好的交流是一個活躍的開源社區的必備品。
— Ben Cotton

 

致謝
譯自 | opensource.com 
作者 | Ben Cotton
譯者 | LCTT / HuanCheng Bai

不管怎麼說,好的交流是一個活躍的開源社區的必備品。

我通常不會定下大的新年決心。當然,我在自我提升方面沒有任何問題,這篇文章我希望錨定的是這個日曆中的另外一部分。不過即使是這樣,這裡也有一些東西要從今年的免費日曆上劃掉,並將其替換為一些可以激發我的自省的新日曆內容。

在 2017 年,我從不在社交媒體上分享我從未閱讀過的文章。我一直保持這樣的狀態,我也認為它讓我成為了一個更好的互聯網公民。對於 2019 年,我正在考慮讓我成為更好的開源軟體維護者的決心。

下麵是一些我在一些專案中擔任維護者或共同維護者時堅持的決心:

1、包含行為準則

Jono Bacon 在他的文章“7 個你可能犯的錯誤[1]”中包含了一條“不強制執行行為準則”。當然,要強制執行行為準則,你首先需要有一個行為準則。我打算預設用貢獻者契約[2],但是你可以使用其他你喜歡的。關於這個許可協議,最好的方法是使用別人已經寫好的,而不是你自己寫的。但是重要的是,要找到一些能夠定義你希望你的社區執行的,無論它們是什麼樣子。一旦這些被記錄下來並強制執行,人們就能自行決定是否成為他們想象中社區的一份子。

2、使許可證清晰且明確

你知道什麼真的很煩麽?不清晰的許可證。這個軟體基於 GPL 授權,如果沒有進一步提供更多信息的文字,我無法知道更多信息。基於哪個版本的GPL[3]?我可以用它嗎?對於專案的非代碼部分,“根據知識共享許可證(CC)授權”更糟糕。我喜歡知識共享許可證[4],但它有幾個不同的許可證包含著不同的權利和義務。因此,我將非常清楚的說明哪個許可證的變種和版本適用於我的專案。我將會在倉庫中包含許可的全文,併在其他檔案中包含簡明的註釋。

與此相關的一類問題是使用 OSI[5] 批准的許可證。想出一個新的準確的說明瞭你想要表達什麼的許可證是有可能的,但是如果你需要強制推行它,祝你好運。會堅持使用它麽?使用您專案的人會理解麽?

3、快速分類錯誤報告和問題

在技術領域, 很少有比開源維護者更貧乏的東西了。即使在小型專案中,也很難找到時間去回答每個問題並修複每個錯誤。但這並不意味著我不能哪怕回應一下,它沒必要是多段的回覆。即使只是給 GitHub 問題貼了個標簽也表明瞭我看見它了。也許我馬上就會處理它,也許一年後我會處理它。但是讓社區看到它很重要,是的,這裡還有人管。

4、如果沒有伴隨的文件,請不要推送新特性或錯誤修複

儘管多年來我的開源貢獻都圍繞著文件,但我的專案並沒有反映出我對它的重視。我能推送的提交不多,並不不需要某種形式的文件。新的特性顯然應該在他們被提交時甚至是在之前就編寫文件。但即使是錯誤修複,也應該在發行說明中有一個條目提及。如果沒有什麼意外,推送提交也是很好的改善文件的機會。

5、放棄一個專案時,要說清楚

我很不擅長對事情說“不”,我告訴編輯我會為 Opensource.com[6] 寫一到兩篇文章,而現在我有了將近 60 篇文章。哎呀。但在某些時候,曾經我有興趣的事情也會不再有興趣。也許該專案是不必要的,因為它的功能被吸收到更大的專案中;也許只是我厭倦了它。但這對社區是不公平的(並且存在潛在的危險,正如最近的 event-stream 惡意軟體註入[7]所示),會讓該專案陷入困境。維護者有權隨時離開,但他們離開時應該說清楚。

無論你是開源維護者還是貢獻者,如果你知道專案維護者應該作出的其他決心,請在評論中分享!


via: https://opensource.com/article/18/12/resolutions-open-source-project-maintainers

作者:Ben Cotton[9] 選題:lujun9972 譯者:bestony 校對:wxy

赞(0)

分享創造快樂