How To Ask Question

对那些不顾思考、或者在发文前不做他们该做的事的人的蔑视。那些人是时间杀手——他们只想索取，从不付出，消耗我们在更有趣的问题或更值得回答人的身上的时间。我们称这样的人为失败者（lusers）。

你不必在技术上很在行才能吸引住我们的注意，但你必须表现出能引导你变得在行的特质——机敏、有想法、善于观察、乐于主动参与解决问题。

如果你决定向我们求助，当然你也不希望被视为失败者，更不愿成为失败者中的一员。能立刻得到快速并有效答案的最好方法，就是像赢家那样提问——聪明、自信、有解决问题的思路，只是偶尔在特定的问题提上需要获得一点帮助。

在提问之前

在你准备要通过电子邮件、新闻群组或者聊天室提出技术问题前，请先做到以下事情：

1. 尝试在你准备提问的论坛的旧文章中搜索答案。
2. 尝试上网搜索以找到答案。
3. 尝试以阅读首层以找到答案。
4. 尝试阅读常见文件（FAQ）以找到答案。
5. 尝试自己检查或实验以找到答案。
6. 想你身边的强者朋友打听以找到答案。
7. 如果你是程式开发者，请尝试阅读源码以找到答案。

尝试提出疑问的时候，请先表明你已经做了上述的努力：这将有助于梳理你并不是一个不劳而获切浪费别人的时间的提问者。如果你能一并表达了做了上述努力的过程中所学到的东西更好，因为我们更乐于回答那些表现出能从答案中学习的人的问题。

运用某些策略，比如先用Google搜索你所遇到的各种错误信息（即搜索Google论坛，也Google网页 这需要翻墙 要么vpn 要么就用Lantern等等 上网上搜索翻墙教程），这样很可能直接就找到了能解决问题的文件或邮件列表线索。即使没有搜索结果，在邮件列表或新闻组寻求帮助时加上一句“我在Google中搜索过下列句子但没有找到什么有用的东西”，也是件好事，即使它只是表名了搜索引擎不能提供哪些帮助。这么做（加上搜索过的子串）也让遇到相似问题的其他人能被搜索引擎引导到你的提问来。

被着急，不要指望几秒钟的Google搜寻就能解决一个复杂的问题、在想专家求助之前，再阅读 一下常见问题文件（FAQ）、放轻松、坐舒服一些，在花点儿时间死牢一下这个问题。相信我们，他们能从你提问看出你做了多少阅读与思考，如果你是有备而来，将更有可能得到解答。不要将所有问题一股脑抛出，只因你的第一次搜索没有找到答案（或者找到太多答案）。

准备好你的问题，再讲问题仔细的思考过一遍，因为草率的发文只能得到草率的回答，或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力，你越可能得到实质性的帮助。

小心别问错了问题。如果你的问题基于错误的假设，某个普通黑客（J.Random Hacker）多半会一边在心里想着“蠢问题”，一边用无意识的字面解释来答复你，希望这你会从问题的回答（而非你想得到的答案）中吸取教训。

绝不要自以为狗哥得到答案，你并没有：你并没有。冰机你没有为这种服务支付任何报酬。你将会是自己去挣到一个答案，考提出有内涵的、有趣的、有思维激动作用的问题——一个有潜力能贡献社群经验的问题，而不仅仅是被动的从他人处索取知识。

另一方面，表名你愿意在找答案的过程中做点什么是一个非常好的开端。“谁能给点提示”、“我的这个例子里缺了什么？”以及“我应该减产什么地方”比“请把我需要的确切的过程贴出来”更容易得到答复。因为你表现出只要有人指个正确方向，你就有完成它的能力和决心。

当你提问时

慎选提问的论坛

小心选择你要提问的场合。如果你做了下述的事情，你很能被忽略掉或者被看做失败者：
- 在与主题不合的论坛上贴出你的问题
- 在探索进阶技术问题的论坛非常初期的问题；反之亦然
- 在太多的不同新闻组上重复转帖同样的问题（cross-post）
- 向既非熟人也没有义务解决你问题的人发送私人电邮

