How To Ask Questions The Smart Way

小心选择你要提问的场合 。如果做了下述的事情，你很可能被忽略掉或者被看作失败者：

• 在与主题不合的论坛上贴出你的问题
• 在探讨进阶技术问题的论坛上发布非常初级的问题；反之亦然
• 在太多的不同新闻组上重复发布同样的问题
• 向既非熟人也没有义务解决你问题的人发送私人电子邮件

在选择论坛、新闻群组或邮件列表时，别太相信名字，先看看 FAQ 或者许可证以弄清楚你的问题是否切题。提问前先翻翻已有的话题，也许你能找到答案。即使找不到，也能帮助你归纳出更好的问题。

在仔细挑选的公共论坛中提问比在私有论坛中更容易得到有用的回答 。理由如下：

• 潜在的回复者更多
• 观众更多

黑客较愿意回答那些能帮助到许多人的问题。

搜索，然后在 Stack Exchange 提问。

近年来，Stack Exchange 社区已经成为回答技术及其他问题的主要渠道，尤其是那些开放源码的项目。

Google 索引网站是即时的，在看 Stack Exchange 之前先在 Google 搜索。有很大几率找到某人已经提问的问题，而且 Stack Exchange 社区的网站往往会是搜索结果中最前面几个。如果你在 Google 上没找到任何答案，再到相关主题的网站去找。使用标签以缩小搜索范围。

Stack Exchange 已经成长到超过一百个网站，以下是最常用的几个：

• Stack Overflow 是问写程序相关的问题
• Super User 是问一些通用的电脑问题，如果你的问题跟代码或写程序无关，只是一些网络连线之类的，请到这里
• Server Fault 是问服务器和网络管理相关的问题

本地的使用者群组，或者你所使用软件的开发者正在宣传他们的网页论坛或 IRC 频道，并提供新手帮助，这些地方是开始提问的好地方，特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。

如果程序出的问题只发生在特定 Linux 发行版提供的版本，最好先去该发行版的论坛或邮件列表中提问，再到程序本身的论坛或邮件列表提问。否则该项目的黑客可能仅仅回复，"用我们的版本"。

在任何论坛发文以前，先确认有没有搜索功能。如果有，试着从自己的问题提取关键字搜索。如果之前你已经进行过搜索引擎搜索，还是在论坛中搜索一下，因为搜索引擎有可能并未索引论坛的全部内容。

通过论坛或 IRC 频道来提供使用者支持服务有增长的趋势，电子邮件则大多是项目开发者间的交流，因为可能对别人有用，所以被保留。所以最好现在论坛或 IRC 中寻求帮助。

在使用 IRC 时，首先最好不要发布很长的问题描述，有些人称之为「频道洪水」。最好通过一句话的问题描述来开始聊天。

当某个项目提供开发者邮件列表时，要向列表而不是其中的个别成员提问，即使你确信他一定能回答你的问题。查一查项目的文件和首页，找到项目的邮件列表并使用它。有几个很好的理由支持我们采用这种办法：

• 任何好到需要向个别开发者提出的问题，也将对整个项目群组有益。反之，如果你认为自己的问题对整个项目群组来说太愚蠢，也不能成为骚扰个别开发者的理由。
• 向列表提问可以分散开发者的负担，个别开发者（尤其是当他是项目负责人时）也许太忙以至于没法回答你的问题。
• 大多数邮件列表都会被存档，那些被存档的内容将被搜索引擎索引。如果你向列表提问并得到解答，将来其他人可以通过网页搜索找到你的问题和答案，也就不用再次发问了。
• 如果某些问题经常被问到，开发者可以利用此信息改进说明文件或软件本身，以使其更清楚。如果只是私下提问，就没有人能看到最常见问题的完整场景。

如果一个项目既有“使用者”也有“开发者”（或“黑客”）列表或论坛，而你又不会动到那些源代码，那么就向“使用者”列表或论坛提问。不要假设自己会在开发者列表中受到欢迎，那些人多半会将你的提问视为干扰他们开发的噪音。

然而，如果你 确信 你的问题很特别，而且在“使用者”列表或论坛中几天都没有回复，可以试试前往“开发者”列表或论坛发问。建议你张贴前最好先暗地里观察几天以了解那里的行事方式（事实上，这是参与任何私有或半私有列表的好主意）。

如果你找不到一个项目的邮件列表，而只能查到项目维护者的电子邮件地址，尽管向他发信。即使是在这种情况下，也别假设（项目）邮件列表不存在。在你的电子邮件中，请陈述你已经试过但没有找到合适的邮件列表，也提及你不反对将自己的邮件转发给他人（许多人认为，即使没什么秘密，私人电子邮件也不应该被公开。通过允许将你的电子邮件转发他人，你给了相应人员处置你邮件的选择）。

