(轉載)提問的智慧(3.2 版)

edited 十月 2013 in 閒聊
出處: http://www.hkpug.net/node/48

[size=large]作者[/size]:

Eric Steven Raymond

Thyrsus Enterprises

<[email]mailto:[email protected][/email]>

Rick Moen

<[email]mailto:[email protected][/email]>

版權 © 2001, 2006 Eric S. Raymond, Rick Moen


[size=large]修訂歷史[/size]

修訂版 3.2, 2006 年 1 月 10 日, esr

加入 Rick Moen 的修定

修訂版 3.1, 2004 年 10 月 28 日, esr

文檔 ‘Google 是你的朋友!’

修訂版 3.0, 2004 年 2 月 2 日, esr

主要增加網頁論壇應有的禮節內容

原文:How To Ask Questions The Smart Way

翻譯(3.2 版):阿恆 <[email protected]>

時間:2006 年 6 月 12 日

翻譯(3.1 版):王剛 <[email protected]>

時間:2004 年 11 月 2 日

[size=large]譯文[/size]

譯文:印度尼西亞語 巴西葡萄牙語 捷克語 丹麥語 愛沙尼亞語 芬蘭語 法語 德語 希伯來語 匈牙利語 義大利語 日語 波蘭語 葡萄牙語 俄語 塞爾維亞語 西班牙語 瑞典語 土耳其語. 如果你想複製、鏡像、翻譯或引用本文,請參閱我的複製須知.

[size=large]棄權申明[/size]

許多項目的網站在如何取得幫助的部分鏈結了本文,這沒有關係,也是我們想要的。但如果你是一個項目網站的網管,請在鏈結附近顯著位置注明 我們是你的項目的服務部!

我們已經遭受沒有此說明帶來的痛苦,不斷受到一些白癡的騷擾。他們認為既然我們發表了此文,那麼我們就有責任解決世上所有技術問題!

如果你因為需要幫助閱讀了本文,然後帶著可以直接從作者那裡取得幫助的印像離開,你就不幸成了那些白癡之一。不要向 我們
提問,我們不會理睬的。 我們在這只是給你說明如何從那些真正懂得你軟硬體問題的人那裏取得幫助的方法,99% 的時間我們不會是那些人。除非你 確信 此文作者是你遇到問題方面的專家,請不要打擾,這樣大家都更開心一點。

[size=large]引言[/size]

黑客 的世界,你所提技術問題的回答很大程度上取決於你提問的方式與解決此問題的難度,本文將教你如何提問才更有可能得到滿意的答覆。

開根源程式的使用已經很廣,你通常可以從其他更有經驗的用戶得到跟黑客那裡同樣好回答。這是好事,他們一般對新手常有的毛病更容忍一點。然而,使用我們介紹的方法像對待黑客那樣對待這些有經驗的用戶,通常能最有效地得到問題的解答。

第一件需要明白的事是黑客喜歡難題和激發思考的好問題。假如不是這樣,我們也不會寫本文了。如果你能提出一個有趣的問題讓我們咀嚼玩味,我們會感激你。好的問題是種激勵與禮物,幫助我們發展認知,揭示沒有注意或想過的問題。在黑客中,「好問題!」是非常真摯的贊許。

除此而外,黑客有遇到簡單問題就表現出敵視或傲慢的名聲,有時候我們看起來還對新手和愚蠢的傢伙有條件反射式的無禮,但並不真正是這樣。

我們只是毫無歉意地敵視那些提問前不願思考、不做自己該做之事的人。這種人就像時間無底洞──他們只知道獲取,不願意付出,他們浪費了時間,這些時間本可用於其他更值得回答的人和更有趣的問題。我們將這種人叫做「失敗者 (loser)」(由於歷史原因,我們有時將「loser」拼為「lusers」)。

我們注意到許多人只想用我們寫的軟體,他們對學習技術細節沒有興趣。對大多數人而言,電腦只是種工具,是種達到目的的手段。他們要生活並且有更要 緊的事要做,我們承認這點,也從不指望每個人都對這些讓我們著迷的技術問題感興趣。不過,我們回答問題的風格是為了適應那些 真正 對此有興趣並願意主動參與問題解決的人,這一點不會變,也不該變。如果這都變了,我們就會在自己能做得最好的事情上不再那麼犀利。

