今天終於懂得了如何提問.這對於我一個剛剛踏進軟件開發行業的新手來說,是極爲寶貴的經驗,在這裏我要感謝子孑.他的話猶如當頭棒喝,讓我受益不少,年輕人難免浮躁,遇到問題更是着急,不知所措.缺乏獨立思考.很多時候都在網上找尋答案,然而,找到的答案有對有錯.無從去判斷.這時盲目的我會不斷的去試,一遍一遍,這樣無疑浪費了很多的時間,所以直到前幾天看到了51cto,我才找到了我想要的.在這裏我忠心的感謝那些幫助過我的人.在此,貼上提問的智慧這篇文章來時時提醒自己.希望以後的日子裏在這裏能學到更多的東西.
提問的智慧
作者：
提問的智慧
作者：引言
在 *** 的世界，你所提技術問題的回答很大程度上取決於你提問的方式與解決此問題的難度，本文將教你如何提問才更有可能得到滿意的答覆。
開源程序的使用已經很廣，你通常可以從其它更有經驗的用戶而不是***那裏得到回答。這是好事，他們一般對新手常有的毛病更容忍一點。然爾，使用我們 介 紹的方法象對待***那樣對待這些有經驗的用戶，通常能最有效地得到問題的解答。
第一件需要明白的事是***喜歡難題和激發思考的好問題。假如不是這樣，我們也不會寫本文了。如果你能提出一個有趣的問題讓我們咀嚼玩味，我們會感激 你。 好的 問題是種激勵與禮物，幫助我們發展認知，揭示沒有注意或想過的問題。在***中，“好問題！”是非常真摯的讚許。
除此而外，***有遇到簡單問題就表現出敵視或傲慢的名聲，有時候我們看起來還對新手和愚蠢的傢伙有條件反 射式的無禮，但並不真正是這樣。
我們只是毫無歉意地敵視那些提問前 不願思考、不做自己該做之事的人。這種人就象時間無底洞──他們只知道獲取，不願意付出，他們浪費了時間，這些時間本可用於其它更值得回答的人和 更有趣 的問題。我們將這種人叫做“失敗者 (loser)” (由於歷史原因，我們有時將“loser”拼爲“lusers")
我們注意到許多人只想用我們寫的軟件，他們對學習技術細節沒有興趣。對大多數人而言，計算機只是種工具，是種達到目的的手段。他們要生活並且有更要 緊的事要做，我們承認這點，也從不指望每個人都對這些讓我們着迷的技術問題感興趣。不過，我們回答問題的風格是爲了適應那些真正對此有興趣並願意主動參與 問題解決的 人，這一點不會變，也不該變。如果這都變了，我們就會在自己能做得最好的事情上不再那麼犀利。
我們(多數)是自願者，從自己繁忙的生活中抽時間來回答問題，有時會力不從心。因此，我們會無情地濾除問題，特別是那些看起來象是失敗者的，以 便更有效地把回答問題的時間留給那些“勝利者”
如果你認爲這種態度 令人憎惡、以施惠者自居或傲慢自大，請檢查你的假設，我們並未要求你屈服──事實上，假如你做了該做的努力使之成爲可能，我們中的 大多數人非常樂意平等地與你交流並歡迎你接納我們的文化。試圖去幫助那些不願自救的人對我們簡直沒有效率，不懂沒有關係，但愚蠢地行事不行。
所以，你不必在技術上很在行才能吸引我們的注意，但你必須表現出能引導你在行的姿態──機 敏、思考、善於觀察、樂於主動參與問題的解決。如果你 做不到這些使你與衆不同的事情，我們建議你付錢跟別人籤商業服務合同，而不是要求***無償幫助。
如果你決定向我們求助，你不會想成爲一名失敗者，你也不想被看成一個失敗者。得到快速有效回覆的最好方法是使提問者看起來象個聰明、自 信的人，並且暗示只是碰巧在某一特別問題上需要幫助。
(歡迎對本文指正，可以將建議發至 [email][email protected][/email] 。 請注意，本文不想成爲一般性的 網絡禮儀 指南，我一般會拒絕那些與引出技術論壇中有用的回覆不特別相關的建議)
在通過電子郵件、新聞組或網頁論壇提技術問題之前，做以下事情：
-
嘗試搜索互聯網以找到答案
-
嘗試閱讀手冊以找到答案
-
嘗試閱讀FAQ(常見問題)文檔以找到答案
-
嘗試自己檢查或試驗以 找到答案
-
嘗試請教懂行的朋友以找到答案
-
如果你是程序員，嘗試閱讀源代碼以找到答案
提問時，請先表述你已經做了上述事情，這將有助於建立你不是寄生蟲與浪費別人時間的印象。最好再表述你從中學到的東西，我們喜歡 回答那些表現出能從答案中學習的人。
使用某些策略，比如用Google搜索你遇到的錯誤提示(既搜索網頁也查查討論組)，可能就直接找到了解決問題的文檔或郵件列表線索。即使沒有結 果，在電子郵件或新聞組張貼問題時提一句“我在Google中查過下列句子但沒有找到什麼有用的東西”也是件好事。
準備你的問題，徹底地思考。輕率的提問只能得到輕率的回答，或者壓根沒有。在提問時，越是表現出做過思考並在努力解 決問題，你越有可能得到 實際幫助。
注意別提錯問題。如果提問基於錯誤的假設，某***多半會一邊想”愚蠢的問題……“，一邊用按照問題字面的無用答案回覆你，並且希望這種只 是得到 字 面回答而不是真正所需的經歷給你一個教訓。
永遠不要假設你有資格得 到解答。你沒有這種資格，畢竟你沒有爲此服務付費。如果你能夠提出有內容、有趣和激勵思考的問題──那種毫無疑問能夠向社 區貢獻經驗而不僅僅是消極地要求從別人那獲取知識的問題，你將“掙到”答案。
另一方面，表明你能夠也樂意參與問題的解決是個很好的開端。“有沒有 人能指個方向？”、“我這還漏點什麼？”、“我應該查哪些網站？”通常要比 “請給出我可以用的完整步驟”更容易得到回覆，因爲你表明了只要有人能指個方向你就很樂意完成剩下的過程。
要對在哪提問留心，如果你做了下 述事情，多半會被一筆勾銷或被看成“失敗者”：
-
張貼與論壇主題完全無關的問題
-
在面向高級技術問題的論壇上提非常 初淺的問題，或者反之。
-
在太多不同的新聞組同時交叉張貼
-
給既非熟人也沒有義務解決你問題的個人張貼你私人的電子郵件
爲保護通信的渠道不被無 關的東西淹沒，***會除掉那些沒有找對地方的問題，你不會想有這種經歷的。
所以第一步是找對論壇，Google與其它搜索引擎還是你的朋友，可以用它們搜索與你遇到困難的軟硬件問題最相關的項目的網站。那 裏通常都有項目的FAQ列表、郵件列表及其文檔的鏈接。如果你的努力(包括閱讀FAQ)都沒有結果，這些郵件列表就是最後能取得幫助 的地方。項目的網站也許還有報告臭蟲的流程或鏈接，如果是這樣，去看看。
向陌生的人或論壇發送郵件極有可能是在冒險。譬如，不要假設一個富含信息的網頁的編寫者想充當你的免費顧問，不要對你 的問題是否會受到歡迎做樂 觀的 估計──如果你 不確定，向別處發或者根本別發。
在選擇網頁論壇、新聞組或郵件列表時，不要太相信名字，先看看FAQ或者許可書以明確你的問題 是否與其主題相關。張貼前先翻翻已有的帖 子可 以 幫助你感受一下那裏行事的方式。事實上，張貼之前在新聞組或郵件列表中搜索與你問題相關的關鍵詞是個很好的主意，也許就找到答案了。即使沒有，也能幫助你 整理 出 更好的問題。
別象機關槍似的一次性“掃射”所有的幫助通 道，那就象大嚷大叫並使人不快。一個一個地來。
弄清楚你的主題！最典型的錯誤之一是在某種致立於跨Unix和Windows平臺的語言、庫或工具的論壇中提關於操作系統程序接口的問題。如果你不 明白爲什麼這是大錯，最好在搞清楚概念前什麼也別問。
一般來說，在仔細挑選的公共論壇中提問比在私有論壇中提同樣的問題更容易得到有用的回覆。有許多理由支持這一點，一是看潛在的回覆者有多少，二是看 論 壇的參與者有多少，***更願回答能啓發多數人的問題。
可以理解，老練的***和一些流行軟件的作者正在收到超出他們承受能力的不當消息。就象那根多出來就可以壓垮駱駝背的稻草一樣，你的 加入也可能會使情況走向極端──已經好幾次了，一些流行軟件的作者退出了對其軟件的支持，因爲伴隨而來的涌向其私人郵箱的大量無用消息變得無法 忍受。
本地的用戶組織或者你所用的Linux發行版也許正在宣傳新手取得幫助的網頁論壇或IRC(互聯網中繼聊天) (在非英語國家，新手論壇很可能還是郵件列表)，這些 地 方 是開始提問的好去處，尤其是當你覺得遇到的也許只是相對簡單或者一般的問題時。經過宣傳的IRC通道是個公開邀請提問的地方，通常可以得到實時的回覆。
事實上，如果出問題的程序來自某發行版(這很常見)，在程序的項目論壇或列表提問前最好先在發行版的論壇或列表中問問，(否則)項目的***可能僅僅 回覆“用我們的代碼”
在任何網頁論壇張貼之前，先看看是否有搜索功能。如果有，就試試用問題的幾個關鍵詞搜索一下，也許就有幫助。如果在此之前你已做過全面的網頁搜索 (你應該這樣做)，還是再搜索一下論壇，搜索引擎最近也許還沒有索引此論壇的全部內容。
通過網頁論壇或IRC頻道提供項目的用戶支持有增長的趨勢，電子郵件交流則更多地爲項目開發保留。先在網頁論壇或IRC中尋求與項目相關的幫 助。
當某項目存在開發者郵件列表時，即使你確信誰能最好地回答問題，也要向列表而不是其中的個體提問。檢查項目的文檔和主頁，找到項目的郵件列表並使 用它。採用這種策略有幾個好理由：
-
任何向單個開發者提的足夠好的問題也將對整個項目組有益。相反，如果你認爲自己的問題對整個項目組來說太愚蠢，這也不能成爲打擾 單個開發者的理由。
-
向列表提問可以平衡開發者的負擔，單個開發者(特別是項目領導)也許太忙以至於無法回答你的問題。
-
大多數郵件列表有歷史文檔並被搜索引擎索引，其它人可以通過網頁搜索找到你的問題和答案而不用再次在郵件列表中發問。
-
如果某些問題經常被問到，開發者可以利用此信息改進文檔或軟件本身以使其更清楚。如果只是私下提問，就沒有人能看到最常見問題的完整 場景。
如果一個項目既有“用戶”也有“開發者”(或“***”)郵件列表或網頁論壇，而你又不擺弄那些代碼，向“用戶”列表或論壇提問。不要假設自己在開發 者列表中會受歡 迎，那些人多半會遭受你的噪音干擾。
然爾，如果你確信你的問題不一般，而且在“用戶” 列表或論壇中幾天都沒有回覆，可以試試“開發者”列表或論壇。建議你在張貼前最好先暗暗地觀察幾天 以瞭解那的行事方式(事實上這是參與任何私有或半私有列表的好主意)
如果你找不到一個項目的郵件列表，而只能查到項目維護者的地址，只管向其發信。即便在這種情況下，也別假設(項目)郵件列表不存在。在你的電子郵 件中陳述你已 經試過但沒有找到合適的郵件列表，也提及你不反對將自己的郵件轉發給他人(許多人認爲，即使沒什麼祕密，私人電子郵件也不應該被公開。通過允許將你的電子 郵件 轉 發他人給 了相應人員處置你郵件的選擇)。
在郵件列表、新聞組或網頁論壇中，主題是你在五十個或更少的字符以內吸引有資格的專家注意的黃金機會，不要用諸如“請幫我”(更別提大寫的“請幫 我！！！！”，這種主題的消息會被條件反射式地刪掉)之類的嘮叨浪費機會。不要用你痛苦的深度來打動我們，相反，要在這點空間中使用超級簡明扼要的問題 描述。
使用主題的好慣例是“對象──偏差”(式的描述)，許多技術支持組織就是這樣做的。在“對象”部分指明是哪一個或哪一組東西有問題，在“偏差”部分 則描述與期望 行 爲不一致的地方。
愚蠢：
-
救命啊！我的筆記本視頻工作不正常！
明智：
-
XFree86 4.1扭曲鼠標光標，某顯卡MV1005型號的芯片組
更明智：
-
使用某顯卡MV1005型號芯片組的XFree86 4.1的鼠標光標被扭曲
編寫“對象──偏差”式描述的過程有助於你更具體地組織你的問題。是什麼被影響了？僅僅是鼠標光標或者還有其它圖形？只在XFree86中出現？或 只是在其4.1版中？是針對某顯卡？或者只是其MV1005型號的芯片組？一個***只需描一眼就能夠立即明白什麼是你遇到的問題，什麼是你自己的問題。
更一般地，想象一下在只顯示主題的文檔索引中查找。讓你的主題更好地反映問題，可以使下一個搜索類似問題的人能夠在文檔中直接找到答案的線索而不用 再次張貼提問。
如果你想在回覆中提問，確保改變主題以表明你是在問一個問題，一個主題象“re: 測試”或“re: 新臭蟲”的消息不太可能引起足夠的注意。同 時，將回復中與新主題不甚相關的引用內容儘量刪除
對於列表消息，不要直接點擊回覆(按鈕)來開始一個新的線索，這將限制你的觀衆。有些郵件閱讀程序，比如mutt，允許用戶按線索排序並通過摺疊線 索來隱藏消息， 這樣做的人永遠看不到你發的消息。
僅僅改變主題還不夠。mutt和其它郵件閱讀程序還要檢查主題以外的其它郵件頭信息，以便爲其指定線索，所以寧可發一 個全 新的郵件。
在網頁論壇，因爲消息與特定的線索緊密結合並且通常在線索之外不可見，好的提問方式略有不同，通過回覆提問並不要緊(一些論壇甚至不允許在 回覆中出現分離的主題，而且這樣做了基本上沒有人會去看)。不過通過回覆提問本身就是令人懷疑的做法，因爲它們只會被正在查看該 線索的人讀到。所以，除非你只想在該線索當前活躍的人羣中提問，還是另起爐竈比較好。
以“請向……回覆”來結束問題多半會使你得不到回答。如果你覺得花幾秒鐘在郵件客戶端設置一下回復地址都麻煩，我們也覺得花幾秒鐘 考慮你的問題更麻煩。如果你的郵件客戶端程序不支持這樣做，換個好點的。如果是操作系統不支持所有這種郵件客戶端程序，也換個好點的。
在網頁論壇，要求通過電子郵件回覆是完全無禮的，除非你確信回覆的信息也許是機密的(而且有人會爲了某種未知的原因只讓你而不是整個論壇知道答 案)。如果 你只是想 在有人回覆線索時得到電子郵件提醒，可以要求論壇發送。幾乎所有論壇都提供諸如“留意本線索”、“有回覆發送郵件”的功能。
經驗告訴我們，粗心與草率的作者通常也粗心與草率地思考和編程(我敢打賭)。爲這些粗心與草率的思考者回答問題沒有什麼好處，我們寧可將 時間花在其它地方。
清楚、完整地表達你的問題非常重要。如果你覺得這樣做麻煩，我們也覺得注意(你的問題)麻煩。花點額外的精力斟酌一下字句，用不着太僵硬與正式──事實 上，***文化很看重能準確地使用非正式、俚語和幽默的語句。但它必須很準確，而且有跡象表明你是在思考和關 注問題。
正確地拼寫、使用標點和大小寫，不要將“its”混淆爲“it's”，“loose”搞成“lose”或者將“discrete”弄成 “discreet”。不要全部用大寫，這會被看成無禮的大聲嚷嚷 (全部小寫也好不到哪去，因爲不易閱讀。Alan Cox[注：著名***，Linux內核的重要參與者]也許可以這樣做，但你不行 )。
一般而言，如果你寫得象個半文盲似的傻子，多半得不到理睬。如果象個小孩似地亂寫亂畫那絕對是在找死，可以肯定沒人會理你(或者最多 是給你一大堆指責與挖苦)。
如果在非母語論壇中提問，你的拼寫與語法錯誤會得到有限的寬容，但懶惰完全不會被容忍(是的，我們通常看得出其中的差別)。同時，除非你知道回覆者 使用 的語言，請使用 英語書寫。繁忙的***一般會直接刪除用他們看不懂語言寫的消息。在互聯網上英語是工作語言，用英語書寫可以將你的問題不被 閱讀就被直接刪除的可能降到最低。
如果你人爲地將問題搞得難以閱讀，它多半會被忽略，人們更願讀易懂的問題，所以：
-
使用文本而不是HTML(超文本標註語言) ( 關閉HTML 並不難)
-
使用MIME(多用途互聯網郵件擴展)附件通常沒有問題，前提是真正有內容(譬如附帶的源文件或補丁)，而不僅僅是郵件客戶端程序 生 成的模板(譬如只是消息內容的拷貝)。
-
不要發送整段只是單行句子但多次折回的郵件(這使得回覆部分內容非常困難)。設想你的讀者是在80個字符寬的文本終端閱讀郵件， 設置你的行折回點小於80列。
-
但是，也不要用 任何固定列折回數據(譬如直接傳送的日 志文件或會話記錄)。數據應該原樣包含，使回覆者確信他們看到的與你看到的東西一樣。
-
在英語論壇中，不要使用'Quoted-Printable' MIME編碼發送消息。這種編碼對於張貼非ASCII語言可能是必須的，但很多郵件代理程序並不支持。當它們分斷時，那些文本中四處散佈 的 “=20”符號既難看也分散注意力。
-
永遠不要指 望***們閱讀使用封閉的專用格式編寫的文檔，諸如微軟公司的Word或Excel文件等，大多數***對此的反應就象有人將還在冒熱氣的豬 糞倒在你門口時你的反應一樣。即使他們能夠處理，他們也很厭惡這麼做。
-
如果你從使用視窗的電腦發送電子郵件，關閉微軟愚蠢的“聰明引用”功能，以免在你的郵件中到處散佈垃圾字符。
-
在網頁論壇，勿濫用“表情符號”和“html”功能(當它們提供時)。一兩個表情符號通常沒有問題，但花哨的彩色文本傾向於使人認爲 你是個無能之輩。過濫地使用表情符號、色彩和字體會使你看來象個傻笑的小姑娘。這通常不是個好主意，除非你只是對性而不是有用的回覆更有興趣。
如果你使用圖形用戶界面的郵件客戶端程序(如網景公司的Messenger、微軟公司的Outlook或者其它類似的)，注意它們的缺省配置不一 定滿足這些要求。大多數這類程序有基於菜單的“查看源碼”命令，用它來檢查發送文件夾中的消息，以確保發送的是沒有多餘雜質的純文本文件。
-
仔細、清楚地描述問題的症狀
-
描述問題發生的環境(主機，操作系統，應用程序，任何相關的)，提供銷售商的發行版和版本號(如：“Fedora Core 2”、“Slackware 9.1”等)
-
描述提問前做過的研究及其理解。
-
描述提問前爲確定問題而採取的診斷步驟。
-
描述最近對計算機或軟件配置的任何相關改變。
盡最大努力預測***會提到的問題，並提前備好答案。
Simon Tatham寫過一篇叫 如何有效報告臭蟲 的文章，我強烈推薦各位閱讀。
你應該(寫得)準確且有內容，簡單地將一大堆代碼或數據“傾倒”在求助消息中達不到目的。如果你有一個很大且複雜的測試樣例讓程序崩潰，嘗 試將其裁剪得越小越好。
至少有三個理由支持這點。第一，讓別人看到你在努力簡化問題使你更有可能得到回覆。第二，簡化問題使你更有可能得到有用的回覆。第三，在提純臭蟲 報告的過程中，你可能自己就找到了解決問題的方法或權宜之計。
當你在一個軟件中遇到問題，除非你非 常、非常的有根據，不要動輒聲稱找到了臭蟲。提示：除非你能提供解決問題的源代碼補丁，或者對前一版本的迴歸測 試 表現出不正確的行爲，否則你都多半不夠完全確信。對於網頁和文檔也如此，如果你(聲稱)發現了文檔的“臭蟲”，你應該能提供相應位置的替代文本。
記住，還有許多其它用戶未經歷你遇到的問題，否則你在閱讀文檔或網頁搜索時就應該發現了(你在報怨前已經做了這些，是吧？)。這也意味着很有可能是你弄錯了而不是軟件本身有問 題。
編寫軟件的人通常非常辛苦地使它儘可能完美。如果你聲稱找到了臭蟲，也就暗示他們做錯了什麼，而這幾乎總會使人不快──即使你是對的， 在主題中嚷嚷“臭蟲”也是特別不老練的。
提問時，即使你私下非常確信已經發現一個真正的臭蟲，最好寫得象是你做 錯了什麼。如果真的有臭蟲，你會在回覆中看到這點。這麼做的話，如果真有蟲子，維護者就會向你道歉，這總比你弄 砸了然後欠別人一個道歉要強。
有些人明白他們不應該粗魯或傲慢地行事並要求得到答覆，但他們退到相反的低聲下氣的極端，“我知道我只是個什麼也不是、什麼也不懂的失敗者， 但……”。這既使人困擾也沒有幫助，當伴隨着對實際問題含糊的描述時還特別令人反感。
別用低級靈長類動物的策略浪費大家的時間，相反，儘量清楚地表述背景事實和你的問題，這比低聲下氣更好地擺正了你的位置。
有時，網頁論壇設有單獨的初學者提問區域，如果你真的認爲遇到了初淺的問題，到那去就是了，但一樣別低聲下氣。
告訴***你認爲是什麼導致了問題是沒有用的(如果你的診斷理論是了不起的東西，你還會向他人諮詢求助嗎？)。所以，確保只是告訴他們問題的原始 症狀，而不是你的解釋和理論，讓他們來解釋和診斷。如果你認爲陳述你的猜測很重要，清楚地說明這只是你的猜測並描述爲什麼它們不起作用。
愚蠢：
-
我在編譯內核時接連遇到SIG11錯誤，懷疑主板上的某根電路絲斷了，找到它們的最好辦法是什麼？
- 明智：
-
我組裝的電腦(K6/233 CPU、FIC-PA2007主板(威盛Apollo VP2芯片組)、Corsair PC133 SDRAM 256Mb內 存)最近在開機20分鐘左右、做內核編譯時頻繁地報SIG11錯，但在頭20分鐘內從不出問題。重啓動不會復位時鐘，但整夜關機會。更換所有內存未解決問 題，相關的典型編譯會話日誌附後。
剛出問題之前發生的事情通常包含有解決問題最有效的線索。所以，記錄中應準確地描述你及電腦在崩潰之前都做了些什麼。在命令行處理的 情況下，有會話日誌(如運行腳本工具生成的)並引用相關的若干(如20)行記錄會非常有幫助。
如果崩潰的程序有診斷選項(如-v詳述選項)，仔細考慮選擇這些能在記錄中增加排錯信息的選項。
如果你的記錄很長(如超過四段)，也許在開頭簡述問題隨後按時間先後羅列詳細過程更有用。這樣做，***在讀你的記錄時就知道該查哪些內容了。
如果你想弄清楚如何做某事(而不是報告一個臭蟲)，在開頭就描述你的目標，此後才描述爲此採取的措施所遇到的問題。
經常有這種情況，尋求技術幫助的人在腦袋裏有個更高層面的目標，他們在自以爲能達到目標的特定道路上被卡住了，然後跑來問該怎麼走，但 沒有意識到這條路本身有問題，結果要費很大的勁才能通過。
- 愚蠢：
-
我怎樣才能讓某圖形程序的顏色拾取器取得十六進制的RGB值？
- 明智：
-
我正試圖用自己選定數值的顏色替換一幅圖片的顏色表，我現在唯一知道的方法是編輯每個表槽，但卻無法讓某圖形程序的顏色拾取器取得十六進 制的RGB值。
第二種提法是明智的，它使得建議採用更合適的工具完成任務的回覆成爲可能。
***們認爲問題的解決過程應該公開、透明，此過程中如果更有才能的人注意到不完整或者不當之處，最初的回覆才能夠、也應該被更正。同時，作爲 回覆者也因爲能力和學識被其它同行看到而得到某種回報。
當你要求私下回復時，此過程和回報都被中止。別這樣做，讓回覆者來決定是否私下回答──如果他 真這麼做了，通常是因爲他認爲問題編寫太差或者太膚淺 以 至於對其它人無意義。
對這條規則存在一條有限的例外，如果你確信提問可能會導致大量雷同的回覆時，那麼“給我發電子郵件，我將爲小組歸納這些回覆”將是神奇的句子。試圖 將郵 件列表或新聞組從洪水般雷同的回覆中解救出來是非常有禮貌的──但你應信守諾言。
漫無邊際的問題通常也被視爲沒有明確限制的時間無底洞。最有可能給你有用答案的人通常也是最忙的人(假如只是因爲他們承擔了大多數工作的話)，這些 人 對於沒 有限制的時間無底洞極其反感，所以他們也傾向於討厭那些漫無邊際的問題。
如果你明確了想讓回覆者做的事(如指點方向、發送代碼、檢查補丁或其它)，你更有可能得到有用的回覆。這可以使他們集中精力並間接地設定了他們爲幫 助你需要花費的時間和精力上限，這很好。
要想理解專家生活的世界，可以這樣設想：那裏有豐富的專長資源但稀缺的響應時間。你暗中要求他們奉獻的時間越少，你越有可能從這些真正懂行也真正很 忙的專家 那裏得到回答。
所以限定你的問題以使專家回答時需要付出的時間最少──這通常還與簡化問題不一樣。舉個例，“請問可否指點一下哪有好一點的X解釋？”通常要 比“請解釋一下X”明智。如果你有什麼代碼不運行了，通常請別人看看哪有問題比叫他們幫你改正更明智。
***們善於發現“家庭作業”式的問題。我們大多數人已經做了自己的家庭作業，那是該你做的，以便從其經歷中學習。問一 下提示沒有關係，但不是要求完整的解決方案。
如果你懷疑自己碰到了一個家庭作業式的問題，但仍然無法解決，嘗試在用戶組論壇或(作爲最後一招)在項目的“用戶”郵件列表或論壇中提問。儘管 ***們會看出來，一些高級用戶也許仍會給你提示。
抵制在求助消息末尾加上諸如“有人能幫我嗎？”或“有沒有答案？”之類在語義上無任何意義東西的誘惑。第一，如果問題描述還不完整，這些附 加的東西最多也只能是多餘的。第二，因爲它們是多餘的，***們會認爲這些東西煩人──就很有可能用邏輯上無誤但打發人的回覆，諸如“是的，你可 以得到幫助”和“不，沒有給你的幫助”
一般來說，避免提“是或否”類型的問題，除非你想得到 “是或否”類型的回答。
這是你自己的問題，不要我們的。宣稱“緊急”極有可能事與願違：大多數***會直接刪除這種消息，他們認爲這是無禮和自私地企圖得到即時與特殊的關 照。
有一點點局部的例外，如果你是在一些知名度很高、會使***們激動的地方使用程序，也許值得這樣去做。在這種情況下，如果你有期限壓力，也很有禮貌 地提到這點，人們也許會有足夠的興趣快一點回答。
當然，這是非常冒險的，因爲***們對什麼是令人激動的標準多半與你的不同。譬如從國際空間站這樣張貼沒有問題，但代表感覺良好的慈善或政治原 因這樣做幾乎肯定不行。事實上，張貼諸如“緊急：幫我救救這個毛絨絨的小海豹！”肯定會被***迴避或光火，即使他們認爲毛絨絨的小海豹很重要。
如果你覺得這不可思議，再把剩下的內容多讀幾遍，直到弄清楚了再發貼。
禮貌一點，使用“請”和“謝謝你的關注”或者“謝謝你的意見”，讓別人明白你感謝他們無償花時間幫助你。
坦率地說，這一點沒有語法正確、文字清晰、準確、有內容和避免使用專用格式重要(同時也不能替代它們)。***們一般寧可讀有點唐突但技術鮮明的臭 蟲報告，而不是那種禮貌但含糊的報告。(如果這點讓你不解，記住我們是按問題能教我們些什麼來評價一個問題的)
然爾，如果你已經談清楚了技術問題，客氣一點肯定會增加你得到有用回覆的機會。
(我們必須指出，本文唯一受到一些老***認真反對的地方是以前曾經推薦過的“提前謝了”，一些***認爲這隱含着事後不用再感謝任何人的暗示。我們的 建議是 先說 “提前謝了”，事後再對回覆者表示感謝。或者換種方式表達，譬如用“謝謝你的關注”或“謝謝你的意見”)。
問題解決後向所有幫助過的人追加一條消息，讓他們知道問題是如何解決的並再次感謝。如果問題在郵件列表或新聞組中受到廣泛關注，在那裏追加此消息比 較恰當。
最理想的方式是向最初提問的線索回覆此消息並在主題包含“已解決”、“已搞定”或其它同樣意思的明顯標記。在人來人往的郵件列表裏，一個看見線索 “問題X”和“問題X-已解決”的潛在回覆者就明白不用再浪費時間了(除非他個人覺得“問題X”有趣)，因此可以用此時間去解決其它 問題。
你追加的消息用不着太長太複雜，一條簡單的“你好──是網線壞了！謝謝大家──比爾”就比什麼都沒有要強。事實上，除 非解決問題的技術真正高深，一條簡短而親切的總結比長篇大論要好。說明是什麼行動解決了問題，用不着重演整個排錯的故事。
對於有深度的問題，張貼排錯歷史的摘要是適當的。描述問題的最終狀態，說明是什麼解決了問題，在此之後才指明可以避免的彎路。應避免的 彎路部分應放在正確的解決方案和其它總結材料之後，而不要將此消息搞成偵探推理小說。列出那些幫助過你的名字，那樣你會交到朋友的。
除了有禮貌、有內容以外，這種類型的追帖將幫助其他人在郵件列表、新聞組或論壇文檔中搜索到真正解決你問題的方案，從而也讓他們受益。
除上述而外，此類追帖還讓每位參與協助的人因問題的解決而產生一種滿足感。如 果你自己 不是技術專家或***，相信我們，這種感覺對於你尋求幫助的老手和專家非常重要。問題敘述到最後不知所終總是令人沮喪的，***們癢 癢地渴望看到它們被解決。“撓癢癢”爲你掙到的好報將對你下次再次張貼提問非常非常的有幫助。
考慮一下怎樣才能避免其他人將來也遇到類似的問題，問問自己編一份文檔或FAQ補丁有沒有幫助，如果有的話就將補丁發給維護者。
在***中，這種行爲實際上比傳統的禮貌更重要，也是你善待他人而贏得聲譽的方式，這是非常有價值的財富。
有一個古老而神聖的傳統：如果你收到了“RTFM”的回覆，發信人認爲你應該去“讀讀該死的手冊”。他多半是對的，去讀一下吧。
RTFM有個年輕的親戚，如果你收到“STFW”的回覆，發信人認爲你應該“搜搜該死的網絡”。他多半也是對的，去搜一下吧。(更溫和一點的說法是 “Google 是你的朋友！”)
在網頁論壇，你也可能被要求去搜索論壇的文檔。事實上，有人甚至可能熱心地爲你提供以前解決此問題的線索。但不要依賴這種好心，提問前應先搜索 一下文 檔。
通常，叫你搜索的人已經打開了能解決你問題的手冊或網頁，正在一邊看一邊敲鍵盤。這些回覆意味着他認爲：第一，你要的信息很容易找到。第二，自已找 要比別人喂到嘴裏能學得更多。
你不應該覺得這樣就被冒犯了，按***的標準，他沒有不理你就是在向你表示某種尊敬，你反而應該感謝他熱切地想幫助你。
如果你看不懂回覆，不要馬上回發一個要求說明的消息，先試試那些最初提問時用過的同樣工具(手冊、FAQ，網頁、懂行的朋友等)試着搞懂回 復。如果還是需要說明，展現你已經明白的。
譬如，假如我告訴你：“聽起來象是某輸入項有問題，你需要清除它”，接着是個不好的回帖：“什麼是某輸入項？”。 而這是一個好的跟帖：“是 的， 我讀了手冊，某輸入項只在-z和-p開關中被提到，但都沒有提及清除某選項，你指的是哪一個還是我弄錯了什麼？”
很多***圈子中看似無禮的行爲並不是存心冒犯。相反，它是直接了當、一刀見血式的交流風格，這種風格對於更關注解決問題而不是使別人感覺舒服而混亂 的人 是很自然的。
你如果覺得被冒犯，努力平靜地反應。如果有人真的做了過格的事，郵件列表或新聞組或論壇中的前輩多半會招呼他。如果這沒有發生而你卻發火了，那麼你發火對 象的言語 可能在***社區中看起來是正常的，而你將 被視爲有錯的一方，這將傷害到你獲取信息或幫助的機會。
另一方面，你會偶而真的碰到無禮和無聊的言行。與上述相反，對真正的冒犯者狠狠地打擊、用犀利的語言將其駁得體無完膚都是可以 接受的。然爾，在行事之前一定要非常非常的有根據。糾正無禮的言論與開始一場毫無意義的口水戰僅一線之隔，***們自己莽撞地越線情況並不鮮見。如果你是新 手或外來者，避開這種莽撞的機會不高。如果你 想得到的是信息而不是消磨時光，這時最好不要把手放在鍵盤上以免冒險。
(有些人斷言很多***都有輕度的自閉症或阿斯伯格綜合症，一定缺少平滑人類社會“正常”交往所需的腦電路。這既可能是真也可能是假。如果你自己不是 ***，興許 你認爲我 們腦袋有問題還能幫助你應付我們的古怪行爲。只管這麼幹好了，我們不在乎。我們喜歡我們現在這個樣子，並且一般都對 臨牀診斷有相當的懷疑。)
在下一節，我們會談到另一個問題，當你行爲不當時會受到的“冒犯”
在***社區的論壇中有那麼幾次你會搞砸──以本文詳述或類似的方式。你會被示衆是如何搞砸的，也許言語中還會帶點顏色。
這種事發生以後，你能做的最糟的事莫過於哀嚎你的遭遇、宣稱被口頭***、要求道歉、高聲尖叫、憋悶氣、威脅訴諸法律、向其僱主報怨、忘了關馬桶蓋等 等。相 反，你該這樣去做：
熬過去，這很正常。事實上，它是有益健康與恰當的。
社區的標準不會自己維持，它們是通過參與者積極而公開地執行來維持的。不要哭嚎所有的 批評都應該通過私下的郵件傳送，這不是事情運作的方式。當有人批評你的 一些主張或者其看法不同時，堅持聲稱個人被侮辱也毫無用處，這些都是失敗者的態度。
也有其它的***論壇，受太高禮節要求的誤導，要求參與者禁止張貼任何對別人帖子挑毛病的消息，並被告知“如果你不想幫助用戶就閉嘴”。有思路的參與 者紛紛 離 開 的結果只會使它們變成了毫無意義的嘮叨與無用的技術論壇。
是誇張的“友誼”(以上述方式)還是有用？挑一個。
記住：當***說你搞砸了，並且(無論多麼刺耳地)告訴你別再這樣做時，他正在爲關心你和他的社區而行動。對他而言，不理你並將你從他的生活中濾除要 容易得 多。如果你無法做到感謝，至少要有點尊嚴，別大聲哀嚎，也別因爲自己是個有戲劇性超級敏感的靈魂和自以爲有資格的新來者，就指望別人象對待脆弱的洋娃娃 那樣對你。
有時候，即使你沒有搞砸(或者只是別人想象你搞砸了)， 有些人會無緣無故地***你本人。在這種情況下，報怨倒是真的會把問題搞砸。
這些找茬者要麼是什麼也不懂但自以爲是專家的不中用傢伙，要麼就是測試你是否真會搞砸的心理學家。其它讀者要麼不理睬，要麼用自己的方式對付他們。 這些找茬者在給自己找麻煩，這點你不用操心。
也別讓自己捲入口水戰，大多數口水戰最好不要理睬──當然是在你覈實它們只是口水戰、沒有指出你搞砸的地方，而且沒有巧妙地將問題真正的答案藏於其 中 (這也 是 可能的)之後。
下面是些典型的愚蠢問題和***不回答它們時的想法。
- 問： 我到哪可以找到程序或X資源？
- 問： 我怎樣用X做Y？
- 問： 如何配置我的shell提示？
- 問： 我可以用Bass-o-matic文件轉換工具將AcmeCorp文檔轉爲TeX格式 嗎？
- 問： 我的{程序、配置、SQL語句}不運行了
- 問： 我的視窗電腦出問題了，你能幫忙嗎？
- 問： 我的程序不運行了，我認爲系統工具X有問題
- 問： 我安裝Linux或X遇到困難，你能幫忙嗎？
- 問： 我如何才能破解超級用戶口令/盜取頻道操作員的特權/查看某人的電子郵件？
- 問： 我怎樣用X做Y？
| 問： | |
| 答： |
在我找到它的同樣地方，笨旦──在網頁搜索引擎上。上帝啊，難道還有人不知道如何使用 Google 嗎？ |
| 問： | |
| 答： |
如果你想做的是Y，提問時別給出可能並不恰當的方法。這種問題說明提問者不但對X完全無知，也對要解決的Y問題糊塗，還被特定形勢禁 錮了思維。等他們把問題弄 好再說。 |
| 問： | |
| 答： |
如果你有足夠的智慧提這個問題，你也該有足夠的智慧去 RTFM， 然後自己去找。 |
| 問： |
|
| 答： |
試試就知道了。如果你試過，你既知道答案，又不用浪費我的時間了。 |
| 問： |
|
| 答： |
這不是一個問題，我也沒有興趣去猜你有什麼問題──我有更要緊的事要做。看到這種東西，我的反應一般如下：
|
| 問： |
|
| 答： |
是的，把視窗垃圾刪了，裝個象Linux或BSD的開源操作系統吧。
注意：如果程序有官方的視窗版或與視窗有交互(如Samba)，你可以問與視窗電腦相關的問題，只是別 對問題是由視窗操作系統而不是程序本身造成的回覆感 到驚訝，因 爲視窗一般來說太差，這種說法一般都成立。 |
| 問： |
|
| 答： |
你完全有可能是第一個注意到被成千上萬用戶反覆使用的系統調用與庫文件有明顯缺陷的人，更有可能的是你完全沒有根據。不同凡響的說法需 要不同凡響的證據， 當你這樣 聲稱時，你必須有清楚而詳盡的缺陷說明文檔作後盾。 |
| 問： |
我安裝Linux或X遇到問題，你能幫忙嗎？ |
| 答： |
不行，我需要親手操作你的電腦才能幫你排錯，去向當地的Linux用戶組尋求方便的幫助(你可以在 這裏 找到用戶組列表)
注意：在爲某一Linux發行版服務的郵件列表或論壇或本地用戶組織中提關於安裝該發行版的問題也許是恰當的。此時，應描述問題的準確 細節。在此之前，先用 “linux”和所有被懷 疑的硬件(爲關鍵詞)仔細搜索。 |
| 問： |
|
| 答： |
想做這種事情說明你是個卑劣的傢伙，想讓***教你做這種事情說明你是個白癡。 |
最後，我將通過舉例來演示提問的智慧。同樣的問題兩種問法，一種愚蠢，另一種明智。
愚蠢：我在哪能找到關於Foonly Flurbamatic設備的東西？
-
這個問題在乞求得到 STFW 式的回覆。
明智：我用Google搜索過“Foonly Flurbamatic 2600”，但沒有找到什麼有用的，有誰知道在哪能找到這種設備的編程信息？
-
這個人已經搜索過網絡了，而且聽起來他可能真的遇到了問題。
愚蠢：我不能編譯某項目的源代碼，它爲什 麼這麼破？
-
他假設是別人搞砸了，太自大了。
明智：某項目的源代碼不能在某Linux 6.2版下編譯。我讀了常見問題文檔，但其中沒有與某Linux相關的問題。這是編譯時的記錄，我做錯了什麼嗎？
-
他指明瞭運行環境，讀了FAQ，列出了錯誤，也沒有假設問題是別人的過錯，這傢伙值得注意。
愚蠢：我的主板有問題，誰能幫我？
-
某***對此的反應可能是：“是的，還需要幫你拍背和換尿布嗎？”，然後是敲下刪除鍵。
明智：我在S2464主板上試過X、Y和 Z，當它們都失敗後，又試了A、B和C。注意我試C時的奇怪症狀，顯然某某東西正在做某某事情，這不是期望的。通常 在Athlon MP主板上導致某某事情的原因是什麼？有誰知道我還能再試點什麼以確定問題？
-
相反地，這個人看來值得回答。他展現瞭解決問題的能力而不是坐等天上掉餡餅。
在最後那個問題中，注意“給我一個回覆”與“請幫我看看我還能再做點什麼測試以得到啓發”之間細微但重要的差別。
事實上，最後那個問題基本上源於2001年8月Linux內核郵件列表(lkml)上的真實事件，是我(Eric)當時提了那個問題，我發現 Tyan S2462 主板有神祕的死機現象，郵件列表成員給我提供瞭解決此問題的關鍵信息。
通過這種提問方式，我給了別人可以咀嚼玩味的東西。我設法使之對參與者既輕鬆又有吸引力，也表明了對同行能力的尊敬並邀請他們與我一起協商。通 過告訴 他們我已經走過的彎路，我還表明了對他們寶貴時間的尊重。
事後，當我感謝大家並評論這次良好的經歷時，一個Linux內核郵件列表的成員談到，他認爲並不是因爲我的名字在列表上，而是因爲我正確的提問方式 才 得到了答 案。
***們在某種方面是非常不留情面的精英分子。我想他是對的，如果我表現得象個不勞而獲的寄生蟲，不管我是誰都會被忽略或斥責。他建議將整個事件作爲 對其它 人 提問的指導直接導致了本文的編寫。
如果得不到回答，請不要認爲我們不想幫你，有時候只是因爲小組成員的確不知道答案。沒有回覆不等於被忽略，當然必須承認從外面很難看出兩者的差別。
一般來說，直接將問題再張貼一次不好，這會被視爲毫無意義的騷擾。
還有其它資源可以尋求幫助，通常是在一些面向新手的資源中。
有許多在線與本地用戶組織，雖然它們自己不編寫任何軟件，但是對軟件很熱心。這些用戶組通常因互助和幫助新手而形成。
還有衆多大小商業公司提供簽約支持服務(紅帽與Linuxcare是兩家最出名的，還有許多其它的)。別因爲要付點錢纔有支持就感到沮喪！畢竟，如 果你車子的 汽缸墊燒了，你多半還得花錢找個修理店把它弄好。即使軟件沒花你一分錢，你總不能指望服務支持都是免費的。
象Linux這樣流行的軟件，每個開發者至少有一萬個以上的用戶，一個人不可能應付這麼多用戶的服務要求。記住，即使你必須付費才能得到支持，也比 你還得額外花錢買軟件要少得多(而且對封閉源代碼軟件的服務支持與開源軟件相比通常還要貴一點，也要差一點)
態度和善一點。問題帶來的壓力常使人 顯得無禮或愚蠢，其實並不是這樣。
對初犯者私下回復。對那些坦誠犯錯 之人沒有必要當衆羞辱，一個真正的新手也許連怎麼搜索或在哪找FAQ都不知道。
如果你不確定，一定要說出來！一個聽 起來權威的錯誤回覆比沒有還要糟，別因爲聽起來象個專家好玩就給別人亂指路。要謙虛和誠實，給提問者與同行都樹個好榜樣。
如果幫不了忙，別妨 礙。不要在具體步驟上開玩笑，那樣也許會毀了用戶的安裝──有些可憐的呆瓜會把它當成真的指令。
探索性的反問以引出更多的細節。如 果你做得好，提問者可以學到點東西──你也可以。試試將很差的問題轉變成好問題，別忘了我們都曾是新手。
儘管對那些懶蟲報怨一聲RTFM是正當的，指出文檔的位置(即使只是建議做個Google關鍵詞搜索)會更好。
如果你決意回答，給 出好的答案。當別人正使用錯誤的工具或不當 的方法時別建議笨拙的權宜之計，應推薦更好的工具，重新組織問題。
幫助你的社區從問題中 學習。當回覆一個好問題時，問問自己 “如何修改相關文件或FAQ文檔以免再次解答同樣的問題？”，接着再向文檔維護者發一份補丁。
如果你的確是在研究一番後才做出的回答，展 現你的技巧而不是直接端出結果。畢竟“授 人以魚，不如授人以漁”。