这篇文章是开源社区翻译的开源指南系列第三篇文章

原作：https://opensource.guide

翻译：psyduck

寻找一个项目

如果你之前从未参与过开源项目的话，那么请记住美国总统约翰 F.肯尼迪的这番建议：“不要问你的国家能为你做什么，要问你能为国家做什么。”

开源的方方面面都需要人作出贡献，你不用在自己的第一份贡献到底是怎么样的或是它是否成功这样的问题上考虑过多。

相反的，从你已经使用过或想去使用的项目。在你积极的贡献中，项目也会帮助你更好的定位自己。

在项目中，不论何时，跟着你的直觉走，去做一些你认为更好或者是不同的事。

开源并不是一个私人会所，它由同你一样的人组成，“开源”只不过是把世间的问题都视做可以解决的一个幻想的词语。

你在阅读 README 时或许会发现有链接损坏或是拼写错误，或者说你是一名新手，在使用中发现了一些问题，又或者你认为某个 issue 应该被写入文档中。请不要坐视不理，或是请求他人帮助修复，投入到项目中来，做自己力所能及的事情，这正是开源的精神所在。

提交贡献前应做的检查

当你找到一个你想参与的项目后，快速检查一遍以保证项目可以接受贡献。不然，你的辛苦付出可能无法得到回报。

以下是一份简易的清单来评估一个项目是否适合新的 contributor

  • 符合开源定义

    是否有许可协议，通常情况下会在项目根目录下有一个 LICENSE 文件

  • 项目接受贡献的活跃度

    查看主干分支上提交的活跃度，在 Github 上你可以在仓库的主页看到这些信息

    最后一次提交是在什么时候

    项目有多少 contributors

    人们提交的频率（在 Github 上可通过点击 “commits” 查阅）

  • 下一步，查看 Issues

    有多少公开的 Issues

    项目维护者对于公开的 Issues 响应是否迅速

    Issues 中讨论是否活跃

    Issues 都是近期产生的么

    有没有关闭的 issue？ (GitHub 中点击 “closed” 可以看到所有已经关闭的 Issue)

  • 查看PR（pull requests）

    有多少公开的PR

    当提交了 PR 后，维护者响应是否迅速？

    PR 中讨论是否活跃

    PR 都是近期产生的么

    最近有多少 PR 合并？ (在 GitHub中点击 PR 页面 “closed” 来查看已经关闭的PR)

  • 项目受欢迎程度

    一个项目的友好程度和受欢迎意味着更能吸引新的贡献者。

    维护者在 Issues 中的回答是否有帮助

    人们在 issue 中、在线聊天室、论坛是讨论否很友好？

    PR是否被 review

    维护者是否会对 contributors 表示感谢

如何提交

有效的沟通

不论你是一次性的贡献还是长期加入一个开源组织，与他人沟通交流都是你在开源中必须锻炼的技能

在你开始一个新的Issues或是PR，亦或是在交流中提出一个新的问题记住以下几点会让你的工作更加高效

给出上下文

以便让他人快速的理解，如果你碰到了错误，解释一下你想做什么，并给出复现错误的方法。如果你提出了一个新的想法，解释一下为什么你觉着它对项目有用处。

做好准备工作

不知道并没有关系，但你要表现出你曾经尝试过，在寻求帮助之前请保证你已经阅读过项目的 README、文档、问题（开放的和关闭的）、邮件列表，并搜索了网络。人们会对你表现出的强烈的求知欲表示欣赏并愿意提供帮助。

保证请求简短且直接

就像发邮件一样，每一个 contribution，不论简单或是实用与否，都需要他人审阅。很多项目请求的人多但帮助的人少。简洁一些，能增加得到他人帮助的概率。

虽然听起来很诱人，但也不要去给维护者发私信，除非是你要分享一些敏感信息（例如安全问题或是严重违规行为）如果你将对话公开，更多的人可以从中获益，交流本身也是一种贡献。

大胆的提问（但是要谨慎！）

某种程度上来说每个人都是项目的新手，哪怕是非常有经验的 contributor 也需要在进入一个新项目时学习。同样的，即使是长期维护人员并不总是熟悉一个项目的每一部分。给予他们足够的耐心就像你希望他们给予你的那样。

尊重社区的决定

你的想法可能会和社区的优先级、愿景等有差异，他们或许会给予反馈或是决定弃用你的想法。这是你应该去积极的讨论，并寻求妥协，维护着必须慎重考虑你的想法。如果你仍旧不同意他们的方向，你可以依旧在自己的分支上工作，或是另起炉灶。

综上所述

开源是由世界各地的人们合作实现的，在不同语言、文化、地理位置、时区间可能会产生误解。另外，文字交流使得语气和情绪的表达更加困难。让对话中都充满善意吧。礼貌地拒绝一个想法，要求更多的上下文，或进一步澄清你的立场是很好的，试着让网络环境越变越好。

收集上下文

在开始前，快速的检查一下你的想法没有在其他地方被讨论过，遍历项目的 README、Issues（开放的和关闭的都算）、邮件列表、Stack Overflow。你不必花上几个小时，但使用几个关键词来搜索一下还是必要的。

