[i=s] 本帖最后由 刘冲 于 2009-7-18 20:06 编辑 [/i]
提问的智慧
作者：
Eric Steven Raymond <esr@thyrsus.com>
Thyrsus Enterprises
Rick Moen <rick@linuxmafia.com>
版权 © 2001 Eric S. Raymond
修订历史
修订版 3.1 2004年10月28日
esr
文档‘Google 是你的朋友！’
修订版 3.0 2004年2月2日
esr
主要增加网页论坛应有的礼节内容
原文：How To Ask Questions The Smart Way
翻译：王刚 <yafrk@yahoo.com >
时间：2004年11月2日
内容
译文
弃权申明
引言
提问前
提问时
仔细挑选论坛
面向新手的网页论坛和IRC通常响应最快
第二步，使用项目邮件列表
使用明确而有意义的主题
使之更易回复
使用清晰、语法与拼写正确的语句
使用易懂的格式发送问题
描述问题应准确且有内容
多不等于准确
别动辄声称找到臭虫
低声下气不能代替自己应做之事
描述问题症状而不是猜测
按时间先后罗列问题症状
描述目的而不是步骤
别要求私下回复
问题应明晰
别张贴家庭作业
删除无意义的问题
不要刻意标明问题紧急
礼貌总是无害的
问题解决后追加一条简要说明
如何解读回答
RTFM与STFW：如何知道你已完全搞砸
如果还不明白.
对待无礼
别象个失败者那样反应
提问禁忌
好问题与坏问题
如果没有回复
如何更好地回答问题
相关资源
鸣谢
译文
译文: 捷克语 丹麦语 爱沙尼 亚语 法语 德语 希伯来语 匈牙利语 意大利语 日语 波 兰语 俄语 西班牙语 瑞典语 土 耳其语. 如果你想复制、镜像、翻译或引用本文，请参阅我的 复制须知.
弃权申明
许多项目的网站在 如何取得帮助的部分链接了本文，这没有关系，也是我们想要的。但如果你是该项目生成此链接的网管，请在链接附近显著位置注明“我们不是此项目的服务部！”
我们已经遭受没有此说明带来的痛苦，不断受到一些白痴的骚扰。他们认为既然我们发表了此文，那么我们就有责任解决世上所有技术问题！
如果你因为需要帮助阅读了本文，然后带着可以直接从作者那取得帮助的印象离开，你就不幸成了那些白痴之一。不要向我们提问，我们不会理睬 的。我们在这只是给你说明如何从那些真正懂得你软硬件问题的人那里取得帮助的方法，99%的时间我们不会是那些人。除非你确信此文作者是你遇到问题方面的专家， 请不要打扰，这样大家都更开心一点。
引言
在 黑客 的世界，你所提技术问题的回答很大程度上取决于你提问的方式与解决此问题的难度，本文将教你如何提问才更有可能得到满意的答复。
开源程序的使用已经很广，你通常可以从其它更有经验的用户而不是黑客那里得到回答。这是好事，他们一般对新手常有的毛病更容忍一点。然尔，使用我们 介 绍的方法象对待黑客那样对待这些有经验的用户，通常能最有效地得到问题的解答。
第一件需要明白的事是黑客喜欢难题和激发思考的好问题。假如不是这样，我们也不会写本文了。如果你能提出一个有趣的问题让我们咀嚼玩味，我们会感激你。 好的 问题是种激励与礼物，帮助我们发展认知，揭示没有注意或想过的问题。在黑客中，“好问题！”是非常真挚的赞许。
除此而外，黑客有遇到简单问题就表现出敌视或傲慢的名声，有时候我们看起来还对新手和愚蠢的家伙有条件反 射式的无礼，但并不真正是这样。
我们只是毫无歉意地敌视那些提问前 不愿思考、不做自己该做之事的人。这种人就象时间无底洞──他们只知道获取，不愿意付出，他们浪费了时间，这些时间本可用于其它更值得回答的人和 更有趣 的问题。我们将这种人叫做“失败者 (loser)” (由于历史原因，我们有时将“loser”拼为“lusers")
我们注意到许多人只想用我们写的软件，他们对学习技术细节没有兴趣。对大多数人而言，计算机只是种工具，是种达到目的的手段。他们要生活并且有更要紧的事要做，我们承认这点，也从不指望每个人都对这些让我们着迷的技术问题感兴趣。不过，我们回答问题的风格是为了适应那些真正对此有兴趣并愿意主动参与问题解决的 人，这一点不会变，也不该变。如果这都变了，我们就会在自己能做得最好的事情上不再那么犀利。
我们(多数)是自愿者，从自己繁忙的生活中抽时间来回答问题，有时会力不从心。因此，我们会无情地滤除问题，特别是那些看起来象是失败者的，以 便更有效地把回答问题的时间留给那些“胜利者”
如果你认为这种态度 令人憎恶、以施惠者自居或傲慢自大，请检查你的假设，我们并未要求你屈服──事实上，假如你做了该做的努力使之成为可能，我们中的大多数人非常乐意平等地与你交流并欢迎你接纳我们的文化。试图去帮助那些不愿自救的人对我们简直没有效率，不懂没有关系，但愚蠢地行事不行。
所以，你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你在行的姿态──机 敏、思考、善于观察、乐于主动参与问题的解决。如果你 做不到这些使你与众不同的事情，我们建议你付钱跟别人签商业服务合同，而不是要求黑客无偿帮助。
如果你决定向我们求助，你不会想成为一名失败者，你也不想被看成一个失败者。得到快速有效回复的最好方法是使提问者看起来象个聪明、自 信的人，并且暗示只是碰巧在某一特别问题上需要帮助。
(欢迎对本文指正，可以将建议发至 esr@thyrsus.com 。 请注意，本文不想成为一般性的 网络礼仪 指南，我一般会拒绝那些与引出技术论坛中有用的回复不特别相关的建议)
提问前
在通过电子邮件、新闻组或网页论坛提技术问题之前，做以下事情：
1.
尝试搜索互联网以找到答案
2.
尝试阅读手册以找到答案
3.
尝试阅读FAQ(常见问题)文档以找到答案
4.
尝试自己检查或试验以 找到答案
5.
尝试请教懂行的朋友以找到答案
6.
如果你是程序员，尝试阅读源代码以找到答案
提问时，请先表述你已经做了上述事情，这将有助于建立你不是寄生虫与浪费别人时间的印象。最好再表述你从中学到的东西，我们喜欢 回答那些表现出能从答案中学习的人。
使用某些策略，比如用Google搜索你遇到的错误提示(既搜索网页也查查讨论组)，可能就直接找到了解决问题的文档或邮件列表线索。即使没有结果，在电子邮件或新闻组张贴问题时提一句“我在Google中查过下列句子但没有找到什么有用的东西”也是件好事。
准备你的问题，彻底地思考。轻率的提问只能得到轻率的回答，或者压根没有。在提问时，越是表现出做过思考并在努力解 决问题，你越有可能得到 实际帮助。
注意别提错问题。如果提问基于错误的假设，某黑客多半会一边想”愚蠢的问题……“，一边用按照问题字面的无用答案回复你，并且希望这种只 是得到 字 面回答而不是真正所需的经历给你一个教训。
永远不要假设你有资格得 到解答。你没有这种资格，毕竟你没有为此服务付费。如果你能够提出有内容、有趣和激励思考的问题──那种毫无疑问能够向社 区贡献经验而不仅仅是消极地要求从别人那获取知识的问题，你将“挣到”答案。
另一方面，表明你能够也乐意参与问题的解决是个很好的开端。“有没有 人能指个方向？”、“我这还漏点什么？”、“我应该查哪些网站？”通常要比 “请给出我可以用的完整步骤”更容易得到回复，因为你表明了只要有人能指个方向你就很乐意完成剩下的过程。
提问时
仔细挑选论坛
要对在哪提问留心，如果你做了下 述事情，多半会被一笔勾销或被看成“失败者”：
*
张贴与论坛主题完全无关的问题
*
在面向高级技术问题的论坛上提非常 初浅的问题，或者反之。
*
在太多不同的新闻组同时交叉张贴
*
给既非熟人也没有义务解决你问题的个人张贴你私人的电子邮件
为保护通信的渠道不被无 关的东西淹没，黑客会除掉那些没有找对地方的问题，你不会想有这种经历的。
所以第一步是找对论坛，Google与其它搜索引擎还是你的朋友，可以用它们搜索与你遇到困难的软硬件问题最相关的项目的网站。那里通常都有项目的FAQ列表、邮件列表及其文档的链接。如果你的努力(包括阅读FAQ)都没有结果，这些邮件列表就是最后能取得帮助的地方。项目的网站也许还有报告臭虫的流程或链接，如果是这样，去看看。
向陌生的人或论坛发送邮件极有可能是在冒险。譬如，不要假设一个富含信息的网页的编写者想充当你的免费顾问，不要对你 的问题是否会受到欢迎做乐 观的 估计──如果你 不确定，向别处发或者根本别发。
在选择网页论坛、新闻组或邮件列表时，不要太相信名字，先看看FAQ或者许可书以明确你的问题 是否与其主题相关。张贴前先翻翻已有的帖 子可 以帮助你感受一下那里行事的方式。事实上，张贴之前在新闻组或邮件列表中搜索与你问题相关的关键词是个很好的主意，也许就找到答案了。即使没有，也能帮助你整理 出 更好的问题。
别象机关枪似的一次性“扫射”所有的帮助通 道，那就象大嚷大叫并使人不快。一个一个地来。
弄清楚你的主题！最典型的错误之一是在某种致立于跨Unix和Windows平台的语言、库或工具的论坛中提关于操作系统程序接口的问题。如果你不 明白为什么这是大错，最好在搞清楚概念前什么也别问。
一般来说，在仔细挑选的公共论坛中提问比在私有论坛中提同样的问题更容易得到有用的回复。有许多理由支持这一点，一是看潜在的回复者有多少，二是看 论 坛的参与者有多少，黑客更愿回答能启发多数人的问题。
可以理解，老练的黑客和一些流行软件的作者正在收到超出他们承受能力的不当消息。就象那根多出来就可以压垮骆驼背的稻草一样，你的加入也可能会使情况走向极端──已经好几次了，一些流行软件的作者退出了对其软件的支持，因为伴随而来的涌向其私人邮箱的大量无用消息变得无法 忍受。
面向新手的网页论坛和IRC通常响应最快
本地的用户组织或者你所用的Linux发行版也许正在宣传新手取得帮助的网页论坛或IRC(互联网中继聊天) (在非英语国家，新手论坛很可能还是邮件列表)，这些 地 方 是开始提问的好去处，尤其是当你觉得遇到的也许只是相对简单或者一般的问题时。经过宣传的IRC通道是个公开邀请提问的地方，通常可以得到实时的回复。
事实上，如果出问题的程序来自某发行版(这很常见)，在程序的项目论坛或列表提问前最好先在发行版的论坛或列表中问问，(否则)项目的黑客可能仅仅 回复“用我们的代码”
在任何网页论坛张贴之前，先看看是否有搜索功能。如果有，就试试用问题的几个关键词搜索一下，也许就有帮助。如果在此之前你已做过全面的网页搜索 (你应该这样做)，还是再搜索一下论坛，搜索引擎最近也许还没有索引此论坛的全部内容。
通过网页论坛或IRC频道提供项目的用户支持有增长的趋势，电子邮件交流则更多地为项目开发保留。先在网页论坛或IRC中寻求与项目相关的帮 助。
第二步，使用项目邮件列表
当某项目存在开发者邮件列表时，即使你确信谁能最好地回答问题，也要向列表而不是其中的个体提问。检查项目的文档和主页，找到项目的邮件列表并使 用它。采用这种策略有几个好理由：
*
任何向单个开发者提的足够好的问题也将对整个项目组有益。相反，如果你认为自己的问题对整个项目组来说太愚蠢，这也不能成为打扰 单个开发者的理由。
*
向列表提问可以平衡开发者的负担，单个开发者(特别是项目领导)也许太忙以至于无法回答你的问题。
*
大多数邮件列表有历史文档并被搜索引擎索引，其它人可以通过网页搜索找到你的问题和答案而不用再次在邮件列表中发问。
*
如果某些问题经常被问到，开发者可以利用此信息改进文档或软件本身以使其更清楚。如果只是私下提问，就没有人能看到最常见问题的完整 场景。
如果一个项目既有“用户”也有“开发者”(或“黑客”)邮件列表或网页论坛，而你又不摆弄那些代码，向“用户”列表或论坛提问。不要假设自己在开发 者列表中会受欢 迎，那些人多半会遭受你的噪音干扰。
然尔，如果你确信你的问题不一般，而且在“用户” 列表或论坛中几天都没有回复，可以试试“开发者”列表或论坛。建议你在张贴前最好先暗暗地观察几天 以了解那的行事方式(事实上这是参与任何私有或半私有列表的好主意)
如果你找不到一个项目的邮件列表，而只能查到项目维护者的地址，只管向其发信。即便在这种情况下，也别假设(项目)邮件列表不存在。在你的电子邮件中陈述你已经试过但没有找到合适的邮件列表，也提及你不反对将自己的邮件转发给他人(许多人认为，即使没什么秘密，私人电子邮件也不应该被公开。通过允许将你的电子邮件 转 发他人给 了相应人员处置你邮件的选择)。
使用明确而有意义的主题
在邮件列表、新闻组或网页论坛中，主题是你在五十个或更少的字符以内吸引有资格的专家注意的黄金机会，不要用诸如“请帮我”(更别提大写的“请帮我！！！！”，这种主题的消息会被条件反射式地删掉)之类的唠叨浪费机会。不要用你痛苦的深度来打动我们，相反，要在这点空间中使用超级简明扼要的问题描述。
使用主题的好惯例是“对象──偏差”(式的描述)，许多技术支持组织就是这样做的。在“对象”部分指明是哪一个或哪一组东西有问题，在“偏差”部分 则描述与期望 行 为不一致的地方。
愚蠢：
救命啊！我的笔记本视频工作不正常！
明智：
XFree86 4.1扭曲鼠标光标，某显卡MV1005型号的芯片组
更明智：
使用某显卡MV1005型号芯片组的XFree86 4.1的鼠标光标被扭曲
编写“对象──偏差”式描述的过程有助于你更具体地组织你的问题。是什么被影响了？仅仅是鼠标光标或者还有其它图形？只在XFree86中出现？或只是在其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”明智。如果你有什么代码不运行了，通常请别人看看哪有问题比叫他们帮你改正更明智。
别张贴家庭作业
黑客们善于发现“家庭作业”式的问题。我们大多数人已经做了自己的家庭作业，那是该你做的，以便从其经历中学习。问一 下提示没有关系，但不是要求完整的解决方案。
如果你怀疑自己碰到了一个家庭作业式的问题，但仍然无法解决，尝试在用户组论坛或(作为最后一招)在项目的“用户”邮件列表或论坛中提问。尽管 黑客们会看出来，一些高级用户也许仍会给你提示。
删除无意义的问题
抵制在求助消息末尾加上诸如“有人能帮我吗？”或“有没有答案？”之类在语义上无任何意义东西的诱惑。第一，如果问题描述还不完整，这些附加的东西最多也只能是多余的。第二，因为它们是多余的，黑客们会认为这些东西烦人──就很有可能用逻辑上无误但打发人的回复，诸如“是的，你可以得到帮助”和“不，没有给你的帮助”
一般来说，避免提“是或否”类型的问题，除非你想得到 “是或否”类型的回答。
不要刻意标明问题紧急
这是你自己的问题，不要我们的。宣称“紧急”极有可能事与愿违：大多数黑客会直接删除这种消息，他们认为这是无礼和自私地企图得到即时与特殊的关 照。
有一点点局部的例外，如果你是在一些知名度很高、会使黑客们激动的地方使用程序，也许值得这样去做。在这种情况下，如果你有期限压力，也很有礼貌 地提到这点，人们也许会有足够的兴趣快一点回答。
当然，这是非常冒险的，因为黑客们对什么是令人激动的标准多半与你的不同。譬如从国际空间站这样张贴没有问题，但代表感觉良好的慈善或政治原因这样做几乎肯定不行。事实上，张贴诸如“紧急：帮我救救这个毛绒绒的小海豹！”肯定会被黑客回避或光火，即使他们认为毛绒绒的小海豹很重要。
如果你觉得这不可思议，再把剩下的内容多读几遍，直到弄清楚了再发贴。
礼貌总是无害的
礼貌一点，使用“请”和“谢谢你的关注”或者“谢谢你的意见”，让别人明白你感谢他们无偿花时间帮助你。
坦率地说，这一点没有语法正确、文字清晰、准确、有内容和避免使用专用格式重要(同时也不能替代它们)。黑客们一般宁可读有点唐突但技术鲜明的臭虫报告，而不是那种礼貌但含糊的报告。(如果这点让你不解，记住我们是按问题能教我们些什么来评价一个问题的)
然尔，如果你已经谈清楚了技术问题，客气一点肯定会增加你得到有用回复的机会。
(我们必须指出，本文唯一受到一些老黑客认真反对的地方是以前曾经推荐过的“提前谢了”，一些黑客认为这隐含着事后不用再感谢任何人的暗示。我们的建议是 先说 “提前谢了”，事后再对回复者表示感谢。或者换种方式表达，譬如用“谢谢你的关注”或“谢谢你的意见”)。
问题解决后追加一条简要说明
问题解决后向所有帮助过的人追加一条消息，让他们知道问题是如何解决的并再次感谢。如果问题在邮件列表或新闻组中受到广泛关注，在那里追加此消息比 较恰当。
最理想的方式是向最初提问的线索回复此消息并在主题包含“已解决”、“已搞定”或其它同样意思的明显标记。在人来人往的邮件列表里，一个看见线索 “问题X”和“问题X-已解决”的潜在回复者就明白不用再浪费时间了(除非他个人觉得“问题X”有趣)，因此可以用此时间去解决其它 问题。
你追加的消息用不着太长太复杂，一条简单的“你好──是网线坏了！谢谢大家──比尔”就比什么都没有要强。事实上，除非解决问题的技术真正高深，一条简短而亲切的总结比长篇大论要好。说明是什么行动解决了问题，用不着重演整个排错的故事。
对于有深度的问题，张贴排错历史的摘要是适当的。描述问题的最终状态，说明是什么解决了问题，在此之后才指明可以避免的弯路。应避免的 弯路部分应放在正确的解决方案和其它总结材料之后，而不要将此消息搞成侦探推理小说。列出那些帮助过你的名字，那样你会交到朋友的。
除了有礼貌、有内容以外，这种类型的追帖将帮助其他人在邮件列表、新闻组或论坛文档中搜索到真正解决你问题的方案，从而也让他们受益。
除上述而外，此类追帖还让每位参与协助的人因问题的解决而产生一种满足感。如 果你自己 不是技术专家或黑客，相信我们，这种感觉对于你寻求帮助的老手和专家非常重要。问题叙述到最后不知所终总是令人沮丧的，黑客们痒 痒地渴望看到它们被解决。“挠痒痒”为你挣到的好报将对你下次再次张贴提问非常非常的有帮助。
考虑一下怎样才能避免其他人将来也遇到类似的问题，问问自己编一份文档或FAQ补丁有没有帮助，如果有的话就将补丁发给维护者。
在黑客中，这种行为实际上比传统的礼貌更重要，也是你善待他人而赢得声誉的方式，这是非常有价值的财富。
如何解读回答
RTFM和STFW：如何知道你已完全搞砸
有一个古老而神圣的传统：如果你收到了“RTFM”的回复，发信人认为你应该去“读读该死的手册”。他多半是对的，去读一下吧。
RTFM有个年轻的亲戚，如果你收到“STFW”的回复，发信人认为你应该“搜搜该死的网络”。他多半也是对的，去搜一下吧。(更温和一点的说法是 “Google 是你的朋友！”)
在网页论坛，你也可能被要求去搜索论坛的文档。事实上，有人甚至可能热心地为你提供以前解决此问题的线索。但不要依赖这种好心，提问前应先搜索 一下文 档。
通常，叫你搜索的人已经打开了能解决你问题的手册或网页，正在一边看一边敲键盘。这些回复意味着他认为：第一，你要的信息很容易找到。第二，自已找 要比别人喂到嘴里能学得更多。
你不应该觉得这样就被冒犯了，按黑客的标准，他没有不理你就是在向你表示某种尊敬，你反而应该感谢他热切地想帮助你。
如果还不明白
如果你看不懂回复，不要马上回发一个要求说明的消息，先试试那些最初提问时用过的同样工具(手册、FAQ，网页、懂行的朋友等)试着搞懂回 复。如果还是需要说明，展现你已经明白的。
譬如，假如我告诉你：“听起来象是某输入项有问题，你需要清除它”，接着是个不好的回帖：“什么是某输入项？”。 而这是一个好的跟帖：“是 的， 我读了手册，某输入项只在-z和-p开关中被提到，但都没有提及清除某选项，你指的是哪一个还是我弄错了什么？”
对待无礼
很多黑客圈子中看似无礼的行为并不是存心冒犯。相反，它是直接了当、一刀见血式的交流风格，这种风格对于更关注解决问题而不是使别人感觉舒服而混乱 的人 是很自然的。
你如果觉得被冒犯，努力平静地反应。如果有人真的做了过格的事，邮件列表或新闻组或论坛中的前辈多半会招呼他。如果这没有发生而你却发火了，那么你发火对 象的言语 可能在黑客社区中看起来是正常的，而你将 被视为有错的一方，这将伤害到你获取信息或帮助的机会。
另一方面，你会偶而真的碰到无礼和无聊的言行。与上述相反，对真正的冒犯者狠狠地打击、用犀利的语言将其驳得体无完肤都是可以接受的。然尔，在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔，黑客们自己莽撞地越线情况并不鲜见。如果你是新手或外来者，避开这种莽撞的机会不高。如果你 想得到的是信息而不是消磨时光，这时最好不要把手放在键盘上以免冒险。
(有些人断言很多黑客都有轻度的自闭症或阿斯伯格综合症，一定缺少平滑人类社会“正常”交往所需的脑电路。这既可能是真也可能是假。如果你自己不是 黑客，兴许 你认为我 们脑袋有问题还能帮助你应付我们的古怪行为。只管这么干好了，我们不在乎。我们喜欢我们现在这个样子，并且一般都对 临床诊断有相当的怀疑。)
在下一节，我们会谈到另一个问题，当你行为不当时会受到的“冒犯”
别象个失败者那样反应
在黑客社区的论坛中有那么几次你会搞砸──以本文详述或类似的方式。你会被示众是如何搞砸的，也许言语中还会带点颜色。
这种事发生以后，你能做的最糟的事莫过于哀嚎你的遭遇、宣称被口头攻击、要求道歉、高声尖叫、憋闷气、威胁诉诸法律、向其雇主报怨、忘了关马桶盖等 等。相 反，你该这样去做：
熬过去，这很正常。事实上，它是有益健康与恰当的。
社区的标准不会自己维持，它们是通过参与者积极而公开地执行来维持的。不要哭嚎所有的 批评都应该通过私下的邮件传送，这不是事情运作的方式。当有人批评你的 一些主张或者其看法不同时，坚持声称个人被侮辱也毫无用处，这些都是失败者的态度。
也有其它的黑客论坛，受太高礼节要求的误导，要求参与者禁止张贴任何对别人帖子挑毛病的消息，并被告知“如果你不想帮助用户就闭嘴”。有思路的参与 者纷纷 离 开 的结果只会使它们变成了毫无意义的唠叨与无用的技术论坛。
是夸张的“友谊”(以上述方式)还是有用？挑一个。
记住：当黑客说你搞砸了，并且(无论多么刺耳地)告诉你别再这样做时，他正在为关心你和他的社区而行动。对他而言，不理你并将你从他的生活中滤除要容易得多。如果你无法做到感谢，至少要有点尊严，别大声哀嚎，也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者，就指望别人象对待脆弱的洋娃娃那样对你。
有时候，即使你没有搞砸(或者只是别人想象你搞砸了)， 有些人会无缘无故地攻击你本人。在这种情况下，报怨倒是真的会把问题搞砸。
这些找茬者要么是什么也不懂但自以为是专家的不中用家伙，要么就是测试你是否真会搞砸的心理学家。其它读者要么不理睬，要么用自己的方式对付他们。 这些找茬者在给自己找麻烦，这点你不用操心。
也别让自己卷入口水战，大多数口水战最好不要理睬──当然是在你核实它们只是口水战、没有指出你搞砸的地方，而且没有巧妙地将问题真正的答案藏于其 中 (这也 是 可能的)之后。
提问禁忌
下面是些典型的愚蠢问题和黑客不回答它们时的想法。
问： 我到哪可以找到程序或X资源？
问： 我怎样用X做Y？
问： 如何配置我的shell提示？
问： 我可以用Bass-o-matic文件转换工具将AcmeCorp文档转为TeX格式 吗？
问： 我的{程序、配置、SQL语句}不运行了
问： 我的视窗电脑出问题了，你能帮忙吗？
问： 我的程序不运行了，我认为系统工具X有问题
问： 我安装Linux或X遇到困难，你能帮忙吗？
问： 我如何才能破解超级用户口令/盗取频道操作员的特权/查看某人的电子邮件？
问：
我到哪可以找到程序或X资源？
答：
在我找到它的同样地方，笨旦──在网页搜索引擎上。上帝啊，难道还有人不知道如何使用 Google 吗？
问：
我怎样用X做Y？
答：
如果你想做的是Y，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对X完全无知，也对要解决的Y问题糊涂，还被特定形势禁 锢了思维。等他们把问题弄 好再说。
问：
如何配置我的shell提示？
答：
如果你有足够的智慧提这个问题，你也该有足够的智慧去 RTFM， 然后自己去找。
问：
我可以用Bass-o-matic文件转换工具将AcmeCorp文档转为TeX格 式吗？
答：
试试就知道了。如果你试过，你既知道答案，又不用浪费我的时间了。
问：
我的{程序、配置、SQL语句}不运行了
答：
这不是一个问题，我也没有兴趣去猜你有什么问题──我有更要紧的事要做。看到这种东西，我的反应一般如下：
*
你还有什么补充吗？
*
噢，太糟了，希望你能搞定。
*
这跟我究竟有什么关系？
问：
我的视窗电脑出问题了，你能帮忙吗？
答：
是的，把视窗垃圾删了，装个象Linux或BSD的开源操作系统吧。
注意：如果程序有官方的视窗版或与视窗有交互(如Samba)，你可以问与视窗电脑相关的问题，只是别 对问题是由视窗操作系统而不是程序本身造成的回复感 到惊讶，因 为视窗一般来说太差，这种说法一般都成立。
问：
我的程序不运行了，我认为系统工具X有问题
答：
你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与库文件有明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据， 当你这样 声称时，你必须有清楚而详尽的缺陷说明文档作后盾。
问：
我安装Linux或X遇到问题，你能帮忙吗？
答：
不行，我需要亲手操作你的电脑才能帮你排错，去向当地的Linux用户组寻求方便的帮助(你可以在 这里 找到用户组列表)
注意：在为某一Linux发行版服务的邮件列表或论坛或本地用户组织中提关于安装该发行版的问题也许是恰当的。此时，应描述问题的准确 细节。在此之前，先用 “linux”和所有被怀 疑的硬件(为关键词)仔细搜索。
问：
我如何才能破解超级用户口令/盗取频道操作员的特权/查看某人的电子邮件？
答：
想做这种事情说明你是个卑劣的家伙，想让黑客教你做这种事情说明你是个白痴。
好问题与坏问题
最后，我将通过举例来演示提问的智慧。同样的问题两种问法，一种愚蠢，另一种明智。
愚蠢：我在哪能找到关于Foonly Flurbamatic设备的东西？
这个问题在乞求得到 STFW 式的回复。
明智：我用Google搜索过“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内核邮件列表的成员谈到，他认为并不是因为我的名字在列表上，而是因为我正确的提问方式 才 得到了答 案。
黑客们在某种方面是非常不留情面的精英分子。我想他是对的，如果我表现得象个不劳而获的寄生虫，不管我是谁都会被忽略或斥责。他建议将整个事件作为 对其它 人 提问的指导直接导致了本文的编写。
如果没有回复
如果得不到回答，请不要认为我们不想帮你，有时候只是因为小组成员的确不知道答案。没有回复不等于被忽略，当然必须承认从外面很难看出两者的差别。
一般来说，直接将问题再张贴一次不好，这会被视为毫无意义的骚扰。
还有其它资源可以寻求帮助，通常是在一些面向新手的资源中。
有许多在线与本地用户组织，虽然它们自己不编写任何软件，但是对软件很热心。这些用户组通常因互助和帮助新手而形成。
还有众多大小商业公司提供签约支持服务(红帽与Linuxcare是两家最出名的，还有许多其它的)。别因为要付点钱才有支持就感到沮丧！毕竟，如果你车子的 汽缸垫烧了，你多半还得花钱找个修理店把它弄好。即使软件没花你一分钱，你总不能指望服务支持都是免费的。
象Linux这样流行的软件，每个开发者至少有一万个以上的用户，一个人不可能应付这么多用户的服务要求。记住，即使你必须付费才能得到支持，也比你还得额外花钱买软件要少得多(而且对封闭源代码软件的服务支持与开源软件相比通常还要贵一点，也要差一点)
如何更好地回答 问题
态度和善一点。问题带来的压力常使人 显得无礼或愚蠢，其实并不是这样。
对初犯者私下回复。对那些坦诚犯错 之人没有必要当众羞辱，一个真正的新手也许连怎么搜索或在哪找FAQ都不知道。
如果你不确定，一定要说出来！一个听 起来权威的错误回复比没有还要糟，别因为听起来象个专家好玩就给别人乱指路。要谦虚和诚实，给提问者与同行都树个好榜样。
如果帮不了忙，别妨 碍。不要在具体步骤上开玩笑，那样也许会毁了用户的安装──有些可怜的呆瓜会把它当成真的指令。
探索性的反问以引出更多的细节。如 果你做得好，提问者可以学到点东西──你也可以。试试将很差的问题转变成好问题，别忘了我们都曾是新手。
尽管对那些懒虫报怨一声RTFM是正当的，指出文档的位置(即使只是建议做个Google关键词搜索)会更好。
如果你决意回答，给 出好的答案。当别人正使用错误的工具或不当 的方法时别建议笨拙的权宜之计，应推荐更好的工具，重新组织问题。
帮助你的社区从问题中 学习。当回复一个好问题时，问问自己 “如何修改相关文件或FAQ文档以免再次解答同样的问题？”，接着再向文档维护者发一份补丁。
如果你的确是在研究一番后才做出的回答，展 现你的技巧而不是直接端出结果。毕竟“授 人以鱼，不如授人以渔”。
相关资源
如果还需要个人电脑、Unix和互联网如何工作的基础知识，参阅 Unix 和互联网如何工作的基本原理
当你发布软件或补丁时，尝试按 软 件发布实践 指南进行。
鸣谢
Evelyn Mitchell 贡献了一些愚蠢问题样例并启发了编写“如何更好地回答问题”这一节，Mikhail Ramendik 贡献了一些特别有价值的建议和改进。
Powered by MessageSoft SMG
SPAM, virus-free and secure email
http://www.messagesoft.com
刘冲 于 2009-07-16 22:56:37发表:
[i=s] 本帖最后由 刘冲 于 2009-7-16 22:57 编辑 [/i]
, but occurred instead" is much more likely toget you a response.
How To Ask Questions The Smart WayEric Steven RaymondThyrsus Enterprises
http://www.catb.org/~esr/faqs/smart-questions.html
<[email=esr@thyrsus.com]esr@thyrsus.com[/email]>
Rick Moen
<[email=respond-auto@linuxmafia.com]respond-auto@linuxmafia.com[/email]>
Copyright © 2001,2006 Eric S. Raymond, Rick Moen
[table=98%][tr][td=3,1]Revision History[/td][/tr][tr][td]Revision 3.6[/td][td]19 Mar 2008[/td][td]esr[/td][/tr][tr][td] Minor update and new links. [/td][/tr][tr][td]Revision 3.5[/td][td]2 Jan 2008[/td][td]esr[/td][/tr][tr][td] Typo fix and some translation links. [/td][/tr][tr][td]Revision 3.4[/td][td]24 Mar 2007[/td][td]esr[/td][/tr][tr][td] New section, "When asking about code". [/td][/tr][tr][td]Revision 3.3[/td][td]29 Sep 2006[/td][td]esr[/td][/tr][tr][td=3,1] Folded in a good suggestion from Kai Niggemann. [/td][/tr][tr][td]Revision 3.2[/td][td]10 Jan 2006[/td][td]esr[/td][/tr][tr][td] Folded in edits from Rick Moen. [/td][/tr][tr][td]Revision 3.1[/td][td]28 Oct 2004[/td][td]esr[/td][/tr][tr][td] Document 'Google is your friend!' [/td][/tr][tr][td]Revision 3.0[/td][td]2 Feb 2004[/td][td]esr[/td][/tr][tr][td] Major addition of stuff about proper etiquette on Web forums. [/td][/tr][/table]
Table of Contents
TranslationsDisclaimerIntroductionBefore You AskWhen You AskChoose your forum carefullyWeb and IRC forums directed towardsnewbies often give the quickest responseAs a second step, use project mailing listsUse meaningful, specific subject headersMake it easy to replyWrite in clear, grammatical, correctly-spelled languageSend questions in accessible, standard formatsBe precise and informative about your problemVolume is not precisionDon't claim that you have found a bugGrovelling is not a substitute for doing your homeworkDescribe the problem's symptoms, not your guessesDescribe your problem's symptoms in chronological orderDescribe the goal, not the stepDon't ask people to reply by private e-mailBe explicit about your questionWhen asking about codeDon't post homework questionsPrune pointless queriesDon't flag your question as “Urgent”, even if it is for youCourtesy never hurts, and sometimes helpsFollow up with a brief note on the solutionHow To Interpret AnswersRTFM and STFW: How To Tell You've Seriously Screwed UpIf you don't understand...Dealing with rudenessOn Not Reacting Like A LoserQuestions Not To AskGood and Bad QuestionsIf You Can't Get An AnswerHow To Answer Questions in a Helpful WayRelated ResourcesAcknowledgements
Translations
Translations:Bahasa IndonesianBrazilo-PortugueseChineseCzechDanishDutchEstonianFinnishFrenchGeorgianGermanGreekHebrewHungarianItalianJapanesePolishPortugueseRomanianRussianSerbianSpanishSwedishThaiTurkish.If you want to copy, mirror, translate, or excerpt this document,please see my copying policy.
Disclaimer
Many project websites link to this document in their sections onhow to get help. That's fine, it's the use we intended -- but ifyou are a webmaster creating such a link for your project page, pleasedisplay prominently near the link notice that we are not ahelp desk for your project!
We have learned the hard way that without such a notice, we willrepeatedly be pestered by idiots who think having published thisdocument makes it our job to solve all the world's technicalproblems.
If you're reading this document because you need help, and youwalk away with the impression you can get it directly from the authorsof this document, you are one of the idiots inquestion. Don't ask us questions. We'll justignore you. We are here to show you how to get help from people whoactually know about the software or hardware you're dealing with, but99.9% of the time that will not be us. Unless you know forcertain that one of the authors is an expert onwhat you're dealing with, leave us alone and everybody will behappier.
Introduction
In the world of hackers, the kind ofanswers you get to your technical questions depends as much on the wayyou ask the questions as on the difficulty of developing the answer.This guide will teach you how to ask questions in a way more likelyto get you a satisfactory answer.
Now that use of open source has become widespread, you canoften get as good answers from other, more experienced users as fromhackers. This is a Good Thing; users tend to be just a little bit moretolerant of the kind of failures newbies often have. Still, treatingexperienced users like hackers in the ways we recommend here willgenerally be the most effective way to get useful answers out of them,too.
The first thing to understand is that hackers actually like hardproblems and good, thought-provoking questions about them. If wedidn't, we wouldn't be here. If you give us an interesting questionto chew on we'll be grateful to you; good questions are a stimulus anda gift. Good questions help us develop our understanding, and oftenreveal problems we might not have noticed or thought about otherwise.Among hackers, “Good question!” is a strong and sincerecompliment.
Despite this, hackers have a reputation for meeting simplequestions with what looks like hostility or arrogance. It sometimeslooks like we're reflexively rude to newbies and the ignorant. Butthis isn't really true.
What we are, unapologetically, is hostile to people who seem tobe unwilling to think or to do their own homework before askingquestions. People like that are time sinks -- they take withoutgiving back, and they waste time we could have spent on another questionmore interesting and another person more worthy of an answer. We callpeople like this “losers” (and for historical reasons wesometimes spell it “lusers”).
We realize that there are many people who just want to use thesoftware we write, and who have no interest in learning technicaldetails. For most people, a computer is merely a tool, a means to anend; they have more important things to do and lives to live. Weacknowledge that, and don't expect everyone to take an interest in thetechnical matters that fascinate us. Nevertheless, our style ofanswering questions is tuned for people who dotake such an interest and are willing to be active participants inproblem-solving. That's not going to change. Nor should it; if itdid, we would become less effective at the things we do best.
We're (largely) volunteers. We take time out of busy lives toanswer questions, and at times we're overwhelmed with them. So wefilter ruthlessly. In particular, we throw away questions from peoplewho appear to be losers in order to spend our question-answering timemore efficiently, on winners.
If you find this attitude obnoxious, condescending, or arrogant,check your assumptions. We're not asking you to genuflect to us-- in fact, most of us would love nothing more than to deal withyou as an equal and welcome you into our culture, if you put in theeffort required to make that possible. But it's simply not efficientfor us to try to help people who are not willing to helpthemselves. It's OK to be ignorant; it's not OK to play stupid.
So, while it isn't necessary to already be technically competentto get attention from us, it is necessary todemonstrate the kind of attitude that leads to competence --alert, thoughtful, observant, willing to be an active partner indeveloping a solution. If you can't live with this sort ofdiscrimination, we suggest you pay somebody for a commercial supportcontract instead of asking hackers to personally donate help toyou.
If you decide to come to us for help, you don't want to be oneof the losers. You don't want to seem like one, either. The best wayto get a rapid and responsive answer is to ask it like a person withsmarts, confidence, and clues who just happens to need help on oneparticular problem.
(Improvements to this guide are welcome. You can mailsuggestions to [email=esr@thyrsus.com]esr@thyrsus.com[/email] or respond-auto@linuxmafia.com.Note however that this document is not intended to be a general guideto netiquette, and wewill generally reject suggestions that are not specifically related toeliciting useful answers in a technical forum.)
Before You Ask
Before asking a technical question by e-mail, or in a newsgroup, or on awebsite chat board, do the following:
[list=1][*]Try to find an answer by searching the archives of theforum you plan to post to.[*]Try to find an answer by searching the Web.[*]Try to find an answer by reading the manual.[*]Try to find an answer by reading a FAQ.[*]Try to find an answer by inspection or experimentation.[*]Try to find an answer by asking a skilled friend.[*]If you're a programmer, try to find an answer by readingthe source code.[/list]
When you ask your question, display the fact that you have donethese things first; this will help establish that you're not being alazy sponge and wasting people's time. Better yet, display what you havelearned from doing these things. We like answeringquestions for people who have demonstrated they can learn fromthe answers.
Use tactics like doing a Google search on the text of whatevererror message you get (searching Google groups as well as Webpages). This might well take you straight to fix documentation or amailing list thread answering your question. Even if it doesn't,saying “I googled on the following phrase but didn't getanything that looked promising” is a good thing to do in e-mailor news postings requesting help, if only because it records whatsearches won't help. It will also help to direct other people withsimilar problems to your thread by linking the search terms to whatwill hopefully be your problem and resolution thread.
Take your time. Do not expect to be able to solve a complicatedproblem with a few seconds of Googling. Read and understand the FAQs,sit back, relax and give the problem some thought before approachingexperts. Trust us, they will be able to tell from your questions howmuch reading and thinking you did, and will be more willing to helpif you come prepared. Don't instantly fire your whole arsenal ofquestions just because your first search turned up no answers (or toomany).
Prepare your question. Think it through. Hasty-soundingquestions get hasty answers, or none at all. The more you do to demonstrate that having put thought and effort into solvingyour problem before seeking help, the more likely you are toactually get help.
Beware of asking the wrong question. If you ask one that isbased on faulty assumptions, J. Random Hacker is quite likely to replywith a uselessly literal answer while thinking “Stupidquestion...”, and hoping the experience of getting whatyou asked for rather than what you needed will teach you alesson.
Never assume you are entitled to an answer.You are not; you aren't, after all, paying for the service. You willearn an answer, if you earn it, by asking a substantial, interesting,and thought-provoking question -- one that implicitly contributesto the experience of the community rather than merely passivelydemanding knowledge from others.
On the other hand, making it clear that you are able and willingto help in the process of developing the solution is a very goodstart. “Would someone provide a pointer?”, “What is myexample missing?”, and “What site should I havechecked?” are more likely to get answered than “Pleasepost the exact procedure I should use.” because you're making itclear that you're truly willing to complete the process if someone canjust point you in the right direction.
When You Ask
Choose your forum carefully
Be sensitive in choosing where you ask your question. You arelikely to be ignored, or written off as a loser, if you:
[list][*]post your question to a forum where it's off topic[*]post a very elementary question to a forum whereadvanced technical questions are expected, or vice-versa[*]cross-post to too many different newsgroups[*]post a personal e-mail to somebody who is neitheran acquaintance of yours nor personally responsible for solving your problem[/list]
Hackers blow off questions that are inappropriately targeted inorder to try to protect their communications channels from beingdrowned in irrelevance. You don't want this to happen to you.
The first step, therefore, is to find the right forum. Again,Google and other Web-searching methods are your friend. Use them tofind the project webpage most closely associated with the hardware orsoftware giving you difficulties. Usually it will have links to a FAQ(Frequently Asked Questions) list, and to project mailing lists andtheir archives. These mailing lists are the final places to go forhelp, if your own efforts (including readingthose FAQs you found) do not find you a solution. The project pagemay also describe a bug-reporting procedure, or have a link to one; ifso, follow it.
Shooting off an e-mail to a person or forum which you are notfamiliar with is risky at best. For example, do not assume that theauthor of an informative webpage wants to be your free consultant.Do not make optimistic guesses about whether your question will bewelcome -- if you're unsure, send it elsewhere, or refrain fromsending it at all.
When selecting a Web forum, newsgroup or mailing list, don'ttrust the name by itself too far; look for a FAQ or charter to verifyyour question is on-topic. Read some of the back traffic beforeposting so you'll get a feel for how things are done there. In fact,it's a very good idea to do a keyword search for words relating toyour problem on the newsgroup or mailing list archives before youpost. It may find you an answer, and if not it will help youformulate a better question.
Don't shotgun-blast all the available help channels at once, that'slike yelling and irritates people. Step through them softly.
Know what your topic is! One of the classic mistakes is askingquestions about the Unix or Windows programming interface in a forumdevoted to a language or library or tool portable across both.If you don't understand why this is a blunder, you'd be best off notasking any questions at all until you get it.
In general, questions to a well-selected public forum are morelikely to get useful answers than equivalent questions to a privateone. There are multiple reasons for this. One is simply the size ofthe pool of potential respondents. Another is the size of theaudience; hackers would rather answer questions that educate manypeople than questions serving only a few.
Understandably, skilled hackers and authors of popular software arealready receiving more than their fair share of mis-targeted messages.By adding to the flood, you could in extreme cases even be the strawthat breaks the camel's back -- quite a few times, contributors topopular projects have withdrawn their support because collateraldamage in the form of useless e-mail traffic to their personal accountsbecame unbearable.
Web and IRC forums directed towardsnewbies often give the quickest response
Your local user group, or your Linux distribution, may advertisea Web forum or IRC channel where newbies can get help. (Innon-English-speaking countries newbie forums are still more likely tobe mailing lists.) These are good first places to ask, especially ifyou think you may have tripped over a relatively simple or commonproblem. An advertised IRC channel is an open invitation to askquestions there and often get answers in real time.
In fact, if you got the program that is giving you problems froma Linux distribution (as common today), it may be better to ask in thedistro's forum/list before trying the program's project forum/list. Theproject's hackers may just say, “use ourbuild”.
Before posting to any Web forum, check if it has a Searchfeature. If it does, try a couple of keyword searches forsomething like your problem; it just might help. If you did a generalWeb search before (as you should have), search the forum anyway; yourWeb-wide search engine might not have all of this forum indexedrecently.
There is an increasing tendency for projects to do user supportover a Web forum or IRC channel, with e-mail reserved more fordevelopment traffic. So look for those channels first when seekingproject-specific help.
As a second step, use project mailing lists
When a project has a development mailing list, write to themailing list, not to individual developers, even if you believeyou know who can best answer your question. Check the documentationof the project and its homepage for the address of a project mailinglist, and use it. There are several good reasons for thispolicy:
[list][*]Any question good enough to be asked of onedeveloper will also be of value to the whole group. Contrariwise, ifyou suspect your question is too dumb for a mailing list, it's notan excuse to harass individual developers.[*]Asking questions on the list distributes load amongdevelopers. The individual developer (especially if he's the projectleader) may be too busy to answer your questions.[*]Most mailing lists are archived and the archives areindexed by search engines. If you ask your question on-list and it isanswered, a future querent could find your question and the answer onthe Web instead of asking it again.[*]If certain questions are seen to be asked often,developers can use that information to improve the documentation or thesoftware itself to be less confusing. But if those questions areasked in private, nobody has the complete picture of what questionsare asked most often.[/list]
If a project has both a “user” and a“developer” (or “hacker”) mailing list orWeb forum, and you are not hacking on the code, ask in the“user” list/forum. Do not assume that you willbe welcome on the developer list, where they're likely to experienceyour question as noise disrupting their developer traffic.
However, if you are sure your question isnon-trivial, and you get no answer in the “user”list/forum for several days, try the “developer” one.You would be well advised to lurk there for a few days before postingto learn the local folkways (actually this is good advice on anyprivate or semi-private list).
If you cannot find a project's mailing list address, but onlysee the address of the maintainer of the project, go ahead and writeto the maintainer. But even in that case, don't assume that themailing list doesn't exist. Mention in your e-mail that you tried andcould not find the appropriate mailing list. Also mention that youdon't object to having your message forwarded to other people. (Manypeople believe that private e-mail should remain private, even ifthere is nothing secret in it. By allowing your message to beforwarded you give your correspondent a choice about how to handleyour e-mail.)
Use meaningful, specific subject headers
On mailing lists, newsgroups or Web forums, the subject headeris your golden opportunity to attract qualified experts' attention inaround 50 characters or fewer. Don't waste it on babble like“Please help me” (let alone “PLEASE HELPME!!!!”; messages with subjects like that get discarded byreflex). Don't try to impress us with the depth of your anguish; usethe space for a super-concise problem description instead.
One good convention for subject headers, used by many tech supportorganizations, is “object - deviation”. The“object” part specifies what thing or group of things ishaving a problem, and the “deviation” part describes thedeviation from expected behavior.
Stupid:HELP! Video doesn't work properly on my laptop!
Smart:X.org 6.8.1 misshapen mouse cursor, Fooware MV1005 vid. chipset
Smarter: X.org 6.8.1 mouse cursor on Fooware MV1005 vid. chipset - is misshapen
The process of writing an “object-deviation”description will help you organize your thinking about the problem inmore detail. What is affected? Just the mouse cursor or othergraphics too? Is this specific to the X.org version of X? To version6.8.1? Is this specific to Fooware video chipsets? To model MV1005? Ahacker who sees the result can immediately understand what it is thatyou are having a problem with and the problem youare having, at a glance.
More generally, imagine looking at the index of an archive ofquestions, with just the subject lines showing. Make your subjectline reflect your question well enough that the next guy searching thearchive with a question similar to yours will be able to follow thethread to an answer rather than posting the question again.
If you ask a question in a reply, be sure to change the subjectline to indicate that you're asking a question. A Subject line thatlooks like “Re: test” or “Re: new bug” isless likely to attract useful amounts of attention. Also, pare quotationof previous messages to the minimum consistent with cluing in newreaders.
Do not simply hit reply to a list message in order to start anentirely new thread. This will limit your audience. Some mail readers,like mutt, allow the user to sort by thread and then hide messages ina thread by folding the thread. Folks who do that will never see yourmessage.
Changing the subject is not sufficient. Mutt, and probably other mailreaders, looks at other information in the e-mail's headers to assignit to a thread, not the subject line. Instead start an entirely newe-mail.
On Web forums the rules of good practice are slightly different,because messages are usually much more tightly bound to specificdiscussion threads and often invisible outside those threads.Changing the subject when asking a question in reply is not essential.Not all forums even allow separate subject lines on replies, andnearly nobody reads them when they do. However, asking a question in areply is a dubious practice in itself, because it will only be seen bythose who are watching this thread. So, unless you are sure youwant to ask only the people currently active in thethread, start a new one.
Make it easy to reply
Finishing your query with “Please send your replyto... ” makes it quite unlikely you will get an answer. If youcan't be bothered to take even the few seconds required to set up acorrect Reply-To header in your mail agent, we can't be bothered totake even a few seconds to think about your problem. If your mailprogram doesn't permit this, get a better mailprogram. If your operating system doesn't support any e-mailprograms that permit this, get a better operating system.
In Web forums, asking for a reply by e-mail is outright rude,unless you believe the information may be sensitive (and somebodywill, for some unknown reason, let you but not the whole forum knowit). If you want an e-mail copy when somebody replies in the thread,request that the Web forum send it; this feature is supportedalmost everywhere under options like “watch this thread”,“send e-mail on answers”, etc.
Write in clear, grammatical, correctly-spelled language
We've found by experience that people who are careless andsloppy writers are usually also careless and sloppy at thinking andcoding (often enough to bet on, anyway). Answering questions forcareless and sloppy thinkers is not rewarding; we'd rather spend ourtime elsewhere.
So expressing your question clearly and well is important. Ifyou can't be bothered to do that, we can't be bothered to payattention. Spend the extra effort to polish your language. Itdoesn't have to be stiff or formal -- in fact, hacker culturevalues informal, slangy and humorous language used with precision.But it has to be precise; there has to be someindication that you're thinking and paying attention.
Spell, punctuate, and capitalize correctly. Don't confuse“its” with “it's”, “loose” with“lose”, or “discrete” with“discreet”. Don't TYPE IN ALL CAPS; this is read asshouting and considered rude. (All-smalls is only slightly lessannoying, as it's difficult to read. Alan Cox can get away with it,but you can't.)
More generally, if you write like a semi-literate boob you willvery likely be ignored. So don't use instant-messaging shortcuts.Spelling "you" as "u" makes you look like a semi-literate boob to savetwo entire keystrokes. Worse: writing like a l33t script kiddie hax0r isthe absolute kiss of death and guarantees you will receive nothing butstony silence (or, at best, a heaping helping of scorn and sarcasm) inreturn.
If you are asking questions in a forum that does not use yournative language, you will get a limited amount of slack for spellingand grammar errors -- but no extra slack at all for laziness (andyes, we can usually spot that difference). Also, unless you know whatyour respondent's languages are, write in English. Busy hackers tendto simply flush questions in languages they don't understand, andEnglish is the working language of the Internet. By writing inEnglish you minimize your chances that your question will be discardedunread.
Send questions in accessible, standard formats
If you make your question artificially hard to read, it is morelikely to be passed over in favor of one that isn't. So:
[list][*]Send plain text mail, not HTML. (It's not hardto turn off HTML.)[*]MIME attachments are usually OK, but only if they arereal content (such as an attached source file or patch), and notmerely boilerplate generated by your mail client (such as another copyof your message).[*] Don't send e-mail in which entire paragraphs are singlemultiply-wrapped lines. (This makes it too difficult to reply to just part of the message.) Assume that your respondents will bereading mail on 80-character-wide text displays and set your line wrap accordingly, to something less than 80.[*] However, do not wrap data (suchas log file dumps or session transcripts) at any fixed column width.Data should be included as-is, so respondents can have confidencethat they are seeing what you saw.[*]Don't send MIME Quoted-Printable encoding to anEnglish-language forum. This encoding can be necessary when you'reposting in a language ASCII doesn't cover, but many e-mail agentsdon't support it. When they break, all those =20 glyphs scatteredthrough the text are ugly and distracting -- or may activelysabotage the semantics of your text.[*] Never, ever expect hackers to beable to read closed proprietary document formats like Microsoft Wordor Excel. Most hackers react to these about as well as you would tohaving a pile of steaming pig manure dumped on your doorstep. Evenwhen they can cope, they resent having to do so.[*]If you're sending e-mail from a Windows machine, turnoff Microsoft's stupid “Smart Quotes” feature. This isso you'll avoid sprinkling garbage characters through your mail.[*]In Web forums, do not abuse “smiley” and“HTML” features (when they are present). A smiley or twois usually OK, but colored fancy text tends to make people think youare lame. Seriously overusing smileys and color and fonts will makeyou come off like a giggly teenage girl, which is not generally a goodidea unless you are more interested in sex than answers.[/list]
If you're using a graphical-user-interface mail client such asNetscape Messenger, MS Outlook, or their ilk, beware that it mayviolate these rules when used with its default settings. Most suchclients have a menu-based “View Source” command. Usethis on something in your sent-mail folder, verifying sending of plaintext without unnecessary attached crud.
Be precise and informative about your problem
[list][*]Describe the symptoms of your problem or bug carefully and clearly.[*]Describe the environment in which it occurs (machine, OS, application,whatever). Provide your vendor's distribution and release level(e.g.: “Fedora Core 7”, “Slackware 9.1”, etc.).[*]Describe the research you did to try and understand the problem before you asked the question.[*]Describe the diagnostic steps you took to try and pin down the problemyourself before you asked the question.[*]Describe any possibly relevant recent changes in your computer orsoftware configuration.[/list]
Do the best you can to anticipate the questions a hacker willask, and answer them in advance in your request for help.
Simon Tatham has written an excellent essay entitled How toReport Bugs Effectively. I strongly recommend thatyou read it.
Volume is not precision
You need to be precise and informative. This end is not servedby simply dumping huge volumes of code or data into a help request.If you have a large, complicated test case that is breaking a program,try to trim it and make it as small as possible.
This is useful for at least three reasons. One: being seen toinvest effort in simplifying the question makes it more likely you'll get an answer, Two: simplifying the question makes it morelikely you'll get a useful answer. Three:In the process of refining your bug report, you may develop a fix or workaround yourself.
Don't claim that you have found a bug
When you are having problems with a piece of software, don'tclaim you have found a bug unless you are very,very sure of your ground. Hint: unless you canprovide a source-code patch that fixes the problem, or a regressiontest against a previous version that demonstrates incorrect behavior,you are probably not sure enough. This applies to webpages anddocumentation, too; if you have found a documentation“bug”, you should supply replacement text and which pagesit should go on.
Remember, there are many other users that are notexperiencing your problem. Otherwise you would have learned about itwhile reading the documentation and searching the Web (you did do thatbefore complaining, didn't you?). Thismeans that very probably it is you who are doing something wrong, notthe software.
The people who wrote the software work very hard to make it workas well as possible. If you claim you have found a bug, you'll beimpugning their competence, which may offend some of them even if youare correct. It's especially undiplomatic to yell “bug”in the Subject line.
When asking your question, it is best to write as though youassume you are doing something wrong, even if youare privately pretty sure you have found an actual bug. If therereally is a bug, you will hear about it in the answer. Play it so themaintainers will want to apologize to you if the bug is real, ratherthan so that you will owe them an apology if you have messed up.
Grovelling is not a substitute for doing your homework
Some people who get that they shouldn't behave rudely orarrogantly, demanding an answer, retreat to the opposite extreme ofgrovelling. “I know I'm just a pathetic newbie loser,but...”. This is distracting and unhelpful. It's especiallyannoying when it's coupled with vagueness about the actualproblem.
Don't waste your time, or ours, on crude primate politics.Instead, present the background facts and your question as clearly asyou can. That is a better way to position yourself than bygrovelling.
Sometimes Web forums have separate places for newbie questions. If youfeel you do have a newbie question, just go there. But don't grovel thereeither.
Describe the problem's symptoms, not your guesses
It's not useful to tell hackers what you think is causing yourproblem. (If your diagnostic theories were such hot stuff, would yoube consulting others for help?) So, make sure you're telling them theraw symptoms of what goes wrong, rather than your interpretations andtheories. Let them do the interpretation and diagnosis. If you feelit's important to state your guess, clearly label it as such anddescribe why that answer isn't working for you.
Stupid:I'm getting back-to-back SIG11 errors on kernel compiles, and suspect ahairline crack on one of the motherboard traces. What's the best way tocheck for those?
Smart:My home-built K6/233 on an FIC-PA2007 motherboard (VIA Apollo VP2chipset) with 256MB Corsair PC133 SDRAM starts getting frequent SIG11errors about 20 minutes after power-on during the course of kernelcompiles, but never in the first 20 minutes. Rebooting doesn't restartthe clock, but powering down overnight does. Swapping out all RAMdidn't help. The relevant part of a typical compile session logfollows.
Since the preceding point seems to be a tough one for many people tograsp, here's a phrase to remind you: "All diagnosticians are fromMissouri." That US state's official motto is "Show me" (earned in1899, when Congressman Willard D. Vandiver said "I come from a countrythat raises corn and cotton and cockleburs and Democrats, and frothyeloquence neither convinces nor satisfies me. I'm from Missouri.You've got to show me.") In diagnosticians' case, it's not a matter ofskepticism, but rather a literal, functional need to see whatever isas close as possible to the same raw evidence that you see, ratherthan your surmises and summaries. Show us.
Describe your problem's symptoms in chronological order
The clues most useful in figuring out something that went wrongoften lie in the events immediately prior. So, your account shoulddescribe precisely what you did, and what the machine and softwaredid, leading up to the blowup. In the case of command-line processes,having a session log (e.g., using the script utility) and quoting therelevant twenty or so lines is very useful.
If the program that blew up on you has diagnostic options (suchas -v for verbose), try to select options that will add usefuldebugging information to the transcript. Remember that more is notnecessarily better; try to choose a debug level that will informrather than drowning the reader in junk.
If your account ends up being long (more than about four paragraphs),it might be useful to succinctly state the problem up top, thenfollow with the chronological tale. That way, hackers will knowwhat to watch for in reading your account.
Describe the goal, not the step
If you are trying to find out how to do something (as opposed toreporting a bug), begin by describing the goal. Only then describethe particular step towards it that you are blocked on.
Often, people who need technical help have a high-level goal inmind and get stuck on what they think is one particular path towardsthe goal. They come for help with the step, but don't realize thatthe path is wrong. It can take substantial effort to get pastthis.
Stupid:How do I get the color-picker on the FooDraw program to take ahexadecimal RGB value?
Smart:I'm trying to replace the color table on an image with valuesof my choosing. Right now the only way I can see to do this is byediting each table slot, but I can't get FooDraw's color picker to take a hexadecimal RGB value.
The second version of the question is smart. It allows ananswer that suggests a tool better suited to the task.
Don't ask people to reply by private e-mail
Hackers believe solving problems should be a public, transparentprocess during which a first try at an answer can and should becorrected if someone more knowledgeable notices that it is incomplete orincorrect. Also, helpers get some of their reward for beingrespondents from being seen to be competent and knowledgeable bytheir peers.
When you ask for a private reply, you are disrupting both theprocess and the reward. Don't do this. It's therespondent's choice whether to reply privately -- and if he does, it's usually because he thinks the question istoo ill-formed or obvious to be interesting to others.
There is one limited exception to this rule. If you thinkthe question is such that you are likely to get many answers thatare all closely similar, then the magic words are “e-mail me and I'llsummarize the answers for the group”. It is courteous to try and save the mailing list or newsgroup a flood of substantially identicalpostings -- but you have to keep the promise to summarize.
Be explicit about your question
Open-ended questions tend to be perceived as open-ended timesinks. Those people most likely to be able to give you a useful answerare also the busiest people (if only because they take on the mostwork themselves). People like that are allergic to open-ended timesinks, thus they tend to be allergic to open-ended questions.
You are more likely to get a useful response if you areexplicit about what you want respondents to do (provide pointers,send code, check your patch, whatever). This will focus their effort and implicitly put an upper bound on the time and energy a respondent must allocate to helping you. This is good.
To understand the world the experts live in, think of expertiseas an abundant resource and time to respond as a scarce one. The lessof a time commitment you implicitly ask for, the more likely you areto get an answer from someone really good and really busy.
So it is useful to frame your question to minimize the timecommitment required for an expert to field it -- but this isoften not the same thing as simplifying the question. Thus, forexample, “Would you give me a pointer to a good explanation ofX?” is usually a smarter question than “Would you explainX, please?”. If you have some malfunctioning code, it isusually smarter to ask for someone to explain what's wrong with itthan it is to ask someone to fix it.
When asking about code
Don't ask others to debug your broken code without giving a hintwhat sort of problem they should be searching for. Posting a fewhundred lines of code, saying "it doesn't work", will get you ignored.Posting a dozen lines of code, saying "after line 7 I was expecting tosee
If you simply want a code review, say as much up front, and besure to mention what areas you think might particularly need reviewand why.
Don't post homework questions
Hackers are good at spotting homework questions; most of us havedone them ourselves. Those questions are for you to work out, so that you will learn from the experience. It is OK toask for hints, but not for entire solutions.
If you suspect you have been passed a homework question, butcan't solve it anyway, try asking in a user group forum or (as a lastresort) in a “user” list/forum of a project. While thehackers will spot it, some of the advanced usersmay at least give you a hint.
Prune pointless queries
Resist the temptation to close your request for help withsemantically-null questions like “Can anyone help me?” or“Is there an answer?” First: if you've written yourproblem description halfway competently, such tacked-on questions areat best superfluous. Second: because they are superfluous, hackersfind them annoying -- and are likely to return logicallyimpeccable but dismissive answers like “Yes, you can behelped” and “No, there is no help for you.”
In general, asking yes-or-no questions is a good thing to avoidunless you want a yes-or-noanswer.
Don't flag your question as “Urgent”, even if it is for you
That's your problem, not ours. Claiming urgency is very likelyto be counter-productive: most hackers will simply delete suchmessages as rude and selfish attempts to elicit immediate and specialattention.
There is one semi-exception. It can be worth mentioning ifyou're using the program in some high-profile place, one that thehackers will get excited about; in such a case, if you're under timepressure, and you say so politely, people may get interested enough toanswer faster.
This is a very risky thing to do, however, because the hackers'metric for what is exciting probably differs from yours. Posting fromthe International Space Station would qualify, for example, butposting on behalf of a feel-good charitable or political cause wouldalmost certainly not. In fact, posting “Urgent: Help me save the fuzzy baby seals!” will reliably get you shunned or flamedeven by hackers who think fuzzy baby seals are important.
If you find this mysterious, re-read the rest of this how-torepeatedly until you understand it before posting anything atall.
Courtesy never hurts, and sometimes helps
Be courteous. Use “Please” and “Thanks foryour attention” or “Thanks for yourconsideration”. Make it clear you appreciate the timepeople spend helping you for free.
To be honest, this isn't as important as (and cannot substitutefor) being grammatical, clear, precise and descriptive, avoidingproprietary formats etc.; hackers in general would rather get somewhatbrusque but technically sharp bug reports than polite vagueness. (Ifthis puzzles you, remember that we value a question by what it teachesus.)
However, if you've got your technical ducks in a row,politeness does increase your chances of getting a usefulanswer.
(We must note that the only serious objection we've receivedfrom veteran hackers to this HOWTO is with respect to our previousrecommendation to use “Thanks in advance”. Some hackersfeel this connotes an intention not to thank anybody afterwards. Ourrecommendation is to either say “Thanks in advance” firstand thank respondents afterwards, or expresscourtesy in a different way, such as by saying “Thanks for yourattention” or “Thanks for yourconsideration”.)
Follow up with a brief note on the solution
Send a note after the problem has been solved to all who helpedyou; let them know how it came out and thank them again for theirhelp. If the problem attracted general interest in a mailing list ornewsgroup, it's appropriate to post the followup there.
Optimally, the reply should be to the thread started by theoriginal question posting, and should have ‘FIXED’,‘RESOLVED’ or an equally obvious tag in the subject line.On mailing lists with fast turnaround, a potential respondent who seesa thread about “Problem X” ending with “Problem X -FIXED” knows not to waste his/her time even reading the thread(unless (s)he) personally finds Problem X interesting) and cantherefore use that time solving a different problem.
Your followup doesn't have to be long and involved; a simple“Howdy -- it was a failed network cable! Thanks, everyone. -Bill” would be better than nothing. In fact, a short and sweetsummary is better than a long dissertation unless the solution hasreal technical depth. Say what action solved the problem, but youneed not replay the whole troubleshooting sequence.
For problems with some depth, it is appropriate to post asummary of the troubleshooting history. Describe your final problemstatement. Describe what worked as a solution, and indicate avoidableblind alleys after that. The blind alleys shouldcome after the correct solution and other summary material, ratherthan turning the follow-up into a detective story. Name the names ofpeople who helped you; you'll make friends that way.
Besides being courteous and informative, this sort of followupwill help others searching the archive of the mailing-list/newsgroup/forumto know exactly which solution helped you and thus may also helpthem.
Last, and not least, this sort of followup helps everybody whoassisted feel a satisfying sense of closure about the problem. If youare not a techie or hacker yourself, trust us that this feeling isvery important to the gurus and experts you tapped for help. Problemnarratives that trail off into unresolved nothingness are frustratingthings; hackers itch to see them resolved. The goodwill thatscratching that itch earns you will be very, very helpful to you nexttime you need to pose a question.
Consider how you might be able to prevent others from having thesame problem in the future. Ask yourself if a documentation or FAQpatch would help, and if the answer is yes send that patch to themaintainer.
Among hackers, this sort of good followup behavior is actuallymore important than conventional politeness. It's how you get areputation for playing well with others, which can be a very valuableasset.
How To Interpret Answers
RTFM and STFW: How To Tell You've Seriously Screwed Up
There is an ancient and hallowed tradition: if you get a replythat reads “RTFM”, the person who sent it thinks youshould have Read The Fucking Manual. He or she is almost certainly right.Go read it.
RTFM has a younger relative. If you get a reply that reads“STFW”, the person who sent it thinks you should haveSearched The Fucking Web. He or she is almost certainly right. Go searchit. (The milder version of this is when you are told “Google isyour friend!”)
In Web forums, you may also be told to search the forumarchives. In fact, someone may even be so kind as to provide a pointerto the previous thread where this problem was solved. But do not relyon this consideration; do your archive-searching before asking.
Often, the person telling you to do a search has the manualor the web page with the information you need open, and is looking atit as he or she types. These replies mean that he thinks (a) the informationyou need is easy to find, and (b) you will learn more if you seek outthe information than if you have it spoon-fed to you.
You shouldn't be offended by this; by hacker standards, yourrespondent is showing you a rough kind of respect simply by notignoring you. You should instead be thankful for this grandmotherlykindness.
If you don't understand...
If you don't understand the answer, do not immediately bounceback a demand for clarification. Use the same tools that you used totry and answer your original question (manuals, FAQs, the Web, skilledfriends) to understand the answer. Then, if you still need to ask forclarification, exhibit what you have learned.
For example, suppose I tell you: “It sounds like you'vegot a stuck zentry; you'll need to clear it.” Then: here's abad followup question: “What's azentry?” Here's a good followupquestion: “OK, I read the man page and zentries are onlymentioned under the -z and -p switches. Neither of them says anythingabout clearing zentries. Is it one of these or am I missing somethinghere?”
Dealing with rudeness
Much of what looks like rudeness in hacker circles is notintended to give offense. Rather, it's the product of the direct,cut-through-the-bullshit communications style that is natural topeople who are more concerned about solving problems than makingothers feel warm and fuzzy.
When you perceive rudeness, try to react calmly. If someoneis really acting out, it is very likely a senior person on thelist or newsgroup or forum will call him or her on it. If that doesn't happen and you lose your temper, itis likely that the person you lose it at was behaving within thehacker community's norms and you will beconsidered at fault. This will hurt your chances of getting theinformation or help you want.
On the other hand, you will occasionally run across rudeness andposturing that is quite gratuitous. The flip-side of the above isthat it is acceptable form to slam real offenders quite hard,dissecting their misbehavior with a sharp verbal scalpel. Be very,very sure of your ground before you try this, however. The linebetween correcting an incivility and starting a pointless flamewar is thinenough that hackers themselves not infrequently blunder across it; ifyou are a newbie or an outsider, your chances of avoiding such ablunder are low. If you're after information rather than entertainment,it's better to keep your fingers off the keyboard than to risk this.
(Some people assert that many hackers have a mild form of autismor Asperger's Syndrome, and are actually missing some of the braincircuitry that lubricates “normal” human socialinteraction. This may or may not be true. If you are not a hackeryourself, it may help you cope with our eccentricities if you think ofus as being brain-damaged. Go right ahead. We won't care; welike being whatever it is we are, and generallyhave a healthy skepticism about clinical labels.)
In the next section, we'll talk about a different issue; the kind of “rudeness” you'll see when you misbehave.
On Not Reacting Like A Loser
Odds are you'll screw up a few times on hacker communityforums -- in ways detailed in this article, or similar. Andyou'll be told exactly how you screwed up, possibly with colourfulasides. In public.
When this happens, the worst thing you can do is whine about theexperience, claim to have been verbally assaulted, demand apologies,scream, hold your breath, threaten lawsuits, complain to people'semployers, leave the toilet seat up, etc. Instead, here's what youdo:
Get over it. It's normal. In fact, it's healthy and appropriate.
Community standards do not maintain themselves: They'remaintained by people actively applying them, visibly, inpublic. Don't whine that all criticism should have beenconveyed via private e-mail: That's not how it works. Nor is it usefulto insist you've been personally insulted when someone comments thatone of your claims was wrong, or that his views differ. Those areloser attitudes.
There have been hacker forums where, out of some misguided sense ofhyper-courtesy, participants are banned from posting any fault-findingwith another's posts, and told “Don't say anything if you're unwillingto help the user.” The resulting departure of clueful participants toelsewhere causes them to descend into meaningless babble and becomeuseless as technical forums.
Exaggeratedly “friendly” (in that fashion) or useful: Pick one.
Remember: When that hacker tells you that you've screwed up, and (nomatter how gruffly) tells you not to do it again, he's acting out ofconcern for (1) you and (2) his community. It would be much easier for himto ignore you and filter you out of his life. If you can't manage to begrateful, at least have a little dignity, don't whine, and don't expectto be treated like a fragile doll just because you're a newcomer witha theatrically hypersensitive soul and delusions of entitlement.
Sometimes people will attack you personally, flame without anapparent reason, etc., even if you don't screw up (or have onlyscrewed up in their imagination). In this case, complaining is the wayto really screw up.
These flamers are either lamers who don't have a clue butbelieve themselves to be experts, or would-be psychologists testingwhether you'll screw up. The other readers either ignore them, or findways to deal with them on their own. The flamers' behavior createsproblems for themselves, which don't have to concern you.
Don't let yourself be drawn into a flamewar, either. Most flamesare best ignored -- after you've checked whether they are really flames,not pointers to the ways in which you have screwed up, and not cleverlyciphered answers to your real question (this happens as well).
Questions Not To Ask
Here are some classic stupid questions, and what hackers are thinkingwhen they don't answer them.
Q: Where can I find program or resource X?Q: How can I use X to do Y?Q: How can I configure my shell prompt?Q: Can I convert an AcmeCorp document into a TeX file usingthe Bass-o-matic file converter?Q: My {program, configuration, SQL statement} doesn't workQ: I'm having problems with my Windows machine. Can you help?Q: My program doesn't work. I think system facility X is broken.Q: I'm having problems installing Linux or X. Can you help?Q: How can I crack root/steal channel-ops privileges/read someone'se-mail?[table][tr][td]Q:
[/td][td]Where can I find program or resource X?
[/td][/tr][tr][td]A:
[/td][td]The same place I'd find it, fool -- at the other end of aweb search. Ghod, doesn't everybody know how to use Google yet?
[/td][/tr][tr][td]Q:
[/td][td]How can I use X to do Y?
[/td][/tr][tr][td]A:
[/td][td]If what you want is to do Y, you should ask that questionwithout pre-supposing the use of a method that may not be appropriate.Questions of this form often indicate a person who is not merelyignorant about X, but confused about what problem Y they are solvingand too fixated on the details of their particular situation. It isgenerally best to ignore such people until they define their problembetter.
[/td][/tr][tr][td]Q:
[/td][td]How can I configure my shell prompt?
[/td][/tr][tr][td]A:
[/td][td]If you're smart enough to ask this question, you're smart enoughto RTFM and find out yourself.
[/td][/tr][tr][td]Q:
[/td][td]Can I convert an AcmeCorp document into a TeX file usingthe Bass-o-matic file converter?
[/td][/tr][tr][td]A:
[/td][td]Try it and see. If you did that, you'd (a) learn the answer, and (b) stop wasting my time.
[/td][/tr][tr][td]Q:
[/td][td]My {program, configuration, SQL statement} doesn't work
[/td][/tr][tr][td]A:
[/td][td]This is not a question, and I'm not interested in playingTwenty Questions to pry your actual question out of you -- I havebetter things to do. On seeing something like this, my reaction isnormally of one of the following:
[list][*]do you have anything else to add to that?[*]oh, that's too bad, I hope you get it fixed.[*]and this has exactly what to do with me?[/list]
[/td][/tr][tr][td]Q:
[/td][td]I'm having problems with my Windows machine. Can you help?
[/td][/tr][tr][td]A:
[/td][td]Yes. Throw out that Microsoft trash and install an open-sourceoperating system like Linux or BSD.
Note: you can ask questions related toWindows machines if they are about a program that does have anofficial Windows build, or interacts with Windows machines(i.e., Samba). Just don't be surprised by the reply that the problem iswith Windows and not the program, because Windows is so broken ingeneral that this is very often the case.
[/td][/tr][tr][td]Q:
[/td][td]My program doesn't work. I think system facility X is broken.
[/td][/tr][tr][td]A:
[/td][td]While it is possible that you are the first person to notice anobvious deficiency in system calls and libraries heavily used byhundreds or thousands of people, it is rather more likely that you areutterly clueless. Extraordinary claims require extraordinary evidence;when you make a claim like this one, you must back it up with clearand exhaustive documentation of the failure case.
[/td][/tr][tr][td]Q:
[/td][td]I'm having problems installing Linux or X. Can you help?
[/td][/tr][tr][td]A:
[/td][td]No. I'd need hands-on access to your machine to troubleshootthis. Go ask your local Linux user group for hands-on help. (You canfind a list of user groups here.)
Note: questions about installing Linux may be appropriate ifyou're on a forum or mailing list about a particular distribution, and theproblem is with that distro; or on local usergroups forums. In this case, be sure to describe the exact details ofthe failure. But do careful searching first, with "linux" andall suspicious pieces of hardware.
[/td][/tr][tr][td]Q:
[/td][td]How can I crack root/steal channel-ops privileges/read someone'se-mail?
[/td][/tr][tr][td]A:
[/td][td]You're a lowlife for wanting to do such things and a moron for asking a hacker to help you.
[/td][/tr][/table]
Good and Bad Questions
Finally, I'm going to illustrate how to ask questions in a smart wayby example; pairs of questions about the same problem, one asked in a stupid way and one in a smart way.
Stupid:Where can I find out stuff about the Foonly Flurbamatic?This question just begs for "STFW" as areply.
Smart:I used Google to try to find “Foonly Flurbamatic 2600” onthe Web, but I got no useful hits. Can I get a pointer toprogramming information on this device?This one has already STFWed, and sounds like he might have a realproblem.
Stupid:I can't get the code from project foo to compile. Why is it broken?The querent assumes that somebody else screwed up. Arrogant git...
Smart:The code from project foo doesn't compile under Nulix version 6.2. I've read the FAQ, but it doesn't have anything in it aboutNulix-related problems. Here's a transcript of my compilationattempt; is it something I did?The querent has specified the environment, read the FAQ, is showingthe error, and is not assuming his problems are someone else'sfault. This one might be worth some attention.
Stupid:I'm having problems with my motherboard. Can anybody help?J. Random Hacker's response to this is likely to be “Right. Do youneed burping and diapering, too?” followed by a punch of the deletekey.
Smart:I tried X, Y, and Z on the S2464 motherboard. When that didn't work,I tried A, B, and C. Note the curious symptom when I tried C.Obviously the florbish is grommicking, but the results aren't what onemight expect. What are the usual causes of grommicking on Athlon MPmotherboards? Anybody got ideas for more tests I can run to pin downthe problem?This person, on the other hand, seems worthy of ananswer. He/she has exhibited problem-solving intelligence rather thanpassively waiting for an answer to drop from on high.
In the last question, notice the subtle but important differencebetween demanding “Give me an answer” and “Pleasehelp me figure out what additional diagnostics I can run to achieveenlightenment.”
In fact, the form of that last question is closely based on areal incident that happened in August 2001 on the linux-kernel mailinglist (lkml). I (Eric) was the one asking the question that time. I wasseeing mysterious lockups on a Tyan S2462 motherboard. Thelist members supplied the critical information I needed to solvethem.
By asking the question in the way I did, I gave people somethingto chew on; I made it easy and attractive for them to get involved. Idemonstrated respect for my peers' ability and invited them to consultwith me as a peer. I also demonstrated respect for the value of theirtime by telling them the blind alleys I had already run down.
Afterwards, when I thanked everyone and remarked how well theprocess had worked, an lkml member observed that he thought it hadworked not because I'm a “name” on that list, but becauseI asked the question in the proper form.
Hackers are in some ways a very ruthless meritocracy; I'mcertain he was right, and that if I had behavedlike a sponge I would have been flamed or ignored no matter who I was.His suggestion that I write up the whole incident as instruction toothers led directly to the composition of this guide.
If You Can't Get An Answer
If you can't get an answer, please don't take it personally thatwe don't feel we can help you. Sometimes the members of the askedgroup may simply not know the answer. No response is not the sameas being ignored, though admittedly it's hard to spot the differencefrom outside.
In general, simply re-posting your question is a bad idea. Thiswill be seen as pointlessly annoying. Have patience: the person withyour answer may be in a different time-zone and asleep. Or it may bethat your question wasn't well-formed to begin with.
There are other sources of help you can go to, often sourcesbetter adapted to a novice's needs.
There are many online and local user groups who are enthusiastsabout the software, even though they may never have written anysoftware themselves. These groups often form so that people can helpeach other and help new users.
There are also plenty of commercial companies you can contractwith for help, both large and small (Red Hat and SpikeSource are two ofthe best known; there are many others). Don't be dismayed at the ideaof having to pay for a bit of help! After all, if your car engineblows a head gasket, chances are you would take it to a repair shopand pay to get it fixed. Even if the software didn't cost youanything, you can't expect that support to always come forfree.
For popular software like Linux, there are at least 10,000 usersper developer. It's just not possible for one person to handle thesupport calls from over 10,000 users. Remember that even if you have topay for support, you are still paying much less than if you had to buythe software as well (and support for closed-source software is usually moreexpensive and less competent than support for open-source software).
How To Answer Questions in a Helpful Way
Be gentle. Problem-related stress can makepeople seem rude or stupid even when they're not.
Reply to a first offender off-line. Thereis no need of public humiliation for someone who may have made anhonest mistake. A real newbie may not know how to search archives orwhere the FAQ is stored or posted.
If you don't know for sure, say so! A wrongbut authoritative-sounding answer is worse than none at all. Don'tpoint anyone down a wrong path simply because it's fun to sound likean expert. Be humble and honest; set a good example for both thequerent and your peers.
If you can't help, don't hinder. Don't makejokes about procedures that could trash the user's setup -- thepoor sap might interpret these as instructions.
Ask probing questions to elicit moredetails. If you're good at this, the querent will learnsomething -- and so might you. Try to turn the bad question intoa good one; remember we were all newbies once.
While muttering RTFM is sometimes justified when replyingto someone who is just a lazy slob, a pointer to documentation (evenif it's just a suggestion to google for a key phrase) isbetter.
If you're going to answer the question at all, givegood value. Don't suggest kludgy workarounds when somebodyis using the wrong tool or approach. Suggest good tools. Reframe thequestion.
Help your community learn from thequestion. When you field a good question, ask yourself“How would the relevant documentation or FAQ have to change sothat nobody has to answer this again?” Then send a patch to thedocument maintainer.
If you did research to answer the question, demonstrate yourskills rather than writing as though you pulled the answer out of yourbutt. Answering one good question is like feeding a hungry personone meal, but teaching them research skills by example is showingthem how to grow food for a lifetime.
Related Resources
If you need instruction in the basics of how personal computers,Unix, and the Internet work, seeThe Unix and Internet Fundamentals HOWTO.
When you release software or write patches for software, try tofollow the guidelines in the Software Release Practice HOWTO.
Acknowledgements
Evelyn Mitchell contributed some example stupid questions andinspired the “How To Give A Good Answer” section. MikhailRamendik contributed some particularly valuable suggestions forimprovements.