diff --git a/how-to-ask-questions-the-smart-way/README.md b/how-to-ask-questions-the-smart-way/README.md
index cf3c772..25e1cd5 100644
--- a/how-to-ask-questions-the-smart-way/README.md
+++ b/how-to-ask-questions-the-smart-way/README.md
@@ -202,7 +202,7 @@
 本地的用户组织或者你所用的`Linux`发行版也许正在宣传新手取得帮助的论坛或`IRC`通道（在一些非英语国家，新手论坛很可能还是邮件列表），这些地方是开始提问的好去处，特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。
 经过宣传的`IRC`通道是公开邀请提问的地方，通常可以得到实时的回复。
 
-事实上，如果出问题的程序来自某发行版（这很常见），最好先去该发行版的论坛或邮件列表中提问，再到程序本身的项目论坛或邮件列表，（否则）该项目的黑客可能仅仅回复『用 **_我们的_** 代码』。
+事实上，如果出问题的程序来自某发行版（这很常见），最好先去该发行版的论坛或邮件列表中提问，再到程序本身的项目论坛或邮件列表。否则该项目的黑客可能仅仅回复『用 **_我们的_** 代码』。
 
 在任何论坛发贴以前，先看看有没有搜索功能。如果有，就试着用问题的几个关键词搜索一下，也许就有帮助。如果在此之前你已做过全面的网页搜索（你应该这样去做），还是再搜索一下论坛，搜索引擎有可能没来得及索引此论坛的全部内容。
 
@@ -212,8 +212,8 @@
 
 当某个项目存在开发者邮件列表时，要向列表而不是其中的个别成员提问，即使你确信他能最好地回答你的问题。查一查项目的文档和主页，找到项目的邮件列表并使用它。采用这种办法有几个很好的理由：
 
-* 向个别开发者提的问题（如果）足够好，也将对整个项目组有益。相反，如果你认为自己的问题对整个项目组来说太愚蠢，这也不能成为骚扰个别开发者的理由。
-* 向列表提问可以分散开发者的负担，个别开发者（尤其是项目领导）也许太忙以至于没法回答你的问题。
+* 向一个开发者提的好问题，对整个项目组也会有益。反之，如果你认为自己的问题对整个项目组来说太愚蠢，就没有理由去去骚扰单个开发者。
+* 向列表提问可以分散开发者的负担，单个开发者（尤其是项目领导）也许太忙以至于没法回答你的问题。
 * 大多数邮件列表都要存档，那些存档将被搜索引擎索引，如果你向列表提问并得到解答，将来其它人可以通过网页搜索找到你的问题和答案，也就不用再次发问了。
 * 如果某些问题经常被问到，开发者可以利用此信息改进文档或软件本身，以使其更清楚。如果只是私下提问，就没有人能看到最常见问题的完整场景。
 
@@ -223,7 +223,7 @@
 建议你在张贴前最好先暗暗地观察几天，至少看看最近几天保存的帖子，以了解那的行事方式（事实上这是参与任何私有或半私有列表的好主意）
 
 如果你找不到一个项目的邮件列表，而只能查到项目维护者的地址，只管向其发信。
-即便在这种情况下，也别假设（项目）邮件列表不存在。在你的电子邮件中陈述你已经试过但没有找到合适的邮件列表，也提及你不反对将自己的邮件转发给他人
+即便在这种情况下，也别假设项目的邮件列表不存在。在你的电子邮件中陈述你已经试过但没有找到合适的邮件列表，也提及你不反对将自己的邮件转发给他人
 （许多人认为，即使没什么秘密，私人电子邮件也不应该被公开。通过允许将你的电子邮件转发他人，你给了相应人员处置你邮件的选择）。
 
 ### 使用有意义且明确的主题
@@ -231,7 +231,7 @@
 在邮件列表、新闻组或论坛中，主题是你在五十个或更少的字以内吸引有资格专家注意的黄金机会，不要用诸如 『请帮我』 （更别提大写的 『请帮我！！！！』，这种主题的消息会被条件反射式地删掉）之类的唠叨浪费机会。
 不要用你痛苦的深度来打动我们，相反，要在这点空间中使用超级简明扼要的问题描述。
 
