update before you ask

2025-02-25 21:04:04 +08:00 · 2015-03-29 10:23:08 +08:00 · 2015-03-29 10:23:08 +08:00 · 4228b372d6
commit 4228b372d6
parent fe8f2dbe35
1 changed files with 141 additions and 133 deletions
--- a/README.md
+++ b/README.md
@ -37,7 +37,7 @@ __本指南不提供此專案的實際支援服務！__

 儘管如此，黑客們有著蔑視或傲慢面對簡單問題的壞名聲，這有時讓我們看起來對新手、無知者似乎較有敵意，但其實不是那樣的。

-我們不諱言我們對那些不願思考、或者在發問前不做他們該做的事的人的蔑視。那些人是時間殺手 -– 他們只想索取，從不付出，消耗我們可用在更有趣的問題或更值得回答的人身上的時間。我們稱這樣的人為 "失敗者（魯蛇）" （由於歷史原因，我們有時把它拼作 "lusers"）。
+我們不諱言我們對那些不願思考、或者在發問前不做他們該做的事的人的蔑視。那些人是時間殺手 -– 他們只想索取，從不付出，消耗我們可用在更有趣的問題或更值得回答的人身上的時間。我們稱這樣的人為 ```失敗者（魯蛇）``` （由於歷史原因，我們有時把它拼作 ```lusers```）。

 我們意識到許多人只是想使用我們寫的軟體，他們對學習技術細節沒有興趣。對大多數人而言，電腦只是種工具，是種達到目的的手段而已。他們有自己的生活並且有更要緊的事要做。我們了解這點，也從不指望每個人都對這些讓我們著迷的技術問題感興趣。儘管如此，我們回答問題的風格是指向那些真正對此有興趣並願意主動參與解決問題的人，這一點不會變，也不該變。如果連這都變了，我們就是在降低做自己最擅長的事情上的效率。

@ -55,29 +55,31 @@ __本指南不提供此專案的實際支援服務！__

 在你準備要通過電子郵件、新聞群組或者聊天室提出技術問題前，請先做到以下事情：

-  1. 嘗試在你準備提問的論壇的舊文章中搜索答案
-  1. 嘗試上網搜索答案
-  1. 嘗試通讀手冊以找到答案。
-  1. 嘗試閱讀"常見問題"（FAQ）以找到答案。
+  1. 嘗試在你準備提問的論壇的舊文章中搜索答案。
+  1. 嘗試上網搜索以找到答案。
+  1. 嘗試閱讀手冊以找到答案。
+  1. 嘗試閱讀常見問題文件（FAQ）以找到答案。
  1. 嘗試自己檢查或試驗以找到答案
-  1. 向你身邊懂行的朋友打聽。
+  1. 向你身邊的強者朋友打聽以找到答案。
  1. 如果你是程式開發者，請嘗試閱讀原始碼以找到答案

-**當你提出問題的時候，請先表明你已經做了上述的努力**，這將有助於樹立你並不是一個妄圖不勞而獲的乞討者的形象，而且不會浪費別人的時間。 如果你能一併表達在做了上述努力的過程中所學到的東西會更好，因為我們更樂於回答那些表現出能從答案中學習的人的問題。
+當你提出問題的時候，請先表明你已經做了上述的努力；這將有助於樹立你並不是一個不勞而獲且浪費別人的時間的提問者。如果你能一併表達在做了上述努力的過程中所**學到**的東西會更好，因為我們更樂於回答那些表現出能從答案中學習的人的問題。

