国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

小心選擇你要提問的場合。如果你做了下述的事情，你很可能被忽略掉或者被看作失敗者：

黑客會剔除掉那些搞錯場合的問題，以保護(hù)他們溝通的渠道不被無關(guān)的東西淹沒。你不會想讓這種事發(fā)生在自己身上的。

因此，第一步是找到對的論壇。再說一次，Google 和其它搜索引擎還是你的朋友，用它們來找到與你遭遇到困難的軟硬件問題最相關(guān)的網(wǎng)站。通常那兒都有常見問題（FAQ）、郵件列表及相關(guān)說明文件的鏈接。如果你的努力（包括**閱讀** FAQ）都沒有結(jié)果，網(wǎng)站上也許還有報告 Bug（Bug-reporting）的流程或鏈接，如果是這樣，鏈過去看看。

向陌生的人或論壇發(fā)送郵件最可能是風(fēng)險最大的事情。舉例來說，別假設(shè)一個提供豐富內(nèi)容的網(wǎng)頁的作者會想充當(dāng)你的免費顧問。不要對你的問題是否會受到歡迎做太樂觀的估計 -- 如果你不確定，那就向別處發(fā)送，或者壓根別發(fā)。

在選擇論壇、新聞群組或郵件列表時，別太相信名字，先看看 FAQ 或者許可書以弄清楚你的問題是否切題。發(fā)文前先翻翻已有的話題，這樣可以讓你感受一下那里的文化。事實上，事先在新聞組或郵件列表的歷史記錄中搜索與你問題相關(guān)的關(guān)鍵詞是個極好的主意，也許這樣就找到答案了。即使沒有，也能幫助你歸納出更好的問題。

別像機(jī)關(guān)槍似的一次"掃射"所有的幫助渠道，這就像大喊大叫一樣會使人不快。要一個一個地來。

搞清楚你的主題！最典型的錯誤之一是在某種致力于跨平臺可移植的語言、套件或工具的論壇中提關(guān)于 Unix 或 Windows 操作系統(tǒng)程序界面的問題。如果你不明白為什么這是大錯，最好在搞清楚這之間差異之前什么也別問。

一般來說，在仔細(xì)挑選的公共論壇中提問，會比在私有論壇中提同樣的問題更容易得到有用的回答。有幾個理由可以支持這點，一是看潛在的回復(fù)者有多少，二是看觀眾有多少。黑客較愿意回答那些能幫助到許多人的問題。

可以理解的是，老練的黑客和一些熱門軟件的作者正在接受過多的錯發(fā)信息。就像那根最后壓垮駱駝背的稻草一樣，你的加入也有可能使情況走向極端 -- 已經(jīng)好幾次了，一些熱門軟件的作者從自己軟件的支持中抽身出來，因為伴隨而來涌入其私人郵箱的無用郵件變得無法忍受。

搜索，然后 在 Stack Exchange 問。

近年來，Stack Exchange community 社區(qū)已經(jīng)成為回答技術(shù)及其他問題的主要渠道，尤其是那些開放源碼的項目。

因為 Google 索引是即時的，在看 Stack Exchange 之前先在 Google 搜索。有很高的機(jī)率某人已經(jīng)問了一個類似的問題，而且 Stack Exchange 網(wǎng)站們往往會是搜索結(jié)果中最前面幾個。如果你在 Google 上沒有找到任何答案，你再到特定相關(guān)主題的網(wǎng)站去找。用標(biāo)簽（Tag）搜索能讓你更縮小你的搜索結(jié)果。

Stack Exchange 已經(jīng)成長到超過一百個網(wǎng)站，以下是最常用的幾個站：

本地的使用者群組（user group），或者你所用的 Linux 發(fā)行版本也許正在宣傳他們的網(wǎng)頁論壇或 IRC 頻道，并提供新手幫助（在一些非英語國家，新手論壇很可能還是郵件列表）， 這些地方是開始提問的好首選，特別是當(dāng)你覺得遇到的也許只是相對簡單或者很普通的問題時。有廣告贊助的 IRC 頻道是公開歡迎提問的地方，通?？梢约磿r得到回應(yīng)。

事實上，如果程序出的問題只發(fā)生在特定 Linux 發(fā)行版提供的版本（這很常見），最好先去該發(fā)行版的論壇或郵件列表中提問，再到程序本身的論壇或郵件列表提問。（否則）該項目的黑客可能僅僅回復(fù) "用**我們的**版本"。

