精確的描述問題并言之有物

仔細、清楚地描述你的問題或 Bug 的癥狀。

描述問題發(fā)生的環(huán)境（機器配置搂抒、操作系統(tǒng)、應用程序朝群、以及相關的信息）燕耿，提供經(jīng)銷商的發(fā)行版和版本號（如：Fedora Core 4、Slackware 9.1等）姜胖。

描述在提問前你是怎樣去研究和理解這個問題的誉帅。

描述在提問前為確定問題而采取的診斷步驟。

描述最近做過什么可能相關的硬件或軟件變更右莱。

盡可能的提供一個可以重現(xiàn)這個問題的可控環(huán)境的方法蚜锨。

盡量去揣測一個黑客會怎樣反問你，在你提問之前預先將黑客們可能遇到的問題回答一遍慢蜓。

以上幾點中亚再，當你報告的是你認為可能在代碼中的問題時，給黑客一個可以重現(xiàn)你的問題的環(huán)境尤其重要晨抡。當你這么做時氛悬，你得到有效的回答的機會和速度都會大大的提升则剃。

Simon Tatham 寫過一篇名為《如何有效的報告 Bug》的出色文章。強力推薦你也讀一讀如捅。

話不在多而在精

你需要提供精確有內(nèi)容的信息棍现。這并不是要求你簡單的把成堆的出錯代碼或者資料完全轉(zhuǎn)錄到你的提問中。如果你有龐大而復雜的測試樣例能重現(xiàn)程序掛掉的情境镜遣，盡量將它剪裁得越小越好己肮。

這樣做的用處至少有三點。 第一悲关，表現(xiàn)出你為簡化問題付出了努力谎僻，這可以使你得到回答的機會增加； 第二寓辱，簡化問題使你更有可能得到有用的答案艘绍； 第三，在精煉你的 bug 報告的過程中讶舰，你很可能就自己找到了解決方法或權宜之計鞍盗。

別動輒聲稱找到 Bug

當你在使用軟件中遇到問題需了，除非你非常跳昼、非常的有根據(jù)，不要動輒聲稱找到了 Bug肋乍。提示：除非你能提供解決問題的源代碼補丁鹅颊，或者提供回歸測試來表明前一版本中行為不正確，否則你都多半不夠完全確信墓造。這同樣適用在網(wǎng)頁和文件堪伍，如果你（聲稱）發(fā)現(xiàn)了文件的Bug，你應該能提供相應位置的修正或替代文件觅闽。

請記得帝雇，還有許多其它使用者沒遇到你發(fā)現(xiàn)的問題，否則你在閱讀文件或搜索網(wǎng)頁時就應該發(fā)現(xiàn)了（你在抱怨前已經(jīng)做了這些蛉拙，是吧尸闸？）。這也意味著很有可能是你弄錯了而不是軟件本身有問題孕锄。

編寫軟件的人總是非常辛苦地使它盡可能完美吮廉。如果你聲稱找到了 Bug，也就是在質(zhì)疑他們的能力畸肆，即使你是對的宦芦，也有可能會冒犯到其中某部分人。當你在標題中嚷嚷著有Bug時轴脐，這尤其嚴重调卑。

提問時抡砂，即使你私下非常確信已經(jīng)發(fā)現(xiàn)一個真正的 Bug，最好寫得像是你做錯了什么恬涧。如果真的有 Bug舀患，你會在回復中看到這點。這樣做的話气破，如果真有 Bug聊浅，維護者就會向你道歉，這總比你惹惱別人然后欠別人一個道歉要好一點现使。

低聲下氣不能代替你的功課

有些人明白他們不該粗魯或傲慢的提問并要求得到答復低匙，但他們選擇另一個極端 -- 低聲下氣：我知道我只是個可悲的新手，一個擼瑟碳锈，但...顽冶。這既使人困擾，也沒有用售碳，尤其是伴隨著與實際問題含糊不清的描述時更令人反感强重。