我們(多數)是自願者,從自己繁忙的生活中抽時間來回答問題,有時會力不從心。因此,我們會無情地濾除問題,特別是那些看起來像是失敗者的,以便更有效地把回答問題的時間留給那些「勝利者」。

如果你認為這種態度令人憎惡、以施惠者自居或傲慢自大,請檢查你的假設,我們並未要求你屈服──事實上,假如你做了該做的努力使之成為可能,我們中的大多數人非常樂意平等地與你交流並歡迎你接納我們的文化。試圖去幫助那些不願自救的人對我們簡直沒有效率,不懂沒有關係,但愚蠢地行事不行。

所以,你不必在技術上很在行才能吸引我們的注意,但你 必須 表現出能引導你在行的姿態──機敏、思考、善於觀察、樂於主動參與問題的解決。如果你做不到這些使你與眾不同的事情,我們建議你付錢跟別人簽商業服務合同,而不是要求黑客無償幫助。

如果你決定向我們求助,你不會想成為一名失敗者,你也不想被看成一個失敗者。得到快速有效回覆的最好方法是使提問者看起來像個聰明、自信的人,並且暗示只是碰巧在某一特別問題上需要幫助。

(歡迎對本文指正,可以將建議發至 [email]mailto:[email protected][/email] 或 [email]mailto:[email protected][/email]。請注意,本文不想成為一般性的 網路禮儀 指南,我一般會拒絕那些與引出技術論壇中有用的回覆不特別相關的建議。)

[size=large]提問前[/size]

在通過電子郵件、新聞組或網頁論壇提技術問題之前,做以下事情:

1. 嘗試搜索互聯網以找到答案
2. 嘗試閱讀手冊以找到答案
3. 嘗試閱讀 FAQ(常見問題)文檔以找到答案
4. 嘗試自己檢查或試驗以找到答案
5. 嘗試請教懂行的朋友以找到答案
6. 如果你是程式師,嘗試閱讀原始碼以找到答案

提問時,請先表述你已經做了上述事情,這將有助於建立你不是寄生蟲與浪費別人時間的印像。最好再表述你從中 學到的東西,我們喜歡回答那些表現出能從答案中學習的人。

使用某些策略,比如用 Google 搜索你遇到的錯誤提示(既搜索網頁也查查討論組),可能就直接找到了解決問題的文檔或郵件列表線索。即使沒有結果,在電子郵件或新聞組張貼問題時提一句「我在 Google 中查過下列句子但沒有找到什麼有用的東西」也是件好事。

準備你的問題,徹底地思考。輕率的提問只能得到輕率的回答,或者壓根沒有。在提問時,越是表現出做過思考並在努力解決問題,你越有可能得到實際幫助。

注意別提錯問題。如果提問基於錯誤的假設,某黑客多半會一邊想「愚蠢的問題……」,一邊用按照問題字面的無用答案回覆你,並且希望這種只是得到字面回答而不是真正所需的經歷給你一個教訓。

永遠不要假設你 有資格 得到解答。你沒有這種資格,畢竟你沒有為此服務付費。如果你能夠提出有內容、有趣和激勵思考的問題──那種毫無疑問能夠向社區貢獻經驗而不僅僅是消極地要求從別人那獲取知識的問題,你將「掙到」答案。

另一方面,表明你能夠也樂意參與問題的解決是個很好的開端。「有沒有人能指個方向?」、「我這還漏點什麼?」、「我應該查哪些網站?」通常要比「請給出我可以用的完整步驟」更容易得到回覆,因為你表明了只要有人能指個方向你就很樂意完成剩下的過程。

[size=large]提問時[/size]

仔細挑選論壇

要對在哪兒提問留心,如果你做了下述事情,多半會被一筆勾銷或被看成「失敗者」:

* 張貼與論壇主題完全無關的問題
* 在面向高級技術問題的論壇上提非常初淺的問題,或者反之。
* 在太多不同的新聞組同時交叉張貼
* 給既非熟人也沒有義務解決你問題的個人張貼你私人的電子郵件

為保護通信的渠道不被無關的東西淹沒,黑客會除掉那些沒有找對地方的問題,你不會想有這種經歷的。