在任何論壇發(fā)文以前，先確認(rèn)一下有沒有搜索功能。如果有，就試著搜索一下問題的幾個關(guān)鍵詞，也許這會有幫助。如果在此之前你已做過通用的網(wǎng)頁搜索（你也該這樣做），還是再搜索一下論壇，搜索引擎有可能沒來得及索引此論壇的全部內(nèi)容。

通過論壇或 IRC 頻道來提供使用者支持服務(wù)有增長的趨勢，電子郵件則大多為項目開發(fā)者間的交流而保留。所以最好先在論壇或 IRC 中尋求與該項目相關(guān)的協(xié)助。

在使用 IRC 的時候，首先最好不要發(fā)布很長的問題描述，有些人稱之為頻道洪水。最好通過一句話的問題描述來開始聊天。

當(dāng)某個項目提供開發(fā)者郵件列表時，要向列表而不是其中的個別成員提問，即使你確信他能最好地回答你的問題。查一查項目的文件和首頁，找到項目的郵件列表并使用它。有幾個很好的理由支持我們采用這種辦法：

任何好到需要向個別開發(fā)者提出的問題，也將對整個項目群組有益。反之，如果你認(rèn)為自己的問題對整個項目群組來說太愚蠢，也不能成為騷擾個別開發(fā)者的理由。

向列表提問可以分散開發(fā)者的負(fù)擔(dān)，個別開發(fā)者（尤其是項目領(lǐng)導(dǎo)人）也許太忙以至于沒法回答你的問題。

大多數(shù)郵件列表都會被存檔，那些被存檔的內(nèi)容將被搜索引擎索引。如果你向列表提問并得到解答，將來其它人可以通過網(wǎng)頁搜索找到你的問題和答案，也就不用再次發(fā)問了。

如果某些問題經(jīng)常被問到，開發(fā)者可以利用此信息來改進(jìn)說明文件或軟件本身，以使其更清楚。如果只是私下提問，就沒有人能看到最常見問題的完整場景。

如果一個項目既有"使用者" 也有"開發(fā)者"（或"黑客"）郵件列表或論壇，而你又不會動到那些源代碼，那么就向"使用者"列表或論壇提問。不要假設(shè)自己會在開發(fā)者列表中受到歡迎，那些人多半會將你的提問視為干擾他們開發(fā)的噪音。

然而，如果你**確信**你的問題很特別，而且在"使用者" 列表或論壇中幾天都沒有回復(fù)，可以試試前往"開發(fā)者"列表或論壇發(fā)問。建議你在張貼前最好先暗地里觀察幾天以了解那里的行事方式（事實上這是參與任何私有或半私有列表的好主意）

如果你找不到一個項目的郵件列表，而只能查到項目維護(hù)者的電子郵件地址，盡管向他發(fā)信。即使是在這種情況下，也別假設(shè)（項目）郵件列表不存在。在你的電子郵件中，請陳述你已經(jīng)試過但沒有找到合適的郵件列表，也提及你不反對將自己的郵件轉(zhuǎn)發(fā)給他人（許多人認(rèn)為，即使沒什么秘密，私人電子郵件也不應(yīng)該被公開。通過允許將你的電子郵件轉(zhuǎn)發(fā)他人，你給了相應(yīng)人員處置你郵件的選擇）。

在郵件列表、新聞群組或論壇中，大約 50 字以內(nèi)的標(biāo)題是抓住資深專家注意力的好機(jī)會。別用喋喋不休的幫幫忙、跪求、急（更別說救命?。。。。∵@樣讓人反感的話，用這種標(biāo)題會被條件反射式地忽略）來浪費這個機(jī)會。不要妄想用你的痛苦程度來打動我們，而應(yīng)該是在這點空間中使用極簡單扼要的描述方式來提出問題。

一個好標(biāo)題范例是目標(biāo) -- 差異式的描述，許多技術(shù)支持組織就是這樣做的。在目標(biāo)部分指出是哪一個或哪一組東西有問題，在差異部分則描述與期望的行為不一致的地方。

