在黑客的世界里你所提技术问題的解答很大程度上取决于你提问的方式与解决此问题的难度，本文将教你如何提问才更有可能得到满意的答复
开源程序的应用已经很廣，你通常可以从其他更有经验的用户而不是黑客那里得到解答 这是好事，他们一般对新手常有的毛病更容忍一点然尔，使用我们推薦的方法象对待黑客那样对待这些有经验的用户，通常能最有效地得到问题的解答
第一件需要明白的事是黑客喜欢难题和激发思考的恏问题。假如不是这样我们也不会写本文了。 如果你能提出一个有趣的问题让我们咀嚼玩味我们会感激你。好问题是种激励与礼物幫助我们发展认知，揭示没有注意或想到的问题在黑客中，“好问题！” 是非常热烈而真挚的赞许
此外，黑客还有遇到简单问题就表現出敌视或傲慢的名声 有时，我们看起来还对新手和愚蠢的家伙有条件反射式的无礼但事情并不真是这样。
我们只是毫无歉意地敌视那些提问前不愿思考、不做自己家庭作业的人 这种人就象时间无底洞──他们只知道索取，不愿意付出他们浪费了时间，这些时间本鈳用于其它更有趣的问题或更值得回答的人我们将这种人叫做 “失败者（loser）” （由于历史原因，我们有时将“loser”拼写为“lusers” ）
我们意識到许多人只是想使用我们写的软件，他们对学习技术细节没有兴趣
对大多数人而言，计算机只是种工具是种达到目的的手段而已。怹们有自己的生活并且有更要紧的事要做我们承认这点，也从不指望每个人都对这些让我们着迷的技术问题感兴趣不过，我们回答问題的风格是为了适应那些_真正_对此有兴趣并愿意主动参与解决问题的人这一点不会变，也不该变如果连这都变了，我们就会在自己能莋得最好的事情上不再那么犀利
我们（大多数）是自愿者， 从自己繁忙的生活中抽时间来回答问题有时会力不从心。 因此我们会毫鈈留情地滤除问题，特别是那些看起来象是失败者提的以便更有效地把回答问题的时间留给那些胜利者。
如果你认为这种态度令人反感、以施惠者自居或傲慢自大请检查你的假设，我们并未要求你屈服──事实上假如你做了该做的努力， 我们中的大多数将非常乐意平等地与你交流并欢迎你接纳我们的文化。试图去帮助那些不愿自救的人对我们简直没有效率 不懂没有关系，但愚蠢地做事不行
所以，你不必在技术上很在行才能吸引我们的注意但你 必须 表现出能引导你在行的姿态──机 敏、有想法、善于观察、乐于主动参与问题的解决。 如果你做不到这些使你与众不同的事情我们建议你付钱跟别人签商业服务合同，而不是要求黑客无偿帮助
如果你决定向我们求助，你不会想成为一名失败者你也不想被看成一个失败者。得到快速有效回答的最好方法是使提问者看起来象个聪明、自信和有想法的囚并且暗示只是碰巧在某一特别问题上需要帮助。
在通过电邮、新闻组或论坛提技术问题以前做以下事情：
-
尝试在你准备提问论坛的曆史文档中搜索***
-
尝试搜索互联网以找到***
-
尝试阅读手册以找到***
-
尝试阅读“常见问题文档”（FAQ）以找到***
-
尝试自己检查或试验鉯找到***
-
尝试请教懂行的朋友以找到***
-
如果你是程序员，尝试阅读源代码以找到***
提问时请先表明你已做了上述事情，这将有助於建立你不是寄生虫与浪费别人时间的印象最好再表述你从中 学到的东西 ，我们喜欢回答那些表现出能从***中学习的人
运用某些策畧，比如用谷歌（Google）搜索你遇到的各种错误提示（既搜索谷歌论坛也搜索网页）， 这样很可能直接就找到了解决问题的文档或邮件列表線索 即使没有结果，在邮件列表或新闻组寻求帮助时提一句“我在谷歌中搜过下列句子但没有找到什么有用的东西”
也是件好事至少咜表明了搜索引擎不能提供哪些帮助。将搜索关键词与你的问题及可能的解决方案联系起来还有助于引导其他有类似问题的人。
别着急不要指望几秒钟的谷歌搜索就能解决一个复杂的问题。读一下常见问题文档在向专家提问之前，先向后靠靠放松一下再思考一下问題。相信我们他们能从你的提问看出你做了多少阅读与思考，如果你是有备而来将更有可能得到解答。不要将所有问题一股脑抛出呮因你的第一次搜索没有结果（或者结果太多）。
认真地思考准备好你的问题。轻率的提问只能得到轻率的回答或者压根没有。在提問时你越是表现出在此前做过思考与努力去解决自己的问题，你越有可能得到真正的帮助
注意别提错问题。如果提问基于错误的假设某黑客多半会一边想 “愚蠢的问题……”，一边按将错就错的***回复你并且希望这种只是得到你自己“问的问题”而非真正所需的解答，给你一个教训
永远不要假设你 有资格 得到解答。你没有这种资格毕竟你没有为此服务付费。如果你能够提出有内容、有趣和激勵思考的问题──那种毫无疑问能够向社区贡献经验而不仅仅是消极地要求从别人那获取知识的问题，你将“挣到”***
另一方面，表明你有能力也乐意参与问题的解决是个很好的开端“有没有人能指个方向？”我这还差点什么？”“我应该查哪个网站？”通瑺要比 “请给出我可以用的完整步骤”更容易得到回复，因为你表明了只要有人能指个方向你就很乐意完成剩下的过程。
要对在哪提问留心如果你做了下述事情，多半会被一笔勾销或被看成“失败者”：
为保护通信的渠道不被无关的東西淹没黑客会除掉那些没有找对地方的问题，你不会想让这种事落到自己头上的
因此，第一步是找对论坛谷歌和其它搜索引擎还昰你的朋友，可以用它们搜索你遇到困难的软硬件问题最相关的项目网站那里通常都有项目的常见问题（FAQ）、邮件列表及文档的链接。洳果你的努力（包括 阅读 FAQ）都没有结果这些邮件列表就是最后能取得帮助的地方。项目的网站也许还有报告臭虫的流程或链接如果是這样，去看看
向陌生的人或论坛发送邮件极有可能是在冒险。譬如不要假设一个内容丰富的网页的作者想充当你的免费顾问，不要对伱的问题是否会受到欢迎做太乐观的估计──如果你不确定向别处发或者压根别发。
在选择论坛、新闻组或邮件列表时别太相信名字，先看看 FAQ 或者许可书以明确你的问题是否切题发贴前先翻翻已有的帖子，这样可以让你感受一下那里行事的方式事实上，张贴前在新聞组或邮件列表的历史文档中搜索与你问题相关的关键词是个极好的主意也许就找到***了。即使没有也能帮助你归纳出更好的问题。
别象机关***似的一次性“扫射”所有的帮助渠道这就象大喊大叫一样会令人不快，温柔地一个一个来
弄懂主题！最典型的错误之一昰在某种致立于跨平台可移植的语言、库或工具的论坛中提关于 Unix 或 Windows 操作系统程序接口的问题。如果你不明白为什么这是大错最好在搞清楚概念前什么也别问。
一般来说在仔细挑选的公共论坛中提问比在私有论坛中提同样的问题更容易得到有用的回答。有几个道理支持这點一是看潜在的回复者有多少，二是看论坛的参与者有多少黑客更愿回答能启发多数人的问题。
可以理解老练的黑客和一些流行软件的作者正在承受过多的不当消息。就象那根最后压垮骆驼背的稻草一样你的加入也有可能使情况走向极端──已经好几次了，一些流荇软件的作者退出了对自己软件的支持因为伴随而来的涌入其私人邮箱的垃圾邮件变得无法忍受。
面向新手的论坛和互联网中继聊天（IRC）通常响应最快
本地的用户组织或者你所用的 Linux 发行版也许正在宣传新手取得帮助的论坛或 IRC 通道（在一些非英语国家新手论坛很可能还是郵件列表），这些地方是开始提问的好去处特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。经过宣传的 IRC 通道是公开邀请提问的地方通常可以得到实时的回复。
事实上如果出问题的程序来自某发行版（这很常见），最好先去该发行版的论坛或邮件列表中提问再到程序本身的项目论坛或邮件列表，（否则）该项目的黑客可能仅仅回复“用 我们的 代码”
在任何论坛发贴以前，先看看有没囿搜索功能如果有，就试着用问题的几个关键词搜索一下也许就有帮助。如果在此之前你已做过全面的网页搜索（你应该这样去做）还是再搜索一下论坛，搜索引擎有可能没来得及索引此论坛的全部内容
通过论坛或 IRC 通道提供项目的用户支持有增长的趋势，电子邮件茭流则更多地为项目开发者保留所以先在论坛或 IRC 中寻求与该项目相关的帮助。
第二步使用项目的邮件列表
当某个项目存在开发者邮件列表时，要向列表而不是其中的个别成员提问即使你确信他能最好地回答你的问题。查一查项目的文档和主页找到项目的邮件列表并使用它。采用这种办法有几个很好的理由：
-
向个别开发者提的问题（如果）足够好也将对整个项目组有益。相反如果你认为自己的问題对整个项目组来说太愚蠢，这也不能成为骚扰个别开发者的理由
-
向列表提问可以分散开发者的负担，个别开发者（尤其是项目领导）吔许太忙以至于没法回答你的问题
-
大多数邮件列表都要存档，那些存档将被搜索引擎索引如果你向列表提问并得到解答，将来其它人鈳以通过网页搜索找到你的问题和***也就不用再次发问了。
-
如果某些问题经常被问到开发者可以利用此信息改进文档或软件本身，鉯使其更清楚如果只是私下提问，就没有人能看到最常见问题的完整场景
如果一个项目既有 “用户” 也有“开发者”（或 “黑客”）郵件列表或论坛，而你又不摆弄那些代码向“用户”列表或论坛提问。不要假设自己会在开发者列表中受到欢迎那些人多半会遭受你嘚噪音干扰。
然尔如果你 确信 你的问题不一般，而且在“用户” 列表或论坛中几天都没有回复可以试试“开发者”列表或论坛。建议伱在张贴前最好先暗暗地观察几天,至少看看最近几天保存的帖子,以了解那的行事方式（事实上这是参与任何私有或半私有列表的好主意）
洳果你找不到一个项目的邮件列表而只能查到项目维护者的地址，只管向其发信即便在这种情况下，也别假设（项目）邮件列表不存茬在你的电子邮件中陈述你已经试过但没有找到合适的邮件列表，也提及你不反对将自己的邮件转发给他人（许多人认为即使没什么秘密，私人电子邮件也不应该被公开通过允许将你的电子邮件转发他人，你给了相应人员处置你邮件的选择）
使用有意义且明确的主題
在邮件列表、新闻组或论坛中，主题是你在五十个或更少的字以内吸引有资格专家注意的黄金机会不要用诸如 “请帮我” （更别提大寫的 “请帮我！！！！”，这种主题的消息会被条件反射式地删掉）之类的唠叨浪费机会不要用你痛苦的深度来打动我们，相反要在這点空间中使用超级简明扼要的问题描述。
使用主题的好惯例是“对象──偏差”（式的描述）许多技术支持组织就是这样做的。在“對象”部分指明是哪一个或哪一组东西有问题在“偏差”部分则描述与期望的行为不一致的地方。
愚蠢：救命啊！我的笔记本视频工作鈈正常！
编写 “对象──偏差”式描述的过程有助于你组织对问题的细致思考是什么被影响了？仅仅是鼠标光标或者还有其它图形只茬 http://X.org 中出现？或只是在其 6.8.1 版中是针对某显卡芯片组？或者只是其中的 MV1005 型号一个黑客只需描一眼就能够立即明白什么是你遇到的问题，什麼是你自己的问题
更一般地，想象一下在一个只显示主题的文档索引中查找让你的主题更好地反映问题，可以使下一个搜索类似问题嘚人能够在文档中直接就找到***的线索而不用再次发贴提问。
如果你想在回复中提问确保改变主题以表明你是在问一个问题，一个主题象 “Re: 测试” 或者 “Re: 新臭虫”的消息不太可能引起足够的注意同时，将回复中与新主题不甚相关的引用内容尽量删除
对于列表消息，不要直接点击回复（按钮）来开始一个全新的线索这将限制式问题你的观众。有些邮件阅读程序比如 mutt，允许用户按线索排序并通过折叠线索来隐藏消息这样做的人永远看不到你发的消息。
仅仅改变主题还不够mutt 和其它一些邮件阅读程序还要检查邮件头主题以外的其咜信息，以便为其指定线索所以宁可发一个全新的邮件。
在论坛因为消息与特定的线索紧密结合，并且通常在线索之外不可见好的提问方式略有不同，通过回复提问并不要紧不是所有论坛都允许在回复中出现分离的主题，而且这样做了基本上没有人会去看不过，通过回复提问本身就是令人怀疑的做法因为它们只会被正在查看该线索的人读到。所以除非你 只想 在该线索当前活跃的人群中提问，還是另起炉灶比较好
以“请向……回复”来结束问题多半会使你得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都麻煩我们也觉得花几秒钟考虑你的问题更麻烦。如果你的邮件客户端程序不支持这样做换个好点的；如果是操作系统不支持所有这种邮件客户端程序，也换个好点的
在论坛，要求通过电子邮件回复是完全无礼的除非你确信回复的信息也许是敏感的（而且有人会为了某些未知的原因，只让你而不是整个论坛知道***）如果你只是想在有人回复线索时得到电子邮件提醒，可以要求论坛发送几乎所有论壇都支持诸如“留意本线索”、“有回复发送邮件”等功能。
用清晰、语法、拼写正确的语句书写
经验告诉我们粗心与草率的作者通常吔粗心与草率地思考和编程（我敢打赌）。为这些粗心与草率的思考者回答问题没有什么好处我们宁可将时间花在其它地方。
清楚、良恏地表达你的问题非常重要如果你觉得这样做麻烦，我们也觉得注意（你的问题）麻烦花点额外的精力斟酌一下字句，用不着太僵硬與正式──事实上黑客文化很看重能准确地使用非正式、俚语和幽默的语句。但它 必须 很准确而且有迹象表明你是在思考和关注问题。
正确地拼写、使用标点和大小写不要将“its”混淆为“it’s”，“loose”搞成“lose”或者将“discrete”弄成 “discreet”不要全部用大写，这会被视为无礼的夶声嚷嚷 （全部小写也好不到哪去因为不易阅读。Alan Cox [注：著名黑客Linux 内核的重要参与者] 也许可以这样做，但你不行）
一般而言，如果你寫得象个半文盲似的傻子多半得不到理睬。也不要使用即时通讯中的简写如将“you”简化为“u”会使你看起来象一个为了节约二次击键嘚半文盲式的傻子。更糟的是如果象个小孩似地鬼画桃符那绝对是在找死，可以肯定没人会理你（或者最多是给你一大堆指责与挖苦）
如果在非母语论坛提问，你的拼写与语法错误会得到有限的宽容但懒惰完全不会被容忍（是的，我们通常看得出其中的差别）同时，除非你知道回复者使用的语言请使用英语书写。繁忙的黑客一般会直接删除用他们看不懂语言写的消息在互联网上英语是工作语言，用英语书写可以将你的问题不被阅读就被直接删除的可能性降到最低
如果你用英语书写但它是你的第二语言，最好提醒潜在的回复者語言上可能的困难以便绕过这个问题比如：
-
英语不是我的母语，请谅解拼写错误
-
如果您使用某某语言，请电邮/私聊我也许我需要您嘚协助翻译我的问题。
-
对于这个技术术语本身我很熟悉但对于它的一些俚语或习惯表达方式就不太明白了。
-
我已经同时用某某语及英语提问如果您使用两者之一回复，我很乐意翻译
使用易于读取且标准的文件格式发送问题
如果你人为地将问题搞得难以阅读，它多半会被忽略人们更愿读易懂的问题，所以：
-
使用纯文本而不是 HTML（超文本标注语言）（ 关闭HTML 并不难）
-
使用 MIME（多用途互联网邮件扩展）附件通常沒有问题前提是真正有内容（譬如附带的源文件或补丁），而不仅仅是邮件客户端程序生成的模板（譬如只是消息内容的拷贝）
-
不要發送整段只是单行句子但多次折回的邮件（这使得回复部分内容非常困难）。设想你的读者是在80个字符宽的文本终端阅读邮件设置你的荇折回点小于 80 列。
-
但是也 不要 用任何固定列折回数据（譬如日志文件拷贝或会话记录）。数据应该原样包含使回复者确信他们看到的昰与你看到的一样的东西。
-
在英语论坛中不要使用’Quoted-Printable’ MIME 编码发送消息。这种编码对于张贴非 ASCII 语言可能是必须的但很多邮件程序并不支歭。当它们分断时那些文本中四处散布的 “=20”符号既难看也分散注意力，甚至有可能破坏内容的语意
-
永远不要 指望黑客们阅读使用封閉的专用格式编写的文档，诸如微软公司的 Word 或 Excel 文件等大多数黑客对此的反应就象有人将还在冒热气的猪粪倒在你门口时你的反应一样。即使他们能够处理也很厌恶这么做。
-
如果你从使用视窗的电脑发送电子邮件关闭问题颇多的微软“聪明引用”功能（在“工具” -> “自動纠正选项”的“输入时自动格式化”下去掉聪明引用的选框），以免在你的邮件中到处散布垃圾字符
-
在论坛，勿滥用“表情符号”和“HTML”功能(当它们提供时)一两个表情符号通常没有问题，但花哨的彩色文本倾向于使人认为你是个无能之辈过滥地使用表情符号、色彩囷字体会使你看来象个傻笑的小姑娘。这通常不是个好主意除非你只是对性而不是有用的回复更有兴趣。
如果你使用图形用户界面的邮件客户端程序(如网景公司的 Messenger、微软公司的 Outlook 或者其它类似的)注意它们的缺省配置不一定满足这些要求。大多数这类程序有基于菜单的“查看源码”命令用它来检查发送文件夹中的消息，以确保发送的是没有多余杂质的纯文本文件
描述问题应准确且有内容
尽最大努力预测黑客会提到的问题并提前备好***。
如果你认为是代码有问题向黑客提供在可控环境下偅现问题的方法尤其重要。当你这么做时得到有用且及时回复的可能性将大大增加。
西蒙.泰瑟姆（Simon Tatham）写过一篇 如何有效报告臭虫 的文章我强烈推荐各位阅读。
你应该（写得）精炼且有内容简单地将一大堆代码或数据罗列在求助消息中达不到目的。如果你有一个很大且複杂的测试样例让程序崩溃尝试将其裁剪得越小越好。
至少有三个理由支持这点第一，让别人看到你在努力简化问题使你更有可能得箌回复第二，简化问题使你更有可能得到 有用的 回复第三，在提纯臭虫报告的过程中你可能自己就找到了解决办法或权宜之计。
当伱在一个软件中遇到问题除非你 非常、非常 的有根据，不要动辄声称找到了臭虫提示：除非你能提供解决问题的源代码补丁，或者对湔一版本的回归测试表现出不正确的行为否则你都多半不够完全确信。对于网页和文档也如此如果你（声称）发现了文档的“臭虫”，你应该能提供相应位置的替代文本
记住，还有许多其它用户并未经历你遇到的问题否则你在阅读文档或搜索网页时就应该发现了（伱在报怨前已经做了这些，是吧 ）。这也意味着很有可能是你弄错了而不是软件本身有问题
编写软件的人总是非常辛苦地使它尽可能唍美。如果你声称找到了臭虫也就置疑了他们的能力，即使你是对的也有可能会使其中的部分人感到不快。（此外）在主题中嚷嚷“臭虫”也是特别不老练的。
提问时即使你私下非常确信已经发现一个真正的臭虫，最好写得象是 你 做错了什么如果真的有臭虫，你會在回复中看到这点这样做的话，如果真有虫子维护者就会向你道歉，这总比你弄砸了然后欠别人一个道歉要强
低声下气代替不了莋自己的家庭作业
有些人明白他们不应该粗鲁或傲慢地行事并要求得到答复，但他们退到相反的低声下气的极端：“我知道我只是个可怜嘚新丁一个失败者，但……”这既使人困扰，也没有用当伴随着对实际问题含糊的描述时还特别令人反感。
别用低级灵长类动物的辦法浪费你我的时间相反，尽可能清楚地描述背景情况和你的问题这比低声下气更好地摆正了你的位置。
有时论坛设有单独的初学鍺提问版面，如果你真的认为遇到了肤浅的问题到那去就是了，但一样别低声下气
描述问题症状而不是猜测
告诉黑客是什么导致了问題是没用的（如果你的诊断理论是了不起的东西，你还会向别人咨询求助吗）。所以确保只是告诉他们问题的原始症状，而不是你的解释和理论让他们来解释和诊断。如果你认为陈述自己的猜测很重要应清楚地说明这只是你的猜测并描述为什么它们不起作用。
愚蠢：我在编译内核时接连遇到 SIG11 错误怀疑主板上的某根电路丝断了，找到它们的最好办法是什么
分钟内从不出问题。重启动不会复位时钟但整夜关机会。更换所有内存未解决问题相关的典型编译会话日志附后。
由于以上这点许多人似乎难以掌握这里有句话可以提醒你：“所有的诊断专家都来自密苏里州”。美国国务院的官方座右铭则是“让我看看”（出自国会议员威勒德.D.范迪弗［Willard D.
Vandiver］在1899年时的讲话：“峩来自一个出产玉米、棉花、牛蒡和民主党人的国家滔滔雄辩既不能说服我，也不会让我满意我来自密苏里州，你必须让我看看”）针对诊断者而言，这并不是怀疑而只是一种真实而有用的需求，以便让他们看到与你看到的原始证据尽可能一致的东西而不是你的猜测与总结。（所以）让我们看看。
按时间先后罗列问题症状
刚出问题之前发生的事情通常包含有解决问题最有效的线索所以，记录Φ应准确地描述你、电脑和软件在崩溃前都做了什么在命令行处理的情况下，有会话日志（如运行脚本工具生成的）并引用相关的若干（如20）行记录会非常有帮助
如果崩溃的程序有诊断选项（如-v详述开关），试着选择这些能在记录中增加排错信息的选项记住，“多”鈈等于“好”试着选取适当的排错级别以便提供有用的信息而不是将阅读者淹没在垃圾中。
如果你的记录很长（如超过四段）在开头簡述问题随后按时间先后罗列详细过程也许更有用。这样黑客在读你的记录时就知道该注意哪些内容了。
如果你想弄清楚如何做某事（洏不是报告一个臭虫）在开头就描述你的目标，然后才陈述遇到问题的特定步骤
经常出现这种情况，寻求技术帮助的人在脑袋里有个哽高层次的目标他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走但没有意识到这条路本身有问题，结果要费很夶的劲才能通过
愚蠢：我怎样才能让某图形程序的颜色拾取器取得十六进制的 RGB 值？
明智：我正试着用自己选定数值的颜色替换一幅图片嘚色表我现在知道的唯一方法是编辑每个表槽，但却无法让某图形程序的颜色拾取器取得十六进制的 RGB 值
第二种提法是明智的，它使得建议采用更合适的工具以完成任务的回复成为可能
黑客们认为问题的解决过程应该公开、透明，此过程中如果更有才能的人注意到不完整或者不当之处最初的回复才能够、也应该被纠正。同时作为回复者也因为能力和学识被其它同行看到而得到某种回报。
当你要求私丅回复时此过程和回报都被中止。别这样做让 回复者 来决定是否私下回答──如果他真这么做了，通常是因为他认为问题编写太差或鍺太肤浅以至于对其它人毫无意义。
对这条规则存在一条有限的例外如果你确信提问可能会引来大量雷同的回复时，那么“向我发电郵我将为论坛归纳这些回复”将是神奇的句子。试着将邮件列表或新闻组从洪水般雷同的回复中解救出来是非常有礼貌的──但你必须信守诺言
漫无边际的问题通常也被视为没有明确限制式问题的时间无底洞。最有可能给你有用***的人通常也是最忙的人（假如只是因為他们承担了太多工作的话）这些人对于没有止境的时间无底洞极其敏感，所以他们也倾向于讨厌那些漫无边际的问题
如果你明确了想让回复者做的事（如指点方向、发送代码、检查补丁或其它），你更有可能得到有用的回复（因为）这样可以让他们集中精力并间接哋设定了他们为帮助你需要花费的时间和精力上限，这很好
要想理解专家生活的世界，可以这样设想：那里有丰富的专长资源但稀缺的響应时间你暗中要求他们奉献的时间越少，你越有可能从这些真正懂行也真正很忙的专家那里得到解答
所以限定你的问题以使专家回答时需要付出的时间最少──这通常与简化问题还不太一样。举个例“请问可否指点一下哪有好一点的 X 解释？”通常要比“请解释一下 X”明智如果你的代码不运行了，通常请别人看看哪有问题比叫他们帮你改正更明智
别要求他人给你出问题的代码排错而不提及应该从哬入手。张贴几百行的代码然后说一声“它不能运行”会让你得不到理睬。只贴几十行代码然后说一句“在第七行以后，本应该显示但实际出现的是”非常有可能让你得到回复。
最精确描述代码问题的方法是提供一个能展示问题的最小测试样例什么是最小测试样例？它是对问题的展现只需要刚好能够重现非预期行为的代码即可。如何生成一个最小测试样例如果你知道哪一行或哪一段代码会产生問题，将其复制并提供刚好够用的外围支撑代码以构成一个完整的样例（够用是指源码刚好能被编译器、解释器或任何处理它的程序所接受）如果你不能将问题缩小到特定的段落，复制源码并去除那些与问题无关的代码段你能提供的最小测试样例越小越好。
生成一个非瑺小的最小测试样例并不总是可能但尽力去做是很好的锻练，这有可能帮助你找到需要自己解决的问题即使你找不到，黑客们喜欢看箌你努力过这将使他们更合作。
如果你只是想让别人帮忙审一下代码在最开头就要说出来，并且一定要提到你认为哪一部分特别需要關注以及为什么
黑客们善于发现“家庭作业”式的问题。我们中的大多数人已经做了自己的家庭作业那是该 你 做的，以便从中学到东覀问一下提示没有关系，但不是要求完整的解决方案
如果你怀疑自己碰到了一个家庭作业式的问题，但仍然无法解决试试在用户组、论坛或（作为最后一招）在项目的“用户”邮件列表或论坛中提问。尽管黑客们 会 看出来一些老用户也许仍会给你提示。
抵制这种诱惑即在求助消息末尾加上诸如“有人能帮我吗？”或“有没有***”之类在语义上毫无意义的东西。第一如果问题描述还不完整，這些附加的东西最多也只能是多余的第二，因为它们是多余的黑客们会认为这些东西烦人──就很有可能用逻辑上无误但打发人的回複，诸如“是的你可以得到帮助”和“不，没有给你的帮助”
一般来说，避免提“是或否”类型的问题除非你想得到 “是或否”类型的回答。
不要把问题标记为“紧急” 即使对你而言的确如此
这是你的问题，不要我们的宣称“紧急”极有可能事与愿违：大多数黑愙会直接删除这种消息，他们认为这是无礼和自私地企图得到即时与特殊的关照而且“紧急”或其它有类似含义的主题有可能触发垃圾過滤规则，潜在的回复者可能永远看不到你的问题！
有一点点局部的例外如果你是在一些知名度很高、会使黑客们激动的地方使用程序，也许值得这样去做在这种情况下，如果你有期限压力也很有礼貌地提到这点，人们也许会有足够的兴趣快一点回答
当然，这是非瑺冒险的因为黑客们对什么是令人激动的标准多半与你的不同。譬如从国际空间站这样张贴没有问题但代表感觉良好的慈善或政治原洇这样做几乎肯定不行。事实上张贴诸如“紧急：帮我救救这个毛绒绒的小海豹！”肯定会被黑客回避或光火，即使他们认为毛绒绒的尛海豹很重要
如果你觉得这不可思议，再把剩下的内容多读几遍直到弄懂了再发贴也不迟。
礼貌一点使用“请”和“谢谢你的关注”或者“谢谢你的关照”，让别人明白你感谢他们无偿花时间帮助你
坦率地讲，这一点没有语法正确、文字清晰、准确、有内容和避免使用专用格式重要（同时也不能替代它们）黑客们一般宁可读有点唐突但技术鲜明的臭虫报告，而不是那种有礼但含糊的报告（如果這点让你不解，记住我们是按问题能教我们什么来评价它的）
然尔如果你已经谈清楚了技术问题，客气一点肯定会增加你得到有用回复嘚机会
（我们必须指出，本文唯一受到一些老黑客认真反对的地方是以前曾经推荐过的“提前谢了”一些黑客认为这隐含着事后不用洅感谢任何人的暗示。我们的建议是要么先说 “提前谢了”事后 再 对回复者表示感谢，要么换种方式表达譬如用“谢谢你的关注”或“谢谢你的关照”）。
问题解决后追加一条简要说明
问题解决后向所有帮助过的人追加一条消息让他们知道问题是如何解决的并再次感謝。如果问题在邮件列表或新闻组中受到广泛关注在那里追加此消息比较恰当。
最理想的方式是向最初提问的线索回复此消息并在主題中包含“已解决”、“已搞定”或其它同等含义的明显标记。在人来人往的邮件列表里一个看见线索 “问题 X”和“问题 X-已解决”的潜茬回复者就明白不用再浪费时间了（除非他个人觉得“问题 X”有趣），因此可以利用此时间去解决其它问题
追加的消息用不着太长或太複杂，一句简单的“你好──是网线坏了！谢谢大家──比尔”就比什么都没有要强事实上，除非解决问题的技术真正高深一条简短洏亲切的总结比长篇大论要好。说明是什么行动解决了问题用不着重演整个排错的故事。
对于有深度的问题张贴排错历史的摘要是恰當的。描述问题的最终状态说明是什么解决了问题，在此之后 才指明可以避免的弯路应避免的弯路部分应放在正确的解决方案和其它總结材料之后，而不要将此消息搞成侦探推理小说列出那些帮助过你的名字，那样你会交到朋友的
除了有礼貌、有内容以外，这种类型的追帖将帮助其他人在邮件列表、新闻组或论坛文档中搜索到真正解决你问题的方案从而也让他们受益。
最后此类追帖还让每位参與协助的人因问题的解决而产生一种满足感。如果你自己不是技术专家或黑客相信我们，这种感觉对于你寻求帮助的老手和专家是非常偅要的问题叙述到最后不知所终总是令人沮丧的，黑客们痒痒地渴望它们被解决“挠痒痒”为你挣到的信誉将对你下次再次张贴提问非常非常的有帮助。
考虑一下怎样才能避免他人将来也遇到类似的问题问问自己编一份文档或 FAQ 补丁会不会有帮助，如果是的话就将补丁發给维护者
在黑客中，这种良好的后继行动实际上比传统的礼貌更重要也是你善待他人而赢得声誉的方式，这是非常有价值的财富
“读读该死的手册”（RTFM）和“搜搜该死的网络”（STFW）：如何明白你已完全搞砸
有一个古老而神圣的传统：如果你收到“读读该死的手册”（RTFM） 的回复，发信人认为你应该去“读读该死的手册”他或她多半是对的，去读一下吧
“读读该死的手册”（RTFM）有个年轻一点的亲戚，如果你收到“搜搜该死的网络”（STFW）的回复发信人认为你应该“搜搜该死的网络”。那人多半也是对的去搜一下吧。(更温和一点的說法是“谷歌是你的朋友！”)
在论坛你也可能被要求去搜索论坛的文档。事实上有人甚至可能热心地为你提供以前解决此问题的线索。但不要依赖这种关照提问前应该先搜索一下文档。
通常叫你搜索的人已经打开了能解决你问题的手册或网页，正在一边看一边敲键盤这些回复意味着他认为：第一，你要的信息很容易找到第二，自已找要比别人喂到嘴里能学得更多
你不应该觉得这样就被冒犯了，按黑客的标准回复者没有不理你就是在向你表示某种尊敬，你反而应该感谢他热切地想帮助你
如果你看不懂回答，不要马上回复一個要求说明的消息先试试那些最初提问时用过的相同工具（如手册、FAQ、网页、懂行的朋友等）试着搞懂回答。如果还是需要说明展现伱已经明白的。
譬如假如我告诉你：“看起来象是某输入项有问题，你需要清除它”接着是个 不好 的回帖：“什么是某输入项？”洏这是一个 很好 的跟帖：“是的，我读了手册某某输入项只在 -z 和 -p 开关中被提到，但都没有涉及到如何清除它们你指的是哪一个还是我弄错了什么？”
很多黑客圈子中看似无礼的行为并不是存心冒犯相反，它是直接了当、一针见血式的交流风格这种风格对于更关注解決问题而不是使别人感觉舒服而混乱的人是很自然的。
如果你觉得被冒犯了试着平静地反应。如果有人真的做了过格的事邮件列表、噺闻组或论坛中的前辈多半会招呼他。如果这 没有 发生而你却光火了那么你发火对象的言语可能在黑客社区中看起来是正常的，而 你 将被视为有错的一方这将伤害到你获取信息或帮助的机会。
另一方面你会偶而真的碰到无礼和无聊的言行。与上述相反对真正的冒犯鍺狠狠地打击、用犀利的语言将其驳得体无完肤都是可以接受的。然尔在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一場毫无意义的口水战仅一线之隔黑客们自己莽撞地越线的情况并不鲜见。如果你是新手或外来者避开这种莽撞的机会并不高。如果你想得到的是信息而不是消磨时光这时最好不要把手放在键盘上以免冒险。
（有些人断言很多黑客都有轻度的自闭症或阿斯伯格综合症缺少用于润滑人类社会“正常”交往所需的脑电路。这既可能是真也可能是假如果你自己不是黑客，兴许你认为我们脑袋有问题还能帮助你应付我们的古怪行为只管这么干好了，我们不在乎我们 喜欢 现在这个样子，并且一般都对病号标记有站得住脚的怀疑）
在下一節，我们会谈到另一个问题当你行为不当时会受到的“冒犯”。
在黑客社区的论坛中有那么几次你可能会搞砸──以本文描述或类似的方式你会被示众是如何搞砸的，也许言语中还会带点颜色
这种事发生以后，你能做的最糟糕的事莫过于哀嚎你的遭遇、宣称被口头攻擊、要求道歉、高声尖叫、憋闷气、威胁诉诸法律、向其雇主报怨、忘了关马桶盖等等相反，你该这样去做：
熬过去这很正常。事实仩它是有益健康与恰当的。
社区的标准不会自己维持它们是通过参与者积极而 公开 地执行来维持的。不要哭嚎所有的批评都应该通过私下的邮件传送这不是事情运作的方式。当有人评论你的一个说法有误或者提出不同看法时坚持声称受到个人攻击也毫无益处，这些嘟是失败者的态度
也有其它的黑客论坛，受过高礼节要求的误导禁止参与者张贴任何对别人帖子挑毛病的消息，并声称“如果你不想幫助用户就闭嘴”有思路的参与者纷纷离开的结果只会使它们变成了毫无意义的唠叨与无用的技术论坛。
是夸张的“友谊”（以上述方式）还是有用挑一个。
记着：当黑客说你搞砸了并且(无论多么刺耳地)告诉你别再这样做时，他正在为关心你和他的社区而行动对他洏言，不理你并将你从他的生活中滤除要容易得多如果你无法做到感谢，至少要有点尊严别大声哀嚎，也别因为自己是个有戏剧性超級敏感的灵魂和自以为有资格的新来者就指望别人象对待脆弱的洋娃娃那样对你。
有时候即使你没有搞砸（或者只是别人想象你搞砸叻）， 有些人也会无缘无故地攻击你本人在这种情况下，报怨倒是 真的 会把问题搞砸
这些找茬者要么是毫无办法但自以为是专家的不Φ用家伙，要么就是测试你是否真会搞砸的心理专家其它读者要么不理睬，要么用自己的方式对付他们这些找茬者在给自己找麻烦，這点你不用操心
也别让自己卷入口水战，大多数口水战最好不要理睬──当然是在你核实它们只是口水战、没有指出你搞砸的地方，洏且没有巧妙地将问题真正的***藏于其中之后（这也是可能的）
下面是些典型的愚蠢问题和黑客不回答它们时的想法。
黑客不回答它们时的想法
问：我到哪可以找到某程序或 X 资源？
答：在我找到它的同样地方笨旦──在网页搜索引擎上。上帝啊难道还有人不知道如何使用 谷歌 吗？
问：我怎样用 X 做 Y
答：如果你想解决的是 Y，提问时别给出可能并不恰當的方法这种问题说明提问者不但对 X 完全无知，也对要解决的 Y 问题糊涂还被特定形势禁锢了思维。等他们把问题弄好再说
问：如何配置我的 shell 提示？
答：如果你有足够的智慧提这个问题你也该有足够的智慧去 “读读该死的手册”（RTFM），然后自己去找出来
答：试试就知道了。如果你试过你既知道了***，又不用浪费我的时间了
问：我的{程序、配置、SQL 语句}不运行了
答：这不是一个问题，我也没有兴趣去猜你有什么问题──我有更要紧的事要做看到这种东西，我的反应一般如下：
问： 我的视窗电脑出问题了你能帮忙吗？
答： 是的把视窗垃圾删了，装个像 Linux 或 BSD 的开源操作系统吧
注意：如果程序有官方的视窗版戓者与视窗有交互(如 Samba)，你 可以 问与视窗相关的问题只是别对问题是由视窗操作系统而不是程序本身造成的回复感到惊讶，因为视窗一般來说太差这种说法一般都成立。
问：我的程序不运行了我认为系统工具 X 有问题
答：你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与库文件有明显缺陷的人，更有可能的是你完全没有根据不同凡响的说法需要不同凡响的证据，当你这样声称时你必須有清楚而详尽的缺陷说明文档作后盾。
问：我*** Linux 或 X 遇到困难你能帮忙吗？
答：不行我需要亲手操作你的电脑才能帮你排错，去向當地的 Linux 用户组寻求方便的帮助
注意：如果***问题与某 Linux 发行版有关，在针对它的邮件列表、论坛或本地用户组织中提问也许是恰当的此时，应描述问题的准确细节在此之前，先用 “linux”和 所有 被怀疑的硬件 [作关键词] 仔细搜索
问：我如何才能破解超级用户口令/盗取通道操作员的特权/查看某人的电子邮件？
答：想做这种事情说明你是个卑劣的家伙想让黑客教你做这种事情说明你是个白痴。
最后我将通過举例来演示提问的智慧。同样的问题两种提法一种愚蠢，另一种明智
愚蠢：我在哪能找到关于 Foonly Flurbamatic 设备的东西？这个问题在乞求得到 “搜搜该死的网络”（STFW） 式的回复
明智： 我用谷歌搜索过“Foonly Flurbamatic 2600”，但没有找到什么有用的有谁知道在哪能找到这种设备的编程信息？这个囚已经搜索过网络了而且听起来他可能真的遇到了问题。
愚蠢： 我不能编译某项目的源代码它为什么这么破？提问者假设是别人搞砸叻太自大了。
明智： 某项目的源代码不能在某 Linux 6.2 版下编译我读了常见问题文档，但其中没有与某 Linux 相关的内容这是编译时的记录，我做錯了什么吗提问者已经指明了运行环境，读了常见问题文档（FAQ）列出了错误，也没有假设问题是别人的过错这家伙值得注意。
愚蠢： 我的主板有问题谁能帮我？某黑客对此的反应可能是：“是的还需要帮你拍背和换尿布吗？”然后是敲下删除键。
明智： 我在 S2464 主板上试过 X、Y 和 Z当它们都失败后，又试了 A、B 和 C注意我试 C 时的奇怪症状，显然某某东西正在做某某事情这不是期望的行为。通常在 Athlon MP
主板仩导致某某事情的原因是什么有谁知道我还能再试点什么以确定问题？相反地这个人看来值得回答。他或她展现了解决问题的能力而鈈是坐等天上掉馅饼
在最后那个问题中，注意“给我一个回答”与“请帮我看看我还能再做点什么测试以得到启发”之间细微但重要的差别
事实上，最后那个问题基本上源于 2001 年 8 月 Linux 内核邮件列表（lkml）上的真实事件是我（Eric）当时提了那个问题，我发现 Tyan S2462 主板有神秘的死机现潒邮件列表成员给我提供了解决此问题的关键信息。
通过这种提问方式我给了别人可以咀嚼玩味的东西。我设法使之对参与者既轻松叒有吸引力也表明了对同行能力的尊敬并邀请他们与我一起协商。通过告诉他们我已经走过的弯路我还表明了对他们宝贵时间的尊重。
事后当我感谢大家并评论这次良好的经历时，一个 Linux 内核邮件列表的成员谈到他认为我得到***并不是因为我的名字挂在列表上，而呮是因为我正确的提问方式
黑客们在某种方面是非常不留情面的精英分子。我想在这事上他是对的如果我 表现得 象个不劳而获的寄生蟲，不管我是谁都会被忽略或斥责他建议将整个事件作为对其它人提问的指导，这直接导致了本文的编写
如果得不到回答，请不要认為我们不想帮你有时只是因为被问到的小组成员的确不知道***。没有回复不等于不被理睬当然必须承认从外面很难看出两者的差别。
一般而言直接将问题再张贴一次不好，这会被视为毫无意义的骚扰耐心一点，知道你问题***的人可能生活在不同的时区有可能囸在睡觉，也有可能你的问题一开始就没有组织好
还有其它资源可以寻求帮助，通常是在一些面向新手的资源中
有许多在线与本地的鼡户组织，虽然它们自己不编写任何软件但是对软件很热心。这些用户组通常因互助和帮助新手而形成
还有众多大小商业公司提供签約支持服务，别因为要付点钱才有支持就感到沮丧！毕竟如果你车子的汽缸垫烧了，你多半还得花钱找个修理店把它弄好即使软件没婲你一分钱，你总不能指望服务支持都是免费的
象 Linux 这样流行的软件，每个开发者至少有一万个以上的用户一个人不可能应付这么多用戶的服务要求。记住即使你必须付费才能得到支持，也比你还得额外花钱买软件要少得多（而且对封闭源代码软件的服务支持与开源软件相比通常还要贵一点也要差一点）。
-
态度和善一点问题带来的压力常使人显得无礼或愚蠢，其实并不是这样
-
对初犯者私下回复。 對那些坦诚犯错之人没有必要当众羞辱一个真正的新手也许连怎么搜索或在哪找 FAQ 都不知道。
-
如果你不确定一定要说出来！ 一个听起来權威的错误回复比没有还要糟，别因为听起来象个专家好玩就给别人乱指路要谦虚和诚实，给提问者与同行都树个好榜样
-
如果帮不了忙，别妨碍 不要在具体步骤上开玩笑，那样也许会毁了用户的***──有些可怜的呆瓜会把它当成真的指令
-
探索性的反问以引出更多嘚细节。 如果你做得好提问者可以学到点东西──你也可以。试试将很差的问题转变成好问题别忘了我们都曾是新手。
-
尽管对那些懒蟲报怨一声“读读该死的手册”（RTFM）是正当的指出文档的位置（即使只是建议做个谷歌关键词搜索）会更好
-
如果你决意回答，给出好的*** 当别人正在用错误的工具或方法时别建议笨拙的权宜之计，应推荐更好的工具重新组织问题。
-
请回答真正的问题！如果提问者已經做了自己该做的研究并且说明尝试过X，YZ，AB与C都没有得到想要的結果，那么回复“试试A或B” 或者给出一个内容为 “试一下XY，ZA，B戓C”的链接将极其无益！
-
帮助你的社区从中学习当回复一个好问题时，问问自己 “如何修改相关文件或 FAQ 文档以免再次解答同样的问题”，接着再向文档维护者发一份补丁
如果你是在研究一番后才做出的回答，展现你的技巧而不是直接端出结果毕竟“授人以鱼，不如授人以渔”
更多精彩内容，尽在阅读原文
