点击“开源之道”关注我们
寻找打算做贡献的项目
你读到这里，说明已经对于一个开源项目如何运作的有了清晰的认识，是该找一个合适的项目做贡献的时候了！
假如你之前从来都没有为开源做过贡献的话，那么请记住来自美国总统约翰 F.肯尼迪的这段话：不要问你的国家能为你做什么，要问你能为国家做什么。
开源项目的方方面面都需要贡献者，你先不要通盘考虑该往哪里贡献，或者是它将如何看。
相反，从你已经使用到的或者打算用到项目开启贡献之路，在你积极的贡献过程中，项目也会反馈给你，让你更好的定位自己。
一旦进入某项目，不论何时，你都要听从自己的直觉，做你认为更好或者不同的事情。
开源并不是高级俱乐部；它就是由你这样的人所浇铸和打造。“开源”只是针对这个世界的需要修复的问题的一个梦幻术语罢了。
你或许在查看 README的时候，发现了损坏的链接，又或者拼写错误。又或者是你是一名新手，使用的过程中发现了问题，又或者是某问题应该在文档中注明。请不要坐视不理，径直绕开，或者是请求他人修复，伸出你的援助之手，解决这些你能看到的问题。而这正是开源的精髓之所在！
28% 的随意贡献 就是说明了文档的开源，诸如拼写错误，段落语句调整、或者是翻译。
你也可以利用如下列出的资源来找到合适的新项目：
GitHub 探索
First Timers Only
你的第一个 PR
CodeTriage
24 Pull Requests
Up For Grabs
像忍者一样贡献
提交贡献之前应做的检查列表
当你找到了你打算贡献的项目时，在进一步行动之前，作一个快速的扫描工作，以确保项目是否接受贡献的。否则，你煞费苦心的工作可能没有任何的回报。
这是一个简易的检查表，用来评估一个项目是否适合新的贡献者。
符合开源的定义
🔸有许可协议吗？通常情况下，会在根目录有一个叫做 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？
🔸维护者是否对做贡献的人们道声”谢谢”？
当你看到一个很长当对话时，来自核心开发者的零星的响应排在列表的后面。你就得考虑，他们在作建设性的总结？是否保持风度的情况下做出最后的决定？如果你看到的是更多的口水仗，而且还在继续，这通常意味着社区的能量重心已经不在开发上了。
— @kfogel, 开源软件生产力
如何提交成果
你已经找到了你喜爱的项目，也已准备好贡献了，迫不及待、跃跃欲试了。好吧！以下就是带领你如何以正确的姿势作贡献。
有效沟通
无论你处于什么样的目的：仅仅是一次性的贡献，亦或是永久性的加入社区，都的和他人进行沟通和交往，这是你要在开源圈发展必须修炼的技能。
[作为一名新手,] 我很快的就意识到，我若是要关闭一条issue时，我不得不问更多的问题。我浏览了代码库，一旦我觉得有什么问题的时候，我就得需要更多的指点，瞧！ 在我得到所有的所需要的信息后，我就可以解决这个问题！
— @shubheksha, 一名菜鸟进入开源世界的坎坷之旅
在你开启一个isse或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”，所有的对话都会通知到你），要让社区的成员们知道你要做的工作，免得你做了之后，再让他们知道，他们不同意，就浪费了。
你能够从单个的项目学习到 很多 ，只要你踊跃的去使用，在GitHub上密切观察项目，并阅读每一个 issue 和 PR。
— @gaearon 参与项目
创建 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项目，按照自己的思路发展出分支来。
🎉 你的贡献被接收。
太棒了！你已经成功的做到了，为开源做贡献也不过如此！
你已经做到了!
你刚刚完成了自己的开源贡献处女秀，接下来，你可能打算寻找另外的方法来做贡献，希望本文给你提供了灵感和实践。即使是你的贡献没有被采纳或接收，也不要有失风度，请对帮助过你的维护者表示感谢！
开源就是由你这样的人所铸造：开启一个issue，在提交PR，评论、讨论、收集反馈，直到被接收。就是这么简单。
完结
上一篇：GitHub 开源指南系列之一——如何参与开源？（上篇）
PS:文中链接部分可在原文中任性点击
点击下方“阅读原文”查看更多
本文分享自微信公众号 - 开源之道（OCSelected）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