下列推荐几个网站：谷歌开发者社区、github、stackoverflow、codekk、arsenal、Android Libraries and Resources、grepcode、Android 开发文档
（如果还有好的网站，欢迎推荐 共同学习 共同进步）

搞清楚你的主题！最经典的错误之一是在某种致力于跨平台可一直语言、嵌套或工具的论坛中提关于Unix或Windows作业系统程序界面的问题。如果你不明白为什么这是打错，最好在搞清楚这之间差异之前什么也别问。

使用有意义且描述明确的标题

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

蠢问题：救命啊！我的必点不能正常显示了！
聪明问题：X.org 6.8.1的滑鼠游标会变形，某牌显示卡MV1005晶片组。
更聪明问题：X.org 6.8.1的滑鼠游标，在某牌显示卡MV1005晶片组环境下-会变形

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

话不在多而在精

别动辄声称找到Bug

可以低声下气，但还是要先做功课

描述问题症状而非猜测

蠢问题

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

聪明问题

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

按发生时间先后列出问题症状

如果你想弄清楚如何做某事，在开头描述你的目标，然后才陈述重现你所卡主的特定步骤。
蠢问题

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

聪明问题

我正试着用替换一副图片的色码成自己选定的色吗，我现在知道的唯一方法是编辑每个色码块，但却无法从某个远程式的颜色选择器取得十六进制的RGB值。

清楚明确的表达你的问题以及需求

漫无边际的提问近乎无休无止的时间黑洞。最有可能给你有用答案的人通常也正是最忙的人（他们忙是因为要亲自完成大部分工作）。这样的人对无节制的时间黑洞相当厌恶，所以他们也倾向与厌恶那些漫无边际的提问。

如果你明确表述需要回答做什么（如提供指点、发送一段程式码、检查你的不定、或者其他等等），就最有可能得到有用的答案，因为这会定出一个事件和精力的上限，便于回答这集中精力来帮你。这么做很棒。

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

所以，界定一下你的问题，是专家花在便是你的问题和回答所需要付出的时间减少到最少，这技巧对你的回答相当有帮助–但这技巧和简化问题有所区别。因为，问“我想更好理解X，可够指点一下哪里有好一点的说明？”通常比问“你能解释一下X吗？”更好。如果你的程式码不能运作，通常请别人看看哪里有问题，比要求别人替你改正明智得多。

询问有关程式码的提问时

被要求他人帮你有问题的代码出错而不提示应该从何入手。张贴几百行的代码，然后说一声：“他不会动”会让你完全被忽略。直贴十几行代码，然后说一句“在第七行以后，我期待它显示,但世纪出现的是”比较有可能让你得到回应。

最有效描述程式问题的方法是提供最精简的Bug展示测试示例（bug-demonstratinf test case）。什么是最精简的测试示例？那是问题的缩影：一个小程式片段能刚好展示出程式的异常行为，而不包含其他令人分散注意力的内容。怎么制作最精简的测试用例？如果你知道哪一行或那一段程式码会造成异常的行文，复制下来并加入足够重现这个状况的程式码（例如，足以让这段程式码能被编译/直译/被应用程式处理）。如果你无法将问题所见到一个特定区域，就复制一份程式码并移除不影响产生问题行为的部分。总之，测试示例越小越好。

别把自己佳通作业的问题贴上来

去掉无意义的提问句

避免用无意义的话结束提问，例如，“有人能帮我吗？”或者“还有答案吗？”

首先：如果你对问题的描述不是很好，这样问更是画蛇添足。

其次：由于这样问是画蛇添足，黑客们会很厌烦你–而且通常会选用逻辑上正确，但毫无意义的回答来表示他们的蔑视。例如：“没错，有人能帮你”或者“不，没答案”。

一般来说，避免用“是或否”、“对或错”、“有或没有”类型的问句，除非你想得到的是或否类型的回答。

即使你很紧急也不要在标题写 紧急

这是你的问题，不是我的问题。

礼多人不怪，而且有时还很有帮著

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

问题解决后，加个简短的补充说明

问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再一次向他们表示感谢。

最理想的方式是向最初提问的话题恢复此消息，并在标题中包含“已修正”，“已解决”或其他同等含义的明显标记。

