### 仔細挑選論壇
要對在哪提問留心,如果你做了下述事情,多半會被一筆勾銷或被看成“失敗者”:
* 張貼與論壇主題無關的問題
* 在面向高級技術問題的論壇上張貼膚淺的問題,或者反之。
* 在太多不同的新聞組同時張貼
* 給既非熟人也沒有義務解決你問題的人發送你私人的電郵
為保護通信的渠道不被無關的東西淹沒,黑客會除掉那些沒有找對地方的問題,你不會想讓這種事落到自己頭上的。
因此,第一步是找對論壇。谷歌和其它搜索引擎還是你的朋友,可以用它們搜索你遇到困難的軟硬件問題最相關的項目網站。那里通常都有項目的常見問題(FAQ)、郵件列表及文檔的鏈接。如果你的努力(包括*?閱讀?*FAQ)都沒有結果,這些郵件列表就是最后能取得幫助的地方。項目的網站也許還有報告臭蟲的流程或鏈接,如果是這樣,去看看。
向陌生的人或論壇發送郵件極有可能是在冒險。譬如,不要假設一個內容豐富的網頁的作者想充當你的免費顧問,不要對你的問題是否會受到歡迎做太樂觀的估計──如果你不確定,向別處發或者壓根別發。
在選擇論壇、新聞組或郵件列表時,別太相信名字,先看看 FAQ 或者許可書以明確你的問題是否切題。發貼前先翻翻已有的帖子,這樣可以讓你感受一下那里行事的方式。事實上,張貼前在新聞組或郵件列表的歷史文檔中搜索與你問題相關的關鍵詞是個極好的主意,也許就找到答案了。即使沒有,也能幫助你歸納出更好的問題。
別象機關槍似的一次性“掃射”所有的幫助渠道,這就象大喊大叫一樣會令人不快,溫柔地一個一個來。
弄懂主題!最典型的錯誤之一是在某種致立于跨平臺可移植的語言、庫或工具的論壇中提關于 Unix 或 Windows 操作系統程序接口的問題。如果你不明白為什么這是大錯,最好在搞清楚概念前什么也別問。
一般來說,在仔細挑選的公共論壇中提問比在私有論壇中提同樣的問題更容易得到有用的回答。有幾個道理支持這點,一是看潛在的回復者有多少,二是看論壇的參與者有多少,黑客更愿回答能啟發多數人的問題。
可以理解,老練的黑客和一些流行軟件的作者正在承受過多的不當消息。就象那根最后壓垮駱駝背的稻草一樣,你的加入也有可能使情況走向極端──已經好幾次了,一些流行軟件的作者退出了對自己軟件的支持,因為伴隨而來的涌入其私人郵箱的垃圾郵件變得無法忍受。
### 面向新手的論壇和互聯網中繼聊天(IRC)通常響應最快
本地的用戶組織或者你所用的 Linux 發行版也許正在宣傳新手取得幫助的論壇或 IRC 通道(在一些非英語國家,新手論壇很可能還是郵件列表),這些地方是開始提問的好去處,特別是當你覺得遇到的也許只是相對簡單或者很普通的問題時。經過宣傳的 IRC 通道是公開邀請提問的地方,通常可以得到實時的回復。
事實上,如果出問題的程序來自某發行版(這很常見),最好先去該發行版的論壇或郵件列表中提問,再到程序本身的項目論壇或郵件列表,(否則)該項目的黑客可能僅僅回復“用*?我們的?*代碼”。
在任何論壇發貼以前,先看看有沒有搜索功能。如果有,就試著用問題的幾個關鍵詞搜索一下,也許就有幫助。如果在此之前你已做過全面的網頁搜索(你應該這樣去做),還是再搜索一下論壇,搜索引擎有可能沒來得及索引此論壇的全部內容。
通過論壇或 IRC 通道提供項目的用戶支持有增長的趨勢,電子郵件交流則更多地為項目開發者保留。所以先在論壇或 IRC 中尋求與該項目相關的幫助。
### 第二步,使用項目的郵件列表
當某個項目存在開發者郵件列表時,要向列表而不是其中的個別成員提問,即使你確信他能最好地回答你的問題。查一查項目的文檔和主頁,找到項目的郵件列表并使用它。采用這種辦法有幾個很好的理由:
* 向個別開發者提的問題(如果)足夠好,也將對整個項目組有益。相反,如果你認為自己的問題對整個項目組來說太愚蠢,這也不能成為騷擾個別開發者的理由。
* 向列表提問可以分散開發者的負擔,個別開發者(尤其是項目領導)也許太忙以至于沒法回答你的問題。
* 大多數郵件列表都要存檔,那些存檔將被搜索引擎索引,如果你向列表提問并得到解答,將來其它人可以通過網頁搜索找到你的問題和答案,也就不用再次發問了。
* 如果某些問題經常被問到,開發者可以利用此信息改進文檔或軟件本身,以使其更清楚。如果只是私下提問,就沒有人能看到最常見問題的完整場景。
如果一個項目既有 “用戶” 也有“開發者”(或 “黑客”)郵件列表或論壇,而你又不擺弄那些代碼,向“用戶”列表或論壇提問。不要假設自己會在開發者列表中受到歡迎,那些人多半會遭受你的噪音干擾。
然爾,如果你*?確信?*你的問題不一般,而且在“用戶” 列表或論壇中幾天都沒有回復,可以試試“開發者”列表或論壇。建議你在張貼前最好先暗暗地觀察幾天,至少看看最近幾天保存的帖子,以了解那的行事方式(事實上這是參與任何私有或半私有列表的好主意)
如果你找不到一個項目的郵件列表,而只能查到項目維護者的地址,只管向其發信。即便在這種情況下,也別假設(項目)郵件列表不存在。在你的電子郵件中陳述你已經試過但沒有找到合適的郵件列表,也提及你不反對將自己的郵件轉發給他人(許多人認為,即使沒什么秘密,私人電子郵件也不應該被公開。通過允許將你的電子郵件轉發他人,你給了相應人員處置你郵件的選擇)。
### 使用有意義且明確的主題
在郵件列表、新聞組或論壇中,主題是你在五十個或更少的字以內吸引有資格專家注意的黃金機會,不要用諸如 “請幫我” (更別提大寫的 “請幫我!!!!”,這種主題的消息會被條件反射式地刪掉)之類的嘮叨浪費機會。不要用你痛苦的深度來打動我們,相反,要在這點空間中使用超級簡明扼要的問題描述。
使用主題的好慣例是“對象──偏差”(式的描述),許多技術支持組織就是這樣做的。在“對象”部分指明是哪一個或哪一組東西有問題,在“偏差”部分則描述與期望的行為不一致的地方。
**愚蠢:**
救命啊!我的筆記本視頻工作不正常!
**明智:**
X.org 6.8.1 扭曲鼠標光標,MV1005 型號的某顯卡芯片組
**更明智:**
使用 MV1005 型號的某顯卡芯片組在 X.org 6.8.1 的鼠標光標被扭曲
編寫 “對象──偏差”式描述的過程有助于你組織對問題的細致思考。是什么被影響了?僅僅是鼠標光標或者還有其它圖形?只在 X.org 中出現?或只是在其 6.8.1 版中?是針對某顯卡芯片組?或者只是其中的 MV1005 型號?一個黑客只需描一眼就能夠立即明白什么是你遇到的問題,什么是你自己的問題。
更一般地,想象一下在一個只顯示主題的文檔索引中查找。讓你的主題更好地反映問題,可以使下一個搜索類似問題的人能夠在文檔中直接就找到答案的線索,而不用再次發貼提問。
如果你想在回復中提問,確保改變主題以表明你是在問一個問題,一個主題象 “Re: 測試” 或者 “Re: 新臭蟲”的消息不太可能引起足夠的注意。同時,將回復中與新主題不甚相關的引用內容盡量刪除。
對于列表消息,不要直接點擊回復(按鈕)來開始一個全新的線索,這將限制你的觀眾。有些郵件閱讀程序,比如 mutt,允許用戶按線索排序并通過折疊線索來隱藏消息,這樣做的人永遠看不到你發的消息。
僅僅改變主題還不夠。mutt 和其它一些郵件閱讀程序還要檢查郵件頭主題以外的其它信息,以便為其指定線索,所以寧可發一個全新的郵件。
在論壇,因為消息與特定的線索緊密結合,并且通常在線索之外不可見,好的提問方式略有不同,通過回復提問并不要緊。不是所有論壇都允許在回復中出現分離的主題,而且這樣做了基本上沒有人會去看。不過,通過回復提問本身就是令人懷疑的做法,因為它們只會被正在查看該線索的人讀到。所以,除非你*?只想?*在該線索當前活躍的人群中提問,還是另起爐灶比較好。
### 使問題容易回復
以“請向……回復”來結束問題多半會使你得不到回答。如果你覺得花幾秒鐘在郵件客戶端設置一下回復地址都麻煩,我們也覺得花幾秒鐘考慮你的問題更麻煩。如果你的郵件客戶端程序不支持這樣做,[換個好點的](http://linuxmafia.com/faq/Mail/muas.html);如果是操作系統不支持所有這種郵件客戶端程序,也換個好點的。
在論壇,要求通過電子郵件回復是完全無禮的,除非你確信回復的信息也許是敏感的(而且有人會為了某些未知的原因,只讓你而不是整個論壇知道答案)。如果你只是想在有人回復線索時得到電子郵件提醒,可以要求論壇發送。幾乎所有論壇都支持諸如“留意本線索”、“有回復發送郵件”等功能。
### 用清晰、語法、拼寫正確的語句書寫
經驗告訴我們,粗心與草率的作者通常也粗心與草率地思考和編程(我敢打賭)。為這些粗心與草率的思考者回答問題沒有什么好處,我們寧可將時間花在其它地方。
清楚、良好地表達你的問題非常重要。如果你覺得這樣做麻煩,我們也覺得注意(你的問題)麻煩。花點額外的精力斟酌一下字句,用不著太僵硬與正式──事實上,黑客文化很看重能準確地使用非正式、俚語和幽默的語句。但它*?必須?*很準確,而且有跡象表明你是在思考和關注問題。
正確地拼寫、使用標點和大小寫,不要將“its”混淆為“it's”,“loose”搞成“lose”或者將“discrete”弄成 “discreet”。不要全部用大寫,這會被視為無禮的大聲嚷嚷 (全部小寫也好不到哪去,因為不易閱讀。Alan Cox [注:著名黑客,Linux 內核的重要參與者] 也許可以這樣做,但你不行。)
一般而言,如果你寫得象個半文盲似的傻子,多半得不到理睬。也不要使用即時通訊中的簡寫,如將“you”簡化為“u”會使你看起來象一個為了節約二次擊鍵的半文盲式的傻子。更糟的是,如果象個小孩似地鬼畫桃符那絕對是在找死,可以肯定沒人會理你(或者最多是給你一大堆指責與挖苦)。
如果在非母語論壇提問,你的拼寫與語法錯誤會得到有限的寬容,但懶惰完全不會被容忍(是的,我們通常看得出其中的差別)。同時,除非你知道回復者使用的語言,請使用英語書寫。繁忙的黑客一般會直接刪除用他們看不懂語言寫的消息。在互聯網上英語是工作語言,用英語書寫可以將你的問題不被閱讀就被直接刪除的可能性降到最低。
如果你用英語書寫但它是你的第二語言,最好提醒潛在的回復者語言上可能的困難以便繞過這個問題,比如:
* 英語不是我的母語,請諒解拼寫錯誤。
* 如果您使用某某語言,請電郵/私聊我,也許我需要您的協助翻譯我的問題。
* 對于這個技術術語本身我很熟悉,但對于它的一些俚語或習慣表達方式就不太明白了。
* 我已經同時用某某語及英語提問,如果您使用兩者之一回復,我很樂意翻譯。
### 使用易于讀取且標準的文件格式發送問題
如果你人為地將問題搞得難以閱讀,它多半會被忽略,人們更愿讀易懂的問題,所以:
* 使用純文本而不是 HTML(超文本標注語言)(?[關閉HTML](http://www.birdhouse.org/etc/evilmail.html)?并不難)
* 使用 MIME(多用途互聯網郵件擴展)附件通常沒有問題,前提是真正有內容(譬如附帶的源文件或補丁),而不僅僅是郵件客戶端程序生成的模板(譬如只是消息內容的拷貝)。
* 不要發送整段只是單行句子但多次折回的郵件(這使得回復部分內容非常困難)。設想你的讀者是在80個字符寬的文本終端閱讀郵件,設置你的行折回點小于 80 列。
* 但是,也*?不要?*用任何固定列折回數據(譬如日志文件拷貝或會話記錄)。數據應該原樣包含,使回復者確信他們看到的是與你看到的一樣的東西。
* 在英語論壇中,不要使用'Quoted-Printable' MIME 編碼發送消息。這種編碼對于張貼非 ASCII 語言可能是必須的,但很多郵件程序并不支持。當它們分斷時,那些文本中四處散布的 “=20”符號既難看也分散注意力,甚至有可能破壞內容的語意。
* *永遠不要?*指望黑客們閱讀使用封閉的專用格式編寫的文檔,諸如微軟公司的 Word 或 Excel 文件等。大多數黑客對此的反應就象有人將還在冒熱氣的豬糞倒在你門口時你的反應一樣。即使他們能夠處理,也很厭惡這么做。
* 如果你從使用視窗的電腦發送電子郵件,關閉問題頗多的微軟“聰明引用”功能(在“工具” -> “自動糾正選項”的“輸入時自動格式化”下去掉聰明引用的選框),以免在你的郵件中到處散布垃圾字符。
* 在論壇,勿濫用“表情符號”和“HTML”功能(當它們提供時)。一兩個表情符號通常沒有問題,但花哨的彩色文本傾向于使人認為你是個無能之輩。過濫地使用表情符號、色彩和字體會使你看來象個傻笑的小姑娘。這通常不是個好主意,除非你只是對性而不是有用的回復更有興趣。
如果你使用圖形用戶界面的郵件客戶端程序(如網景公司的 Messenger、微軟公司的 Outlook 或者其它類似的),注意它們的缺省配置不一定滿足這些要求。大多數這類程序有基于菜單的“查看源碼”命令,用它來檢查發送文件夾中的消息,以確保發送的是沒有多余雜質的純文本文件。
### 描述問題應準確且有內容
* 仔細、清楚地描述問題的癥狀
* 描述問題發生的環境(主機、操作系統、應用程序,任何相關的),提供銷售商的發行版和版本號(如:“Fedora Core 7”、“Slackware 9.1”等)
* 描述提問前做過的研究及其理解。
* 描述提問前為確定問題而采取的診斷步驟。
* 描述最近對計算機或軟件配置的任何相關改變。
* 如果可能,提供在可控環境下重現問題的方法。
盡最大努力預測黑客會提到的問題,并提前備好答案。
如果你認為是代碼有問題,向黑客提供在可控環境下重現問題的方法尤其重要。當你這么做時,得到有用且及時回復的可能性將大大增加。
西蒙.泰瑟姆(Simon Tatham)寫過一篇?[如何有效報告臭蟲](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html)?的文章,我強烈推薦各位閱讀。
### 量不在多,精煉則靈
你應該(寫得)精煉且有內容,簡單地將一大堆代碼或數據羅列在求助消息中達不到目的。如果你有一個很大且復雜的測試樣例讓程序崩潰,嘗試將其裁剪得越小越好。
至少有三個理由支持這點。第一,讓別人看到你在努力簡化問題使你更有可能得到回復。第二,簡化問題使你更有可能得到*?有用的?*回復。第三,在提純臭蟲報告的過程中,你可能自己就找到了解決辦法或權宜之計。
### 別急于宣稱找到臭蟲
當你在一個軟件中遇到問題,除非你*?非常、非常?*的有根據,不要動輒聲稱找到了臭蟲。提示:除非你能提供解決問題的源代碼補丁,或者對前一版本的回歸測試表現出不正確的行為,否則你都多半不夠完全確信。對于網頁和文檔也如此,如果你(聲稱)發現了文檔的“臭蟲”,你應該能提供相應位置的替代文本。
記住,還有許多其它用戶并未經歷你遇到的問題,否則你在閱讀文檔或搜索網頁時就應該發現了(你在報怨前已經做了這些,[是吧](http://doc.zengrong.net/smart-questions/cn.html#before "Before You Ask")??)。這也意味著很有可能是你弄錯了而不是軟件本身有問題。
編寫軟件的人總是非常辛苦地使它盡可能完美。如果你聲稱找到了臭蟲,也就置疑了他們的能力,即使你是對的,也有可能會使其中的部分人感到不快。(此外,)在主題中嚷嚷“臭蟲”也是特別不老練的。
提問時,即使你私下非常確信已經發現一個真正的臭蟲,最好寫得象是*?你?*做錯了什么。如果真的有臭蟲,你會在回復中看到這點。這樣做的話,如果真有蟲子,維護者就會向你道歉,這總比你弄砸了然后欠別人一個道歉要強。
### 低聲下氣代替不了做自己的家庭作業
有些人明白他們不應該粗魯或傲慢地行事并要求得到答復,但他們退到相反的低聲下氣的極端:“我知道我只是個可憐的新丁,一個失敗者,但……”。這既使人困擾,也沒有用,當伴隨著對實際問題含糊的描述時還特別令人反感。
別用低級靈長類動物的辦法浪費你我的時間,相反,盡可能清楚地描述背景情況和你的問題,這比低聲下氣更好地擺正了你的位置。
有時,論壇設有單獨的初學者提問版面,如果你真的認為遇到了膚淺的問題,到那去就是了,但一樣別低聲下氣。
### 描述問題癥狀而不是猜測
告訴黑客是什么導致了問題是沒用的(如果你的診斷理論是了不起的東西,你還會向別人咨詢求助嗎?)。所以,確保只是告訴他們問題的原始癥狀,而不是你的解釋和理論,讓他們來解釋和診斷。如果你認為陳述自己的猜測很重要,應清楚地說明這只是你的猜測并描述為什么它們不起作用。
**愚蠢:**
我在編譯內核時接連遇到 SIG11 錯誤,懷疑主板上的某根電路絲斷了,找到它們的最好辦法是什么?
**明智:**
我組裝的電腦(K6/233 CPU、FIC-PA2007 主板[威盛 Apollo VP2 芯片組]、Corsair PC133 SDRAM 256Mb 內存)最近在開機 20 分鐘左右、做內核編譯時頻繁地報 SIG11 錯,但在頭 20 分鐘內從不出問題。重啟動不會復位時鐘,但整夜關機會。更換所有內存未解決問題,相關的典型編譯會話日志附后。
由于以上這點許多人似乎難以掌握,這里有句話可以提醒你:“所有的診斷專家都來自密蘇里州”。美國國務院的官方座右銘則是“讓我看看”(出自國會議員威勒德.D.范迪弗[Willard D. Vandiver]在1899年時的講話:“我來自一個出產玉米、棉花、牛蒡和民主黨人的國家,滔滔雄辯既不能說服我,也不會讓我滿意。我來自密蘇里州,你必須讓我看看。”)針對診斷者而言,這并不是懷疑,而只是一種真實而有用的需求,以便讓他們看到與你看到的原始證據盡可能一致的東西,而不是你的猜測與總結。(所以,)讓我們看看。
### 按時間先后羅列問題癥狀
剛出問題之前發生的事情通常包含有解決問題最有效的線索。所以,記錄中應準確地描述你、電腦和軟件在崩潰前都做了什么。在命令行處理的情況下,有會話日志(如運行腳本工具生成的)并引用相關的若干(如20)行記錄會非常有幫助。
如果崩潰的程序有診斷選項(如-v詳述開關),試著選擇這些能在記錄中增加排錯信息的選項。記住,“多”不等于“好”。試著選取適當的排錯級別以便提供有用的信息而不是將閱讀者淹沒在垃圾中。
如果你的記錄很長(如超過四段),在開頭簡述問題隨后按時間先后羅列詳細過程也許更有用。這樣,黑客在讀你的記錄時就知道該注意哪些內容了。
### 描述目標而不是過程
如果你想弄清楚如何做某事(而不是報告一個臭蟲),在開頭就描述你的目標,然后才陳述遇到問題的特定步驟。
經常出現這種情況,尋求技術幫助的人在腦袋里有個更高層次的目標,他們在自以為能達到目標的特定道路上被卡住了,然后跑來問該怎么走,但沒有意識到這條路本身有問題,結果要費很大的勁才能通過。
**愚蠢:**
我怎樣才能讓某圖形程序的顏色拾取器取得十六進制的 RGB 值?
**明智:**
我正試著用自己選定數值的顏色替換一幅圖片的色表,我現在知道的唯一方法是編輯每個表槽,但卻無法讓某圖形程序的顏色拾取器取得十六進制的 RGB 值。
第二種提法是明智的,它使得建議采用更合適的工具以完成任務的回復成為可能。
### 別要求私下回復電郵
黑客們認為問題的解決過程應該公開、透明,此過程中如果更有才能的人注意到不完整或者不當之處,最初的回復才能夠、也應該被糾正。同時,作為回復者也因為能力和學識被其它同行看到而得到某種回報。
當你要求私下回復時,此過程和回報都被中止。別這樣做,讓*?回復者?*來決定是否私下回答──如果他真這么做了,通常是因為他認為問題編寫太差或者太膚淺,以至于對其它人毫無意義。
對這條規則存在一條有限的例外,如果你確信提問可能會引來大量雷同的回復時,那么“向我發電郵,我將為論壇歸納這些回復”將是神奇的句子。試著將郵件列表或新聞組從洪水般雷同的回復中解救出來是非常有禮貌的──但你必須信守諾言。
### 提問應明確
漫無邊際的問題通常也被視為沒有明確限制的時間無底洞。最有可能給你有用答案的人通常也是最忙的人(假如只是因為他們承擔了太多工作的話),這些人對于沒有止境的時間無底洞極其敏感,所以他們也傾向于討厭那些漫無邊際的問題。
如果你明確了想讓回復者做的事(如指點方向、發送代碼、檢查補丁或其它),你更有可能得到有用的回復。(因為)這樣可以讓他們集中精力并間接地設定了他們為幫助你需要花費的時間和精力上限,這很好。
要想理解專家生活的世界,可以這樣設想:那里有豐富的專長資源但稀缺的響應時間。你暗中要求他們奉獻的時間越少,你越有可能從這些真正懂行也真正很忙的專家那里得到解答。
所以限定你的問題以使專家回答時需要付出的時間最少──這通常與簡化問題還不太一樣。舉個例,“請問可否指點一下哪有好一點的 X 解釋?”通常要比“請解釋一下 X”明智。如果你的代碼不運行了,通常請別人看看哪有問題比叫他們幫你改正更明智。
### 關于代碼的問題
別要求他人給你出問題的代碼排錯而不提及應該從何入手。張貼幾百行的代碼,然后說一聲“它不能運行”會讓你得不到理睬。只貼幾十行代碼,然后說一句“在第七行以后,本應該顯示,但實際出現的是”非常有可能讓你得到回復。
最精確描述代碼問題的方法是提供一個能展示問題的最小測試樣例。什么是最小測試樣例?它是對問題的展現,只需要剛好能夠重現非預期行為的代碼即可。如何生成一個最小測試樣例?如果你知道哪一行或哪一段代碼會產生問題,將其復制并提供剛好夠用的外圍支撐代碼以構成一個完整的樣例(夠用是指源碼剛好能被編譯器、解釋器或任何處理它的程序所接受)。如果你不能將問題縮小到特定的段落,復制源碼并去除那些與問題無關的代碼段。你能提供的最小測試樣例越小越好(參見?[量不在多,精煉則靈](http://doc.zengrong.net/smart-questions/cn.html#volume)?)。
生成一個非常小的最小測試樣例并不總是可能,但盡力去做是很好的鍛練,這有可能幫助你找到需要自己解決的問題。即使你找不到,黑客們喜歡看到你努力過,這將使他們更合作。
如果你只是想讓別人幫忙審一下代碼,在最開頭就要說出來,并且一定要提到你認為哪一部分特別需要關注以及為什么。
### 別張貼家庭作業式問題
黑客們善于發現“家庭作業”式的問題。我們中的大多數人已經做了自己的家庭作業,那是該*?你?*做的,以便從中學到東西。問一下提示沒有關系,但不是要求完整的解決方案。
如果你懷疑自己碰到了一個家庭作業式的問題,但仍然無法解決,試試在用戶組、論壇或(作為最后一招)在項目的“用戶”郵件列表或論壇中提問。盡管黑客們*?會?*看出來,一些老用戶也許仍會給你提示。
### 刪除無意義的要求
抵制這種誘惑,即在求助消息末尾加上諸如“有人能幫我嗎?”或“有沒有答案?”之類在語義上毫無意義的東西。第一,如果問題描述還不完整,這些附加的東西最多也只能是多余的。第二,因為它們是多余的,黑客們會認為這些東西煩人──就很有可能用邏輯上無誤但打發人的回復,諸如“是的,你可以得到幫助”和“不,沒有給你的幫助”。
一般來說,避免提“是或否”類型的問題,除非你想得到 “[是或否”類型的回答](http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/questions-with-yes-or-no-answers.html)。
### 不要把問題標記為“緊急”, 即使對你而言的確如此
這是你的問題,不要我們的。宣稱“緊急”極有可能事與愿違:大多數黑客會直接刪除這種消息,他們認為這是無禮和自私地企圖得到即時與特殊的關照。而且“緊急”或其它有類似含義的主題有可能觸發垃圾過濾規則,潛在的回復者可能永遠看不到你的問題!
有一點點局部的例外,如果你是在一些知名度很高、會使黑客們激動的地方使用程序,也許值得這樣去做。在這種情況下,如果你有期限壓力,也很有禮貌地提到這點,人們也許會有足夠的興趣快一點回答。
當然,這是非常冒險的,因為黑客們對什么是令人激動的標準多半與你的不同。譬如從國際空間站這樣張貼沒有問題,但代表感覺良好的慈善或政治原因這樣做幾乎肯定不行。事實上,張貼諸如“緊急:幫我救救這個毛絨絨的小海豹!”肯定會被黑客回避或光火,即使他們認為毛絨絨的小海豹很重要。
如果你覺得這不可思議,再把剩下的內容多讀幾遍,直到弄懂了再發貼也不遲。
### 禮貌總是有益的
禮貌一點,使用“請”和“謝謝你的關注”或者“謝謝你的關照”,讓別人明白你感謝他們無償花時間幫助你。
坦率地講,這一點沒有語法正確、文字清晰、準確、有內容和避免使用專用格式重要(同時也不能替代它們)。黑客們一般寧可讀有點唐突但技術鮮明的臭蟲報告,而不是那種有禮但含糊的報告。(如果這點讓你不解,記住我們是按問題能教我們什么來評價它的)
然爾,如果你已經談清楚了技術問題,客氣一點肯定會增加你得到有用回復的機會。
(我們必須指出,本文唯一受到一些老黑客認真反對的地方是以前曾經推薦過的“提前謝了”,一些黑客認為這隱含著事后不用再感謝任何人的暗示。我們的建議是要么先說 “提前謝了”,事后*?再?*對回復者表示感謝,要么換種方式表達,譬如用“謝謝你的關注”或“謝謝你的關照”)。
### 問題解決后追加一條簡要說明
問題解決后向所有幫助過的人追加一條消息,讓他們知道問題是如何解決的并再次感謝。如果問題在郵件列表或新聞組中受到廣泛關注,在那里追加此消息比較恰當。
最理想的方式是向最初提問的線索回復此消息,并在主題中包含“已解決”、“已搞定”或其它同等含義的明顯標記。在人來人往的郵件列表里,一個看見線索 “問題 X”和“問題 X-已解決”的潛在回復者就明白不用再浪費時間了(除非他個人覺得“問題 X”有趣),因此可以利用此時間去解決其它問題。
追加的消息用不著太長或太復雜,一句簡單的“你好──是網線壞了!謝謝大家──比爾”就比什么都沒有要強。事實上,除非解決問題的技術真正高深,一條簡短而親切的總結比長篇大論要好。說明是什么行動解決了問題,用不著重演整個排錯的故事。
對于有深度的問題,張貼排錯歷史的摘要是恰當的。描述問題的最終狀態,說明是什么解決了問題,*在此之后?*才指明可以避免的彎路。應避免的彎路部分應放在正確的解決方案和其它總結材料之后,而不要將此消息搞成偵探推理小說。列出那些幫助過你的名字,那樣你會交到朋友的。
除了有禮貌、有內容以外,這種類型的追帖將幫助其他人在郵件列表、新聞組或論壇文檔中搜索到真正解決你問題的方案,從而也讓他們受益。
最后,此類追帖還讓每位參與協助的人因問題的解決而產生一種滿足感。如果你自己不是技術專家或黑客,相信我們,這種感覺對于你尋求幫助的老手和專家是非常重要的。問題敘述到最后不知所終總是令人沮喪的,黑客們癢癢地渴望它們被解決。“撓癢癢”為你掙到的信譽將對你下次再次張貼提問非常非常的有幫助。
考慮一下怎樣才能避免他人將來也遇到類似的問題,問問自己編一份文檔或 FAQ 補丁會不會有幫助,如果是的話就將補丁發給維護者。
在黑客中,這種良好的后繼行動實際上比傳統的禮貌更重要,也是你善待他人而贏得聲譽的方式,這是非常有價值的財富。