在邮件列表、新闻群组或论坛中，大约 50 字以内的标题是抓住资深专家注意力的好机会。别用喋喋不休的 帮帮忙 、 跪求 、 急 （更别说 救命啊！！！ 这样令人反感的话，用这种标题会被条件反射式地忽略）来浪费这个机会。要在这点空间中使用极简单扼要的描述方式来提出问题。

一个好标题的范例是 目标 —— 差异 式的描述，许多技术支持组织就是这样做的。在 目标 部分指出是哪一个或哪一组东西有问题，在 差异 部分则描述与期望的行为不一致的地方。

蠢问题 ：

救命啊！我的笔记本电脑不能正常显示了！

聪明问题 ：

X.org 6.8.1 鼠标光标变形，Fooware MV1005 vid.芯片组。

更聪明的问题 ：

X.org 6.8.1 的鼠标光标，在某牌显卡 MV1005 芯片组环境下 —— 会变形

编写 目标 —— 差异 式描述的过程有助于你对问题进行细致的思考 。是什么被影响了？仅仅是鼠标光标或者还有其他图形？只在 X.org 的 X 版中出现？是针对某牌显卡芯片组？或者只是其中的 MV 1005 型号？一个黑客只需瞄一眼就能够立即明白你的环境和你遇到的问题。

如果你想在回复中提出问题，记得要修改内容标题，以表明你是如何问一个问题，一个看起来像 Re：测试 或者 Re：新 Bug 的标题很难引起足够重视。另外，在不影响连贯性之下，适当引用并删减前文的内容，能给新的读者留下线索。

在网页论坛上，好的提问方式稍有不同，因为讨论串与特定的信息紧密结合，并且通常在讨论串外就看不到里面的内容，故通过回复提问，而非改变标题是可接受的。

不是所有论坛都允许在回复中出现分离的标题，而且这样做了基本上没有人回去看。不过通过回复提问，这本身就是暧昧的行为，因为它们只会被正在查看该标题的人读到。所以，除非你只想在该讨论串当前活跃的人群中提问，不然还是另起炉灶比较好。

不要因为麻烦而放弃在邮件客户端设置回复地址，这会降低回复的概率。在论坛，要求通过电子邮件回复是非常无礼的，除非你认为回复的信息可能比较敏感（有人会为了某些未知的原因，只让你而不是整个论坛知道答案）。

如果你只是想在有人回复讨论串时得到电子邮件提醒，可以要求网页论坛发送给你。几乎所有论坛都支持诸如 追踪此讨论串 、 有回复时发送邮件提醒 等功能。

正确的拼写、标点符号和大小写是很重要的。如果你觉得这样做很麻烦，那你多半得不到别人的帮助。不用太僵硬与正式——在黑客文化里，在保证 很准确 的情况下，能够使用非正式的语句也是一种得到关注的能力。这能够表明你是在思考和关注问题。

如果在非母语论坛提问，犯点拼写和语法上的小错误是可以原谅的，但绝不能在思考上马虎（这时可以区分的）。英语是通用的网络语言。

如果英语是你的第二外语，提示潜在回复者「你有潜在的语言困难是很好的」：

English is not my native language; please excuse typing errors.

英语不是我的母语，请原谅我的错别字。

If you speak $LANGUAGE , please email/PM me; I may need assistance translating my question.

如果你说 某语言 ，请电邮或私信我；我可能需要帮助以翻译我的问题。

I am familiar with the technical terms, but some slang expressions and idioms are difficult for me.

我对技术名词很熟悉，但对俗语或是特别用法比较不甚了解。

I've posted my question in $LANGUAGE and English. I'll be glad to translate responses, if you only use one or the other.

我把我的问题用某语言和英文写出来，如果你只用一种语言回答，我会乐意将其翻译成另一种。

需要做到：

• 使用纯文字而不是 HTML（关闭 HTML并不难）。
• 可以使用 MIME 附件，前提是真正有内容（譬如附带的源代码或 patch）。
• 不要发送「一段文字只是一行句子但在自动换行后会变成多行」的邮件（这样回复部分内容就变得很困难）。
• 但是，不要对一些特殊文件设置固定宽度（譬如日志档案拷贝或会话记录）。数据应该原样包含，让回复者有信心——觉得他们自己看到的和你看到的是一样的。
• 在英文论坛中不要使用 Quoted-Printable MIME 编码发送消息。这种编码对于张贴非 ASCII 语言可能是必须的，但很多邮件程序并不支持这种编码。当它们处理换行时，那些文本中四处散布的 =20 符号既难看也分散注意力，甚至有可能破坏内容的语意。
• 永远不要向黑客发送使用封闭格式编写的文档，像微软公司的 Word 或 Excel 文件等。
• 如果使用 Windows 的电脑发送电子邮件，关闭 智能引号 功能（位于 [选项] –> [校订] –> [自动矫正选项]，取消勾选 智能引号 ），以免在你的邮件中到处散布垃圾字符。
• 在论坛，不要滥用 表情符号 和 HTML 功能（当它们提供时）。