編寫目標(biāo) -- 差異 式描述的過程有助于你組織對問題的細(xì)致思考。是什么被影響了？ 僅僅是鼠標(biāo)光標(biāo)或者還有其它圖形？只在 X.org 的 X 版中出現(xiàn)？或只是出現(xiàn)在 6.8.1 版中？ 是針對某牌顯卡芯片組？或者只是其中的 MV1005 型號？ 一個黑客只需瞄一眼就能夠立即明白你的環(huán)境**和**你遇到的問題。

總而言之，請想像一下你正在一個只顯示標(biāo)題的存檔討論串（Thread）索引中查尋。讓你的標(biāo)題更好地反映問題，可使下一個搜索類似問題的人能夠關(guān)注這個討論串，而不用再次提問相同的問題。

如果你想在回復(fù)中提出問題，記得要修改內(nèi)容標(biāo)題，以表明你是在問一個問題， 一個看起來像 Re: 測試 或者 Re: 新 bug 的標(biāo)題很難引起足夠重視。另外，在不影響連貫性之下，適當(dāng)引用并刪減前文的內(nèi)容，能給新來的讀者留下線索。

對于討論串，不要直接點擊回復(fù)來開始一個全新的討論串，這將限制你的觀眾。因為有些郵件閱讀程序，比如 mutt ，允許使用者按討論串排序并通過折疊討論串來隱藏消息，這樣做的人永遠(yuǎn)看不到你發(fā)的消息。

僅僅改變標(biāo)題還不夠。mutt 和其它一些郵件閱讀程序還會檢查郵件標(biāo)題以外的其它信息，以便為其指定討論串。所以寧可發(fā)一個全新的郵件。

在網(wǎng)頁論壇上，好的提問方式稍有不同，因為討論串與特定的信息緊密結(jié)合，并且通常在討論串外就看不到里面的內(nèi)容，故通過回復(fù)提問，而非改變標(biāo)題是可接受的。不是所有論壇都允許在回復(fù)中出現(xiàn)分離的標(biāo)題，而且這樣做了基本上沒有人會去看。不過，通過回復(fù)提問，這本身就是曖昧的做法，因為它們只會被正在查看該標(biāo)題的人讀到。所以，除非你**只想**在該討論串當(dāng)前活躍的人群中提問，不然還是另起爐灶比較好。

以請將你的回復(fù)寄到……來結(jié)束你的問題多半會使你得不到回答。如果你覺得花幾秒鐘在郵件客戶端設(shè)置一下回復(fù)地址都麻煩，我們也覺得花幾秒鐘思考你的問題更麻煩。如果你的郵件程序不支持這樣做，換個好點的；如果是操作系統(tǒng)不支持這種郵件程序，也換個好點的。

在論壇，要求通過電子郵件回復(fù)是非常無禮的，除非你相信回復(fù)的信息可能比較敏感（而且有人會為了某些未知的原因，只讓你而不是整個論壇知道答案）。如果你只是想在有人回復(fù)討論串時得到電子郵件提醒，可以要求網(wǎng)頁論壇發(fā)送給你。幾乎所有論壇都支持諸如追蹤此討論串、有回復(fù)時發(fā)送郵件提醒等功能。

我們從經(jīng)驗中發(fā)現(xiàn)，粗心的提問者通常也會粗心的寫程序與思考（我敢打包票）?；卮鸫中拇笠庹叩膯栴}很不值得，我們寧愿把時間耗在別處。

正確的拼字、標(biāo)點符號和大小寫是很重要的。一般來說，如果你覺得這樣做很麻煩，不想在乎這些，那我們也覺得麻煩，不想在乎你的提問。花點額外的精力斟酌一下字句，用不著太僵硬與正式 -- 事實上，黑客文化很看重能準(zhǔn)確地使用非正式、俚語和幽默的語句。但它**必須很**準(zhǔn)確，而且有跡象表明你是在思考和關(guān)注問題。

正確地拼寫、使用標(biāo)點和大小寫，不要將its混淆為it's，loose搞成lose或者將discrete弄成discreet。不要全部用大寫，這會被視為無禮的大聲嚷嚷（全部小寫也好不到哪去，因為不易閱讀。Alan Cox 也許可以這樣做，但你不行。）

更白話的說，如果你寫得像是個半文盲[譯注：小白]，那多半得不到理睬。也不要使用即時通訊中的簡寫或火星文，如將的簡化為ㄉ會使你看起來像一個為了少打幾個鍵而省字的小白。更糟的是，如果像個小孩似地鬼畫符那絕對是在找死，可以肯定沒人會理你（或者最多是給你一大堆指責(zé)與挖苦）。

