智慧的提问(不做慵懒的寄生虫)

提问的智慧

作者:Eric Steven Raymond:《How To Ask Questions The Smart Way》

版本:3.9

修改时间:2013年4月13日

翻译:王刚(yafrank at 126 dot com)

翻译时间:2010年9月28日

王刚翻译版本

修改注释:陈锦辉(cnfeat at Gmail dot com)

修改注释时间:2014年5月15日

注释版本:3.9

摘要

提问在学习中占据着重要的位置,很多人对知识好奇,却收效甚少,原因他们是尚未掌握正确提问的方法,因此,我尝试修改《提问的智慧》,发布出来。原作者是Eric S. Raymond,这篇文章在黑客界拥有很高的地位,指引无数黑客前进,希望对你有用。

为何要做一个修改注释版?

试图做出一个容易阅读,方便理解,与时俱进,可以执行的提问执行方案。

    1. 原翻译为2010年,新版2013年,时隔2年有余,原作有变;
    1. 尊重原作的复制及引用协议[1];
    1. 原翻译很好,检查中发现有些语句不顺,语意不准,或者已不符合现在语言规范,参照王刚老师的版本进行修改;
    1. 附上自己的看法和注解,更加适合现在阅读使用。
    1. 每当有人来向我提问,我可以将他指引到这篇文章,可以减少很多的不必要的麻烦。

【本章注释】

[1]复制协议中注明了应用该文时不可复制部分或者部分引用,只能全文转载。

You may not make or redistribute static copies (whether print or online) without my express permission.

However, I don't like having old, stale versions of my content floating around on other peoples' sites. These rules are mainly designed to try to ensure that when some third party sees my name on a document, the content reflects all my updates to it.

译文

译文: 印尼语、 巴西葡萄牙语、 汉语、 捷克语、 丹麦语、 荷兰语、 爱沙尼亚语、 芬兰语、 法语、 乔治亚语、 德语、 希腊语、 希伯来语、 匈牙利语、 意大利语、 日语、 蒙古语、 波兰语、 葡萄牙语、 罗马尼亚语、 俄语、 塞尔维亚语、 西班牙语、 瑞典语、 泰语、 土耳其语。 如果你想复制、镜像、翻译或引用本文,请参阅我的 复制协议[2]。

【本章注释】

[2]这份复制协议类似于版权声明,这份声明主要说明了以下四点:(1)你们可以复制此文,可以添加本站链接;(2)但是转载需注明出处,原版本经常更新(已更新11次),转载版本不会更新;(3)不可以部分引用,或拼接此文;(4)翻译要注明出处,并且注明翻译时间和翻译版本。

免责声明

许多的项目单位都在在他们的网站附加了帮助的链接,这正是我们想要的。但按照现实情况,如果你是该网站项目负责人,请在链接附近显著位置注明:我们不提供该项目的服务支持!

我们已经领教了没有此说明带来的痛苦,我们将不停地被一些白痴们纠缠,他们认为既然我们发布了帮助链接,那么我们就有责任解决世上所有的技术问题。

如果你是因为需要帮助正在阅读本文,还想着直接从作者那取得帮助(答案),然后挥一挥衣袖转身离开,那么你就不幸成了我们所说的白痴之一。别向我们提问,我们不会理你的。我们只是在这教你「如何从那些真正懂得问题答案的人那里取得帮助」的方法。不过,在99.9%的时间里我们不会是那些百事通。除非你非常地确定本文的作者是你的问题专家,否则请不要打扰,这样大家都更开心一点。

引言

在黑客[3]的世界里,你所提技术问题的解答很大程度上取决于你提问的方式与此问题的难度,本文将教你如何提问才更有可能得到满意的答复。

开源程序的应用已经很广,你通常可以从其他更有经验的用户而不是黑客那里得到解答。这是好事,因为他们更能够容忍一般的新手错误。但我们还建议你使用我们推荐的方法,像对待黑客那样对待这些有经验的用户,这样,你能最有效地得到问题的回答。

第一件需要明白的事:黑客喜欢艰巨的任务和激发思考的好问题。否则,我们也不会写这篇文章了。如果你有值得我们反复咀嚼玩味的好问题,我们自会对你感激不尽。好问题是激励和馈赠,帮助我们发展认知,揭示没有注意的问题。对于黑客,提供「好问题」就是热情而真诚的赞扬。

虽然如此,黑客在外却有坏名声:遇到简单问题就表现出鄙视或傲慢的姿态。有时,我们看起来还会对新手和愚蠢的人有条件反射般的无礼,但事实并不如此。

我们只是毫无歉意地鄙视那些提问前不愿思考、不做功课的人。这种人就象时间黑洞一样,只知道索取,不愿意付出,他们在浪费我们时间,而这些时间我们本可用于其它更有趣的问题或更值得回答的人身上。我们将这种人叫做 「loser」[4] (由于历史原因,我们有时将「loser」拼写为「lusers」[5])。

我们注意到很多人只是想使用我们写的软件,对学习技术细节没有任何兴趣。对他们而言,计算机只是种工具,是种达到目的的手段而已。他们有自己的生活,有更重要的事要做,我们承认这一点,也从不指望每个人都能对这些让我们着迷的技术问题感兴趣。所以,我们回答问题也有自己的选择,仅仅回应那些真正对问题有兴趣并愿意主动参与解决问题的人,这一点现在不变,以后不会变,也不该变,否则,我们就无法做好那些该做好的事情了。

我们(大多数)是自愿者,从自己繁忙的生活中抽时间来回答问题,有时也会力不从心。因此,(请原谅)我们会毫不留情地过滤问题,特别是那些像是losers提的问题,这样,我们就有更多的时间和精力去回答那些winner[6]的问题

如果你认为这种态度令人反感、以施惠者自居或傲慢自大,烦请检查你的假设,我们并未要求你崇拜我们,事实上,假如你做了力所能及的努力,我们大多将非常乐意平等地与你交流,并欢迎你接纳我们的文化。我们认为试图去帮助那些不愿自助的人是一件没有效率和效果的事情。所以,我们宁愿被称作傲慢,也不去做愚蠢的事[7]。

所以,你无须拥有很高超技术也可以吸引我们的注意,前提是你必须表现出解决此问题的积极态度:热切关注、深入分析、试图努力查找过解决此问题的方法,并且乐意主动参与到解决问题的组织,分享你的想法。如果你做不到使你与众不同,我们建议你付费寻求他人帮助,而不是要求黑客提供无偿的帮助。

如果你决定向我们求助,不想成为一名loser,或者不想被看成一个lose,我们有一个立竿见影的方法:(1)有技术含量地提问,(2)像是一个有智慧有自信和会思考的人那样去提问,(3)暗示这个提问只是碰巧在特别情况出现的。

(欢迎你对本文进行指正,可以将建议发至[email protected][email protected]。请注意,本文不想成为一般的网络礼仪指南,同时,我也会拒绝回应引自论坛并与此文不相关的建议。)

【本章注释】

[3]本文不仅仅适用于黑客,而且适用于普通人。黑客的态度:解决问题,建设事物,崇尚自由和无私的双向帮助。出自Eric S. Raymond的另一篇著名文章《How To Become A Hacker》