注意自己所使用的邮件客户端，可能它们的默认设置满足不了这些要求。注意检查是否有 查看源代码 功能，以确保发送的是纯文本文件同时没有一些奇怪的字符。

• 仔细、清楚地描述你的问题或 Bug 的症状。
• 描述问题发生的环境（机器配置、操作系统、应用程序以及相关的信息），提供经销商的发行版和版本号（如： Fedora Core 4 、 Slackware 9.1 等）。
• 描述在提问前你是怎样去研究和理解这个问题的。
• 描述在提问前为确定问题而采取的诊断步骤。
• 描述最近做过什么可能相关的硬件或软件变更。
• 尽可能地提供一个可以 重现这个问题的可控环境 的方法。

揣测黑客会怎样反问你，在你提问之前预先将黑客们可能遇到的问题回答一遍。

以上几点中，当你报告的是你认为可能在代码中的问题时，给黑客一个可以重现你的问题的环境尤其重要。当你这么做时，你得到有效回答的机会和速度都会大大地提升。

Simon Tatham 写过一篇名为《How to Report Bugs Effectively》的出色文章。强力推荐你也读一读。

你需要提供精确有内容的信息。这并不是要求你简单地把成堆的出错代码或者资料完全放到你的提问中。如果你有庞大而复杂的测试样例能重现程序挂掉的情境，尽量将它裁剪得越小越好。

这样做的三点好处：

第一，能表现出你为简化问题付出了努力，这可以使你得到回答的机会增加；

第二，简化问题使你更有可能得到有用的答案；

第三，在精炼你的 bug 报告的过程中，你很可能就自己找到了解决办法。

除非你能提供解决问题的源代码补丁，或者提供回归测试来表明前一版本中行为不正确，否则你多半不能够完全确信。这同样适用于文件，如果你（声称）发现了文件的 bug，你应该能提供相应位置的修正或替代文件。

如果你的问题并不常见，那么它可能不是 bug。开发者总是希望软件足够完美，出现 bug 会冒犯他们（如果不是真正的 bug 会更严重）。

过于卑微同样无法为你带来问题的解决办法。做好前文所说明的步骤。

蠢问题 ：

我在编译内核时接连遇到 SIG11 错误，我怀疑某条飞线搭在主板的走线上了，这种情况应该怎样检查最好？

聪明问题 ：

我的组装电脑是 FIC-PA2007 主机板搭载 AMD K6/233 CPU（威盛 Apollo VP2 芯片组）， 256MB Corsair PC133 SDRAM 内存，在编译内核时，从开机 20 分钟以后就频频产生 SIG11 错误， 但是在头 20 分钟内从没发生过相同的问题。重新启动也没有用，但是关机一晚上就又能工作 20 分钟。 所有内存都换过了，没有效果。相关部分的标准编译记录如下……。

在说明中包含操作步骤，以及机器和软件的反应，直到问题发生。

寻求帮助的人经常在心中有个更高层次的目标，而在他们认为达成目标的一条特定路径上停滞了。他们不会思考：会不会这条路本身就有问题？

蠢问题 ：

我怎样才能从某绘图程序的颜色选择器中取得十六进制的的 RGB 值？

聪明问题 ：

我正试着用替换一幅图片的色码（color table）成自己选定的色码，我现在知道的唯一方法是编辑每个色码区块（table slot）， 但却无法从某绘图程序的颜色选择器取得十六进制的的 RGB 值。

第二种提问法比较聪明，你可能得到像是=建议采用另一个更合适的工具=的回复。

黑客们认为问题的解决过程应该公开透明，可能会有更有经验的人能够注意到不完整或者不当之处，最初的回复才能够、也应该被纠正。同时，提供帮助的人也能借此展示自己的才能，给同行看。

向别人提问时，要明确表述需要回答者做什么，这样做会定出一个时间和精力的上限，便于回答者能够集中精力帮助你。

要理解专家们所处的世界，要把专业技能想象为充裕的资源，而回复的时间则是稀缺的资源。要求他们奉献的时间越少，就越有可能从真正专业而且很忙的专家那里得到解答。

