Merge branch 'master' into master

Author: kenyonj

.github/main.workflow

@@ -1,19 +1,15 @@
-workflow "test" {
-  resolves = ["CI Test Runner"]
-  on = "push"
+workflow "Test and build on push" {
+  resolves = ["Jekyll Pages Builder"]
+  on = "pull_request"
 }
 
 action "CI Test Runner" {
   uses = "./.github/test_runner"
   secrets = ["GITHUB_TOKEN"]
 }
 
-workflow "build" {
-  on = "push"
-  resolves = ["Jekyll Pages Builder"]
-}
-
 action "Jekyll Pages Builder" {
+  needs = "CI Test Runner"
   uses = "./.github/pages_builder"
   secrets = ["GITHUB_TOKEN"]
 }

.travis.yml

@@ -0,0 +1,27 @@
+language: node_js
+node_js:
+  - 6
+before_install:
+  - rvm install 2.4.3
+  - npm install -g npm@5
+install:
+  - npm install
+  - bundle install
+script: script/test
+notifications:
+  email: false
+env:
+  global:
+    - NOKOGIRI_USE_SYSTEM_LIBRARIES=true
+addons:
+  apt:
+    packages:
+      - libcurl4-openssl-dev
+cache:
+  bundler: true
+  directories:
+    - node_modules
+    - test/node_modules
+branches:
+  only:
+    - master

Gemfile.lock

@@ -30,7 +30,7 @@ GEM
       multipart-post (>= 1.2, < 3)
     ffi (1.10.0)
     forwardable-extended (2.6.0)
-    gemoji (3.0.0)
+    gemoji (3.0.1)
     github-pages (198)
       activesupport (= 4.2.11.1)
       github-pages-health-check (= 1.16.1)

_articles/zh-cn/best-practices.md

@@ -58,7 +58,7 @@ related:
 
 这里是一些值得你写进项目里的东西：
 
-* 怎样的贡献才会被复查和接受(_需要测试吗？提Issue有模板吗？_)
+* 怎样的贡献才会被复查和接受（_需要测试吗？提Issue有模板吗？_）
 * 你本人会接受什么类型的贡献？（_你是不是只希望在某些部分的代码上需要别人的帮助？_）
 * 在合适的时候跟进项目（比如说 _如果你在七天之内没有收到maintainer的回复，而且依旧没有其它任何的响应，那么就直接找Ta。_）
 * 你会在这个项目上话多少时间（比如说 "_我们每星期只会在这个项目上花5个小时_"）
@@ -67,9 +67,9 @@ related:
 
 ### 保证交流是公开进行的
 
-不管是什么时候，保证你的交流是在公共的场所（就是大家都能看到的地方）。如果有人尝试和你私聊，哪怕是讨论一个新的需求或者功能，请礼貌的引导Ta到公共的交流场所，比如邮件列表或者iuuse tracker。
+不管是什么时候，保证你的交流是在公共的场所（就是大家都能看到的地方）。如果有人尝试和你私聊，哪怕是讨论一个新的需求或者功能，请礼貌的引导Ta到公共的交流场所，比如邮件列表或者issue tracker。
 
-如果你和别的维护者面基了，或者在私下做了一个很重要的决定，把这些信息告诉大家，即使只是把你的笔记发上去。
+如果你和别的维护者见面了，或者在私下做了一个很重要的决定，把这些信息告诉大家，即使只是把你的笔记发上去。
 
 这样的话，每个人新加入到你们社区的人和已经呆了多年的人能够了解到的信息是一样的。
 
@@ -93,7 +93,7 @@ related:
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
-  管理大型开源项目的关键就是保证issue活跃。尽量避免让issue停滞不前。如果你是一个IOS开发者，你会知道提交雷达是多么让人沮丧（我也不知道这是什么意思。。）你可能过了两年之后有人让你兼容一下现在的IOS版本。
+  管理大型开源项目的关键就是保证issue活跃。尽量避免让issue停滞不前。如果你是一个IOS开发者，你会知道<abbr title="提交问题到 Apple 的 Radar bug 跟踪系统">提交雷达</abbr>是多么让人沮丧。您可能会在2年后收到回复，并被告知要再次使用最新版本的iOS。
   <p markdown="1" class="pquote-credit">
 — @KrauseFx, ["开源社区黑客增长"](https://krausefx.com/blog/scaling-open-source-communities)
   </p>
@@ -150,7 +150,7 @@ related:
 
 可能在你的社区里有人不断提交一些不符合项目需求的贡献。对你们双方来说，不停的拒绝他的提交，会令双方都很尴尬。
 
-如果你发现有人对你的项目很上心，但是就是需要调教，那就耐心一点。给他解释明白每次它的提交为什么不符合项目需求。尝试着让他先做一些简单一点的事，比如那些标有_"good first issue"_ 标签的issue，以此让他慢慢习惯。如果你有时间的话，考虑教Ta怎么完成第一次贡献，或者在社区找一个人教Ta。
+如果你发现有人对你的项目很上心，但是就是需要调教，那就耐心一点。给他解释明白每次它的提交为什么不符合项目需求。尝试着让他先做一些简单一点的事，比如那些标有 _"good first issue"_ 标签的issue，以此让他慢慢习惯。如果你有时间的话，考虑教Ta怎么完成第一次贡献，或者在社区找一个人教Ta。
 
 ## Leverage your community
 
@@ -162,7 +162,7 @@ related:
 
 当你看到新的贡献者不停的提交贡献，通过分配给他们更多任务来表示认可。如果别人愿意的话，记录下别人是怎么成长为领导者的过程。
 
-鼓励别人来[一起管理项目](../building-community/#share-ownership-of-your-project)能很大程度上减轻你的工作量，就像 [@lmccart](https://github.com/lmccart)在他的项目上做的那样，[p5.js](https://github.com/processing/p5.js)
+鼓励别人来[一起管理项目](../building-community/#share-ownership-of-your-project)能很大程度上减轻你的工作量，就像 [@lmccart](https://github.com/lmccart) 在他的项目上做的那样，[p5.js](https://github.com/processing/p5.js)
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
@@ -172,7 +172,7 @@ related:
   </p>
 </aside>
 
-如果你需要暂时或者永久的离开的项目，请找人来代替你，这并没有什么不好意思。
+如果你需要暂时或者永久的离开项目，请找人来代替你，这并没有什么不好意思。
 
 如果别人认同项目的发展方向，给他们提交的权限或者正式把项目所有权转移给他。如果有人fork了你的项目而且在保持活跃的维护中，考虑在你的原始的仓库放上这个fork版本的链接。如果大家都希望你的项目继续的话这不失为一种好办法。
 
@@ -246,7 +246,7 @@ fork一个项目不什么坏事情。能复制并且修改别人的代码是开
 
 疲倦在开源工作工作中是一个常见的问题，特别是在维护者中间。作为一个维护者，你做的开心对项目的生存来说是一个没有商量余地的条件。
 
-虽然你不需要跟谁请假，但是也不要拖到自己疲倦不堪的时候才去度假。[@brettcannon](https://github.com/brettcannon)，一个python的核心开发者，决定在14年的义务劳动之后[休一个月的假](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering)
+虽然你不需要跟谁请假，但是也不要拖到自己疲倦不堪的时候才去度假。[@brettcannon](https://github.com/brettcannon)，一个python的核心开发者，决定在14年的义务劳动之后[休一个月的假](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering)。
 
 就像其他工作一样，有规律的休息会让你对工作保持舒适愉快的心情。
 

_articles/zh-cn/code-of-conduct.md

@@ -29,7 +29,7 @@ related:
 * 如果有人违反了行为守则会怎样？
 * 大家如何举报违规
 
-无论你们在哪里，请使用已有的行为守则。[贡献者盟约](https://www.contributor-covenant.org/)是一个被超过40，000个开源项目（包括Kubernetes, Rails和Swift）所使用的行为守则。
+无论你们在哪里，请使用已有的行为守则。[贡献者盟约](https://www.contributor-covenant.org/)是一个被超过40,000个开源项目（包括Kubernetes, Rails和Swift）所使用的行为守则。
 
 [Django行为守则](https://www.djangoproject.com/conduct/)和[Citizen行为守则](http://citizencodeofconduct.org/)都是非常好的行为守则。
 

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

@@ -387,7 +387,7 @@ related:
   </p>
 </aside>
 
-在你开启一个isse或PR之前，或者是在聊天室问问题之前，请牢记下面所列出的几点建议，会让你的工作更加的高效。
+在你开启一个 issue 或 PR 之前，或者是在聊天室问问题之前，请牢记下面所列出的几点建议，会让你的工作更加的高效。
 
 **给出上下文** 以便于让其他人能够快速的理解。比方说你运行程序时遇到一个错误，要解释你是如何做的，并描述如何才能再现错误现象。又比方说你是提交一个新的想法，要解释你为什么这么想，对于项目有用处吗（不仅仅是只有你！）
 
@@ -431,7 +431,7 @@ related:
 
 在正式开始之前，做一些快速的检查项，以确保你的想法是没有被讨论过的。遍历项目的 README、问题（开放的和关闭的都算）、邮件列表、Stack Overflow。毋需去花好几个小时去全部折腾一遍，但是使用几个关键的词汇来搜索一下是必要的。
 
-如果你没有找到和你想法一样的内容，你就可以继续了。如果项目是在 GitHub上的话，你可以通过开启一个issue或PR：
+如果你没有找到和你想法一样的内容，你就可以继续了。如果项目是在 GitHub 上的话，你可以通过开启一个issue或PR：
 
 * **Issues** 开启一次对话或讨论
 * **Pull requests** 请求接受自己的解决方法
@@ -499,9 +499,9 @@ related:
 
 如果你做了所有该做的事情，还是没有人理你，那就是真的没有人对你的贡献做出响应。这可能感觉上不太好受，但是千万不要灰心。每个人都会遇到这样的情况。其实有太多种原因没有人响应你的提交了，包括很多个人情形都是不在你控制范围的。再接再厉，换一种方法去提交，或者换一个项目。这年头，很多社区成员都在积极的参与和响应他人，都在抢夺优秀的人才，若没有人搭理你，你换地方是没有任何不对的地方的。
 
-### 🚧 其他人的要求你对自己的提交做出变更。
+### 🚧 有人要求你对自己的提交做出变更。
 
-对于自己的提交作出变更这件事非常的普遍，可能是你获得了反馈，也可能是变更了代码。
+被要求对你的提交进行更改是很常见的，无论是对你的实现上的反馈，还是你代码改动上的反馈。
 
 当有人提出变更时，请表现出大度的地方，要及时响应。他们花时间审核了你的提交，要尊重他们。开启了PR，然后一走了之，是一种恶习。如果你不知道如何修改，请花时间深入研究问题的所在，如果还是没有想到好的办法，那么是该向他人求助的时候了。