提问的方式,解读答案等内容讲解
树图思维导图提供 提问的智慧 在线思维导图免费制作,点击“编辑”按钮,可对 提问的智慧 进行在线思维导图编辑,本思维导图属于思维导图模板主题,文件编号是:d6349e57d538000225bc35470b935730
提问的智慧思维导图模板大纲
许多项目在他们网站的帮助文档中链接了本指南。这很好,这正是我们想要的用途。但如果你是该项目管理员并试图创建指向本指南的超链接,请在超链接附近的显著位置注明: 本指南不提供此项目的实际支持服务! 我们已经深刻领教到缺少上述声明所带来的痛苦:我们将不停地被那些认为发布这本指南就意味着有责任解决世上所有技术问题的傻瓜苦苦纠缠。 如果你因寻求某些帮助而阅读本指南,并在离开时还觉得可以从本文作者这里得到直接帮助,那你就是我们之前说的那些傻瓜之一。别问我们问题,我们只会忽略你。我们在这本指南中想教你如何从那些真正懂得你所遇到的软件或硬件问题的人处取得协助,而 99% 的情况下那不会是我们。除非你确定本指南的作者之一刚好是你所遇到的问题领域的专家,否则请不要打扰我们,这样大家都会开心一点。
简介
1. 尝试在你准备提问的论坛的旧文章中搜索答案。
2. 尝试上网搜索以找到答案。
3. 尝试阅读手册以找到答案。
4. 尝试阅读常见问题文件(FAQ)以找到答案。
5. 尝试自己检查或试验以找到答案。
6. 向你身边的强者朋友打听以找到答案。
7. 如果你是程序开发者,请尝试阅读源代码以找到答案。
慎选提问的论坛
在与主题不合的论坛上贴出你的问题。
在探讨进阶技术问题的论坛张贴非常初级的问题;反之亦然。
在太多的不同新闻群组上重复转贴同样的问题(cross-post)。
向既非熟人也没有义务解决你问题的人发送私人电邮。
Stack Overflow
Super User 是问一些通用的电脑问题,如果你的问题跟代码或是写程序无关,只是一些网络连线之类的,请到这里。
Stack Overflow 是问写程序有关的问题。
Server Fault 是问服务器和网管相关的问题。
网站和 IRC 论坛
第二步,使用项目邮件列表
任何好到需要向个别开发者提出的问题,也将对整个项目群组有益。反之,如果你认为自己的问题对整个项目群组来说太愚蠢,那这也不能成为骚扰个别开发者的理由。
向列表提问可以分散开发者的负担,个别开发者(尤其是项目领导人)也许太忙以至于没法回答你的问题。
大多数邮件列表都会被存档,那些被存档的内容将被搜索引擎索引。如果你向列表提问并得到解答,将来其他人可以通过网页搜索找到你的问题和答案,也就不用再次发问了。
如果某些问题经常被问到,开发者可以利用此信息来改进说明文件或软件本身,以使其更清楚。如果只是私下提问,就没有人能看到最常见问题的完整场景。
使用有意义且描述明确的标题
使问题容易回复
<a name="使用清晰、正确、精准且合乎语法的语句">使用清晰、正确、精准且合乎语法的语句</a>
英文不是我的母语,请原谅我的错字或语法。
如果你说**某语言**,请向我发电邮/私信;
我需要有人协助我翻译我的问题。
我对技术名词很熟悉,但对于俗语或是特别用法不甚了解。
我把我的问题用**某语言**和英文写出来。
如果你只用其中的一种语言回答,我会乐意将回复翻译成为你使用的语言。
使用易于读取且标准的文件格式发送问题
使用纯文字而不是 HTML ( 并不难)。
使用 MIME 附件通常是可以的,前提是真正有内容(譬如附带的源代码或 patch),而不仅仅是邮件程序生成的模板(譬如只是信件内容的拷贝)。
不要发送一段文字只是一行句子但自动换行后会变成多行的邮件(这使得回复部分内容非常困难)。设想你的读者是在 80 个字符宽的终端机上阅读邮件,最好设置你的换行分割点小于 80 字。
但是,对一些特殊的文件**不要**设置固定宽度(譬如日志文件拷贝或会话记录)。数据应该原样包含,让回复者有信心他们看到的是和你看到的一样的东西。
在英语论坛中,不要使用`Quoted-Printable` MIME 编码发送消息。这种编码对于张贴非 ASCII 语言可能是必须的,但很多邮件程序并不支持这种编码。当它们处理换行时,那些文本中四处散布的`=20`符号既难看也分散注意力,甚至有可能破坏内容的语意。
绝对,**永远**不要指望黑客们阅读使用封闭格式编写的文档,像微软公司的 Word 或 Excel 文件等。大多数黑客对此的反应就像有人将还在冒热气的猪粪倒在你家门口时你的反应一样。即便他们能够处理,他们也很厌恶这么做。
如果你从使用 Windows 的电脑发送电子邮件,关闭微软愚蠢的`智能引号`功能 (从[选项] > [校订] > [自动校正选项],勾选掉`智能引号`单选框),以免在你的邮件中到处散布垃圾字符。
在论坛,勿滥用`表情符号`和`HTML`功能(当它们提供时)。一两个表情符号通常没有问题,但花哨的彩色文本倾向于使人认为你是个无能之辈。过滥地使用表情符号、色彩和字体会使你看来像个傻笑的小姑娘。这通常不是个好主意,除非你只是对性而不是对答案感兴趣。
精确地描述问题并言之有物
仔细、清楚地描述你的问题或 Bug 的症状。
描述问题发生的环境(机器配置、操作系统、应用程序、以及相关的信息),提供经销商的发行版和版本号(如:`Fedora Core 4`、`Slackware 9.1`等)。
描述在提问前你是怎样去研究和理解这个问题的。
描述在提问前为确定问题而采取的诊断步骤。
描述最近做过什么可能相关的硬件或软件变更。
尽可能地提供一个可以`重现这个问题的可控环境`的方法。
话不在多而在精
你需要提供精确有内容的信息。这并不是要求你简单的把成堆的出错代码或者资料完全转录到你的提问中。如果你有庞大而复杂的测试样例能重现程序挂掉的情境,尽量将它剪裁得越小越好。
这样做的用处至少有三点。
第一,表现出你为简化问题付出了努力,这可以使你得到回答的机会增加;
第二,简化问题使你更有可能得到有用的答案;
第三,在精炼你的 bug 报告的过程中,你很可能就自己找到了解决方法或权宜之计。
别动辄声称找到 Bug
低声下气不能代替你的功课
有些人明白他们不该粗鲁或傲慢的提问并要求得到答复,但他们选择另一个极端 —— 低声下气:`我知道我只是个可悲的新手,一个失败者,但...`。这既使人困扰,也没有用,尤其是伴随着与实际问题含糊不清的描述时更令人反感。
别用原始灵长类动物的把戏来浪费你我的时间。取而代之的是,尽可能清楚地描述背景条件和你的问题情况。这比低声下气更好地定位了你的位置。
有时网页论坛会设有专为新手提问的版面,如果你真的认为遇到了初学者的问题,到那去就是了,但一样别那么低声下气。
描述问题症状而非你的猜测
按发生时间先后列出问题症状
描述目标而不是过程
别要求使用私人电邮回复
清楚明确地表达你的问题以及需求
询问有关代码的问题时
别把自己家庭作业的问题贴上来
去掉无意义的提问句
避免用无意义的话结束提问,例如`有人能帮我吗?`或者`这有答案吗?`。
首先:如果你对问题的描述不是很好,这样问更是画蛇添足。
其次:由于这样问是画蛇添足,黑客们会很厌烦你 —— 而且通常会用逻辑上正确,但毫无意义的回答来表示他们的蔑视, 例如:`没错,有人能帮你`或者`不,没答案`。
一般来说,避免用 `是或否`、`对或错`、`有或没有`类型的问句,除非你想得到是或否类型的回答 https://strcat.de/questions-with-yes-or-no-answers.html
即使你很急也不要在标题写`紧急`
礼多人不怪,而且有时还很有帮助
彬彬有礼,多用`请`和`谢谢您的关注`,或`谢谢你的关照`。让大家都知道你对他们花时间免费提供帮助心存感激。
坦白说,这一点并没有比使用清晰、正确、精准且合乎语法和避免使用专用格式重要(也不能取而代之)。黑客们一般宁可读有点唐突但技术上鲜明的 Bug 报告,而不是那种有礼但含糊的报告。(如果这点让你不解,记住我们是按问题能教给我们什么来评价问题的价值的)
然而,如果你有一串的问题待解决,客气一点肯定会增加你得到有用回应的机会。
(我们注意到,自从本指南发布后,从资深黑客那里得到的唯一严重缺陷反馈,就是对预先道谢这一条。一些黑客觉得`先谢了`意味着事后就不用再感谢任何人的暗示。我们的建议是要么先说`先谢了`,然后事后再对回复者表示感谢,或者换种方式表达感激,譬如用`谢谢你的关注`或`谢谢你的关照`。)
问题解决后,加个简短的补充说明
RTFM 和 STFW:如何知道你已完全搞砸了
**你需要的信息非常容易获得**;
**你自己去搜索这些信息比灌给你,能让你学到更多**。
你不应该因此不爽;依照黑客的标准,他已经表示了对你一定程度的关注,而没有对你的要求视而不见。你应该对他祖母般的慈祥表示感谢。
如果还是搞不懂
如果你看不懂回应,别立刻要求对方解释。像你以前试着自己解决问题时那样(利用手册,FAQ,网络,身边的高手),先试着去搞懂他的回应。如果你真的需要对方解释,记得表现出你已经从中学到了点什么。
比方说,如果我回答你:`看来似乎是 zentry 卡住了;你应该先清除它。`,然后,这是一个很糟的后续问题回应:`zentry 是什么?` 好的问法应该是这样:`哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries,而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗?还是我看漏了什么?`
处理无礼的回应
如何避免扮演失败者
你还有什么要补充的吗?
真糟糕,希望你能搞定。
这关我屁事?
蠢问题:
我可以在哪儿找到关于 Foonly Flurbamatic 的资料? 这种问法无非想得到 STFW #RTFM 这样的回答。
聪明问题:
我用 Google 搜索过 "Foonly Flurbamatic 2600",但是没找到有用的结果。谁知道上哪儿去找对这种设备编程的资料? 这个问题已经 STFW 过了,看起来他真的遇到了麻烦。
蠢问题:
我从 foo 项目找来的源码没法编译。它怎么这么烂? 他觉得都是别人的错,这个傲慢自大的提问者。
聪明问题:
foo 项目代码在 Nulix 6.2 版下无法编译通过。我读过了 FAQ,但里面没有提到跟 Nulix 有关的问题。这是我编译过程的记录,我有什么做的不对的地方吗? 提问者已经指明了环境,也读过了 FAQ,还列出了错误,并且他没有把问题的责任推到别人头上,他的问题值得被关注。
如果得不到回答
态度和善一点。
问题带来的压力常使人显得无礼或愚蠢,其实并不是这样。
对初犯者私下回复。
对那些坦诚犯错之人没有必要当众羞辱,一个真正的新手也许连怎么搜索或在哪找常见问题都不知道。
如果你不确定,一定要说出来!
一个听起来权威的错误回复比没有还要糟,别因为听起来像个专家很好玩,就给别人乱指路。要谦虚和诚实,给提问者与同行都树个好榜样。
如果帮不了忙,也别妨碍他。
不要在实际步骤上开玩笑,那样也许会毁了提问者的设置 —— 有些可怜的呆瓜会把它当成真的指令。
试探性的反问以引出更多的细节。
如果你做得好,提问者可以学到点东西 —— 你也可以。试试将蠢问题转变成好问题,别忘了我们都曾是新手。
尽管对那些懒虫抱怨一声 RTFM 是正当的,但能给出文档的链接(即使只是建议个 Google 搜索关键词)会更好。
如果你决定回答,就请给出好的答案。
当别人正在用错误的工具或方法时别建议笨拙的权宜之计(workaround),应推荐更好的工具,重新界定问题。
正面地回答问题!
如果这个提问者已经很深入的研究而且也表明已经试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到结果,回答 `试试看 A 或是 B` 或者 `试试 X 、 Y 、 Z 、 A 、 B 、 C` 并附上一个链接一点用都没有。
帮助你的社区从问题中学习。
当回复一个好问题时,问问自己`如何修改相关文件或常见问题文件以免再次解答同样的问题?`,接着再向文件维护者发一份补丁。
如果你在研究一番后才作出了回答,展现你的技巧而不是直接端出结果。毕竟`授人以鱼不如授人以渔`。
Evelyn Mitchel 贡献了一些愚蠢问题例子并启发了编写`如何更好地回答问题`这一节, Mikhail Ramendik 贡献了一些特别有价值的建议和改进。
树图思维导图提供 走近文本感受小说之美 在线思维导图免费制作,点击“编辑”按钮,可对 走近文本感受小说之美 进行在线思维导图编辑,本思维导图属于思维导图模板主题,文件编号是:2655ac48e91d1f99f2b7b844a7d63ee0
树图思维导图提供 电子商务客户服务 在线思维导图免费制作,点击“编辑”按钮,可对 电子商务客户服务 进行在线思维导图编辑,本思维导图属于思维导图模板主题,文件编号是:0aac532b9ae4c1114c35029b9a098532