不要让别人帮你调试问题代码，也不提示以下应该如何入手。

愚蠢的做法 ：

张贴几百行代码，然后只是说，"某某不能工作"。

聪明的做法 ：

只贴几十行代码，然后说，"在某行以后，我期待 x，但实际是 y。"

最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例（bug-demonstrating test case） 。如何定义 最精简的测试用例 ？那是问题的缩影；一个小程序片段能 刚好 展示出程序的异常行为，而不包含其他令人分散注意力的内容。

怎么制作最精简的测试用例 ？如果你知道哪一行或哪一段代码会造成异常的行为，复制下来并加入足够重现这个状况的代码。如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。总之，测试用例越小越好。

这些问题是需要我们自己独自解决的，可能有经验的人会给我们一些提示，但是仍然需要自己解决。

彬彬有礼，多用 请 和 谢谢您的关注 ，或 谢谢你的关照 。让大家都知道你对他们花时间免费提供帮助心存感激。

坦白说，这一点并没有比清晰、正确、精准并合法语法和避免使用专用格式重要（也不能取而代之）。黑客们一般宁可读有点唐突但技术上鲜明的 Bug 报告，而不是那种有礼但含糊的报告（如果这点让你不解，记住我们是按问题能教给我们什么来评价问题的价值的）。

然而，如果你有一串的问题待解决，客气一点肯定会增加你得到有用回应的机会。

（我们注意到，自从本指南发布后，从资深黑客那里得到的唯一严重缺陷反馈，就是对预先道谢这一条。一些黑客觉得 先谢了 意味着事后就不用再感谢任何人的暗示。我们的建议是要么先说 先谢了 ， 然后 事后再对回复者表示感谢，或者换种方式表达感激，譬如用 谢谢你的关注 或 谢谢你的关照 。）

问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注，应该在那里贴一个说明比较恰当。

最理想的方式是向最初提问的话题回复此消息，并在标题中包含 已修正 ， 已解决 或其它同等含义的明显标记。在人来人往的邮件列表里，一个看见讨论串 问题 X 和 问题 X - 已解决 的潜在回复者就明白不用再浪费时间了（除非他个人觉得 问题 X 的有趣），因此可以利用此时间去解决其它问题。

补充说明不必很长或是很深入；简单的一句 你好，原来是网线出了问题！谢谢大家 – Bill 比什么也不说要来的好。事实上，除非结论真的很有技术含量，否则简短可爱的小结比长篇大论更好。说明问题是怎样解决的，但大可不必将解决问题的过程复述一遍。

对于有深度的问题，张贴调试记录的摘要是有帮助的。

思考一下怎样才能避免他人将来也遇到类似的问题，自问写一份文件或加个常见问题（FAQ）会不会有帮助。如果是的话就将它们发给维护者。

在黑客中，这种良好的后继行动实际上比传统的礼节更为重要，也是你如何透过善待他人而赢得声誉的方式，这是非常有价值的资产。

RTFM: Read The Fucking Manual

STFW: Search The Fucking Web

这些答复意味着回答者认为

• 你需要的信息非常容易获得 ；
• 你自己去搜索这些信息比灌给你，能让你学到更多 。

你不应该因此不爽； 依照黑客的标准，他已经表示了对你一定程度的关注，而没有对你的要求视而不见 。你应该对他祖母般的慈祥表示感谢。

如果你看不懂回应，别立刻要求对方解释。像你以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。

比方说，如果我回答你： 看来似乎是 zentry 卡住了；你应该先清除它。 ，然后，这是一个 很糟的 后续问题回应： zentry 是什么？ 好 的问法应该是这样： 哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries，而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗？还是我看漏了什么？

很多黑客圈子中看似无礼的行为并不是存心冒犯。相反，它是直接了当，一针见血式的交流风格，这种风格更注重解决问题，而不是使人感觉舒服而却模模糊糊。

如果你觉得被冒犯了，试着平静地反应。如果有人真的做了出格的事，邮件列表、新闻群组或论坛中的前辈多半会招呼他。如果这 没有 发生而你却发火了，那么你发火对象的言语可能在黑客社区中看起来是正常的，而 你 将被视为有错的一方，这将伤害到你获取信息或帮助的机会。

另一方面，你偶尔真的会碰到无礼和无聊的言行。与上述相反，对真正的冒犯者狠狠地打击，用犀利的语言将其驳得体无完肤都是可以接受的。然而，在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔，黑客们自己莽撞地越线的情况并不鲜见。如果你是新手或外人，避开这种莽撞的机会并不高。如果你想得到的是信息而不是消磨时光，这时最好不要把手放在键盘上以免冒险。