补充说明不必很长或是很深入：简单的一句“你好，原来是网络线除了问题！谢谢大家 -Bill”比什么也不说要来的好。

如何戒赌答案

RTFM和STFW：如何知道你已完全搞砸了

有一个古老而神圣的传统：如果你收到RTFM（Read The Fucking Manual）的回应，回答者认为你应该读那该死的手册。当然，基本上他是对的，你应该去读一读。

RTFM有一个年轻的亲戚。如果你收到STFW（Search TheFucking Web）的回应，回答者认为你应该到该死的网络上搜索过了。那个人多半也是对的，去搜索一下吧。（更温和一点的说法是Google是你的朋友）

在论坛，你也肯恩被要求去爬爬论坛的旧文。实际上，有人甚至可能热心地为你提供以前解决问题的讨论串。但不要依赖这种关照，提问前应该先搜索一下旧文。

通常，用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他们打这些字的时候也正在读着。这些答复意味着回答者认为
- 你需要的咨询非常容易获得
- 你自己去搜索这些咨询比灌给你能让你学到更多。

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

如果还是搞不懂

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

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

处理无理的回应

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

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

不该问的问题

问题：我能在哪找到X程式或X资源

回答：就在我找到它的地方啊，保持–搜索引擎的那一头。天哪！难道还有人不会用Google吗？

问题：我怎样用X做Y?

回答：如果你想解决的是Y，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对X完全无知，也对Y要解决的问题糊涂，还被特定形式禁锢了思想。最好忽略这种人，等他们把问题好清楚了再说。

问题：如何设定我的shell提示？？

回答：如果你有足够的智慧提这个问题，你也该有足够的智慧去RTFM，然后自己去找出来。

问题：我可以用Bass-o-matic文件转换工具将AcmeCrop档案转换为TeX格式吗？

回答：试试看就知道了。如果你试过了，你既知道答案，就不用浪费我的时间了。

问题：我的程式/设定/SQL语句没有用

回答：这不算是问题吧，我对要我问你二十个问题才找得出你真正的问题没兴趣-我有更有意思的事要做呢。在看到这类问题的时候，我的反应通常不外如下三种
- 你还有什么要补充的吗？
- 真糟糕，希望你能搞定
- 这关我有什么屁事？

问题：我的Windows电脑有问题，你能帮我吗？

回答：能啊，扔掉微软的垃圾，换个像Linux或BSD的开放源码作业系统吧。

注意：如果程式有官方版Windows或者与Windows有互动（如Samba）骂你可以问与Windows相关的问题，只是被对问题是由WIndows作业系统而不是程式本身造成的回复感到惊讶，因为Windows一般来说实在太烂，这种说法通常都是对的。

问题：我的程式不会动了，我认为系统工具X有问题

回答：你完全有可能是第一个注意到被成千上万用户反复使用的系统呼叫与函式库档案有明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据，当你这样声称时，你必须有清楚而详细的缺陷说明文件做后盾。

问题：我在安装Linux（或者X）时有问题，你能帮到我吗？

回答：不能，我只有亲自在你的电脑上动手才能找到脑病。还是去找你当地的Linux使用群组织者寻求实际的指导吧（你能在这儿找到使用者群组的清单）。

注意：如果安装问题与某Linux的发行版有关，在它的邮件列表、论坛或本地使用者群组中提问也许是恰当的。此时，应描述问题的准确细节。再次之前，先用Linux和所有被怀疑的硬体做关键词仔细搜寻。

问题：我怎么才能破解root账号/获取OP特权/读别人的邮件呢？

回答：想要这样做，说明了你是个卑鄙小人；想找黑客帮你，说明你是个白痴。

好问题与蠢问题

最后，我将透过举一些例子，来说明怎样聪明的提问；同一个问题，的两种文法被放在一起，一个是愚蠢的，另一种才是聪明的。
蠢问题

我可以在哪儿找到关于Foonly Flurbamaticde 的资料？

这种文法无非想得到STFW这样的回答。
聪明问题：

我用Google搜索过”Foonly Flurbamaticde 2600”,但是没找到有用的结构。谁知道上哪儿去找对这种设备编程的资料？

这个为题已经STFW过了，看起来他真的遇到了麻烦。