-使用主题的好惯例是『对象 —— 偏差』（式的描述），许多技术支持组织就是这样做的。在『对象』部分指明是哪一个或哪一组东西有问题，在『偏差』部分则描述与期望的行为不一致的地方。
+编写主题题头好的惯例格式是『对象 —— 偏差』，许多技术支持组织都支持这么做。在『对象』部分指明是哪一个或哪一组东西有问题，在『偏差』部分则描述与期望的行为不一致的地方。
 
 **愚蠢：**
 
@@ -252,7 +252,7 @@
 
 如果你想在回复中提问，确保改变主题以表明你是在问一个问题，一个主题像 『Re: 测试』 或者 『Re: 新臭虫』的消息不太可能引起足够的注意。同时，将回复中与新主题不甚相关的引用内容尽量删除。
 
-对于列表消息，不要直接点击回复（按钮）来开始一个全新的线索，这将限制你的观众。有些邮件阅读程序，比如`mutt`，允许用户按线索排序并通过折叠线索来隐藏消息，这样做的人永远看不到你发的消息。
+对于列表消息，不要直接点击回复按钮来开始一个全新的线索，这将限制你的观众。有些邮件阅读程序，比如`mutt`，允许用户按线索排序并通过折叠线索来隐藏消息，这样做的人永远看不到你发的消息。
 
 仅仅改变主题还不够。`mutt`和其它一些邮件阅读程序还要检查邮件头主题以外的其它信息，以便为其指定线索，所以宁可发一个全新的邮件。
 
@@ -271,7 +271,7 @@
 
 经验告诉我们，粗心与草率的作者通常也粗心与草率地思考和编程（我敢打赌）。为这些粗心与草率的思考者回答问题没有什么好处，我们宁可将时间花在其它地方。
 
-清楚、良好地表达你的问题非常重要。如果你觉得这样做麻烦，我们也觉得注意（你的问题）麻烦。
+清楚、良好地表达你的问题非常重要。如果你觉得这样做麻烦，我们也觉得注意你的问题麻烦。
 花点额外的精力斟酌一下字句，用不着太僵硬与正式 —— 事实上，黑客文化很看重能准确地使用非正式、俚语和幽默的语句。但它 **_必须_** 很准确，而且有迹象表明你是在思考和关注问题。
 
 正确地拼写、使用标点和大小写，不要将『its』混淆为『it's』，『loose』搞成『lose』或者将『discrete』弄成 『discreet』。不要全部用大写，这会被视为无礼的大声嚷嚷
@@ -296,8 +296,8 @@
 
 如果你人为地将问题搞得难以阅读，它多半会被忽略，人们更愿读易懂的问题，所以：
 
