diff --git a/src/appendix/rust-dev.md b/src/appendix/rust-dev.md
index 1e79d8b3..092f1f82 100644
--- a/src/appendix/rust-dev.md
+++ b/src/appendix/rust-dev.md
@@ -1,7 +1,7 @@
 ## 附录E Rust自身开发流程
 
 
-本附录介绍 Rust 是如何开发的以及这如何影响作为 Rust 开发者的你。
+本附录介绍 Rust语言自身是如何开发的以及这如何影响作为 Rust 开发者的你。
 
 ### 无停滞稳定
 
@@ -9,9 +9,9 @@
 
 对于这个问题我们的解决方案被称为 “无停滞稳定”（“stability without stagnation”），其指导性原则是：无需担心升级到最新的稳定版 Rust。每次升级应该是无痛的，并应带来新功能，更少的 bug 和更快的编译速度。
 
-### Choo, Choo! ~~（开车啦，逃）~~ 发布通道和发布时刻表（Riding the Trains）
+### Choo, Choo! ~~ 小火车发布流程启动
 
-Rust 开发运行于一个 ~~车次表~~ **发布时刻表**（*train schedule*）之上。也就是说，所有的开发工作都位于 Rust 仓库的 `master` 分支。发布采用 software release train 模型，其被用于思科 IOS 等其它软件项目。Rust 有三个 **发布通道**（*release channel*）：
+开发Rust语言是基于一个**火车时刻表**来进行的：所有的开发工作在Master分支上完成，但是发布就像火车时刻表一样，拥有不同的时间，发布采用的软件发布列车模型，被用于思科IOS和等其它软件项目。Rust 有三个 **发布通道**（*release channel*）：
 
 * Nightly
 * Beta
@@ -19,7 +19,7 @@ Rust 开发运行于一个 ~~车次表~~ **发布时刻表**（*train schedule*
 
 大部分 Rust 开发者主要采用稳定版通道，不过希望实验新功能的开发者可能会使用 nightly 或 beta 版。
 
-如下是一个开发和发布过程如何运转的例子：假设 Rust 团队正在进行 Rust 1.5 的发布工作。该版本发布于 2015 年 12 月，不过这里只是为了提供一个真实的版本。Rust 新增了一项功能：一个 `master` 分支的新提交。每天晚上，会产生一个新的 nightly 版本。每天都是发布版本的日子，而这些发布由发布基础设施自动完成。所以随着时间推移，发布轨迹看起来像这样，版本一天一发：
+如下是一个开发和发布过程如何运转的例子：假设 Rust 团队正在进行 Rust 1.5 的发布工作。该版本发布于 2015 年 12 月，这个版本和时间显然比较老了，不过这里只是为了提供一个真实的版本。Rust 新增了一项功能：一个 `master` 分支的新提交。每天晚上，会产生一个新的 nightly 版本。每天都是发布版本的日子，而这些发布由发布基础设施自动完成。所以随着时间推移，发布轨迹看起来像这样，版本一天一发：
 
 ```text
 nightly: * - - * - - *
@@ -107,7 +107,7 @@ $ cd ~/projects/needs-nightly
 $ rustup override set nightly
 ```
 
-现在，每次在 *~/projects/needs-nightly* 调用 `rustc` 或 `cargo`，`rustup` 会确保使用 nightly 版 Rust。在你有很多 Rust 项目时大有裨益！
+现在，每次在 *~/需要nightly的项目/*下(在项目的根目录下，也就是Cargo.toml所在的目录) 调用 `rustc` 或 `cargo`，`rustup` 会确保使用 nightly 版 Rust。在你有很多 Rust 项目时大有裨益！
 
 ### RFC 过程和团队
 
@@ -115,6 +115,6 @@ $ rustup override set nightly
 
 任何人都可以编写 RFC 来改进 Rust，同时这些 RFC 会被 Rust 团队评审和讨论，他们由很多不同分工的子团队组成。这里是 [Rust 官网上](https://www.rust-lang.org/governance) 所有团队的总列表，其包含了项目中每个领域的团队：语言设计、编译器实现、基础设施、文档等。各个团队会阅读相应的提议和评论，编写回复，并最终达成接受或回绝功能的一致。
 
-如果功能被接受了，在 Rust 仓库会打开一个 issue，人们就可以实现它。实现功能的人当然可能不是最初提议功能的人！当实现完成后，其会合并到 `master` 分支并位于一个功能开关（feature gate）之后，正如 [“不稳定功能”](#unstable-features) 部分所讨论的。
+如果功能被接受了，在 Rust 仓库会打开一个 issue，人们就可以实现它。实现功能的人可能不是最初提议功能的人！当实现完成后，其会合并到 `master` 分支并位于一个特性开关（feature gate）之后，正如 [不稳定功能](#不稳定功能) 部分所讨论的。
 
-在稍后的某个时间，一旦使用 nightly 版的 Rust 团队能够尝试这个功能了，团队成员会讨论这个功能，它如何在 nightly 中工作，并决定是否应该进入稳定版。如果决定继续推进，功能开关会移除，然后这个功能就被认为是稳定的了！乘着“发布的列车”，最终在新的稳定版 Rust 中出现。
+在稍后的某个时间，一旦使用 nightly 版的 Rust 团队能够尝试这个功能了，团队成员会讨论这个功能在 nightly 中运行的情况，并决定是否应该进入稳定版。如果决定继续推进，特性开关会移除，然后这个功能就被认为是稳定的了！乘着“发布的列车”，最终在新的稳定版 Rust 中出现。
diff --git a/src/style-guide/naming.md b/src/style-guide/naming.md
index ff247df6..de82c739 100644
--- a/src/style-guide/naming.md
+++ b/src/style-guide/naming.md
@@ -10,7 +10,7 @@
 | 模块Modules | `snake_case` |
 | 类型Types | `UpperCamelCase` |
 | 特征Traits | `UpperCamelCase` |
-| 枚举变量Enum variants | `UpperCamelCase` |
+| 枚举项 | `UpperCamelCase` |
 | 函数Functions | `snake_case` |
 | 方法Methods | `snake_case` |
 | 通用构造器General constructors | `new` or `with_more_details` |
diff --git a/writing-material/style_guide/naming.md b/writing-material/style_guide/naming.md
index ff247df6..de82c739 100644
--- a/writing-material/style_guide/naming.md
+++ b/writing-material/style_guide/naming.md
@@ -10,7 +10,7 @@
 | 模块Modules | `snake_case` |
 | 类型Types | `UpperCamelCase` |
 | 特征Traits | `UpperCamelCase` |
-| 枚举变量Enum variants | `UpperCamelCase` |
+| 枚举项 | `UpperCamelCase` |
 | 函数Functions | `snake_case` |
 | 方法Methods | `snake_case` |
 | 通用构造器General constructors | `new` or `with_more_details` |