- 一、提问之前
- 二、怎样提问
- 选择正确的论坛
- 用辞贴切，语法正确，拼写无误
- 使用含义丰富，描述准确的标题
- 精确描述，信息量大
- 话不在多，在于提供精确有效的信息
- 去除无意义的疑问
- 按时间顺序列出症状
- 明白你想问什么
- 三、注意事项
- 提问没有人回答
- 谦逊绝没有害处，而且常帮大忙
- 问题解决后，加个简短说明
- 还是不懂
- 四、最重要的是要做到精确。程序员喜欢精确。
- 五、不该问的问题
- 六、好问题与蠢问题
- 相关资料
一、提问之前
在通过电邮、新闻组或者聊天室提出技术问题前，检查你有没有做到：
1、通读手册，试着自己找答案。
2、在FAQ里找答案(一份维护得好的FAQ可以包罗万象:)。
3、在网上搜索(个人推荐google~~~)。
4、向你身边精于此道的朋友打听。
当你提出问题的时候，首先要说明在此之前你干了些什么。
这将有助于树立你的形象：你不是一个妄图不劳而获的乞讨者，不愿浪费别人的时间。如果提问者能从答案中学到东西，我们更乐于回答他的问题。
周全的思考，准备好你的问题，草率的发问只能得到草率的回答，或者根本得不到任何答案。越表现出在寻求帮助前为解决问题付出的努力，你越能得到实质性的帮助。
小心别问错了问题。如果你的问题基于错误的假设，普通黑客(J. Random Hacker)通常会用无意义的字面解释来答复你，心里想着“蠢问题…”，希望着你会从问题的回答(而非你想得到的答案)中汲取教训。
决不要自以为够资格得到答案，你没这种资格。毕竟你没有为这种服务支付任何报酬。你要自己去“挣”回一个答案，靠提出一个有内涵的，有趣的，有思维激励作用的问题–一个对社区的经验有潜在贡献的问题，而不仅仅是被动的从他人处索要知识–去挣到这个答案。
另一方面，表明你愿意在找答案的过程中做点什么，是一个非常好的开端。“谁能给点提示？”、“我这个例子里缺了什么？”以及“我应该检查什么地方？”比“请把确切的过程贴出来”更容易得到答复。因为你显得只要有人指点正确的方向，你就有完成它的能力和决心。
二、怎样提问
选择正确的论坛
小心选择提问的场合。如果象下面描述的那样，你很可能被忽略掉或者被看作失败者：
1、在风马牛不相及的论坛贴出你的问题 ；
2、在探讨高级技巧的论坛张贴非常初级的问题；
3、反之亦然 在太多的不同新闻组交叉张贴。
用辞贴切，语法正确，拼写无误
1、粗心的写作者通常也是马虎的思考者。 回答粗心大意者的问题很不值得，我们宁愿把时间耗在别处。
2、正确的拼写，标点符号和大小写很重要。一般的说，如果你的提问写得象个半文盲，你很有可能被忽视。
3、如果你在使用非母语的论坛提问，你可以犯点拼写和语法上的小错–但决不能在思考上马虎。
使用含义丰富，描述准确的标题
在邮件列表或者新闻组中，大约50字以内的主题标题是抓住资深专家注意力的黄金时机。别用喋喋不休的“帮帮忙”(更别说“救命啊！！！！！”这样让人反感的话)来浪费这个机会。不要妄想用你的痛苦程度来打动我们， 别用空格代替问题的描述，哪怕是极其简短的描述。
如果你在回复中提出问题，记得要修改内容标题，表明里面有一个问题。一个看起来象“Re：测试”或者“Re：新bug”的问题很难引起足够重视。另外，引用并删减前文的内容，给新来的读者留下线索。
精确描述，信息量大
1、谨慎明确的描述症状。
2、提供问题发生的环境(机器配置、操作系统、应用程序以及别的什么)。
3、说明你在提问前是怎样去研究和理解这个问题的。
4、说明你在提问前采取了什么步骤去解决它。
5、罗列最近做过什么可能有影响的硬件、软件变更。
话不在多，在于提供精确有效的信息
不能简单的把成吨的出错代码或者数据完全转储摘录到你的提问中。如果你有庞大而复杂的测试条件，尽量把它剪裁得越小越好。
这样做的用处至少有三点。第一，表现出你为简化问题付出了努力，这可以使你得到回答的机会增加；第二，简化问题使你得到有用答案的机会增加；第三，在提炼你的bug报告的过程中，也许你自己就能找出问题所在或作出更正，去除无意义的疑问。
别用无意义的话结束提问，例如“有人能帮我吗？”或者“有答案吗？”。首先：如果你对问题的描述不很合适，这样问更是画蛇添足。其次：由于这样问是 画蛇添足，黑客们会很厌烦你–而且通常会用逻辑上正确的回答来表示他们的蔑视，例如：“没错，有人能帮你”或者“不，没答案”。
按时间顺序列出症状
对找出问题最有帮助的线索，往往就是问题发生前的一系列操作，因此，你的说明应该包含操作步骤，以及电脑的反应，直到问题产生。
如果你的说明很长(超过四个段落)，在开头简述问题会有所帮助，接下来按时间顺序详述。这样别人就知道该在你的说明中找什么。
明白你想问什么
漫无边际的提问近乎无休无止的时间黑洞。最能给你有用答案的人也正是最忙的人(他们忙是因为要亲自完成大部分工作)。这样的人对无节制的时间黑洞不太感冒，因此也可以说他们对漫无边际的提问不大感冒。
如果你明确表述需要回答者做什么(提供建议，发送一段代码，检查你的补丁或是别的)，就最有可能得到有用的答案。这会定出一个时间和精力的上限，便 于回答者集中精力来帮你，这很奏效。要理解专家们生活的世界，要把专业技能想象为充裕的资源，而回复的时间则是贫乏的资源。解决你的问题需要的时间越少， 越能从忙碌的专家口中掏出答案。
因此，优化问题的结构，尽量减少专家们解决它所需要的时间，会有很大的帮助–这通常和简化问题有所区别。因此，问“我想更好的理解X，能给点提示吗？”通常比问“你能解释一下X吗？”更好。如果你的代码不能工作，问问它有什么地方不对，比要求别人替你修改要明智得多。
三、注意事项
提问没有人回答
如果仍得不到答案，请不要以为我们觉得无法帮助你。有时只是看到你问题的人不知道答案罢了。没有回应不代表你被忽视，虽然不可否认这种差别很难区分。
总的说来，简单的重复张贴问题是个很糟的想法。这将被视为无意义的喧闹。
你可以通过其它渠道获得帮助，这些渠道通常更适合初学者的需要。有许多网上的以及本地的用户组，由狂热的软件爱好者(即使他们可能从没亲自写过任何软件)组成。通常人们组建这样的团体来互相帮助并帮助新手。
谦逊绝没有害处，而且常帮大忙
彬彬有礼，多用“请”和“先道个谢了”。让大家都知道你对他们花费时间义务提供帮助心存感激。然而，如果你有很多问题无法解决，礼貌将会增加你得到有用答案的机会。
问题解决后，加个简短说明
问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再一次向他们表示感谢。
如果问题在新闻组或者邮件列表中引起了广泛关注， 应该在那里贴一个补充说明。补充说明不必很长或是很深入；简单的一句“你好，原来是网线出了问题！谢谢大家–Bill”比什么也不说要强。事实上，除非结论真的很有技术含量，否则简短可爱的小结比长篇学术论文更好。说明问题是怎样解决的，但大可不必将解决问题的过程复述一遍。除了表示礼貌和反馈信息以外， 这种补充有助于他人在邮件列表/新闻组/论坛中搜索对你有过帮助的完整解决方案，这可能对他们也很有用。最后这种补充有助于所有提供过帮助的人从中得到满足感。
还是不懂
如果你不是很理解答案，别立刻要求对方解释。象你以前试着自己解决问题时那样(利用手册，FAQ，网络，身边的高手)，去理解它。如果你真的需要对 方解释，记得表现出你已经学到了点什么。比方说，如果我回答你：“看来似乎是zEntry被阻塞了；你应该先清除它。”，然后：一个很糟的后续问题： “zEntry是什么？” 聪明的问法应该是这样：“哦~~~我看过帮助了但是只有-z和-p两个参数中提到了zEntry而且还都没有清楚的解释:<你是指这两个中的哪一个 吗？还是我看漏了什么？”
四、最重要的是要做到精确。程序员喜欢精确。
精确：
如果做相同的事情有两种方法，请说明您用的是哪一种。例如：“我选择了‘载入’”，可能意味着“我用鼠标点击‘载入’”或“我按下了‘ALT+L’”，说清楚您用了哪种方法，有时候这也有关系。
详细：
信息宁多毋少！如果您说了很多，程序员可以略去一部分，可是如果您说的太少，他们就不得不回过头再去问您一些问题。有一次我收到了一份bug报告只有一句话，每一次我问他更多事情时，他每次的回复都是一句话，于是我花了几个星期的时间才得到了有用的信息。
五、不该问的问题
以下是几个经典蠢问题，以及黑客没回答时心中所想的：
问题：我能在哪找到 X 程序或 X 资源？
问题：我怎样用 X 做 Y？
问题：如何设定我的 shell 提示？
问题：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗？
问题：我的程序/设定/SQL 语句没有用
问题：我的 Windows 电脑有问题，你能帮我吗？
问题：我的程序不会动了，我认为系统工具 X 有问题
问题：我在安装 linux(或者 X )时有问题，你能帮我吗？
问题：我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？
问题：我能在哪找到 X 程序或 X 资源？
回答：就在我找到它的地方啊，白痴 —— 搜索引擎的那一头。天哪！难道还有人不会用 Google 吗？
问题：我怎样用 X 做 Y？
回答：如果你想解决的是 Y ，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对 X 完全无知，也对 Y 要解决的问题糊涂，还被特定形势禁锢了思维。最好忽略这种人，等他们把问题搞清楚了再说。
问题：如何设定我的 shell 提示？？
回答：如果你有足够的智慧提这个问题，你也该有足够的智慧去 RTFM，然后自己去找出来。
问题：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗？
回答：试试看就知道了。如果你试过，你既知道了答案，就不用浪费我的时间了。
问题：我的{程序/设定/SQL 语句}不工作
回答：这不算是问题吧，我对要我问你二十个问题才找得出你真正问题的问题没兴趣 —— 我有更有意思的事要做呢。在看到这类问题的时候，我的反应通常不外如下三种
◆你还有什么要补充的吗？
◆真糟糕，希望你能搞定。
◆这关我有什么屁事？
问题：我的 Windows 电脑有问题，你能帮我吗？
回答：能啊，扔掉微软的垃圾，换个像 Linux 或 BSD 的开源操作系统吧。
注意：如果程序有官方版 Windows 或者与 Windows 有互动(如 Samba)，你可以问与 Windows 相关的问题， 只是别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶， 因为 Windows 一般来说实在太烂，这种说法通常都是对的。
问题：我的程序不会动了，我认为系统工具 X 有问题
回答：你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与函数库档案有明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据，当你这样声称时，你必须有清楚而详尽的缺陷说明文件作后盾。
问题：我在安装 Linux(或者 X )时有问题，你能帮我吗？
回答：不能，我只有亲自在你的电脑上动手才能找到毛病。还是去找你当地的 Linux 使用群组者寻求实际的指导吧(你能在这儿找到使用者群组的清单)。
注意：如果安装问题与某 Linux 的发行版有关，在它的邮件列表、论坛或本地使用者群组中提问也许是恰当的。此时，应描述问题的准确细节。在此之前，先用 Linux 和所有被怀疑的硬件作关键词仔细搜索。
问题：我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？
回答：想要这样做，说明了你是个卑鄙小人；想找个黑客帮你，说明你是个白痴！
六、好问题与蠢问题
最后，我将透过举一些例子，来说明怎样聪明的提问；同一个问题的两种问法被放在一起，一种是愚蠢的，另一种才是明智的。
蠢问题：
我可以在哪儿找到关于 Foonly Flurbamatic 的资料？
这种问法无非想得到 STFW 这样的回答。
聪明问题：
我用 Google 搜索过 "Foonly Flurbamatic 2600"，但是没找到有用的结果。谁知道上哪儿去找对这种设备编程的资料？
这个问题已经 STFW 过了，看起来他真的遇到了麻烦。
蠢问题：
我从 foo 项目找来的源码没法编译。它怎么这么烂？
他觉得都是别人的错，这个傲慢自大的提问者。
聪明问题：
foo 项目代码在 Nulix 6.2 版下无法编译通过。我读过了 FAQ，但里面没有提到跟 Nulix 有关的问题。这是我编译过程的记录，我有什么做的不对的地方吗？
提问者已经指明了环境，也读过了 FAQ，还列出了错误，并且他没有把问题的责任推到别人头上，他的问题值得被关注。
蠢问题：
我的主机板有问题了，谁来帮我？
某黑客对这类问题的回答通常是：好的，还要帮你拍拍背和换尿布吗？，然后按下删除键。
聪明问题：
我在 S2464 主机板上试过了 X 、 Y 和 Z ，但没什么作用，我又试了 A 、 B 和 C 。请注意当我尝试 C 时的奇怪现象。显然 florbish 正在 grommicking，但结果出人意料。通常在 Athlon MP 主机板上引起 grommicking 的原因是什么？有谁知道接下来我该做些什么测试才能找出问题？
这个家伙，从另一个角度来看，值得去回答他。他表现出了解决问题的能力，而不是坐等天上掉答案。
在最后一个问题中，注意告诉我答案和给我启示，指出我还应该做什么诊断工作之间微妙而又重要的区别。
事实上，后一个问题源自于 2001 年 8 月在 Linux 内核邮件列表(lkml)上的一个真实的提问。我(Eric)就是那个提出问题的人。我在 Tyan S2464 主板上观察到了这种无法解释的锁定现象，列表成员们提供了解决这一问题的重要信息。
通过我的提问方法，我给了别人可以咀嚼玩味的东西；我设法让人们很容易参与并且被吸引进来。我显示了自己具备和他们同等的能力，并邀请他们与我共同探讨。通过告诉他们我所走过的弯路，以避免他们再浪费时间，我也表明了对他们宝贵时间的尊重。
事后，当我向每个人表示感谢，并且赞赏这次良好的讨论经历的时候， 一个 Linux 内核邮件列表的成员表示，他觉得我的问题得到解决并非由于我是这个列表中的名人，而是因为我用了正确的方式来提问。
黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙；我相信他是对的，如果我像个乞讨者那样提问，不论我是谁，一定会惹恼某些人或者被他们忽视。他建议我记下这件事，这直接导致了本指南的出现。