[4]在此,用直接「loser」更加合适,语意浅点译做「失败者」,语意深点译做「废柴」、「贱人」和「窝囊废」。

[5]wikipedia的解释:「lusers」为「loser」和「user」的混合词,有贬义,指使人厌烦的,愚蠢的计算机操作员。

[6]指乐于分享,懂得专研和回报的人。

[7]人必自助而后人助之,而后天助之。出自《周易·系辞上》

提问前需要做的事情

在通过邮件、讨论组、论坛或社区提问之前,请先尝试做以下事情寻找答案:

    1. 使用论坛、知乎、百度知道、Quaro的搜索功能;
    1. 善用google、百度或其他搜索引擎在网络搜寻;
    1. 阅读说明书或者使用手册;
    1. 阅读网站上「常见问题解答」(FAQ);
    1. 自己检查或做试验;
    1. 请教熟悉此问题的朋友;
    1. 如果你是程序员,尝试阅读源代码。

提问时,请先表明你已做了上述事情,这将有助于改变你是懒又肥的寄生虫形象,同时给别人一种你不会浪费别人时间的印象。提问时最好再总结一下你从中学到的东西 ,我们喜欢那些善于学习总结的人,也喜欢回答他们提出的问题。

运用搜索策略,比如利用Google搜索时你遇到的各种提示(记得也搜索一下Google groups),这样很可能直接就找到了解决问题的文档或讨论组的相关线索。即使没有结果,在论坛或讨论小组寻求帮助时提一句「我在Google中搜过下列句子,但没有找到什么有用的东西」也是件好事,至少它表明了搜索引擎暂时还不能提供哪些帮助。另外,将搜索关键词与你的问题及可能的解决方案联系起来,还有助于引导其他有类似问题的人。

耐心一点,不要指望Google搜索几秒钟就能解决一个复杂的问题。读一下与产品或项目相关的常见问题解答。在向专家提问之前,先稍微放松一下,再深入地思考一下问题。相信我们,他们能从你的提问之中看得出你做了多少阅读与思考的准备功课,如果你是有备而来,专家们很有可能会为你解答。如果你第一次搜索没有结果(或者结果太多),也不要抛出一堆问题,专家们更喜欢有针对性的提问。

认真地思考,准备好你的问题。草率的提问只能得到草率的回答,甚至得不到回答。在提问时,你越是表现出在此前做过思考与努力去解决自己的问题,你越有可能得到真正的帮助。

注意别提问错误的问题。如果提问基于错误的假设,某黑客多半会一边想「这真是一个愚蠢的问题」,一边按将错就错地敷衍你,并且希望这个结果能够给你一个教训:如果提问的方式不对,你就得不到正确的答案。

永远不要假设你有资格得到解答。你没有这种资格,毕竟你没有为此服务付费。如果你能够提出有内容、有趣和激励思考的问题,你将通过自己的努力「挣到」答案,因为这种提问能够向社区贡献经验,而不仅仅是消极无止境地索取。

另一方面,展现你的能力,并且表明你乐意参与解决问题,这是个很好的开始。「有没有人能指个方向?」,「我这还差点什么?」,「我应该查哪个网站?」,通常要比「请给出我可以用的解决方案」更容易得到回复,因为你的行为表明一种积极的态度:只要有人能为我指明方向,我就会很乐意自己走完剩下的路。

提问时

认真选择论坛

谨慎地要选择提问的地方,如果你做了下述事情,多半会被忽视或被看成loser:

    1. 张贴与论坛主题无关的问题;
    1. 在面向高级技术问题的论坛上张贴初级的问题,反之亦然;
    1. 在不同的论坛或讨论小组同时张贴同一个问题;
    1. 向非熟人或没有义务解决你问题的人发送私人问题邮件。

为防止论坛被灌水,黑客们(论坛管理员)会删掉那些与论坛及主题无关的问题,你不想自己的问题被删掉吧。

因此,第一步是找到正确的提问论坛。谷歌和其它搜索引擎是你好帮手,当你遇到问题时,它们可以帮你搜索到与问题最相关的网站或者论坛。那里通常都会有「常见问题解答」(FAQ)、讨论组及文档的链接。如果你的努力(包括阅读 FAQ)都没有结果,这些讨论组就是你最后能取得帮助的地方。这些网站通常会有报告bug(错误)的地方或链接,你可以尝试通过这个方式按照指示反馈信息。

冒昧地向陌生人发送邮件或在不熟悉的论坛发表主题是一件比较「冒险」的事情。你不要天真地以为一个经验丰富的网站架构师会给你提供免费解答,也不要以为你的问题会在论坛中引起巨大反响,除非你很确定这一点,否则还是发送去其他地方去吧,或者最好就别发了。

在选择论坛和讨论组时,不要被他们的名字迷惑了,先看看FAQ或者版规以明确你的问题是否切合这个论坛的风格。发帖之前先翻翻已有的帖子,感受一下论坛的讨论氛围。事实上,善用论坛的搜索功能将会给带来极大的便利,或者这样你就更容易找到答案,即使没有,这也可以让你更好地表述出你的问题。

不要像机关枪似的一次性「扫射」所有的帮助通道,这样的行为像泼妇骂街一样令人抓狂,要有重点地一步一步来。

要搞清楚你提问的主题是什么!最典型的错误就是跑去苹果的论坛问关于Unix或Windows的问题,如果你不明白,最好在搞清楚概念,否则什么也别问。

一般来说,在公共论坛中提问比在封闭论坛中提问更容易得到有用的回答。选择依据:一是评估潜在的回复数较多,二是估算论坛的活跃度较高,相比之下,黑客更喜欢回答那些能启发多数人的问题。

同时,你可以理解,一些经验丰富的黑客和流行软件的作者正在承受过多的非议,因为涌入其私人邮箱的垃圾邮件变得越来越多,他们实在无法忍受,同时,你的加入有可能使情况更加恶劣,就像那根最后压垮骆驼背的稻草一样,所以,一些流行软件的作者正陆续停止对软件的更新和支持。

通过新手论坛和在线客服可获得最快的回复

本地发行商会为宣传新产品会专门为新手设置论坛或在线客服(IRC)[8],这些地方是提问的好地方,特别是当你觉得遇到的是很普通的问题时。通过专门的在线客服或者公开新手提问专区,一般可以得到实时的回复。

事实上,如果出问题的程序来自某发行版(这很常见),最好先去该发行版的论坛中提问,再到程序本身的项目论坛中提问,否则该项目的黑客可能仅仅回复「尝试用我们的代码」来搪塞你。

在任何论坛发帖之前,先看看有没有搜索功能。如果有,就试着用问题的几个关键词搜索一下,这会给你带来帮助。如果在此之前你已做过全面的网页搜索(你应该这样去做),还是应该再搜索一下论坛,搜索引擎有可能还没建立此论坛的内容索引[9]。

目前,通过论坛或在线客服为用户提供帮助已经成为一种趋势,电子邮件交流方式则更多地为项目开发者保留。所以,新手一般建议在通过论坛或在线客服寻求与该项目相关的帮助。

【本章注释】

[8]「IRC」全程为Internet Relay Chat,即时聊天工具,在国内常见的是挂在网页内的QQ客服。