如果在使用非母語的論壇提問，你可以犯點拼寫和語法上的小錯，但決不能在思考上馬虎（沒錯，我們通常能弄清兩者的分別）。同時，除非你知道回復(fù)者使用的語言，否則請使用英語書寫。繁忙的黑客一般會直接刪除用他們看不懂語言寫的消息。在網(wǎng)絡(luò)上英語是通用語言，用英語書寫可以將你的問題在尚未被閱讀就被直接刪除的可能性降到最低。

如果英文是你的外語（Second language），提示潛在回復(fù)者你有潛在的語言困難是很好的： [譯注：以下附上原文以供使用]

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

如果你使用圖形用戶界面的郵件程序（如微軟公司的 Outlook 或者其它類似的），注意它們的默認(rèn)設(shè)置不一定滿足這些要求。大多數(shù)這類程序有基于選單的查看源代碼命令，用它來檢查發(fā)送文件夾中的郵件，以確保發(fā)送的是純文本文件同時沒有一些奇怪的字符。

關(guān)鍵要點在于：

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

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

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

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

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

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

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

編寫軟件的人總是非常辛苦地使它盡可能完美。如果你聲稱找到了 Bug，也就是在質(zhì)疑他們的能力，即使你是對的，也有可能會冒犯到其中某部分人。當(dāng)你在標(biāo)題中嚷嚷著有Bug時，這尤其嚴(yán)重。

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

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

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

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

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

蠢問題

聰明問題

由于以上這點似乎讓許多人覺得難以配合，這里有句話可以提醒你：所有的診斷專家都來自密蘇里州。 美國國務(wù)院的官方座右銘則是：讓我看看（出自國會議員 Willard D. Vandiver 在 1899 年時的講話：我來自一個出產(chǎn)玉米，棉花，牛蒡和民主黨人的國家，滔滔雄辯既不能說服我，也不會讓我滿意。我來自密蘇里州，你必須讓我看看。） 針對診斷者而言，這并不是一種懷疑，而只是一種真實而有用的需求，以便讓他們看到的是與你看到的原始證據(jù)盡可能一致的東西，而不是你的猜測與歸納的結(jié)論。所以，大方的展示給我們看吧！

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

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

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

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

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

蠢問題

聰明問題

第二種提問法比較聰明，你可能得到像是建議采用另一個更合適的工具的回復(fù)。

黑客們認(rèn)為問題的解決過程應(yīng)該公開、透明，此過程中如果更有經(jīng)驗的人注意到不完整或者不當(dāng)之處，最初的回復(fù)才能夠、也應(yīng)該被糾正。同時，作為提供幫助者可以得到一些獎勵，獎勵就是他的能力和學(xué)識被其他同行看到。

當(dāng)你要求私下回復(fù)時，這個過程和獎勵都被中止。別這樣做，讓**回復(fù)者**來決定是否私下回答 -- 如果他真這么做了，通常是因為他認(rèn)為問題編寫太差或者太膚淺，以至于對其它人沒有興趣。

這條規(guī)則存在一條有限的例外，如果你確信提問可能會引來大量雷同的回復(fù)時，那么這個神奇的提問句會是向我發(fā)電郵，我將為論壇歸納這些回復(fù)。試著將郵件列表或新聞群組從洪水般的雷同回復(fù)中解救出來是非常有禮貌的 -- 但你必須信守諾言。

漫無邊際的提問是近乎無休無止的時間黑洞。最有可能給你有用答案的人通常也正是最忙的人（他們忙是因為要親自完成大部分工作）。這樣的人對無節(jié)制的時間黑洞相當(dāng)厭惡，所以他們也傾向于厭惡那些漫無邊際的提問。

如果你明確表述需要回答者做什么（如提供指點、發(fā)送一段代碼、檢查你的補(bǔ)丁、或是其他等等），就最有可能得到有用的答案。因為這會定出一個時間和精力的上限，便于回答者能集中精力來幫你。這么做很棒。

要理解專家們所處的世界，請把專業(yè)技能想像為充裕的資源，而回復(fù)的時間則是稀缺的資源。你要求他們奉獻(xiàn)的時間越少，你越有可能從真正專業(yè)而且很忙的專家那里得到解答。

