新人必看的开源指南：如何参与并做贡献
【导读】：对程序员而言，参与开源有着难以置信的回报，比如有一个自己的出色开源项目，在技术面试能增色很多，极大加分。所以，越来越多的人在参与到开源运动中来。但对应很多新手来说，如何参与开源做出第一个贡献，如何发起一个新项目，却成了一个问题。
2月14日，GitHub 官博发文宣告正式推出「开源指南」，旨在方便想参与到开源的个人和组织。「开源指南」是一个系列集合，内容简洁明了，分了 10 个方面。本文是其中的首篇。
怎样为开源做贡献
想为开源做贡献吗？这是一份写给新手和老手的开源贡献指南。
第一部分：为何要为开源做贡献？
在 freenode 的工作使我学到了很多技能，后来我将它们运用到我的大学学习和实际工作中。我认为在开源项目中的工作对我的帮助和它对项目本身的帮助一样大！
为开源做贡献是学习、教学和在你能想象的任何技能上积累经验的有益途径。
为什么人们为开源做贡献？有许多理由！
提升现有技能
不管是写代码、用户界面设计、平面造型设计、写作，或是规划，如果你在寻找实践机会，在开源项目中总有适合你的任务。
结识爱好相似的人
拥有热情而友好的团体组织的开源项目使人们在多年以来常常回访。许多人通过参与开源成了一辈子的好朋友，无论是在会议中碰面还是深夜里线上聊玉米煎饼。
找到导师和教导他人
在共享的项目中与他人一起工作，意味着你必须解释你做事的方式，此外还要寻求他人的帮助。学习和教导，对参与其中的所有人都是一种满足的活动。
开发公开作品，帮你提升声望（和事业）
根据定义，你的所有开源工作都是公开的，这意味着你得到了免费的样本，可以带到任何地方，作为你能做事情的证明。
学习交际能力
开源提供了练习领导才能和管理技能的机会，比如解决冲突、组织不同团队的人，和给工作排优先级。
人人都可以参与改变，不分大小
你不一定要成为终生的贡献者才能享受参与开源的乐趣。你是否曾在网站上看到一个拼写错误，希望某人会修正它？在开源项目中，你就能做到这点。开源帮助人们在他们的生命中和他们对世界的体验中感受到力量，这本身是令人满足的。
第二部分：贡献意味着什么
如果你是一个开源贡献方面的新人，这个过程可能是令人生畏的。怎么找到合适的项目？不会写代码怎么办？某件事出岔子了会怎样？
不用担心！有各种各样的方法参与开源项目，并且有几个诀窍会帮你最大程度地运用你的经验。
你不一定要贡献代码
关于为开源做贡献，一个常见的误解是你必须贡献代码。事实上，常常是项目中非代码的部分大多被遗漏和忽视了。通过参与提供非代码的贡献，你会给项目做出巨大的帮助！
我因为在 CocoaPods 中的工作出名，但大多数人不知道实际上我在 CocoaPods 工具本身上并没有做任何实际的工作。我在这个项目上花费的时间，大部分是在做诸如文档和品牌推广工作之类的事情。
即使你是一名开发者，非代码贡献也是参与项目并结识其它团体成员的极好方式。建立那样的关系，将给予你在项目的其它部分工作的机会。
我初次接触 Python 开发组（也叫做 python-dev）是在 2002 年 6 月 17 日，我就接受我的补丁事宜向邮件列表发电子邮件。很快我发现了开源中的一个 bug，并决定把这个错误写成邮件摘要汇报给小组。我对这个主题做了澄清，他们为麻烦我做这件事而表示了大大的歉意。但更关键的是，当某人指出的某些东西需要修正时，我能够看到的。
— @brettcannon, “Maintainer Stories”
你是否喜欢活动规划？
· 组织关于项目的专题讨论会或聚会，就像 @fzamperin 为 NodeSchool 所做的那样。
· 组织项目会议（如果他们有的话）
· 帮助团体成员找到合适的会议并提交演讲提议
你是否喜欢设计？
· 调整布局以提高项目的可用性
· 做用户调查以重新组织和改善项目的导航和菜单，就像 Drupal 建议的那样。
· 制订风格指南以帮助项目拥有一致的视觉设计
· 为T恤或新的 logo 绘画，就像 hapi.js 的贡献者所做的那样。
你是否喜欢写作？
· 编写和改进项目文档
· 组织一个示例文件夹，展示怎样使用项目
· 开办项目通讯，或从邮件列表中组织重要内容
· 为项目编写教程，就像 pypa 的贡献者所做的那样。
· 翻译项目的文档
说真的，“文档”极其重要。到目前为止，Babel（Kittens 的开源项目）的文档一直很棒，已经成为了它的杀手级特性。但是肯定还需要做一些工作加以完善，甚至加一些段落上去，对此我非常感激。
你是否喜欢组织？
· 链接重复的 Issue，给出新的 Issue 标签建议，让事情井井有条
· 检查开放的 Issue ，提议关闭旧的 Issue ，就像 @nzakas 为 eslint 所做的那样
· 在最近开放的 Issue 中提有助于澄清的问题，把讨论向前推进
你是否喜欢写代码？
· 找一个开放的 Issue 着手处理，就像 @dianjin 为 Leaflet 所做的那样
· 问问你是否能帮忙写一个新特性
· 自动化项目的设置
· 提升工具和测试
你是否喜欢帮助他人？
· 在诸如 Stack Overflow（就像这个 Postgres 的例子一样）或 reddit 之类的地方回答关于项目的问题
· 在开放的 Issue 中为人们回答问题
· 帮忙主持讨论版或会话通道（conversation channels）
你是否喜欢为他人的代码提供帮助？
· 审查他人提交的代码
· 为如何使用项目写教程
· 为其它贡献者提供指导，就像 @ereichert 在 Rust 上为 @bronzdoc 所做的那样
你并不非得要在软件项目中工作！
虽然“开源”通常指软件，但你可以在任何事情上协作。有书籍、食谱、清单和课程是作为开源项目开发的。
例如：
· @sindresorhus 组织了一个 Awesome 的清单列表
· @h5bp 为前端开发求职者维护了一个可能的面试问题的清单
· @stuartlynn 和 @nicole-a-tesla 制作了一份关于 puffins 的有趣事实的集合
即使你是一名软件开发者，在文档项目上的工作也能帮你在开源方面起步。在与代码无关的项目中工作常常不那么令人生畏，而且协作的过程将增强你的自信和经验。
第三部分：熟悉一个新项目
如果你去看一个 Issue 追踪器，发现事情看起来令人困惑，并不是只有你这样。这些工具需要大量的隐性知识，但人们能帮你驾驭它，你也能向他们提问。
对任何超过修正拼写错误的事情来说，为开源做贡献就像在社交聚会上走向一群陌生人。如果当他们正在深入讨论金鱼时，你开始谈论美洲鸵，他们可能有点奇怪地看着你。
在带着你自己的建议盲目投入以前，先从学习怎样观察聚会中的人，参与他们讨论的话题开始。这样做能增加你的想法被注意到和听取的可能性。
开源项目剖析
每个开源团体都是不同的。
在一个开源项目中花了若干年时间意味着你已经了解了一个开源项目。转向一个不同的项目，你可能会发现词汇、规范和沟通方式完全不同。
即便如此，许多开源项目遵循着相似的组织结构。理解不同的团体角色和总体过程将帮你迅速熟悉任何新项目。
一个典型的开源项目有以下几类人：
· 作者（Author）：创建该项目的人或组织。
· 所有者（Owner）：对组织或仓库（repository）拥有行政所有权的人（并不总和原始作者是同一个人）
· 维护者（Maintainers）：对推动愿景和管理项目的组织方面负有责任的贡献者。（他们可能也是项目的作者或所有者）
· 贡献者（Contributors）：每个对项目做出过某种贡献的人。
· 团体成员（CommunityMembers）：使用项目的人。他们可能在对话中保持活跃或者对项目的方向表达他们的主张。
大的项目可能还有下属委员会或工作组，他们致力于不同的任务，比如工具、分类（triage）、团体节制（community moderation）和活动组织。在项目的网站上寻找“team”页面，或者在仓库（repository）里寻找治理文档（governance documentation），来找到此类信息。
项目也有文档。这些文件通常列在仓库（repository）的顶层。
· 许可证（LICENSE）：根据定义，每个开源项目必须有一个开源许可证。如果项目没有许可证，那它就不是开源的。
· 自述文件（README）：自述文件是迎接项目的新团体成员的操作指南手册。它解释了为什么项目是有用的以及如何开始。
· 贡献（CONTRIBUTING）：自述文件帮助人们使用项目，而贡献文件帮助人们为项目做贡献。它解释了需要什么类型的贡献者以及这个过程是怎么工作的。虽然不是每个项目都有贡献文件，但它的存在表明这是一个欢迎做贡献的项目。
o 行动守则（CODE_OF_CONDUCT）：行动守则为参与者的相关行为设定了基本准则，并且帮助促进一个友好而热情的环境。虽然不是每个项目都有行动守则文件，但它的存在表明这是一个欢迎做贡献的项目。
o 其它文档：可能有另外的文档，比如教程、演练（walkthroughs）或管理策略，尤其是在大项目中。
最后，开源项目使用以下工具来组织讨论。通读档案文件将为你很好地描绘该团体是怎样思考和工作的。
· Issue 追踪器（Issuetracker）：人们讨论项目相关 Issue 的地方。
· Pullrequests：人们讨论和审查进行中的更改的地方。
· 讨论板或邮件列表：有些项目可能为会话主题使用这些通道（例如，“我怎样……”或“你认为……怎么样”，而不用 bug 报告或特性请求）。其它项目为所有会话使用 Issue 追踪器。
· 同步聊天通道（Synchronous chat channel）：有些项目为临时会话、协作和快速交流使用聊天通道（比如 Slack 或 IRC）。
第四部分：找到一个要做贡献的项目
既然你已经弄明白开源项目是怎样工作的，是时候找到一个要做贡献的项目了！
如果你之前从未为开源做过贡献，听听美国总统约翰·F·肯尼迪的建议，他曾经说：“不要问你的国家能为你做什么-问问你能为你的国家做什么。”
为开源做贡献在所有层面和不同项目间都能发生。你不必对你的第一个确切的贡献是什么，或它看起来是什么样想得过多。
相反地，从考虑你已经在使用的或想要使用的项目开始。你会积极地做贡献的项目正是你发现自己会回访的项目。
在那些项目里，无论何时你发现自己想到某件事可以变的更好或不同，按照你的直觉行动吧。
开源不是一个排外的俱乐部；它是由和你一样的人做出来的。“开源”只是一个花哨的术语，为了把世界上的问题都作为可修正的来处理。
你可能会细看一份自述文件，发现一个断开的链接或一个拼写错误。或者，你是一个新用户，你发现某样东西毁坏了，或是一个 Issue 你认为实际上应该在文档中。与其忽略它并继续，或请求其他人修正它，不如看看你能不能参与帮忙。这就是开源的真谛！
对开源的非正式贡献中，有28%是文档，比如拼写错误修正、重排格式，或翻译。
你也可以使用下列资源之一来帮你发现新项目：
·
做贡献前的一份检查表
当你找到一个你想要做贡献的项目，做一个快速的浏览来确认该项目适合接受贡献。否则，你的努力工作可能永远得不到回应。
这是一份便于使用的检查表，用来评估一个项目对新贡献者来说好不好。
满足开源的定义
· 它有没有许可证？通常，这是在仓库（repository）根目录里的一个叫做 LICENSE 的文件。
项目积极地接受贡献
看看主分支上的提交活动。在 GitHub 上，你可以在仓库的主页上看到此信息。
· 最新的提交（commit）是在什么时候？
· 项目有多少贡献者？
· 人们提交频繁程度？（在 GitHub 上，你可以通过点击顶部横条里的“Commits”来找到此信息）
下一步，看看项目的 Issue 。
· 有多少开放的 Issue ？
· 当 Issue 开放时，维护者是否快速地回应？
· 对于 Issue 有没有活跃的讨论？
· Issue 是最近的吗？
· Issue 是否得到关闭？（在 GitHub 上，点击 Issue 页面上的“closed”标签来看已关闭的 Issue 。）
现在对项目的 pull requests做同样的动作。
· 有多少开放的 pull requests？
· 当开放pull requests时， 维护者是否快速地回应？
· 对于pull requests有没有活跃的讨论？
· pull requests是最近的吗？
· pull requests被合并是在多久之前？（在 GitHub 上，点击pull requests页面上的“closed”标签来看已关闭的pull requests。）
热情的项目
友好而热情的项目标志着他们乐于接受新的贡献者。
· 维护者对于 Issue 中的问题是否作出有帮助的回应？
· 人们在 Issue 、讨论板和聊天（例如 IRC 或 Slack）中是否友好？
· Pull Requests(PR) 功能是否得到审查（reviewed）？
· 维护者对人们的贡献是否表示感谢？
无论何时你看一个长的讨论帖，抽查一下较晚进入这个帖子的核心开发者的反应。他们是否作出建设性的总结，在做出决策和付诸实施时，是否同时还保持礼貌？如果你看到发生许多口水仗，那通常表明精力用在了争论而不是开发上。
第五部分：怎样提交贡献
你已经找到一个你喜欢的项目，并且你已经准备好作出贡献。最后！这里告诉你怎样以正确的方式作出你的贡献。
有效的沟通
不管你是一次性的贡献者或是试着加入一个团体，与他人一起工作是你将在开源中发展的最重要的技能之一。
作为一个新贡献者，我很快认识到，如果我想要能关闭 Issue ，我必须提问。我浏览了代码库。一旦我对发生的事有了一些认识，我请求更多的指点。就是这样！在得到我需要的所有相关细节后，我能解答 Issue 了。
在你打开一个 Issue 或使用pullrequest，或是在聊天中提问以前，记住这些要点可以使你的想法有效地被别人理解。
给出上下文。帮助他人快速赶上进度。如果你遇到一个错误，解释你正准备做什么和怎么重现它。如果你提出一个新主张，解释为什么你认为它对项目有用（不只是对你！）。