Fix some mistakes in how-to-contribute.md

Author: aeilot

_articles/zh-hans/how-to-contribute.md

@@ -133,11 +133,11 @@ redirect_from: /zh-cn/how-to-contribute/
 
 ### 其实不必一定是软件项目！
 
-尽管人们一提起"开源"二字，默认就是指开源软件，其实不尽然，开源可以是任何事情的修饰，而不仅仅是指软件而言的。比如图书、食谱、列表、以及任何可以开源的项目类。
+尽管人们一提起"开源"二字，默认就是指开源软件，其实不尽然，开源可以是任何事情的修饰，而不仅仅是指软件。比如图书、食谱、列表、以及任何可以开源的项目类别。
 
 举例来说：
 
-* @sindresorhus 创建了 ["惊奇" 列表](https://github.com/sindresorhus/awesome)
+* @sindresorhus 创建了 ["令人惊叹的" 列表](https://github.com/sindresorhus/awesome)
 * @h5bp 维护了针对前端开发者的[面试题](https://github.com/h5bp/Front-end-Developer-Interview-Questions)
 * @stuartlynn 和 @nicole-a-tesla 制作了[收集关于海雀的有趣的事实](https://github.com/stuartlynn/puffin_facts)
 
@@ -153,7 +153,7 @@ redirect_from: /zh-cn/how-to-contribute/
   </p>
 </aside>
 
-为开源做贡献，除了单词拼写错误之外，大多数时候就像是走在陌生人中间，浑身上下不适。这就像人们已经在西边讨论的非常深入了，你突然开始讲东，肯定会让人感到不舒服。
+为开源做贡献，除了单词拼写错误之外，大多数时候就像是走在陌生人中间，浑身上下不适。这就像人们已经讨论西边的事情讨论得非常深入了，你突然开始讲东边的事情，肯定会让人感到不舒服。
 
 与其盲目的在项目中游荡，不如静下心来学习规则。这样反而会让你的想法被注意到，也会有人听到你的声音。
 
@@ -173,22 +173,22 @@ redirect_from: /zh-cn/how-to-contribute/
 * **贡献者:** 只要是为项目做出了贡献，就算。
 * **社区成员:** 那些使用项目的人们。他们或许是积极的讨论者，又或者是为项目的方向提出意见的人。
 
-一个较大的项目，可能下面还会细分子社区，或者是针对不同的任务分成不同的小组，比如工具小组、分流、社区事务、以及活动组织等。径直到项目到 web 站点，找到"团队"页面，或者是查看治理文档，从而获得类似到信息。
+一个较大的项目，可能下面还会细分子社区，或者是针对不同的任务分成不同的小组，比如工具小组、分流、社区事务、以及活动组织等。径直到项目到网站，找到"团队"页面，或者是查看治理文档，从而获得类似到信息。
 
 靠谱的开源项目，一般都会有文档的，这些文档文件通常会在代码仓库的顶级目录列出。
 
 * **LICENSE:** 根据开源软件的定义，每一个开源项目必须是有[开源许可协议](https://choosealicense.com)的. 可以这么认为：假如说某个项目源码开放，但是没有任何的许可协议，那么它就不能叫做开源。
 * **README:** README 是一个介绍性的说明文件，对初次光临社区的人们表示欢迎，它通常会解释项目有何用处，为何发起，以及如何快速入门等。
-* **CONTRIBUTING:**  READMEs 帮助人们来认识项目，CONTRIBUTING 这个文件则是帮助对项目如何做贡献。它解释了目前项目需要什么样类型对贡献者，社区的流程是什么样的。并非所有的项目都会有这个文件，它某种程度上也是展示项目对于贡献者的友好程度。
-* **CODE_OF_CONDUCT:** 顾名思义，即是一些参与社区时的一些礼仪、说话方式、行为等，帮助形成一种友好的氛围，不是所有的项目都会撰写行为准则文件，它某种程度上也是展示项目对于贡献者的友好程度。
+* **CONTRIBUTING:**  README 文件帮助人们来认识项目，而 CONTRIBUTING 文件则是告诉人们对项目如何做贡献。它解释了目前项目需要什么样类型的贡献者，社区的流程是什么样的。并非所有的项目都会有这个文件，它某种程度上也是展示项目对于贡献者的友好程度。
+* **CODE_OF_CONDUCT:** 顾名思义，即是一些参与社区时的一些礼仪、说话方式、行为等，让社区形成一种友好的氛围，不是所有的项目都会撰写行为准则文件，它某种程度上也是展示项目对于贡献者的友好程度。
 * **其它文档:** 有些项目也许还有其它文档，例如教程、导游，或者是治理规则，这在大型项目中常见。
 
 此外，开源项目还会利用如下一些工具来进行组织讨论，阅读这些归档对于理解社区的想法、是如何工作的有非常大的作用。
 
 * **问题追踪:** 这里是人们讨论项目相关问题的地方。
 * **Pull requests:** 审核代码、以及相关的问题讨论。
-* **论坛或邮件列表:** 一些项目会实用会话式的主题（例如 _"How do I..."_ 或 _"What do you think about..."_ 来替代 Bug 报告或特性请求）。然而有一些项目关于讨论全部实用问题追踪。
-* **即时在线聊天:** 有一些项目会实用聊天频道（诸如 Slack 或 IRC），从而能够随意的谈话、协作和快速交流。
+* **论坛或邮件列表:** 一些项目会使用会话式的主题（例如 _"How do I..."_ 或 _"What do you think about..."_ 来替代 Bug 报告或特性请求）。然而有一些项目关于讨论全部实用问题追踪。
+* **即时在线聊天:** 有一些项目会使用聊天频道（诸如 Slack 或 IRC），从而能够随意的谈话、协作和快速交流。
 
 ## 找一个项目开始贡献
 
@@ -220,7 +220,7 @@ redirect_from: /zh-cn/how-to-contribute/
 
 ### 提交贡献之前的检查列表
 
-当你找到了你打算贡献的项目时，在进一步行动之前，作一个快速的扫描工作，以确保项目是否接受贡献的。否则，你煞费苦心的工作可能没有任何的回报。
+当你找到了你打算贡献的项目时，在进一步行动之前，做一个快速的扫描工作，以确保项目是否接受贡献的。否则，你煞费苦心的工作可能没有任何的回报。
 
 这是一个简易的检查表，用来评估一个项目是否适合新的贡献者。
 
@@ -300,7 +300,7 @@ redirect_from: /zh-cn/how-to-contribute/
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-    现下有多少处于开放状态的 PR？
+    现在有多少处于开放状态的 PR？
   </label>
 </div>
 
@@ -420,27 +420,27 @@ redirect_from: /zh-cn/how-to-contribute/
 >
 > 😢 _"你为什么不修复我的问题？这难道不是你的项目吗？"_
 
-**尊重社区的决定。** 你的想法可能会和社区的优先级、愿景等有差异，他们可能对于你的想法提供了反馈和最后的决定的理由，这时你应该去积极的讨论，并寻求妥协的办法，维护者必须慎重的考虑你的想法。但是如果你实在是不能同意社区的做法，你可以坚持自己！保持自己的分支，或者另起炉灶。
+**尊重社区的决定。** 你的想法可能会和社区的优先级、愿景等有差异，他们可能对于你的想法提供了反馈和最后决定的理由，这时你应该去积极的讨论，并寻求妥协的办法，维护者必须慎重的考虑你的想法。但是如果你实在是不能同意社区的做法，你可以坚持下去！继续维护自己的分支，或者另起炉灶。
 
-> 😇 _"你不能支持我的用例，我蛮失望，但是你的解释仅仅是对一小部分用户起作用，我理解是为什么。感谢你的耐心倾听。"_
+> 😇 _"你不能支持我的用例，我很失望，但是你的解释仅仅是对一小部分用户起作用，我理解为什么。感谢你的耐心倾听。"_
 >
 > 😢 _"你为什么不支持我的用例？这是不可接受的！"_
 
-**最重要的是，保持优雅** 开源社区有来自世界各地的协作者，所以跨语言、文化、地理位置和时区的情况下会丢失上下文语境。另外，书面交流使得传达语气或情绪变得更加困难。对话过程中善意的理解对方的意图。礼貌地反驳他人的想法，询问更多的上下文语境，或进一步澄清你的立场都是好事。我们要让互联网变得更加美好。
+**最重要的是，保持优雅** 开源社区有来自世界各地的协作者，所以跨语言、文化、地理位置和时区的情况下会丢失上下文语境。另外，书面交流使得传达语气或情绪变得更加困难。对话过程中善意地理解对方的意图、礼貌地反驳他人的想法，询问更多的上下文语境，或进一步澄清你的立场都是好事。我们要让互联网变得更加美好。
 
 ### 收集上下文
 
-在正式开始之前，做一些快速的检查项，以确保你的想法是没有被讨论过的。遍历项目的 README、问题（开放的和关闭的都算）、邮件列表、Stack Overflow。毋需去花好几个小时去全部折腾一遍，但是使用几个关键的词汇来搜索一下是必要的。
+在正式开始之前，做一些快速的检查项，以确保没有人讨论过你的想法。看一遍项目的 README、问题（开放的和关闭的都算）、邮件列表、Stack Overflow。不需去花好几个小时去全部折腾一遍，但是使用几个关键的词汇来搜索一下是必要的。
 
 如果你没有找到和你想法一样的内容，你就可以继续了。如果项目是在 GitHub 上的话，你可以通过开启一个 issue 或 PR：
 
 * **Issues** 开启一次对话或讨论
 * **Pull requests** 请求接受自己的解决方法
-* **少量的沟通，** 诸如澄清或how-to的问题，尝试到 Stack Overflow、IRC、Slack 或其它聊天频道。
+* **少量的沟通，** 诸如澄清或"怎样做"的问题，尝试到 Stack Overflow、IRC、Slack 或其它聊天平台去问。
 
 在你创建 issue 和 PR 之前，请检查项目的贡献者文档（文件名通常叫做 CONTRIBUTING，或者就直接包含在README中），找一些你需要的较具体的东西，例如，他们会要求你遵循某个模版，或者是要求你使用某个测试。
 
-如果你做的是一个非常实际的贡献，在正式开启之前，先创建一个 issue。监视项目是很有帮助的（在 GitHub，[点击 "Watch"](https://help.github.com/articles/watching-repositories/)，所有的对话都会通知到你），要让社区的成员们知道你要做的工作，免得你做了之后，再让他们知道，他们不同意，就浪费了。
+如果你做的是一个非常实际的贡献，在正式开启之前，先创建一个 issue。Watch 这个项目是很有帮助的（在 GitHub，[点击 "Watch"](https://help.github.com/articles/watching-repositories/)，所有的对话都会通知你），要让社区的成员们知道你要做的工作，免得你做了之后，再让他们知道，他们不同意，就浪费了。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
@@ -478,7 +478,7 @@ redirect_from: /zh-cn/how-to-contribute/
 * **[Fork 代码仓库](https://guides.github.com/activities/forking/)** 并克隆到本地，在本地的仓库配置"上游"为远端仓库。这样你可以在提交你的 PR 时保持和"上游"同步，会减少很多解决冲突的时间。(更多关于同步的说明，请参考[这里](https://help.github.com/articles/syncing-a-fork/).)
 * **[创建一个分支](https://guides.github.com/introduction/flow/)** 用于自己编辑。
 * **参考任何相关的issue** 或者在你的 PR 中支持文档(比如. "Closes #37.")
-* **包含之前和之后的快照** 如果你的改动是包含了不同的 HTML/CSS。在你的 PR 中拖拉相应的图片。
+* **包含之前和之后的快照** 如果你的改动是包含了不同的 HTML/CSS。在你的 PR 中加入相应的图片。
 * **测试你的改动！** 若测试用例存在的话，跑一遍，以覆盖你的更改，若没有的话，则创建相应的用例。无论测试是否存在，一定要确保你的改动不会破坏掉现有的项目。
 * **和项目现有的风格保持一致** 尽你最大的努力，这也就是意味着在使用缩进、分号、以及注释很可能和你自己的风格大相径庭，但是为了节省维护者的精力，以及未来他人更好的理解和维护，还请你容忍一下。
 
@@ -488,7 +488,7 @@ redirect_from: /zh-cn/how-to-contribute/
 
 很不错，你做到了！恭贺你成为开源贡献者。我们希望这是一个良好的开端。
 
-在你提交了贡献之后，下面几种情形中的某种是可能发生的：
+在你提交了贡献之后，下面几种情形是可能发生的：
 
 ### 😭 没有人响应你。