Fix typo

phylee · phylee · commit 6b71f475fd53 · 2018-01-11T00:07:32.000+08:00
diff --git a/chapters/13-read-code.md b/chapters/13-read-code.md
@@ -36,19 +36,21 @@
 ![linux-history.png](./img/linux-history.png)
 
 表格源自一本书叫《Linux内核0.11(0.95)完全注释》，简单地再介绍一下：
+
 - 版本0.00是一个hello,world程序
 - 版本0.01包含了可以工作的代码
 - 版本0.11是基本可以正常的版本
 
 这里就要扯到《GNU 风格的版本号管理策略》：
 
-1．项目初版本时，版本号可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0，如果你为人很低调，我想你会选择那个主版本号为 0 的方式；
-2．当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
+1. 项目初版本时，版本号可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0，如果你为人很低调，我想你会选择那个主版本号为 0 的方式；
+2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
 3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0，因而可以被忽略掉；
-4．当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1；
-5．另外，编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制。
+4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1；
+5. 另外，编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制。
 
 因此，我们可以得到几个简单的结论：
+
 - 我们需要阅读最早的有核心代码的版本
 - 我们需要阅读1.0版本的Release
 - 往后每一次大的Release我们都需要了解一下
diff --git a/chapters/15-milestone.md b/chapters/15-milestone.md
@@ -23,7 +23,7 @@ GitHub 里程碑
 
 一年前，稍微改变了下策略：暂时以**培养人为主**，同时想着做一个合适的开源框架——只是在今年看来，前端领域已经没有合适的地方可以造轮子了。
 
-在 GitHub 上有一个很常见的问题是，**大多部分项目的维护者就是发起人**——如果这个发起人发生意外了，那么这个项目怎么办。如果这是一个很火的项目，它就存在着巨大的风险；同时这可能也说明了，缺乏一套合理的机制。
+在 GitHub 上有一个很常见的问题是，**大多数项目的维护者就是发起人**——如果这个发起人发生意外了，那么这个项目怎么办。如果这是一个很火的项目，它就存在着巨大的风险；同时这可能也说明了，缺乏一套合理的机制。
 
 你的开源项目不仅仅需要一个使用文档，还需要一个相关设计思想的文档、路线图、未来计划等等。
 
@@ -53,9 +53,9 @@ GitHub 里程碑
 
 **家居智能中心**。我仍然对于大学学的知识有点念念不忘，虽然已经写了一本书，但是硬件还是相当的刺激。唯一的问题是：连房子都没有，怎么做智能家居。
 
-**图形框架**。这是我之前在做一个图形界面的时候，发生没有一个合适的框架可以满足我的要求。然后我就在想，还是自己做一个吧。
+**图形框架**。这是我之前在做一个图形界面的时候，发现没有一个合适的框架可以满足我的要求。然后我就在想，还是自己做一个吧。
 
-不过，最好的开源项目就是自己平时用的。于是，我开始将写各种工作来提自己使用——如现在在用的这篇微信编辑工具：[mdpub](https://github.com/phodal/mdpub)。
+不过，最好的开源项目就是自己平时用的。于是，我开始将写各种工具来给自己使用——如现在在用的这篇微信编辑工具：[mdpub](https://github.com/phodal/mdpub)。
 
 最后，我做了一个简单的 HTML 5 动画来记录这一时刻，作为这一个里程碑的记念：
 
diff --git a/chapters/16-faq.md b/chapters/16-faq.md
@@ -12,7 +12,7 @@ FAQ
 
 在这种时候，也没有法律来保护这些开源软件作者。你只能从道德上谴责他们，然后指望他们的领导来做出一些什么事。如之前的《[知名公司（努比亚/中兴）拿我的开源软件（ XXL-JOB）申请国家知识专利，我该怎么办？](https://link.zhihu.com/?target=https%3A//www.v2ex.com/t/367424%3Fp%3D1)》事件。
 
-并且对于大部分的开源软件作者来说，都不大可像 OpenResty、Vue、emqtt 等软件的作者一样，可以从开源软件获得收益来支撑他们开发。还有一些少数人，还能从开源软件中获得一些利益，提高他们今年的 KPI。然后明年的工资，又会多涨一点点。
+并且对于大部分的开源软件作者来说，都不大可能像 OpenResty、Vue、emqtt 等软件的作者一样，可以从开源软件获得收益来支撑他们开发。还有一些少数人，还能从开源软件中获得一些利益，提高他们今年的 KPI。然后明年的工资，又会多涨一点点。
 
 可多数人，并没有这样的可能性。我在 GitHub 上有接近 30k 的 star（笑，有接近 20k 是属于电子书的，毕竟思想改变世界），它一点儿也不影响我涨工资。反而多了一个 GitHub “网红” 的称号，要知道在技术领域，“网红” 并不是一个好词。我观察过的大量开源爱好者，怕是比我还惨一些。明明做了很好的工作，因为宣传工作没有做好，连几个 star 都没有，后来就弃坑了。
 
