关于 开源贡献

是否热衷于规划事件？

为项目组织研讨会或线下分享，一如 @fzamperin 为 NodeSchool 所做的那样

为项目组织大型会议（假如它有的话）

帮助社区成员寻找合适的技术会议，且帮助有实力的成员提交演讲的拟稿

是否偏向于设计？

重新布置布局以提高项目的可用性

进行用户研究以重新组织和完善项目的导航或菜单

整理一个风格指南，以帮助项目有一致的视觉设计

创建t恤的艺术或一个新的标志，就像 hapi.js 的贡献者那样

你是否热衷于写作？

撰写和改进项目的文档

能够以实例来展示项目该如何使用的

为项目撰写教程

翻译项目的文档为本土语言

---

假如你之前从来都没有为开源做过贡献的话，那么请记住来自美国总统约翰 F.肯尼迪的这段话：“不要问你的国家能为你做什么，要问你能为国家做什么。”

开源项目的方方面面都需要贡献者，你先不要通盘考虑你的第一个贡献会是什么，或者是它看起来如何。

相反，从你已经使用到的或者打算用到的项目开启贡献之路，在你积极的贡献过程中，项目也会反馈给你，让你更好的定位自己。

一旦进入某项目，不论何时，你都要听从自己的直觉，做你认为更好或者不同的事情。

开源并不是高级俱乐部；它就是由你这样的人所浇铸和打造。“开源”只是针对这个世界的需要修复的问题的一个梦幻术语罢了。

你或许在查看 README 的时候，发现了损坏的链接，又或者拼写错误。又或者是你是一名新手，使用的过程中发现了问题，又或者是某问题应该在文档中注明。请不要坐视不理，径直绕开，或者是请求他人修复，伸出你的援助之手，解决这些你能看到的问题。而这正是开源的精髓之所在！

28% 的随意贡献 就是说明了文档的开源，诸如拼写错误，段落语句调整、或者是翻译。

---

创建 issue

你应该在遇到下列情况下，去创建一个 issue：

1.报告你自己无法解决的错误
2.讨论一个高级主题或想法(例如. 社区、远景、政策等)
3.期望实现某新的特性，或者其它项目的想法
4.在 issue 的沟通中几点实用的技巧:

如果你创建了一个 issue，但是没多久自己解决了， 也要添加评论，让其他人知道，然后关闭该 issue。记录本身就是为社区的贡献。

---

创建 pull request

在下面的情形时，请你务必使用PR：

提交补丁 (例如，纠正拼写错误、损坏的链接、或者是其它较明显的错误）

开始一项别人请求的任务，或者是过去在 issue 中早就讨论过的

一个 PR 并不代表着工作已经完成。它通常是尽早的开启一个 PR，是为了其他人可以观看或者给作者反馈意见。只需要在子标题标记为”WIP”（正在进行中）。作者可以在后面添加很多评论。

---

在你提交了贡献之后，下面几种情形是可能发生的：

😭 没有人响应你。

希望你确认在开始工作之前检查过了项目的活跃度。不过，即使在一个活跃的项目中，你的贡献也有可能得不到响应。

如果过去了一周，依旧没有人响应，请心平气和的在后面跟帖，询求他人帮助你审核。如果你熟悉某个人可以审核你的贡献，你可以使用@+名字，直接提醒他一下。

千万不要 私下里去联系他人；一定要记住，开源项目所有的沟通都应该是公开的。

如果你做了所有该做的事情，还是没有人理你，那就是真的没有人对你的贡献做出响应。这可能令人难受，但是千万不要灰心，每个人都会遇到这样的情况。你没有得到回复的原因有很多，包括你无法控制的个人情况。再接再厉，试着寻找另一个项目或方式来做出贡献。

🚧 有人要求你对自己的提交做出变更。

被要求修改你的提交是很常见的，无论是对你的想法的反馈，还是对你代码的改动。

当有人提出变更时，请及时响应。他们花时间审核了你的提交，要尊重他们。开启 PR 然后一走了之是一种恶习。如果你不知道如何修改，请花时间深入研究，并在需要时寻求他人帮助。

如果你没有时间继续处理这个 issue（举例来说，如果对话持续了几个月，而你情况有变），那么请告知维护者(QQ 2530665121)你无法再及时响应了。或许有其他人乐意接手你的工作

👎 你的贡献没有被接受。

你的贡献最终可能被接受，也可能不被接受。真心希望你没有为此花费太多力气。如果你不确定为什么它不被接受，请维护者提供反馈和说明是完全合理的。但最终，无论如何，你都要对他们的决定表示尊重。不要去无谓的争论或者显露敌意。如果你坚持自己，你仍可以 fork 项目，按照自己的思路来发展分支。

🎉 你的贡献被采纳。

太棒了！你已经成功地完成了一次开源贡献！

---