How to Contribute to Open Source
原文链接 -> 传送门
参与到开源事业的最好办法之一就是为现有的开源项目贡献力量。GitHub 上拥有超过五百万的开源项目供你选择。这里面包含各种类型的技术，比如：recipes、 HTML/CSS、Ruby、Astrophysics 和其他许多项目。本文将涵盖你在一个典型的项目中可能发现的内容以及如何做出贡献。
寻找项目
我们建议从你已经在使用（或者感兴趣）的项目开始。
下面是一些值得访问的链接：
- GitHub Explore：当前的热门项目
- GitHub Stars：你点赞过的项目
- GitHub Showcases：查找相关的仓库
- LayerVault News：前端开发和设计项目
一个典型的项目
下面是在一个开源项目中可能会访问的一些元素：
社区（The Community）
每个项目通常都有一个相关联的社区，由其他用户扮演（正式或非正式）的角色组成：
- 所有者是指创建项目的个人或组织，该身份拥有这个项目
- 维护者和协作者是指这个项目的主要开发者和推动项目开发方向的人，通常项目所有者和维护者是同一个人，他们都拥有仓库的写入权限
- 贡献者是指任何对项目开启 pull request 并被合并到项目中的人
- 社区成员是指经常使用这个项目，深切关心项目并且活跃讨论项目的功能和 pull requests 的人
文档（The Docs）
项目中包含的常见文件。
请先读我（Readme）
几乎所有 Github 上的项目都包含一个叫做 README.md 文件。这个 Readme 文件通常描述了项目如何使用、编译的细节，有时也提供参与项目方法。
贡献（Contributing）
因为不同的项目有不同的维护者，所以参与项目的方式也不尽相同。你可以查看一个叫做 CONTRIBUTING 的文档，该文档详细描述了维护者希望看到补丁或功能实现的具体规范。这可能包含了如何编写测试，代码语法风格，或者补丁应用范围。
许可证（License）
LICENSE 文件就是项目的许可证。一个开源项目的许可证告诉用户他们可以做和不可以做什么（例如：使用、修改和分发），以及参与者的权利。开源项目的许可证有非常多的种类，你可以在 度娘 中查看到每一个许可证的含义。
文档和 Wikis（Documentation and Wikis）
许多大型的项目没办法在一个 Readme 文件中描述所有的细节，这种情况下你可以在仓库中找到另一个文件的链接或者叫“docs”的文件夹。
另外，仓库也可以使用 GitHub 的 wiki 系统来代替文档。
参与一个项目
现在你已经掌握如何了解一个项目的技能了，那么让我们开始行动起来吧。
创建一个问题单（Issue）
如果你在项目中发现一个 bug（然而你不知道如何去修复它），在文档中也找不到相关信息或者对项目存在疑问，那么就应该 —— 创建一个问题单（issue）！不管是什么问题，你都可能不是唯一遇到这个问题的，所以创建一个问题单对于其他用户来说也是有帮助的。对于问题单的更多信息及工作原理，请查看我们的 接下来的文章 Issues 指南。
有关 Issues 的专业建议
- 检查当前已有的问题单是否与你的问题有关。发布重复的问题单会降低大家的效率，所以先搜索正在进行和已经关闭的问题单，看是否你的问题已经被提及。
- 请明确你的问题：期望的输出是什么，实际发生了什么？以及其他人如何重现你的问题。
- 通过链接到示例的方式重现问题，比如在 jsfiddle 和 codepen 上的示例链接。
- 包含你的系统环境的详细信息，比如使用什么浏览器，库或者操作系统及其版本。
- 在你的问题或 Gist 中将错误输出或日志粘贴出来。如果你在一个问题中粘贴它们，使用三个反引号（```）可以让显示更漂亮一些。
Pull Request
如果你有能力修复 bug 或者添加新的功能 —— 那实在是太美妙了！快点对代码开启一个 pull request 吧！在此之前，请确保你已经阅读过相关的参与文档，理解许可证内容并且根据需要签署“贡献者许可协议”（CLA）。一旦你开启一个 pull request，项目的维护者（们）可以比较你的分支和当前的分支，并确定是否合并（pull in）你的更改。
Pull Request 的专业建议
- Fork（将在后面介绍） 仓库并克隆到本地。通过将其添加为远程，将本地连接到原始的“上游”仓库。经常从“上游”拉取更改，以保证提交你的 pull request 时是最新的版本，从而减少合并冲突的可能性。更多细节请看这里。
- 为你的编辑创建一个分支。
- 弄清楚问题是如何产生的，同时他人应该如何去重现该问题，或者确定你提交的功能是有用的。同样，清楚了解你的更改执行步骤。
- Pull Request 之前最好进行测试。将你的更改在已有的测试（如果有的话）上都跑一遍，需要时还可以创建一个新的测试。不管是否存在现有的测试，请确保你的更改不会扰乱现有的项目。
- 如果你的更改保函 HTML/CSS 上的不同，请提供更改前后的截图。只需拖拽图片到 pull request 中即可。
- 尽最大的努力使用和项目一致的风格进行开发。这可能意味着使用的缩进、符号和注释风格与你自己仓库的不同，但是为了项目维护者更容易合并，其他人更容易理解和将来的维护，请务必要这么做。
开启 Pull Requests
一旦你开启了一个 pull request，就会开始一场关于你提交的更改的讨论。其他贡献者和用户都可能参与进来，但最终还是由维护者（们）进行决策。你可能会被要求对你的 pull request 进行一些修改，如果是这样的话，为你的分支添加更多的提交（更改），并推送（push）它们 —— 它们将自动加入到已经存在 pull request 中。
如果你的 pull request 被合并了 —— 那就简直是帅呆了！如果没有被合并，也别伤心难过了，可能是维护者没有注意到你的 pull request，或者他们自己正在开发这方面的东西……遇到这种情况，我们建议你处理接收到的反馈信息，然后再次提交 pull request —— 或者干脆放弃他们，创建自己的开源项目吧。