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

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

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

在 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