-運用某些策略，比如用Google先搜索你所遇到的各種錯誤提示訊息（既搜索Google論壇，也搜索網頁），這樣很可能直接就找到了能解決問題的文件或郵件列表線索。 即使沒有結果，在郵件列表或新聞組尋求幫助時提一句"我在谷歌中搜過下列句子但沒有找到什麼有用的東西" 也是件好事，即使它只是表明了搜索引擎不能提供哪些幫助。 這麼做（加上搜尋過的字串）也讓遇到相似問題的其他人能被搜尋引擎引導到你的提問來。
+運用某些策略，比如先用Google搜索你所遇到的各種錯誤訊息（既搜索[Google論壇](http://groups.google.com/)，也搜索網頁），這樣很可能直接就找到了能解決問題的文件或郵件列表線索。即使沒有結果，在郵件列表或新聞組尋求幫助時加上一句 ```我在Google中搜過下列句子但沒有找到什麼有用的東西``` 也是件好事，即使它只是表明了搜索引擎不能提供哪些幫助。這麼做（加上搜尋過的字串）也讓遇到相似問題的其他人能被搜尋引擎引導到你的提問來。

-別著急，不要指望幾秒鐘的Google搜尋就能解決一個複雜的問題。 先閱讀並看懂常見問題（FAQ）文件。在向專家求助之前，先放鬆、坐舒服一些，再花點時間思考一下這個問題。 相信我們，他們能從你的提問看出你做了多少閱讀與思考，如果你是有備而來，將更有可能得到解答。 不要將所有問題一股腦拋出，只因你的第一次搜索沒有找到答案（或者找到太多答案）。
+別著急，不要指望幾秒鐘的Google搜尋就能解決一個複雜的問題。在向專家求助之前，再閱讀一下常見問題（FAQ）文件、放輕鬆、坐舒服一些，再花點時間思考一下這個問題。相信我們，他們能從你的提問看出你做了多少閱讀與思考，如果你是有備而來，將更有可能得到解答。不要將所有問題一股腦拋出，只因你的第一次搜索沒有找到答案（或者找到太多答案）。

-準備好你的問題，**全面地將問題思考數遍**，因為草率的發問只能得到草率的回答，或者根本得不到任何答案。 越是表現出在尋求幫助前你為解決問題所付出的努力，你越有可能得到實質性的幫助。
+準備好你的問題，再將問題仔細的思考過一遍，因為草率的發問只能得到草率的回答，或者根本得不到任何答案。越是能表現出在尋求幫助前你為解決問題所付出的努力，你越有可能得到實質性的幫助。

-小心別問錯了問題。如果你的問題基於錯誤的假設，某個普通黑客（J. Random Hacker）多半會一邊在心裏想著"蠢問題…"， 一邊用無意義的字面解釋來答覆你，希望著你會從問題的回答（而非你想得到的答案）中汲取教訓。
+小心別問錯了問題。如果你的問題基於錯誤的假設，某個普通黑客（J. Random Hacker）多半會一邊在心裏想著```蠢問題…```， 一邊用無意義的字面解釋來答覆你，希望著你會從問題的回答（而非你想得到的答案）中汲取教訓。

-絕不要自以為夠資格得到答案，你沒這種資格。畢竟你沒有為這種服務支付任何報酬。 **你需要自己去"掙到"一個答案**，你能靠提出有內涵的，有趣的，有思維激勵作用的問題– 那些對社區的經驗有潛在貢獻的問題，而不僅僅是被動的從他人處索要知識。
+絕不要自以為**夠格**得到答案，你沒有；你並沒有。畢竟你沒有為這種服務支付任何報酬。你將會是自己去**掙到**一個答案，靠提出有內涵的、有趣的、有思維激勵作用的問題 --一個有潛力能貢獻社群經驗的問題，而不僅僅是被動的從他人處索取知識。

-另一方面，**表明你願意在找答案的過程中做點什麼，**是一個非常好的開端。 "誰能給點提示？"、"我的這個例子裏缺了什麼？"以及"我應該檢查什麼地方？"比"請把我需要的確切的過程貼出來"更容易得到答復。 因為你表現出只要有人能指個正確方向，你就有完成它的能力和決心。# 如何提問 #
+另一方面，表明你願意在找答案的過程中做點什麼是一個非常好的開端。```誰能給點提示？```、```我的這個例子裏缺了什麼？```以及```我應該檢查什麼地方```比```請把我需要的確切的過程貼出來```更容易得到答復。因為你表現出只要有人能指個正確方向，你就有完成它的能力和決心。

-## 慎選提問的論壇 ##
+##如何提問
+
+###慎選提問的論壇

 小心選擇你要提問的場合。如果你做了下述的事情，你很可能被忽略掉或者被看作失敗者：

@ -102,7 +104,7 @@ __本指南不提供此專案的實際支援服務！__

 可以理解的是，老練的黑客和一些熱門軟體的作者正在接受過多的錯發訊息。就像那根最後壓垮駱駝背的稻草一樣，你的加入也有可能使情況走向極端── 已經好幾次了，一些熱門軟體的作者從自己軟體的支援中抽身出來，因為伴隨而來湧入其私人郵箱的無用郵件變得無法忍受。

-## 新手網站或IRC回應最快 ##
+### 新手網站或IRC回應最快

 你當地的使用者群組，或者你所用的Linux發行版本也許正在宣傳他們的網頁論壇或IRC頻道，並提供新手幫助（在一些非英語國家，新手論壇很可能還是郵件列表）， 這些地方是開始提問的好去處，特別是當你覺得遇到的也許只是相對簡單或者很普通的問題時。經過宣傳的IRC頻道是公開歡迎提問的地方，通常可以即時得到回應。

@ -112,7 +114,7 @@ __本指南不提供此專案的實際支援服務！__

 通過論壇或 IRC 頻道來提供使用者支援服務有增長的趨勢，電子郵件則更多地為專案開發者間的交流而保留。所以最好先在論壇或 IRC 中尋求與該專案相關的協助。

-## 第二步，使用專案郵件列表 ##
+### 第二步，使用專案郵件列表

 當某個專案提供開發者郵件列表時，要向列表而不是其中的個別成員提問，即使你確信他能最好地回答你的問題。查一查專案的文件和首頁，找到專案的郵件列表並使用它。有幾個很好的理由支持我們採用這種辦法：

@ -127,7 +129,7 @@ __本指南不提供此專案的實際支援服務！__

 如果你找不到一個專案的郵件列表，而只能查到專案維護者的電子郵件地址，儘管向他發信。即使是在這種情況下，也別假設（專案）郵件列表不存在。在你的電子郵件中，請陳述你已經試過但沒有找到合適的郵件列表，也提及你不反對將自己的郵件轉發給他人（許多人認為，即使沒什麼秘密，私人電子郵件也不應該被公開。通過允許將你的電子郵件轉發他人，你給了相應人員處置你郵件的選擇）。

-## 使用有意義且描述明確的標題 ##
+### 使用有意義且描述明確的標題

 在郵件列表、新聞群組或論壇中，大約50字以內的標題是抓住資深專家注意力的黃金時機。別用喋喋不休的"幫幫忙"、"跪求"、"急"（更別說"救命啊！ ！！！"這樣讓人反感的話，用這種標題會被條件反射式地忽略）來浪費這個機會。不要妄想用你的痛苦程度來打動我們，相反，要在這點空間中使用最簡明扼要的描述方式來提出問題。

@ -148,13 +150,13 @@ __本指南不提供此專案的實際支援服務！__

 在網頁論壇上，因為話題與特定的線索緊密結合，並且通常在話題外就看不到裡面的內容，因此好的提問方式略有不同，通過回覆提問，而非改變標題是可接受的。不是所有論壇都允許在回覆中出現分離的主題，而且這樣做了基本上沒有人會去看。不過，通過回覆提問，這本身就是令人懷疑的做法，因為它們只會被正在查看該話題的人讀到。所以，除非你只想在該話題當前活躍的人群中提問，不然還是另起爐灶比較好。

-## 使問題容易回覆 ##
+### 使問題容易回覆

 以"請向……回复"來結束問題多半會使你得不到回答。如果你覺得花幾秒鐘在郵件客戶端設置一下回复地址都麻煩，我們也覺得花幾秒鐘考慮你的問題更麻煩。如果你的郵件程式不支持這樣做，換個好點的；如果是作業系統不支持這種郵件程式，也換個好點的。

 在論壇，要求通過電子郵件回覆是非常無禮的， 除非你確信回覆的信息也許是敏感的（而且有人會為了某些未知的原因，只讓你而不是整個論壇知道答案）。如果你只是想在有人回覆線索時得到電子郵件提醒，可以要求網頁論壇發送給你。幾乎所有論壇都支持諸如"追蹤此話題"、"有回覆發送郵件提醒"等功能。

-## 用辭貼切，語法正確，拼寫無誤 ##
+### 用辭貼切，語法正確，拼寫無誤

 我們從經驗中發現，粗心的寫作者通常也是馬虎的思考者（我敢打包票）。回答粗心大意者的問題很不值得，我們寧願把時間耗在別處。

@ -166,7 +168,7 @@ __本指南不提供此專案的實際支援服務！__

 如果在使用非母語的論壇提問，**你可以犯點拼寫和語法上的小錯，但決不能在思考上馬虎**（沒錯，我們能弄清兩者的分別）。同時，除非你知道回覆者使用的語言，否則請使用英語書寫。繁忙的黑客一般會直接刪除用他們看不懂語言寫的消息。在網路上英語是通用語言，用英語書寫可以將你的問題在尚未被閱讀就被直接刪除的可能性降到最低。

-## 使用易於讀取且標準的文件格式發送問題 ##
+### 使用易於讀取且標準的文件格式發送問題

 如果你人為地將問題搞得難以閱讀，它多半會被忽略，人們更願讀易懂的問題，所以：

@ -181,7 +183,7 @@ __本指南不提供此專案的實際支援服務！__

 如果你使用圖形用戶界面的郵件程式（如微軟公司的Outlook或者其它類似的），注意它們的預設配置不一定滿足這些要求。大多數這類程式有基於選單的"查看原始碼"命令，用它來檢查發送文件夾中的消息，以確保發送的是沒有多餘雜質的純文本文件。

-## 準確描述問題並言之有物 ##
+### 準確描述問題並言之有物

  * 仔細、清楚地描述問題的症狀。
  * 描述問題發生的環境（機器配置、作業系統、應用程式以及別的什麼），提供銷售商的發行版和版本號（如："Fedora Core 4"、"Slackware 9.1"等）。
@ -192,7 +194,7 @@ __本指南不提供此專案的實際支援服務！__

 Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpress.com/?id=725X1342&site=mmdays.wordpress.com&url=http%3A%2F%2Fwww.chiark.greenend.org.uk%2F~sgtatham%2Fbugs-cn.html&sref=http%3A%2F%2Fmmdays.wordpress.com%2F2007%2F09%2F25%2Fquestion%2F）》的出色文章。強力推薦你也讀一讀。

-## 話不在多而在精 ##
+### 話不在多而在精

 你需要提供精確有內容的資訊。這並不是要求你簡單的把成噸的出錯代碼或者資料完全轉錄到你的提問中。如果你有龐大而複雜的測試樣例能重現程式當掉的情境，儘量將它剪裁得越小越好。這樣做的用處至少有三點。

@ -200,7 +202,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre
 第二，簡化問題使你更有可能得到有用的答案；
 第三，在提煉你的bug報告的過程中，很可能你自己就找到了解決方法或權宜之計

-## 別動輒聲稱找到Bug ##
+### 別動輒聲稱找到Bug

 當你在使用軟體中遇到問題，除非你非常、非常的有根據，不要動輒聲稱找到了Bug。提示：除非你能提供解決問題的源代碼補丁，或者對前一版本的回歸測試表現出不正確的行為，否則你都多半不夠完全確信。對於網頁和文件也如此，如果你（聲稱）發現了文件的"Bug"，你應該能提供相應位置的替代文件。

@ -210,7 +212,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre

 提問時，即使你私下非常確信已經發現一個真正的臭蟲，最好寫得像是你做錯了什麼。如果真的有臭蟲，你會在回復中看到這點。這樣做的話，如果真有蟲子，維護者就會向你道歉，這總比你搞砸了然後欠別人一個道歉要強。

-## 低聲下氣前還是要先做功課 ##
+### 低聲下氣前還是要先做功課

 有些人明白他們不應該粗魯或傲慢地行事並要求得到答覆，但他們退到相反的低聲下氣的極端："我知道我只是個可憐的新手，一個失敗者，但... ..."。這既使人困擾，也沒有用，當伴隨著對實際問題含糊的描述時還特別令人反感。

@ -218,7 +220,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre

 有時網頁論壇會設有專為初學者提問的版面，如果你真的認為遇到了初淺的問題，到那去就是了，但一樣別那麼低聲下氣。

-## 描述問題症狀而非猜測 ##
+### 描述問題症狀而非猜測

 告訴黑客們你認為問題是怎樣引起的沒什麼幫助。（如果你的推斷如此有效，還用向別人求助嗎？）， 因此要確信你原原本本告訴了他們問題的症狀，而不是你的解釋和理論。讓黑客們來診斷吧。如果你認為陳述自己的猜測很重要，清楚地說明這只是你的猜測，並描述為什麼它們不起作用。

@ -227,7 +229,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre

 由於以上這點許多人似乎難以掌握，這裡有句話可以提醒你："所有的診斷專家都來自密蘇里州。" 美國國務院的官方座右銘則是："讓我看看"（出自國會議員威勒德。範迪弗在1899年時的講話："我來自一個出產玉米，棉花，牛蒡和民主黨人的國家，滔滔雄辯既不能說服我，也不會讓我滿意。我來自密蘇里州，你必須讓我看看。"） 針對診斷者而言，這並不是懷疑，而只是一種真實而有用的需求，以便讓他們看到的是與你看到的原始證據盡可能一致的東西，而不是你的猜測與總結。所以，展示給我們看吧。

-## 按發生時間先後列出問題症狀 ##
+### 按發生時間先後列出問題症狀

 問題發生前的一系列操作，往往就是對找出問題最有幫助的線索。因此，你的說明裡應該包含你的操作步驟，以及機器和軟體的反應，直到問題產生。在命令行處理的情況下，提供一段操作記錄（如運行腳本工具所生成的），並引用相關的若干行（如20行）記錄會非常有幫助。

@ -235,7 +237,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre

 如果你的說明很長（如超過四個段落），在開頭簡述問題，接下來再按時間順序詳述會有所幫助。這樣黑客們在讀你的記錄時就知道該注意哪些內容了。

-## 描述目標而不是過程 ##
+### 描述目標而不是過程

 如果你想弄清楚如何做某事（而不是報告一個Bug），在開頭就描述你的目標，然後才陳述重現你所遇到問題的特定步驟。

@ -246,7 +248,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre

 第二種提法是聰明的，你可能能得到建議採用更合適的工具以完成任務的回覆。

-## 別要求使用私人電郵回覆 ##
+### 別要求使用私人電郵回覆

 黑客們認為問題的解決過程應該公開，透明，此過程中如果更有經驗的人注意到不完整或者不當之處，最初的回覆才能夠，也應該被糾正。同時，作為幫助者也能因為能力和學識被其它同行看到而得到某種回報。

@ -254,7 +256,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre

 對這條規則存在一條有限的例外，如果你確信提問可能會引來大量雷同的回覆時，那麼"向我發電郵，我將為論壇歸納這些回覆"將是神奇的句子。試著將郵件列表或新聞組從洪水般雷同的回覆中解救出來是非常有禮貌的──但你必須信守諾言。

-## 提問應清楚明確 ##
+### 提問應清楚明確

 漫無邊際的提問近乎無休無止的時間黑洞。最有可能給你有用答案的人通常也正是最忙的人（他們忙是因為要親自完成大部分工作）。這樣的人對無節制的時間黑洞相當敏感，所以他們也傾向於討厭那些漫無邊際的提問。

@ -264,7 +266,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre

 所以，限定一下你的問題，以使專家辨識你的問題並回答時所需要付出的時間減到最少，這技巧對你取得答案相當有幫助–這技巧通常和簡化問題有所區別。因此，問"我想更好的理解X，可否指點一下哪有好一點說明？"通常比問"你能解釋一下X嗎？"更好。如果你的程式碼不能運作，通常請別人看看哪裡有問題，比要求別人替你改正要明智得多。

-## 當詢問有關程式碼的問題時 ##
+### 當詢問有關程式碼的問題時

 別要求他人給你有問題的代碼除錯而不提示一下應該從何入手。張貼幾百行的代碼，然後說一聲："它不能運行"會讓你得不到理睬。只貼幾十行代碼，然後說一句："在第七行以後，本應該顯示 的，但實際出現的是鍵"比較有可能讓你得到回應。

@ -274,13 +276,13 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre

 如果你只是想讓別人幫忙審一下代碼，在信的開頭就要說出來，並且一定要提到你認為哪一部分特別需要關注以及為什麼。

-## 別把自己家庭作業的問題貼上來 ##
+### 別把自己家庭作業的問題貼上來

 黑客們總是善於分辨哪些問題應該由你自己解決；因為我們中的大多數都曾自己解決這類問題。同樣，這些問題得由你來搞定，你會從中學到東西。你可以要求給點提示，但別要求得到完整的解決方案。

 如果你懷疑自己碰到了一個家庭作業式的問題，但仍然無法解決， 試試在使用者群組，論壇或（作為最後一招）在專案的"使用者"郵件列表或論壇中提問。儘管黑客們會看出來，但一些有經驗的使用者也許仍會給你提示。

-## 去除無意義的疑問 ##
+### 去除無意義的疑問

 避免用無意義的話結束提問，例如"有人能幫我嗎？"或者"有答案嗎？"。

@ -288,7 +290,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre
 其次：由於這樣問是畫蛇添足，黑客們會很厭煩你–而且通常會用邏輯上正確，但毫無意義的回答來表示他們的蔑視， 例如："沒錯，有人能幫你"或者"不，沒答案"。
 一般來說，避免提"是或否"類型的問題，除非你想得到"[是或否]（http://homepages.tesco.net/~J.deBoynePollard/FGA/questions-with-yes-or-no-answers.html）"類型的回答。

-## 不要把問題標記為"急"，即使對你而言確實如此 ##
+### 不要把問題標記為"急"，即使對你而言確實如此

 這是你的問題，而不是我們的。宣稱"緊急"（或"線上等"）極有可能事與願違：大多數黑客會直接刪除這種消息，他們認為這是無禮和自私地企圖得到即時與特殊的關照。

@ -298,7 +300,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre

 如果你覺得這點很不可思議，最好再把剩下的內容多讀幾遍，直到你弄懂了再發任何文章也不遲。

-## 有禮貌絕沒有害處，而且有時是有益的 ##
+### 有禮貌絕沒有害處，而且有時是有益的

 彬彬有禮，多用"請"和"謝謝你的關注"，或"謝謝你的關照"。讓大家都知道你對他們花費時間義務提供幫助心存感激。

@ -308,7 +310,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre

 （我們注意到，自從本指南發佈後，從資深黑客處得到的唯一嚴重缺陷反饋，就是對預先道謝這一條。一些黑客覺得"先謝了"的言外之意是事後就不用再感謝任何人的暗示。我們的建議是要麼先說"先謝了"，事後再對回复者表示感謝， 要么換種方式表達，譬如用"謝謝你的關注"或"謝謝你的關照"。）

-## 問題解決後，加個簡短說明 ##
+### 問題解決後，加個簡短說明

 問題解決後，向所有幫助過你的人發個說明，讓他們知道問題是怎樣解決的，並再一次向他們表示感謝。如果問題在新聞組或者郵件列表中引起了廣泛關注，應該在那裏貼一個補充說明比較恰當。

@ -326,7 +328,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre

 在黑客中，這種良好的後繼行動實際上比傳統的禮節更為重要，也是你如何透過善待他人而贏得聲譽的方式。這是筆非常有價值的財富。# 如何解讀答案 #

-## RTFM和STFW：如何知道你已完全搞砸 ##
+### RTFM和STFW：如何知道你已完全搞砸

 有一個古老而神聖的傳統：如果你收到"RTFM （Read The Fxxking Manual）"的回應，回答者認為你應該去讀讀該死的手冊。當然，基本上他是對的，你應該去讀一讀。

@ -341,13 +343,13 @@ RTFM有一個年輕的親戚。如果你收到"STFW （Search The Fxxking Web）

 別為這個而不爽；**依照黑客的標準，他已經表示了對你一定程度的關注，而沒有對你的要求視而不見**。你應該對他祖母般的慈祥表示感謝。

-## 如果還是搞不懂 ##
+### 如果還是搞不懂

 如果你看不懂回應，別立刻要求對方解釋。像你以前試著自己解決問題時那樣（利用手冊，FAQ，網路，身邊的高手），先試著去搞懂他的回應。如果你真的需要對方解釋，記得表現出你已經從中學到了點什麼。

 比方說，如果我回答你："看來似乎是zentry被擋住了；你應該先清除它。"，然後，這是一個很糟的後續問題回應："zentry是什麼？" 聰明的問法應該是這樣："哦~~~我看過說明了但是只有-z和-p兩個參數中提到了zentry，而且還都沒有清楚的解釋:<你是指這兩個中的哪一個嗎？還是我看漏了什麼？"~~

-## 應對粗魯的回應 ##
+### 應對粗魯的回應

 很多黑客圈子中看似無禮的行為並不是存心冒犯。相反，它是直接了當，一針見血式的交流風格，這種風格更關注解決問題，而不是使別人感覺舒服而卻模模糊糊。

@ -381,7 +383,7 @@ RTFM有一個年輕的親戚。如果你收到"STFW （Search The Fxxking Web）

 以下是幾個經典蠢問題，以及黑客在拒絕回答時心中所想的：

-## 問題清單 ##
+### 問題清單

 問題：我能在哪找到X程式或X資源？

@ -401,7 +403,7 @@ RTFM有一個年輕的親戚。如果你收到"STFW （Search The Fxxking Web）

 問題：我怎麼才能破解root帳號/竊取OP特權/讀別人的郵件呢？

-## 蠢問題範例 ##
+### 蠢問題範例

 問題：我能在哪找到X程式或X資源？

@ -512,7 +514,9 @@ RTFM有一個年輕的親戚。如果你收到"STFW （Search The Fxxking Web）

 通過我的提問方法，我給了別人可以咀嚼玩味的東西；我設法讓人們很容易參與並且被吸引進來。我顯示了自己具備和他們同等的能力，並邀請他們與我共同探討。通過告訴他們我所走過的彎路，以避免他們再浪費時間，我也表明了對他們寶貴時間的尊重。

-事後，當我向每個人表示感謝，並且讚賞這次良好的討論經歷的時候， 一個Linux內核郵件列表的成員表示，他覺得我的問題得到解決並非由於我是這個列表中的"名人"，而是因為我用了正確的方式來提問。 黑客從某種角度來說是擁有豐富知識但缺乏人情味的傢伙；我相信他是對的，如果我像個乞討者那樣提問，不論我是誰，一定會惹惱某些人或者被他們忽視。 他建議我記下這件事，這直接導致了本指南的出現。# 如果得不到回答 #
+事後，當我向每個人表示感謝，並且讚賞這次良好的討論經歷的時候， 一個Linux內核郵件列表的成員表示，他覺得我的問題得到解決並非由於我是這個列表中的"名人"，而是因為我用了正確的方式來提問。黑客從某種角度來說是擁有豐富知識但缺乏人情味的傢伙；我相信他是對的，如果我像個乞討者那樣提問，不論我是誰，一定會惹惱某些人或者被他們忽視。他建議我記下這件事，這直接導致了本指南的出現。
+
+##如果得不到回答

 如果仍得不到回答，請不要以為我們覺得無法幫助你。有時只是看到你問題的人不知道答案罷了。沒有回應不代表你被忽視，雖然不可否認這種差別很難區分。

@ -524,7 +528,9 @@ RTFM有一個年輕的親戚。如果你收到"STFW （Search The Fxxking Web）

 另外，你可以向很多商業公司尋求幫助，不論公司大還是小（Red Hat 和LinuxCare 就是兩個最常見的例子）。別為要付費才能獲得幫助而感到沮喪！ 畢竟，假使你的汽車發動機汽缸密封圈爆掉了–完全可能如此–你還得把它送到修車鋪，並且為維修付費。就算軟體沒花費你一分錢，你也不能強求技術支援總是免費的。

-對大眾化的軟體，像是Linux之類而言，每個開發者至少會對應到上萬名使用者。根本不可能由一個人來處理來自上萬名使用者的求助電話。 要知道，即使你要為這些協助付費，和你所購買的同類軟體相比，你所付出的也是微不足道的（通常封閉原始碼軟體的技術支援費用比開放原始碼軟體的要高得多，且內容也沒那麼豐富）。# 如何更好地回答問題 #
+對大眾化的軟體，像是Linux之類而言，每個開發者至少會對應到上萬名使用者。根本不可能由一個人來處理來自上萬名使用者的求助電話。要知道，即使你要為這些協助付費，和你所購買的同類軟體相比，你所付出的也是微不足道的（通常封閉原始碼軟體的技術支援費用比開放原始碼軟體的要高得多，且內容也沒那麼豐富）。
+
+## 如何更好地回答問題

 態度和善一點。問題帶來的壓力常使人顯得無禮或愚蠢，其實並不是這樣。

@ -542,7 +548,9 @@ RTFM有一個年輕的親戚。如果你收到"STFW （Search The Fxxking Web）

 幫助你的社群從中學習。當回覆一個好問題時，問問自己"如何修改相關文件或常見問題文件以免再次解答同樣的問題？"，接著再向文件維護者發一份patch。

-如果你是在研究一番後才做出的回答，展現你的技巧而不是直接端出結果。畢竟"授人以魚，不如授人以漁"。# 相關資源 #
+如果你是在研究一番後才做出的回答，展現你的技巧而不是直接端出結果。畢竟"授人以魚，不如授人以漁"。
+
+## 相關資源

 如果需要個人電腦，Unix系統和網路如何工作的基礎知識，參閱[Unix系統和網路基本原理]（http://en.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/）。