-* 使用纯文本而不是`HTML`（超文本标注语言）（ [关闭`HTML`](http://www.birdhouse.org/etc/evilmail.html) 并不难）
-* 使用`MIME`（多用途互联网邮件扩展）附件通常没有问题，前提是真正有内容（譬如附带的源文件或补丁），而不仅仅是邮件客户端程序生成的模板（譬如只是消息内容的拷贝）。
+* 使用纯文本而不是`HTML`（ [关闭`HTML`](http://www.birdhouse.org/etc/evilmail.html) 并不难）
+* 使用`MIME`附件通常没有问题，前提是真正有内容（譬如附带的源文件或补丁），而不仅仅是邮件客户端程序生成的模板（譬如只是消息内容的拷贝）。
 * 不要发送整段只是单行句子但多次折回的邮件（这使得回复部分内容非常困难）。设想你的读者是在80个字符宽的文本终端阅读邮件，设置你的行折回点小于 80 列。
 * 但是，也 **_不要_** 用任何固定列折回数据（譬如日志文件拷贝或会话记录）。数据应该原样包含，使回复者确信他们看到的是与你看到的一样的东西。
 * 在英语论坛中，不要使用`'Quoted-Printable' MIME`编码发送消息。这种编码对于张贴非`ASCII`语言可能是必须的，但很多邮件程序并不支持。
@@ -328,7 +328,7 @@
 
 ### 量不在多，精炼则灵
 
-你应该（写得）精炼且有内容，简单地将一大堆代码或数据罗列在求助消息中达不到目的。如果你有一个很大且复杂的测试样例让程序崩溃，尝试将其裁剪得越小越好。
+你应该写得精炼且有内容，简单地将一大堆代码或数据罗列在求助消息中达不到目的。如果你有一个很大且复杂的测试样例让程序崩溃，尝试将其裁剪得越小越好。
 
 至少有三个理由支持这点。第一，让别人看到你在努力简化问题使你更有可能得到回复。
 第二，简化问题使你更有可能得到 **_有用的_** 回复。第三，在提纯臭虫报告的过程中，你可能自己就找到了解决办法或权宜之计。
@@ -337,13 +337,13 @@
 
 当你在一个软件中遇到问题，除非你 **_非常、非常_** 的有根据，不要动辄声称找到了臭虫。
 提示：除非你能提供解决问题的源代码补丁，或者对前一版本的回归测试表现出不正确的行为，否则你都多半不够完全确信。
-对于网页和文档也如此，如果你（声称）发现了文档的『臭虫』，你应该能提供相应位置的替代文本。
+对于网页和文档也如此，如果你发现了文档的『臭虫』，你应该能提供相应位置的替代文本。
 
 记住，还有许多其它用户并未经历你遇到的问题，否则你在阅读文档或搜索网页时就应该发现了（你在报怨前已经做了这些，[是吧](#提问前) ？）。
 这也意味着很有可能是你弄错了而不是软件本身有问题。
 
 编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了臭虫，也就置疑了他们的能力，即使你是对的，也有可能会使其中的部分人感到不快。
-（此外，）在主题中嚷嚷『臭虫』也是特别不老练的。
+此外，在主题中嚷嚷『臭虫』也是特别不老练的。
 
 提问时，即使你私下非常确信已经发现一个真正的臭虫，最好写得像是 **_你_** 做错了什么。如果真的有臭虫，你会在回复中看到这点。
 这样做的话，如果真有虫子，维护者就会向你道歉，这总比你弄砸了然后欠别人一个道歉要强。
@@ -374,7 +374,7 @@
 由于以上这点许多人似乎难以掌握，这里有句话可以提醒你：『所有的诊断专家都来自密苏里州』。
 美国国务院的官方座右铭则是『让我看看』（出自国会议员威勒德 · D · 范迪弗［_Willard D. Vandiver_］在1899年时的讲话：
 『我来自一个出产玉米、棉花、牛蒡和民主党人的国家，滔滔雄辩既不能说服我，也不会让我满意。我来自密苏里州，你必须让我看看。』）
-针对诊断者而言，这并不是怀疑，而只是一种真实而有用的需求，以便让他们看到与你看到的原始证据尽可能一致的东西，而不是你的猜测与总结。（所以，）让我们看看。
+针对诊断者而言，这并不是怀疑，而只是一种真实而有用的需求，以便让他们看到与你看到的原始证据尽可能一致的东西，而不是你的猜测与总结。所以，让我们看看。
 
 ### 按时间先后罗列问题症状
 
@@ -417,7 +417,7 @@
 最有可能给你有用答案的人通常也是最忙的人（假如只是因为他们承担了太多工作的话），这些人对于没有止境的时间无底洞极其敏感，所以他们也倾向于讨厌那些漫无边际的问题。
 
 如果你明确了想让回复者做的事（如指点方向、发送代码、检查补丁或其它），你更有可能得到有用的回复。
-（因为）这样可以让他们集中精力并间接地设定了他们为帮助你需要花费的时间和精力上限，这很好。
+因为这样可以让他们集中精力并间接地设定了他们为帮助你需要花费的时间和精力上限，这很好。
 
 要想理解专家生活的世界，可以这样设想：那里有丰富的专长资源但稀缺的响应时间。你暗中要求他们奉献的时间越少，你越有可能从这些真正懂行也真正很忙的专家那里得到解答。