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