diff --git a/Gemfile.lock b/Gemfile.lock
index ac10b70a90d..911f4374a79 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -13,7 +13,6 @@ GEM
       execjs
     coffee-script-source (1.11.1)
     colorator (1.1.0)
-    colorize (0.8.1)
     commonmarker (0.17.13)
       ruby-enum (~> 0.5)
     concurrent-ruby (1.1.5)
@@ -86,13 +85,13 @@ GEM
     html-pipeline (2.11.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    html-proofer (3.10.2)
+    html-proofer (3.11.0)
       activesupport (>= 4.2, < 6.0)
       addressable (~> 2.3)
-      colorize (~> 0.8)
       mercenary (~> 0.3.2)
       nokogiri (~> 1.9)
       parallel (~> 1.3)
+      rainbow (~> 3.0)
       typhoeus (~> 1.3)
       yell (~> 2.0)
     http_parser.rb (0.6.0)
@@ -224,6 +223,7 @@ GEM
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
     public_suffix (3.1.0)
+    rainbow (3.0.0)
     rake (12.3.2)
     rb-fsevent (0.10.3)
     rb-inotify (0.10.0)
diff --git a/_articles/id/starting-a-project.md b/_articles/id/starting-a-project.md
index 5d08f14f5a2..f1c276d7109 100644
--- a/_articles/id/starting-a-project.md
+++ b/_articles/id/starting-a-project.md
@@ -324,7 +324,7 @@ Jika Anda perseorangan:
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox8" class="overflow-hidden d-block text-normal">
-  Anda telah mengunjungi kantor hukum dan/atau membahami hak cipta dan kebijakan open source pada perusahaan Anda (jika Anda merupakan karyawan pada sebuah perusahaan)
+  Anda telah mengunjungi kantor hukum dan/atau memahami hak cipta dan kebijakan open source pada perusahaan Anda (jika Anda merupakan karyawan pada sebuah perusahaan)
   </label>
 </div>
 
@@ -354,7 +354,7 @@ Jika Anda merupakan perusahaan atau organisasi:
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox12" class="overflow-hidden d-block text-normal">
-    Minimal terdapat dua orang yang memiliki akses admministratif pada proyek
+    Minimal terdapat dua orang yang memiliki akses administratif pada proyek
   </label>
 </div>
 
diff --git a/_articles/leadership-and-governance.md b/_articles/leadership-and-governance.md
index b0981efb31a..ab4c7977007 100644
--- a/_articles/leadership-and-governance.md
+++ b/_articles/leadership-and-governance.md
@@ -3,6 +3,15 @@ lang: en
 title: Leadership and Governance
 description: Growing open source projects can benefit from formal rules for making decisions.
 class: leadership
+toc:
+  understanding-governance-for-your-growing-project: "Understanding governance for your growing project"
+  what-are-examples-of-formal-roles-used-in-open-source-projects: "What are examples of formal roles used in open source projects?"
+  how-do-i-formalize-these-leadership-roles: "How do I formalize these leadership roles?"
+  when-should-i-give-someone-commit-access: "When should I give someone commit access?"
+  what-are-some-of-the-common-governance-structures-for-open-source-projects: "What are some of the common governance structures for open source projects?"
+  do-i-need-governance-docs-when-i-launch-my-project: "Do I need governance docs when I launch my project?"
+  what-happens-if-corporate-employees-start-submitting-contributions: "What happens if corporate employees start submitting contributions?"
+  do-i-need-a-legal-entity-to-support-my-project: "Do I need a legal entity to support my project?"
 order: 6
 image: /assets/images/cards/leadership.png
 related:
diff --git a/_articles/zh-cn/best-practices.md b/_articles/zh-cn/best-practices.md
index 150585ebfe6..4dbefe18356 100644
--- a/_articles/zh-cn/best-practices.md
+++ b/_articles/zh-cn/best-practices.md
@@ -16,7 +16,7 @@ related:
 
 在项目的起步阶段，你会不断尝试着实现自己的新想法，也能够基于自己想要的作出决定。随着项目逐渐的开始流行，就会发现你的大部分时间都花在了与用户、贡献者打交道上。
 
-维护一个项目需要的不仅仅是写代码的能力。有些时候会有一个你意想不到的的事情要应付，但是这对一个项目的成长也很重要（相对于代码来说），我们收集了一些小技巧来让你的维护工作变得稍轻松些，这些技巧，涉及范围颇广，从写文档到管理社区都有所涉猎。
+维护项目需要的不仅仅是编码。有些意料之外的任务，对于项目的持续发展同样重要。我们收集了几种方法让你的维护工作变得稍轻松些，这些技巧，涉及范围颇广，从编写文档到管理社区都有所涉及。
 
 ## Documenting your processes
 
@@ -61,7 +61,7 @@ related:
 * 怎样的贡献才会被复查和接受（_需要测试吗？提Issue有模板吗？_）
 * 你本人会接受什么类型的贡献？（_你是不是只希望在某些部分的代码上需要别人的帮助？_）
 * 在合适的时候跟进项目（比如说 _如果你在七天之内没有收到maintainer的回复，而且依旧没有其它任何的响应，那么就直接找Ta。_）
-* 你会在这个项目上话多少时间（比如说 "_我们每星期只会在这个项目上花5个小时_"）
+* 你会在这个项目上花多少时间（比如说 "_我们每星期只会在这个项目上花5个小时_"）
 
 [Jekyll](https://github.com/jekyll/jekyll/tree/master/docs)、[CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules)、以及 [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) 均是为维护者和贡献者提供了很好的基本规则的项目.乃业内典范。
 
@@ -101,7 +101,7 @@ related:
 
 别因为自己感到内疚或者想做一个好人就把你不想接受的贡献继续保留。随着时间的流逝，这些你没有回答的issue和PR会让你觉得很不爽。
 
-更好的方式是马上关掉你不想接受的贡献。如果你的项目已经保守积压的issue的折磨，@steveklabnik 可以给你点儿建议，[如何高效的解决issue](https://words.steveklabnik.com/how-to-be-an-open-source-gardener)。
+更好的方式是马上关掉你不想接受的贡献。 如果你的项目已经积压大量的问题，@steveklabnik 可以给你点儿建议，[如何高效的解决issue](https://words.steveklabnik.com/how-to-be-an-open-source-gardener)。
 
 第二点，忽略别人的贡献等于是在社区传递了一个负面的信号。让人感觉提交一个贡献是蛮恐惧的事情，尤其是对于刚加入的新手来说。即使你不接受他们的贡献，告诉他们为什么然后致谢。这会让人觉得更舒服。
 
diff --git a/_articles/zh-cn/building-community.md b/_articles/zh-cn/building-community.md
index a77d36f3a88..8661202861a 100644
--- a/_articles/zh-cn/building-community.md
+++ b/_articles/zh-cn/building-community.md
@@ -26,12 +26,12 @@ related:
 
 从你的文档开始：
 
-* **让大家很容易上手。** [一份友好的 README](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-02.md#编写readme)以及清晰的代码示例将让大家很容易的上手。
-* **清楚的解释如何做贡献**，使用[你的CONTRIBUTING file](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-02.md#编写你的贡献指南)以及持续更新issues。
+* **让大家很容易上手。** [一份友好的 README](../starting-a-project/#writing-a-readme)以及清晰的代码示例将让大家很容易的上手。
+* **清楚的解释如何做贡献**，使用[你的CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines)以及持续更新issues。
 
 好的文档能够邀请他人参与你们项目的互动。最终，一些人会开一个issue或者pull request。将这些互动视为机会，将他们转移到漏斗的下方。
 
-* **当一些人选择了你们的项目，请对他们表示感谢！** 仅仅只是一次消极的经历就足以让一些人再也不想回来。
+* **当一些人选择了你们的项目，请对他们表示感谢！** 一次糟糕的体验就可能失去一个用户。
 * **及时回应。** 如果你们一个月都没有回答他们的问题，他们可能早已忘记了你们的项目。
 * **对你以后接受的所有贡献者持开放态度。** 很多贡献者是从一份bug报告或者小的修复开始的。这里有[很多为项目做贡献的方式](../how-to-contribute/#what-it-means-to-contribute)。让大家选择他们喜欢的方式。
 * **如果你不赞成一个贡献，** 首先你需要对他们的想法表示感谢，同时 [解释为什么](../best-practices/#learning-to-say-no)它不适合项目，如果有必要的话你可以给出相关的文档链接。
@@ -116,14 +116,14 @@ related:
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/karissa?s=180" class="pquote-avatar" alt="avatar">
 
-  事实上是，拥有一个支持性社区才是项目成功的关键。如果没有来自我的同事，互联网上一些友好的陌生人，以及聊天渠道IRC的帮助，我不可能做好这些工作。（。。。）不要退而求其次。不要满足于混蛋。
+  事实上是，拥有一个支持性社区才是项目成功的关键。如果没有来自我的同事，互联网上一些友好的陌生人，以及聊天渠道IRC的帮助，我不可能做好这些工作。（。。。）不要退而求其次。不要容忍混蛋。
 
   <p markdown="1" class="pquote-credit">
 — @karissa, ["如何运营一个 FOSS 项目"](https://okdistribute.xyz/post/okf-de)
   </p>
 </aside>
 
-对项目的微不足道的问题进行定期辩论会分散别人的注意力，包括你自己，要将精力几种在重要的任务上，新人如果看见这样的情景，他们可能不会加入到项目中来。
+关于项目琐碎方面的定期辩论会分散其他人（包括您）的注意力，使他们无法专注于重要任务。新人可能会看到这些对话而不想参加。
 
 当发现社区中有消极的行为时，要即时、公然的指出来。特别说明的是，要用坚定的语气解释他们的行为为什么是不可接受的。如果这种问题继续发生，你有必要[要求他们离开](../code-of-conduct/#enforcing-your-code-of-conduct)。你的[行为准则](../code-of-conduct/)是为这些情景准备的建设性指南。
 
diff --git a/_articles/zh-cn/getting-paid.md b/_articles/zh-cn/getting-paid.md
index aa4bd5efca5..252269e719c 100644
--- a/_articles/zh-cn/getting-paid.md
+++ b/_articles/zh-cn/getting-paid.md
@@ -42,7 +42,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
-  询问任何一位开源项目的维护著，他们都会告诉你关于管理一个项目需要花费大量时间的真相。你拥有客户，你的为他们修复问题，你创建新的功能。这些都需要真正的花时间去做的事情。
+  询问任何一位开源项目维护者，他们会告诉您管理项目的工作量的实际情况。你拥有客户，你要为他们解决问题，你要创建新功能，这些都需要花时间去做。
   <p markdown="1" class="pquote-credit">
 — @ashedryden, ["无偿劳动的伦理和开源软件社区"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
   </p>
diff --git a/_articles/zh-cn/how-to-contribute.md b/_articles/zh-cn/how-to-contribute.md
index 30f19652aef..02a5c6c2c1d 100644
--- a/_articles/zh-cn/how-to-contribute.md
+++ b/_articles/zh-cn/how-to-contribute.md
@@ -60,7 +60,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
-  我被大家所熟知是因为为 CocoaPods 做了一些事, 其实大伙并不知道我实际并没有为 CocoaPods本身做了什么，我大多数的工作是诸如撰写文档、品牌宣传之类的。
+  我被大家所熟知是因为为 CocoaPods 做了一些事, 其实大伙并不知道我实际并没有为 CocoaPods 本身做了什么，我大多数的工作是诸如撰写文档、品牌宣传之类的。
   <p markdown="1" class="pquote-credit">
 — @orta, ["默认迁移到开源软件"](https://realm.io/news/orta-therox-moving-to-oss-by-default/)
   </p>
@@ -70,7 +70,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/brettcannon?s=180" class="pquote-avatar" alt="avatar">
-  我第一次接触Python开发团队（简称 python-dev)是在 2002年6月17日，当时我是向其邮件列表发送了一份邮件，是关于请求通过我的补丁的。我很快就又发现了开源的bug，于是决定开始为小组收集邮件摘要，然后他们给了我一个澄清问题的理由，但是更加重要的是，我能够捕获到某人指出需要修复的问题。
+  我第一次接触 Python 开发团队（简称 python-dev）是在 2002年6月17日，当时我是向其邮件列表发送了一份邮件，是关于请求通过我的补丁的。我很快就又发现了开源的 bug，于是决定开始为小组收集邮件摘要，然后他们给了我一个澄清问题的理由，但是更加重要的是，我能够捕获到某人指出需要修复的问题。
   <p markdown="1" class="pquote-credit">
 — @brettcannon, ["维护者的故事"](https://github.com/open-source/stories/brettcannon)
   </p>
@@ -94,12 +94,12 @@ related:
 * 撰写和改进项目的文档
 * 能够以实例来展示项目该如何使用的
 * 为项目撰写新闻稿，或者到邮件列表高调布道
-* 为项目撰写教程， [一如 pypa 的贡献者所做的](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* 为项目撰写教程，[一如 pypa 的贡献者所做的](https://github.com/pypa/python-packaging-user-guide/issues/194)
 * 翻译项目的文档为本土语言
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
-  说真心话， \[文档\] 是非常重要的. 目前Babel的文档已经很棒了，这也是其杀手锏的特性之一。当然，还有一些章节需要大家的完善，即使是随便在哪儿增加一个段落都很感激。
+  说真心话， \[文档\] 是非常重要的. 目前 Babel 的文档已经很棒了，这也是其杀手锏的特性之一。当然，还有一些章节需要大家的完善，即使是随便在哪儿增加一个段落都很感激。
   <p markdown="1" class="pquote-credit">
 — @kittens, ["贡献者召集令"](https://github.com/babel/babel/issues/1347)
   </p>
@@ -128,7 +128,7 @@ related:
 
 * 为他人的提交审核代码
 * 为如何利用项目撰写教程
-* 为其他贡献者做导师， [正如 @ereichert 为 @bronzdoc 所做的那样，哦，是 Rust 项目](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+* 为其他贡献者做导师，[正如 @ereichert 为 @bronzdoc 所做的那样，哦，是 Rust 项目](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
 
 ### 其实不必一定是软件项目！
 
@@ -146,7 +146,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
-  如果你跟着了一条issue，还发现了令人感到困惑的事情，这很正常，不是你一个人这样。这些工具需要大量的隐式的知识，但是总会有人带着你熟悉这些，当然你要找他们问对的问题。
+  如果你跟着了一条 issue，还发现了令人感到困惑的事情，这很正常，不是你一个人这样。这些工具需要大量的隐式的知识，但是总会有人带着你熟悉这些，当然你要找他们问对的问题。
   <p markdown="1" class="pquote-credit">
 — @shaunagm, ["如何为开源做贡献"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
   </p>
@@ -172,21 +172,21 @@ related:
 * **贡献者:** 只要是为项目做出了贡献，就算。
 * **社区成员:** 那些实用项目的人们。他们或许是积极的讨论者，又或者是为项目的方向提出意见的人。
 
-一个较大的项目，可能下面还会细分子社区，或者是针对不同的任务分成不同的小组，比如工具小组、分流、社区事务、以及活动组织等。径直到项目到web站点，找到"团队"页面，或者是查看治理文档，从而获得类似到信息。
+一个较大的项目，可能下面还会细分子社区，或者是针对不同的任务分成不同的小组，比如工具小组、分流、社区事务、以及活动组织等。径直到项目到 web 站点，找到"团队"页面，或者是查看治理文档，从而获得类似到信息。
 
-靠谱的开源项目，一般都会有一个文档的，这些文档文件通常会在代码仓库的顶级目录列出。
+靠谱的开源项目，一般都会有文档的，这些文档文件通常会在代码仓库的顶级目录列出。
 
-* **许可协议:** 根据开源软件的定义，每一个开源项目必须是有[开源许可协议](https://choosealicense.com)的. 可以这么认为：假如说某个项目源码开放，但是没有任何的许可协议，那么它就不能叫做开源。
-* **README:**  README 是一个介绍性的说明文件，对初次光临社区对人们表示欢迎，它通常会解释项目有何用处，为何发起，以及如何快速入门等。
-* **贡献:**  READMES 帮助人们来认识项目，贡献这个文件则是帮助对项目如何做贡献。它解释了目前项目需要什么样类型对贡献者，社区对流程是啥样的。并非所有的项目都会有这个文件，它某种程度上也是展示项目对于贡献者的友好程度。
-* **行为准则:** 顾名思义，即是一些参与社区时的一些礼仪、说话方式、行为等，帮助形成一种友好的氛围，不是所有的项目都会撰写行为准则文件，它某种程度上也是展示项目对于贡献者的友好程度。
+* **LICENSE:** 根据开源软件的定义，每一个开源项目必须是有[开源许可协议](https://choosealicense.com)的. 可以这么认为：假如说某个项目源码开放，但是没有任何的许可协议，那么它就不能叫做开源。
+* **README:** README 是一个介绍性的说明文件，对初次光临社区的人们表示欢迎，它通常会解释项目有何用处，为何发起，以及如何快速入门等。
+* **CONTRIBUTING:**  READMEs 帮助人们来认识项目，CONTRIBUTING 这个文件则是帮助对项目如何做贡献。它解释了目前项目需要什么样类型对贡献者，社区的流程是什么样的。并非所有的项目都会有这个文件，它某种程度上也是展示项目对于贡献者的友好程度。
+* **CODE_OF_CONDUCT:** 顾名思义，即是一些参与社区时的一些礼仪、说话方式、行为等，帮助形成一种友好的氛围，不是所有的项目都会撰写行为准则文件，它某种程度上也是展示项目对于贡献者的友好程度。
 * **其它文档:** 有些项目也许还有其它文档，例如教程、导游，或者是治理规则，这在大型项目中常见。
 
 此外，开源项目还会利用如下一些工具来进行组织讨论，阅读这些归档对于理解社区的想法、是如何工作的有非常大的作用。
 
 * **问题追踪:** 这里是人们讨论项目相关问题的地方。
 * **Pull requests:** 审核代码、以及相关的问题讨论。
-* **论坛或邮件列表:** 一些项目会实用会话式的主题（例如 _"How do I..."_ 或 _"What do you think about..."_ 来替代Bug报告或特性请求）。然而有一些项目关于讨论全部实用问题追踪。
+* **论坛或邮件列表:** 一些项目会实用会话式的主题（例如 _"How do I..."_ 或 _"What do you think about..."_ 来替代 Bug 报告或特性请求）。然而有一些项目关于讨论全部实用问题追踪。
 * **即时在线聊天:** 有一些项目会实用聊天频道（诸如 Slack 或 IRC），从而能够随意的谈话、协作和快速交流。
 
 ## Finding a project to contribute to
@@ -203,7 +203,7 @@ related:
 
 开源并不是高级俱乐部；它就是由你这样的人所浇铸和打造。**"开源"只是针对这个世界的需要修复的问题的一个梦幻术语罢了。**
 
-你或许在查看 README的时候，发现了损坏的链接，又或者拼写错误。又或者是你是一名新手，使用的过程中发现了问题，又或者是某问题应该在文档中注明。请不要坐视不理，径直绕开，或者是请求他人修复，伸出你的援助之手，解决这些你能看到的问题。而这正是开源的精髓之所在！
+你或许在查看 README 的时候，发现了损坏的链接，又或者拼写错误。又或者是你是一名新手，使用的过程中发现了问题，又或者是某问题应该在文档中注明。请不要坐视不理，径直绕开，或者是请求他人修复，伸出你的援助之手，解决这些你能看到的问题。而这正是开源的精髓之所在！
 
 > [28% 的随意贡献](https://www.igor.pro.br/publica/papers/saner2016.pdf) 就是说明了文档的开源，诸如拼写错误，段落语句调整、或者是翻译。
 
@@ -234,7 +234,7 @@ related:
 
 **项目被接收的提交活跃度**
 
-在主干上确认提交的活跃度。在GitHub上托管的开源项目，你可以在仓库主页上看到这些信息。
+在主干上确认提交的活跃度。在 GitHub 上托管的开源项目，你可以在仓库主页上看到这些信息。
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
@@ -269,14 +269,14 @@ related:
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox6" class="overflow-hidden d-block text-normal">
-    项目的维护者对于处于开放状态的issue响应是否迅速？
+    项目的维护者对于处于开放状态的 issue 响应是否迅速？
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox7" class="overflow-hidden d-block text-normal">
-    是否有讨论很活跃的issue？
+    是否有讨论很活跃的 issue？
   </label>
 </div>
 
@@ -290,23 +290,23 @@ related:
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox9" class="overflow-hidden d-block text-normal">
-    有没有关闭的issue？ (在 GitHub, 点击 "closed" 标签就可以看到所有已经关闭的issue。)
+    有没有关闭的issue？ (在 GitHub, 点击 "closed" 标签就可以看到所有已经关闭的 issue。)
   </label>
 </div>
 
-同样再来看看 PR的情形。
+同样再来看看 PR 的情形。
 
 <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>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox20" class="overflow-hidden d-block text-normal">
-    当提交了PR后，维护者响应是否迅速？
+    当提交了 PR 后，维护者响应是否迅速？
   </label>
 </div>
 
@@ -320,14 +320,14 @@ related:
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox12" class="overflow-hidden d-block text-normal">
-    均是近期的RP吗？
+    均是近期的 RP 吗？
   </label>
 </div>
 
 <div class="clearfix mb-4">
   <input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox13" class="overflow-hidden d-block text-normal">
-    最近有多少PR合并？ (在 GitHub, 点击 RP页面的 "closed" 的标签页来查看已经关闭的标签页。)
+    最近有多少 PR 合并？ (在 GitHub, 点击 RP 页面的 "closed" 的标签页来查看已经关闭的标签页。)
   </label>
 </div>
 
@@ -338,21 +338,21 @@ related:
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox14" class="overflow-hidden d-block text-normal">
-    在issue的问题中，维护者的回答是否非常有帮助？
+    在 issue 的问题中，维护者的回答是否非常有帮助？
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox15" class="overflow-hidden d-block text-normal">
-    人们在issue的讨论中、在线聊天室、论坛是否很友好？
+    人们在 issue 的讨论中、在线聊天室、论坛是否很友好？
   </label>
 </div>
 
 <div class="clearfix mb-2">
   <input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
   <label for="cbox16" class="overflow-hidden d-block text-normal">
-    PR是否被review？
+    PR 是否被 review？
   </label>
 </div>
 
@@ -381,7 +381,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
-  \[作为一名新手,\] 我很快的就意识到，我若是要关闭一条issue时，我不得不问更多的问题。我浏览了代码库，一旦我觉得有什么问题的时候，我就得需要更多的指点，瞧！ 在我得到所有的所需要的信息后，我就可以解决这个问题！
+  \[作为一名新手,\] 我很快的就意识到，我若是要关闭一条 issue 时，我不得不问更多的问题。我浏览了代码库，一旦我觉得有什么问题的时候，我就得需要更多的指点，瞧！ 在我得到所有的所需要的信息后，我就可以解决这个问题！
   <p markdown="1" class="pquote-credit">
 — @shubheksha, [一名菜鸟进入开源世界的坎坷之旅](https://medium.freecodecamp.com/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39#.pcswr2e78)
   </p>
@@ -409,11 +409,11 @@ related:
 
 **让所有的沟通都是在公开场合下进行。** 哪怕是很不起眼的小事，也不要去给维护者发私信，除非是你要分享一些敏感信息（诸如安全问题或严重的过失）。你若能够保持谈话是公开的，很多人可以你们交换的意见中学习和受益。
 
-> 😇 _(评论) "@维护者 你好！我们该如何处理这个PR？"_
+> 😇 _(评论) "@维护者 你好！我们该如何处理这个 PR？"_
 >
-> 😢 _(邮件) "你好，非常抱歉给发信，但是我实在很希望你能看一下我提交的PR。"_
+> 😢 _(邮件) "你好，非常抱歉给发信，但是我实在很希望你能看一下我提交的 PR。"_
 
-**大胆的提问（但是要谨慎！）。** 每个人参与社区，开始的时候都是新手，哪怕是非常有经验的贡献者也一样，在刚进入一个新的项目的时候，也是新手。出于同样的原因,甚至长期维护人员并不总是熟悉一个项目的每一部分。给他们同样的耐心,你也会得到同样的回报。
+**大胆的提问（但是要谨慎！）。** 每个人参与社区，开始的时候都是新手，哪怕是非常有经验的贡献者也一样，在刚进入一个新的项目的时候，也是新手。出于同样的原因,甚至长期维护人员并不总是熟悉一个项目的每一部分。给他们同样的耐心，你也会得到同样的回报。
 
 > 😇 _"感谢查看了这个错误，我按照您的建议做了，这是输出结果。"_
 >
@@ -425,21 +425,21 @@ related:
 >
 > 😢 _"你为什么不支持我的用例？这是不可接受的！"_
 
-**以上几点，要铭记在心。** 开源是由来自世界各地的人们共同协作实现的。面临的问题是跨语言、跨文化、不同的地理为止、不同的时区，另外，撰写文字的沟通更是难上加难，无法传达语气和情绪。请让这些会话都充满善意吧！在以下情形中请保持礼貌：推动一个想法、请求更多的上下文、进一步澄清你的立场。既然你在互联网找到了自己的所需，那么请尝试让它变得更好！
+**最重要的是，保持优雅** 开源社区有来自世界各地的协作者，所以跨语言、文化、地理位置和时区的情况下会丢失上下文语境。另外，书面交流使得传达语气或情绪变得更加困难。对话过程中善意的理解对方的意图。礼貌地反驳他人的想法，询问更多的上下文语境，或进一步澄清你的立场都是好事。我们要让互联网变得更加美好。
 
 ### 收集上下文
 
 在正式开始之前，做一些快速的检查项，以确保你的想法是没有被讨论过的。遍历项目的 README、问题（开放的和关闭的都算）、邮件列表、Stack Overflow。毋需去花好几个小时去全部折腾一遍，但是使用几个关键的词汇来搜索一下是必要的。
 
-如果你没有找到和你想法一样的内容，你就可以继续了。如果项目是在 GitHub 上的话，你可以通过开启一个issue或PR：
+如果你没有找到和你想法一样的内容，你就可以继续了。如果项目是在 GitHub 上的话，你可以通过开启一个 issue 或 PR：
 
 * **Issues** 开启一次对话或讨论
 * **Pull requests** 请求接受自己的解决方法
-* **少量的沟通，** 诸如澄清或how-to的问题，尝试到 Stack Overflow 、IRC、Slack或其它聊天频道。
+* **少量的沟通，** 诸如澄清或how-to的问题，尝试到 Stack Overflow、IRC、Slack 或其它聊天频道。
 
-在你创建issue和PR之前，请检查项目的贡献者文档（文件名通常叫做 CONTRIBUTING，或者就直接包含在README中），找一些你需要的较具体的东西，例如，他们会要求你遵循某个模版，或者是要求你使用某个测试。
+在你创建 issue 和 PR 之前，请检查项目的贡献者文档（文件名通常叫做 CONTRIBUTING，或者就直接包含在README中），找一些你需要的较具体的东西，例如，他们会要求你遵循某个模版，或者是要求你使用某个测试。
 
-如果你做的是一个非常实际的贡献，在正式开启之前，先创建一个issue。监视项目是很有帮助的（在GitHub，[点击 "Watch"](https://help.github.com/articles/watching-repositories/)，所有的对话都会通知到你），要让社区的成员们知道你要做的工作，免得你做了之后，再让他们知道，他们不同意，就浪费了。
+如果你做的是一个非常实际的贡献，在正式开启之前，先创建一个 issue。监视项目是很有帮助的（在 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">
@@ -457,31 +457,31 @@ related:
 * 讨论一个高级主题或想法(例如. 社区、远景、政策等)
 * 期望实现某新的特性，或者其它项目的想法
 
-在issue的沟通中几点实用的技巧:
+在 issue 的沟通中几点实用的技巧:
 
-* **如果你刚好看到一个开放的issue，恰是你打算解决的，** 添加评论，告诉他人你将负责这个。这样的话，可以避免他人重复劳动。
-* **如果说某个issue已经开放很久了，** 这可能是已经有人正在解决中，又或者是早已经解决过了，所以也请添加评论，在打算开启工作之前，最好是确认一下。
-* **如果你创建了一issue，但是没多久自己解决了，** 也要添加评论，让其他人知道，然后关闭该issue。记录本身就是为社区的贡献。
+* **如果你刚好看到一个开放的 issue，恰是你打算解决的，** 添加评论，告诉他人你将负责这个。这样的话，可以避免他人重复劳动。
+* **如果说某个 issue 已经开放很久了，** 这可能是已经有人正在解决中，又或者是早已经解决过了，所以也请添加评论，在打算开启工作之前，最好是确认一下。
+* **如果你创建了一个 issue，但是没多久自己解决了，** 也要添加评论，让其他人知道，然后关闭该 issue。记录本身就是为社区的贡献。
 
 ### 创建 pull request
 
 在下面的情形时，请你务必使用PR：
 
 * 提交补丁 (例如，纠正拼写错误、损坏的链接、或者是其它较明显的错误）
-* 开始一项别人请求的任务，或者是过去在issue中早就讨论过的
+* 开始一项别人请求的任务，或者是过去在 issue 中早就讨论过的
 
-一个 PR 并不代表着工作已经完成。它通常是尽早的开启一个PR，是为了其他人可以观看或者给作者反馈意见。只需要在子标题标记为"WIP"（正在进行中）。作者可以在后面添加很多评论。
+一个 PR 并不代表着工作已经完成。它通常是尽早的开启一个 PR，是为了其他人可以观看或者给作者反馈意见。只需要在子标题标记为"WIP"（正在进行中）。作者可以在后面添加很多评论。
 
-如果说项目是托管在 GitHub上的，以下是我们总结出的提交RP的建议：
+如果说项目是托管在 GitHub 上的，以下是我们总结出的提交 RP 的建议：
 
-* **[Fork 代码仓库](https://guides.github.com/activities/forking/)** 并克隆到本地，在本地的仓库配置"上游"为远端仓库。这样你可以在提交你的PR时保持和"上游"同步，会减少很多解决冲突的时间。(更多关于同步的说明，请参考[这里](https://help.github.com/articles/syncing-a-fork/).)
+* **[Fork 代码仓库](https://guides.github.com/activities/forking/)** 并克隆到本地，在本地的仓库配置"上游"为远端仓库。这样你可以在提交你的 PR 时保持和"上游"同步，会减少很多解决冲突的时间。(更多关于同步的说明，请参考[这里](https://help.github.com/articles/syncing-a-fork/).)
 * **[创建一个分支](https://guides.github.com/introduction/flow/)** 用于自己编辑。
-* **参考任何相关的issue** 或者在你的RP中支持文档(比如. "Closes #37.")
-* **包含之前和之后的快照** 如果你的改动是包含了不同的 HTML/CSS。在你的PR中拖拉相应的图片。
+* **参考任何相关的issue** 或者在你的 RP 中支持文档(比如. "Closes #37.")
+* **包含之前和之后的快照** 如果你的改动是包含了不同的 HTML/CSS。在你的 PR 中拖拉相应的图片。
 * **测试你的改动！** 若测试用例存在的话，跑一遍，以覆盖你的更改，若没有的话，则创建相应的用例。无论测试是否存在，一定要确保你的改动不会破坏掉现有的项目。
 * **和项目现有的风格保持一致** 尽你最大的努力，这也就是意味着在使用缩进、分号、以及注释很可能和你自己的风格大相径庭，但是为了节省维护者的精力，以及未来他人更好的理解和维护，还请你容忍一下。
 
-如果这是你第一次提交PR。可以浏览[PR制造](http://makeapullrequest.com/)的文档，这是 @kentcdodds 专门为初次创建PR的人写的公开的资料。
+如果这是你第一次提交 PR。可以浏览 [PR 制造](http://makeapullrequest.com/)的文档，这是 @kentcdodds 专门为初次创建 PR 的人写的公开的资料。
 
 ## What happens after you submit a contribution
 
@@ -503,13 +503,13 @@ related:
 
 被要求对你的提交进行更改是很常见的，无论是对你的实现上的反馈，还是你代码改动上的反馈。
 
-当有人提出变更时，请表现出大度的地方，要及时响应。他们花时间审核了你的提交，要尊重他们。开启了PR，然后一走了之，是一种恶习。如果你不知道如何修改，请花时间深入研究问题的所在，如果还是没有想到好的办法，那么是该向他人求助的时候了。
+当有人提出变更时，请表现出大度的地方，要及时响应。他们花时间审核了你的提交，要尊重他们。开启了 PR，然后一走了之，是一种恶习。如果你不知道如何修改，请花时间深入研究问题的所在，如果还是没有想到好的办法，那么是该向他人求助的时候了。
 
-如果你因为没有时间而无法继续在此issue继续工作（举例来说，如果对话已经过去了一个月了，没有任何的回复和进度，环境肯定变得不一样了），那么请向维护者告知你无法在及时的响应了，肯定有人非常乐意接替你的工作的。
+如果你因为没有时间而无法继续在此 issue 继续工作（举例来说，如果对话已经过去了一个月了，没有任何的回复和进度，环境肯定变得不一样了），那么请向维护者告知你无法在及时的响应了，肯定有人非常乐意接替你的工作的。
 
 ### 👎 你的贡献没有获得通过。
 
-你的提交最后可能没有被接受。真心希望你没有在此作出过多的努力。如果你不确定为什么没有被接收的话，这正是一个很好的询问维护者反馈和澄清的机会。最终，无论如何，你都要对他们的决定表示尊重。不要去做过多无谓的争论或者是充满敌意的谩骂。如果你坚持自己，你可以随意的fork项目，按照自己的思路发展出分支来。
+你的提交最后可能没有被接受。真心希望你没有在此作出过多的努力。如果你不确定为什么没有被接收的话，这正是一个很好的询问维护者反馈和澄清的机会。最终，无论如何，你都要对他们的决定表示尊重。不要去做过多无谓的争论或者是充满敌意的谩骂。如果你坚持自己，你可以随意的 fork 项目，按照自己的思路发展出分支来。
 
 ### 🎉 你的贡献被接收。
 
@@ -519,4 +519,4 @@ related:
 
 你刚刚完成了自己的开源贡献处女秀，接下来，你可能打算寻找另外的方法来做贡献，希望本文给你提供了灵感和实践。即使是你的贡献没有被采纳或接收，也不要有失风度，请对帮助过你的维护者表示感谢！
 
-开源就是由你这样的人所铸造：开启一个issue，在提交PR，评论、讨论、收集反馈，直到被接收。就是这么简单。
+开源就是由你这样的人所铸造：开启一个 issue，在提交 PR，评论、讨论、收集反馈，直到被接收。就是这么简单。
diff --git a/_articles/zh-cn/leadership-and-governance.md b/_articles/zh-cn/leadership-and-governance.md
index fc100c27518..019fbe85157 100644
--- a/_articles/zh-cn/leadership-and-governance.md
+++ b/_articles/zh-cn/leadership-and-governance.md
@@ -109,13 +109,13 @@ related:
 * [精英模式模版](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
 * [Node.js 的自由贡献规则](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
 
-## Do I need governance docs when I launch my project?
+## 启动项目时是否需要治理文档？
 
-其实没有什么合适的时间来撰写项目的治理，但是可以根据社区的动态来进行恰当的定义。开源治理最好的也是最难的部分是有社区本身来塑造！
+其实没有什么合适的时间来撰写项目的治理，但是一旦你看到社区活跃起来就更容易定义。开源治理最好（也是最难）的部分是它由社区塑造！
 
 在项目的治理中，一些早期的文档将会不可避免的，然而也不必太强求，写下你所能够想到的。举例来说，你可以将某些预期的行为定义清楚，贡献的流程是如何的，或者项目是如何启动的，等等。
 
-如果你自己是公司所启动开源的一部分，在启动之前，应该做一些讨论，如公司将会如何维护项目，随着项目的发展，决策该如何定夺。你可以会公开的解释一下，贵公司将如何参与（或不参与）该项目。
+如果你要开源公司的项目，那么在发布之前，有必要进行内部讨论，了解你的公司希望如何维护并做出有关项目进展的决策。你可能还想公开解释贵公司将如何（或不会！）参与项目的具体内容。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
diff --git a/_articles/zh-cn/legal.md b/_articles/zh-cn/legal.md
index d12c4d29ed2..4e923df1d24 100644
--- a/_articles/zh-cn/legal.md
+++ b/_articles/zh-cn/legal.md
@@ -79,11 +79,11 @@ related:
 
 例如，随着你们项目的壮大，它添加了新的依赖或用户，或者你们的公司改变了策略，或者其他的要求要更换不同的许可协议。如果你们在开始项目的时候没有添加许可协议，那么再添加一个许可协议和更换许可协议是一样的效果。当你们要添加或者更换项目的许可协议时，需要考虑以下三件事：
 
-**这件事很复杂。**确定许可协议的兼容性和合规行，以及谁拥有版权，这会非常快速地变得复杂和混乱。为新的发布和贡献选择一个新的且合适的许可协议与重新许可已存在的贡献是不同的。一旦你们有任何想改变许可协议的想法，请首先让法律团队知道。即使你们已经或者能获得可以更换许可协议的权限，请考虑者会给项目的其他用户和贡献者带来怎样的影响。将更换许可协议视为"管理事件"，只有通过与项目的利益相关者进行明确的沟通和咨询，才更有可能顺利进行。请谨记，从一开始就为你们的选择和使用合适的许可协议。
+**这件事很复杂。**确定许可协议的兼容性和合规行，以及谁拥有版权，这会非常快速地变得复杂和混乱。为新的发布和贡献选择一个新的且合适的许可协议与重新许可已存在的贡献是不同的。一旦你们有任何想改变许可协议的想法，请首先让法律团队知道。即使你已经或可以获得项目版权所有者的许可证更改许可，请考虑更改对项目的其他用户和贡献者的影响。将更换许可协议视为"管理事件"，只有通过与项目的利益相关者进行明确的沟通和咨询，才更有可能顺利进行。请谨记，从一开始就为你们的选择和使用合适的许可协议。
 
 **你们的项目已经有了许可协议。**如果项目的现有许可证与您要更改的许可证兼容，则可以开始使用新许可证。这是因为如果A许可协议与B许可协议兼容，你们将遵守A的条款，同时遵守B的条款（但不一定反之亦然）。因此，如果你们目前正在使用许可型的许可协议（例如MIT），则可以更改为具有更多条件的许可协议，只要你们保留MIT许可协议的副本和任何相关的版权声明（即继续遵守MIT许可协议的最低条件）。如果你们现在的许可协议不是许可型的（例如，copyleft或者你们还没有许可协议）以及你们不是版权的唯一所有者，那么你们不能将许可协议改为MIT。基本上，只要是使用的许可型的许可协议，版权所有者能事先更换许可协议。
 
-**你们的项目已经有版权所有者。**如果你们是你们项目的唯一贡献者，然后你们或者你们的公司是项目版权的唯一所有者。你们可以添加或更换任何你们或者你们公司心仪的许可协议。不然你们需要取得其他版权所有者的同意。他们是谁？他们是已经参与你们项目提交的人。但有些情况是项目版权掌握在这些人的雇主手中。在某些情况下，人们只是做了_微小的_贡献，但没有硬性规定，在一些行代码下的贡献不受版权保护。对与这样的情况该怎么办？对于一个相对较小以及年轻的项目来说，取得所有贡献者对更换许可协议的同意是可行的。。但对于大项目和老项目来说，你们必须寻求很多贡献者以及他们继承者的共识。Mozilla花费了多年重新授权Firefox，Thunderbird和相关软件。
+**你们的项目已经有版权所有者。**如果你们是你们项目的唯一贡献者，然后你们或者你们的公司是项目版权的唯一所有者。你们可以添加或更换任何你们或者你们公司心仪的许可协议。不然你们需要取得其他版权所有者的同意。他们是谁？他们是已经参与你们项目提交的人。但有些情况是项目版权掌握在这些人的雇主手中。在某些情况下，人们只是做了_微小的_贡献，但没有硬性规定，在一些行代码下的贡献不受版权保护。对与这样的情况该怎么办？对于一个相对较小以及年轻的项目来说，取得所有贡献者对更换许可协议的同意是可行的。但对于大项目和老项目来说，你们必须寻求很多贡献者以及他们继承者的共识。Mozilla花费了多年重新授权Firefox，Thunderbird和相关软件。
 
 或者，你们可以让贡献者事先同意（通过额外的贡献者协议 - 见下文）在某些条件下更改某些许可协议，这些更改将超过现有的开源许可协议。这会改变许可协议改的复杂性。如果在执行许可协议更改时，你们仍然想要和项目利益相关者进行沟通，你们需要从你们律师那得到更多帮助。
 
@@ -110,14 +110,14 @@ related:
 * 如果你们的项目使用的是copyleft许可协议，但你们也需要分发项目的专有版本。那你们需要每个贡献者分配版权给你们或者授予你们许可权。[MongoDB贡献者协议](https://www.mongodb.com/legal/contributor-agreement)就是这中类型的。
 * 你们认为你们的项目在其有效期内需要更换许可协议，以及事先得到贡献者的同意。
 
-如果您们实需要在您的项目中使用额外的贡献者协议，请考虑使用诸如CLA助手之类的集成，以最大限度地减少贡献者的分心。
+如果你的项目确实需要使用额外的贡献者协议，请考虑使用[CLA助手](https://github.com/cla-assistant/cla-assistant)等集成来最大限度地减少贡献者分心。
 
 ## What does my company's legal team need to know?
 
 作为一名公司的雇员，如果你们在发布一个开源项目，你们首先需要让法律团队知道。
-即使只是一个个人项目，请考虑让他们知道。你们可能和公司有一个"员工知识产权协议"，这给了公司一些对你们项目的控制权，特别是当项目和公司的业务有着很多的联系或者你们使用公司的资源发展项目。你们的公司_应该_很容易给们许可，也许已经通过一个员工友好的知识产权协议或公司政策。如果不是这样，你么可以谈判（例如，解释你们的项目为公司的专业学习和发展目标服务），或者你们在找到一个更好的公司前停止你们项目的工作。
+即使是个人项目，请考虑让他们知道。你们可能和公司有一个"员工知识产权协议"，这给了公司一些对你们项目的控制权，特别是当项目和公司的业务有着很多的联系或者你们使用公司的资源发展项目。你的公司 _应该_ 很容易地给你许可，也许已经通过一个员工友好的知识产权协议或公司政策。如果不是这样，你么可以谈判（例如，解释你们的项目为公司的专业学习和发展目标服务），或者你们在找到一个更好的公司前停止你们项目的工作。
 
-**如果你们的开源项目是为了你们的公司，**者绝对需要让他们知道。根据公司的业务需求和专业知识，你们的法律团队可能已经制定了有关开放源代码许可协议（以及可能还有其他贡献者协议）的政策，以确保您的项目符合其依赖关系的许可协议。如果不是这样，你们和他们很幸运！你们的法律团队应该渴望与你们合作，把这个东西搞清楚。你们需要思考这些事：
+**如果你们的开源项目是为了你们的公司，**那么绝对要让他们知道。根据公司的业务需求和专业知识，你们的法律团队可能已经制定了有关开放源代码许可协议（以及可能还有其他贡献者协议）的政策，以确保您的项目符合其依赖关系的许可协议。如果不是这样，你们和他们很幸运！你们的法律团队应该渴望与你们合作，把这个东西搞清楚。你们需要思考这些事：
 
 * **第三方资源：**你们的项目有其他人创建的依赖或者使用他人的代码？如果这些事开源项目，你们需要遵守第三方资源的开源许可协议。首先，选择与第三方资源的开放源许可协议一起使用的许可协议（见上文）。如果你们的项目修改或者发布第三方开源资源，那么你们法律团队还想知道你们符合第三方开源许可协议的其他条件，例如保留版权声明。如果你们使用了其他没有开源许可协议的代码，那么你们可能会要求第三方资源的维护者[添加一个开源许可协议](https://choosealicense.com/no-license/#for-users)，要是你们得不到许可，你们只能停止使用他们的代码。
 
diff --git a/_articles/zh-cn/starting-a-project.md b/_articles/zh-cn/starting-a-project.md
index 1bd1e9dc703..ff3d4f640b3 100644
--- a/_articles/zh-cn/starting-a-project.md
+++ b/_articles/zh-cn/starting-a-project.md
@@ -12,7 +12,7 @@ related:
 
 ## The "what" and "why" of open source
 
-所以你在考虑开始参与开源？恭喜！世界赞赏你的贡献。让我们来谈谈开源是什么，以及人们这样做。
+那你在考虑开始参与开源？恭喜！世界赞赏你的贡献。我们来谈谈开源是什么以及为什么人们这样做。
 
 ### "开源"是什么意思？
 
@@ -57,7 +57,7 @@ related:
 
 因此，大多数开源项目是免费的，但"免费"不是开源定义的一部分。 有些方法可以通过双重许可或有限功能间接地为开源项目收费，同时仍然遵守开源的官方定义。
 
-## Should I launch my own open source project?
+## 我应该启动自己的开源项目吗？
 
 简单来说，答案是肯定的，因为无论结果如何，启动您自己的项目来了解开源的工作原理是一个好方法。
 
@@ -177,15 +177,15 @@ related:
 * 你项目的路线图或者版本
 * 贡献者应该（或者不应该）如何与你取得联系
 
-温柔友好的逾期和向贡献者们提供具体的建议（例如写文档或者搭建一个网页）能够有效地使新人感到受欢迎并乐于参与其中。
+使用热情友好的语气并提供具体的贡献建议（例如编写文档或者搭建网站）可以大大提高新人的参与度。
 
 例如，[Active Admin](https://github.com/activeadmin/activeadmin/) 以这样的方式开始[它的贡献指南](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md)：
 
-> 首先， 非常感谢你考虑为 Active Admin 贡献帮助。正式你这样的人们使得 Active Admin 成为了如此优秀的工具。
+> 首先， 非常感谢你考虑为 Active Admin 贡献帮助。正是你这样的人使 Active Admin 成为一个很棒的工具。
 
 在你项目开始的初期，你的贡献文件可以很简单。你应该经常解释如何提交错误和文件问题，以及关于如何作出贡献的技术问题（例如测试）。
 
-随着时间的推移，你硬弓增加其他常见问题到你的贡献文件中去。写下这些信息意味着问你相同问题的人会越来越少。
+随着时间的推移，你可以将其他常见问题添加到贡献文件中去。写下这些信息意味着问你相同问题的人会越来越少。
 
 想要获得更多有关编写贡献文件的方式，请查阅 @nayafia 的 [贡献指南模板](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) 或者 @mozilla 的 ["如何构建 CONTRIBUTION.md"](https://mozillascience.github.io/working-open-workshop/contributing/)。
 
@@ -203,7 +203,7 @@ related:
   </p>
 </aside>
 
-最后，行为规范有助于为你项目的参与者车里行为规则。这在你为社区或者项目推出一个开源项目的时候尤为有价值。一份行为帮助你促进健康，有建设性的社区行为，这也会减轻你作为维护者的压力。
+最后，行为准则有助于为项目参与者的行为设定基本规则。这在你为社区或者项目推出一个开源项目的时候尤为有价值。一份行为帮助你促进健康，有建设性的社区行为，这也会减轻你作为维护者的压力。
 
 更多信息，请参见 [行为规范指导](../code-of-conduct/)。