articles/zh-cn: fix test failures.

Author: MikeMcQuaid

_articles/zh-cn/best-practices.md

@@ -17,15 +17,15 @@ related:
   - leadership
 ---
 
-## 身为一名维护者意味着什么？
+## What does it mean to be a maintainer?
 
 如果你维护着一个非常流行的项目，你可能就会意识到自己写代码的时间变少，而花费在回答issue的时间越来越多。
 
 在项目的起步阶段，你会不断尝试着实现自己的新想法，也能够基于自己想要的作出决定。随着项目逐渐的开始流行，就会发现你的大部分时间都花在了与用户、贡献者打交道上。
 
 维护一个项目需要的不仅仅是写代码的能力。有些时候会有一个你意想不到的的事情要应付，但是这对一个项目的成长也很重要（相对于代码来说），我们收集了一些小技巧来让你的维护工作变得稍轻松些，这些技巧，涉及范围颇广，从写文档到管理社区都有所涉猎。
 
-## 将流程撰文档化
+## Documenting your processes
 
 对于一个项目的维护者来说写文档是最重要的事情之一。
 
@@ -45,13 +45,12 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars2.githubusercontent.com/u/1976330?v=3&s=460" class="pquote-avatar" alt="avatar" alt="@lord avatar">
-  我一直都在摸索。我没有努力寻求一个完整的解决方案。与其采用那种半吊子办法，我真希望曾经对某些Issue的提出者说：“我暂时没有时间干这个，但是我会把他放到我的待办事项中”。
+  我一直都在摸索。我没有努力寻求一个完整的解决方案。与其采用那种半吊子办法，我真希望曾经对某些Issue的提出者说："我暂时没有时间干这个，但是我会把他放到我的待办事项中"。
   <p markdown="1" class="pquote-credit">
 — @lord, ["开源项目维护者新手的几点技巧"](https://lord.io/blog/2014/oss-tips/)
   </p>
 </aside>
 
-
 ### 和大家交流你自己对项目的期望
 
 制定规则是很伤脑筋的。有时候你可能觉得你像是在限制别人的行为或者说把好玩的东西都搞没了。
@@ -71,7 +70,6 @@ related:
 * 在合适的时候跟进项目（比如说 _如果你在七天之内没有收到maintainer的回复，而且依旧没有其它任何的响应，那么就直接找Ta。_）
 * 你会在这个项目上话多少时间（比如说 "_我们每星期只会在这个项目上花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) 均是为维护者和贡献者提供了很好的基本规则的项目.乃业内典范。
 
 ### 保证交流是公开进行的
@@ -82,11 +80,11 @@ related:
 
 这样的话，每个人新加入到你们社区的人和已经呆了多年的人能够了解到的信息是一样的。
 
-## 学会拒绝他人
+## Learning to say no
 
 把所有的事情都写下来，当然，对你执行你制定的规则的时候客观分析实际情况也有帮助。
 
-拒绝别人确实不是很好玩，但是也要表现出专业程度，比如使用“你的贡献不符合这个项目的标准”而不是“我不喜欢你的贡献”这样显得粗鲁的语句。
+拒绝别人确实不是很好玩，但是也要表现出专业程度，比如使用"你的贡献不符合这个项目的标准"而不是"我不喜欢你的贡献"这样显得粗鲁的语句。
 
 作为一个维护者，在很多情况下，你都要拒绝别人：不符合项目规则的PR, 某个人脱离了讨论的重点，给别人做无关紧要的工作等等。
 
@@ -128,7 +126,7 @@ related:
 
 > 我和很多来自诸如Mesos, Kubernetes, Chromium等不同开源项目的维护者交流过，他们都异口同声的觉得做一个维护者最难的就是拒绝你不想要的补丁。
 
-对于不想接受别人的贡献这件事不要感到愧疚。如 [@shykes](https://github.com/shykes)[所说](https://twitter.com/solomonstre/status/715277134978113536)开源的第一原则就是 _"拒绝是暂时的，接受是永远的。”_ 当然啦，认同别人的热情还是一件好事，拒绝他的贡献和拒绝他这个人是两码事。（要做到对事不对人。）
+对于不想接受别人的贡献这件事不要感到愧疚。如 [@shykes](https://github.com/shykes)[所说](https://twitter.com/solomonstre/status/715277134978113536)开源的第一原则就是 _"拒绝是暂时的，接受是永远的。"_ 当然啦，认同别人的热情还是一件好事，拒绝他的贡献和拒绝他这个人是两码事。（要做到对事不对人。）
 
 最后，如果一个贡献不是够好，你没任何义务接受它。对那些想对你的项目做贡献的人保持和蔼和积极的态度，但是只能接受那些你确定会让你的项目变得更好的提交。你说拒绝的次数越多，对你来说拒绝别人就越容易。谨记！
 
@@ -161,7 +159,7 @@ related:
 
 如果你发现有人对你的项目很上心，但是就是需要调教，那就耐心一点。给他解释明白每次它的提交为什么不符合项目需求。尝试着让他先做一些简单一点的事，比如那些标有_"good first bug"_ 标签的issue，以此让他慢慢习惯。如果你有时间的话，考虑教Ta怎么完成第一次贡献，或者在社区找一个人教Ta。
 
-## 有效利用社区
+## Leverage your community
 
 你不需要凡事亲力亲为。这就是社区存在的原因！即使你没有一个活跃的贡献者社区，但是如果你有很多用户的话，拉他们来干活儿。
 
@@ -171,14 +169,13 @@ related:
 
 当你看到新的贡献者不停的提交贡献，通过分配给他们更多任务来表示认可。如果别人愿意的话，记录下别人是怎么成长为领导者的过程。
 
-
 鼓励别人来[一起管理项目](../building-community/#share-ownership-of-your-project)能很大程度上减轻你的工作量，就像 [@lmccart](https://github.com/lmccart)在他的项目上做的那样，[p5.js](https://github.com/processing/p5.js?files=1)
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars3.githubusercontent.com/u/191056?v=3&s=460" class="pquote-avatar" alt="avatar">
-  我曾经说过，“对，每个人都可以参与进来，你不需要有很多编程的经验。”当有申请来参加我们的活动的时候，我就在想，这是真的吗，我说了啥？有将近40个人来了，我虽然不可能和每个人都单独交谈，但是大家一起来了，这说明我说的没错。只要有人知道怎么做了，他们就能教他们的邻居。
+  我曾经说过，"对，每个人都可以参与进来，你不需要有很多编程的经验。"当有申请来参加我们的活动的时候，我就在想，这是真的吗，我说了啥？有将近40个人来了，我虽然不可能和每个人都单独交谈，但是大家一起来了，这说明我说的没错。只要有人知道怎么做了，他们就能教他们的邻居。
   <p markdown="1" class="pquote-credit">
-—  @lmccart, ["“开源” 意味着什么? p5.js 版"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39#.chnjlag7p)
+—  @lmccart, [""开源" 意味着什么? p5.js 版"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39#.chnjlag7p)
   </p>
 </aside>
 
@@ -208,7 +205,7 @@ fork一个项目不什么坏事情。能复制并且修改别人的代码是开
 
 > 一旦一个项目变大之后，维护者对怎么增加新代码变得保守是不可避免的事情。你可能很会拒绝别人的需求，但是很多人提的都是合法的需求。所以，你不得不把你的一个工具变成平台。
 
-## 使用机器人
+## Bring in the robots
 
 就像很多工作别人可以帮你做一样，也有很多工作不需要人来做。因为有机器可以替代人工，尤其是那些重复、无聊的工作，用好它们能够让你的维护生活变得更容易。
 
@@ -230,7 +227,6 @@ fork一个项目不什么坏事情。能复制并且修改别人的代码是开
   </p>
 </aside>
 
-
 ### 用工具来自动化日常的维护工作
 
 对于维护一个流行的项目来说，一个好消息是别的维护者也可能遇到过类似的问题而且已经找到一个解决方案。
@@ -257,7 +253,6 @@ fork一个项目不什么坏事情。能复制并且修改别人的代码是开
 
 疲倦在开源工作工作中是一个常见的问题，特别是在维护者中间。作为一个维护者，你做的开心对项目的生存来说是一个没有商量余地的条件。
 
-
 虽然你不需要跟谁请假，但是也不要拖到自己疲倦不堪的时候才去度假。[@brettcannon](https://github.com/brettcannon)，一个python的核心开发者，决定在14年的义务劳动之后[休一个月的假](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering)
 
 就像其他工作一样，有规律的休息会让你对工作保持舒适愉快的心情。
@@ -276,6 +271,6 @@ fork一个项目不什么坏事情。能复制并且修改别人的代码是开
 
 休假不仅适用于度假。如果你周末不想做开源项目的工作了，或者在本该工作的时候不想干活了，和别人说，这样他们知道什么时候不该打扰你。
 
-## 首先照顾好自己！
+## It's okay to hit pause
 
 维护一个大型项目时，相比早期的增长阶段，是需要更多的不一样的技能，作为一个维护者，你会将自己的领导力和个人能力提高一个层次，而这是很少人能体会的到的。但是与此同时，要挑战管理项目，以及设定清晰的界限。只做你感到舒服的事情，能够让你保持开心，活力，高产的状态。

_articles/zh-cn/building-community.md

@@ -14,7 +14,7 @@ related:
   - coc
 ---
 
-## 建立成功的项目
+## Setting your project up for success
 
 现在的你，已经启动了属于自己的项目，而且正在传播它，更重要的是现在已经有人将之下载到本地进行观摩。这真是令人振奋！那么你现在要做的就是，怎么能够让这些有兴趣的人们坚持下去，持续跟进项目。
 
@@ -48,7 +48,7 @@ related:
   </p>
 </aside>
 
-多数开源贡献者是“临时贡献者”，因为他们只是偶尔参与项目贡献。一位临时贡献者可能没有充足的时间全程跟踪你的项目，所以你的工作是能让他们很轻松地参与贡献。
+多数开源贡献者是"临时贡献者"，因为他们只是偶尔参与项目贡献。一位临时贡献者可能没有充足的时间全程跟踪你的项目，所以你的工作是能让他们很轻松地参与贡献。
 
 鼓励其他的贡献者也是对项目的一种投资。当你们授权大量的粉丝做他们感兴趣的工作时，压力就会少很多。
 
@@ -91,7 +91,6 @@ related:
 
 与项目有关的话题也可能发生在互联网的其它地方，例如Stack Overflow，Twitter，或者Reddit。你可以在像这样的一些网站设置通知，这样当有人提及项目时，可以即时的收到提醒。
 
-
 ### 为你们的社区提供一个聚会的场所
 
 有两个理由可以解释为什么要给社区提供一个聚会的场所。
@@ -108,11 +107,11 @@ related:
 
 公开交流需要特别注意的事项：1）有关安全方面的issues 2）敏感的行为准则。应该为大家提供一个私下报告这些issue的方式。若不想使用自己的个人邮箱，那么就创建一个公用的邮箱。
 
-## 社区生长
+## Growing your community
 
 社区拥有强大的能量。这种能量可能是正面的也可能是负面的，这一切都取决于你如何驾驭它。随着项目社区的成长，要想办法让之成为建设性的力量，而不是具有破坏性的。
 
-### 不要容忍糟糕的角色
+### Don't tolerate bad actors
 
 一些流行的项目将不可避免地会吸引到一些破坏它们的人。这些人可能会从一些没必要的争论开始，对一些细枝末节进行纠缠不清，甚或用语言伤及他人。
 
@@ -132,7 +131,6 @@ related:
 
 当发现社区中有消极的行为时，要即时、公然的指出来。特别说明的是，要用坚定的语气解释他们的行为为什么是不可接受的。如果这种问题继续发生，你有必要[要求他们离开](https://github.com/cnbo/open-source-guide/blob/gh-pages/_articles/code-of-conduct.md#enforcing-your-code-of-conduct)。你的[行为准则](https://github.com/cnbo/open-source-guide/blob/gh-pages/_articles/code-of-conduct.md)是为这些情景准备的建设性指南。
 
-
 ### 知道贡献者在哪里
 
 随着项目的成长，好的文档会变得愈加重要。临时贡献者或路人是不可能一下子就对项目非常熟悉，一份好的文档，能够很快找到他们需要的。
@@ -151,7 +149,7 @@ related:
 
 > 我们想感谢你们使用Rubinius。这个项目是一个充满爱的工作，我们希望所有用户查找bugs，取得性能上的提升，以及帮助完善文档。每一个贡献都是有意义的，所以感谢你们的参与。话虽如此，但我们还是要求你们遵守一些指南，这样我们就能够找到你们的issue。
 
-### 分享项目的所有权
+### Share ownership of your project
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars3.githubusercontent.com/u/270108?v=3&s=400" class="pquote-avatar" alt="avatar">
@@ -189,7 +187,7 @@ related:
   </p>
 </aside>
 
-## 解决冲突
+## Resolving conflicts
 
 在项目的早期，做决定是件蛮容易的事。几乎是想做什么就可以做什么。
 
@@ -223,13 +221,13 @@ README [不仅仅是一组指令](../starting-a-project/#writing-a-readme)。它
 
 ### 专注过程，而不是结果
 
-一些项目用投票的方式做重要决定。虽然看上去是明智的，投票强调的是得到一个“答案”，而不是倾听以及解决每个人的顾虑。
+一些项目用投票的方式做重要决定。虽然看上去是明智的，投票强调的是得到一个"答案"，而不是倾听以及解决每个人的顾虑。
 
 投票会变成政治，社区成员在做感兴趣的事或者表决一个明确的方法时会感到压力。不是每个人都参与了投票，可能在你们的社区中[保持沉默的人占了多数](http://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users)，或者用户不知道投票这件事正在发生。
 
 有时候，投票是必要的手段。尽你们所能强调["寻求共识"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making)而不是共识本身。
 
-在寻求共识的过程中，社区成员讨论主要问题，直到他们感到他们的意见已经得到充分的表达。当仅遗留下一些无关紧要的问题时，社区需要向前迈进。“寻求共识”不能确保社区能得到一个完美的答案。而是侧重聆听和讨论。
+在寻求共识的过程中，社区成员讨论主要问题，直到他们感到他们的意见已经得到充分的表达。当仅遗留下一些无关紧要的问题时，社区需要向前迈进。"寻求共识"不能确保社区能得到一个完美的答案。而是侧重聆听和讨论。
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars3.githubusercontent.com/u/1038121?v=3&s=460" class="pquote-avatar" alt="avatar">
@@ -252,9 +250,9 @@ Atom Issues不存在投票系统的部分原因是因为Atom团队在所有情
 
 允许这些对话进行下去不仅对解决问题没有帮助，而且不利于社区的健康发展。它释放了这样一个信号，表示允许或甚至鼓励这种类型的对话，它可能阻止人们提高或者解决未来的问题。
 
-当你们或者其他人每提出一个观点时，请自问：“这如何使我们更接近一个决议？”
+当你们或者其他人每提出一个观点时，请自问："这如何使我们更接近一个决议？"
 
-如果对话开始有解散的征兆，问团队：“我们下一步该做什么?”才能重新对话。
+如果对话开始有解散的征兆，问团队："我们下一步该做什么?"才能重新对话。
 
 如果一个对话没有清晰的方向，没有明确的措施可以采取，或者合适的措施已经被使用，那么关掉issue并解释为什么关掉它。
 
@@ -283,6 +281,6 @@ Atom Issues不存在投票系统的部分原因是因为Atom团队在所有情
 
 使用决策者应该是你们最后才能采取的手段。分离issues是一个你们社区成长和学习的机会。利用这些机会并精诚合作，尽量找出问题的解决方案。
 
-## 社区是开源的❤️
+## Community is the ❤️ of open source
 
 健康，蓬勃的社区每周都会为开源付出大量辛勤的劳动。许多贡献者指出其他人在开源工作或不在开源工作的原因。通过学习如何建设性地利用这股力量，你们会帮助他人有一个难忘的开源体验。