所以第一步是找對論壇,Google 與其他搜索引擎還是你的朋友,可以用它們搜索與你遇到困難的軟硬體問題最相關的項目的網站。那裏通常都有項目的 FAQ 列表、郵件列表及其文檔的鏈結。如果你的努力(包括閱讀 FAQ)都沒有結果,這些郵件列表就是最後能取得幫助的地方。項目的網站也許還有報告臭蟲的流程或鏈結,如果是這樣,去看看。

向陌生的人或論壇發送郵件極有可能是在冒險。譬如,不要假設一個富含資訊的網頁的編寫者想充當你的免費顧問,不要對你 的問題是否會受到歡迎做樂觀的估計──如果你不確定,向別處發或者根本別發。

在選擇網頁論壇、新聞組或郵件列表時,不要太相信名字,先看看 FAQ 或者許可以明確你的問題是否與其主題相關。張貼前先翻翻已有的帖子可以幫助你感受一下那裏行事的方式。事實上,張貼之前在新聞組或郵件列表中搜索與你問題相關的關鍵字是個很好的主意,也許就找到答案了。即使沒有,也能幫助你整理出更好的問題。

別像機關槍似的一次性「掃射」所有的幫助通道,那就像大嚷大叫並使人不快。一個一個地來。

弄清楚你的主題!最典型的錯誤之一是在某種致立於跨 Unix 和 Windows 平台的語言、庫或工具的論壇中提關於作業系統程式介面的問題。如果你不 明白為什麼這是大錯,最好在搞清楚概念前什麼也別問。

一般來說,在仔細挑選的公共論壇中提問比在私有論壇中提同樣的問題更容易得到有用的回覆。有許多理由支持這一點,一是看潛在的回覆者有多少,二是看論壇的參與者有多少,黑客更願回答能啟發多數人的問題。

可以理解,老練的黑客和一些流行軟體的作者正在收到超出他們承受能力的不當訊息。就像那根多出來就可以壓垮駱駝背的稻草一樣,你的加入也可能會使情況走向極端──已經好幾次了,一些流行軟體的作者退出了對其軟體的支援,因為伴隨而來的湧向其私人郵箱的大量無用消息變得無法忍受。

面向新手的網頁論壇和 IRC 通常響應最快

本地的用戶組織或者你所用的 Linux 發行版也許正在宣傳新手取得幫助的網頁論壇或 IRC(互聯網中繼聊天)(在非英語國家,新手論壇很可能還是郵件列表),這些地方是開始提問的好去處,尤其是當你覺得遇到的也許只是相對簡單或者一般的問題時。經過宣傳的 IRC 通道是個公開邀請提問的地方,通常可以得到即時的回覆。

事實上,如果出問題的程式來自某發行版(這很常見),在程式的項目論壇或列表提問前最好先在發行版的論壇或列表中問問,否則項目的黑客可能僅僅回覆「用 我們的 原始碼」。

在任何網頁論壇張貼之前,先看看是否有搜索功能。如果有,就試試用問題的幾個關鍵字搜索一下,也許就有幫助。如果在此之前你已做過全面的網頁搜索(你應該這樣做),還是再搜索一下論壇,搜索引擎最近也許還沒有索引此論壇的全部內容。

通過網頁論壇或 IRC 頻道提供項目的用戶支援有增長的趨勢,電子郵件交流則更多地為項目開發保留。先在網頁論壇或 IRC 中尋求與項目相關的幫助。

第二步,使用項目郵件列表

當某項目存在開發者郵件列表時,即使你確信誰能最好地回答問題,也要向列表而不是其中的個體提問。檢查項目的文檔和主頁,找到項目的郵件列表並使用它。採用這種策略有幾個好理由:

* 任何向單個開發者提的足夠好的問題也將對整個項目組有益。相反,如果你認為自己的問題對整個項目組來說太愚蠢,這也不能成為打擾單個開發者的理由。

* 向列表提問可以平衡開發者的負擔,單個開發者(特別是項目領導)也許太忙以至於無法回答你的問題。

* 大多數郵件列表有歷史文檔並被搜索引擎索引,其他人可以通過網頁搜索找到你的問題和答案而不用再次在郵件列表中發問。

