Fix markdown style errors

vvtommy · Sep 15, 2019 · d8fca40 · d8fca40
1 parent 95f811d
commit d8fca40
Show file tree

Hide file tree

Showing 3 changed files with 8 additions and 8 deletions.
diff --git a/review/emergencies.md b/review/emergencies.md
@@ -2,15 +2,15 @@
 
 有时候紧急 CL 必须尽快通过 code review 过程。
 
-## 什么是紧急情况？{#what}
+## 什么是紧急情况？ {#what}
 
 紧急 CL 是这样的**小**更新：允许主要发布继续而不是回滚，修复显着影响用户生产的错误，处理紧迫的法律问题，关闭主要安全漏洞等。
 
 在紧急情况下，我们确实关心 Code Review 的整体速度，而不仅仅是响应的速度。仅在这种情况下，审查人员应该更关心审查的速度和代码的正确性（是否解决了紧急情况？）。此外（显然）这类状况的审查应该优先于所有其他 code reivew。
 
 但是，在紧急情况解决后，您应该再次查看紧急 CL 并进行[更彻底的审查](reviewer/looking-for.md)。
 
-## 什么不是紧急情况？{#not}
+## 什么不是紧急情况？ {#not}
 
 需要说明的是，以下情况并非紧急情况：
 
@@ -23,7 +23,7 @@
 
 等等。
 
-## 什么是 Hard Deadline？{#deadlines}
+## 什么是 Hard Deadline？ {#deadlines}
 
 硬性截止日期（Hard Deadline）是指如果你错过它会发生灾难性的事情。例如：
 

diff --git a/review/reviewer/navigate.md b/review/reviewer/navigate.md
@@ -18,7 +18,7 @@
 
 如果您获得了多个您不想变更的 CL，您应该考虑重整开发团队的开发过程或外部贡献者的发布过程，以便在编写CL之前有更多的沟通。最好在他们完成大量工作之前告诉别人“不”，这些工作现在必须被抛弃或彻底重写。
 
-## 第二步：检查 CL 的主要部分{#step_two}
+## 第二步：检查 CL 的主要部分 {#step_two}
 
 查找作为此 CL “主要”部分的文件。通常，逻辑变更最大的文件就是 CL 的主要部分。先看看这些主要部分。这有助于为 CL 的所有较小部分提供上下文，通常可以加速代码审查。如果 CL 太大而无法确定哪些部分是主要部分，请向开发人员询问您应该首先查看的内容，或者要求他们[将 CL 拆分为多个 CL](../developer/small-cls.md)。
 

diff --git a/review/reviewer/speed.md b/review/reviewer/speed.md
@@ -10,7 +10,7 @@
 * **开发者开始抗议代码审查流程。**如果审查者每隔几天只响应一次，但每次都要求对 CL 进行重大更改，那么开发者可能会变得沮丧。通常，开发者将表达对审查者过于“严格”的抱怨。如果审查者请求相同实质性更改（确实可以改善代码运行状况的更改），但每次开发者进行更新时都会快速响应，则抱怨会逐渐消失。**大多数关于代码审查流程的投诉实际上是通过加快流程来解决的。**
 * **代码运行状况可能会受到影响。**如果审查速度很慢，则放任开发者提交效果不尽如人意的 CL 的压力会增大。审查太慢还会阻止代码清理、重构以及对现有 CL 的进一步改进。
 
-## Code Review 应该有多快？{#fast}
+## Code Review 应该有多快？ {#fast}
 
 如果您没有处于重点任务的中，那么您应该在**收到代码审查后尽快开始**。
 
@@ -24,7 +24,7 @@
 
 相反，在回复审查请求之前，请等待工作中断点。可能是当你的当前编码任务完成，午餐后，从会议返回，从厨房回来等等。
 
-## 快速响应{#responses}
+## 快速响应 {#responses}
 
 当我们谈论代码审查的速度时，我们关注的是响应时间，而不是 CL 需要多长时间才能完成整个审查并提交。理想情况下，整个过程也应该是快速的，**快速的个人响应比整个过程快速发生更为重要**。
 
@@ -34,11 +34,11 @@
 
 重要的是，审查人员要花足够的时间进行审查，确信他们的“LGTM”意味着“此代码符合我们的[标准](standard.md)。”但是，理想情况下，个人反应仍然应该很[快](#fast)。
 
-## 跨时区审查{#tz}
+## 跨时区审查 {#tz}
 
 在处理时区差异时，尝试在他们还在办公室时回复作者。 如果他们已经下班回家了，那么请确保在第二天回到办公室之前完成审查。
 
-## 带评论的 LGTM{#lgtm-with-comments}
+## 带评论的 LGTM {#lgtm-with-comments}
 
 为了加快代码审查，在某些情况下，即使他们也在 CL 上留下未解决的评论，审查者也应该给予 LGTM/Approval，这可以是以下任何一种情况：