[9]也有部分论坛会屏蔽来自搜索引擎的爬虫,所以有时候还得在论坛中搜索。

使用项目组的论坛

当某个项目组设立有开发者论坛[10]时,要向论坛而不是其中的个人成员提问,即使你确信他能为你提供最好的回答。查看一下项目的说明文件和主页,找到论坛地址并注册使用。采用这种办法有几个很好的理由:

    1. 如果向个人开发者提的问题足够好,他的回答也将对整个项目组有益。相反,如果你认为自己的问题对整个项目组来说太白痴,这也不能成为骚扰个人开发者的理由。
    1. 向论坛提问可以分散开发者们的负担,个人开发者(尤其是项目领导)也可能太忙,以至于没法回答你的问题。
    1. 大多数论坛记录都会存档,那些存档将会被搜索引擎索引,如果你向论坛递交的提问得到解答,将来其他人可以通过网页搜索找到你的问题和答案,那么他们就不用再次提问了。
    1. 如果某些问题经常被问到,开发者可以利用此信息改进说明文件或软件本身,以使其更清晰明白。如果只是私下提问,就没有人能知道最常见问题是什么,也无法建立一个常见问题解答手册。

如果一个项目论坛中既有「用户」 也有「开发者」(或 「黑客」,而你又不钻研那些高深代码,那就向「用户」组论坛提问。不要以为自己会在「开发者」论坛中会受到欢迎,那些人只会认为你是一个在装逼的傻逼。

然而,如果你确信你的问题十分特殊,在「用户」组论坛中提问了好几天都没有回复,可以尝试在「开发者」论坛提问。建议你在发帖前最好先潜水一阵以了解那的行事风格(事实上这是参与任何私有或半私有论坛的好主意)。

如果你找不到一个项目组的论坛,只能查到项目维护者的邮箱地址,可以向其发送邮件。但即便在这种情况下,也不要以为这个论坛是不存在的。在电子邮件中你可以陈述你试图寻找这个论坛的事实,告诉维护者也可以转发该邮件到相关的人员手中(许多人认为,即使没什么秘密,私人电子邮件也不应该被公开。通过允许将你的电子邮件转发他人,你给了相应人员处置你邮件的选择)。

【本章注释】

[10]原文为邮件列表,邮件列表是论坛的初始形态,以前的论坛是以邮件名称作为联系ID交流,所以,在此篇文章中,邮件列表可视作论坛。

使用含义丰富,描述准确的标题

请在论坛中用五十个或更少的字来描述你的主题,这是你吸引专家专家注意力的黄金法则,

精练的标题是你吸引专家注意的黄金机会,别喋喋不休地用诸如「帮帮我」的标题,这种主题只会被条件反射式地删掉,浪费掉一次提问的机会。不要试图用你深深的痛苦来打动我们,相反,要在讨论空间中使用简明扼要语句来描述问题。

撰写主题的规则是「对象──偏差」式的描述,许多技术支持组织就是这样做的。「对象」部分需要指明是哪一个或哪一组项目有问题,「偏差」部分则描述与期望的行为不一致的地方。

愚蠢的问题描述:救命啊!我的笔记本播放不了视频!

明智的问题描述:X.org 6.8.1 鼠标光标出现偏差,MV1005型号的某显卡芯片组

更明智的问题描述:使用 MV1005 型号的某显卡芯片组在 X.org 6.8.1 的鼠标光标出现偏差

撰写「对象──偏差」式的主题描述有助于引发你对问题的细致思考:是什么导致了这个问题?仅仅是鼠标光标出问题或者还有其它原因?只在X.org中出现抑或是在6.8.1的版本中?是针对某显卡芯片组还是或者只是其中的 MV1005 型号?一个黑客只需瞄一眼就能够立即知道你遇到的什么问题和解决方案。

为了方便索引查找,你需要正确地用标题来描述你的问题,以便下一个搜索类似主题的人能够迅速定位到你的答案中来,无须再发帖提问。

如果你想在回复中提问,请修改主题名称,以注明你是在问一个问题,例如「Re: 测试」或者「Re: 新bug反馈」这样的信息就不能引起足够的注意,同时,请注意删除与新主题无关的引用内容。

对于论坛消息,请不要直接点击回复(按钮)来开始一个全新的主题索引,这将限制主题的参与者。例如有些论坛允许隐藏消息,如果你这样做的话,别人就永远看不到你发的消息了。

有时候,仅仅改变标题还不够。其他的一些论坛还会检查你论坛主题的其他信息,以便为其提供索引,所以这时候宁可重新发一新帖。

成熟的论坛有一套完善的讨论规则,参与者发送的信息与特定的主题紧密结合,所以通过回复来提问也未尝不可。但并不是所有论坛都允许在回复中出现分支的主题,这样做的结果就是基本上没有人会去看[11],而且通过回复来继续提问是一种成效较低的做法,因为它们只会被正在查看该主题的人看到。所以,除非你只想向当前活跃的人群中提问,否则还是另发新帖比较好。

【本章注释】

[10]论坛中经常会出现灌水或者是版聊的情况,一大群人一个主题下你谈你的我谈我的,原主题容易就会被冲散。

让回答来得更简便一点

用「请将回答发送到……」这样的方式来提问会使你的问题得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都嫌麻烦,我们也懒得花几秒钟去考虑你的问题。如果你的邮件客户端程序不支持设置,请换一个;如果你的操作系统不支持这种邮件客户端程序,也请换一个。

实际上,在论坛中,要求回答者通过电子邮件回复你的提问是粗暴无礼的,除非你确定他回复的比较敏感或涉及隐私的(现在的论坛也可以设置「私人可见」的回复)。如果你只是想在有人回复主题时得到电子邮件提醒,可以要求论坛发送。几乎所有论坛都支持诸如「留意本主题」、「有回复发送邮件」等功能[12]。

【本章注释】

[12]实际上,目前中国的论坛已很少使用邮件通知回复,只有少数索取资料的主题要求留些邮箱发送而已,大部分的论坛已采用消息提醒的方式来显示回复。

用字义清晰、语法标准、拼写正确的语句撰写问题

经验告诉我们,粗心草率的人通常也会粗心草率地思考与编程。回答这些粗心草率者的提问没有什么好处,我们宁可将时间花在其他地方。

清楚、正确地表达你的问题非常重要。如果你嫌斟字酌句麻烦,那我们也懒得回复。所以,请稍微花一点点时间组织语言,也用不着太正式和死板──事实上,黑客文化提倡使用非正式词句、网络语言和幽默的语句,同时注意在遣词造句的过程中体现文字的准确性和你思考问题的积极性。

正确地拼写、使用标点和大小写,不要将「its」混淆为「it's」,「loose」搞成「lose」或者将「discrete」弄成 「discreet」。不要全部用大写,这会被视为粗鲁无礼的大声嚷嚷 (全部小写也好不到哪去,因为不易阅读。Alan Cox[13]也许可以这样做,但你不行。)

一般来说,如果你像个半文盲般来提问,你多半会被无视。也不要使用短信中的简写,如将「you」简化为「u」,这会让你看起来像偷懒的傻逼。更有甚者像个小孩似地用火星文来提问,那就绝对是在找死,真的是喊破喉咙也没有人来理你(或者会有人在围观,并给你一大堆指责与挖苦)。

如果你在非母语(中文)的论坛提问,你可以犯点拼写和语法上的小错,但决不能在思考上懒惰(没错,我们能看得出其中的差别)。同时,除非你知道回复者们使用的语言,否则请使用英语书写。如果你用黑客看不懂的语言发送提问,繁忙的黑客一般会直接无视并立即除。英语是互联网上的通用语言,用英语书写可以避免你的问题被直接无视。

如果你要用英文作为第二语言来提问,你可以使用以下的语句来进行说明,降低回答者对你语言使用的不适感:

    1. English is not my native language; please excuse typing errors.
    1. If you speak $LANGUAGE, please email/PM me; I may need assistance translating my question.
    1. I am familiar with the technical terms, but some slang expressions and idioms are difficult for me.
    1. I've posted my question in $LANGUAGE and English. I'll be glad to translate responses, if you only use one or the other.

【本章注释】

[13]Alan Cox:著名黑客,Linux 内核的重要参与者

使用易于读取且标准的文件格式发送问题

本章阅读提示[14]。

如果你将问题搞得复制难以阅读,它多半会被忽略,人们更愿读易懂的问题,所以:

    1. 使用纯文本而不是HTML格式;
    1. 发送邮件时如有附件,记得添加附件,同时记得检查附件内容是否能正常打开;
    1. 不要发送整段的文字,尝试将文字按主题分段;
    1. 发送数据时应该发送原始数据,让回复者看到的东西与你看到的一样;
    1. 很多邮件程序并不支持「Quoted-Printable」MIME编码,所以谨慎使用;
    1. 不要指望黑客们阅读封闭格式的文档,诸如微软公司的Word或Excel文件等。大多数黑客讨厌这种文件格式。即使他们能够处理,也很厌恶这么做;
    1. 如果你用Windows操作系统发送电子邮件,关闭微软的「引用」功能,以免在你的邮件中出现乱码;
    1. 切勿在在论坛勿滥用「表情符号」和「HTML」功能。使用一两个表情符号还可以,但使用过多的花哨彩色文本会使人认为你无法表达出你的意思。过滥地使用表情符号、色彩和字体会让看起来更傻逼;

如果你是使用图形界面的邮件客户端程序(如腾讯的Foxmail、微软公司的Outlook),注意它们的默认配置不一定满足以上的这些要求。不过大多数这类程序有「查看源码」的命令,可以用它来检查发件箱的消息,确保发送的是没有乱码的纯文本文件。

【本章注释】

[14]在本章中作者使用大量的计算机术语,我已尽量简化处理,同时,我认为以上的方法并不适合大多数的提问者,所以我在此总结一下适合普通用户的文件格式:

    1. Txt:直接粘贴,方便阅读;
    1. Pdf:文件规范,推荐使用;
    1. Doc:使用广泛,打开方便;
    1. Md:Markdown文本,未来趋势。

邮件送发建议使用网页端,邮件客户端推荐使用Outlook2013或Foxmail 7。

准确简练地描述问题

问题的描述应该包含以下内容:

    1. 清晰的细节;
    1. 问题发生的环境(主机品牌、操作系统、应用程序,任何相关的),提供销售商的发行版和版本号(如:「Fedora Core 7」、「Slackware 9.1」等);
    1. 提问前做过的调查研究及对其的理解;
    1. 提问前为确定问题而采取的诊断步骤;
    1. 最近对计算机或软件配置的任何相关改变;
    1. 如果可能,提供在可控环境下重现问题的方法;

做大的努力预测黑客会提到的问题,并提前备好答案。

如果你认为是代码有问题,在可控环境下重现问题,并向黑客提供报告,这个的方法尤其重要。当你这么做时,你大有可能获得及时而有效的回复。

西蒙.泰瑟姆(Simon Tatham)曾写过一篇《如何有效报告bug》的文章,我强烈推荐各位阅读。

话不在多,精炼最好

你应该精炼且简要地描述问题,简单地将堆砌代码或罗列数据是没有用的。如果你有一个体积庞大且复杂的测试样本,尝试将其裁剪,越小越好。

至少有三个理由支持以上这点。第一,让别人看到你在努力简化问题的过程,这会使你更有可能得到回复。第二,简化的问题更容易得到回复。第三,在简化的过程中,你有可能自己就找到了解决办法。

别急于宣称找到bug

当你在一个软件中遇到问题时,除非你非常、非常的有根据,否则不要动辄声称找到了bug。提示:除非你能提供解决问题的源代码补丁,或者在前一版本的回归测试收集了足够的证据,否则你都不能够完全确信。对于网页和文档也如此,如果你声称发现了文档的「bug」,你应该提供可以替代的解决方案。

记住,还有许多用户并未经历你遇到的问题,否则你在阅读文档或搜索网页时早应该发现了(疑问:你在报怨前已经搜索过了,是吧?)。这也意味着很有可能是你弄错了,而不是软件本身有问题。

编写软件的人总会非常努力地优化修正这个软件。所以,如果你声称找到了bug,这是对他们能力的质疑,即使你是对的,也有可能会使某些人人感到不爽。此外,在标题中寻找「bug」也是相当不厚道的行为。

即使你私下已经非常确信发现一个真正的bug,你在提交问题时最好也写得像是你做错了什么。这样,如果是真有bug,你会在回复中获知,同时,维护者会向你道歉,这总比你无心破坏而欠下一个道歉要好。

跪求也不能解决问题

有些人明白不应该采用粗鲁或傲慢的方式提问并要求得到答复,所以他们走了另一个极端,转而低声下气地哀求:「我知道我只是个可怜的菜鸟,一个loser,但……」。这种对实际问题含糊的描述特别令人反感,不但困扰,也没有用。

别用低级灵长类动物的老办法浪费时间,相反,尽可能清楚地描述背景情况和你的问题,这比摆出卑贱态度更有用,同时这也是对自己的重新定位。

有的论坛专门设置了新手提问区,如果你真的认为遇到了新手该遇到的问题,直接到那去提问就好,别再跪求了。

描述症状,不做猜测

向黑客陈述你的猜测是没有用的(如果你的诊断理论真的那么有用,你还会向别人求助吗?)。所以,你只需要告诉他们问题的原始状态,而不是你的解释和理论,让他们来解释和诊断。如果你真的认为自己的猜测很重要,那么你就应该清楚地说明这只是你的猜测,并解释为什么不起作用。

愚蠢的提问:我在编译内核时接连遇到SIG11错误,怀疑主板上的某根电路丝断了,找到它们的最好办法是什么?

明智的提问:我组装的电脑(K6/233 CPU、FIC-PA2007 主板[威盛 Apollo VP2 芯片组]、Corsair PC133 SDRAM 256Mb 内存)最近在开机20分钟左右、做内核编译时频繁地报错,提示SIG11 ,但在头20分钟内从不出问题。重启动不会复位时钟,但会整夜关机。更换所有内存未解决问题,相关的典型编译会话日志附后。

鉴于不是每个人都不能做到明智的提问,所以这里有一句话可以给到你启示:「所有的诊断专家都来自密苏里州」。美国国务院的官方座右铭则是「让我看看」(Show me)[15],对回复者而言,这并不是质疑,而只是一种真实而有用的需求,以便让他们看到与你看到一样的原始证据,目睹尽可能一致的东西,而不是你的片面的猜测与总结。(所以)让我们看看(Show me)。

【本章注释】

[15]「让我看看」出自国会议员威勒德.D.范迪弗[Willard D. Vandiver]在1899年时的讲话:「我来自一个出产玉米、棉花、牛蒡和民主党人的国家,滔滔雄辩既不能说服我,也不会让我满意。我来自密苏里州,你必须让我看看。」大意是我不相信别人的描述,我只相信我眼前的事实。

按时间顺序描述问题症状

解决问题最有效的线索就是问题之前发生的情况。所以,在问题描述汇中应准确地记录你、电脑和软件在崩溃前的情况。在命令行处理的情况下,对话日志(如运行脚本工具生成的)的记录会非常有帮助。

如果崩溃的程序有诊断选项,试着选择能在能生成排错日志的选项。记住,「多」不等于「好」。试着选取适当的排错级别,以便提供有用的信息。

如果你的问题记录很长(如超过四段),在开头简述问题,随后按时间先后描述详细过程也许更有用。这样黑客在阅读你的记录时就知道该注意哪些内容了。

描述目标而不是过程

如果你想知道如何做某事(而不是报告一个bug),你需要在开头就表明你的目标,然后再陈述你遇到问题。

经常出现这种一种情况:寻求技术帮助的人在脑中里有个更高层次的目标,他们自以为按自己的路走能达成目的,但在中途却被卡住了,又跑来问该怎么走,他们从来没有意识到这条路本身有问题,所以他们往往更折腾才能达成目的

愚蠢的提问:我怎样才能让某图形程序的颜色拾取器取得十六进制的RGB值?

明智的提问:我正试着用自己选定数值的颜色替换一幅图片的色表,我现在知道的唯一方法是编辑每个表槽,但却无法让某图形程序的颜色拾取器取得十六进制的RGB值。

第二种提法是明智的,它会获得更合适的回答:建议采用更合适的工具来完成任务。

不要请求私下回复

黑客们认为问题的解决过程应该公开、透明,这样就会有更多的人参与到此问题的解决,如果有知识渊博,经验更丰富的人发现了这个问题,他们就会留意到回答中不完整或不准确的地方,那么原来的回答就会被纠正修复。同时,这些人的能力和学识也会被其他同行看到而得到赏识。

而当你要求私下回复时,以上的纠正过程就会被中止,所以,不要请求私下回复,要让回复者来决定是否私下回复。实际上,如果他真的私下回复你了,通常是因为他认为问题太差或者太肤浅,自己给出的答案对其它人也毫无意义,那就发给你吧。

这条规则也有一个例外,如果你确定该提问可能会带来大量雷同的回复时,那么你可以主动表示:「请向我发电子邮件,我将为论坛统一归纳这些回复」。你这个举动是非常值得赞扬的,因为你将论坛从洪水般雷同的回复中解救出来。最后,最重要的一点,你必须言出必行。

精准地提问

漫无边际的问题通常被视为时间黑洞,回答这些问题需要付出更多的时间和精力,只有最忙的人才会给你最有用答案,但这些人对于时间黑洞极其敏感,所以他们比较讨厌那些漫无边际的问题。

如果你明确指认了让回复者做的事(如指点方向、发送代码、检查补丁或其它),你更有可能得到有用的回复。(因为)这样可以让他们集中精力去解决问题,并间接地设定了他们为帮助你需要花费的时间和精力上限,这是很好的做法。

如果你想要向专家提问,你可以这样设想:你去到一个金库,可是你只有一点点的时间。专家就像金库,如果你想在尽可能短的时间来换取更多的价值,你就要向他们提出一个精准的问题。

所以,为了让专家能够用尽量少的时间来回答你的问题,你最好限定问题的范围。限定问题范围与简化问题是不一样的。举个例,「请问可否指点一下哪有好一点关于X的解释?」通常就要比「请解释一下X」来得明智。再譬如,如果你的代码运行不了,「请别人看看哪有问题」就比「叫他们帮你改正」更加明智。

如何提问关于代码的问题

不要直接要求别人给你修正代码,而应该提问如何入手解决这个问题,如果你一上来就一段几百行的代码,说你这里有bug提示出错,你能帮我找出来吗?这样的请求只会被直接无视,而如果你精简代码,明确地描述问题:在第七行以后,本应该显示,但实际出现的是,如何处理?这样就大大提高问题被回答的几率。

最精确描述代码问题的方法是提供一个能展现问题的最小测试样本。什么是最小测试样本?它是可以集中展现问题,只需要能够刚好重现问题的代码即可。如何生成一个最小测试样本?如果你知道哪一行或哪一段代码会产生问题,将其复制并提供刚好够用的外围支撑代码以构成一个完整的样本(够用是指源码刚好能被编译器、解释器或任何处理它的程序所接受)。如果你不能将问题缩小到特定的段落,复制源代码并去除那些与问题无关的代码段。你能提供的最小测试样例本越小越好(参见《浓缩精华》这一章节 )。

用最小测试样本去测试bug也并不是万能的,但这毕竟是一个很好的尝试,这有助于帮助你独立去解决问题,即使你找不到,黑客们也喜欢看到曾经你努力过,这将使他们跟你合作去解决这个问题。

如果你只是想让别人帮忙审核一下代码,在最开头就要说出来,并且一定要提到你认为哪一部分特别需要关注以及为什么。

不要提问「家庭作业式」的问题

黑客们擅长发现「家庭作业式」[16]的问题。家庭作业要求独立完成,因为这是你该做的,这样你才能从中学到东西,遇到困惑的时候可以要去给一点提示,但是千万不要要求给出完整的答案。

如果你怀疑自己碰到了一个「家庭作业式」的问题,自己尝试过但仍然无法解决,可以试试在用户组、论坛或(作为最后一招)中提问。在那里,黑客们会留意到你的问题,一些老用户也许会给你提示。

【本章注释】

[16]「家庭作业式」的问题:在学习者眼中的复杂问题,在专家眼中的简单问题,基础式问题。

删除无意义的疑问

有的人喜欢在求助信息的末尾加上「有人能帮我吗?」或者「有没有答案?」这一类无意义的提问,应该在提问中尽量删除这些废话,理由如下:第一,如果问题本身描述的不完整,这些附加的东西就是废话。第二,因为它们提问的方式不对,黑客们会认为这些东西很烦,很有可能就会用逻辑上无误回复来敷衍你,诸如「是的,你可以得到帮助」和「不好意思,没有人能帮你」。

一般来说,避免提「是或非」问题,除非你想得到「是或非」回答。

不要把问题标记为「紧急」,即使你真的很紧急

「紧急」只是你的「紧急」,跟我们无关。同时,这些动辄「紧急」的提问往往欲速而不达,而且多数会被黑客们删掉,因为他们认为这是一种自私与鲁莽的提问方式:企图通过文字的简单修饰来引起别人注意而获得特殊的关照。

当然也有例外,如果你在知名度很高使用某些程序出现问题,你的提问很有可能让黑客们兴奋,在这种情况下,如果你有时间压力,并且很有礼貌地提出请求,黑客们会有兴趣尽快地回复你。

不过需要注意的一点是:这样提问是非常冒险的,因为黑客兴奋的标准和你的不同。譬如发个主题关于「国际空间站」帖子就可以得到关注,但是如果转发关于慈善或政治的帖子就几乎没人理你。再如「紧急:帮我救救这个毛绒绒的小海豹!」这样帖子在专业技术论坛让黑客看到了肯定会相当抓狂,即使他们认为拯救毛绒绒的小海豹很重要。

如果你觉得以上的解释难以理解,把剩下的内容多读几遍,直到弄懂了再发帖也不迟。

谦逊没害,而且有益

礼貌一点,使用「请」和「谢谢你的关注」或者「谢谢你的帮助」,让别人明白你的真诚,让他们觉得这样无偿的帮助你是值得的。

坦白讲,对黑客而言,在提问中使用正确的语法、清晰的文字、准确的内容,标准的格式远比使用礼节重要。黑客们一般宁可看文字锋利直白但技术鲜明的bug报告,也不要看那种彬彬有礼有礼但内容空洞含糊其辞的报告。(如果你不明黑客们为什么喜欢这样,那么你就要明白:黑客评价一个提问价值的标准在于这个问题能给他带来什么样的成长。)

然而,如果你已经清楚地描述了一个问题,客气礼貌一点肯定会增加你得到回复的机会。

(本文曾受到一些老黑客的指责,这也是本文的唯一受指责的地方,所以我们必须指出,我们曾经推荐使用「提前谢了」的感谢方式,这种感谢方式在一些黑客看来有一种事后不用再感谢任何人暗示和过河拆桥的味道,所以,我们现在的建议是:一、先说「提前谢了」,事后再表示对回复者的感谢;二、换一种表达方式,譬如用「谢谢你的关注」或「谢谢你的帮助」等。)

问题解决后,追加简短说明

在问题解决后向所有帮助过的人回复一条信息,让他们知道问题是如何解决的并再次感谢。如果问题在论坛中受到广泛关注,在那里追加此信息比较恰当。

最理想的方式是向最初提问的主题中回复此消息,并在主题中注明「已解决」、「已搞定」或其它同等含义的字样[17]。这样,在信息快速流动的论坛中,一个注明「已解决」或「已搞定」的主题就会让别人节省很多时间,回复者不用再点进去重复回复(除非他觉得这个问题值得再商榷),因此他就可以用这些时间去解决其他问题。

追加的信息无须太冗厂繁复,一句简单的「你好,问题已解决,是网线坏了!谢谢大家──比尔」就比什么都没有要好。事实上,除非解决问题的过程很复杂,需要用得很高深的技术,否则就用一条简短亲切的总结来回复就好了,总结中说明用了什么方法,解决了什么问题,无需将整个解决问题的过程给写下来。

对于有深度的问题,建议给出一份完整解决该问题的方案,方案包括:问题的最终状态、用了什么方法、列出具体的步骤和和易出错的地方,这样才可以给到后来者一个完整的指引,注意不要将此方案搞成什么侦探推理小说。最后列出那些帮助过你的人的名字,那样你有可能会交到朋友。

这种后续的跟进信息不仅是礼貌的回复,而且是内容的分享,因为这些后续的解决方案会帮助其他有同样问题的人,他们会在论坛中找到你的解决方案,并因此受益。

最后,此类后续的信息跟进还让每位参与协助的人因问题的解决而产生一种满足感。如果你自己不是技术专家或黑客,相信我们,这种感觉对于你寻求帮助的老手和专家是非常重要的。问题的不了了之总会令人沮丧,但黑客们有强迫症,总渴望它们被解决,你的后续跟进就像是为他们消灭了一个眼中钉,并因此获得了一定的信誉的威望,这对你的下次提问非常有帮助。

考虑到将来也会有人面临类似的问题,如何避免重蹈覆辙呢?你可以自己写一篇文章或者对FAQ进行补充,然后发给项目的维护者。

在黑客交流的过程中,这种良好的后续跟踪行为比传统的礼貌更重要,这也是你善待他人赢得声誉的方式,这是非常有价值的经验和财富。

【本章注释】

[17]在国内论坛,问题解决之后,可以主动修改论坛主题,添加上「已解决」字样,然后通知版主做出处理。

如何解读回答

RTFM[18]和STFW[19]:你为什么不去试一试?

有一个古老而神圣的惯例:如果你收到RTFM的回复,你就应该去「Read The Fucking Manual」,他说得对,去读一下吧。

「Read The Fucking Manual」(RTFM)有个年轻点的亲戚,如果你收到「Search The Fucking Web」(STFW)的回复,你也应该去「Search The Fucking Web」,他说得也对,去搜一下吧。(更温和一点的说法是「善用Google」)

在论坛,你也可能被要求去搜索论坛的存档记录。事实上,有人甚至可能热心到为你提供以前解决此问题的线索。但千万不要依赖这种帮助,你应该在提问前搜索一下存档。

通常的情况是,要求你主动去搜索的人已经打开了能解决你问题的手册或网页,他那时可能是一边在看屏幕一边敲着键盘回复「RTFM」或「STFW」,这些回复意味着:第一,你要的信息很容易找到。第二,自己动手,丰衣足食。

这不是一种是鄙视,按黑客的标准,回复者没有不理你,反而在耐心地回复你,这是对你提问的尊敬,你应该感谢他还像一个老奶奶一样唠唠叨叨地回复你。

【本章注释】

[18]RTFM,是一个英文缩写,意思是:「去读那些他妈的手册」(Read The Fucking Manual),这句话通常用在回复那些只要查阅文件就可以解决,拿出来提问只是浪费别人时间的问题.

[19]STFW:Search The Fucking Web,去搜那些他妈的网站,语意同RTFM。

如果还不明白……

如果你看不懂回答,不要马上发帖要求别人进行解释说明,你应该回过头去看看你提问时候试用过的工具(如手册、FAQ、网页、行业内朋友等),如果检查过后,你发现还是需要解释说明,你就要将已学的东西展现出来。

譬如,我告诉你:「看起来像是输入项有问题,你需要清除它」,接着是个不好的回帖示范:「什么是输入项?」(因为你没有主动在搜索引擎中搜查什么是输入项)。而以下就是一个很好的跟帖:「是的,我读了手册,某某输入项只在 -z 和 -p 开关中被提到,但都没有涉及到如何清除它们,你指的是哪一个还是我弄错了什么?」

对待无礼

很多黑客圈子中看似无礼的行为并不是存心冒犯。相反,它是直接了当、一针见血式的交流风格,这种风格对于更关注解决问题而不是使别人感觉舒服。

如果你觉得被冒犯了,试着平静地对待。如果有人真的做了过分的事,论坛中的老前辈会教训他。如果这些没有发生而你却恼火了,那么这些致使你恼火的言语可能在黑客社区中看来是正常的,而你将被视为有错的一方,这会让你丧失进一步获得信息或帮助的机会。

另一方面,如果你真的偶然地遇到了无礼和无聊的冲撞,你就要对真正的冒犯者予以狠狠的反击了,用犀利的语言将其驳得体无完肤都是可以接受的,然而,在行事之前一定要有非常肯定的证据。因为纠正无礼的言论与一场毫无意义的口水战仅一线之隔,黑客们自己莽撞地越线的情况也屡见不鲜。新手可能难免中枪。但如果你想得到的是信息和帮助,就不要浪费时间参与到口水战之中。

(有些人断言很多黑客都有轻度的自闭症或阿斯伯格综合症[20],缺少用于润滑人类社会「正常」社交所需的人脑回路。这既可能是真也可能是假。如果你不是黑客,也许你会认为我们脑袋有问题,以为还能帮助我们纠正那些古怪行为。如果你真的以为这么做会有效,你就只管这么做好了,我们不在乎。我们就喜欢现在这个样子,因我们会对那些所谓的「诊断」拥有正常的科学的健康的怀疑精神。

在下一节,我们会谈到另一个主题,当你犯错遭受到的指责该怎么办。

【本章注释】

20、阿斯伯格综合症,是一种泛自闭症障碍,其重要特征是社交困难,伴随着兴趣狭隘及重复特定行为,但相较于其他泛自闭症障碍,仍相对保有语言及认知发展。

不要像loser那样去行事

常在河边走,哪有不湿鞋。在黑客论坛混,总有有犯错的时候,你的错误会被别人长篇大论的公开地揭露,或许在言语之中还会透露着鄙视和得意。

事后你能做的最坏的事莫过于哀怨你的遭遇、四处哭喊着被人诽谤、要求道歉、竭斯底里的呼喊、忍隐不做声、威胁诉诸法律、向他公司投诉、忘了关马桶盖等等,但实际上,以下的的几件事才是你应该去做的:

就让它这样过去,这是一件很正常的事情。事实上,这样的被人指出错误也没什么大不了,对自己反而是好事。

论坛社区的规则不会自行运转,它们是只能通过参与者通过积极公开的方式来执行维持。不要哭诉着要求将所有的批评和指责通过私下的邮件传达,这不是行之有效的运作方式,当有人在评论你的一个说法有误或者提出不同看法时,你坚持声称受到人身攻击,这也是没用的,这也是loser对待事情的态度。

也有一些黑客论坛愚蠢地执行过「高礼节要求」的规则,禁止参与者公开发表任何对别人观点挑错的文章,并发出「如果你不想帮助用户就闭嘴」的言论,结果造成大批有思想的参与者逃离此论坛,这个论坛就变成了一个毫无意义,絮絮叨叨,没有价值的技术论坛。

是要夸张的不切实际的「友好」还是坦诚直白的「实用」?你自己挑一个吧。

记着:当黑客说你犯错了,并且(无论说得多么尖锐地)告诉你别再这样做时,这表明他在为关心你和这个社区。对他而言,无视并拉黑要容易得多,如果你无法做到感谢,至少要有点自尊,别大声哀怨,别以一个敏感而莽撞的新手自居,更别指望别人能像对待一个波大无脑的女人一样去抚慰你。

有时候,即使你没有犯错(或者只是别人的臆想),有些人也会以莫须有的名义来指责你。在这种情况下,你的报怨倒是真的会把事情弄得更糟。

这些无事生非的人其实也没有多大的能耐,不是在吹牛逼的专家,就是一天到晚在唱反调的心理预测专家。总有读者有能力分辨,并想办法去对付他们,这些人在玩火自焚,你就不用操心了。

如果你在网络上不得不要面对一场争论,你得首先去确认一下自己是否犯错,如果你没有犯错,那么你就可以断定这是一场无聊的口水战,不要将自己卷入口水战之中,也最好不要理睬其他与你无关的口水战,因为这样争论不会有一个明确的结果。

三思而后问

下面是些典型的愚蠢问题和黑客不回答它们的原因和想法。

  • 问:1、我到哪可以找到某程序或X资源?
  • 问:2、我怎样用X做Y?
  • 问:3、如何配置我的shell提示?
  • 问:4、我可以用Bass-o-matic文件转换工具将AcmeCorp文档转为TeX格式吗?
  • 问:5、我的{程序、配置、SQL 语句}不运行了。
  • 问:6、我的Windows系统出问题了,你能帮个忙吗?
  • 问:7、我的程序运行不了,我认为是系统工具X有问题。
  • 问:8、我在安装Linux或X是遇到困难,你能帮个忙吗?
  • 问:9、我如何才能破解超级用户口令/盗取操作员的特权/查看某人的电子邮件?

问:1、我到哪可以找到某程序或X资源?

答: 在我找到的地方啊,笨蛋!──你就不会在网页找么,真抓狂,难道还有人不知道如何使用Google吗?

问:2、我怎样用X做Y?

答:如果你想得出Y的结果,那么请不要在想得出Y的结果前提供X的方法,这样的问题表明提问者不但对X完全无知,也对Y了解不深,这个问题还表明提问者已经被某种思维定势禁锢住了,最好让他们将问题整理好再来提问。

问:3、如何配置我的shell提示?

答:如果你有足够的智慧提这个问题,你也该有足够的智慧去「Read The Fucking Manual」(RTFM),然后自己去找出来。

问:4、我可以用Bass-o-matic文件转换工具将AcmeCorp文档转为TeX格式吗?

答: 试试就知道了。如果你试过,你既知道答案,又不用浪费我的时间。

问:5、我的{程序、配置、SQL 语句}不运行了。

答: 这不是一个问题,我也没有兴趣去猜你有什么问题──我有更要紧的事要做。看到这种东西,我的反应一般如下:

  • 你还有什么补充吗?
  • oh,太可惜了,希望你能搞定。
  • 这跟我有什么关系?

问:6、我的Window系统出问题了,你能帮个忙吗?

答:可以,将Windows系统给卸了,装个开源操作系统,例如Linux或BSD[21]。

注意:你可以问与Windows系统相关的问题,前提是这个程序有Windows的官方版,不是我对Windows系统有偏见,而是Windows系统与大部分的软件存在兼容问题,而实际上Windows系统实在很差。

问:7、我的程序运行不了,我认为是系统工具X有问题。

答:这个程序被成千上万用户反复使用,你有可能是第一个提出这个程序有缺陷的人,不过你得要拿出具体的证明,最后有一份详细清晰的缺陷说明。

问:8、我在安装Linux或X是遇到困难,你能帮个忙吗?

答:不好意思,我帮不了你,我需要亲手操作你的电脑才能帮你排错,去向当地的Linux论坛寻求帮助吧。

注意:如果安装问题与某Linux发行版有关,请首先在论坛中提问。同时,应准确描述问题的细节。在此之前,先用 「linux」和所有被怀疑出问题的硬件 [作关键词] 仔细搜索。

问:9、我如何才能破解超级用户口令/盗取操作员的特权/查看某人的电子邮件?

答:想做这种事情说明你是个人品恶劣的家伙,想让黑客教你做这种事情说明你是个傻逼。

【本章注释】

21、这个回答可以视为一句吐槽,也可以视为一个建议,毕竟大多数黑客都是使用开源系统的。

好问题与坏问题

最后,我将通过举例来演示提问的智慧。同样的问题两种提法,一种愚蠢,另一种明智。

愚蠢:我在哪能找到关于Foonly Flurbamatic设备的东西?

这个问题在请求一个「Search The Fucking Web」(STFW) 式的回复。

明智:我用谷歌搜索过「Foonly Flurbamatic 2600」,但没有找到什么有用的信息,有谁知道在哪能找到这种设备的编程信息吗?

这个人已经搜索过网络了,而且听起来他可能真的遇到了问题。

愚蠢:我不能编译某项目的源代码,它为什么这么烂?

提问者预提了一个假设:是别人搞砸了,太狂妄自大了。

明智:某项目的源代码不能在某Linux 6.2版下编译。我读了常见问题文档,但其中没有与某Linux相关的内容。这是编译时的记录,我做错了什么吗?

提问者已经指明了运行环境,读了常见问题文档(FAQ),列出了错误,也没有假设问题是别人的过错,值得留意一下。

愚蠢:我的主板有问题,谁能帮我?

某黑客管理员对此的反应可能是:「是的,还需要帮你拍背和换尿布吗?」,然后是敲下删除键。

明智:我在S2464主板上试过X、Y和Z方法,当它们都失败后,又试了A、B和C方法。注意我试C时的奇怪症状,显然某某东西正在做某某事情,这并不是正常的现象。通常在Athlon MP主板上导致某某事情的原因是什么?有谁知道我还能再尝试什么方法以确定问题?

相反地,这个人的问题看来值得回答。他或她展现了解决问题的能力而不是坐等天上掉馅饼。

在最后那个问题中,注意「给我一个答案」与「请帮我看看我还能再做点什么测试以得到启发」之间细微但重要的差别。

事实上,最后那个问题基本上源于2001年8月Linux内核邮件列表(lkml)上的真实事件,是我(Eric)当时提了那个问题,我发现Tyan S2462主板有神秘的死机现象,邮件列表成员给我提供了解决此问题的关键信息。

通过这种提问方式,我给了别人可以深思玩味的东西。我设法使之对参与者既轻松又有吸引力,也表明了对同行能力的尊敬并邀请他们与我一起协商。通过告诉他们我已经走过的弯路,我还表明了对他们宝贵时间的尊重。

事后,当我感谢大家并评论这次良好的经历时,一个Linux内核邮件列表的成员谈到,他认为我得到答案并不是因为我的名字挂在列表上,而只是因为我正确的提问方式。

黑客们在某种层面上貌似是非常冷漠无情的精英分子。我想在这事上他是对的,如果我表现得像个不劳而获的寄生虫,不管我是谁都会被忽略或斥责。他建议将整个事件作为对其它人提问的指导,这直接导致了本文的编写。

如果得不到回答

如果得不到回答,请不要认为我们不想帮你,有时的确是因为被问到的小组成员不知道答案。没有回复不等于不被无视,当然,必须承认从外部很难看出两者的差别。

一般而言,不要在再重复发表这个问题,这会被视为毫无意义的骚扰。耐心一点,知道你问题答案的人可能生活在不同的时区,有可能正在睡觉,也有可能你的问题一开始就没有组织好。

还有其它信息源可以寻求帮助,例如一些面向新手的资源区。

有许多在线与本地的用户组织,虽然他们自己不编写任何软件,但是他们对软件很忠诚热心。这些用户组通常因互助和帮助新手而形成。

还有众多大小商业公司提供签约支持服务(红帽与SpikeSource是两家最出名的,还有许多其它的)。别因为要付点钱才有支持就感到沮丧!毕竟,如果你车子的汽缸垫烧坏了,你还是得花钱找个修理店把它弄好。同理,即使软件没花你一分钱,你总不能指望他的服务支持都是免费的。

象Linux这样流行的软件,每个开发版至少有一万个以上的用户,一个人不可能应付这么多用户的服务要求。即使你必须付费才能得到支持,也比你还得额外花钱买软件要少得多(封闭源代码软件的服务支持与开源软件相比通常还要贵一点,也要差一点)。

如何更好地回答

态度和善一点。问题带来的压力常使人显得无礼或愚蠢,即使你平时不是这样的。

对初犯错者私下回复。对那些无心犯错之人也没有必要当众羞辱,一个真正的新手也许连怎么搜索或者连FAQ在哪都不知道。

如果你对某样事物不确定,一定要说出来! 一个听起来权威的错误回复比没有还要糟,别因为听起来象个专家好玩就给别人乱指路。要谦虚和诚实,给提问者与同行都树个好榜样。

如果你帮不了忙,也不要帮倒忙。不要在具体步骤上开玩笑,有些可怜的新手会把它当成真的指令,那样也许会毁了用户的安装进程。

探索性的疑问可以引出更多的细节。如果你问题问得好,你也可以学到点东西。试试将很差的问题转变成好问题,别忘了我们曾经都是新手。

尽管对那些懒人敷衍一句「Read The Fucking Manual」(RTFM)是正当的,但是指出文档的位置(或者给出一个搜索关键词)会更好

如果你决定回答一个问题,请尽可能详尽地提供一个好答案。当别人正在用错误的工具或方法时,别给出一个权宜之计,应推荐一个更好的工具,重新组织这个问题。

提供一个可操作的回答建议!如果回答者已经详细地研究过问题,并且已经测试过X、 Y, Z, A、B、和C方法,均没有得出一个满意的结果,这表明简单地回复「请尝试X或者Y方法」或提供一个链接是没有用的,你要给出一个可操作的详细的操作步骤。

让你所在的社区或论坛也从学习中获益。当回复一个好问题时,问问自己「如何修改相关文件或FAQ文档以免再次解答同样的问题?」,接着再向社区或论坛维护者发一份补充说明。

如果你的答案是在研究一番后得出的,请展现你的解题技巧而不是直接端出结果,毕竟「授人以鱼,不如授人以渔」。

相关资源

如果需要个人电脑、Unix和互联网如何工作的基础知识,参阅Unix和互联网工作的基本原理。

当你发布软件或补丁,试着按软件发布实践手册操作。

鸣谢

Evelyn Mitchell贡献了一些愚蠢问题例子并启发了我编写「如何更好地回答问题」这一章节
Mikhail Ramendik贡献了一些特别有价值的建议和改进意见。

附:知乎对「如何提问题?」的答案总结

    1. 认真:认真对待你的提问,就像你希望别人认真回答你的问题一样。
    1. 先搜索:确保你提了一个新问题,而不是别人问过的重复问题(解决办法:提问之前先搜索)。
    1. 具体:让你的问题处于具体的环境中,避免大而空洞、需要具体情况来分析、或别人难以读懂的问题。
    1. 解决办法:将问题阐述清楚,尽可能将问题的「补充说明」写清楚。
    1. 书写:正确地使用标点符号和英文大小写,没有错别字。
    1. 添加话题:给问题添加合适的相关话题。
    1. 邀请回答:使用右侧的「站内邀请」,邀请专业的人来回答。
    1. 在问题中避免出现绝对性词汇。很多问题你认为是这样但事实并不如此。eg. 为什么画的画画得再像也一眼能看出来不是照的相?
    1. 避免在问题中加上自己对答案非专业或非正确的猜想。

你可能感兴趣的:(提问,学习方法)