本文是【Github开源项目贡献指南】系列的第一章，原文【Open Source Guides——How to Contribute to Open Source】
为何要给开源项目做贡献？
给freenode做贡献帮助我学到了很多后来在大学和实际工作中用到的技能，我觉得给开源项目工作对我的帮助和对项目本身的帮助相差无几。—@errietta “Why I love contributing to open source software”
给开源项目做贡献可以说是在你能想象的领域上学习，传授，累计经验的最有效的方式！为什么人们要给开源项目做贡献，原因太多了！
提高现有技能
不管是写代码，用户界面的设计，图形设计，写作，或者是组织，如果你想找点练习做一做，在开源项目上你总能找到能胜任的任务。
认识和你有同样爱好的人
气氛融洽开放的开源项目会让人数年之后仍然不忘回来看看（项目进展）。许多人在参与开源项目的过程中结识了一生挚友，友谊在会议的互相照面和深夜的线上闲聊中渐渐形成。
寻找导师或者教导别人
和他人一起合作一个项目意味着你得解释你是怎么做事情的，同时寻求他人的帮助。学习和传授知识的体验对每个参与其中的人来说都是令人愉快的体验。
做一个公开的产品帮你赢得声誉（和职业机会）
从开源项目的定义可以知道，你所有的工作成果都应该公开，这意味着你免费获得了一个向众人展示你能力的机会。
学习他人的技能
开源项目给参与其中的人们提供了锻炼领导力和管理能力的机会，比如解决冲突，组织团队的成员，辨别工作的轻重缓急。
你有权做出改动，就算是很小的
你不需要成为那种一直在给开源做贡献的人。你有在网站上看见手误吗，而且希望有人能修正它。在一个开源项目中，你自己就可以做到。开源帮助人们在生活和对世界的体验上感觉到更有力量，这本身确实是意见可喜的事情。
贡献是什么意思
如果你是一个刚刚开始的开源贡献者，这个过程可能会让你觉得很吓人。如何找到正确的项目？你不知道怎么贡献代码怎么办？如果改错了怎么办？
不必担心！有很多参与开源项目的方法，和一些让你走出困境的小技巧。
你不需要贡献代码
对开源贡献的一个普遍的误解就是你得贡献代码。实际上，通常和代码无关的部分才是最容易忽视的：通过参与非代码部分的贡献会给项目带来巨大的帮助。
我因为对 CocoaPods的贡献而著名，但是大部分人都不知道我在这个工具本身的开发上并没有做实质性的工作。我花在这个项目上的主要时间都用来整理文档和宣传品牌。—–@orta
即使你是一个开发者，非代码部分的贡献是一个很好的方式让你参与一个项目和认识社区的成员。建立这种关系会给你从事项目其他部分工作的机会。
我第一次接触 Python 开发团队（又叫做 python-dev）是在2002年6月17号我给邮件列表发邮件让他们接受我的补丁的时候。我迅速的发现的这个项目的缺陷，并决定负责组织团队的邮件摘要。这给了我一个很好的机会去咨询他们对一个话题的解释，但是实际上更关键的是当有人提出问题的时候我能意识到那是不是需要修复的 bug 。—–@brettcannon
你喜欢策划活动吗?
- 组织关于项目的研讨会或者线下聚会，就像 @fzamperin
- 组织项目会议（如果他们有的话）
- 帮助社区成员找到合适的会议主题并提交一份发言稿。你喜欢设计吗？
- 重构项目的布局以增加其易用性
- 组织用户使用调查来重构项目的导航或者菜单
- 把样式指南放在一起以此来帮助项目有一致的视觉设计
- 设计 t-shirt 或者 新的logo，就像是hapijs的贡献者们做的一样你喜欢写作吗？
- 编写或者改善项目的文档
- 创建一个文件夹展示项目怎样使用的例子
- 给项目编写教程，就像pypa的贡献者们做的一样
- 为项目的文档做翻译认真的说，文档真的是重要得一逼。目前Babel的文档已经很棒了，这也是其杀手锏的特性之一。当然，还有一些章节需要大家的完善，即使是随便在哪儿增加一个段落都很感激。你喜欢组织吗？
- 连接重复的 issue，或者为某个iuuse添加新的标签来让事情变得井然有序
你喜欢写代码吗？
- 使配置项目的过程自动化
- 改善工具链和测试
你喜欢帮助别人吗?
- 在诸如 Stack Overflow或者reddit上回答关于项目的问题（这里有一个关于Postgres例子）
- 在打开的 issue 中回答人们的问题
- 帮助调整讨论板块或者对话渠道你喜欢帮助改善别人的代码吗?
- 审查别人提交的代码
- 写一个关于项目如何使用的教程
- 帮助其他的贡献者，就像在Rust项目上@ereichert为@bronzdoc做的那样
你不一定只能给软件项目做贡献！
虽然开源一般指的是软件项目，实际上你可以在任何项目上进行协作。有很多书籍，经验贴，列表，课程都是开源项目。
比如：
- @sindresorhus策划了 awesome 系列的列表
- @h5bp持有一份关于前端常见面试问题的列表
- @stuartlynn 和 @nicole-a-tesla制作了一份关于海雀的有趣现象集锦即使你不是你个软件工程师，给一个文档性质的项目做贡献也会让你迈进开源世界的大门。在没有代码的项目上做事通常没那么吓人（相比与有代码的项目来说）,而且这个写作的过程会让你积累更多自信和经验。投身于一个新项目如果你打开一个项目的 issue tracker 。里面的东西可能让你觉得不解，不只是你有这样的感觉。这些工具需要很多的隐性知识，但是人们会帮助你搞清楚，你也可以问他们问题。
—-@shaunagm “How to Contribute to Open Source”对于那种不仅仅是修复一个手误的工作，给开源项目做贡献就像是在一个聚会上走近一群陌生人一样。当他们正在热火朝天的讨论金鱼的时候，你插进去开始讲骆驼,他们会像你投来异样的眼光。在你带着你的见解盲目的加入讨论之前，首先研究一下他们到底在讨论什么。这样会增加你的观点被注意到和听取的机会。分析一个开源项目每一个开源社区都不一样。在一个项目上花费数年的事件会让你对这个项目了如指掌。但是当你迁移到另外一个项目中时，你会发现他们的词汇，规范和讨论的风格完全不一样。话虽如此，很多开源项目还是遵循一个相似的组织结构。理解不同社区的角色和总体的进程会帮助你很快的融入一个新的项目。一个经典的开源项目会有这样几类人： - 作者： 创建该项目的人或者组织
- 所有者： 对该组织或者仓库有行政权的人（通常和原始的作者不是一个人）
- 维护者： 那些负责宣传项目，管理项目组织的贡献者（ 他们也可能是作者或者所有者）
- 贡献者： 每个给项目做出或多或少贡献的人
- 社区成员： 使用项目的人。他们可能在关于项目方向上的讨论中积极发表自己的观点
更大型的项目可能有针对不同工作的子社区或者工作组，比如工具链，工作分配，打造社区的舒适度和事件管理。查看项目网站上的“团队”页面，或者存放管理文档的仓库寻找这些信息。
一个项目也会有他自己的文档，这些文件放在项仓库目的一级目录。
- LISENCE：由于开源项目的定义，每个开源项目都要有一个开源协议。如果一个项目没有一个开源协议，那么他就不是开源项目。
- README：README文件是给社区的新成员的使用手册。它解释了为什么这个项目是有用的和怎么开始使用这个项目。
- CONTRIBUTING：READMEj文件是帮助人们使用项目的，而CONTRIBUTING文档是帮助人们对项目做贡献。但是不是每个项目都有CONTRIBUTING文件，那么有这个文件就标志着这是一个开放的项目。
- CODE_OF_CONDUCT：行动守则制定了参与者行为的基本规则，帮组促进了社区的友好，开放的氛围。但是不是所有项目都有 CODE_OF_CONDUCT 文件，如果有的话那就标志着这是一个开放的项目。
- Other documentation：还可能有其他的文档，比如教程，预览，或者管理政策，尤其是在大型项目中会出现。最后，开源项目使用下面这些工具来管理讨论。在你阅读本文的过程中，你会对开源社区思考和工作的方式有一个总体的映像。
- Issue tracker：人们用来讨论和项目相关的问题的地方
- Pull requests: 人们用来讨论和审查正在进行中的修改。
- Discussion forums or mailing lists（论坛或者邮件列表）： 有些项目会用不同的频道对应不同的讨论主题（比如说，“我怎样才能…” 或者 “你们对于…的看法是”，而不是 bug 报告或者功能请求。另外一些项目直接用 Issue tracker 进行所有话题的讨论。
- Synchronous chat channel（匿名的聊天频道）：有些项目用聊天频道（比如Slack或者IRC)来进行随意的讨论，合作，或者快速的修改。找一个项目来做贡献现在你已经知道开源项目是怎么工作的了，是时候找个项目然后开始贡献了！如果你从来没有给开源项目做过贡献，那么从美国前总统约翰·肯尼迪的名言之中吸取一点建议吧：不要问你的国家能为你做什么，先问问自己你能为自己的国家做什么。给开源项目做贡献可以发生在任何级别的任何项目。你不需要过分在意你的第一次贡献会是什么，或是以什么形式。相反，从你已经在用的项目或者你想用的项目开始。你贡献最积极的项目正好是那些你发现你会是不是来看一下的项目。在那些项目中，尽管释放你的本能，去发现那些你觉得可以做的更好或者做的不同的东西。开源世界不是一个排他性的俱乐部，它正是有那些像你一样的人创造的。“开源组织”是一个把世界上所有问题看成可以解决的梦幻之地。你可以浏览一下项目的 README 文档，找找有没有挂掉的链接或者手误。或者你是一个新用户，而且你发现什么了东西不对，或者一个你觉得应该放在文档中的 Issue ，与其直接忽视或者找别人修复它，还不如自己动手把他改过来。这就是开源的含义啦！28%的不固定的贡献者所做的都是在文档上，比如更正手误，重新排版或者提供一种语言的翻译版本。你还可以用以下的资源来帮助你寻找项目。
- GitHub Explore
- First Timers Only
- Your First PR
- CodeTriage
- 24 Pull Requests
- Up For Grabs
一个在你贡献之前的清单
当你发现了一个你想要贡献的项目的时候，对项目做一快速的浏览来保证这个项目适合接受你的贡献，否则你的工作得不到应有的回应。
这里提供了一份评估一个项目是否适合新的贡献者的清单
检查开源的定义
他有一份开源协议吗？通常情况下是一个在项目根目录下的叫 LISENCE 的文件。
项目接受贡献者的活跃程度
查看 master 分支上的提交活动。在github上，你可以在仓库的主页上看到这个信息
最近一次提交是什么时候
项目目前有多少贡献者
人们提交的频率是怎样的？（在 Github ，你可以通过点击顶部的 “commit” 来找到。
接下来，查看项目的 issue 。
目前有多少 issue 。
Do maintainers respond quickly to issues when they are opened?
项目维护者对打开的 issue 回复的速度如何？
在 issue 中的讨论是否热烈。
issue 都是在最近的吗？
issue 被关闭了吗（在 Github ，在 issue 页面点击 “closed” 标签查看关闭的 issue 。
对项目的 pull request 做同样的检查。
目前有多少 pull request？
项目维护者对打开的 pull request 回复的速度如何？
在 pull request 中的讨论是否热烈？
pull request 都是最近的吗？
最近一次的 pull request 被合并是什么时候？（在 Github ，在 pull request 页面点击 “closed” 标签查看被关闭的 pull request。
项目是否足够开放
如果一个项目是友好和开放的那么意味着他们很乐意接受新的贡献者。
项目维护者对 issue 中的问题的回复时候有帮助？
在 issue ，论坛，聊天室（比如 IRC 或者 Slack）中的人们是不是乐于助人。
pull request会被审查吗？
项目维护者对贡献者的 pull request 表示感谢了吗？
不管何时当你看到核心开发者做出的长篇大论式的，总结性的发言。不妨思考他们总结是建设性的吗？而且在保持礼貌的同时一步一步把讨论引向一个结论。如果你看到了讨论过程中出现摩擦，经常让人叹息的是他们把精力浪费在了争吵而不是开发上面。— @kfogel, Producing OSS
如何提交贡献？
假如你已经找到了一个你喜欢的项目，而且你已经准备好做一次贡献。终于！是时候谈谈怎么正确做出贡献啦！
