Merge pull request #992 from freeman0432/improve-chinese-translation

Improve some chinese translation

Author: MikeMcQuaid

_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)。
 
 第二点，忽略别人的贡献等于是在社区传递了一个负面的信号。让人感觉提交一个贡献是蛮恐惧的事情，尤其是对于刚加入的新手来说。即使你不接受他们的贡献，告诉他们为什么然后致谢。这会让人觉得更舒服。
 

_articles/zh-cn/building-community.md

@@ -31,7 +31,7 @@ related:
 
 好的文档能够邀请他人参与你们项目的互动。最终，一些人会开一个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/)是为这些情景准备的建设性指南。
 

_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>

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

@@ -425,7 +425,7 @@ related:
 >
 > 😢 _"你为什么不支持我的用例？这是不可接受的！"_
 
-**以上几点，要铭记在心。** 开源是由来自世界各地的人们共同协作实现的。面临的问题是跨语言、跨文化、不同的地理为止、不同的时区，另外，撰写文字的沟通更是难上加难，无法传达语气和情绪。请让这些会话都充满善意吧！在以下情形中请保持礼貌：推动一个想法、请求更多的上下文、进一步澄清你的立场。既然你在互联网找到了自己的所需，那么请尝试让它变得更好！
+**最重要的是，保持优雅** 开源社区有来自世界各地的协作者，所以跨语言、文化、地理位置和时区的情况下会丢失上下文语境。另外，书面交流使得传达语气或情绪变得更加困难。对话过程中善意的理解对方的意图。礼貌地反驳他人的想法，询问更多的上下文语境，或进一步澄清你的立场都是好事。我们要让互联网变得更加美好。
 
 ### 收集上下文
 

_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">

_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)，要是你们得不到许可，你们只能停止使用他们的代码。