海未的苏打
[转载]提问的智慧
(在此感谢原作者和翻译者)
How To Ask Questions The Smart Way
提问的智慧
Copyright (C) 2001 by Eric S. Raymond
中文版Copyleft 2001 by D.H.Grand(nOBODY/Ginux)
英文版：http://www.tuxedo.org/~esr/faqs/smart-questions.html
感谢Eric的耐心指点和同意，本文才得以完成并发布，本指南
英文版版权为Eric Steven Raymond所有，
中文版版权由D.H.Grand[nOBODY/Ginux]所有。
====
简介
====
我们知道，很多人只想使用程序员们编写的软件，对技术细节没什么兴趣。对多
数人们而言，计算机不过是一个工具，一种达到目的的手段；他们有更重要的
事情要做，有更重要的生活要过。我们明白这点，也并不奢望每个人都对另我
们痴狂的技术问题有兴致。然而，我们回答问题的风格是
针对这样一群人--他们有兴趣，并且愿意积极参与问题的解决。这点不会改变，
也不应该改变；如果变了，我们将失去我们引以为傲的效率。
我们在很大程度上属于志愿者，从繁忙的生活中抽出时间来解惑答疑，而且时常
被提问淹没。所以我们无情的滤掉一些话题，特别是抛弃那些看起来象失败者的
家伙，以便更高效的利用时间来回答胜利者的问题。
如果你觉得我们过于傲慢的态度让你不爽，让你委屈，不妨设身处地想想。我
们并没有要求你向我们屈服--事实上，我们中的大多数人最喜欢公平交易不过
了，只要你付出小小努力来满足最起码的要求，我们就会欢迎你加入到我们的
文化中来。但让我们帮助那些不愿意帮助自己的人是没有意义的。
如果你决定向我们求助，当然不希望被视为失败者，更不愿成为失败者中的一
员。立刻得到有效答案的最好方法，就是象胜利者那样提问--聪明、自信、有
解决问题的思路，只是偶尔在特定的问题上需要获得一点帮助。
========
提问之前
========
在通过电邮、新闻组或者聊天室提出技术问题前，检查你有没有做到：
1. 通读手册，试着自己找答案。
2. 在FAQ里找答案（一份维护得好的FAQ可以包罗万象:）。
3. 在网上搜索（个人推荐google~~~）。
4. 向你身边精于此道的朋友打听。
当你提出问题的时候，首先要说明在此之前你干了些什么，不愿浪费别人的时间。能说明你从这些操作中学到了什么就更好了。如果提问者能从答案中学到东西，我们更
乐于回答他的问题。
周全的思考，准备好你的问题，草率的发问只能得到草率的回答，或者根本得
不到任何答案。越表现出在寻求帮助前为解决问题付出的努力，你越能得到实
质性的帮助。
========
怎样提问
========
----------------------------
用辞贴切，语法正确，拼写无误
----------------------------
我们从经验中发现，粗心的写作者通常也是马虎的思考者（我敢打包票）。
回答粗心大意者的问题很不值得，我们宁愿把时间耗在别处。
因此，明确充分表述你的问题非常重要。不要嫌这样做很麻烦。注意推敲你的用辞，不一定要用呆板正式的语言
------------------
用易读格式发送问题
------------------
如果人为造成你的提问难以阅读和理解，将会更容易被人忽略。因此你要：
1. 在可以叙述明白问题的情况下使用纯文本。
2. 提出问题时，尽可能的截图下来。
3. 不要把所有问题放在不停换行的一整段中。
----------------------------
使用含义丰富，描述准确的标题
----------------------------
别用喋喋不休的“帮帮忙”来浪费这个机会。
蠢问题：
救命啊！我的膝上机不能正常显示了！
聪明问题：
XFree86 4.1下鼠标光标变形，Fooware MV1005的显示芯片。
如果你在回复中提出问题，记得要修改内容标题，表明里面有一个问题。一个
看起来象“Re：测试”或者“Re：新bug”的问题很难引起足够重视。另外，引
用并删减前文的内容，给新来的读者留下线索。
------------------
精确描述，信息量大
------------------
1. 谨慎明确的描述症状。
2. 提供问题发生的环境（机器配置、操作系统、应用程序以及别的什么）。
3. 说明你在提问前是怎样去研究和理解这个问题的。
4. 说明你在提问前采取了什么步骤去解决它。
5. 罗列最近做过什么可能有影响的硬件、软件变更。
------------------
只说症状，不说猜想
------------------
要确信你原原本本说明问题的症状。
蠢问题：
我在内核编译中一次又一次遇到SIG11错误，我怀疑某条飞线搭在主板的走线上了，
这种情况应该怎样检查最好？
聪明问题：
我自制的一套K6/233系统，主板是FIC-PA2007 （VIA Apollo VP2芯片组），256MB
Corsair PC133
SDRAM，在内核编译中频频产生SIG11错误，从开机20分钟以后就有这种情况，开机
前20分钟内从没发生过。重启也没有用，但是关机一晚上就又能工作20分钟。所有
内存都换过了，没有效果。相关部分的典型编译记录如下...。
------------------
按时间顺序列出症状
------------------
对找出问题最有帮助的线索，往往就是问题发生前的一系列操作，因此，你的说明
应该包含操作步骤，以及电脑的反应，直到问题产生。在命令行操作的情况下，保
存一个操作记录（例如使用脚本工具），并且引用相关的大约20条命令会大有帮助。
如果崩溃的程序有诊断选项（例如用-v转到详尽模式），试着仔细考虑选择选项以
在操作记录中增加有用的调试信息。
如果你的说明很长（超过四个段落），在开头简述问题会有所帮助，接下来按时间
顺序详述。
--------------
明白你想问什么
--------------
漫无边际的提问近乎无休无止的时间黑洞。最能给你有用答案的人也正是最忙的
人（他们忙是因为要亲自完成大部分工作）。这样的人对无节制的时间黑洞不太
感冒，因此也可以说他们对漫无边际的提问不大感冒。
如果你明确表述需要回答者做什么，就最有可能得到有用的答案。这会定出一个时间和精力的上限，
便于回答者集中精力来帮你，这很凑效。
因此，优化问题的结构，尽量解决它所需要的时间，会有很大的帮助--这通常和简化问题有所区别。因此，问“我想更好的理解X，能给点提示吗？”通常比问“你能解释一下X吗？”更好。如果你编写的程序不能工作，问问它有什么地方不对，比要求别人替你修改要明智得多。
------------------------
别问应该自己解决的问题
------------------------
(在此感谢原作者和翻译者)
How To Ask Questions The Smart Way
提问的智慧
Copyright (C) 2001 by Eric S. Raymond
中文版Copyleft 2001 by D.H.Grand(nOBODY/Ginux)
英文版：http://www.tuxedo.org/~esr/faqs/smart-questions.html
感谢Eric的耐心指点和同意，本文才得以完成并发布，本指南
英文版版权为Eric Steven Raymond所有，
中文版版权由D.H.Grand[nOBODY/Ginux]所有。
====
简介
====
我们知道，很多人只想使用程序员们编写的软件，对技术细节没什么兴趣。对多
数人们而言，计算机不过是一个工具，一种达到目的的手段；他们有更重要的
事情要做，有更重要的生活要过。我们明白这点，也并不奢望每个人都对另我
们痴狂的技术问题有兴致。然而，我们回答问题的风格是
针对这样一群人--他们有兴趣，并且愿意积极参与问题的解决。这点不会改变，
也不应该改变；如果变了，我们将失去我们引以为傲的效率。
我们在很大程度上属于志愿者，从繁忙的生活中抽出时间来解惑答疑，而且时常
被提问淹没。所以我们无情的滤掉一些话题，特别是抛弃那些看起来象失败者的
家伙，以便更高效的利用时间来回答胜利者的问题。
如果你觉得我们过于傲慢的态度让你不爽，让你委屈，不妨设身处地想想。我
们并没有要求你向我们屈服--事实上，我们中的大多数人最喜欢公平交易不过
了，只要你付出小小努力来满足最起码的要求，我们就会欢迎你加入到我们的
文化中来。但让我们帮助那些不愿意帮助自己的人是没有意义的。
如果你决定向我们求助，当然不希望被视为失败者，更不愿成为失败者中的一
员。立刻得到有效答案的最好方法，就是象胜利者那样提问--聪明、自信、有
解决问题的思路，只是偶尔在特定的问题上需要获得一点帮助。
========
提问之前
========
在通过电邮、新闻组或者聊天室提出技术问题前，检查你有没有做到：
1. 通读手册，试着自己找答案。
2. 在FAQ里找答案（一份维护得好的FAQ可以包罗万象:）。
3. 在网上搜索（个人推荐google~~~）。
4. 向你身边精于此道的朋友打听。
当你提出问题的时候，首先要说明在此之前你干了些什么，不愿浪费别人的时间。能说明你从这些操作中学到了什么就更好了。如果提问者能从答案中学到东西，我们更
乐于回答他的问题。
周全的思考，准备好你的问题，草率的发问只能得到草率的回答，或者根本得
不到任何答案。越表现出在寻求帮助前为解决问题付出的努力，你越能得到实
质性的帮助。
========
怎样提问
========
----------------------------
用辞贴切，语法正确，拼写无误
----------------------------
我们从经验中发现，粗心的写作者通常也是马虎的思考者（我敢打包票）。
回答粗心大意者的问题很不值得，我们宁愿把时间耗在别处。
因此，明确充分表述你的问题非常重要。不要嫌这样做很麻烦。注意推敲你的用辞，不一定要用呆板正式的语言
------------------
用易读格式发送问题
------------------
如果人为造成你的提问难以阅读和理解，将会更容易被人忽略。因此你要：
1. 在可以叙述明白问题的情况下使用纯文本。
2. 提出问题时，尽可能的截图下来。
3. 不要把所有问题放在不停换行的一整段中。
----------------------------
使用含义丰富，描述准确的标题
----------------------------
别用喋喋不休的“帮帮忙”来浪费这个机会。
蠢问题：
救命啊！我的膝上机不能正常显示了！
聪明问题：
XFree86 4.1下鼠标光标变形，Fooware MV1005的显示芯片。
如果你在回复中提出问题，记得要修改内容标题，表明里面有一个问题。一个
看起来象“Re：测试”或者“Re：新bug”的问题很难引起足够重视。另外，引
用并删减前文的内容，给新来的读者留下线索。
------------------
精确描述，信息量大
------------------
1. 谨慎明确的描述症状。
2. 提供问题发生的环境（机器配置、操作系统、应用程序以及别的什么）。
3. 说明你在提问前是怎样去研究和理解这个问题的。
4. 说明你在提问前采取了什么步骤去解决它。
5. 罗列最近做过什么可能有影响的硬件、软件变更。
------------------
只说症状，不说猜想
------------------
要确信你原原本本说明问题的症状。
蠢问题：
我在内核编译中一次又一次遇到SIG11错误，我怀疑某条飞线搭在主板的走线上了，
这种情况应该怎样检查最好？
聪明问题：
我自制的一套K6/233系统，主板是FIC-PA2007 （VIA Apollo VP2芯片组），256MB
Corsair PC133
SDRAM，在内核编译中频频产生SIG11错误，从开机20分钟以后就有这种情况，开机
前20分钟内从没发生过。重启也没有用，但是关机一晚上就又能工作20分钟。所有
内存都换过了，没有效果。相关部分的典型编译记录如下...。
------------------
按时间顺序列出症状
------------------
对找出问题最有帮助的线索，往往就是问题发生前的一系列操作，因此，你的说明
应该包含操作步骤，以及电脑的反应，直到问题产生。在命令行操作的情况下，保
存一个操作记录（例如使用脚本工具），并且引用相关的大约20条命令会大有帮助。
如果崩溃的程序有诊断选项（例如用-v转到详尽模式），试着仔细考虑选择选项以
在操作记录中增加有用的调试信息。
如果你的说明很长（超过四个段落），在开头简述问题会有所帮助，接下来按时间
顺序详述。
--------------
明白你想问什么
--------------
漫无边际的提问近乎无休无止的时间黑洞。最能给你有用答案的人也正是最忙的
人（他们忙是因为要亲自完成大部分工作）。这样的人对无节制的时间黑洞不太
感冒，因此也可以说他们对漫无边际的提问不大感冒。
如果你明确表述需要回答者做什么，就最有可能得到有用的答案。这会定出一个时间和精力的上限，
便于回答者集中精力来帮你，这很凑效。
因此，优化问题的结构，尽量解决它所需要的时间，会有很大的帮助--这通常和简化问题有所区别。因此，问“我想更好的理解X，能给点提示吗？”通常比问“你能解释一下X吗？”更好。如果你编写的程序不能工作，问问它有什么地方不对，比要求别人替你修改要明智得多。
------------------------
别问应该自己解决的问题
------------------------
