学习资料：开源软件指南（Open Source Guides，GitHub：XNoteW/opensource.guide）
为什么会有人为开源做贡献？
为开源贡献力量，得到的回报就是能够学习到很多、受教很多、且能够锻炼任何你能够想到的经验。
巩固现有技能
无论是撰写代码、设计用户界面、图形设计、撰写文档、亦或是组织活动，假如你有实践的愿望，你总能在开源项目中找到自己的位置。
遇见那些和你”臭味相投”的人
开源项目一般都会有一个和谐、热心的社区，以让大家团结一致。实际上，开源界经常发生这样的情形，很多人的深厚友谊都是通过共同参与开源所建立起来的，至于具体的方式，可能是在一次技术研讨会上相谈甚欢，也可能是一直在聊天室中探讨问题。
寻找导师，并且尝试帮助他人
和他人共同在一个共享的项目下工作，这意味着需要向他人解释清楚自己是如何做的，同理，也需要向他人求助，询问别人是如何做的。相互学习和彼此教学对于每位参与者都能满载而归。
在公众间建立你的声誉（职业口碑）
根据开源的定义，你在开源下所有的工作都是公开的，这也就意味着开源项目是一个很好展示你实力的地方。
学习领导和管理的艺术
开源为实践领导力和管理技能提供了很好的机会，比如解决冲突、组织团队、工作的优先级排列。
鼓励作出改变，哪怕改变是很微小的
在开源的世界里，作出贡献的不一定非得是花了很长时间拥有大量经验的人。你是否遇到过浏览某些网站发现有拼写错误，希望有人能修改它？其实，在开源的项目中，你只需要做就可以了。没有那么多的顾忌，开源让人们在很舒服的状态做事，而这才是这个世界应有的体验。
开源贡献意味着什么？
如果你是一名开源界的新手，可能会对贡献的流程心生畏惧。比如：该如何找到正确的项目？不懂编码又想参与怎么办？万一做错事情了怎么办？
你不需要具备编码的能力
对于为开源做贡献常见的误解就是：为开源做贡献必须得提交代码。事实上，代码固然重要，但是项目中不需编码的重要部分经常被忽视。你若做了这部分，对于项目来说可是莫大的贡献，而这根本就不需要什么撰写代码！
即使你是一位开发者，非代码的贡献对于项目来说也是举足轻重的，尤其是对于社区的其他成员来说。用心维系这些关系能够让你有到项目的其它部分的工作机会。
是否热衷于规划事件？
- 为项目组织研讨会或线下分享，一如 @fzamperin 为 NodeSchool 所做的那样
- 为项目组织大型会议（假如它有的话）
- 帮助社区成员寻找合适的技术会议，且帮助有实力的成员提交演讲的拟稿
是否偏向于设计？
- 重新布置布局以提高项目的可用性
- 进行用户研究以重新组织和完善项目的导航或菜单
- 整理一个风格指南，以帮助项目有一致的视觉设计
- 创建 t 恤的艺术或一个新的标志，就像 hapi.js 的贡献者那样
你是否热衷于写作？
- 撰写和改进项目的文档
- 能够以实例来展示项目该如何使用的
- 为项目撰写新闻稿，或者到邮件列表高调布道
- 为项目撰写教程，一如 pypa 的贡献者所做的
- 翻译项目的文档为本土语言
你喜欢组织活动吗？
- 链接重复的问题，并建议新的问题标签，使事物井井有条
- 通过开放的问题，并建议关闭旧的，就像 @nzakas 为 eslint 做的
- 把最近开放的问题阐述清晰，以推动讨论
享受编码的乐趣？
- 找到一个开放的问题并解决它，就像 @dianjin 为 Leaflet 做的
- 想一想你是否可以帮忙写一个新的功能
- 自动化项目设置
- 改进工具和测试
热衷于帮助他人？
- 回答关于项目的问题，例如在 Stack Overflow（像 Postgres 的这个示例）或者 reddit 上
- 为人们解答公开的问题
- 帮助缓和讨论板或对话渠道
在编码方面是否喜欢帮助他人？
- 为他人的提交审核代码
- 为如何利用项目撰写教程
- 为其他贡献者做导师，正如 @ereichert 为 @bronzdoc 所做的那样，哦，是 Rust 项目
其实不必一定是软件项目！
尽管人们一提起”开源”二字，默认就是指开源软件，其实不尽然，开源可以是任何事情的修饰，而不仅仅是指软件而言的。比如图书、食谱、列表、以及任何可以开源的项目类。
举例来说：
- @sindresorhus 创建了 “惊奇” 列表
- @h5bp 维护了针对前端开发者的面试题
- @stuartlynn 和 @nicole-a-tesla 制作了收集关于海雀的有趣的事实
尽管你是一名软件开发者，也可以去撰写一些文档去帮助新的入门者。其实项目中那些看起来令人生畏的项目并不是写代码，做开发者总得挑战自己，其实在做得过程中可以增强信心和获得全新的体验。
分析感兴趣的开源项目
每一个开源社区都是不一样的。
在某一个开源项目扎根多年，这意味着你只是对这一个开源项目无比的熟悉。若是切换到不同的项目，可能会发现完全是另外一回事，所谓的使用词汇、习惯用语、沟通方式都发生了变化。
然而，很多的开源项目还是遵循相似的组织结构的。理解不同的社区角色和全部的流程，可以很好的帮助你快速的切入新的项目。
一个典型的开源项目均会有如下类型的人：
- 作者: 项目的创始人或创始组织
- 归属者: 代码仓库或组织的管理员（不一定和作者是同一个人）
- 维护者: 贡献者，负责项目的未来走向和组织的管理（他们通常也是项目的作者或归属者。）
- 贡献者: 只要是为项目做出了贡献，就算。
- 社区成员: 那些使用项目的人们。他们或许是积极的讨论者，又或者是为项目的方向提出意见的人。
一个较大的项目，可能下面还会细分子社区，或者是针对不同的任务分成不同的小组，比如工具小组、分流、社区事务、以及活动组织等。径直到项目到 web 站点，找到”团队”页面，或者是查看治理文档，从而获得类似到信息。
靠谱的开源项目，一般都会有文档的，这些文档文件通常会在代码仓库的顶级目录列出。
- LICENSE: 根据开源软件的定义，每一个开源项目必须是有开源许可协议的. 可以这么认为：假如说某个项目源码开放，但是没有任何的许可协议，那么它就不能叫做开源。
- README: README 是一个介绍性的说明文件，对初次光临社区的人们表示欢迎，它通常会解释项目有何用处，为何发起，以及如何快速入门等。
- CONTRIBUTING: READMEs 帮助人们来认识项目，CONTRIBUTING 这个文件则是帮助对项目如何做贡献。它解释了目前项目需要什么样类型对贡献者，社区的流程是什么样的。并非所有的项目都会有这个文件，它某种程度上也是展示项目对于贡献者的友好程度。
- CODE_OF_CONDUCT: 顾名思义，即是一些参与社区时的一些礼仪、说话方式、行为等，帮助形成一种友好的氛围，不是所有的项目都会撰写行为准则文件，它某种程度上也是展示项目对于贡献者的友好程度。
- 其它文档: 有些项目也许还有其它文档，例如教程、导游，或者是治理规则，这在大型项目中常见。
此外，开源项目还会利用如下一些工具来进行组织讨论，阅读这些归档对于理解社区的想法、是如何工作的有非常大的作用。
- 问题追踪:（Issue tracker） 这里是人们讨论项目相关问题的地方。
- Pull requests: 审核代码、以及相关的问题讨论。
- 论坛或邮件列表: 一些项目会实用会话式的主题（例如 “How do I…“ 或 “What do you think about…“ 来替代 Bug 报告或特性请求）。然而有一些项目关于讨论全部实用问题追踪。
- 即时在线聊天: 有一些项目会实用聊天频道（诸如 Slack 或 IRC），从而能够随意的谈话、协作和快速交流
找一个合适的项目做贡献
你也可以利用如下列出的资源来找到合适的新项目：
在你贡献之前需要一份检查列表
当你找到了你打算贡献的项目时，在进一步行动之前，作一个快速的扫描工作，以确保项目是否接受贡献的。否则，你煞费苦心的工作可能没有任何的回报。
这是一个简易的检查表，用来评估一个项目是否适合新的贡献者。
符合开源的定义
- 有许可协议吗？通常情况下，会在根目录有一个叫做
LICENSE的文件。
项目被接收的提交活跃度
在主干上确认提交的活跃度。在 GitHub 上托管的开源项目，你可以在仓库主页上看到这些信息。
最后一次提交是在什么时候？
项目目前有多少贡献者？
人们提交的频繁吗？ (在 GitHub，可以在顶栏里点击"commits"来展现。）
接下来，就是看项目的 issue 数量。
目前有多少个还处于开放状态的 issue？
项目的维护者对于处于开放状态的 issue 响应是否迅速？
是否有讨论很活跃的 issue？
issue 均是近期产生的吗？
有没有关闭的issue？ (在 GitHub, 点击 "closed" 标签就可以看到所有已经关闭的 issue。)
同样再来看看 PR 的情形。
现下有多少处于开放状态的 PR？
当提交了 PR 后，维护者响应是否迅速？
是否有活跃讨论的 PR？
均是近期的 RP 吗？
最近有多少 PR 合并？ (在 GitHub, 点击 RP 页面的 "closed" 的标签页来查看已经关闭的标签页。)
项目的受欢迎程度
一个项目的友好程度和受欢迎意味着更能吸引新的贡献者。
在 issue 的问题中，维护者的回答是否非常有帮助？
人们在 issue 的讨论中、在线聊天室、论坛是否很友好？
PR 是否被 review？
维护者是否对做贡献的人们道声"谢谢"？
如何提交贡献
你已经找到了你喜爱的项目，也已准备好贡献了，迫不及待、跃跃欲试了。好吧！以下就是带领你如何以正确的姿势作贡献。
有效沟通
无论你处于什么样的目的：仅仅是一次性的贡献，亦或是永久性的加入社区，都的和他人进行沟通和交往，这是你要在开源圈发展必须修炼的技能。
[作为一名新手,] 我很快的就意识到，我若是要关闭一条 issue 时，我不得不问更多的问题。我浏览了代码库，一旦我觉得有什么问题的时候，我就得需要更多的指点，瞧！ 在我得到所有的所需要的信息后，我就可以解决这个问题！
— @shubheksha, 一名菜鸟进入开源世界的坎坷之旅
在你开启一个 issue 或 PR 之前，或者是在聊天室问问题之前，请牢记下面所列出的几点建议，会让你的工作更加的高效。
给出上下文 以便于让其他人能够快速的理解。比方说你运行程序时遇到一个错误，要解释你是如何做的，并描述如何才能再现错误现象。又比方说你是提交一个新的想法，要解释你为什么这么想，对于项目有用处吗（不仅仅是只有你！）
😇 “当我做 Y 的时候 X 不能工作”
😢 “X 出问题! 请修复它。”
在进一步行动前，做好准备工作。 不知道没关系，但是要展现你尝试过、努力过。在寻求帮助之前，请确认阅读了项目的 README、文档、问题（开放的和关闭的）、邮件列表，并搜索了网络。当你表现出很强烈的求知欲的时候，人们是非常欣赏这点的，会很乐意的帮助你。
😇 “我不确定 X 是如何实现的，我查阅了相关的帮助文档，然而毫无所获。”
😢 “我该怎么做 X ?”
保持请求内容短小而直接。 正如发送一份邮件，每一次的贡献，无论是多么的简单，都是需要他人去查阅的。很多项目都是请求的人多，提供帮助的人少。相信我，保持简洁，你能得到他人帮助的机会会大大的增加。
😇 “我很乐意写 API 的教程。”
😢 ” 有一天我驾驶汽车行驶在高速公路上，在某个加油站加油的时候，突发奇想，我们应该这么做，不过在我进一步解释之前，我先和大家展示一下。。。”
让所有的沟通都是在公开场合下进行。 哪怕是很不起眼的小事，也不要去给维护者发私信，除非是你要分享一些敏感信息（诸如安全问题或严重的过失）。你若能够保持谈话是公开的，很多人可以你们交换的意见中学习和受益。
😇 (评论) “@维护者 你好！我们该如何处理这个 PR？”
😢 (邮件) “你好，非常抱歉给发信，但是我实在很希望你能看一下我提交的 PR。”
大胆的提问（但是要谨慎！）。 每个人参与社区，开始的时候都是新手，哪怕是非常有经验的贡献者也一样，在刚进入一个新的项目的时候，也是新手。出于同样的原因,甚至长期维护人员并不总是熟悉一个项目的每一部分。给他们同样的耐心，你也会得到同样的回报。
😇 “感谢查看了这个错误，我按照您的建议做了，这是输出结果。”
😢 “你为什么不修复我的问题？这难道不是你的项目吗？”
尊重社区的决定。 你的想法可能会和社区的优先级、愿景等有差异，他们可能对于你的想法提供了反馈和最后的决定的理由，这时你应该去积极的讨论，并寻求妥协的办法，维护者必须慎重的考虑你的想法。但是如果你实在是不能同意社区的做法，你可以坚持自己！保持自己的分支，或者另起炉灶。
😇 “你不能支持我的用例，我蛮失望，但是你的解释仅仅是对一小部分用户起作用，我理解是为什么。感谢你的耐心倾听。”
😢 “你为什么不支持我的用例？这是不可接受的！”
最重要的是，保持优雅 开源社区有来自世界各地的协作者，所以跨语言、文化、地理位置和时区的情况下会丢失上下文语境。另外，书面交流使得传达语气或情绪变得更加困难。对话过程中善意的理解对方的意图。礼貌地反驳他人的想法，询问更多的上下文语境，或进一步澄清你的立场都是好事。我们要让互联网变得更加美好。
收集上下文
在正式开始之前，做一些快速的检查项，以确保你的想法是没有被讨论过的。遍历项目的 README、问题（开放的和关闭的都算）、邮件列表、Stack Overflow。毋需去花好几个小时去全部折腾一遍，但是使用几个关键的词汇来搜索一下是必要的。
如果你没有找到和你想法一样的内容，你就可以继续了。如果项目是在 GitHub 上的话，你可以通过开启一个 issue 或 PR：
- Issues 开启一次对话或讨论
- Pull requests 请求接受自己的解决方法
- 少量的沟通， 诸如澄清或how-to的问题，尝试到 Stack Overflow、IRC、Slack 或其它聊天频道。
在你创建 issue 和 PR 之前，请检查项目的贡献者文档（文件名通常叫做 CONTRIBUTING，或者就直接包含在README中），找一些你需要的较具体的东西，例如，他们会要求你遵循某个模版，或者是要求你使用某个测试。
如果你做的是一个非常实际的贡献，在正式开启之前，先创建一个 issue。监视项目是很有帮助的（在 GitHub，点击 “Watch”，所有的对话都会通知到你），要让社区的成员们知道你要做的工作，免得你做了之后，再让他们知道，他们不同意，就浪费了。
创建 issue
你应该在遇到下列情况下，去创建一个 issue：
- 报告你自己无法解决的错误
- 讨论一个高级主题或想法(例如. 社区、远景、政策等)
- 期望实现某新的特性，或者其它项目的想法
在 issue 的沟通中几点实用的技巧:
- 如果你刚好看到一个开放的 issue，恰是你打算解决的， 添加评论，告诉他人你将负责这个。这样的话，可以避免他人重复劳动。
- 如果说某个 issue 已经开放很久了， 这可能是已经有人正在解决中，又或者是早已经解决过了，所以也请添加评论，在打算开启工作之前，最好是确认一下。
- 如果你创建了一个 issue，但是没多久自己解决了， 也要添加评论，让其他人知道，然后关闭该 issue。记录本身就是为社区的贡献。
创建 pull request
在下面的情形时，请你务必使用PR：
- 提交补丁 (例如，纠正拼写错误、损坏的链接、或者是其它较明显的错误）
- 开始一项别人请求的任务，或者是过去在 issue 中早就讨论过的
一个 PR 并不代表着工作已经完成。它通常是尽早的开启一个 PR，是为了其他人可以观看或者给作者反馈意见。只需要在子标题标记为”WIP”（正在进行中）。作者可以在后面添加很多评论。
如果说项目是托管在 GitHub 上的，以下是我们总结出的提交 RP 的建议：
- Fork 代码仓库 并克隆到本地，在本地的仓库配置”上游”为远端仓库。这样你可以在提交你的 PR 时保持和”上游”同步，会减少很多解决冲突的时间。(更多关于同步的说明，请参考这里.)
- 创建一个分支 用于自己编辑。
- 参考任何相关的issue 或者在你的 RP 中支持文档(比如. “Closes #37.”)
- 包含之前和之后的快照 如果你的改动是包含了不同的 HTML/CSS。在你的 PR 中拖拉相应的图片。
- 测试你的改动！ 若测试用例存在的话，跑一遍，以覆盖你的更改，若没有的话，则创建相应的用例。无论测试是否存在，一定要确保你的改动不会破坏掉现有的项目。
- 和项目现有的风格保持一致 尽你最大的努力，这也就是意味着在使用缩进、分号、以及注释很可能和你自己的风格大相径庭，但是为了节省维护者的精力，以及未来他人更好的理解和维护，还请你容忍一下。
如果这是你第一次提交 PR。可以浏览 PR 制造的文档，这是 @kentcdodds 专门为初次创建 PR 的人写的公开的资料。
你提交贡献之后发生了什么
很不错，你做到了！恭贺你成为开源贡献者。我们希望这是一个良好的开端。
在你提交了贡献之后，下面几种情形中的某种是可能发生的：
😭 没有人响应你。
希望你确认在开始工作之前检查过了项目的活跃度，不过即使检查过了，也不保证一个活跃的项目，没有人理会你的贡献也是很正常的。
如果过去了一周，依旧没有人响应，请心平气和的在后面跟帖，询求他人帮助你审核下。如果你熟悉某个人可以审核你的贡献，你可以使用@+名字，直接提醒他一下。
千万不要 私下里去联系他人；一定要记住，开源项目所有的沟通都应该是公开的。
如果你做了所有该做的事情，还是没有人理你，那就是真的没有人对你的贡献做出响应。这可能感觉上不太好受，但是千万不要灰心。每个人都会遇到这样的情况。其实有太多种原因没有人响应你的提交了，包括很多个人情形都是不在你控制范围的。再接再厉，换一种方法去提交，或者换一个项目。这年头，很多社区成员都在积极的参与和响应他人，都在抢夺优秀的人才，若没有人搭理你，你换地方是没有任何不对的地方的。
🚧 有人要求你对自己的提交做出变更。
被要求对你的提交进行更改是很常见的，无论是对你的实现上的反馈，还是你代码改动上的反馈。
当有人提出变更时，请表现出大度的地方，要及时响应。他们花时间审核了你的提交，要尊重他们。开启了 PR，然后一走了之，是一种恶习。如果你不知道如何修改，请花时间深入研究问题的所在，如果还是没有想到好的办法，那么是该向他人求助的时候了。
如果你因为没有时间而无法继续在此 issue 继续工作（举例来说，如果对话已经过去了一个月了，没有任何的回复和进度，环境肯定变得不一样了），那么请向维护者告知你无法在及时的响应了，肯定有人非常乐意接替你的工作的。
👎 你的贡献没有获得通过。
你的提交最后可能没有被接受。真心希望你没有在此作出过多的努力。如果你不确定为什么没有被接收的话，这正是一个很好的询问维护者反馈和澄清的机会。最终，无论如何，你都要对他们的决定表示尊重。不要去做过多无谓的争论或者是充满敌意的谩骂。如果你坚持自己，你可以随意的 fork 项目，按照自己的思路发展出分支来。
🎉 你的贡献被接收。
太棒了！你已经成功的做到了，为开源做贡献也不过如此！