所以，界定一下你的問題，使專家花在辨識你的問題和回答所需要付出的時間減到最少，這技巧對你有用答案相當(dāng)有幫助 -- 但這技巧通常和簡化問題有所區(qū)別。因此，問我想更好的理解 X，可否指點一下哪有好一點說明？通常比問你能解釋一下 X 嗎？更好。如果你的代碼不能運作，通常請別人看看哪里有問題，比要求別人替你改正要明智得多。

別要求他人幫你調(diào)試有問題的代碼，不提示一下應(yīng)該從何入手。張貼幾百行的代碼，然后說一聲：它不能工作會讓你完全被忽略。只貼幾十行代碼，然后說一句：在第七行以后，我期待它顯示 <x>，但實際出現(xiàn)的是 <y>比較有可能讓你得到回應(yīng)。

最有效描述程序問題的方法是提供最精簡的 Bug 展示測試用例（bug-demonstrating test case）。什么是最精簡的測試用例？那是問題的縮影；一小個程序片段能剛好展示出程序的異常行為，而不包含其他令人分散注意力的內(nèi)容。怎么制作最精簡的測試用例？如果你知道哪一行或哪一段代碼會造成異常的行為，復(fù)制下來并加入足夠重現(xiàn)這個狀況的代碼（例如，足以讓這段代碼能被編譯/直譯/被應(yīng)用程序處理）。如果你無法將問題縮減到一個特定區(qū)塊，就復(fù)制一份代碼并移除不影響產(chǎn)生問題行為的部分?？傊瑴y試用例越小越好（查看話不在多而在精一節(jié)）。

一般而言，要得到一段相當(dāng)精簡的測試用例并不太容易，但永遠(yuǎn)先嘗試這樣做的是種好習(xí)慣。這種方式可以幫助你了解如何自行解決這個問題 —- 而且即使你的嘗試不成功，黑客們也會看到你在嘗試取得答案的過程中付出了努力，這可以讓他們更愿意與你合作。

如果你只是想讓別人幫忙審查（Review）一下代碼，在信的開頭就要說出來，并且一定要提到你認(rèn)為哪一部分特別需要關(guān)注以及為什么。

黑客們很擅長分辨哪些問題是家庭作業(yè)式的問題；因為我們中的大多數(shù)都曾自己解決這類問題。同樣，這些問題得由**你**來搞定，你會從中學(xué)到東西。你可以要求給點提示，但別要求得到完整的解決方案。

如果你懷疑自己碰到了一個家庭作業(yè)式的問題，但仍然無法解決，試試在使用者群組，論壇或（最后一招）在項目的使用者郵件列表或論壇中提問。盡管黑客們**會**看出來，但一些有經(jīng)驗的使用者也許仍會給你一些提示。

避免用無意義的話結(jié)束提問，例如有人能幫我嗎？或者這有答案嗎？。

首先：如果你對問題的描述不是很好，這樣問更是畫蛇添足。

其次：由于這樣問是畫蛇添足，黑客們會很厭煩你 -- 而且通常會用邏輯上正確，但毫無意義的回答來表示他們的蔑視， 例如：沒錯，有人能幫你或者不，沒答案。

一般來說，避免用 是或否、對或錯、有或沒有類型的問句，除非你想得到是或否類型的回答。

這是你的問題，不是我們的。宣稱緊急極有可能事與愿違：大多數(shù)黑客會直接刪除無禮和自私地企圖即時引起關(guān)注的問題。更嚴(yán)重的是，緊急這個字（或是其他企圖引起關(guān)注的標(biāo)題）通常會被垃圾信過濾器過濾掉 -- 你希望能看到你問題的人可能永遠(yuǎn)也看不到。

有半個例外的情況是，如果你是在一些很高調(diào)，會使黑客們興奮的地方，也許值得這樣去做。在這種情況下，如果你有時間壓力，也很有禮貌地提到這點，人們也許會有興趣回答快一點。

當(dāng)然，這風(fēng)險很大，因為黑客們興奮的點多半與你的不同。譬如從 NASA 國際空間站（International Space Station）發(fā)這樣的標(biāo)題沒有問題，但用自我感覺良好的慈善行為或政治原因發(fā)肯定不行。事實上，張貼諸如緊急：幫我救救這個毛絨絨的小海豹！肯定讓你被黑客忽略或惹惱他們，即使他們認(rèn)為毛絨絨的小海豹很重要。

