
提问的技巧 作者: houlin 浏览数(237) | 评论数(0) | 2008-04-02内容
译文译文: 捷克语 丹麦语 爱沙尼亚语
法语 德语
希伯来语 匈牙利语
意大利语 日语
波兰语 俄语
西班牙语 瑞典语
土耳其语. 如果你想复制、镜像、翻译或引用本文,请参阅我的
复制须知. 弃权申明许多项目的网站在如何取得帮助的部分链接了本文,这没有关系,也是我们想要的。但如果你是该项目生成此链接的网管,请在链接附近显著位置注明“我们不是此项目的服务部!” 我们已经遭受没有此说明带来的痛苦,不断受到一些白痴的骚扰。他们认为既然我们发表了此文,那么我们就有责任解决世上所有技术问题! 如果你因为需要帮助阅读了本文,然后带着可以直接从作者那取得帮助的印象离开,你就不幸成了那些白痴之一。不要向我们提问,我们不会理睬的。我们在这只是给你说明如何从那些真正懂得你软硬件问题的人那里取得帮助的方法,99%的时间我们不会是那些人。除非你确信此文作者是你遇到问题方面的专家, 请不要打扰,这样大家都更开心一点。 引言在 黑客 的世界,你所提技术问题的回答很大程度上取决于你提问的方式与解决此问题的难度,本文将教你如何提问才更有可能得到满意的答复。 开源程序的使用已经很广,你通常可以从其它更有经验的用户而不是黑客那里得到回答。这是好事,他们一般对新手常有的毛病更容忍一点。然尔,使用我们介 绍的方法象对待黑客那样对待这些有经验的用户,通常能最有效地得到问题的解答。 第一件需要明白的事是黑客喜欢难题和激发思考的好问题。假如不是这样,我们也不会写本文了。如果你能提出一个有趣的问题让我们咀嚼玩味,我们会感激你。 好的 问题是种激励与礼物,帮助我们发展认知,揭示没有注意或想过的问题。在黑客中,“好问题!”是非常真挚的赞许。 除此而外,黑客有遇到简单问题就表现出敌视或傲慢的名声,有时候我们看起来还对新手和愚蠢的家伙有条件反射式的无礼,但并不真正是这样。 我们只是毫无歉意地敌视那些提问前不愿思考、不做自己该做之事的人。这种人就象时间无底洞──他们只知道获取,不愿意付出,他们浪费了时间,这些时间本可用于其它更值得回答的人和更有趣 的问题。我们将这种人叫做“失败者 (loser)” (由于历史原因,我们有时将“loser”拼为“lusers")
我们注意到许多人只想用我们写的软件,他们对学习技术细节没有兴趣。对大多数人而言,计算机只是种工具,是种达到目的的手段。他们要生活并且有更要紧的事要做,我们承认这点,也从不指望每个人都对这些让我们着迷的技术问题感兴趣。不过,我们回答问题的风格是为了适应那些真正对此有兴趣并愿意主动参与问题解决的
人,这一点不会变,也不该变。如果这都变了,我们就会在自己能做得最好的事情上不再那么犀利。 我们(多数)是自愿者,从自己繁忙的生活中抽时间来回答问题,有时会力不从心。因此,我们会无情地滤除问题,特别是那些看起来象是失败者的,以便更有效地把回答问题的时间留给那些“胜利者” 如果你认为这种态度令人憎恶、以施惠者自居或傲慢自大,请检查你的假设,我们并未要求你屈服──事实上,假如你做了该做的努力使之成为可能,我们中的大多数人非常乐意平等地与你交流并欢迎你接纳我们的文化。试图去帮助那些不愿自救的人对我们简直没有效率,不懂没有关系,但愚蠢地行事不行。 所以,你不必在技术上很在行才能吸引我们的注意,但你必须表现出能引导你在行的姿态──机敏、思考、善于观察、乐于主动参与问题的解决。如果你做不到这些使你与众不同的事情,我们建议你付钱跟别人签商业服务合同,而不是要求黑客无偿帮助。 如果你决定向我们求助,你不会想成为一名失败者,你也不想被看成一个失败者。得到快速有效回复的最好方法是使提问者看起来象个聪明、自信的人,并且暗示只是碰巧在某一特别问题上需要帮助。 (欢迎对本文指正,可以将建议发至 esr@thyrsus.com 。 请注意,本文不想成为一般性的 网络礼仪 指南,我一般会拒绝那些与引出技术论坛中有用的回复不特别相关的建议) 提问前在通过电子邮件、新闻组或网页论坛提技术问题之前,做以下事情:
提问时,请先表述你已经做了上述事情,这将有助于建立你不是寄生虫与浪费别人时间的印象。最好再表述你从中学到的东西,我们喜欢回答那些表现出能从答案中学习的人。 使用某些策略,比如用Google搜索你遇到的错误提示(既搜索网页也查查讨论组),可能就直接找到了解决问题的文档或邮件列表线索。即使没有结果,在电子邮件或新闻组张贴问题时提一句“我在Google中查过下列句子但没有找到什么有用的东西”也是件好事。 准备你的问题,彻底地思考。轻率的提问只能得到轻率的回答,或者压根没有。在提问时,越是表现出做过思考并在努力解决问题,你越有可能得到 实际帮助。 注意别提错问题。如果提问基于错误的假设,某黑客多半会一边想”愚蠢的问题……“,一边用按照问题字面的无用答案回复你,并且希望这种只是得到 字 面回答而不是真正所需的经历给你一个教训。 永远不要假设你有资格得到解答。你没有这种资格,毕竟你没有为此服务付费。如果你能够提出有内容、有趣和激励思考的问题──那种毫无疑问能够向社区贡献经验而不仅仅是消极地要求从别人那获取知识的问题,你将“挣到”答案。 另一方面,表明你能够也乐意参与问题的解决是个很好的开端。“有没有人能指个方向?”、“我这还漏点什么?”、“我应该查哪些网站?”通常要比 “请给出我可以用的完整步骤”更容易得到回复,因为你表明了只要有人能指个方向你就很乐意完成剩下的过程。 提问时仔细挑选论坛要对在哪提问留心,如果你做了下 述事情,多半会被一笔勾销或被看成“失败者”:
为保护通信的渠道不被无 关的东西淹没,黑客会除掉那些没有找对地方的问题,你不会想有这种经历的。 所以第一步是找对论坛,Google与其它搜索引擎还是你的朋友,可以用它们搜索与你遇到困难的软硬件问题最相关的项目的网站。那里通常都有项目的FAQ列表、邮件列表及其文档的链接。如果你的努力(包括阅读FAQ)都没有结果,这些邮件列表就是最后能取得帮助的地方。项目的网站也许还有报告臭虫的流程或链接,如果是这样,去看看。 向陌生的人或论坛发送邮件极有可能是在冒险。譬如,不要假设一个富含信息的网页的编写者想充当你的免费顾问,不要对你的问题是否会受到欢迎做乐 观的 估计──如果你 不确定,向别处发或者根本别发。 在选择网页论坛、新闻组或邮件列表时,不要太相信名字,先看看FAQ或者许可书以明确你的问题 是否与其主题相关。张贴前先翻翻已有的帖子可 以帮助你感受一下那里行事的方式。事实上,张贴之前在新闻组或邮件列表中搜索与你问题相关的关键词是个很好的主意,也许就找到答案了。即使没有,也能帮助你整理 出 更好的问题。 别象机关枪似的一次性“扫射”所有的帮助通 道,那就象大嚷大叫并使人不快。一个一个地来。 弄清楚你的主题!最典型的错误之一是在某种致立于跨Unix和Windows平台的语言、库或工具的论坛中提关于操作系统程序接口的问题。如果你不明白为什么这是大错,最好在搞清楚概念前什么也别问。
一般来说,在仔细挑选的公共论坛中提问比在私有论坛中提同样的问题更容易得到有用的回复。有许多理由支持这一点,一是看潜在的回复者有多少,二是看论
坛的参与者有多少,黑客更愿回答能启发多数人的问题。 可以理解,老练的黑客和一些流行软件的作者正在收到超出他们承受能力的不当消息。就象那根多出来就可以压垮骆驼背的稻草一样,你的加入也可能会使情况走向极端──已经好几次了,一些流行软件的作者退出了对其软件的支持,因为伴随而来的涌向其私人邮箱的大量无用消息变得无法忍受。 面向新手的网页论坛和IRC通常响应最快本地的用户组织或者你所用的Linux发行版也许正在宣传新手取得帮助的网页论坛或IRC(互联网中继聊天) (在非英语国家,新手论坛很可能还是邮件列表),这些 地 方是开始提问的好去处,尤其是当你觉得遇到的也许只是相对简单或者一般的问题时。经过宣传的IRC通道是个公开邀请提问的地方,通常可以得到实时的回复。 事实上,如果出问题的程序来自某发行版(这很常见),在程序的项目论坛或列表提问前最好先在发行版的论坛或列表中问问,(否则)项目的黑客可能仅仅回复“用我们的代码” 在任何网页论坛张贴之前,先看看是否有搜索功能。如果有,就试试用问题的几个关键词搜索一下,也许就有帮助。如果在此之前你已做过全面的网页搜索 (你应该这样做),还是再搜索一下论坛,搜索引擎最近也许还没有索引此论坛的全部内容。 通过网页论坛或IRC频道提供项目的用户支持有增长的趋势,电子邮件交流则更多地为项目开发保留。先在网页论坛或IRC中寻求与项目相关的帮助。 第二步,使用项目邮件列表当某项目存在开发者邮件列表时,即使你确信谁能最好地回答问题,也要向列表而不是其中的个体提问。检查项目的文档和主页,找到项目的邮件列表并使用它。采用这种策略有几个好理由:
如果一个项目既有“用户”也有“开发者”(或“黑客”)邮件列表或网页论坛,而你又不摆弄那些代码,向“用户”列表或论坛提问。不要假设自己在开发者列表中会受欢 迎,那些人多半会遭受你的噪音干扰。 然尔,如果你确信你的问题不一般,而且在“用户” 列表或论坛中几天都没有回复,可以试试“开发者”列表或论坛。建议你在张贴前最好先暗暗地观察几天以了解那的行事方式(事实上这是参与任何私有或半私有列表的好主意)
如果你找不到一个项目的邮件列表,而只能查到项目维护者的地址,只管向其发信。即便在这种情况下,也别假设(项目)邮件列表不存在。在你的电子邮件中陈述你已经试过但没有找到合适的邮件列表,也提及你不反对将自己的邮件转发给他人(许多人认为,即使没什么秘密,私人电子邮件也不应该被公开。通过允许将你的电子邮件
转 发他人给 了相应人员处置你邮件的选择)。 使用明确而有意义的主题在邮件列表、新闻组或网页论坛中,主题是你在五十个或更少的字符以内吸引有资格的专家注意的黄金机会,不要用诸如“请帮我”(更别提大写的“请帮我!!!!”,这种主题的消息会被条件反射式地删掉)之类的唠叨浪费机会。不要用你痛苦的深度来打动我们,相反,要在这点空间中使用超级简明扼要的问题描述。 使用主题的好惯例是“对象──偏差”(式的描述),许多技术支持组织就是这样做的。在“对象”部分指明是哪一个或哪一组东西有问题,在“偏差”部分则描述与期望 行 为不一致的地方。
编写“对象──偏差”式描述的过程有助于你更具体地组织你的问题。是什么被影响了?仅仅是鼠标光标或者还有其它图形?只在XFree86中出现?或只是在其4.1版中?是针对某显卡?或者只是其MV1005型号的芯片组?一个黑客只需描一眼就能够立即明白什么是你遇到的问题,什么是你自己的问题。 更一般地,想象一下在只显示主题的文档索引中查找。让你的主题更好地反映问题,可以使下一个搜索类似问题的人能够在文档中直接找到答案的线索而不用再次张贴提问。 如果你想在回复中提问,确保改变主题以表明你是在问一个问题,一个主题象“re: 测试”或“re: 新臭虫”的消息不太可能引起足够的注意。同 时,将回复中与新主题不甚相关的引用内容尽量删除 对于列表消息,不要直接点击回复(按钮)来开始一个新的线索,这将限制你的观众。有些邮件阅读程序,比如mutt,允许用户按线索排序并通过折叠线索来隐藏消息, 这样做的人永远看不到你发的消息。 仅仅改变主题还不够。mutt和其它邮件阅读程序还要检查主题以外的其它邮件头信息,以便为其指定线索,所以宁可发一 个全新的邮件。 在网页论坛,因为消息与特定的线索紧密结合并且通常在线索之外不可见,好的提问方式略有不同,通过回复提问并不要紧(一些论坛甚至不允许在回复中出现分离的主题,而且这样做了基本上没有人会去看)。不过通过回复提问本身就是令人怀疑的做法,因为它们只会被正在查看该线索的人读到。所以,除非你只想在该线索当前活跃的人群中提问,还是另起炉灶比较好。 使之更易回复以“请向……回复”来结束问题多半会使你得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都麻烦,我们也觉得花几秒钟考虑你的问题更麻烦。如果你的邮件客户端程序不支持这样做,换个好点的。如果是操作系统不支持所有这种邮件客户端程序,也换个好点的。 在网页论坛,要求通过电子邮件回复是完全无礼的,除非你确信回复的信息也许是机密的(而且有人会为了某种未知的原因只让你而不是整个论坛知道答案)。如果 你只是想在有人回复线索时得到电子邮件提醒,可以要求论坛发送。几乎所有论坛都提供诸如“留意本线索”、“有回复发送邮件”的功能。 使用清晰、语法与拼写正确的语句经验告诉我们,粗心与草率的作者通常也粗心与草率地思考和编程(我敢打赌)。为这些粗心与草率的思考者回答问题没有什么好处,我们宁可将时间花在其它地方。 清楚、完整地表达你的问题非常重要。如果你觉得这样做麻烦,我们也觉得注意(你的问题)麻烦。花点额外的精力斟酌一下字句,用不着太僵硬与正式──事实上,黑客文化很看重能准确地使用非正式、俚语和幽默的语句。但它必须很准确,而且有迹象表明你是在思考和关注问题。 正确地拼写、使用标点和大小写,不要将“its”混淆为“it's”,“loose”搞成“lose”或者将“discrete”弄成 “discreet”。不要全部用大写,这会被看成无礼的大声嚷嚷 (全部小写也好不到哪去,因为不易阅读。Alan Cox[注:著名黑客,Linux内核的重要参与者]也许可以这样做,但你不行 )。 一般而言,如果你写得象个半文盲似的傻子,多半得不到理睬。如果象个小孩似地乱写乱画那绝对是在找死,可以肯定没人会理你(或者最多是给你一大堆指责与挖苦)。 如果在非母语论坛中提问,你的拼写与语法错误会得到有限的宽容,但懒惰完全不会被容忍(是的,我们通常看得出其中的差别)。同时,除非你知道回复者使用 的语言,请使用英语书写。繁忙的黑客一般会直接删除用他们看不懂语言写的消息。在互联网上英语是工作语言,用英语书写可以将你的问题不被阅读就被直接删除的可能降到最低。 使用易懂的格式发送问题如果你人为地将问题搞得难以阅读,它多半会被忽略,人们更愿读易懂的问题,所以:
如果你使用图形用户界面的邮件客户端程序(如网景公司的Messenger、微软公司的Outlook或者其它类似的),注意它们的缺省配置不一定满足这些要求。大多数这类程序有基于菜单的“查看源码”命令,用它来检查发送文件夹中的消息,以确保发送的是没有多余杂质的纯文本文件。 描述问题应准确且有内容
尽最大努力预测黑客会提到的问题,并提前备好答案。 Simon Tatham写过一篇叫 如何有效报告臭虫 的文章,我强烈推荐各位阅读。 多不等于准确你应该(写得)准确且有内容,简单地将一大堆代码或数据“倾倒”在求助消息中达不到目的。如果你有一个很大且复杂的测试样例让程序崩溃,尝试将其裁剪得越小越好。 至少有三个理由支持这点。第一,让别人看到你在努力简化问题使你更有可能得到回复。第二,简化问题使你更有可能得到有用的回复。第三,在提纯臭虫报告的过程中,你可能自己就找到了解决问题的方法或权宜之计。 别动辄声称找到臭虫当你在一个软件中遇到问题,除非你非常、非常的有根据,不要动辄声称找到了臭虫。提示:除非你能提供解决问题的源代码补丁,或者对前一版本的回归测 试表现出不正确的行为,否则你都多半不够完全确信。对于网页和文档也如此,如果你(声称)发现了文档的“臭虫”,你应该能提供相应位置的替代文本。 记住,还有许多其它用户未经历你遇到的问题,否则你在阅读文档或网页搜索时就应该发现了(你在报怨前已经做了这些,是吧?)。这也意味着很有可能是你弄错了而不是软件本身有问题。 编写软件的人通常非常辛苦地使它尽可能完美。如果你声称找到了臭虫,也就暗示他们做错了什么,而这几乎总会使人不快──即使你是对的,在主题中嚷嚷“臭虫”也是特别不老练的。 提问时,即使你私下非常确信已经发现一个真正的臭虫,最好写得象是你做错了什么。如果真的有臭虫,你会在回复中看到这点。这么做的话,如果真有虫子,维护者就会向你道歉,这总比你弄砸了然后欠别人一个道歉要强。 低声下气不能代替自己应做之事有些人明白他们不应该粗鲁或傲慢地行事并要求得到答复,但他们退到相反的低声下气的极端,“我知道我只是个什么也不是、什么也不懂的失败者,但……”。这既使人困扰也没有帮助,当伴随着对实际问题含糊的描述时还特别令人反感。 别用低级灵长类动物的策略浪费大家的时间,相反,尽量清楚地表述背景事实和你的问题,这比低声下气更好地摆正了你的位置。 有时,网页论坛设有单独的初学者提问区域,如果你真的认为遇到了初浅的问题,到那去就是了,但一样别低声下气。 描述问题症状而不是猜测告诉黑客你认为是什么导致了问题是没有用的(如果你的诊断理论是了不起的东西,你还会向他人咨询求助吗?)。所以,确保只是告诉他们问题的原始症状,而不是你的解释和理论,让他们来解释和诊断。如果你认为陈述你的猜测很重要,清楚地说明这只是你的猜测并描述为什么它们不起作用。
按时间先后罗列症状刚出问题之前发生的事情通常包含有解决问题最有效的线索。所以,记录中应准确地描述你及电脑在崩溃之前都做了些什么。在命令行处理的情况下,有会话日志(如运行脚本工具生成的)并引用相关的若干(如20)行记录会非常有帮助。 如果崩溃的程序有诊断选项(如-v详述选项),仔细考虑选择这些能在记录中增加排错信息的选项。 如果你的记录很长(如超过四段),也许在开头简述问题随后按时间先后罗列详细过程更有用。这样做,黑客在读你的记录时就知道该查哪些内容了。 描述目的而不是步骤如果你想弄清楚如何做某事(而不是报告一个臭虫),在开头就描述你的目标,此后才描述为此采取的措施所遇到的问题。 经常有这种情况,寻求技术帮助的人在脑袋里有个更高层面的目标,他们在自以为能达到目标的特定道路上被卡住了,然后跑来问该怎么走,但没有意识到这条路本身有问题,结果要费很大的劲才能通过。
第二种提法是明智的,它使得建议采用更合适的工具完成任务的回复成为可能。 别要求私下回复黑客们认为问题的解决过程应该公开、透明,此过程中如果更有才能的人注意到不完整或者不当之处,最初的回复才能够、也应该被更正。同时,作为回复者也因为能力和学识被其它同行看到而得到某种回报。 当你要求私下回复时,此过程和回报都被中止。别这样做,让回复者来决定是否私下回答──如果他真这么做了,通常是因为他认为问题编写太差或者太肤浅 以 至于对其它人无意义。 对这条规则存在一条有限的例外,如果你确信提问可能会导致大量雷同的回复时,那么“给我发电子邮件,我将为小组归纳这些回复”将是神奇的句子。试图将邮 件列表或新闻组从洪水般雷同的回复中解救出来是非常有礼貌的──但你应信守诺言。 问题应明晰
|
| 问: |
我到哪可以找到程序或X资源? |
| 答: |
在我找到它的同样地方,笨旦──在网页搜索引擎上。上帝啊,难道还有人不知道如何使用 Google 吗? |
| 问: |
我怎样用X做Y? |
| 答: |
如果你想做的是Y,提问时别给出可能并不恰当的方法。这种问题说明提问者不但对X完全无知,也对要解决的Y问题糊涂,还被特定形势禁锢了思维。等他们把问题弄 好再说。 |
| 问: |
如何配置我的shell提示? |
| 答: |
如果你有足够的智慧提这个问题,你也该有足够的智慧去 RTFM,然后自己去找。 |
| 问: |
我可以用Bass-o-matic文件转换工具将AcmeCorp文档转为TeX格 式吗? |
| 答: |
试试就知道了。如果你试过,你既知道答案,又不用浪费我的时间了。 |
| 问: |
我的{程序、配置、SQL语句}不运行了 |
| 答: |
这不是一个问题,我也没有兴趣去猜你有什么问题──我有更要紧的事要做。看到这种东西,我的反应一般如下:
|
| 问: |
我的视窗电脑出问题了,你能帮忙吗? |
| 答: |
是的,把视窗垃圾删了,装个象Linux或BSD的开源操作系统吧。 注意:如果程序有官方的视窗版或与视窗有交互(如Samba),你可以问与视窗电脑相关的问题,只是别对问题是由视窗操作系统而不是程序本身造成的回复感 到惊讶,因 为视窗一般来说太差,这种说法一般都成立。 |
| 问: |
我的程序不运行了,我认为系统工具X有问题 |
| 答: |
你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与库文件有明显缺陷的人,更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据, 当你这样 声称时,你必须有清楚而详尽的缺陷说明文档作后盾。 |
| 问: |
我安装Linux或X遇到问题,你能帮忙吗? |
| 答: |
不行,我需要亲手操作你的电脑才能帮你排错,去向当地的Linux用户组寻求方便的帮助(你可以在 这里 找到用户组列表) 注意:在为某一Linux发行版服务的邮件列表或论坛或本地用户组织中提关于安装该发行版的问题也许是恰当的。此时,应描述问题的准确细节。在此之前,先用 “linux”和所有被怀疑的硬件(为关键词)仔细搜索。 |
| 问: |
我如何才能破解超级用户口令/盗取频道操作员的特权/查看某人的电子邮件? |
| 答: |
想做这种事情说明你是个卑劣的家伙,想让黑客教你做这种事情说明你是个白痴。 |
最后,我将通过举例来演示提问的智慧。同样的问题两种问法,一种愚蠢,另一种明智。
这个问题在乞求得到 STFW 式的回复。
这个人已经搜索过网络了,而且听起来他可能真的遇到了问题。
他假设是别人搞砸了,太自大了。
他指明了运行环境,读了FAQ,列出了错误,也没有假设问题是别人的过错,这家伙值得注意。
某黑客对此的反应可能是:“是的,还需要帮你拍背和换尿布吗?”,然后是敲下删除键。
相反地,这个人看来值得回答。他展现了解决问题的能力而不是坐等天上掉馅饼。
在最后那个问题中,注意“给我一个回复”与“请帮我看看我还能再做点什么测试以得到启发”之间细微但重要的差别。
事实上,最后那个问题基本上源于2001年8月Linux内核邮件列表(lkml)上的真实事件,是我(Eric)当时提了那个问题,我发现
Tyan S2462 主板有神秘的死机现象,邮件列表成员给我提供了解决此问题的关键信息。
通过这种提问方式,我给了别人可以咀嚼玩味的东西。我设法使之对参与者既轻松又有吸引力,也表明了对同行能力的尊敬并邀请他们与我一起协商。通过告诉 他们我已经走过的弯路,我还表明了对他们宝贵时间的尊重。
事后,当我感谢大家并评论这次良好的经历时,一个Linux内核邮件列表的成员谈到,他认为并不是因为我的名字在列表上,而是因为我正确的提问方式才 得到了答 案。
黑客们在某种方面是非常不留情面的精英分子。我想他是对的,如果我表现得象个不劳而获的寄生虫,不管我是谁都会被忽略或斥责。他建议将整个事件作为对其它 人 提问的指导直接导致了本文的编写。
如果得不到回答,请不要认为我们不想帮你,有时候只是因为小组成员的确不知道答案。没有回复不等于被忽略,当然必须承认从外面很难看出两者的差别。
一般来说,直接将问题再张贴一次不好,这会被视为毫无意义的骚扰。
还有其它资源可以寻求帮助,通常是在一些面向新手的资源中。
有许多在线与本地用户组织,虽然它们自己不编写任何软件,但是对软件很热心。这些用户组通常因互助和帮助新手而形成。
还有众多大小商业公司提供签约支持服务(红帽与Linuxcare是两家最出名的,还有许多其它的)。别因为要付点钱才有支持就感到沮丧!毕竟,如果你车子的 汽缸垫烧了,你多半还得花钱找个修理店把它弄好。即使软件没花你一分钱,你总不能指望服务支持都是免费的。
象Linux这样流行的软件,每个开发者至少有一万个以上的用户,一个人不可能应付这么多用户的服务要求。记住,即使你必须付费才能得到支持,也比你还得额外花钱买软件要少得多(而且对封闭源代码软件的服务支持与开源软件相比通常还要贵一点,也要差一点)
态度和善一点。问题带来的压力常使人显得无礼或愚蠢,其实并不是这样。
对初犯者私下回复。对那些坦诚犯错之人没有必要当众羞辱,一个真正的新手也许连怎么搜索或在哪找FAQ都不知道。
如果你不确定,一定要说出来!一个听起来权威的错误回复比没有还要糟,别因为听起来象个专家好玩就给别人乱指路。要谦虚和诚实,给提问者与同行都树个好榜样。
如果帮不了忙,别妨碍。不要在具体步骤上开玩笑,那样也许会毁了用户的安装──有些可怜的呆瓜会把它当成真的指令。
探索性的反问以引出更多的细节。如果你做得好,提问者可以学到点东西──你也可以。试试将很差的问题转变成好问题,别忘了我们都曾是新手。
尽管对那些懒虫报怨一声RTFM是正当的,指出文档的位置(即使只是建议做个Google关键词搜索)会更好。
如果你决意回答,给 出好的答案。当别人正使用错误的工具或不当的方法时别建议笨拙的权宜之计,应推荐更好的工具,重新组织问题。
帮助你的社区从问题中 学习。当回复一个好问题时,问问自己 “如何修改相关文件或FAQ文档以免再次解答同样的问题?”,接着再向文档维护者发一份补丁。
如果你的确是在研究一番后才做出的回答,展现你的技巧而不是直接端出结果。毕竟“授 人以鱼,不如授人以渔”。
| 关联主题 |
| 作者的其他文章 |
参与值:2191 贡献值:138 |
提问的技巧
一段有智慧话
西藏獒犬的神话与传说
在恐惧中成长(李阳)| ©2006-2008 深圳市海为信息技术有限公司 | 关于i170 | 工作机会 | 联系我们 粤ICP备05095695号 ![]() |