別用原始靈長類動物的把戲來浪費你我的時間。取而代之的是贸人，盡可能清楚地描述背景條件和你的問題情況间景。這比低聲下氣更好地定位了你的位置。

有時網(wǎng)頁論壇會設有專為新手提問的版面艺智，如果你真的認為遇到了初學者的問題倘要，到那去就是了，但一樣別那么低聲下氣十拣。

描述問題癥狀而非你的猜測

告訴黑客們你認為問題是怎樣造成的并沒什么幫助封拧。（如果你的推斷如此有效，還用向別人求助嗎夭问？）泽西，因此要確信你原原本本告訴了他們問題的癥狀，而不是你的解釋和理論缰趋；讓黑客們來推測和診斷捧杉。如果你認為陳述自己的猜測很重要，清楚地說明這只是你的猜測埠胖，并描述為什么它們不起作用糠溜。

蠢問題

我在編譯內(nèi)核時接連遇到 SIG11 錯誤， 我懷疑某條飛線搭在主板的走線上了直撤，這種情況應該怎樣檢查最好非竿？

聰明問題

我的組裝電腦是 FIC-PA2007 主機板搭載 AMD K6/233 CPU（威盛 Apollo VP2 芯片組）， 256MB Corsair PC133 SDRAM 內(nèi)存谋竖，在編譯內(nèi)核時红柱，從開機 20 分鐘以后就頻頻產(chǎn)生 SIG11 錯誤承匣， 但是在頭 20 分鐘內(nèi)從沒發(fā)生過相同的問題。重新啟動也沒有用锤悄，但是關機一晚上就又能工作 20 分鐘韧骗。 所有內(nèi)存都換過了，沒有效果零聚。相關部分的標準編譯記錄如下…袍暴。 由于以上這點似乎讓許多人覺得難以配合，這里有句話可以提醒你：所有的診斷專家都來自密蘇里州隶症。 美國國務院的官方座右銘則是：讓我看看（出自國會議員 Willard D. Vandiver 在 1899 年時的講話：我來自一個出產(chǎn)玉米政模，棉花，牛蒡和民主黨人的國家蚂会，滔滔雄辯既不能說服我淋样，也不會讓我滿意。我來自密蘇里州胁住，你必須讓我看看趁猴。） 針對診斷者而言，這并不是一種懷疑彪见，而只是一種真實而有用的需求儡司，以便讓他們看到的是與你看到的原始證據(jù)盡可能一致的東西，而不是你的猜測與歸納的結論企巢。所以枫慷，大方的展示給我們看吧！

按發(fā)生時間先后列出問題癥狀

問題發(fā)生前的一系列操作浪规，往往就是對找出問題最有幫助的線索。因此探孝，你的說明里應該包含你的操作步驟笋婿，以及機器和軟件的反應，直到問題發(fā)生顿颅。在命令行處理的情況下缸濒，提供一段操作記錄（例如運行腳本工具所生成的），并引用相關的若干行（如 20 行）記錄會非常有幫助粱腻。

如果掛掉的程序有診斷選項（如 -v 的詳述開關）庇配，試著選擇這些能在記錄中增加調(diào)試信息的選項。記住绍些，多不等于好捞慌。試著選取適當?shù)恼{(diào)試級別以便提供有用的信息而不是讓讀者淹沒在垃圾中。

如果你的說明很長（如超過四個段落）柬批，在開頭簡述問題啸澡，接下來再按時間順序詳述會有所幫助袖订。這樣黑客們在讀你的記錄時就知道該注意哪些內(nèi)容了。

描述目標而不是過程

如果你想弄清楚如何做某事（而不是報告一個 Bug）嗅虏，在開頭就描述你的目標洛姑，然后才陳述重現(xiàn)你所卡住的特定步驟。

經(jīng)常尋求技術幫助的人在心中有個更高層次的目標皮服，而他們在自以為能達到目標的特定道路上被卡住了楞艾，然后跑來問該怎么走，但沒有意識到這條路本身就有問題龄广。結果要費很大的勁才能搞定产徊。