在提問之前：
在你準備要通過電子郵件、新聞群組或者聊天室提出技術問題前，請先做到以下事情：
- 嘗試在你準備提問的論壇的舊文章中搜索答案。
- 嘗試上網搜索以找到答案。
- 嘗試閱讀手冊以找到答案。
- 嘗試閱讀常見問題文件（FAQ）以找到答案。
- 嘗試自己檢查或試驗以找到答案
- 向你身邊的強者朋友打聽以找到答案。
- 如果你是程序開發(fā)者，請嘗試閱讀源代碼以找到答案。
在提問時
慎選提問的論壇
小心選擇你要提問的場合。如果你做了下述的事情，你很可能被忽略掉或者被看作失敗者：
- 在與主題不合的論壇上貼出你的問題
- 在探討進階技術問題的論壇張貼非常初級的問題；反之亦然
- 在太多的不同新聞群組上重復轉貼同樣的問題（cross-post）
- 向既非熟人也沒有義務解決你問題的人發(fā)送私人電郵
Stack Overflow
搜索，然后 在 Stack Exchange 問。
近年來，Stack Exchange community 社區(qū)已經成為回答技術及其他問題的主要渠道，尤其是那些開放源碼的項目。
因為 Google 索引是即時的，在看 Stack Exchange 之前先在 Google 搜索。有很高的機率某人已經問了一個類似的問題，而且 Stack Exchange 網站們往往會是搜索結果中最前面幾個。如果你在 Google 上沒有找到任何答案，你再到特定相關主題的網站去找。用標簽（Tag）搜索能讓你更縮小你的搜索結果。
網站和 IRC 論壇
本地的使用者群組（user group），或者你所用的 Linux 發(fā)行版本也許正在宣傳他們的網頁論壇或 IRC 頻道，并提供新手幫助（在一些非英語國家，新手論壇很可能還是郵件列表）， 這些地方是開始提問的好首選，特別是當你覺得遇到的也許只是相對簡單或者很普通的問題時。有廣告贊助的 IRC 頻道是公開歡迎提問的地方，通常可以即時得到回應。
事實上，如果程序出的問題只發(fā)生在特定 Linux 發(fā)行版提供的版本（這很常見），最好先去該發(fā)行版的論壇或郵件列表中提問，再到程序本身的論壇或郵件列表提問。（否則）該項目的黑客可能僅僅回復 "用我們的版本"。
在任何論壇發(fā)文以前，先確認一下有沒有搜索功能。如果有，就試著搜索一下問題的幾個關鍵詞，也許這會有幫助。如果在此之前你已做過通用的網頁搜索（你也該這樣做），還是再搜索一下論壇，搜索引擎有可能沒來得及索引此論壇的全部內容。
通過論壇或 IRC 頻道來提供使用者支持服務有增長的趨勢，電子郵件則大多為項目開發(fā)者間的交流而保留。所以最好先在論壇或 IRC 中尋求與該項目相關的協助。
在使用 IRC 的時候，首先最好不要發(fā)布很長的問題描述，有些人稱之為頻道洪水。最好通過一句話的問題描述來開始聊天。
第二步，使用項目郵件列表
當某個項目提供開發(fā)者郵件列表時，要向列表而不是其中的個別成員提問，即使你確信他能最好地回答你的問題。查一查項目的文件和首頁，找到項目的郵件列表并使用它。有幾個很好的理由支持我們采用這種辦法：
- 任何好到需要向個別開發(fā)者提出的問題，也將對整個項目群組有益。反之，如果你認為自己的問題對整個項目群組來說太愚蠢，也不能成為騷擾個別開發(fā)者的理由。
- 向列表提問可以分散開發(fā)者的負擔，個別開發(fā)者（尤其是項目領導人）也許太忙以至于沒法回答你的問題。
- 大多數郵件列表都會被存檔，那些被存檔的內容將被搜索引擎索引。如果你向列表提問并得到解答，將來其它人可以通過網頁搜索找到你的問題和答案，也就不用再次發(fā)問了。
- 如果某些問題經常被問到，開發(fā)者可以利用此信息來改進說明文件或軟件本身，以使其更清楚。如果只是私下提問，就沒有人能看到最常見問題的完整場景。
使用有意義且描述明確的標題
在郵件列表、新聞群組或論壇中，大約 50 字以內的標題是抓住資深專家注意力的好機會。別用喋喋不休的幫幫忙、跪求、急（更別說救命啊！！！！這樣讓人反感的話，用這種標題會被條件反射式地忽略）來浪費這個機會。不要妄想用你的痛苦程度來打動我們，而應該是在這點空間中使用極簡單扼要的描述方式來提出問題。
一個好標題范例是目標 -- 差異式的描述，許多技術支持組織就是這樣做的。在目標部分指出是哪一個或哪一組東西有問題，在差異部分則描述與期望的行為不一致的地方。
蠢問題：救命啊！我的筆記本電腦不能正常顯示了！
聰明問題：X.org 6.8.1 的鼠標光標會變形，某牌顯卡 MV1005 芯片組。
更聰明問題：X.org 6.8.1 的鼠標光標，在某牌顯卡 MV1005 芯片組環(huán)境下 - 會變形。
使問題容易回復
以請將你的回復寄到……來結束你的問題多半會使你得不到回答。如果你覺得花幾秒鐘在郵件客戶端設置一下回復地址都麻煩，我們也覺得花幾秒鐘思考你的問題更麻煩。如果你的郵件程序不支持這樣做，換個好點的；如果是操作系統(tǒng)不支持這種郵件程序，也換個好點的。
在論壇，要求通過電子郵件回復是非常無禮的，除非你相信回復的信息可能比較敏感（而且有人會為了某些未知的原因，只讓你而不是整個論壇知道答案）。如果你只是想在有人回復討論串時得到電子郵件提醒，可以要求網頁論壇發(fā)送給你。幾乎所有論壇都支持諸如追蹤此討論串、有回復時發(fā)送郵件提醒等功能。
用清晰、正確、精準并語法正確的語句
我們從經驗中發(fā)現，粗心的提問者通常也會粗心的寫程序與思考（我敢打包票）。回答粗心大意者的問題很不值得，我們寧愿把時間耗在別處。
精確的描述問題并言之有物
仔細、清楚地描述你的問題或 Bug 的癥狀。
描述問題發(fā)生的環(huán)境（機器配置、操作系統(tǒng)、應用程序、以及相關的信息），提供經銷商的發(fā)行版和版本號（如：Fedora Core 4、Slackware 9.1等）。
描述在提問前你是怎樣去研究和理解這個問題的。
描述在提問前為確定問題而采取的診斷步驟。
描述最近做過什么可能相關的硬件或軟件變更。
盡可能的提供一個可以重現這個問題的可控環(huán)境的方法。
話不在多而在精
你需要提供精確有內容的信息。這并不是要求你簡單的把成堆的出錯代碼或者資料完全轉錄到你的提問中。如果你有龐大而復雜的測試樣例能重現程序掛掉的情境，盡量將它剪裁得越小越好。
這樣做的用處至少有三點。 第一，表現出你為簡化問題付出了努力，這可以使你得到回答的機會增加； 第二，簡化問題使你更有可能得到有用的答案； 第三，在精煉你的 bug 報告的過程中，你很可能就自己找到了解決方法或權宜之計。
別動輒聲稱找到 Bug
當你在使用軟件中遇到問題，除非你非常、非常的有根據，不要動輒聲稱找到了 Bug。提示：除非你能提供解決問題的源代碼補丁，或者提供回歸測試來表明前一版本中行為不正確，否則你都多半不夠完全確信。這同樣適用在網頁和文件，如果你（聲稱）發(fā)現了文件的Bug，你應該能提供相應位置的修正或替代文件。
請記得，還有許多其它使用者沒遇到你發(fā)現的問題，否則你在閱讀文件或搜索網頁時就應該發(fā)現了（你在抱怨前已經做了這些，是吧？）。這也意味著很有可能是你弄錯了而不是軟件本身有問題。
編寫軟件的人總是非常辛苦地使它盡可能完美。如果你聲稱找到了 Bug，也就是在質疑他們的能力，即使你是對的，也有可能會冒犯到其中某部分人。當你在標題中嚷嚷著有Bug時，這尤其嚴重。
提問時，即使你私下非常確信已經發(fā)現一個真正的 Bug，最好寫得像是你做錯了什么。如果真的有 Bug，你會在回復中看到這點。這樣做的話，如果真有 Bug，維護者就會向你道歉，這總比你惹惱別人然后欠別人一個道歉要好一點。
低聲下氣不能代替你的功課
有些人明白他們不該粗魯或傲慢的提問并要求得到答復，但他們選擇另一個極端 -- 低聲下氣：我知道我只是個可悲的新手，一個擼瑟，但...。這既使人困擾，也沒有用，尤其是伴隨著與實際問題含糊不清的描述時更令人反感。
別用原始靈長類動物的把戲來浪費你我的時間。取而代之的是，盡可能清楚地描述背景條件和你的問題情況。這比低聲下氣更好地定位了你的位置。
有時網頁論壇會設有專為新手提問的版面，如果你真的認為遇到了初學者的問題，到那去就是了，但一樣別那么低聲下氣。
描述問題癥狀而非你的猜測
告訴黑客們你認為問題是怎樣造成的并沒什么幫助。（如果你的推斷如此有效，還用向別人求助嗎？），因此要確信你原原本本告訴了他們問題的癥狀，而不是你的解釋和理論；讓黑客們來推測和診斷。如果你認為陳述自己的猜測很重要，清楚地說明這只是你的猜測，并描述為什么它們不起作用。