如果你没有找到和你想法一样的内容，那你就可以开始下一步了，如果项目发布在Github上你可以通过开启一个Issue 或 PR 来进行交流：

  • Issues 开启一次对话或讨论
  • PR 开始一项工作或解决方案
  • 少量的对话 尝试着在Stack Overflow, IRC, Slack,或其他聊天频道澄清或是提出一个问题。

在你创建一个 Issues 或 PR 之前，请检查项目的贡献者文档（文件名通常叫做 CONTRIBUTING，或者就直接包含在 README 中），查看你是否需要加入一些比较具体的东西。例如，他们会要求你遵循某个模版，或者是要求你进行某个测试。

如果你想做一个非常实际的贡献，在正式开启之前，先创建一个 Issue。观察项目一段时间是非常有帮助的，（在 GitHub 中点击 “Watch”，所有的对话都会通知到你）让项目成员知道你所做的工作，以免工作完成之后他们不接受。

创建 Issues

碰到以下情况时你应当创建一个Issues

  • 报告你自己无法解决的错误
  • 讨论一个高层次的想法或主题（例如. 社区、远景、政策等）
  • 提出实现一个新特性或者其他项目的想法

在Issue的沟通中几点实用的技巧

  • 如果你刚好看到一个开放的issue，恰是你打算解决的， 添加评论，告诉他人你将负责这个。这样的话，可以避免他人重复劳动。
  • 如果某个issue已经开放很久了， 这可能是已经有人正在解决，又或是已经解决了，所以在开始工作前也请添加评论。
  • 如果你创建了一issue，但是没多久自己解决了， 也要添加评论，让其他人知道，然后关闭该issue。记录本身就是为社区的贡献。

创建一个PR

碰到以下情况时你应当创建一个PR

  • 提交补丁（例如，拼写错误、损坏的链接、或者是其它较明显的错误）**
  • 开始一项别人请求过任务，或者是过去在Issue中早就讨论过的
  • 一个 PR 并不意味着工作的结束。通常是早早的开启一个PR，是为了其他人可以观看或者给作者反馈意见。只需要在子标题标记为“WIP”（正在进行中）。你可以在后面添加很多评论。

如果项目是托管在 GitHub上，以下是提交PR的建议：

  • Fork 代码仓库 并克隆到本地，在本地的仓库配置“上游”为远端仓库。这样你可以在提交你的PR时保持和“上游”同步，会减少很多解决冲突的时间。
  • 创建一个分支 用于自己编辑。
  • 参考任何相关的Issue 或者在你的RP中支持文档
  • 包含之前和之后的快照 如果你的修改包含了HTML/CSS的变动，请在你的PR中保存相应的快照
  • 测试 如果存在测试样例的话，用您更改过的代码跑一遍，如果没有，在必要时创建一个新的测试样例。不论测试样例是否存在，一定要确保你的改动不会破坏掉现有的项目。
  • 和项目现有的风格保持一致 尽你最大的努力，这也就是意味着在使用缩进、分号、以及注释很可能和你自己的风格大相径庭,但这有助于节省维护者的精力，以及未来他人更好的理解和维护。

提交之后

在你提交一次 contribution 之后，一下事件之一可能会发生

😭 没有人响应你。

希望你确认在开始工作之前检查过了项目的活跃度。不过即使是一个活跃的项目，没有人理你也是很正常的。（b数自在人心/手动微笑）

如果过去了一周，依旧没有人响应，请有礼貌的的在后面询求他人帮助你审核。如果你熟悉某个人可以审核你的贡献，你可以使用@，直接提醒他一下。

千万不要 私下里去联系他人；一定要记住，开源项目所有的沟通都应该是公开的。

如果你做了你该做的，但还是没有人理你，那就真的是没有人理你了（微笑），这可能让人感觉不那么好受，但别灰心，这种事情每个人都会碰到。没人响应你也是有很多原因的，包括一些超出你掌控的个人情况。换一种方式提交或是换一个项目，一个小建议：在其他项目成员参与和反应之前不要投入太多的时间在里面。

🚧 其他人的要求你对自己的提交做出变更

被要求对自己的提交做出更该是非常常见的，可能是在想法上获得了反馈，也可能是代码上的修改。

当有人要求修改时，表现的积极一些，毕竟他们也花时间审核了你的提交。开启一个新的PR然后一走了之是一种非常不好的习惯，如果你不知道如何修改，请花时间深入研究问题的所在，如果还是没有想到好的办法，可以向他人求助。

如果你没有时间继续在此 Issues 中工作（举例来说，如果对话已经过去几个月了，而你的工作环境也发生了变化）那么请告知维护者你无法再及时响应了，肯定会有其他人非常乐意接替你的工作。

👎 你的贡献没有获得通过

你的提交最后可能没有被接受。真心希望你没有在此投入过多。如果你不确定为什么被拒绝的话，这正是一个很好的询问维护者反馈和澄清的机会。最终，无论如何，你都要对他们的决定表示尊重。不要去做过多无谓的争论或者是充满敌意的谩骂。如果你坚持自己，你可以随意的 fork 项目，按照自己的思路发展出分支来。

🎉 你的贡献通过了