* 如果某些問題經常被問到,開發者可以利用此資訊改進文檔或軟體本身以使其更清楚。如果只是私下提問,就沒有人能看到最常見問題的完整場景。

如果一個項目既有「用戶」也有「開發者」(或「黑客」)郵件列表或網頁論壇,而你又不擺弄那些原始碼,向「用戶」列表或論壇提問。不要假設自己在開發者列表中會受歡迎,那些人多半會遭受你的噪音干擾。

然而,如果你 確信 你的問題不一般,而且在「用戶」列表或論壇中幾天都沒有回覆,可以試試「開發者」列表或論壇。建議你在張貼前最好先暗暗地觀察幾天以瞭解那裡的行事方式(事實上這是參與任何私有或半私有列表的好主意)。

如果你找不到一個項目的郵件列表,而只能查到項目維護者的位址,只管向其發信。即便在這種情況下,也別假設項目郵件列表不存在。在你的電子郵件中陳述你已經試過但沒有找到合適的郵件列表,也提及你不反對將自己的郵件轉發給他人(許多人認為,即使沒什麼秘密,私人電子郵件也不應該被公開。通過允許將你的電子郵件轉發他人給了相應人員處置你郵件的選擇)。

使用明確而有意義的主題

在郵件列表、新聞組或網頁論壇中,主題是你在五十個或更少的字元以內吸引有資格的專家注意的黃金機會,不要用諸「請幫我」(更別提大寫的「請幫我!!!!」,這種主題的消息會被條件反射式地刪掉)之類的嘮叨浪費機會。不要用你痛苦的深度來打動我們,相反,要在這點空間中使用超級簡明扼要的問題描述。

使用主題的好慣例是「物件──偏差」式的描述,許多技術支援組織就是這樣做的。在「物件」部分指明是哪一個或哪一組東西有問題,在「偏差」部分則描述與期望行為不一致的地方。

愚蠢
救命啊!我的筆記本視頻工作不正常!

明智
X.org 4.1扭曲滑鼠游標,某顯卡 MV1005 型號的晶片組

更明智
使用某顯卡 MV1005 型號晶片組的 x.org 4.1 的滑鼠游標被扭曲

編寫「物件──偏差」式描述的過程有助於你更具體地組織你的問題。是什麼被影響了?僅僅是滑鼠游標或者還有其他圖形?只在 X.org 中出現?或只是在其 4.1 版中?是針對某顯卡?或者只是其 MV1005 型號的晶片組?一個黑客只需描一眼就能夠立即明白什麼是你遇到的問題,什麼是你自己的問題。

更一般地,想像一下在只顯示主題的文檔索引中查找。讓你的主題更好地反映問題,可以使下一個搜索類似問題的人能夠在文檔中直接找到答案的線索而不用再次張貼提問。

如果你想在回覆中提問,確保改變主題以表明你是在問一個問題,一個主題像「re: 測試」或「re: 新臭蟲」的消息不太可能引起足夠的注意。同時,將回覆中與新主題不甚相關的引用內容儘量刪除。

對於郵件列表訊息,不要直接點擊回覆按鈕來開始一個新的主題,這將限制你的觀眾。有些郵件閱讀程式,比如 mutt,允許用戶按線索排序並通過折疊主題來隱藏消息,這樣做的人永遠看不到你發的訊息。

僅僅改變主題還不夠。mutt 和其他郵件閱讀程式還要檢查主題以外的其他郵件頭資訊,以便為其指定主題,所以寧可發一 個全 新的郵件。

在網頁論壇,因為消息與特定的主題緊密結合並且通常在主題之外不可見,好的提問方式略有不同,通過回覆提問並不要緊(一些論壇甚至不允許在回覆中出現分離的主題,而且這樣做了基本上沒有人會去看)。不過通過回覆提問本身就是令人懷疑的做法,因為它們只會被正在查看該主題的人讀到。所以,除非你只想在該主題當前活躍的人群中提問,還是另起爐灶比較好。

使之更易回覆

