技術問題的解答很大程度上取決於你提問的方式與解決此問題的難度
嘗試在你準備提問論壇的歷史文件中搜尋答案
嘗試搜尋網際網路以找到答案
嘗試閱讀手冊以找到答案
嘗試閱讀「常見問題文件」（faq）以找到答案
嘗試自己檢查或試驗以找到答案
嘗試請教懂行的朋友以找到答案
如果你是程式設計師，嘗試閱讀源**以找到答案
做了上述事情，這將有助於建立你不是寄生蟲與浪費別人時間的印象。最好再表述你從中* 學到的東西 *，我們喜歡回答那些表現出能從答案中學習的人。
認真地思考，準備好你的問題。輕率的提問只能得到輕率的回答，或者壓根沒有。在提問時，你越是表現出在此前做過思考與努力去解決自己的問題，你越有可能得到真正的幫助。
另一方面，表明你有能力也樂意參與問題的解決是個很好的開端。「有沒有人能指個方向？」，我這還差點什麼？」，「我應該查哪個**？」，通常要比 「請給出我可以用的完整步驟」更容易得到回覆，因為你表明了只要有人能指個方向，你就很樂意完成剩下的過程。
要對在哪提問留心，如果你做了下述事情，多半會被一筆勾銷或被看成「失敗者」：
告訴黑客是什麼導致了問題是沒用的（如果你的診斷理論是了不起的東西，你還會向別人諮詢求助嗎？）。所以，確保只是告訴他們問題的原始症狀，而不是你的解釋和理論，讓他們來解釋和診斷。如果你認為陳述自己的猜測很重要，應清楚地說明這只是你的猜測並描述為什麼它們不起作用。
如果你想弄清楚如何做某事（而不是報告乙個臭蟲），在開頭就描述你的目標，然後才陳述遇到問題的特定步驟。
經常出現這種情況，尋求技術幫助的人在腦袋裡有個更高層次的目標，他們在自以為能達到目標的特定道路上被卡住了，然後跑來問該怎麼走，但沒有意識到這條路本身有問題，結果要費很大的勁才能通過。
漫無邊際的問題通常也被視為沒有明確限制的時間無底洞。最有可能給你有用答案的人通常也是最忙的人（假如只是因為他們承擔了太多工作的話），這些人對於沒有止境的時間無底洞極其敏感，所以他們也傾向於討厭那些漫無邊際的問題。
如果你明確了想讓回覆者做的事（如指點方向、傳送**、檢查補丁或其它），你更有可能得到有用的回覆。（因為）這樣可以讓他們集中精力並間接地設定了他們為幫助你需要花費的時間和精力上限，這很好。
別要求他人給你出問題的**排錯而不提及應該從何入手。張貼幾百行的**，然後說一聲「它不能執行」會讓你得不到理睬。只貼幾十行**，然後說一句「在第七行以後，本應該顯示，但實際出現的是」非常有可能讓你得到回覆。
最精確描述**問題的方法是提供乙個能展示問題的最小測試樣例。什麼是最小測試樣例？它是對問題的展現，只需要剛好能夠重現非預期行為的**即可。如何生成乙個最小測試樣例？如果你知道哪一行或哪一段**會產生問題，將其複製並提供剛好夠用的外圍支撐**以構成乙個完整的樣例（夠用是指原始碼剛好能被編譯器、直譯器或任何處理它的程式所接受）。如果你不能將問題縮小到特定的段落，複製原始碼並去除那些與問題無關的**段。你能提供的最小測試樣例越小越好
這是你的問題，不要我們的。宣稱「緊急」極有可能事與願違：大多數黑客會直接刪除這種訊息，他們認為這是無禮和自私地企圖得到即時與特殊的關照。而且「緊急」或其它有類似含義的主題有可能觸發垃圾過濾規則，潛在的回覆者可能永遠看不到你的問題！
問題解決後向所有幫助過的人追加一條訊息，讓他們知道問題是如何解決的並再次感謝。如果問題在郵件列表或新聞組中受到廣泛關注，在那裡追加此訊息比較恰當。
下面是些典型的愚蠢問題和黑客不回答它們時的想法。
如果得不到回答，請不要認為我們不想幫你，有時只是因為被問到的小組成員的確不知道答案。沒有回覆不等於不被理睬，當然必須承認從外面很難看出兩者的差別。
一般而言，直接將問題再張貼一次不好，這會被視為毫無意義的騷擾。耐心一點，知道你問題答案的人可能生活在不同的時區，有可能正在睡覺，也有可能你的問題一開始就沒有組織好。
還有其它資源可以尋求幫助，通常是在一些面向新手的資源中。
還有眾多大小商業公司提供簽約支援服務，別因為要付點錢才有支援就感到沮喪！畢竟，如果你車子的汽缸墊燒了，你多半還得花錢找個修理店把它弄好。即使軟體沒花你一分錢，你總不能指望服務支援都是免費的。
象 linux 這樣流行的軟體，每個開發者至少有一萬個以上的使用者，乙個人不可能應付這麼多使用者的服務要求。記住，即使你必須付費才能得到支援，也比你還得額外花錢買軟體要少得多（而且對封閉源**軟體的服務支援與開源軟體相比通常還要貴一點，也要差一點）。
態度和善一點。問題帶來的壓力常使人顯得無禮或愚蠢，其實並不是這樣。
對初犯者私下回覆。 對那些坦誠犯錯之人沒有必要當眾羞辱，乙個真正的新手也許連怎麼搜尋或在哪找 faq 都不知道。
如果你不確定，一定要說出來！ 乙個聽起來權威的錯誤回覆比沒有還要糟，別因為聽起來象個專家好玩就給別人亂指路。要謙虛和誠實，給提問者與同行都樹個好榜樣。
如果幫不了忙，別妨礙。不要在具體步驟上開玩笑，那樣也許會毀了使用者的安裝──有些可憐的呆瓜會把它當成真的指令。
探索性的反問以引出更多的細節。如果你做得好，提問者可以學到點東西──你也可以。試試將很差的問題轉變成好問題，別忘了我們都曾是新手。
如果你決意回答，給出好的答案。 當別人正在用錯誤的工具或方法時別建議笨拙的權宜之計，應推薦更好的工具，重新組織問題。
請回答真正的問題！如果提問者已經做了自己該做的研究，並且說明嘗試過x，y，z，a，b與c都沒有得到想要的結果，那麼回覆「試試a或b」 或者給出乙個內容為 「試一下x，y，z，a，b或c」的鏈結將極其無益！
幫助你的社群從中學習。當回覆乙個好問題時，問問自己 「如何修改相關檔案或 faq 文件以免再次解答同樣的問題？」，接著再向文件維護者發乙份補丁。
如果你是在研究一番後才做出的回答，展現你的技巧而不是直接端出結果。畢竟「授人以魚，不如授人以漁」。
提問的智慧型
題前注 本文轉截自程式設計論壇 在論壇中，當提出乙個問題時，你能得到怎樣的回答？這取決於挖出答案的難度，同樣取決於你提問的方法。首先你應該明白 大俠們不想掩飾一種鄙視 某些人不願思考，或者在發問前不去完成他們應該做的事。這種人只會 時間，他們只願索取，從不付出，無端消耗大家的時間，而大俠們本可以把時...
提問的智慧型
如果您經常有問題需要問 如果您的問題經常無人解答 如果您的提問貼裡經常有人和您叫板 那麼 您最適合閱讀一下 提問的智慧型 這篇文章 如果您沒有足夠時間來閱讀那些冗長的文字 那麼 這幅圖可能最適合您了 希望大家提問之前先看下這個 也許就可以從中找到答案 提問的時候最好把問題表訴的清楚些 別總是讓人回帖...
提問的智慧型
1.先在google,論壇，metalink,online document 裡搜尋.在提問前，應該先自己嘗試去解決問題。一些功能和語法，可以直接在online document中查到。在alert log裡發現了報錯資訊或者在執行時發現了報錯資訊，那麼，最簡單的做法就是將錯誤資訊或者錯誤號先在go...