前言
你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你变得在行的特质 —— 机敏、有想法、善于观察、乐于主动参与解决问题。
能立刻得到快速并有效答案的最好方法，就是像赢家那样提问 —— 聪明、自信、有解决问题的思路，只是偶尔在特定的问题上需要获得一点帮助。
在提问之前
在你准备提出技术问题前，请先做到以下事情：
- 尝试在你准备提问的论坛的旧文章中搜索答案。
- 尝试上网搜索以找到答案。
- 尝试阅读手册以找到答案。
- 尝试阅读常见问题文件（FAQ）以找到答案。
- 尝试自己检查或试验以找到答案。
- 向你身边的强者朋友打听以找到答案。
- 如果你是程序开发者，请尝试阅读源代码以找到答案。
当你提出问题的时候，请先表明你已经做了上述的努力。
这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。
如果你能一并表达在做了上述努力的过程中所学到的东西会更好，因为我们更乐于回答那些表现出能从答案中学习的人的问题。
提问前SOP：
google搜索 -> 阅读FAQ -> 再将问题仔细思考一遍 -> 综合检索到的材料+思考+试错过程 -> 提问
在提问时
提问时采用有意义且描述明确的问题
一个好标题是目标-差异式的描述，在目标部分指出是哪一个或哪一组东西有问题，在差异部分则描述与期望的行为不一致的地方。
使用清晰、正确、精准且合乎语法的语句
正确的拼写、标点符号和大小写是很重要的。花点额外的精力斟酌一下字句，用不着太僵硬与正式，它必须很准确，而且有迹象表明你是在思考和关注问题。
精确地描述问题并言之有物
- 仔细、清楚地描述你的问题或 Bug 的症状。
- 描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息），提供经销商的发行版和版本号（如：Fedora Core 4、Slackware 9.1等）。
- 描述在提问前你是怎样去研究和理解这个问题的。
- 描述在提问前为确定问题而采取的诊断步骤。
- 描述最近做过什么可能相关的硬件或软件变更。
- 尽可能地提供一个可以重现这个问题的可控环境的方法。
尽量去揣测一个黑客会怎样反问你，在你提问之前预先将黑客们可能提出的问题回答一遍。
简化你的问题
你需要提供精确有内容的信息，这并不是要求你简单的把成堆的出错代码或者资料完全写到你的提问中，所以需要简化问题。
如果你有庞大而复杂的测试样例能重现程序挂掉的情境，尽量将它剪裁得越小越好。
描述问题症状而非你的猜测
告诉别人你认为问题是怎样造成的并没什么帮助。（如果你的推断如此有效，还用向别人求助吗？），因此要确信你原原本本告诉了他们问题的症状，而不是你的解释和理论，让别人来推测和诊断。
如果你认为陈述自己的猜测很重要，清楚地说明这只是你的猜测，并描述为什么它们不起作用。
按发生时间先后列出问题症状
问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，你的说明里应该包含你的操作步骤，以及机器和软件的反应，直到问题发生。
在命令行处理的情况下，提供一段操作记录（例如运行脚本工具所生成的），并引用相关的若干行（如 20 行）记录会非常有帮助。
试着选取提供有用的信息而不是让读者淹没在垃圾中。
假如说明很长，在开头简述问题，接下来再按时间顺序详细描述。
想弄清楚如何做某事的问题：描述目标而不是过程
如果你想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。
代码相关的问题：提供最精简的 Bug 展示测试用例
最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例（bug-demonstrating test case）。
什么是最精简的测试用例？那是问题的缩影。一小个程序片段能刚好展示出程序的异常行为，而不包含其他令人分散注意力的内容。
怎么制作最精简的测试用例？如果你知道哪一行或哪一段代码会造成异常的行为，复制下来并加入足够重现这个状况的代码（例如，足以让这段代码能被编译/直译/被应用程序处理）。
如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。总之，测试用例越小越好。
一般而言，要得到一段相当精简的测试用例并不太容易，但永远先尝试这样做是一个好习惯。这种方式可以帮助你了解如何自行解决这个问题。
如何解读答案
如果你看不懂回应，别立刻要求对方解释。像你以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。
如果你真的需要对方解释，记得表现出你已经从中学到了点什么。
参考资料
How-To-Ask-Questions-The-Smart-Way