以「請向……回覆」來結束問題多半會使你得不到回答。如果你覺得花幾秒鐘在郵件用戶端設置一下回覆位址都麻煩,我們也覺得花幾秒鐘考慮你的問題更麻煩。如果你的郵件用戶端程式不支援這樣做,換個好點的。如果是作業系統不支援所有這種郵件用戶端程式,也換個好點的。

在網頁論壇,要求通過電子郵件回覆是完全無禮的,除非你確信回覆的資訊也許是機密的(而且有人會為了某種未知的原因只讓你而不是整個論壇知道答案)。如果你只是想在有人回覆主題時得到電子郵件提醒,可以要求論壇發送。幾乎所有論壇都提供諸如「留意本主題」、「有回覆發送郵件」的功能。

使用清晰、語法與拼寫正確的語句

經驗告訴我們,粗心與草率的作者通常也粗心與草率地思考和編程(我敢打賭)。為這些粗心與草率的思考者回答問題沒有什麼好處,我們寧可將時間花在其他地方。

清楚、完整地表達你的問題非常重要。如果你覺得這樣做麻煩,我們也覺得注意你的問題麻煩。花點額外的精力斟酌一下字句,用不著太僵硬與正式──事實 上,黑客文化很看重能準確地使用非正式、俚語和幽默的語句。但它必須很 準確,而且有跡像表明你是在思考和關注問題。

正確地拼寫、使用標點和大小寫,不要將 “its” 混淆為 “it's”,“loose” 搞成 “lose” 或者將 “discrete” 弄成 “discreet”。不要全部用大寫,這會被看成無禮的大聲嚷嚷(全部小寫也好不到哪去,因為不易閱讀。Alan Cox [注:著名黑客,Linux 內核的重要參與者] 也許可以這樣做,但你不行)。

一般而言,如果你寫得像個半文盲似的傻子,多半得不到理睬。如果像個小孩似地亂寫亂畫那絕對是在找死,可以肯定沒人會理你(或者最多是給你一大堆指責與挖苦)。

如果在非母語論壇中提問,你的拼寫與語法錯誤會得到有限的寬容,但懶惰完全不會被容忍(是的,我們通常看得出其中的差別)。同時,除非你知道回覆者使用的語言,請使用英語書寫。繁忙的黑客一般會直接刪除用他們看不懂語言寫的訊息。在互聯網上英語是工作語言,用英語書寫可以將你的問題不被閱讀就被直接刪除的可能降到最低。

使用易懂的格式發送問題

如果你人為地將問題搞得難以閱讀,它多半會被忽略,人們更願讀易懂的問題,所以:

* 使用文本而不是 HTML(超文本標注語言)(關閉HTML 並不難)

* 使用 MIME(多用途互聯網郵件擴展)附件通常沒有問題,前提是真正有內容(譬如附帶的原始檔案或補丁),而不僅僅是郵件用戶端程式生成的範本(譬如只是訊息內容的拷貝)。

* 不要發送整段只是單行句子但多次折回的郵件(這使得回覆部分內容非常困難)。設想你的讀者是在 80 個字元寬的文本終端閱讀郵件,設置你的行折回點小於 80 列。

* 但是,也 不要 用任何固定列折回資料(譬如直接傳送的日誌檔或會話記錄)。資料應該原樣包含,使回覆者確信他們看到的與你看到的東西一樣。

* 在英語論壇中,不要使用 "Quoted-Printable" MIME 編碼發送消息。這種編碼對於張貼非 ASCII 語言可能是必須的,但很多郵件代理程式並不支援。當它們分斷時,那些文本中四處散佈 的「=20」符號既難看也分散注意力。

* 永遠不要 指望黑客們閱讀使用封閉的專用格式編寫的文檔,諸如微軟公司的 Word 或 Excel 文件等,大多數黑客對此的反應就像有人將還在冒熱氣的豬糞倒在你門口時你的反應一樣。即使他們能夠處理,他們也很厭惡這麼做。

* 如果你從使用視窗的電腦發送電子郵件,關閉微軟愚蠢的「聰明引用」功能,以免在你的郵件中到處散佈垃圾字元。

* 在網頁論壇,勿濫用「表情符號」和「html」功能(當它們提供時)。一兩個表情符號通常沒有問題,但花哨的彩色文本傾向於使人認為你是個無能之輩。過濫地使用表情符號、色彩和字體會使你看來像個傻笑的小姑娘。這通常不是個好主意,除非你只是對性而不是有用的回覆更有興趣。

