提問的智慧
提問的智慧（How To Ask Questions The Smart Way）
作者
Eric Steven Raymond
Thyrsus Enterprises <esr@thyrsus.com>
Rick Moen <rick@linuxmafia.com>
Copyright © 2001 Eric S. Raymond
版本修訂紀錄
Revision 3.1 文件：Google 是你的朋友！ 2004.10.28 by esr
Revision 3.0 主要增加網頁論壇應有的禮節內容 2004.02.02 by esr
目錄
譯文
免責聲明
引言
發問前
發問時
慎選論壇
為新手而設的網頁與 IRC 論壇可以最快得到回應
第二步，使用項目郵件列表
使用有意義且明確的主題
想辦法讓問題容易回覆
用清晰、合乎文法與拼音的語言
用容易瞭解的格式送出問題
描述你的問題須精準且提供足夠資訊
寫得多不如寫得巧
不要動輒宣稱你發現程式臭蟲
低聲下氣不能代替你該做的事
描述問題的症狀，而不是你的臆測
依序列出你的問題症狀
描述目的而不是步驟
不要請人私下回信
搞清楚你要問的是什麼
不要把你的作業拿來提問
省去不得要領的請求
不要標明問題緊急，即使真的是這樣
禮多人不怪，有些時候還很有幫助
問題解決後簡短說明一下
如何解讀回答
RTFM 與 STFW：如何知道你已經搞砸了
如果你還是不懂…
面對無禮的情況
別反應得像個失敗者一樣
提問禁忌
好問題與爛問題
若沒有得到答案
如何提出有助益的回答
相關資源
鳴謝
譯文
原文：How To Ask Questions The Smart Way
繁體中文翻譯：提問的智慧
其他譯文版本：中文（簡體）、捷克語、丹麥語、愛沙尼亞語、法語文、德語、希伯來語、匈牙利語、義大利語、日語、波蘭語、俄語、西班牙語、瑞典語以及土耳其語。
如果你想要複製、鏡射、翻譯或是引用本文，請看我們的複製政策。
免責聲明
許多主題網站在他們如何取得幫助的部分連結到了本文，這沒有關係，也是我們想要的，但如果你是製作這個連結的網管，請在該連結附近顯著註明：我們並不是此網站的服務台。
我們已經學到沒有此聲明所帶來的痛苦，我們一再地受到白痴的騷擾。他們認為既然我們發布了這份文件，我們就要解決世界上所有相關的技術問題。
如果你是因為需要幫助而來閱讀這份文件，而認為可以從我們這得到幫助，那麼你也成了白痴之一。不要問我們問題，我們只會不鳥你。我們只是教你，如何向懂得你正在操作的軟硬體的人取得幫助，但有 99% 的機會我們不是這種人。除非你確信我們之中有人是你真正想詢問的專家，否則放過我們吧，這樣大家都會快樂些。
引言
在電腦高手的世界裡，你得到的問題解答，取決於你提問的方法與問題的難度。這份指南將教你如何提出一個最容易令你得到滿意答案的問題。
現在開放原始碼的應用越來越普及，你可以從有經驗的人那邊得到幫助，而不是所謂的電腦高手。這是件好事，因為這些使用者一般對於新手常遭遇的問題會比較寬容。同樣地，用我們的方法來對待這些有經驗的使用者，跟拿來與電腦高手打交道一樣有效。
首先必須了解的是，電腦高手們喜歡有挑戰性且有深度的好問題。如果不是這樣的話，我們也不用在這邊廢話了。如果你給我們一個有趣的議題，我們會非常感謝你，因為這是個很好的刺激與禮物。一個好的問題可以幫助我們發現被遺漏而未曾注意的問題。在電腦高手中，“好問題！”是非常強烈而真摯的讚美。
除此之外，有時候電腦高手們會對簡單的問題表現得敵視或自大，看起來好像是我們輕視新手或外行人，但事實上並不盡然如此。
只有對於不想思考或在問問題前不先做功課的人，我們才會表現出毫無歉意的敵意。這種人就像時間漩渦般，問了就跑，只會浪費我們的時間，使我們錯過更值得注意的問題或更值得回答的人。這種人我們稱之為“失敗者”（loser，基於一些歷史因素，有時候我們會將之拼為lusers。）。
我們體認到，有很多人只想使用我們寫的程式，但對一些技術性的細節沒什麼興趣。對大多數人來說，電腦只是個工具、一種獲取結果的方法，他們有自己的生活要過，還有其他更重要的事情要做。我們承認這點，也不期望大家都對這些讓我們著迷的技術細節有興趣。雖然如此，我們回答的風格還是會與那些有求知慾並主動參與的人同調。這不會改變、也不該改變的，一旦改變了，我們也會對原本我們做得最好的事情不再那麼有效率。
我們大多數是自願者，從繁忙的生活中撥時間來回答問題，而有時候我們也會力不從心，所以我們會殘酷地過濾問題。特別是那些看起來就像是失敗者提的問題，以期把回答問題的時間更有效率地花在勝利者身上。
如果你覺得這種態度令人憎惡、像施捨東西一般或是自大，請檢查你的假設，我們並未要求你屈服於我們。事實上，如果你做了該有的努力，我們巴不得對你平等並歡迎你進入我們的世界。但是我們才不會蠢到去幫助那些不肯自助的人，這是笨蛋才做的事情。
所以我們可以知道，要得到我們的注意，本身技術並不需要非常高竿，而是必須表現出你的能力－－機伶、能思考、善於觀察的，並且在解決問題的過程中是一個很主動的參與者。如果你表現不出這些差異，我們建議你花錢找人幫忙，而不是要我們無償貢獻協助。
如果你決定來找我們幫忙了，你不會想被我們認為是失敗者，也不想成為一個失敗者。得到快速回應的訣竅，在於聰明而有自信的提問，並且暗示只在特定關鍵上需要幫忙。
（歡迎對本文進行指正，你可以寫信到 esr@thyrsus.com。但注意，本文並不想成為一般性的網路禮儀指南（Netiquette Guidelines），因此我們會駁回與在技術論壇中激起有用答案無關的建議。）
發問前
在你用電子郵件、新聞群組或是網站討論區提問前，先做以下事情：
嘗試搜尋網路來找答案
嘗試閱讀說明書來找答案
嘗試閱讀常見問與答（FAQ, Frequently Asked Questions）來找答案
嘗試自己實驗檢查來找答案
嘗試先詢問內行的朋友來找答案
如果你是程式設計師，嘗試從原始碼中找答案
提問時，先表明你已經做過上述事情，這樣有助於建立你不是個浪費時間的寄生蟲的印象。最好還能表示你已從中領悟了什麼，我們喜歡那些可以從答案中學習的人。
使用一些手段，諸如利用 Google 搜尋你的錯誤訊息（要同時搜尋網頁與討論區），也許就直接找到可以解決你問題的文件或是郵件，就算沒找到，你也可以說：「我用 Google 搜尋了相關關鍵字，可是沒有有用的結果。」這在你的提問中是件好事。
徹底組織思考你的問題後再提出。一個草率的提問只會獲得同樣草率的答案，甚至沒人鳥你。越是表現出你在提問前確實努力過，就越能獲得實質上的幫助。
小心問錯問題。若你的問題建立於錯誤的假設上，某高手會邊想著“蠢問題……”，邊以敷衍無用的答案回覆你，並希望你能從中學到教訓。
絕不要假設你有資格得到回答，畢竟你沒有付錢。如果你提了個確實有趣且可激發思考的問題，並且可以無形中對社群有所貢獻，而不只是單純想從別人那兒得到答案，那你自然就會為自己爭取到答案。
另一方面，表明你可以、也希望參與問題解答過程，也是一個很好的開始。「有沒有人能給點提示？」、「我還漏了些什麼？」、「有什麼網站可以參考嗎？」會比「請給我正確的步驟。」更容易得到答案，因為你表明了若有人給個方向，你就樂於完成剩下的部分。
發問時
慎選論壇
要注意你該在哪提問，否則八成會被忽略或是當成失敗者：
在不相關的論壇張貼你的問題
在進階論壇提基礎問題，反之亦然
一文多貼到太多不同的新聞群組
給既非熟人也沒義務解決你問題的人發私人信件
為了保護他們的通信頻道不被無關緊要的東西淹沒，高手們通常會刪除那些走錯板的問題。你不會想要有這種經驗的。
因此首先你要找對論壇，再來是善用 Google 等搜尋引擎，用他們來搜尋與你出問題的軟硬體相關的網站，它們通常也會有 FAQ 清單、郵件列表與精華區。如果你努力過了還找不到答案，這些郵件列表可能是你的最終目標。網頁上可能也會有臭蟲回報的流程與連結，有的話就去看看。
向不熟悉的人或論壇發信件極有可能是在冒險，別假設作者或提供資訊的網站有意願當你的免費顧問，也別樂觀地以為他們會歡迎你的問題。如果你不確定以上幾點，換個地方發問，或是根本就別問。
在搜尋網頁論壇、新聞群組與郵件列表的時候，不要太相信它們的名字。先看一下 FAQ 或使用許可，以確認你的問題不會離題。發文前先翻一下過去的文章以熟悉那裡的風格，此外，最好先在論壇或郵件列表精華區中將你問題相關的關鍵字搜尋一次。也許就會找到答案，如果沒有，也有助於你陳述你的問題。
不要一次對所有幫助頻道亂槍打鳥，這樣讓人感覺你在大聲嚷嚷而激怒其他人。一步一步來吧。
瞭解你要問的主題。最典型的一種錯誤是，在一個討論關於跨 Unix 及 Windows 程式語言、程式庫與工具的論壇，詢問程序介面的問題。如果你不懂為什麼這樣不對，在離開去搞清楚之前最好都不要發問。
一般來說，在對的公開論壇問對的問題，得到答案的機率比在私有論壇詢問要高，有許多理由可證實。一是看潛在的回應者有多少，二是看聽眾有多少。同樣回答一個問題，高手們寧可在公開論壇指導一群人，也不願在私有論壇服務少數人。
可以理解的，有能力的高手與知名軟體的作者們已經收到太多超出他們能力範圍的不當訊息了。在極端的情況下，你可能會成為壓死駱駝的最後一根稻草－－這樣的情況已經發生好幾次了，知名軟體的作者收回他們對軟體的支持，因為隨之而來的垃圾郵件傷害已經超出他們所能負荷的範圍。
為新手而設的網頁與 IRC 論壇可以最快得到回應
你的本地使用者群組，或是 Linux 的發行版本，也許正在宣傳一個給新手使用的網頁論壇或是 IRC 頻道（在非英語國家，也許還只有郵件列表。）。它們是發問地點的首選，尤其是當你的問題相對簡單或是很常見的時候。一個經過廣告的 IRC 頻道本身就是歡迎問問題的，也最容易得到即時的幫助。
事實上，如果你是使用某軟體的修改版（現在很常見），那你最好在該版本的論壇上提問，而不是到整個軟體計劃的論壇，否則他們可能只會跟你說：「用我們的版本吧。」
在張貼你的問題前，先看看論壇有沒有搜尋的功能。如果有的話，先用幾個關鍵字搜尋與你類似的問題，也許會有幫助。如果你之前已經做過一般的網頁搜尋（這是你該做的），到這邊還是再搜尋一次，因為也許網頁搜尋引擎尚未索引新的內容。
用網頁論壇或是 IRC 頻道來提供支援的方式有增加的趨勢，而 E-mail 則多保留為開發交流之用，因此如果需要幫助的話，盡可能先尋找這些服務吧。
第二步，使用項目郵件列表
當研發者郵件列表存在的時候，就算你知道誰可以將你的問題回答得最好，你還是應該將問題寄給列表中的每一為開發成員，而不是特定的某人。先檢查專案中的文件及其網頁，找出郵件列表並使用它，以下是幾點原則：
任何值得向單一開發成員提出的問題，同樣也值得向整個團隊提出；反之，如果你自認你的問題太蠢，那也不值得你打擾任何一位開發成員。
詢問列表中的所有成員可以分散他們的壓力。單一成員（尤其是整個專案的領導者）可能因為太忙而無法回覆你的問題。
大部分的郵件列表都會被保存並且讓搜尋引擎索引，其他有類似問題的人可以直接尋找答案而不用打擾列表中的人員。
如果某些問題常被詢問，開發者可根據這些訊息來改進他們的文件或軟體以免使人疑惑。如果你私下詢問，就沒人會知道整個問題的全貌。
如果一個專案同時有使用者、開發者（甚至修改版本）郵件列表或是網頁論壇，而你並沒有修改程式碼，那麼你應該在使用者列表、論壇發問。不要以為你在開發者的郵件列表中會受到歡迎，你的問題可能會成為交流開發訊息中的噪音。
然而，如果你覺得你的問題並不一般，而且在使用者郵件列表及論壇中好幾天都得不到答案，你也許可以試試看開發者的郵件列表或論壇。不過建議你，最好可以在那觀察幾天以瞭解他們的風氣（事實上這也是參與其他私有或半私有郵件列表與論壇的好方法）。
如果你找不到該主題的郵件列表地址，而只看到維護者的地址，就放手去寫信給他們吧。但即使在這樣的情況下，也別就認為該郵件烈表是不存在的，請表明你曾試著尋找，但未找到適合的郵件列表，順便提到你不反對將這個訊息轉給相關的人。（許多人認為私人信件應該保持私密，即使其中並沒有什麼秘密。允許轉寄你的訊息，可給對方多一個處理你訊息的選擇。）
使用有意義且明確的主題
在郵件列表、新聞群組或網頁論壇中，使用這 50 字元甚至更少的文字，是吸引適合回答你問題的專家的最好機會。不要用「請幫我」（或是大寫的「請幫我」，這樣的訊息通常會被反射性地略過。）等等含糊的標題。別想用這種痛苦的深度來打動我們，改用簡明扼要的問題描述取代吧。
許多技術支援組織使用的優良主題慣例是像“對象－偏差”的形式。所謂的“對象”指的是出問題的設備，而“偏差”則是指問題的狀況。
愚蠢的做法： 救命啊！我的筆電畫面有問題！
聰明的做法： XFree86 4.1 滑鼠游標異常，某顯卡 MV1005 型號晶片組。
最聰明的做法： 使用某顯卡 MV1005 型號晶片組的 XFree86 4.1 滑鼠游標有問題。
以“對象－偏差”的方式描述有助於更仔細地組織關於這問題的思考，這影響了什麼？僅只滑鼠游標或是其他圖形介面也有問題？只在 XFree86 出現嗎？只有 4.1 版有問題嗎？是某牌顯示晶片組的問題呢？或是只有 MV1005 型號晶片組有問題？一個高手只消看一眼便知是你的問題或是你確實遭遇到問題。
此外，想像一下其他有同樣問題的人，在只有主旨的列表中尋找時，使你的主旨充分對應到內文，可使下一個尋找問題解答的使用者容易找到與他類似的問題，以便從你的討論串中得到答案，而不用另發新文。
如果你在一個回覆中再提出問題，請將主旨改成切合你的問題。一個類似“Re: 測試”或“Re: 新臭蟲”的主旨，往往不容易得到注意。此外，也要將與新問題不相關的引言刪減至最少。
不要在討論串中直接使用“回覆”來發新主題，因為有些郵件閱讀軟體（如 Mutt）可將同一討論串摺疊起來，如此將使你的訊息不容易被看到。
僅僅改變主旨還不夠，因為郵件軟體也許會以整個檔頭為基準來判斷是否為同一討論串，而不只是主旨。所以請改以“發新郵件”來張貼一個新的訊息吧。
在網頁論壇中，好的實踐方式可能稍有不同，因為訊息通常與整個討論串結合而不易為其他人所見。是否另開主題提問並不是重點（有些論壇甚至允許文章與回覆有不同的主旨，雖然說這樣做幾乎沒人會去看。），但若刻意在回覆中提問本身就令人質疑，因為這只有關心這串討論的人看得到。所以除非你希望只有正關心這串討論的人可以看到，不然還是另開主題吧。
想辦法讓問題容易回覆
請不要以「請回信給……」做結束，你會比較不容易得到答案。如果你連花幾秒鐘在你的郵件軟體中設置一個回信地址都懶，那他們可能也懶得花幾秒鐘回答你的問題。如果你的郵件軟體不支援這個功能，換一個吧；如果你的作業系統不支持堪用的郵件軟體，也換一個吧。
在網頁論壇中，要求私下回信是一整個無禮的，除非你確認事屬敏感（有些人為了某些未知原因，會只讓你知道而不會發布到整個論壇）。如果你希望有人回覆問題的時候以 E-mail 通知你，可要求論壇寄發通知郵件，幾乎所有論壇都支援這樣的功能。
用清晰、合乎文法與拼音的語言
根據經驗我們發現，那些拼字懶惰不小心的人通常也懶得思考（我敢打賭）。回答他們的問題是不值得的，我們寧願把時間花在其他任何事上。
所以清楚地表達你的問題是很重要的，如果你連這樣也覺得麻煩，那我們也覺得注意你的問題麻煩，所以多花點時間修飾你的語句吧。但不需要太僵硬與正式－－高手文化裡是很重視那些使用精準而非正式的俚語或幽默，但是必須使用精準，而且必須表明你還是有在思考與注意。
拼音、發音以及大小寫也要正確。別把“its”與“it's”、“loose”與“lose”以及“discrete”與“discreet”給搞混了，也不要用全部大寫來表達，這樣感覺你好像在無禮地大聲嚷嚷。（全部小寫只稍微好一點，但它依然不利閱讀。Alan Cox[註：著名的高手、Linux 核心的重要參與者。] 可以這樣，但你不行。）
此外，若寫得像個文盲傻子般，大概也不會有人理你，像個小孩塗鴉般也是在找死，保證除了一片死寂外不會有任何回應（或者只有一堆指責與挖苦）。
若你在非你母語的論壇中提問，對於你拼字與文法的錯誤可以得到些許寬容，但懶惰是不被允許的（是的，我們看得出其中差別。）。此外，若你不確定你的回應者使用何種語言，就請用英語。繁忙的高手會直接略過他看不懂語言的問題，而英語是網路上的工作語言，如此可將你被忽視的機率降到最低。
用容易瞭解的格式送出問題
如果你把你的問題搞得很難理解，它們就容易被忽略，畢竟人們喜歡閱讀簡單的文字，所以：
以純文字送出文章，而不要用 HTML（關閉 HTML 並不難）。
MIME（Multipurpose Internet Mail Extensions）附件通常是沒問題的，但必須附上有用的東西（例如原始碼或更新檔），而不僅只是你的郵件軟體產生的模板（相當於另一份訊息文件的拷貝）。
不要發送只有單一段落而必須不斷自動換行的訊息（這會使得要回覆部分內容變得困難），假設你的對象使用小於 80 字元行寬的文字終端機，在小於 80 字元的時候就先換行。
然而，也不要在固定欄寬的文件中任意換行（如紀錄檔），這些數據與樣式應該原封不動，這樣可以確保閱讀的人可以看到跟你一樣的內容。
在英文論壇中，不要以 'Quoted-Printable' MIME 編碼。這種編碼對於一些使用不在 ASCII 範圍內字元的語言是必須的，但有許多郵件軟體不支援，當它們斷行的時候，“=20”會到處出現在文件中，既難看又分散注意。
絕對，不要指望高手們會閱讀封閉格式的文件，諸如 Microsoft Word 或是 Excel 等。多數高手對這的反應，就像有人把熱呼呼的豬糞倒在你家門口時你的反應一樣。就算他們能夠處理，他們也不喜歡這麼做。
如果你是從 Windows 作業系統送出郵件，關掉微軟愚蠢的“聰明引用”功能，以免你的郵件中到處都是垃圾字元。
在網頁論壇中，不要濫用表情符號與 HTML 功能（如果有這些功能的話）。一兩個表情符號還可以，如果搞得太花俏，會讓人傾向認為你腦殘。真的，過度使用表情符號和彩色文字會使你看起來像個花痴，這不是個好主意，除非你對性比你要的答案更有興趣。
如果你是使用有圖形介面的郵件軟體（例如 Netscape Messenger 或是 MS Outlook 等類似軟體），注意它們的預設規則往往違反上述原則。但它們大多可以從選單中選擇“瀏覽原始碼”的功能，用這個來確認你送出的郵件沒有多餘字元的純文字文件。
描述你的問題須精準且提供足夠資訊
清楚且小心地描述你的問題。
描述發生問題的環境（機器配備、作業系統、應用程式等等），提供經銷商的發行與版本號（例如 Fedora Core 2、Slackware 9.1）。
描述你提問前已做過的研究與心得。
描述你提問前的診斷處理過程。
描述你最近電腦做的改變，像是安裝軟體、變更設定或各種相關可能。
盡可能預想高手們可能還會問什麼，並先準備好答案。
Simon Tatham 寫過一篇叫做“How to Report Bugs Effectively”的文章，我強烈建議你們閱讀。
寫得多不如寫得巧
你必須描述得精準且提供足夠資訊，而不只是無目的地在求助文章中加些無意義的文字。如果你有一個大而複雜的測試方法使得程式當掉，請盡量精簡你的敘述。
至少有三個理由支持此論點：第一，讓人看到你在努力簡化問題有助於你得到答案；第二，簡化問題可以使你得到更有用的回覆；第三，在重整這些錯誤紀錄的過程中，也許你會自己發現問題所在。
不要動輒宣稱你發現程式臭蟲
在使用軟體發生問題的時候，除非你非常確定，否則不要輕易宣稱發現了臭蟲。提示：除非你能做出修正檔來解決這問題，或是對先前的版本進行交叉測試以證明錯誤，否則你沒辦法完全確定。這就像如果有兩份文件，而其中一份有了錯誤，你應該可以指出錯誤並更正之。
記住，有許多的使用者沒有經歷過你所發生的問題，不然你應該可以在閱讀文件或搜尋的時候發現（你在發問前定有做過，對吧？）。這也代表了也許是你個人的問題，而非軟體。
軟體作者盡可能地使軟體正常工作且付出了心力，如果你大聲嚷嚷無疑是公開指責他做錯了，這會使人感到不快－－即使你是對的。尤其是在主旨就大叫“臭蟲！”，更顯得你很外行。
在你提問的時候，即使你私下真的認為發現了臭蟲，你還是要表現得好像是你自己做錯事一般。如果真的有蟲，你會在回覆中看到的。如果真的有錯，維護者定會向你道歉，總比你搞砸了然後欠人家一個道歉好。
低聲下氣不能代替你該做的事
有些人知道他們在求解答的時候沒有立場無禮傲慢，而相反地改以無敵低聲下氣的口氣陳述，如「我知道我是個悲慘低能的新手兼失敗者，但是……」，這是模糊焦點且沒有用的，尤其是如果又沒有好好好好說明你的問題時，更令人感到厭煩。
別用這種低能靈長動物的把戲來浪費你我的時間。相反地，要盡可能清楚說明你的背景與問題，這才是你該有的態度，而不是一味地卑躬屈膝。
有時候，網頁論壇會有特別的新手專區。如果你認為你的是新手問題，就到那邊去吧。但一樣不需低聲下氣。
描述問題的症狀，而不是你的臆測
告訴高手你認為問題出在哪是沒有用的（如果你那麼行，還需要問別人嗎？），所以要確認告訴他們問題的症狀，而不是你的解釋與理論，讓他們來解釋診斷就好。如果你覺得陳述你的猜測很重要，請清楚註明這是你的做法以及為什麼不起作用。
愚蠢的： 我在編譯核心的時候一直遇到 SIG11 錯誤，懷疑我的主機板電路絲有細微斷裂。有什麼好方法可以確認它們？
聰明的： 我自組的 K6/233 CPU、用 FIC-PA2007 主機板（VIA Apollo VP2 晶片組）、記憶體是 256MB Corsair PC133 SDRAM，在開機約 20 分鐘左右後，編譯核心時頻繁遇到 SIG11 錯誤，但在前 20 分鐘完全不會。重新啟動電腦時不會重啟時鐘，但整夜關機後再開就會。替換所有記憶體也沒用。相關的典型編譯紀錄如後。
依序列出你的問題症狀
在出問題前所發生的事情往往有指出錯誤最有幫助的線索。所以你應該精準描述在系統掛掉前，你和你的系統做了什麼事。使用命令列模式來產生紀錄並且適當引用關鍵的幾行會很有幫助。
如果會當掉的程式有診斷選項（例如 -v 參數），想辦法使用這些除錯選項來做紀錄。
如果你的紀錄很長（如超過四段），先簡單描述問題的發生點接著附上紀錄，這樣高手們就知道大概要注意哪些地方了。
描述目的而不是步驟
如果你是想知道如何達成某個目的（而不是回報臭蟲），請先描述你的目標，接著再說明過程中遇到什麼困難。
通常來尋求技術協助的人，心中都有一個比較高層次的目標，但他們一開始就想錯了，以致於讓過程變得非常複雜。
愚蠢的： 我要怎麼做才能在某程式中使用顏色選取器來取得十六進位的 RGB 值？
聰明的： 我正試著用我選定的顏色來取代圖片中的顏色表，我現在所知的方法是手動編輯每一個對照表內容，但卻無法讓某程式的顏色選取器取得十六進位的 RGB 值。
第二種方法是明智的，它使人容易想到該建議其他更好用的工具來達到目的。
不要請人私下回信
高手們認為問題的解決過程應該要透明公開，這樣若有更強的人能點出錯誤或不完善之處，一開始的解法才得以被修正。且他們的才能與知識也才會為同儕所知曉而得到某種形式的回報。
當你要求私下回覆的時候，以上的功能都將被干擾，所以別這麼做。是否需要私下回覆，取決於回覆者的決定－－而如果他這麼做，通常表示他認為問題太差或答案很明顯，以至於引不起他人的興趣。
但這項限制有個例外，就是當你覺得這個問題可能引來太多類似的答案時，你可以使用這麼個神奇的句子：「回信給我，我將為小組統整答案。」這樣就很客氣地為郵件列表或是新聞群組省掉如洪水般千篇一律的答案－－但你得記得遵守諾言。
搞清楚你要問的是什麼
一個無邊際的開放問題就像一個無邊際的時間漩渦般。通常最有能力給你回答的人同時也是最忙碌的人（假設只是因為他們本身承擔太多工作），而他們對這種漫無邊際的閒聊也是最敏感的，因而他們也討厭這種類型的問題。
當你清楚瞭解你希望回覆者回答什麼時，通常你也能得到最有用的答案（提出問題點、提供原始碼或是檢查更新檔等等）。這有助於他們集中精神，並且暗中間接設定了對這問題所需付出的時間精力上限。這樣很好。
要了解專家的世界，你可以這麼想：他們有很豐沛的專業技術，但卻很少有時間。你委託他付出的時間越少，就越有可能從他那邊得到幫助。
所以使你的問題結構化以使專家所需花的時間減到最低是有幫助的－－但這又跟簡化問題是兩碼子事了。例如“你能對 X 提出個好解釋嗎？”通常要比“能請你解釋一下 X 嗎？”要來得聰明。如果你有程式跑不動，請人解釋一下為什麼不能跑要比請人家來修正他要來得好。
不要把你的作業拿來提問
高手們很容易就可以辨別出哪些問題是作業。我們的作業大多數都是靠我們自己完成的，而你的作業則是你自己該做的，所以你應該要從經驗中學。要求點提示是可以的，但別要整個解法。
如果你的問題看起來真的很像作業，但也真的解決不了，那就試試看到使用者群組論壇（作為最終手段）或專案的使用者郵件列表與論壇去發問。雖然高手們還是看得出來，但一些進階使用者至少會給你點提示。
省去不得要領的請求
抗拒在問題結尾加上諸如“有人能幫我嗎？”或“有答案嗎？”等語意空洞句子的誘惑。首先，如果你的問題描述得不完整，這些附加上去的問題是多餘的。第二，因為它們是多餘的，高手們會覺得這很煩－－他們可能給你一個邏輯上沒有錯，但卻擺明了輕視你的答案，像是“是的，你可以獲得幫助。”或是“不，沒人幫得了你。”
一般來說，最好能避免提出是與否的問題，除非你只要簡單的是與否答案。
不要標明問題緊急，即使真的是這樣
這是你的問題，不是我們的，宣稱緊急的話往往會得到反效果。多數高手可能直接就刪了這樣的訊息，因為這是無禮且自私地想引起注意的做法。
有一種勉強算是例外的情況，如果你是在某些高手們會覺得刺激的特殊點使用程式，那就值得提醒一下。如果你委婉地說明你真的有時間壓力，他們可能會有興趣快點回答。
但這是個有風險的做法，因為你覺得有趣的東西他們不見得有興趣。例如在國際空間站上貼文是沒問題的，但是如果基於慈善或政治等理由貼文，可能就會不妥。事實上，張貼像是“緊急：幫我救救這毛絨絨的小海豹！”可以肯定高手會走避甚至感到光火，即使他們覺得毛絨絨的小海豹很重要。
如果你感到不可思議，建議你把剩下的內容多讀幾遍，在你搞懂之前最好不要貿然發文。
禮多人不怪，有些時候還很有幫助
客氣地使用“請”、“謝謝你的注意”或“謝謝你的考量”等等，可以清楚表達你對這些無償幫助你的人的感謝之意。
老實說，這點不比之前提的其他要點，諸如文法語意精準明確來得重要，更不能取代它們。但高手們一般寧願閱讀唐突但技術性夠的臭蟲報告，也不願看一份充滿禮貌但很含糊的報告（如果這讓你迷惑，請記得我們是以一個問題能教我們多少來給予價值的。）。
然而，如果你的技術問題已經談得夠完善，多點禮貌會增加你得到有用幫助的機會。
（一定要提一下，我們這份文件唯一受到老手嚴正反對的部分，是關於我們先前建議大家大家使用“先謝了”來表達感激。有些人認為這一方面也暗示了之後就不必再謝任何人的意思。我們現在建議大家先說“先謝了”，得到回應後再感謝一次，或是換個形式說“謝謝你的注意”或“謝謝你的考量”。）
問題解決後簡短說明一下
在問題得到解決後，留個訊息讓曾經幫過你的人知道最後是如何解決的，並再度表示感謝之意。如果這問題在郵件列表或新聞群組中受到廣泛關注，那麼在那邊回文會更加適合。
最理想的方式是在討論串的第一篇或是主旨等明顯地方加上“已修復”或“已解決”，這樣一些潛在的回覆者就明白他們不用再浪費時間來解決了，而可以轉向解決其他問題，除非他對這個議題很有興趣。
你的回文不需要太長，一句簡單的“嘿…是網路線壞了！謝謝大家。－比爾上”就比什麼都不說還要好。事實上，一個簡明貼心的回覆要比長篇大論來得好，除非解決方法真的很有技術深度。你可以提一下解決問題的關鍵步驟，但不需要替你的整個疑難排解過程提出冗長的說明。
對於有深度的問題，則適合提一下解決的步驟要點。說明問題的最終狀態，以及是如何解決的，以及日後可避免的瞎子摸象過程，而這部分等你講完正確解答後再提就好，這樣比把你的討論串搞得跟偵探小說一樣來得好。列出那些曾幫助過你的人，這也是個交朋友的方法。
除了要客氣有禮並提供足夠資訊外，這類型的回文也有助於搜尋或保存這個郵件列表、新聞群組或網頁論壇討論串，讓其他人確實知道該怎麼解決，以及這如何幫到他們。
至少，這樣的整理使得參與解題過程的產生一種解決問題的滿足感。如果你本身不是技術人員或高手，相信我們，這種感覺對你尋求幫助的專家老手是很重要的。問題到最後無疾而終是會讓人挫折的。他們巴望著看到問題被解決，而你可以適時告知的話，對於你下次提問也會有幫助的。
考慮一下是否可以避免以後的人遇到類似的問題，你可以問自己，編一份文件或是 FAQ 修正是否會有幫助？如果是的話就做一份，並幫維護者更新他們的文件。
在高手中，這樣的動作要比傳統上所謂的禮貌要來得有用多了。這也是你善待別人並贏取威望的方式，將會成為一個無價的資產。
如何解讀回答
RTFM 與 STFW：如何知道你已經搞砸了
有個古老而神聖的傳統，當你得到一個“RTFM”的回覆時，他的意思是叫你去看說明書吧。他幾乎是沒錯的，去看一下吧。
“RTFM”有個小親戚叫做“STFW”，當你收到這個回覆的時候，他的意思是叫你先找找網路吧。同樣地他也應該沒錯，所以搜尋一下吧。別忘了 Google 是你的好朋友。
在網站論壇中，你也可能被要求先找找精華區。事實上，也可能有好心人直接跟你點出舊文章中的哪裡有提到這問題的解答。但別太依賴這個，你還是應該在提問前就先搜尋。
通常，會叫你去看說明書或搜尋網路的人，他本身也正一邊看著一邊回覆你。而他這樣講表示他認為：1. 這個答案太容易找了。2. 你自己去找的話可以學得更多，而不是只是要人家餵你答案。
你不應該因為這樣而感到不快，在高手眼中，沒有忽視你就是表示了某種初步的尊敬了。你應該轉而感謝他熱切的好意。
如果你還是不懂…
如果你對答案有疑惑，不應貿然馬上要求對方說清楚講明白。用你之前曾用過的工具（說明書、FAQs、網路以及內行的朋友）試著瞭解答案。如果還是需要說明，先表示一下你有學到了什麼。
舉個例子，如果我告訴你：「這聽起來像是 zentry 的問題，你應該先清除它。」此時“啥是 zentry？”是個爛回文；而“是的，我看了說明書，裡面只提到了 -z 與 -p 參數，但沒提到如何清除它。你指的是哪一個？或是我漏了什麼嗎？”則顯得聰明。
面對無禮的情況
高手圈中的某些看似無禮的行為有時並非確實如此。相反地，這是一種直接、一針見血的溝通方式。因為他們更關注於解決問題，而不是要使人感到舒服或迷惑。
若你感受到無禮，試著冷靜回應。如果他真的太過分了，郵件列表或論壇中的前輩自然會出來料理他。如果你失控了而卻沒人出來指責對方，表示這樣的言語在高手圈中合乎標準，而你會被視為錯的一方，這會影響到你得到答案的機會。
另一方面，有時候你會沒來由地遇到這樣的情況。與上述相反地，你可以用犀利的言辭攻擊莽撞的冒犯者，但行事前你必須非常確認你的立場。糾正無禮與掀起一場無意義的筆戰僅一線之隔，高手越界的情況也不少見。如果你是個新手或外來者，避開這種莽撞的機會並不高，如果你想要的是答案而不是娛樂，最好把你的手移開鍵盤，別冒這個險。
（有人認為許多高手的人格特質傾向孤獨，或是自閉症與亞斯伯格症候群，他們的腦神經缺乏與普通人進行社交的潤滑。這未有定論，但若你本身不是高手，如果你認為我們腦袋有問題，這有助於你應付我們古怪的行徑。儘管這麼做吧，我們不會在意的，不管如何我們還是我們，且對這些臨床診斷多抱持著懷疑的態度。）
在下一單元，我們會談談不同的問題，談你行為不當時會受到的“冒犯”。
別反應得像個失敗者一樣
在高手交流論壇中，你偶而會搞砸那麼幾次－－像本文這樣細數你的罪狀或什麼的。你會被慘電你是如何搞砸的、在公開場合，甚至還帶點其他意思。
發生這種情況時，最糟糕的莫過於發牢騷、嚷著你被言辭攻擊、要求道歉、大吵大鬧、生悶氣、威脅訴諸法律、向他們的雇主抱怨或是忘了蓋馬桶蓋等等。相反地，你應該做做下面的事：
熬過去，這是正常的。事實上，這是有益健康且恰當的。
一個社群運作的標準，是由其中積極實踐的人們，以公開可見的方法來維持的。不要抱怨說所有批評都該透過私人郵件傳送，這不是該有的運作方式。當有人指責你錯或是與你看法不同的時候，堅持你被針對是沒有用的，那是失敗者的態度。
曾有一些高手論壇，因為道德標準過高，禁止回文挑人毛病，他們認為如果你不願幫忙，“只管什麼都不要說”。但結果導致有能力的參與者離開，最後論壇上只有無意義而含糊的言論，而不再配稱為技術論壇。
你想要極度的友善還是有用的資訊？挑一個吧！
記得，當一個高手告訴你：“你搞砸啦，（無論多麼刺耳）以後別再這麼做。”他的行為是在關心你，以及他的社群。他要略過你的訊息，或是將你從他的生命中過濾掉，都比回文要容易多了。如果你還是不能釋懷，至少有點尊嚴，別發牢騷。也別以為你是個有著敏感靈魂的新手，別人就該像對待易碎的娃娃般小心對你。
有時候人們會無緣無故指責你，即便你沒有搞砸（只是別人想像你搞砸），這時抱怨的話，就是真的搞砸了。
這些筆戰魔人要不是自以為是專家的無能者，就是來測試你會否搞砸的心理學家。其他人或許不會鳥他，或許會用自己的方式來對付他們。他們只是在給自己找麻煩，你可以不用理他們。
也別讓自己掉進筆戰漩渦中，最好是忽視他們－－在你確認這是筆戰，既沒有指出你搞砸的地方，也沒有在其中暗藏答案時（這也是有可能的）。
提問禁忌
這邊有一些經典的蠢問題，以及當高手們不打算回答的時候，他們的考量是什麼。
Ｑ：在哪兒可找到 X 程式或其資源？
Ａ：就在我找到的那個地方啊，笨蛋－－在搜尋引擎上。天啊，難道不是所有人都知道怎麼用 Google 嗎？
Ｑ：我該怎麼用 X 工具來達成 Y 目的？
Ａ：如果你想做 Y，提問時就別預設不恰當的 X。會提這種問題通常表示這人對 X 很外行，對要解決的問題在某些情況下也轉不過腦筋。一般來說在這種人釐清問題之前最好先不要理他。
Ｑ：我該怎麼設定介面提示？
Ａ：如果你聰明到知道要來這問問題，應該也聰明到自己去翻他媽的說明書吧。
Ｑ：我能用 Bass-o-matic 檔案轉換程式把 AcmeCorp 文件轉成 TeX 檔案嗎？
Ａ：試試看不就知道了？如果可以，你就知道答案了，也不用浪費我的時間了。
Ｑ：我的{程式、設定、SQL 敘述}沒辦法運作？
Ａ：這不是個問題，我也沒興趣猜你的問題－－我還有更重要的事要做。一般當我看到這種問題，我的反應如下：
還有要補充的嗎？
真慘，希望你修得好。
這到底跟我有啥關係？
Ｑ：我的 Windows 電腦有問題，有人能幫嗎？
Ａ：是的，丟掉垃圾微軟，改用開放原始碼的作業系統，像是 Linux 或 BSD 等等。
注意：如果這是個有官方 Windows 版或是與 Windows 互動的程式（如：Samba），你可以問有關 Windows 電腦的問題。如果回報錯誤的是 Windows 而不是軟體本身，你也不用太驚訝，Windows 本身就是個破爛，常常會出狀況。
Ｑ：我的程式不會跑，我想是系統配備 X 壞了？
Ａ：你有可能是成千上萬使用者中第一個發現這個系統調用與函式庫明顯出錯的人，但更可能你根本完全沒有根據。不同凡響的說法也得有不同凡響的證據，當你在這邊發出聲明的時候，你必須有清楚且徹底的文件來說明這件事。
Ｑ：我安裝 Linux 或 X 的時候有問題，有人能幫嗎？
Ａ：沒辦法，我得親手操作你的電腦才能解決。去找你當地的 Linux 使用者群組親自幫你吧。（你可以在這裡找到。）
注意：若你在該發布版本的郵件列表或是本地使用者群組論壇中提問也許是適當的，但仍要確定精準描述問題的細節，也要先仔細搜尋“linux”與相關的關鍵字。
Ｑ：我要怎麼破解系統管理員的密碼 / 盜取頻道操作權限 / 閱讀某人的 E-mail？
Ａ：想做這事證明你是個卑劣的人，來這請高手幫你證明你是個低能兒。
好問題與爛問題
最後，我想用例子示範一些聰明的問法，並分別列出相同問題的不同問法。
愚蠢：在哪可以找到關於 Foonly Flurbamatic 的東西？
（這種問題只會得到“去搜尋網路啦”式的回答。）
聰明：我用 Google 想找 Foonly Flurbamatic 2600，但沒有有用的資訊。有人知道哪邊可以找到在這機器上設計程式的資訊嗎？
（這人已經找過網路了，也許他真的有問題。）
愚蠢：我不能編譯某程式的原始碼，為什麼這麼爛？
（他假設都是別人搞砸的，真自大。）
聰明：某程式在 Nulix 6.2 版下的原始碼不能編譯，我已經看過 FAQ，但是找不到跟 Nulix 有關的問題，這邊有我的編譯訊息，我該怎麼做？
（他點出了運行環境、也讀了 FAQ、也提出錯誤訊息、也沒假設是別人的錯，這傢伙值得注意。）
愚蠢：我的主機板有問題，誰能幫我？
（某高手可能這樣回答：「是的，還需要幫你拍背或換尿布嗎？」隨即按下刪除鍵。）
聰明：我在 S2464 主機板上試了 X、Y 和 Z 等方法，但沒用。又試了 A、B 和 C，注意我試 C 時的奇怪症狀，明顯地有在進行什麼動作，但是結果還是不正確。通常 Athlon MP 主機板上可能造成這個的原因是什麼？有人可以提供點意見，我還可以做什麼測試來確定問題嗎？
（這個人才值得回答。他展現了解決問題的天份，而不只是等著答案從天上掉下來。）
在最後一個問題中，注意“給我個答案”與“請幫我看看還有什麼額外測試可以用來得到點啟發”之間的微妙差異。
事實上，最後一個問題是 2001 年八月發生在 linux-kernel mailing list（lkml）上的真實事件。當時我（Eric）是問問題的那一個，我發現了 Tyan S2462 上神秘的當機現象，列表成員提供了我解決問題的重要訊息。
用我的方法提問，也給了人們思考的空間，我把問題簡化並吸引他們一起來解決，我對同儕們的能力表現了尊敬並且邀請他們一起來解決，也告訴他們我走過的死路藉以表示對他們時間的珍惜。
事後，我向大家致謝並提及這個很棒的工作經驗，其中一位成員認為我的成功並不是因為我的名字在列表中，而是因為我用了適當的形式提問。
高手在某些方面是很無情的精英分子，我想這是對的。如果我表現得像個寄生蟲，可能會引發筆戰或被忽略。他建議我把整件事寫成指引，也直接地促成了這份指南。
若沒有得到答案
如果沒有得到答案，請不要擅自認為沒人想幫你。有時候只是大家不知道答案，沒回應不代表被忽略，雖然這從外觀很難分辨。
一般來說，單純重貼一次問題並不是個好主意，會被視為無意義的吵鬧。
還有其他資源可以求助，通常在一些貼近新手需求的資源中。
有很多對軟體熱心的線上或本地使用者群組，雖然他們自己不寫任何軟體，但群組內的人通常會互助或幫助新手。
還有很多中小型商業公司可供你求助（Red Hat 和 Linuxcare 是其中知名的兩個，還有許多其他的。）。別因為要付點錢才有支援而感到心慌。不管如何，你的汽車引擎襯墊掛了一樣得花錢送修。軟體已經不花你錢了，不能連服務也免費吧。
像 Linux 這樣受歡迎的軟體，平均每個研發者至少都有一萬個使用者，他們不可能處理所有的問題。即便你花了錢買服務，還是比連軟體都買的費用便宜多了（封閉軟體的支援費用通常貴多了，也不比開放軟體好。）。
如何提出有助益的回答
態度溫和點。發生問題的人看起來可能無禮或愚蠢，但並不一定如此。
給初犯者私下回覆。對坦承犯錯的人沒必要公開給予羞辱，一個新手可能連要怎麼找精華區或是 FAQ 都不懂。
如果你不確定，要講出來。一個看似很專業的錯誤，可能比沒人回覆還糟糕。也不要因為好玩而用看似專業的口氣指點錯誤的方法。要謙遜且誠實，給提問者和同儕樹立一個好榜樣。
如果你幫不上忙，別妨礙。不要在步驟中開玩笑，那可能會毀了別人的安裝－－有些可憐的呆子可能會信以為真。
提出試探性的問題以引出更多細節。如果你擅長這樣，提問者可以學到些東西－－也許你也可以。試著將爛問題轉變為好問題，別忘了我們都曾是新手。
抱怨那些懶蟲，叫他們去看說明書或找網路是正當的。如果可以指出在文件的哪裡（即便只是建議搜尋的關鍵字）會更好。
如果你要給答案，就給個好答案。當某人用了錯誤的工具或方法，別給笨拙的權宜之計。建議好的工具並重新組織問題。
幫助你的社群從問題中學習。當你回答問題時，一邊想著“要怎麼改進這份文件或 FAQ，以避免相關問題再出現。”然後向文件的維護者發一份更新。
如果你是做了研究來回答這個問題，表現一下你的技巧而不只是端出答案來。畢竟“授人以魚，不如授之以漁”。
相關資源
如果你需要個人電腦、Unix 以及網路工作的基礎指導，請看 The Unix and Internet Fundamentals HOWTO。
當你發布軟體或軟體更新，請看 Software Release Practice HOWTO。
鳴謝
Evelyn Mitchell 提供了一些蠢問題範例，並給了“如何提出有助益的回答”撰寫靈感。Mikhail Ramendik 提供了參考改進的重要建議。
Last updated