一位開源項目維護者的 5 個決心

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

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

下面是一些我在一些項目中擔任維護者或共同維護者時堅持的決心：

1、包含行為準則

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

2、使許可證清晰且明確

你知道什麼真的很煩么？不清晰的許可證。這個軟體基於 GPL 授權，如果沒有進一步提供更多信息的文字，我無法知道更多信息。基於哪個版本的GPL？我可以用它嗎？對於項目的非代碼部分，「根據知識共享許可證（CC）授權」更糟糕。我喜歡知識共享許可證，但它有幾個不同的許可證包含著不同的權利和義務。因此，我將非常清楚的說明哪個許可證的變種和版本適用於我的項目。我將會在倉庫中包含許可的全文，並在其他文件中包含簡明的注釋。

與此相關的一類問題是使用 OSI 批准的許可證。想出一個新的準確的說明了你想要表達什麼的許可證是有可能的，但是如果你需要強制推行它，祝你好運。會堅持使用它么？使用您項目的人會理解么？

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

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

4、如果沒有伴隨的文檔，請不要推送新特性或錯誤修復

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

5、放棄一個項目時，要說清楚

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

無論你是開源維護者還是貢獻者，如果你知道項目維護者應該作出的其他決心，請在評論中分享！

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

作者：Ben Cotton 選題：lujun9972 譯者：bestony 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive