提问的智慧艾瑞克.史蒂文.雷蒙德（Eric Steven Raymond）Thyrsus Enterprises
<esr@thyrsus.com>
瑞克.莫恩（Rick Moen）
<respond-auto@linuxmafia.com>
版权©2001, 2006 Eric S. Raymond, Rick Moen
内容
译文
弃权申明
引言
提问前
提问时
仔细挑选论坛
面向新手的论坛和互联网中继聊天（IRC）通常响应最快
第二步，使用项目的邮件列表
使用有意义且明确的主题
使问题容易回复
用清晰、语法、拼写正确的语句书写
使用易于读取且标准的文件格式发送问题
描述问题应准确且有内容
量不在多，精炼则灵
别急于宣称找到臭虫
低声下气代替不了做自己的家庭作业
描述问题症状而不是猜测
按时间先后罗列问题症状
描述目标而不是过程
别要求私下回复电邮
提问应明确
关于代码的问题
别张贴家庭作业式问题
删除无意义的要求
不要把问题标记为"紧急",即使对你而言的确如此
礼貌总是有益的
问题解决后追加一条简要说明
如何解读回答
"读读该死的手册"(RTFM)和"搜搜该死的网络"(STFW):如何明白你已完全搞砸
如果还不明白...
对待无礼
别象失败者那样反应
提问禁忌
好问题与坏问题
如果得不到回答
如何更好地回答
相关资源
鸣谢

弃权申明
许多项目的网站在如何取得帮助的部分链接了本文,这没有关系,也正是我们想要的.但如果你是该项目生成此链接的网管,请在链接附近显著位置注明:我们不提供该项目的服务支持!
我们已经领教了没有此说明带来的痛苦,我们将不停地被一些白痴纠缠,他们认为既然我们发布了本文,那么我们就有责任解决世上所有的技术问题.
如果你是因为需要帮助正在阅读本文,然后就带着可以直接从作者那取得帮助的印象离开,那么你就不幸成了我们所说的白痴之一.别向我们提问,我们不会理睬的.我们只是在这教你如何从那些真正懂得你软硬件问题的人那里取得帮助,但 99.9% 的时间我们不会是那些人.除非你非常地确定本文的作者是你遇到问题方面的专家,请不要打搅,这样大家都更开心一点.

引言
在黑客的世界里,你所提技术问题的解答很大程度上取决于你提问的方式与解决此问题的难度,本文将教你如何提问才更有可能得到满意的答复.
开源程序的应用已经很广,你通常可以从其他更有经验的用户而不是黑客那里得到解答.这是好事,他们一般对新手常有的毛病更容忍一点.然尔,使用我们推荐的方法,象对待黑客那样对待这些有经验的用户,通常能最有效地得到问题的解答.
第一件需要明白的事是黑客喜欢难题和激发思考的好问题.假如不是这样,我们也不会写本文了.如果你能提出一个有趣的问题让我们咀嚼玩味,我们会感激你.好问题是种激励与礼物,帮助我们发展认知,揭示没有注意或想到的问题.在黑客中,"好问题!"是非常热烈而真挚的赞许.
此外,黑客还有遇到简单问题就表现出敌视或傲慢的名声.有时,我们看起来还对新手和愚蠢的家伙有条件反射式的无礼,但事情并不真是这样.
我们只是毫无歉意地敌视那些提问前不愿思考,不做自己家庭作业的人.这种人就象时间无底洞--他们只知道索取,不愿意付出,他们浪费了时间,这些时间本可用于其它更有趣的问题或更值得回答的人.我们将这种人叫做"失败者(loser)"(由于历史原因,我们有时将"loser"拼写为"lusers".)
我们意识到许多人只是想使用我们写的软件,他们对学习技术细节没有兴趣.对大多数人而言,计算机只是种工具,是种达到目的的手段而已.他们有自己的生活并且有更要紧的事要做,我们承认这点,也从不指望每个人都对这些让我们着迷的技术问题感兴趣.不过,我们回答问题的风格是为了适应那些真正对此有兴趣并愿意主动参与解决问题的人,这一点不会变,也不该变.如果连这都变了,我们就会在自己能做得最好的事情上不再那么犀利.
我们(大多数)是自愿者,从自己繁忙的生活中抽时间来回答问题,有时会力不从心.因此,我们会毫不留情地滤除问题,特别是那些看起来象是失败者提的,以便更有效地把回答问题的时间留给那些胜利者.
如果你认为这种态度令人反感,以施惠者自居或傲慢自大,请检查你的假设,我们并未要求你屈服--事实上,假如你做了该做的努力,我们中的大多数将非常乐意平等地与你交流,并欢迎你接纳我们的文化.试图去帮助那些不愿自救的人对我们简直没有效率.不懂没有关系,但愚蠢地做事不行.
所以,你不必在技术上很在行才能吸引我们的注意,但你必须表现出能引导你在行的姿态--机敏,有想法,善于观察,乐于主动参与问题的解决.如果你做不到这些使你与众不同的事情,我们建议你付钱跟别人签商业服务合同,而不是要求黑客无偿帮助.
如果你决定向我们求助,你不会想成为一名失败者,你也不想被看成一个失败者.得到快速有效回答的最好方法是使提问者看起来象个聪明,自信和有想法的人,并且暗示只是碰巧在某一特别问题上需要帮助.

提问前
在通过电邮、新闻组或论坛提技术问题以前，做以下事情：
1. 尝试在你准备提问论坛的历史文档中搜索答案
2. 尝试搜索互联网以找到答案
3. 尝试阅读手册以找到答案
4. 尝试阅读“常见问题文档”（FAQ）以找到答案
5. 尝试自己检查或试验以找到答案
6. 尝试请教懂行的朋友以找到答案
7. 如果你是程序员，尝试阅读源代码以找到答案
提问时，请先表明你已做了上述事情，这将有助于建立你不是寄生虫与浪费别人时间的印象。最好再表述你从中 学到的东西 ，我们喜欢回答那些表现出能从答案中学习的人。
运用某些策略，比如用谷歌（Google）搜索你遇到的各种错误提示（既搜索 谷歌论坛，也搜索网页）， 这样很可能直接就找到了解决问题的文档或邮件列表线索。 即使没有结果，在邮件列表或新闻组寻求帮助时提一句“我在谷歌中搜过下列句子但没有找到什么有用的东西” 也是件好事，至少它表明了搜索引擎不能提供哪些帮助。将搜索关键词与你的问题及可能的解决方案联系起来，还有助于引导其他有类似问题的人。
别着急，不要指望几秒钟的谷歌搜索就能解决一个复杂的问题。读一下常见问题文档。在向专家提问之前，先向后靠靠放松一下，再思考一下问题。相信我们，他们能从你的提问看出你做了多少阅读与思考，如果你是有备而来，将更有可能得到解答。不要将所有问题一股脑抛出，只因你的第一次搜索没有结果（或者结果太多）。
认真地思考，准备好你的问题。轻率的提问只能得到轻率的回答，或者压根没有。在提问时，你越是表现出在此前做过思考与努力去解决自己的问题，你越有可能得到真正的帮助。
注意别提错问题。如果提问基于错误的假设，某黑客多半会一边想 “愚蠢的问题……”，一边按将错就错的答案回复你，并且希望这种只是得到你自己“问的问题”而非真正所需的解答，给你一个教训。
永远不要假设你 有资格 得到解答。你没有这种资格，毕竟你没有为此服务付费。如果你能够提出有内容、有趣和激励思考的问题——那种毫无疑问能够向社区贡献经验，而不仅仅是消极地要求从别人那获取知识的问题，你将“挣到”答案。
另一方面，表明你有能力也乐意参与问题的解决是个很好的开端。“有没有人能指个方向？”，我这还差点什么？”，“我应该查哪个网站？”，通常要比 “请给出我可以用的完整步骤”更容易得到回复，因为你表明了只要有人能指个方向，你就很乐意完成剩下的过程。

提问时
仔细挑选论坛
要对在哪提问留心，如果你做了下述事情，多半会被一笔勾销或被看成“失败者”：
张贴与论坛主题无关的问题
在面向高级技术问题的论坛上张贴肤浅的问题，或者反之。
在太多不同的新闻组同时张贴
给既非熟人也没有义务解决你问题的人发送你私人的电邮
为保护通信的渠道不被无关的东西淹没，黑客会除掉那些没有找对地方的问题，你不会想让这种事落到自己头上的。
因此，第一步是找对论坛。谷歌和其它搜索引擎还是你的朋友，可以用它们搜索你遇到困难的软硬件问题最相关的项目网站。那里通常都有项目的常见问题（FAQ）、邮件列表及文档的链接。如果你的努力（包括 阅读 FAQ）都没有结果，这些邮件列表就是最后能取得帮助的地方。项目的网站也许还有报告臭虫的流程或链接，如果是这样，去看看。
向陌生的人或论坛发送邮件极有可能是在冒险。譬如，不要假设一个内容丰富的网页的作者想充当你的免费顾问，不要对你的问题是否会受到欢迎做太乐观的估计——如果你不确定，向别处发或者压根别发。
在选择论坛、新闻组或邮件列表时，别太相信名字，先看看 FAQ 或者许可书以明确你的问题是否切题。发贴前先翻翻已有的帖子，这样可以让你感受一下那里行事的方式。事实上，张贴前在新闻组或邮件列表的历史文档中搜索与你问题相关的关键词是个极好的主意，也许就找到答案了。即使没有，也能帮助你归纳出更好的问题。
别象机关枪似的一次性“扫射”所有的帮助渠道，这就象大喊大叫一样会令人不快，温柔地一个一个来。
弄懂主题！最典型的错误之一是在某种致立于跨平台可移植的语言、库或工具的论坛中提关于 Unix 或 Windows 操作系统程序接口的问题。如果你不明白为什么这是大错，最好在搞清楚概念前什么也别问。
一般来说，在仔细挑选的公共论坛中提问比在私有论坛中提同样的问题更容易得到有用的回答。有几个道理支持这点，一是看潜在的回复者有多少，二是看论坛的参与者有多少，黑客更愿回答能启发多数人的问题。
可以理解，老练的黑客和一些流行软件的作者正在承受过多的不当消息。就象那根最后压垮骆驼背的稻草一样，你的加入也有可能使情况走向极端——已经好几次了，一些流行软件的作者退出了对自己软件的支持，因为伴随而来的涌入其私人邮箱的垃圾邮件变得无法忍受。

面向新手的论坛和互联网中继聊天（IRC）通常响应最快
本地的用户组织或者你所用的 Linux 发行版也许正在宣传新手取得帮助的论坛或 IRC 通道（在一些非英语国家，新手论坛很可能还是邮件列表），这些地方是开始提问的好去处，特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。经过宣传的 IRC 通道是公开邀请提问的地方，通常可以得到实时的回复。
事实上，如果出问题的程序来自某发行版（这很常见），最好先去该发行版的论坛或邮件列表中提问，再到程序本身的项目论坛或邮件列表，（否则）该项目的黑客可能仅仅回复“用 我们的代码”。
在任何论坛发贴以前，先看看有没有搜索功能。如果有，就试着用问题的几个关键词搜索一下，也许就有帮助。如果在此之前你已做过全面的网页搜索（你应该这样去做），还是再搜索一下论坛，搜索引擎有可能没来得及索引此论坛的全部内容。
通过论坛或 IRC 通道提供项目的用户支持有增长的趋势，电子邮件交流则更多地为项目开发者保留。所以先在论坛或 IRC 中寻求与该项目相关的帮助。

第二步，使用项目的邮件列表
当某个项目存在开发者邮件列表时，要向列表而不是其中的个别成员提问，即使你确信他能最好地回答你的问题。查一查项目的文档和主页，找到项目的邮件列表并使用它。采用这种办法有几个很好的理由：
向个别开发者提的问题（如果）足够好，也将对整个项目组有益。相反，如果你认为自己的问题对整个项目组来说太愚蠢，这也不能成为骚扰个别开发者的理由。
向列表提问可以分散开发者的负担，个别开发者（尤其是项目领导）也许太忙以至于没法回答你的问题。
大多数邮件列表都要存档，那些存档将被搜索引擎索引，如果你向列表提问并得到解答，将来其它人可以通过网页搜索找到你的问题和答案，也就不用再次发问了。
如果某些问题经常被问到，开发者可以利用此信息改进文档或软件本身，以使其更清楚。如果只是私下提问，就没有人能看到最常见问题的完整场景。
如果一个项目既有 “用户” 也有“开发者”（或 “黑客”）邮件列表或论坛，而你又不摆弄那些代码，向“用户”列表或论坛提问。不要假设自己会在开发者列表中受到欢迎，那些人多半会遭受你的噪音干扰。
然尔，如果你 确信 你的问题不一般，而且在“用户” 列表或论坛中几天都没有回复，可以试试“开发者”列表或论坛。建议你在张贴前最好先暗暗地观察几天以了解那的行事方式（事实上这是参与任何私有或半私有列表的好主意）。
如果你找不到一个项目的邮件列表，而只能查到项目维护者的地址，只管向其发信。即便在这种情况下，也别假设（项目）邮件列表不存在。在你的电子邮件中陈述你已经试过但没有找到合适的邮件列表，也提及你不反对将自己的邮件转发给他人（许多人认为，即使没什么秘密，私人电子邮件也不应该被公开。通过允许将你的电子邮件转发他人，你给了相应人员处置你邮件的选择）。

使问题容易回复
以“请向……回复”来结束问题多半会使你得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都麻烦，我们也觉得花几秒钟考虑你的问题更麻烦。如果你的邮件客户端程序不支持这样做，换个好点的；如果是操作系统不支持所有这种邮件客户端程序，也换个好点的。
在论坛，要求通过电子邮件回复是完全无礼的，除非你确信回复的信息也许是敏感的（而且有人会为了某些未知的原因，只让你而不是整个论坛知道答案）。如果你只是想在有人回复线索时得到电子邮件提醒，可以要求论坛发送。几乎所有论坛都支持诸如“留意本线索”、“有回复发送邮件”等功能。

使用易于读取且标准的文件格式发送问题
如果你人为地将问题搞得难以阅读，它多半会被忽略，人们更愿读易懂的问题，所以：
使用纯文本而不是 HTML（超文本标注语言）（ 关闭HTML 并不难）
使用 MIME（多用途互联网邮件扩展）附件通常没有问题，前提是真正有内容（譬如附带的源文件或补丁），而不仅仅是邮件客户端程序生成的模板（譬如只是消息内容的拷贝）。
不要发送整段只是单行句子但多次折回的邮件（这使得回复部分内容非常困难）。设想你的读者是在80个字符宽的文本终端阅读邮件，设置你的行折回点小于 80 列。
但是，也不要用任何固定列折回数据（譬如日志文件拷贝或会话记录）。数据应该原样包含，使回复者确信他们看到的是与你看到的一样的东西。
在英语论坛中，不要使用'Quoted-Printable' MIME 编码发送消息。这种编码对于张贴非 ASCII 语言可能是必须的，但很多邮件程序并不支持。当它们分断时，那些文本中四处散布的“=20”符号既难看也分散注意力，甚至有可能破坏内容的语意。
永远不要指望黑客们阅读使用封闭的专用格式编写的文档，诸如微软公司的 Word 或 Excel 文件等。大多数黑客对此的反应就象有人将还在冒热气的猪粪倒在你门口时你的反应一样。即使他们能够处理，也很厌恶这么做。
如果你从使用视窗的电脑发送电子邮件，关闭微软愚蠢的“聪明引用”功能，以免在你的邮件中到处散布垃圾字符。
在论坛，勿滥用“表情符号”和“HTML”功能(当它们提供时)。一两个表情符号通常没有问题，但花哨的彩色文本倾向于使人认为你是个无能之辈。过滥地使用表情符号、色彩和字体会使你看来象个傻笑的小姑娘。这通常不是个好主意，除非你只是对性而不是有用的回复更有兴趣。
如果你使用图形用户界面的邮件客户端程序(如网景公司的 Messenger、微软公司的 Outlook 或者其它类似的)，注意它们的缺省配置不一定满足这些要求。大多数这类程序有基于菜单的“查看源码”命令，用它来检查发送文件夹中的消息，以确保发送的是没有多余杂质的纯文本文件。

描述问题应准确且有内容
仔细、清楚地描述问题的症状
描述问题发生的环境(主机、操作系统、应用程序，任何相关的)，提供销售商的发行版和版本号（如：“Fedora Core 7”、“Slackware 9.1”等）
描述提问前做过的研究及其理解。
描述提问前为确定问题而采取的诊断步骤。
描述最近对计算机或软件配置的任何相关改变。
如果可能，提供在可控环境下重现问题的方法。
尽最大努力预测黑客会提到的问题，并提前备好答案。
如果你认为是代码有问题，向黑客提供在可控环境下重现问题的方法尤其重要。当你这么做时，得到有用且及时回复的可能性将大大增加。
西蒙.泰瑟姆（Simon Tatham）写过一篇 如何有效报告臭虫 的文章，我强烈推荐各位阅读。

