yunfei-dev/How-To-Ask-Questions-The-Smart-Way
1
1
Fork 0
mirror of https://github.com/yunfei-dev/How-To-Ask-Questions-The-Smart-Way.git synced 2025-02-25 21:04:04 +08:00
Code Issues Packages Projects Releases Wiki Activity

fine tune

Browse Source
This commit is contained in:
Ryan Wu 2015-03-29 02:38:29 +08:00
parent becfc2c9f9
commit 312ca174bf
1 changed files with 33 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
README.md
View File

@ -1,16 +1,23 @@
#「提問的智慧(How To Ask Questions The Smart Way)」 #提問的智慧
英文版: [http://www.catb.org/~esr/faqs/smart-questions.html](http://www.catb.org/~esr/faqs/smart-questions.html) **How To Ask Questions The Smart Way**
Copyright © 2001,2006,2014 Eric S. Raymond, Rick Moen Copyright © 2001,2006,2014 Eric S. Raymond, Rick Moen
本指南英文版版權為 Eric S. Raymond, Rick Moen 所有。 本指南英文版版權為 Eric S. Raymond, Rick Moen 所有。
Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu 原文網址:[http://www.catb.org/~esr/faqs/smart-questions.html](http://www.catb.org/~esr/faqs/smart-questions.html)
這本中文指南是根據原文 3.10 版的最新翻譯，請協助指出翻譯問題，或直接[發Pull Request](https://github.com/ryanhanwu/smartquestions/compare/) 給我。
另有简体中文版: [http://www.beiww.com/doc/oss/smart-questions.html](http://www.beiww.com/doc/oss/smart-questions.html) Copyleft 2001 by D.H.Grand（nOBODY/Ginux）, 2010 by Gasolin, 2015 by Ryan Wu
## 聲明 ## 本中文指南是根據原文 3.10 版的最新翻譯；
協助指出翻譯問題，__請[發Issue](https://github.com/ryanhanwu/smartquestions/issues/new)，或直接[發Pull Request](https://github.com/ryanhanwu/smartquestions/compare/)給我。__
本文另有简体中文版: [http://www.beiww.com/doc/oss/smart-questions.html](http://www.beiww.com/doc/oss/smart-questions.html)
##目錄
##聲明
許多專案在他們的使用協助/說明網頁中連結了本指南，這麼做很好，我們也鼓勵大家都這麼做。 但如果你是負責管理這個專案網頁的人，請在超連結附近的顯著位置上註明： 許多專案在他們的使用協助/說明網頁中連結了本指南，這麼做很好，我們也鼓勵大家都這麼做。 但如果你是負責管理這個專案網頁的人，請在超連結附近的顯著位置上註明：
@ -20,7 +27,7 @@ __本指南不提供此專案的實際支援服務！__
如果你是因為需要某些協助而正在閱讀這本指南，並且最後離開是因為發現從本指南作者們身上得不到直接的協助，那麼你就是我們所說的那些白痴之一。別問我們問題，我們只會忽略你。我們在這本指南中是教你如何從那些真正懂得你所遇到軟體或硬體問題的人取得協助，而99%的情況下那不會是我們。除非你確定本指南的作者之一剛好是你所遇到的問題領域的專家，否則請不要打擾我們，這樣大家都會開心一點。 如果你是因為需要某些協助而正在閱讀這本指南，並且最後離開是因為發現從本指南作者們身上得不到直接的協助，那麼你就是我們所說的那些白痴之一。別問我們問題，我們只會忽略你。我們在這本指南中是教你如何從那些真正懂得你所遇到軟體或硬體問題的人取得協助，而99%的情況下那不會是我們。除非你確定本指南的作者之一剛好是你所遇到的問題領域的專家，否則請不要打擾我們，這樣大家都會開心一點。
# 簡介 # ##簡介
在[黑客](http://www.catb.org/~esr/faqs/hacker-howto.html)的世界裡，當你拋出一個技術問題時，最終是否能得到有用的回答，往往取決於你所提問和追問的方式。本指南將教你如何正確的提問以獲得你滿意的答案。 在[黑客](http://www.catb.org/~esr/faqs/hacker-howto.html)的世界裡，當你拋出一個技術問題時，最終是否能得到有用的回答，往往取決於你所提問和追問的方式。本指南將教你如何正確的提問以獲得你滿意的答案。
@ -30,11 +37,11 @@ __本指南不提供此專案的實際支援服務！__
儘管如此，黑客們有著蔑視或傲慢面對簡單問題的壞名聲，這有時讓我們看起來對新手、無知者似乎較有敵意，但其實不是那樣的。 儘管如此，黑客們有著蔑視或傲慢面對簡單問題的壞名聲，這有時讓我們看起來對新手、無知者似乎較有敵意，但其實不是那樣的。
我們不諱言我們對那些不願思考、或者在發問前不做他們該做的事的人的蔑視。那些人是時間殺手 -– 他們只想索取，從不付出，消耗我們可用在更有趣的問題或更值得回答的人身上的時間。我們稱這樣的人為 "失敗者（魯蛇）" (由於歷史原因，我們有時把它拼作 "lusers")。 我們不諱言我們對那些不願思考、或者在發問前不做他們該做的事的人的蔑視。那些人是時間殺手 -– 他們只想索取，從不付出，消耗我們可用在更有趣的問題或更值得回答的人身上的時間。我們稱這樣的人為 "失敗者（魯蛇）" （由於歷史原因，我們有時把它拼作 "lusers"）。
我們意識到許多人只是想使用我們寫的軟體，他們對學習技術細節沒有興趣。對大多數人而言，電腦只是種工具，是種達到目的的手段而已。他們有自己的生活並且有更要緊的事要做。我們了解這點，也從不指望每個人都對這些讓我們著迷的技術問題感興趣。儘管如此，我們回答問題的風格是指向那些真正對此有興趣並願意主動參與解決問題的人，這一點不會變，也不該變。如果連這都變了，我們就是在降低做自己最擅長的事情上的效率。 我們意識到許多人只是想使用我們寫的軟體，他們對學習技術細節沒有興趣。對大多數人而言，電腦只是種工具，是種達到目的的手段而已。他們有自己的生活並且有更要緊的事要做。我們了解這點，也從不指望每個人都對這些讓我們著迷的技術問題感興趣。儘管如此，我們回答問題的風格是指向那些真正對此有興趣並願意主動參與解決問題的人，這一點不會變，也不該變。如果連這都變了，我們就是在降低做自己最擅長的事情上的效率。
我們 (在很大程度上) 是自願的，從繁忙的生活中抽出時間來解答疑惑，而且時常被提問淹沒。 所以我們無情的濾掉一些話題，特別是拋棄那些看起來像失敗者的傢伙，以便更高效的利用時間來回答勝利者（溫拿）的問題。 我們（在很大程度上）是自願的，從繁忙的生活中抽出時間來解答疑惑，而且時常被提問淹沒。所以我們無情的濾掉一些話題，特別是拋棄那些看起來像失敗者的傢伙，以便更高效的利用時間來回答勝利者（溫拿）的問題。
如果你厭惡我們的態度，高高在上，或過於傲慢，不妨也設身處地想想。我們並沒有要求你向我們屈服 -- 事實上，我們大多數人非常樂意與你平等地交流，只要你付出小小努力來滿足基本要求，我們就會歡迎你加入我們的文化。但讓我們幫助那些不願意幫助自己的人是沒有效率的。無知沒有關係，但裝白痴就是不行。 如果你厭惡我們的態度，高高在上，或過於傲慢，不妨也設身處地想想。我們並沒有要求你向我們屈服 -- 事實上，我們大多數人非常樂意與你平等地交流，只要你付出小小努力來滿足基本要求，我們就會歡迎你加入我們的文化。但讓我們幫助那些不願意幫助自己的人是沒有效率的。無知沒有關係，但裝白痴就是不行。
@ -42,11 +49,9 @@ __本指南不提供此專案的實際支援服務！__
如果你決定向我們求助，當然你也不希望被視為失敗者，更不願成為失敗者中的一員。 能立刻得到快速並有效答案的最好方法，就是像勝利者那樣提問 --聰明、自信、有解決問題的思路，只是偶爾在特定的問題上需要獲得一點幫助。 如果你決定向我們求助，當然你也不希望被視為失敗者，更不願成為失敗者中的一員。 能立刻得到快速並有效答案的最好方法，就是像勝利者那樣提問 --聰明、自信、有解決問題的思路，只是偶爾在特定的問題上需要獲得一點幫助。
（歡迎對本指南提出改進意見。你可以 email 你的建議至 [esr@thyrsus.com](esr@thyrsus.com) 或 [respond-auto@linuxmafia.com](respond-auto@linuxmafia.com)，然而請注意，本文並非 [網路禮節](http://www.dtcc.edu/cs/rfc1855.html)的通用指南，我通常會拒絕無助於在技術論壇得到有用答案的建議。） （歡迎對本指南提出改進意見。你可以 email 你的建議至 [esr@thyrsus.com](esr@thyrsus.com) 或 [respond-auto@linuxmafia.com](respond-auto@linuxmafia.com)。然而請注意，本文並非[網路禮節](http://www.ietf.org/rfc/rfc1855.txt)的通用指南，而我們通常會拒絕無助於在技術論壇得到有用答案的建議。）
__如果你寫中文，請直接[發Issues](https://github.com/ryanhanwu/smartquestions/issues/new)給我__ ##在提問之前
# 在提問之前 #
在你準備要通過電子郵件、新聞群組或者聊天室提出技術問題前，請先做到以下事情： 在你準備要通過電子郵件、新聞群組或者聊天室提出技術問題前，請先做到以下事情：
@ -137,7 +142,7 @@ __如果你寫中文，請直接[發Issues](https://github.com/ryanhanwu/smartqu
如果你想在話題回覆中提出問題，記得要修改內容標題，以表明你是在問一個問題， 一個看起來像“Re: 測試” 或者“Re: 新bug”的問題很難引起足夠重視。另外，引用並刪減前文的內容，給新來的讀者留下線索。 如果你想在話題回覆中提出問題，記得要修改內容標題，以表明你是在問一個問題， 一個看起來像“Re: 測試” 或者“Re: 新bug”的問題很難引起足夠重視。另外，引用並刪減前文的內容，給新來的讀者留下線索。
對於問題列表，不要直接點擊回覆（按鈕）來開始一個全新的話題(Thread)，這將限縮你的觀眾。 因為有些郵件閱讀程序，比如mutt，允許使用者按話題排序並通過折疊話題來隱藏消息，這樣做的人永遠看不到你發的消息。 對於問題列表，不要直接點擊回覆（按鈕）來開始一個全新的話題（Thread），這將限縮你的觀眾。 因為有些郵件閱讀程序，比如mutt，允許使用者按話題排序並通過折疊話題來隱藏消息，這樣做的人永遠看不到你發的消息。
僅僅改變主題還不夠。 mutt和其它一些郵件閱讀程式還會檢查郵件標題以外的其它信息，以便為其指定話題。所以寧可發一個全新的郵件。 僅僅改變主題還不夠。 mutt和其它一些郵件閱讀程式還會檢查郵件標題以外的其它信息，以便為其指定話題。所以寧可發一個全新的郵件。
@ -157,7 +162,7 @@ __如果你寫中文，請直接[發Issues](https://github.com/ryanhanwu/smartqu
正確地拼寫、使用標點和大小寫，不要將“its”混淆為“it's”，“loose”搞成“lose”或者將“discrete”弄成“discreet”。 不要全部用大寫，這會被視為無禮的大聲嚷嚷（全部小寫也好不到哪去，因為不易閱讀。Alan Cox[注：著名黑客，Linux內核的重要參與者]也許可以這樣做，但你不行。） 正確地拼寫、使用標點和大小寫，不要將“its”混淆為“it's”，“loose”搞成“lose”或者將“discrete”弄成“discreet”。 不要全部用大寫，這會被視為無禮的大聲嚷嚷（全部小寫也好不到哪去，因為不易閱讀。Alan Cox[注：著名黑客，Linux內核的重要參與者]也許可以這樣做，但你不行。）
一般而言，如果你寫得像是個[小白](http://zh.wikipedia.org/zh-tw/小白)，那多半得不到理睬。也不要使用即時通訊中的簡寫或[火星文](http://zh.wikipedia.org/zh-tw/火星文)，如將“的”簡化為“ㄉ”會使你看起來像一個為了少打幾個鍵而省字的小白。 更糟的是，如果像個小孩似地鬼畫符那絕對是在找死，可以肯定沒人會理你（或者最多是給你一大堆指責與挖苦）。 一般而言，如果你寫得像是個[小白]（http://zh.wikipedia.org/zh-tw/小白），那多半得不到理睬。也不要使用即時通訊中的簡寫或[火星文]（http://zh.wikipedia.org/zh-tw/火星文），如將“的”簡化為“ㄉ”會使你看起來像一個為了少打幾個鍵而省字的小白。 更糟的是，如果像個小孩似地鬼畫符那絕對是在找死，可以肯定沒人會理你（或者最多是給你一大堆指責與挖苦）。
如果在使用非母語的論壇提問，**你可以犯點拼寫和語法上的小錯，但決不能在思考上馬虎**（沒錯，我們能弄清兩者的分別）。 同時，除非你知道回覆者使用的語言，否則請使用英語書寫。繁忙的黑客一般會直接刪除用他們看不懂語言寫的消息。 在網路上英語是通用語言，用英語書寫可以將你的問題在尚未被閱讀就被直接刪除的可能性降到最低。 如果在使用非母語的論壇提問，**你可以犯點拼寫和語法上的小錯，但決不能在思考上馬虎**（沒錯，我們能弄清兩者的分別）。 同時，除非你知道回覆者使用的語言，否則請使用英語書寫。繁忙的黑客一般會直接刪除用他們看不懂語言寫的消息。 在網路上英語是通用語言，用英語書寫可以將你的問題在尚未被閱讀就被直接刪除的可能性降到最低。
@ -165,27 +170,27 @@ __如果你寫中文，請直接[發Issues](https://github.com/ryanhanwu/smartqu
如果你人為地將問題搞得難以閱讀，它多半會被忽略，人們更願讀易懂的問題，所以： 如果你人為地將問題搞得難以閱讀，它多半會被忽略，人們更願讀易懂的問題，所以：
* 使用純文本而不是HTML（ [關閉HTML](http://expita.com/nomime.html)並不難） * 使用純文本而不是HTML（ [關閉HTML]（http://expita.com/nomime.html）並不難）
* 使用MIME附件通常沒有問題，前提是真正有內容（譬如附帶的原始碼或patch），而不僅僅是郵件程式生成的模板（譬如只是消息內容的拷貝）。 * 使用MIME附件通常沒有問題，前提是真正有內容（譬如附帶的原始碼或patch），而不僅僅是郵件程式生成的模板（譬如只是消息內容的拷貝）。
* 不要發送整段只是單行句子但多次折回的郵件（這使得回复部分內容非常困難）。設想你的讀者是在80個字符寬的終端機上閱讀郵件，最好設置你的行折回點小於80字。 * 不要發送整段只是單行句子但多次折回的郵件（這使得回复部分內容非常困難）。設想你的讀者是在80個字符寬的終端機上閱讀郵件，最好設置你的行折回點小於80字。
* 但是，也不要用任何固定列折回資料(譬如日誌檔案拷貝或會話記錄)。檔案應該原樣包含，使回复者確信他們看到的是與你看到的一樣的東西。 * 但是，也不要用任何固定列折回資料（譬如日誌檔案拷貝或會話記錄）。檔案應該原樣包含，使回复者確信他們看到的是與你看到的一樣的東西。
* 在英語論壇中，不要使用'Quoted-Printable' MIME編碼發送消息。這種編碼對於張貼非ASCII語言可能是必須的，但很多郵件程式並不支援這種編碼。 當它們分斷時，那些文本中四處散佈的“=20”符號既難看也分散注意力，甚至有可能破壞內容的語意。 * 在英語論壇中，不要使用'Quoted-Printable' MIME編碼發送消息。這種編碼對於張貼非ASCII語言可能是必須的，但很多郵件程式並不支援這種編碼。 當它們分斷時，那些文本中四處散佈的“=20”符號既難看也分散注意力，甚至有可能破壞內容的語意。
* 永遠不要指望黑客們閱讀使用封閉的專用格式編寫的文檔，諸如微軟公司的Word或Excel文件等。 大多數黑客對此的反應就像有人將還在冒熱氣的豬糞倒在你門口時你的反應一樣。 即使他們能夠處理，他們也很厭惡這麼做。 * 永遠不要指望黑客們閱讀使用封閉的專用格式編寫的文檔，諸如微軟公司的Word或Excel文件等。 大多數黑客對此的反應就像有人將還在冒熱氣的豬糞倒在你門口時你的反應一樣。 即使他們能夠處理，他們也很厭惡這麼做。
* 如果你從使用Windows的電腦發送電子郵件，關閉微軟愚蠢的“聰明引用”功能，以免在你的郵件中到處散佈垃圾字符。 * 如果你從使用Windows的電腦發送電子郵件，關閉微軟愚蠢的“聰明引用”功能，以免在你的郵件中到處散佈垃圾字符。
* 在論壇，勿濫用“表情符號”和“HTML”功能(當它們提供時)。一兩個表情符號通常沒有問題，但花哨的彩色文本傾向於使人認為你是個無能之輩。 過濫地使用表情符號、色彩和字體會使你看來像個傻笑的小姑娘。 這通常不是個好主意，除非你只是對性而不是有用的回覆更有興趣。 * 在論壇，勿濫用“表情符號”和“HTML”功能（當它們提供時）。一兩個表情符號通常沒有問題，但花哨的彩色文本傾向於使人認為你是個無能之輩。 過濫地使用表情符號、色彩和字體會使你看來像個傻笑的小姑娘。 這通常不是個好主意，除非你只是對性而不是有用的回覆更有興趣。
如果你使用圖形用戶界面的郵件程式(如微軟公司的Outlook或者其它類似的)，注意它們的預設配置不一定滿足這些要求。 大多數這類程式有基於選單的“查看原始碼”命令，用它來檢查發送文件夾中的消息，以確保發送的是沒有多餘雜質的純文本文件。 如果你使用圖形用戶界面的郵件程式（如微軟公司的Outlook或者其它類似的），注意它們的預設配置不一定滿足這些要求。 大多數這類程式有基於選單的“查看原始碼”命令，用它來檢查發送文件夾中的消息，以確保發送的是沒有多餘雜質的純文本文件。
## 準確描述問題並言之有物 ## ## 準確描述問題並言之有物 ##
* 仔細、清楚地描述問題的症狀。 * 仔細、清楚地描述問題的症狀。
* 描述問題發生的環境（機器配置、作業系統、應用程式以及別的什麼），提供銷售商的發行版和版本號(如：“Fedora Core 4”、“Slackware 9.1”等)。 * 描述問題發生的環境（機器配置、作業系統、應用程式以及別的什麼），提供銷售商的發行版和版本號（如：“Fedora Core 4”、“Slackware 9.1”等）。
* 描述在提問前你是怎樣去研究和理解這個問題的。 * 描述在提問前你是怎樣去研究和理解這個問題的。
* 描述在提問前為確定問題而採取的診斷步驟。 * 描述在提問前為確定問題而採取的診斷步驟。
* 描述最近做過什麼可能有影響的硬體、軟體變更。 * 描述最近做過什麼可能有影響的硬體、軟體變更。
* 儘量想像一個黑客會怎樣反問你，在提問的時候預先給他答案。 * 儘量想像一個黑客會怎樣反問你，在提問的時候預先給他答案。
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)》的出色文章。強力推薦你也讀一讀。 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）》的出色文章。強力推薦你也讀一讀。
## 話不在多而在精 ## ## 話不在多而在精 ##
@ -263,7 +268,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug](http://go2.wordpress
別要求他人給你有問題的代碼除錯而不提示一下應該從何入手。 張貼幾百行的代碼，然後說一聲：“它不能運行”會讓你得不到理睬。 只貼幾十行代碼，然後說一句：“在第七行以後，本應該顯示 的，但實際出現的是鍵”比較有可能讓你得到回應。 別要求他人給你有問題的代碼除錯而不提示一下應該從何入手。 張貼幾百行的代碼，然後說一聲：“它不能運行”會讓你得不到理睬。 只貼幾十行代碼，然後說一句：“在第七行以後，本應該顯示 的，但實際出現的是鍵”比較有可能讓你得到回應。
最有效描述程式問題的方式是提供最精簡的Bug展示測試用例。什麼是最精簡的測試示例? 那是問題的速寫;一小段程式片段剛好展示出程式不正常的行為，而不包含其他分散注意力的內容。 怎麼製作最精簡的測試示例?如果你知道哪一行或哪一段程式碼會造成產生問題的行為，複製下來並加入充足的程式碼以重現這個示例 (例如，足以讓這段程式碼能被編譯/直譯/被應用程式處理)。 如果你無法將問題縮減到一段特定的區塊，複製並開始移除不影響產生問題行為的程式碼。測試示例越小越好(查看話不在多而在精一節). 最有效描述程式問題的方式是提供最精簡的Bug展示測試用例。什麼是最精簡的測試示例? 那是問題的速寫;一小段程式片段剛好展示出程式不正常的行為，而不包含其他分散注意力的內容。 怎麼製作最精簡的測試示例?如果你知道哪一行或哪一段程式碼會造成產生問題的行為，複製下來並加入充足的程式碼以重現這個示例 （例如，足以讓這段程式碼能被編譯/直譯/被應用程式處理）。 如果你無法將問題縮減到一段特定的區塊，複製並開始移除不影響產生問題行為的程式碼。測試示例越小越好（查看話不在多而在精一節）.
通常要得到一段相當精簡的測試示例並不太容易, 但永遠先做這樣的嘗試是種好習慣。 這種方式可以幫助你了解如何自行解決這個問題 — 而且即使你的嘗試不成功，黑客們也會欣然看到你在嘗試取得答案的過程中付出了努力。 這可以讓他們更願意與你合作。 通常要得到一段相當精簡的測試示例並不太容易, 但永遠先做這樣的嘗試是種好習慣。 這種方式可以幫助你了解如何自行解決這個問題 — 而且即使你的嘗試不成功，黑客們也會欣然看到你在嘗試取得答案的過程中付出了努力。 這可以讓他們更願意與你合作。
@ -281,7 +286,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug](http://go2.wordpress
首先：如果你對問題的描述不很合適，這樣問更是畫蛇添足。 首先：如果你對問題的描述不很合適，這樣問更是畫蛇添足。
其次：由於這樣問是畫蛇添足，黑客們會很厭煩你–而且通常會用邏輯上正確，但毫無意義的回答來表示他們的蔑視， 例如：“沒錯，有人能幫你”或者“不，沒答案”。 其次：由於這樣問是畫蛇添足，黑客們會很厭煩你–而且通常會用邏輯上正確，但毫無意義的回答來表示他們的蔑視， 例如：“沒錯，有人能幫你”或者“不，沒答案”。
一般來說，避免提“是或否”類型的問題，除非你想得到“[是或否](http://homepages.tesco.net/~J.deBoynePollard/FGA/questions-with-yes-or-no-answers.html)”類型的回答。 一般來說，避免提“是或否”類型的問題，除非你想得到“[是或否]（http://homepages.tesco.net/~J.deBoynePollard/FGA/questions-with-yes-or-no-answers.html）”類型的回答。
## 不要把問題標記為“急”，即使對你而言確實如此 ## ## 不要把問題標記為“急”，即使對你而言確實如此 ##
@ -325,7 +330,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug](http://go2.wordpress
有一個古老而神聖的傳統：如果你收到“RTFM （Read The Fxxking Manual）”的回應，回答者認為你應該去讀讀該死的手冊。當然，基本上他是對的，你應該去讀一讀。 有一個古老而神聖的傳統：如果你收到“RTFM （Read The Fxxking Manual）”的回應，回答者認為你應該去讀讀該死的手冊。當然，基本上他是對的，你應該去讀一讀。
RTFM有一個年輕的親戚。如果你收到“STFW （Search The Fxxking Web）”的回應，回答者認為你應該已經到該死的網路上搜索過了。那人多半也是對的，去搜尋一下吧。 （更溫和一點的說法是“[Google是你的朋友](http://lmgtfy.com/)！”） RTFM有一個年輕的親戚。如果你收到“STFW （Search The Fxxking Web）”的回應，回答者認為你應該已經到該死的網路上搜索過了。那人多半也是對的，去搜尋一下吧。 （更溫和一點的說法是“[Google是你的朋友]（http://lmgtfy.com/）！”）
在論壇，你也可能被要求去爬爬論壇的舊文。事實上，有人甚至可能熱心地為你提供以前解決此問題的線索。 但不要依賴這種關照，提問前應該先搜索一下舊文。 在論壇，你也可能被要求去爬爬論壇的舊文。事實上，有人甚至可能熱心地為你提供以前解決此問題的線索。 但不要依賴這種關照，提問前應該先搜索一下舊文。
@ -539,10 +544,10 @@ RTFM有一個年輕的親戚。如果你收到“STFW （Search The Fxxking Web
如果你是在研究一番後才做出的回答，展現你的技巧而不是直接端出結果。畢竟“授人以魚，不如授人以漁”。# 相關資源 # 如果你是在研究一番後才做出的回答，展現你的技巧而不是直接端出結果。畢竟“授人以魚，不如授人以漁”。# 相關資源 #
如果需要個人電腦，Unix系統和網路如何工作的基礎知識，參閱[Unix系統和網路基本原理](http://en.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/)。 如果需要個人電腦，Unix系統和網路如何工作的基礎知識，參閱[Unix系統和網路基本原理]（http://en.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/）。
當你發布軟體或patch時，試著按[軟體發布實踐](http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html)操作。 當你發布軟體或patch時，試著按[軟體發布實踐]（http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html）操作。
# 鳴謝 #
## 鳴謝
Evelyn Mitchel貢獻了一些愚蠢問題例子並啟發了編寫“如何更好地回答問題”這一節， Mikhail Ramendik貢獻了一些特別有價值的建議和改進。 Evelyn Mitchel貢獻了一些愚蠢問題例子並啟發了編寫“如何更好地回答問題”這一節， Mikhail Ramendik貢獻了一些特別有價值的建議和改進。