mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-13 22:30:37 +08:00
Vic Yu
GitHub
commit
1957d00a03
@ -1,64 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (bestony)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (5 resolutions for open source project maintainers)
|
||||
[#]: via: (https://opensource.com/article/18/12/resolutions-open-source-project-maintainers)
|
||||
[#]: author: (Ben Cotton https://opensource.com/users/bcotton)
|
||||
|
||||
5 resolutions for open source project maintainers
|
||||
======
|
||||
No matter how you say it, good communication is essential to strong open source communities.
|
||||
|
||||
|
||||
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][1]." Of course, to enforce a code of conduct, you must first have a code of conduct. I plan on defaulting to the [Contributor Covenant][2], 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][3]? 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][4], 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][5]-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][6] 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][7] 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.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/12/resolutions-open-source-project-maintainers
|
||||
|
||||
作者：[Ben Cotton][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/bcotton
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/article/17/8/mistakes-open-source-avoid
|
||||
[2]: https://www.contributor-covenant.org/
|
||||
[3]: https://opensource.org/licenses/gpl-license
|
||||
[4]: https://creativecommons.org/share-your-work/licensing-types-examples/
|
||||
[5]: https://opensource.org/
|
||||
[6]: http://Opensource.com
|
||||
[7]: https://arstechnica.com/information-technology/2018/11/hacker-backdoors-widely-used-open-source-software-to-steal-bitcoin/
|
||||
@ -0,0 +1,70 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (bestony)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (5 resolutions for open source project maintainers)
|
||||
[#]: via: (https://opensource.com/article/18/12/resolutions-open-source-project-maintainers)
|
||||
[#]: author: (Ben Cotton https://opensource.com/users/bcotton)
|
||||
|
||||
5个为开源项目维护者而生的解决方案
|
||||
======
|
||||
|
||||
不管你怎么说，好的交流是一个活跃的开源社区的必备品。
|
||||
|
||||
|
||||
|
||||
我不会给你一个大而全的新年的解决方案。关于自我提升，我没有任何问题，这篇文章我希望锚定这个日历中的另外一部分。不过即使是这样，这里也有一些关于取消今年的免费日历并将其替换为新的日历的内容，以激发自省。
|
||||
|
||||
在 2017 年，我从不在社交媒体上分享我从未阅读过的文章。我一直保持这样的状态，我也认为它让我成为了一个更好的互联网公民。对于 2019 年，我正在考虑让我成为更好的开源软件维护者的解决方案。
|
||||
|
||||
|
||||
下面是一些我在一些项目中担任维护者或共同维护者时坚持的决议：
|
||||
|
||||
### 1\. 包含行为准则
|
||||
|
||||
Jono Bacon 在他的文章“[7个你可能犯的错误][1]”中包含了“不强制执行行为准则”。当然，去强制执行行为准则，你首先需要有一个行为准则。我设计了一个默认的[贡献者契约][2],但是你可以使用其他你喜欢的。关于这个 License ，最好的方法是使用别人已经写好的，而不是你自己写的。但是重要的是，要找到一些能够定义你希望你的社区执行的，无论他们是什么样子。一旦这些被记录下来并强制执行，人们就能自行决定是否成为他们想象中社区的一份子。
|
||||
|
||||
|
||||
### 2\. 使许可证清晰且明确
|
||||
|
||||
你知道什么真的很烦么？不清晰的许可证。"这个软件基于 GPL 授权"，如果没有进一步提供更多信息的文字，我无法知道更多信息。基于哪个版本的[GPL][3]?对于项目的非代码部分，“根据知识共享许可证授权”更糟糕。我喜欢[知识共享许可证][4]，但其中有几个不同的许可证包含着不同的权利和义务。因此，我将清楚的说明许可证的版本适用于我的项目。我将会在 repo 中包含许可的全文，并在其他文件中包含简明的注释。
|
||||
|
||||
与此相关的一类是使用 [OSI][5]批准的许可证。想出一个新的准确的说明了你想要表达什么的许可证是有可能的，但是如果你需要强制执行它，祝你好运。会坚持使用它么？使用您项目的人会理解么？
|
||||
|
||||
|
||||
|
||||
### 3\. 快速分类错误报告和问题
|
||||
|
||||
技术的规模很难会和开源维护者一样差。即使在小型项目中，也很难找到时间去回答每个问题并修复每个错误。但这并不意味着我至少不能去回应这个人，它没必要是多段的回复。即使只是标记了 Github Issue 也表明了我看见它了。也许我马上就会处理它，也许一年后我会处理它。但是让社区看到它很重要。是的，这里还有其他人。
|
||||
|
||||
### 4\. 如果没有伴随的文档，请不要推送新特性或 Bugfix
|
||||
|
||||
尽管多年来我的开源贡献都围绕着文档，但我的项目并没有反映出我对他们的重视。我很少有不需要某种形式文档的推送。新的特性显然应该在他们被提交甚至是之前编写文档。但即使是错误修复，也应该在发行说明中有一个条目。如果没有什么其他的，一个 push 也是很好的改善文档的机会。
|
||||
|
||||
### 5\. 放弃一个项目时，要说清楚
|
||||
|
||||
我很擅长对事情说“不”，我告诉编辑我会为 [Opensource.com][6] 写一到两篇文章，现在我有了将近 60 篇文章。Oops。但在某些时候，曾经符合我利益的事情不再有用。也许该项目是不必要的，因为它的功能被吸收到更大的项目中，也许只是我厌倦了它。但这对社区是不公平的（并且存在潜在的危险，正如最近的[event-stream 恶意软件注入][7]所示），会让项目陷入困境。维护者有权随时离开，但他们离开时应该清清楚楚。
|
||||
|
||||
无论你是开源维护者还是贡献者，如果你知道项目维护者应该作出的其他决议，请在评论中分享！
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/12/resolutions-open-source-project-maintainers
|
||||
|
||||
作者：[Ben Cotton][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[bestony](https://github.com/bestony)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/bcotton
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/article/17/8/mistakes-open-source-avoid
|
||||
[2]: https://www.contributor-covenant.org/
|
||||
[3]: https://opensource.org/licenses/gpl-license
|
||||
[4]: https://creativecommons.org/share-your-work/licensing-types-examples/
|
||||
[5]: https://opensource.org/
|
||||
[6]: http://Opensource.com
|
||||
[7]: https://arstechnica.com/information-technology/2018/11/hacker-backdoors-widely-used-open-source-software-to-steal-bitcoin/
|
||||
Loading…
Reference in New Issue
Block a user