量不在多，精炼则灵
你应该（写得）精炼且有内容，简单地将一大堆代码或数据罗列在求助消息中达不到目的。如果你有一个很大且复杂的测试样例让程序崩溃，尝试将其裁剪得越小越好。
至少有三个理由支持这点。第一，让别人看到你在努力简化问题使你更有可能得到回复。第二，简化问题使你更有可能得到 有用的 回复。第三，在提纯臭虫报告的过程中，你可能自己就找到了解决办法或权宜之计。

别急于宣称找到臭虫
当你在一个软件中遇到问题，除非你 非常、非常 的有根据，不要动辄声称找到了臭虫。提示：除非你能提供解决问题的源代码补丁，或者对前一版本的回归测试表现出不正确的行为，否则你都多半不够完全确信。对于网页和文档也如此，如果你（声称）发现了文档的“臭虫”，你应该能提供相应位置的替代文本。
记住，还有许多其它用户并未经历你遇到的问题，否则你在阅读文档或搜索网页时就应该发现了（你在报怨前已经做了这些，是吧 ？）。这也意味着很有可能是你弄错了而不是软件本身有问题。
编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了臭虫，也就置疑了他们的能力，即使你是对的，也有可能会使其中的部分人感到不快。（此外，）在主题中嚷嚷“臭虫”也是特别不老练的。
提问时，即使你私下非常确信已经发现一个真正的臭虫，最好写得象是 你 做错了什么。如果真的有臭虫，你会在回复中看到这点。这样做的话，如果真有虫子，维护者就会向你道歉，这总比你弄砸了然后欠别人一个道歉要强。

低声下气代替不了做自己的家庭作业
有些人明白他们不应该粗鲁或傲慢地行事并要求得到答复，但他们退到相反的低声下气的极端：“我知道我只是个可怜的新丁，一个失败者，但……”。这既使人困扰，也没有用，当伴随着对实际问题含糊的描述时还特别令人反感。
别用低级灵长类动物的办法浪费你我的时间，相反，尽可能清楚地描述背景情况和你的问题，这比低声下气更好地摆正了你的位置。
有时，论坛设有单独的初学者提问版面，如果你真的认为遇到了肤浅的问题，到那去就是了，但一样别低声下气。

描述问题症状而不是猜测
告诉黑客是什么导致了问题是没用的（如果你的诊断理论是了不起的东西，你还会向别人咨询求助吗？）。所以，确保只是告诉他们问题的原始症状，而不是你的解释和理论，让他们来解释和诊断。如果你认为陈述自己的猜测很重要，应清楚地说明这只是你的猜测并描述为什么它们不起作用。
愚蠢：
我在编译内核时接连遇到 SIG11 错误，怀疑主板上的某根电路丝断了，找到它们的最好办法是什么？
明智：
我组装的电脑（K6/233 CPU、FIC-PA2007 主板[威盛 Apollo VP2 芯片组]、Corsair PC133 SDRAM 256Mb 内存）最近在开机 20 分钟左右、做内核编译时频繁地报 SIG11 错，但在头 20 分钟内从不出问题。重启动不会复位时钟，但整夜关机会。更换所有内存未解决问题，相关的典型编译会话日志附后。
由于以上这点许多人似乎难以掌握，这里有句话可以提醒你：“所有的诊断专家都来自密苏里州”。美国国务院的官方座右铭则是“让我看看”（出自国会议员威勒德.D.范迪弗〔Willard D. Vandiver〕在1899年时的讲话：“我来自一个出产玉米、棉花、牛蒡和民主党人的国家，滔滔雄辩既不能说服我，也不会让我满意。我来自密苏里州，你必须让我看看。”）针对诊断者而言，这并不是怀疑，而只是一种真实而有用的需求，以便让他们看到与你看到的原始证据尽可能一致的东西，而不是你的猜测与总结。（所以，）让我们看看。