一位开源项目维护者的 5 个决心
开源 贡献者

> 
> 不管怎么说，好的交流是一个活跃的开源社区的必备品。
> 
> 
> 


![](/data/attachment/album/201901/16/093920o0m0zi1ki1kxukg0.png)


我通常不会定下大的新年决心。当然，我在自我提升方面没有任何问题，这篇文章我希望锚定的是这个日历中的另外一部分。不过即使是这样，这里也有一些东西要从今年的免费日历上划掉，并将其替换为一些可以激发我的自省的新日历内容。


在 2017 年，我从不在社交媒体上分享我从未阅读过的文章。我一直保持这样的状态，我也认为它让我成为了一个更好的互联网公民。对于 2019 年，我正在考虑让我成为更好的开源软件维护者的决心。


下面是一些我在一些项目中担任维护者或共同维护者时坚持的决心：


### 1、包含行为准则


Jono Bacon 在他的文章“[7 个你可能犯的错误](https://opensource.com/article/17/8/mistakes-open-source-avoid)”中包含了一条“不强制执行行为准则”。当然，要强制执行行为准则，你首先需要有一个行为准则。我打算默认用[贡献者契约](https://www.contributor-covenant.org/)，但是你可以使用其他你喜欢的。关于这个许可协议，最好的方法是使用别人已经写好的，而不是你自己写的。但是重要的是，要找到一些能够定义你希望你的社区执行的，无论它们是什么样子。一旦这些被记录下来并强制执行，人们就能自行决定是否成为他们想象中社区的一份子。


### 2、使许可证清晰且明确


你知道什么真的很烦么？不清晰的许可证。这个软件基于 GPL 授权，如果没有进一步提供更多信息的文字，我无法知道更多信息。基于哪个版本的[GPL](https://opensource.org/licenses/gpl-license)？我可以用它吗？对于项目的非代码部分，“根据知识共享许可证（CC）授权”更糟糕。我喜欢[知识共享许可证](https://creativecommons.org/share-your-work/licensing-types-examples/)，但它有几个不同的许可证包含着不同的权利和义务。因此，我将非常清楚的说明哪个许可证的变种和版本适用于我的项目。我将会在仓库中包含许可的全文，并在其他文件中包含简明的注释。


与此相关的一类问题是使用 [OSI](https://opensource.org/) 批准的许可证。想出一个新的准确的说明了你想要表达什么的许可证是有可能的，但是如果你需要强制推行它，祝你好运。会坚持使用它么？使用您项目的人会理解么？


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


在技术领域, 很少有比开源维护者更贫乏的东西了。即使在小型项目中，也很难找到时间去回答每个问题并修复每个错误。但这并不意味着我不能哪怕回应一下，它没必要是多段的回复。即使只是给 GitHub 问题贴了个标签也表明了我看见它了。也许我马上就会处理它，也许一年后我会处理它。但是让社区看到它很重要，是的，这里还有人管。


### 4、如果没有伴随的文档，请不要推送新特性或错误修复


尽管多年来我的开源贡献都围绕着文档，但我的项目并没有反映出我对它的重视。我能推送的提交不多，并不不需要某种形式的文档。新的特性显然应该在他们被提交时甚至是在之前就编写文档。但即使是错误修复，也应该在发行说明中有一个条目提及。如果没有什么意外，推送提交也是很好的改善文档的机会。


### 5、放弃一个项目时，要说清楚


我很不擅长对事情说“不”，我告诉编辑我会为 [Opensource.com](http://Opensource.com) 写一到两篇文章，而现在我有了将近 60 篇文章。哎呀。但在某些时候，曾经我有兴趣的事情也会不再有兴趣。也许该项目是不必要的，因为它的功能被吸收到更大的项目中；也许只是我厌倦了它。但这对社区是不公平的（并且存在潜在的危险，正如最近的 [event-stream 恶意软件注入](https://arstechnica.com/information-technology/2018/11/hacker-backdoors-widely-used-open-source-software-to-steal-bitcoin/)所示），会让该项目陷入困境。维护者有权随时离开，但他们离开时应该说清楚。


无论你是开源维护者还是贡献者，如果你知道项目维护者应该作出的其他决心，请在评论中分享！




---


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


作者：[Ben Cotton](https://opensource.com/users/bcotton) 选题：[lujun9972](https://github.com/lujun9972) 译者：[bestony](https://github.com/bestony) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
I'm generally not big on New Year's resolutions. I have no problem with self-improvement, of course, but I tend to anchor around other parts of the calendar. Even so, there's something about taking down this year's free calendar and replacing it with next year's that inspires some introspection.

In 2017, I resolved to not share articles on social media until I'd read them. I've kept to that pretty well, and I'd like to think it has made me a better citizen of the internet. For 2019, I'm thinking about resolutions to make me a better open source software maintainer.

Here are some resolutions I'll try to stick to on the projects where I'm a maintainer or co-maintainer.

## 1. Include a code of conduct

Jono Bacon included "not enforcing the code of conduct" in his article "[7 mistakes you're probably making](https://opensource.com/article/17/8/mistakes-open-source-avoid)." Of course, to *enforce* a code of conduct, you must first *have* a code of conduct. I plan on defaulting to the [Contributor Covenant](https://www.contributor-covenant.org/), but you can use whatever you like. As with licenses, it's probably best to use one that's already written instead of writing your own. But the important thing is to find something that defines how you want your community to behave, whatever that looks like. Once it's written down and enforced, people can decide for themselves if it looks like the kind of community they want to be a part of.

## 2. Make the license clear and specific

You know what really stinks? Unclear licenses. "This software is licensed under the GPL" with no further text doesn't tell me much. Which version of the [GPL](https://opensource.org/licenses/gpl-license)? Do I get to pick? For non-code portions of a project, "licensed under a Creative Commons license" is even worse. I love the [Creative Commons licenses](https://creativecommons.org/share-your-work/licensing-types-examples/), but there are several different licenses with significantly different rights and obligations. So, I will make it very clear which variant and version of a license applies to my projects. I will include the full text of the license in the repo and a concise note in the other files.

Sort of related to this is using an [OSI](https://opensource.org/)-approved license. It's tempting to come up with a new license that says exactly what you want it to say, but good luck if you ever need to enforce it. Will it hold up? Will the people using your project understand it?

## 3. Triage bug reports and questions quickly


Few things in technology scale as poorly as open source maintainers. Even on small projects, it can be hard to find the time to answer every question and fix every bug. But that doesn't mean I can't at least acknowledge the person. It doesn't have to be a multi-paragraph reply. Even just labeling the GitHub issue shows that I saw it. Maybe I'll get to it right away. Maybe I'll get to it a year later. But it's important for the community to see that, yes, there is still someone here.

## 4. Don't push features or bug fixes without accompanying documentation

For as much as my open source contributions over the years have revolved around documentation, my projects don't reflect the importance I put on it. There aren't many commits I can push that don't require some form of documentation. New features should obviously be documented at (or before!) the time they're committed. But even bug fixes should get an entry in the release notes. If nothing else, a push is a good opportunity to also make a commit to improving the docs.

## 5. Make it clear when I'm abandoning a project

I'm really bad at saying "no" to things. I told the editors I'd write one or two articles for [Opensource.com](http://Opensource.com) and here I am almost 60 articles later. Oops. But at some point, the things that once held my interests no longer do. Maybe the project is unnecessary because its functionality got absorbed into a larger project. Maybe I'm just tired of it. But it's unfair to the community (and potentially dangerous, as the recent [event-stream malware injection](https://arstechnica.com/information-technology/2018/11/hacker-backdoors-widely-used-open-source-software-to-steal-bitcoin/) showed) to leave a project in limbo. Maintainers have the right to walk away whenever and for whatever reason, but it should be clear that they have.

Whether you're an open source maintainer or contributor, if you know other resolutions project maintainers should make, please share them in the comments.

## 2 Comments