我通常不太热衷于新年决心。当然，我对自我提升没有意见，但我倾向于围绕日历的其他部分。即便如此，在取下今年的免费日历并换上明年的日历时，总会引发一些反思。
2017 年，我决心在阅读文章之前不在社交媒体上分享文章。我一直做得很好，并且我认为这让我成为一个更好的互联网公民。对于 2019 年，我正在考虑一些决心，让我成为一个更好的开源软件维护者。
以下是我将在我作为维护者或共同维护者的项目中努力坚持的一些决心。
1. 包含行为准则
Jono Bacon 在他的文章“你可能正在犯的 7 个错误”中包含了“不执行行为准则”。当然，要执行行为准则，你必须首先拥有行为准则。我计划默认使用贡献者公约，但你可以使用任何你喜欢的。与许可协议一样，最好使用已经写好的，而不是自己编写。但重要的是要找到一些定义你希望你的社区如何表现的东西，无论它看起来像什么。一旦它被写下来并执行，人们就可以自己决定它是否看起来像他们想要成为其中一部分的社区。
2. 使许可证清晰明确
你知道真正糟糕的是什么吗？不明确的许可证。“此软件根据 GPL 许可”没有进一步的文本并没有告诉我太多。哪个版本的 GPL？我可以选择吗？对于项目的非代码部分，“根据 Creative Commons 许可证许可”甚至更糟。我喜欢 Creative Commons 许可证，但有几种不同的许可证，其权利和义务差异很大。因此，我将非常清楚地说明哪个变体和版本的许可证适用于我的项目。我将在 repo 中包含许可证的全文，并在其他文件中包含简明扼要的说明。
与此有点相关的是使用 OSI 批准的许可证。想出一个新的许可证，确切地说出你想要说的内容是很诱人的，但是如果你需要执行它，祝你好运。它会站得住脚吗？使用你项目的人会理解它吗？
3. 快速分类错误报告和问题
在技术领域，很少有东西像开源维护者一样扩展性差。即使在小型项目中，也很难找到时间回答每个问题和修复每个错误。但这并不意味着我不能至少承认这个人。不一定需要多段回复。即使只是标记 GitHub 问题也表明我看到了它。也许我会马上处理它。也许我会一年后处理它。但重要的是让社区看到，是的，这里仍然有人。
4. 不要推送没有附带文档的功能或错误修复
尽管多年来我的开源贡献一直围绕文档展开，但我的项目并没有反映出我对它的重视。我几乎没有可以推送的提交不需要某种形式的文档。新功能显然应该在提交时（或之前！）记录在案。但即使是错误修复也应该在发行说明中添加条目。如果说还有什么，那么推送也是一个改进文档的好机会。
5. 明确说明我何时放弃一个项目
我真的很不擅长对事情说“不”。我告诉编辑我会为 Opensource.com 写一两篇文章，结果我现在已经写了将近 60 篇文章了。哎呀。但在某个时候，曾经吸引我兴趣的东西不再吸引我了。也许这个项目是不必要的，因为它的功能被更大的项目吸收了。也许我只是厌倦了它。但是将一个项目置于 limbo 状态对社区是不公平的（并且可能很危险，正如最近的 event-stream 恶意软件注入 事件所表明的那样）。维护者有权在任何时候和出于任何原因离开，但应该明确他们已经离开了。
无论你是开源维护者还是贡献者，如果你知道项目维护者应该做出的其他决议，请在评论中分享。
2 条评论