如果你使用圖形用戶介面的郵件用戶端程式(如網景公司的 Messenger、微軟公司的 Outlook 或者其他類似的),注意它們的預設配置不一定滿足這些要求。大多數這類程式有基於功能表的「查看原始碼」命令,用它來檢查發送檔夾中的訊息,以確保發送的是沒有多餘雜質的純文字檔案。

描述問題應準確且有內容

* 仔細、清楚地描述問題的徵狀

* 描述問題發生的環境(主機,作業系統,應用程式,任何相關的),提供銷售商的發行版和版本號(如:「Fedora Core 2」、「Slackware 9.1」等)

* 描述提問前做過的研究及其理解。

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

* 描述最近對電腦或軟體配置的任何相關改變。

盡最大努力預測黑客會提到的問題,並提前備好答案。

Simon Tatham 寫過一篇叫 如何有效報告臭蟲 的文章,我強烈推薦各位閱讀。

多不等於準確

你應該寫得準確且有內容,簡單地將一大堆原始碼或資料「傾倒」在求助訊息中達不到目的。如果你有一個很大且複雜的測試樣例讓程式崩潰,嘗試將其裁剪得越小越好。

至少有三個理由支持這點。第一,讓別人看到你在努力簡化問題使你更有可能得到回覆。第二,簡化問題使你更有可能得到 有用的 回覆。第三,在提純臭蟲報告的過程中,你可能自己就找到了解決問題的方法或權宜之計。

別動輒聲稱找到臭蟲

當你在一個軟體中遇到問題,除非你 非常、非常 的有根據,不要動輒聲稱找到了臭蟲。提示:除非你能提供解決問題的原始碼補丁,或者對前一版本的回歸測 試表現出不正確的行為,否則你都多半不夠完全確信。對於網頁和文檔也如此,如果你聲稱發現了文檔的「臭蟲」,你應該能提供相應位置的替代文本。

記住,還有許多其他用戶未經歷你遇到的問題,否則你在閱讀文檔或網頁搜索時就應該發現了(你在埋怨前已經做了這些,是吧?)。這也意味著很有可能是你弄錯了而不是軟體本身有問題。

編寫軟體的人通常非常辛苦地使它盡可能完美。如果你聲稱找到了臭蟲,也就暗示他們做錯了什麼,而這幾乎總會使人不快──即使你是對的,在主題中嚷嚷「臭蟲」也是特別不老練的。

提問時,即使你私下非常確信已經發現一個真正的臭蟲,最好寫得像是 你 做錯了什麼。如果真的有臭蟲,你會在回覆中看到這點。這麼做的話,如果真有蟲子,維護者就會向你道歉,這總比你弄砸了然後欠別人一個道歉要強。

低聲下氣不能代替自己應做之事

有些人明白他們不應該粗魯或傲慢地行事並要求得到答覆,但他們退到相反的低聲下氣的極端,「我知道我只是個什麼也不是、什麼也不懂的失敗者, 但……」。這既使人困擾也沒有幫助,當伴隨著對實際問題含糊的描述時還特別令人反感。

別用低級靈長類動物的策略浪費大家的時間,相反,儘量清楚地表述背景事實和你的問題,這比低聲下氣更好地擺正你的位置。

有時,網頁論壇設有單獨的初學者提問區域,如果你真的認為遇到了初淺的問題,到那去就是了,但一樣別低聲下氣。

描述問題症狀而不是猜測

告訴黑客你認為是什麼導致了問題是沒有用的(如果你的診斷理論是了不起的東西,你還會向他人諮詢求助嗎?)。所以,確保只是告訴他們問題的原始症狀,而不是你的解釋和理論,讓他們來解釋和診斷。如果你認為陳述你的猜測很重要,清楚地說明這只是你的猜測並描述為什麼它們不起作用。

愚蠢
我在編譯內核時接連遇到 SIG11 錯誤,懷疑主板上的某根電路絲斷了,找到它們的最好辦法是什麼?

