在問答網站提問
在提問之前
在準備要通過電子郵件、新聞群組或者聊天室提出技術問題前，應做到以下事情：
- 嘗試在準備提問的論壇的舊文章中搜索答案。
- 嘗試上網搜索以找到答案。
- 嘗試閱讀手冊以找到答案。
- 嘗試閱讀常見問題文件（FAQ）以找到答案。
- 嘗試自己檢查或試驗以找到答案。
- 向身邊的強者朋友打聽以找到答案。
- 程序開發者請嘗試閱讀源代碼以找到答案。
提出問題的時候，應先表明自己已經做了上述的努力；這將有助于樹自己并不是一個不勞而獲且浪費別人的時間的提問者的形象。如果能一并表達在做了上述努力的過程中所學到的東西會更好，因為回答者更樂于回答那些表現出能從答案中學習的人的問題。
準備好自己的問題，再將問題仔細的思考過一遍.
在提問時
應該要小心選擇自己提問的場合，避免做下述事情：
- 在與主題不和的論壇上貼出自己的問題。
- 在探討進階技術問題的論壇張貼非常初級的問題；反之亦然。
- 在太多的不同新聞群組上重復轉貼同樣的問題（cross-post）。
- 向既非熟人也沒有義務解決我們問題的人發送私人電郵。
黑客會剔除掉那些搞錯場合的問題，以保護他們溝通的渠道不被無關的東西淹沒。
因此，第一步是找到對的論壇。
在選擇論壇、新聞群組或郵件列表時，別太相信名字，先看看 FAQ 或者許可書以弄清楚自己的問題是否切題。發文前先翻翻已有的話題，這樣可以幫助我們感受那里的文化。
事先在新聞組或郵件列表的歷史記錄中搜索與自己的問題相關的關鍵詞是個很好的主意，也許這樣就找到答案了。即使沒有，也能幫助我們歸納出更好的問題。
這里有兩個推薦的技術類問答網站：
http://segmentfault.com -（國內）
https://stackoverflow.com -（國外）
在任何論壇發文以前，先確認一下有沒有搜索功能。如果有，就試著搜索一下問題的幾個關鍵詞，也許這會有幫助。
第二部 使用項目郵件列表
當某個項目提供開發者郵件列表時，要向列表而不是其中的個別成員提問，即使確信他能最好地回答你的問題。查一查項目的文件和首頁，找到項目的郵件列表并使用它。
如果一個項目既有"使用者" 也有"開發者"（或"黑客"）郵件列表或論壇，而自己又不會動到那些源代碼，那么就向"使用者"列表或論壇提問。
如果確信自己的問題很特別，而且在"使用者" 列表或論壇中幾天都沒有回復，可以試試前往"開發者"列表或論壇發問。最好在張貼前最好先暗地里觀察幾天以了解那里的行事方式。
如果找不到一個項目的郵件列表，而只能查到項目維護者的電子郵件地址，盡管向他發信。但在自己的電子郵件中要陳述自己已經試過但沒有找到合適的郵件列表，也說明自己不反對將自己的郵件轉發給他人。
要注意的地方
使用有意義且描述明確的標題
在郵件列表、新聞群組或論壇中，大約 50 字以內的標題是抓住資深專家注意力的好機會。
一個好標題的范例是目標—差異式的描述，在目標部分指出哪一個或哪一組東西有問題，在差異部分則描述與期望的行為不一致的地方。
如：
蠢問題：救命啊！我的筆記本電腦不能正常顯示了！
聰明問題：X.org 6.8.1鼠標光標會變形，某牌顯卡MV1005芯片組。
更聰明的問題：X.org 6.8.1鼠標光標，在某牌顯卡MV1005芯片組環境下 - 會變形。
如果想在回復中提出問題，記得要修改內容標題，以表明自己是在問一個問題。
不要直接點擊回復來開始一個全新的討論串，因為有些郵件閱讀程序會折疊討論串，這將限制我們問題的觀眾。因此，寧可發一個全新的郵件。
使問題容易回復
在郵件客戶端設置回復地址。
在論壇，要求通過電子郵件回復是非常無禮的。如果只是想在有人回復討論串時得到電子郵件提醒，可以要求網頁論壇發送給自己。幾乎所有論壇都支持諸如追蹤此討論串、有回復時發送郵件提醒等功能。
用清晰、正確、精準并語法正確的語句
正確的拼寫、標點符號和大小寫是很重要的。可以使用非正式、俚語和幽默的語句，但它必須很準確，并且能表明自己是在思考和關注問題。
如果在使用非母語的論壇提問，可以犯點拼寫和語法上的小錯，但決不能在思考上馬虎。
除非知道回復者使用的語言，否則應使用英語書寫。英語非母語的我們，可以提示潛在回復者我們有語言困難，如：
English is not my native language; please excuse typing errors.
使用易于讀取且標準的文件格式發送問題
- 使用純文字而不是HTML。
- 使用MIME附件的前提是真正有內容（如源代碼）。
- 不要發送一段文字只是一行句子但自動換行后會變成多行的郵件。設想讀者是在 80 個字符寬的終端機上閱讀郵件，最好設置換行分割點小于 80 字。
- 對日志檔案拷貝等特殊文件不要設置固定寬度。數據應該原樣包含。
- 在英語論壇中，不要使用
Quoted-PrintableMIME 編碼發送消息。 - 絕對，永遠不要指望黑客們閱讀使用封閉格式編寫的文檔，像微軟公司的 Word 或 Excel 文件等。
- 從使用 Windows 的電腦發送電子郵件時，關閉
智能引號功能。 - 在論壇，不要濫用表情符號和
HTML功能（當它們提供時）。
精確地描述問題并言之有物
- 仔細、清楚地描述自己的問題或Bug的癥狀。
- 描述問題發生的環境（機器配置、操作系統、應用程序、以及相關的信息），提供經銷商的發行版和版本號（如：
Fedora Core 4、Slackware 9.1等）。 - 描述在提問前自己是怎樣去研究和理解這個問題的。
- 描述在提問前為確定問題而采取的診斷步驟。
- 描述最近做過什么可能相關的硬件或軟件變更。
- 盡可能的提供一個可以
重現這個問題的可控環境的方法。
話不在多而在精
提問時應該提供精確有內容的信息，但這并不是說簡單的把成堆的出錯代碼或者資料完全轉錄到提問中，盡量剪裁得越小越好。
別動輒聲稱找到Bug
在使用軟件中遇到問題，除非自己能提供解決問題的源代碼補丁，或者提供回歸測試來表明前一版本中行為不正確，否則不要動輒聲稱自己找到了 Bug。
提問時，即使自己私下非常確信已經發現一個真正的 Bug，最好寫得像是自己做錯了什么。如果真的有 Bug，會在回復中看到這點的。這樣做的話，如果真有 Bug，維護者就會向我們道歉，這比我們惹惱別人然后欠別人一個道歉要好一點。
低聲下氣不能代替功課
盡可能清楚地描述背景條件和自己的問題情況。這比低聲下氣更好地定位了自己的位置。
有時網頁論壇會設有專為新手提問的版面，如果真的認為自己遇到了初學者的問題，就去那里提問，但也別低聲下氣。
描述問題癥狀而不是自己的猜測
要確信自己原原本本告訴了黑客們問題的癥狀，而不是解釋和理論；讓黑客們來推測和診斷。如果認為陳述自己的猜測很重要，要清楚地說明這只是自己的猜測，并描述為什么它們不起作用。
按發生時間先后列出問題癥狀
問題發生前的一系列操作，往往就是對找出問題最有幫助的線索。因此，問題說明里應該包含自己的操作步驟，以及機器和軟件的反應，直到問題發生。在命令行處理的情況下，提供一段操作記錄（例如運行腳本工具所生成的），并引用相關的若干行（如 20 行）記錄會非常有幫助。
描述目標而不是過程
如果想弄清楚如何做某事（而不是報告一個 Bug），在開頭就描述自己的目標，然后才陳述重現自己所卡住的特定步驟。
別要求使用私人電郵回復
黑客們認為問題的解決過程應該公開、透明，此過程中如果更有經驗的人注意到不完整或者不當之處，最初的回復才能夠、也應該被糾正。同時，作為提供幫助者可以得到一些獎勵，獎勵就是他的能力和學識被其他同行看到。
讓回復者來決定是否私下回答。
清楚明確地表達自己地問題及需求
明確表述需要回答者做什么，界定一下自己地問題，使專家花在辨識問題和回答所需要付出的時間減到最少，就最有可能得到有用的答案。
詢問有關代碼地問題時
最有效描述程序問題的方法是提供最精簡的 Bug 展示測試用例，即就是問題的縮影，一小個剛好能展示出程序地異常行為地程序片段。
如果知道哪一行或哪一段代碼會造成異常的行為，復制下來并加入足夠重現這個狀況的代碼。如果無法將問題縮減到一個特定區塊，就復制一份代碼并移除不影響產生問題行為的部分。測試用例越小越好。
如果只是想讓別人幫忙審（Review）一下代碼，在信的開頭就要說出來，并且一定要提到自己認為哪一部分特別需要關注以及為什么。
別把自己家庭作業的問題貼上來
因為這些問題得由我們自己來搞定，我們會從中學到東西。可以要求別人給點提示，但別要求得到完整的解決方案。
如果懷疑自己碰到了一個家庭作業式的問題，但仍然無法解決，試試在使用者群組，論壇或（最后一招）在項目的使用者郵件列表或論壇中提問。
去掉無意義的提問句
避免用無意義的話結束提問，例如有人能幫我嗎？或者這有答案嗎？。
一般來說，避免用 是或否、對或錯、有或沒有類型的問句，除非想得到是或否類型的回答。
即使很緊急也不要在標題寫 緊急
這是我們自己的問題，不是回答者們的。
這樣的標題很可能會被回答者們刪除甚至會惹怒他們。
禮多人不怪，而且有時還很有幫助。
彬彬有禮，多用請和謝謝您的關注或謝謝你的關照，讓回答者們知道我們對他們花時間免費提供幫助心存感激。
問題解決后，加個簡短的補充說明
問題解決后，向所有幫助過自己的人發個說明，讓他們知道問題是怎樣解決的，并再一次向他們表示感謝。如果問題在新聞組或者郵件列表中引起了廣泛關注，應該在那里貼一個說明比較恰當。
最理想的方式是向最初提問的話題回復此消息，并在標題中包含已修正，已解決或其它同等含義的明顯標記。
如何解讀答案
RTFM 和 STFW
RTFM (Read The Fucking Manual)
STFW (Search The Fucking Web)
這兩句答復意味著：
- 我們需要的信息非常容易獲得
- 我們應該自己去搜索這些信息
如果還是搞不懂
如果看不懂回應，別立刻要求對方解釋。像以前試著自己解決問題時那樣（利用手冊，FAQ，網絡，身邊的高手），先試著去搞懂他的回應。如果真的需要對方解釋，記得要表現出自己已經從中學到了點什么。
處理無禮的回應
如果覺得自己被冒犯了，試著平靜地反應。如果有人真的做了出格的事，郵件列表、新聞群組或論壇中的前輩多半會招呼他。如果這沒有發生而我們自己卻發火了，那么我們發火對象的言語可能在黑客社區中看起來是正常的，而我們將被視為有錯的一方，這將傷害到我們獲取信息或幫助的機會。
如果得不到回答
如果得不到回復，最好不要簡單的重復張貼問題。還可以通過其他渠道獲得幫助，如網上及本地的使用者群組，或者向很多商業公司尋求幫助。
如何更好地回答問題
在學習過程中，我們一定會有許多問題需要別人幫助解答，隨著學習的深入，我們也會有幫別人解答問題的能力。推己及人，回答別人的問題時，我們應該：
- 態度和善一點。
- 對初犯者私下回復。
- 如果不確定，一定要說出來！
- 如果幫不了忙，也別妨礙他！
- 試探性地反問以引導出更多的細節。
- 如果決定回答，就請給出好的答案。
- 正面地回答問題！
- 幫助社區從問題中學習。
- 展現技巧而不是直接端出結果。
當面向人請教技術問題
當面向別人請教問題時，出了提問網站使用的一些技術點外，基本的方式方法是相通的。
當我們要當面請教別人問題時應該：
- 在請教前首先在網站和論壇上搜索自己的問題，能自己在依靠資料解決的問題就不要去麻煩別人。
- 請教問題前先精煉自己的問題，抓住重點，將實質問題資料，如故障的計算機，有問題的代碼塊等，提前準備好，節約別人的時間。
- 描述問題時，把自己為了解決這個問題所作的嘗試也說出來，無論有沒有效。
- 請教問題時注意禮貌用語。
- 語氣也不必太低聲下氣，弄得彼此都不自在。
- 表達感謝，無論對方有沒有解決問題。
- 如果對方沒有解決問題，再自己找到解決的辦法后，分享給對方。或者之后找到了更加好的解決辦法，也可以分享給對方，共同進步。
小黃鴨調試法
有時當我們像別人描述自己遇到的問題時，在傾訴中途我們就會恍然大悟，自己找到解決的辦法。但是別人并非一直有空，甚至有些人也不喜歡向別人傾訴，那么我們就可以向其他東西傾訴。
小黃鴨調試法是軟件在工程中使用的調試代碼方法之一。就是在程序的調試、糾錯或測試過程中，耐心地向小黃鴨解釋每一行程序地作用，以此來激發靈感。
在流傳的故事中，程序大師會向一只隨身攜帶的小黃鴨解釋代碼，因而這種方法被稱為小黃鴨調試法。
我們也可以選擇自己喜歡的任意物品。
