开源解决方案_开源项目维护者的5种解决方案

开源解决方案

我通常对新年的决议不太感兴趣。 当然，我没有自我完善的问题，但是我倾向于锚定日历的其他部分。 即便如此，仍有一些事情需要取消今年的免费日历并将其替换为明年的日历，这激发了一些内省。

在2017年，我决定不阅读社交媒体上的文章。 我一直坚持的很好，我想认为这使我成为了一个更好的互联网公民。 对于2019年，我正在考虑使我成为更好的开源软件维护者的解决方案。

在我是维护者或联合维护者的项目中，我将尝试遵循以下一些解决方案。

1.包含行为准则

乔诺·培根（Jono Bacon）在他的文章“ 您可能犯的7个错误 ”中包括“不执行行为准则”。 当然， 执行的行为准则，你必须先有行为准则。 我计划默认使用Contributor Covenant ，但是您可以使用任何您喜欢的东西。 与许可证一样，最好使用已经编写的许可证而不是自己编写许可证。 但是重要的是要找到定义您希望社区行为方式的内容。 写下并执行后，人们可以自己决定是否看起来像他们想加入的社区类型。

2.使许可证清晰明确

你知道什么真的很臭吗？ 许可证不明确。 “该软件是根据GPL许可的”，没有进一步的文字说明的内容并不多。 哪个版本的GPL ？ 我可以选择吗？ 对于项目的非代码部分，“获得知识共享许可的许可”更为糟糕。 我喜欢知识共享许可 ，但是有几种不同的许可，它们的权利和义务有很大不同。 因此，我将很清楚地说明哪种许可证的变体和版本适用于我的项目。 我将在回购中包含许可证的全文，并在其他文件中包含简明注释。

与此相关的某种程度是使用OSI批准的许可证。 诱使人们想出一个新许可证，该许可证确切说明了您想要说的话，但是如果您需要执行它，那就很幸运。 会坚持吗？ 使用您的项目的人会理解吗？

3.快速分类错误报告和问题

4.在没有随附文档的情况下，请勿推送功能或错误修复

多年来，尽管我的开源贡献主要围绕文档，但我的项目并没有反映出我对它的重视。 我可以提交的提交很多，不需要任何形式的文档。 新功能显然应在提交时（或之前！）记录在案。 但是，即使是错误修复，也应该在发行说明中获得条目。 如果没有其他问题，那么推动也是一个致力于改进文档的好机会。

5.放弃项目时要清楚

我真的很不好意思对事情说“不”。 我告诉编辑们，我会为Opensource.com写一两篇文章，而在这里我差不多要写60篇文章。 哎呀。 但是在某些时候，曾经让我感兴趣的事情不再有效。 也许该项目是不必要的，因为其功能已被更大的项目吸收。 也许我只是厌倦了。 但这对社区不公平（如最近的事件流恶意软件注入所示，这很危险），使项目陷入困境。 维护者有权因任何原因而随时随地走开，但应该清楚的是，他们拥有。

---

无论您是开源维护者还是贡献者，如果您知道项目维护者应制定的其他解决方案，请在评论中分享。

翻译自: https://opensource.com/article/18/12/resolutions-open-source-project-maintainers

开源解决方案