明智
我組裝的電腦( K6/233 CPU、FIC-PA2007 主板(威盛 Apollo VP2 晶片組)、Corsair PC133 SDRAM 256MB 內存)最近在開機 20 分鐘左右、做內核編譯時頻繁地報 SIG11 錯,但在頭 20 分鐘內從不出問題。重啟動不會重定時鐘,但整夜關機會。更換所有記憶體未解決問題,相關的典型編譯會話日誌附後。

按時間先後羅列症狀

剛出問題之前發生的事情通常包含有解決問題最有效的線索。所以,記錄中應準確地描述你及電腦在崩潰之前都做了些什麼。在命令行處理的情況下,有會話日誌(如運行腳本工具生成的)並引用相關的若干(如 20)行記錄會非常有幫助。

如果崩潰的程式有診斷選項(如 -v 詳述選項),仔細考慮選擇這些能在記錄中增加排錯資訊的選項。

如果你的記錄很長(如超過四段),也許在開頭簡述問題隨後按時間先後羅列詳細過程更有用。這樣做,黑客在讀你的記錄時就知道該查哪些內容了。

描述目的而不是步驟

如果你想弄清楚如何做某事(而不是報告一個臭蟲),在開頭就描述你的目標,此後才描述為此採取的措施所遇到的問題。

經常有這種情況,尋求技術幫助的人在腦袋裏有個更高層面的目標,他們在自以為能達到目標的特定道路上被卡住了,然後跑來問該怎麼走,但沒有意識到這條路本身有問題,結果要費很大的勁才能通過。

愚蠢
我怎樣才能讓某圖形程式的顏色拾取器取得十六進位的 RGB 值?

明智
我正試圖用自己選定數值的顏色替換一幅圖片的顏色表,我現在唯一知道的方法是編輯每個表槽,但卻無法讓某圖形程式的顏色拾取器取得十六進制的 RGB 值。

第二種提法是明智的,它使得建議採用更合適的工具完成任務的回覆成為可能。

別要求私下回覆

黑客們認為問題的解決過程應該公開、透明,此過程中如果更有才能的人注意到不完整或者不當之處,最初的回覆才能夠、也應該被更正。同時,作為回覆者也因為能力和學識被其他同行看到而得到某種回報。

當你要求私下回覆時,此過程和回報都被中止。別這樣做,讓 回覆者 來決定是否私下回答──如果他真這麼做了,通常是因為他認為問題編寫太差或者太膚淺以至於對其他人無意義。

對這條規則存在一條有限的例外,如果你確信提問可能會導致大量雷同的回覆時,那麼「給我發電子郵件,我將為小組歸納這些回覆」將是神奇的句子。試圖將郵件列表或新聞組從洪水般雷同的回覆中解救出來是非常有禮貌的──但你應信守諾言。

問題應明晰

漫無邊際的問題通常也被視為沒有明確限制的時間無底洞。最有可能給你有用答案的人通常也是最忙的人(假如只是因為他們承擔了大多數工作的話),這些人對於沒有限制的時間無底洞極其反感,所以他們也傾向於討厭那些漫無邊際的問題。

如果你明確了想讓回覆者做的事(如指點方向、發送代碼、檢查補丁或其他),你更有可能得到有用的回覆。這可以使他們集中精力並間接地設定了他們為幫助你需要花費的時間和精力上限,這很好。

要想理解專家生活的世界,可以這樣設想:那裏有豐富的專長資源但稀缺的回應時間。你暗中要求他們奉獻的時間越少,你越有可能從這些真正懂行也真正很忙的專家那裏得到回答。

所以限定你的問題以使專家回答時需要付出的時間最少──這通常還與簡化問題不一樣。舉個例,「請問可否指點一下哪有好一點的 X 解釋?」通常要 比「請解釋一下 X」明智。如果你有什麼代碼不運行了,通常請別人看看哪有問題比叫他們幫你改正更明智。

別張貼家庭作業

黑客們善於發現「家庭作業」式的問題。我們大多數人已經做了自己的家庭作業,那是 該你 做的,以便從其經歷中學習。問一 下提示沒有關係,但不是要求完整的解決方案。

如果你懷疑自己碰到了

原始討論: http://twpug.net/x/modules/newbb/viewtopic.php?topic_id=1725
Sign In or Register to comment.