如果你覺得這點很不可思議，最好再把這份指南剩下的內(nèi)容多讀幾遍，直到你弄懂了再發(fā)文。

彬彬有禮，多用請和謝謝您的關(guān)注，或謝謝你的關(guān)照。讓大家都知道你對他們花時間免費提供幫助心存感激。

坦白說，這一點并沒有比清晰、正確、精準(zhǔn)并合法語法和避免使用專用格式重要（也不能取而代之）。黑客們一般寧可讀有點唐突但技術(shù)上鮮明的 Bug 報告，而不是那種有禮但含糊的報告。（如果這點讓你不解，記住我們是按問題能教給我們什么來評價問題的價值的）

然而，如果你有一串的問題待解決，客氣一點肯定會增加你得到有用回應(yīng)的機(jī)會。

（我們注意到，自從本指南發(fā)布后，從資深黑客那里得到的唯一嚴(yán)重缺陷反饋，就是對預(yù)先道謝這一條。一些黑客覺得先謝了意味著事后就不用再感謝任何人的暗示。我們的建議是要么先說先謝了，**然后**事后再對回復(fù)者表示感謝，或者換種方式表達(dá)感激，譬如用謝謝你的關(guān)注或謝謝你的關(guān)照。）

問題解決后，向所有幫助過你的人發(fā)個說明，讓他們知道問題是怎樣解決的，并再一次向他們表示感謝。如果問題在新聞組或者郵件列表中引起了廣泛關(guān)注，應(yīng)該在那里貼一個說明比較恰當(dāng)。

最理想的方式是向最初提問的話題回復(fù)此消息，并在標(biāo)題中包含已修正，已解決或其它同等含義的明顯標(biāo)記。在人來人往的郵件列表里，一個看見討論串問題 X和問題 X - 已解決的潛在回復(fù)者就明白不用再浪費時間了（除非他個人覺得問題 X的有趣），因此可以利用此時間去解決其它問題。

補(bǔ)充說明不必很長或是很深入；簡單的一句你好，原來是網(wǎng)線出了問題！謝謝大家 – Bill比什么也不說要來的好。事實上，除非結(jié)論真的很有技術(shù)含量，否則簡短可愛的小結(jié)比長篇大論更好。說明問題是怎樣解決的，但大可不必將解決問題的過程復(fù)述一遍。

對于有深度的問題，張貼調(diào)試記錄的摘要是有幫助的。描述問題的最終狀態(tài)，說明是什么解決了問題，在此**之后**才指明可以避免的盲點。避免盲點的部分應(yīng)放在正確的解決方案和其它總結(jié)材料之后，而不要將此信息搞成偵探推理小說。列出那些幫助過你的名字，會讓你交到更多朋友。

除了有禮貌和有內(nèi)涵以外，這種類型的補(bǔ)充也有助于他人在郵件列表/新聞群組/論壇中搜索到真正解決你問題的方案，讓他們也從中受益。

至少，這種補(bǔ)充有助于讓每位參與協(xié)助的人因問題的解決而從中得到滿足感。如果你自己不是技術(shù)專家或者黑客，那就相信我們，這種感覺對于那些你向他們求助的大師或者專家而言，是非常重要的。問題懸而未決會讓人灰心；黑客們渴望看到問題被解決。好人有好報，滿足他們的渴望，你會在下次提問時嘗到甜頭。

思考一下怎樣才能避免他人將來也遇到類似的問題，自問寫一份文件或加個常見問題（FAQ）會不會有幫助。如果是的話就將它們發(fā)給維護(hù)者。

在黑客中，這種良好的后繼行動實際上比傳統(tǒng)的禮節(jié)更為重要，也是你如何透過善待他人而贏得聲譽(yù)的方式，這是非常有價值的資產(chǎn)。

有一個古老而神圣的傳統(tǒng)：如果你收到RTFM （Read The Fucking Manual）的回應(yīng)，回答者認(rèn)為你應(yīng)該去讀他媽的手冊。當(dāng)然，基本上他是對的，你應(yīng)該去讀一讀。

RTFM 有一個年輕的親戚。如果你收到STFW（Search The Fucking Web）的回應(yīng)，回答者認(rèn)為你應(yīng)該到他媽的網(wǎng)上搜索過了。那人多半也是對的，去搜索一下吧。（更溫和一點的說法是 Google 是你的朋友?。?/div>