提问的智慧
咱们现已深刻领教到少了上述声明所带来的痛苦。由于少了这点声明,咱们不停地被一些白痴纠缠。这些白痴以为既然咱们发布了这本攻略,那么咱们就有责任处理世上一切的技术问题。

提问的智慧

PRs Welcome

How To Ask Questions The Smart Way

Copyright © 2001,2006,2014 Eric S. Raymond, Rick Moen

本攻略英文版版权为 Eric S. Raymond, Rick Moen 一切。

Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu

本中文攻略是根据原文 3.10 版以及 2010 年由 Gasolin 所翻译版别的最新翻译;

帮忙指出翻译问题,发 issue,或直接发 pull request 给我。

目录

声明

许多项目在他们的运用帮忙/阐明网页中链接了本攻略,这么做很好,咱们也鼓励大家都这么做。但假如你是负责管理这个项目网页的人,请在超链接附近的显著位置上注明:

本攻略不供给此项意图实践支撑服务!

咱们现已深刻领教到少了上述声明所带来的痛苦。由于少了这点声明,咱们不停地被一些白痴纠缠。这些白痴以为既然咱们发布了这本攻略,那么咱们就有责任处理世上一切的技术问题。

假如你因寻求某些帮忙而阅览本攻略,并在脱离时还觉得能够从本文作者这里得到直接帮忙,那你便是咱们之前说的那些白痴之一。别问咱们问题,咱们只会疏忽你。咱们在这本攻略中想教你怎样从那些真实懂得你所遇到的软件或硬件问题的人处取得帮忙,而 99% 的情况下那不会是咱们。除非你确定本攻略的作者之一刚好是你所遇到的问题领域的专家,不然请不要打扰咱们,这样大家都会开心一点。

简介

黑客的世界里,当你拋出一个技术问题时,最终是否能得到有用的答复,往往取决于你所发问和追问的方式。本攻略将教你怎样正确的发问以取得你满意的答案。

现在开源(Open Source)软件现已相当盛行,您一般能够从其他更有经验的用户那里取得与黑客相同好的答案,这是件好事;和黑客相比,用户们往往对那些新手常遇到的问题更宽容一些。尽管如此,以咱们在此推荐的方式对待这些有经验的用户一般也是从他们那里取得有用答案的最有效方式。

首先你应该明白,黑客们喜欢有挑战性的问题,或许能激发他们思维的好问题。假如咱们并非如此,那咱们也不会成为你想询问的对象。假如你给了咱们一个值得反复咀嚼玩味的好问题,咱们自会对你感谢不尽。好问题是激励,是厚礼。好问题能够提高咱们的了解力,并且一般会暴露咱们曾经从没意识到或许考虑过的问题。对黑客而言,“好问题!”是诚挚的大力称赞。

尽管如此,黑客们有着鄙视或高傲面对简单问题的坏名声,这有时让咱们看起来对新手、无知者似乎较有敌意,但其实不是那样的。

咱们不讳言咱们对那些不肯考虑、或许在发问前不做他们该做的事的人的鄙视。那些人是时刻杀手 —— 他们只想索取,从不付出,消耗咱们可用在更风趣的问题或更值得答复的人身上的时刻。咱们称这样的人为 失败者(撸瑟) (由于历史原因,咱们有时把它拼作 lusers)。

咱们意识到许多人仅仅想运用咱们写的软件,他们对学习技术细节没有兴趣。对大多数人而言,电脑仅仅种东西,是种达到意图的手段而已。他们有自己的日子并且有更要紧的事要做。咱们了解这点,也从不指望每个人都对这些让咱们着迷的技术问题感兴趣。尽管如此,咱们答复问题的风格是指向那些真实对此有兴趣并愿意自动参与处理问题的人,这一点不会变,也不该变。假如连这都变了,咱们便是在降低做自己最擅长的作业上的效率。

咱们(在很大程度上)是自愿的,从繁忙的日子中抽出时刻来解答疑问,并且时常被发问淹没。所以咱们无情地滤掉一些论题,特别是拋弃那些看起来像失败者的家伙,以便更高效地使用时刻来答复赢家(winner)的问题。

假如你讨厌咱们的态度,高高在上,或过于高傲,不妨也设身处地想想。咱们并没有要求你向咱们屈服 —— 事实上,咱们大多数人十分乐意与你平等地沟通,只要你付出小小尽力来满意基本要求,咱们就会欢迎你参加咱们的文明。但让咱们帮忙那些不肯意帮忙自己的人是没有效率的。无知没有关系,但装白痴便是不行。

所以,你不必在技术上很在行才干吸引咱们的留意,但你必须表现出能引导你变得在行的特质 —— 机敏、有想法、善于调查、乐于自动参与处理问题。假如你做不到这些使你与众不同的作业,咱们主张你花点钱找家商业公司签个技术支撑服务合同,而不是要求黑客个人无偿地帮忙你。

假如你决定向咱们求助,当然你也不希望被视为失败者,更不肯成为失败者中的一员。能马上得到快速并有效答案的最好办法,便是像赢家那样发问 —— 聪明、自信、有处理问题的思路,仅仅偶尔在特定的问题上需求取得一点帮忙。

(欢迎对本攻略提出改善意见。你能够把你的主张发送至 esr@thyrsus.comrespond-auto@linuxmafia.com。然而请留意,本文并非网络礼节的通用攻略,而咱们一般会回绝无助于在技术论坛得到有用答案的主张)。

在发问之前

在你预备要经过电子邮件、新闻群组或许聊天室提出技术问题前,请先做到以下作业:

  1. 测验在你预备发问的论坛的旧文章中查找答案。
  2. 测验上网查找以找到答案。
  3. 测验阅览手册以找到答案。
  4. 测验阅览常见问题文件(FAQ)以找到答案。
  5. 测验自己检查或试验以找到答案。
  6. 向你身边的强者朋友打听以找到答案。
  7. 假如你是程序开发者,请测验阅览源代码以找到答案。

当你提出问题的时分,请先表明你现已做了上述的尽力;这将有助于树立你并不是一个不劳而获且糟蹋他人的时刻的发问者。假如你能一起表达在做了上述尽力的过程中所学到的东西会更好,由于咱们更乐于答复那些表现出能从答案中学习的人的问题。

运用某些战略,比如先用 Google 查找你所遇到的各种过错信息(查找 Google 论坛和网页),这样很或许直接就找到了能处理问题的文件或邮件列表线索。即使没有成果,在邮件列表或新闻组寻求帮忙时加上一句 我在 Google 中搜过下列句子但没有找到什么有用的东西 也是件好事,即使它仅仅表明了查找引擎不能供给哪些帮忙。这么做(加上查找过的字串)也让遇到相似问题的其他人能被查找引擎引导到你的发问来。

别着急,不要指望几秒钟的 Google 查找就能处理一个复杂的问题。在向专家求助之前,再阅览一下常见问题文件(FAQ)、放轻松、坐得舒服一些,再花点时刻考虑一下这个问题。信任咱们,他们能从你的发问看出你做了多少阅览与考虑,假如你是有备而来,将更有或许得到解答。不要将一切问题一股脑拋出,只因你的第一次查找没有找到答案(或许找到太多答案)。

预备好你的问题,再将问题仔细的考虑过一遍,由于草率的发问只能得到草率的答复,或许根本得不到任何答案。越是能表现出在寻求帮忙前你为处理问题所付出的尽力,你越有或许得到实质性的帮忙。

小心别问错了问题。假如你的问题根据过错的假设,某个普通黑客(J. Random Hacker)八成会一边在心里想着蠢问题…,一边用无意义的字面解释来答复你,希望着你会从问题的答复(而非你想得到的答案)中汲取教训。

绝不要自以为够格得到答案,你没有;你并没有。毕竟你没有为这种服务支付任何报酬。你将会是自己去挣到一个答案,靠提出有内涵的、风趣的、有思维激励作用的问题 —— 一个有潜力能贡献社区经验的问题,而不仅仅是被动的从他人处索取知识。

另一方面,表明你愿意在找答案的过程中做点什么是一个十分好的开端。谁能给点提示?我的这个例子里缺了什么?以及我应该检查什么地方请把我需求确实切的过程贴出来更简单得到答复。由于你表现出只要有人能指个正确方向,你就有完成它的能力和决心。

当你发问时

慎选发问的论坛

小心挑选你要发问的场合。假如你做了下述的作业,你很或许被疏忽掉或许被看作失败者:

  • 在与主题不合的论坛上贴出你的问题。
  • 在讨论进阶技术问题的论坛粘贴十分初级的问题;反之亦然。
  • 在太多的不同新闻群组上重复转贴同样的问题(cross-post)。
  • 向既非熟人也没有义务处理你问题的人发送私家电邮。

黑客会剔除掉那些搞错场合的问题,以保护他们沟通的途径不被无关的东西淹没。你不会想让这种事发生在自己身上的。

因而,第一步是找到对的论坛。再说一次,Google 和其它查找引擎仍是你的朋友,用它们来找到与你遭遇到困难的软硬件问题最相关的网站。一般那儿都有常见问题(FAQ)、邮件列表及相关阐明文件的链接。假如你的尽力(包括阅览 FAQ)都没有成果,网站上或许还有陈述 Bug(Bug-reporting)的流程或链接,假如是这样,链过去看看。

向陌生的人或论坛发送邮件最或许是危险最大的作业。举例来说,别假设一个供给丰厚内容的网页的作者会想充任你的免费顾问。不要对你的问题是否会遭到欢迎做太乐观的估计 —— 假如你不确定,那就向别处发送,或许压根别发。

在挑选论坛、新闻群组或邮件列表时,别太信任它的名字,先看看 FAQ 或许许可书以弄清楚你的问题是否切题。发文前先翻翻已有的论题,这样能够让你感受一下那里的文明。事实上,事先在新闻组或邮件列表的历史记载中查找与你问题相关的关键词是个极好的主意,或许这样就找到答案了。即使没有,也能帮忙你概括出更好的问题。

别像机关枪似的一次“扫射”一切的帮忙途径,这就像大喊大叫相同会使人不快。要一个一个地来。

搞清楚你的主题!最典型的过错之一是在某种致力于跨平台可移植的言语、套件或东西的论坛中提关于 Unix 或 Windows 操作系统程序界面的问题。假如你不明白为什么这是大错,最好在搞清楚这之间差异之前什么也别问。

一般来说,在仔细挑选的公共论坛中发问,会比在私有论坛中提同样的问题更简单得到有用的答复。有几个理由能够支撑这点,一是看潜在的回复者有多少,二是看观众有多少。黑客较愿意答复那些能帮忙到许多人的问题。

能够了解的是,老练的黑客和一些抢手软件的作者正在接受过多的错发信息。就像那根最后压垮骆驼背的稻草相同,你的参加也有或许使情况走向极点 —— 现已好几次了,一些抢手软件的作者由于涌入其私家邮箱的大量不堪忍受的无用邮件而不再供给支撑。

Stack Overflow

查找,然后在 Stack Exchange 问。

近年来,Stack Exchange 社区现已成为答复技术及其他问题的首要途径,尤其是那些开放源码的项目。

由于 Google 索引是即时的,在看 Stack Exchange 之前先在 Google 查找。有很高的几率或人现已问了一个相似的问题,并且 Stack Exchange 网站们往往会是查找成果中最前面几个。假如你在 Google 上没有找到任何答案,你再到特定相关主题的网站去找。用标签(Tag)查找能让你更缩小你的查找成果。

假如你仍是找不到任何对你的问题有用的内容,请把你的问题发在与它最相关的网站上。发问的时分请善用善用格局化东西,尤其留意为代码添加格局,并且添加相关的标签(特别是编程言语、操作系统或库/包的名称)。当有人要求你供给更多相关信息时,请编辑你的贴子来弥补它们[译注:而不是发一个回帖或答复!]。假如你觉得一个答案对你有帮忙,点击向上的箭头来为它投票;假如一个答案供给了问题的正确处理计划,点击投票按钮下方的对勾来将它标记为正解。

Stack Exchange 现已成长到超越一百个网站,以下是最常用的几个站:

  • Super User 是问一些通用的电脑问题,假如你的问题跟代码或是写程序无关,仅仅一些网络连线之类的,请到这里。
  • Stack Overflow 是问写程序有关的问题。
  • Server Fault 是问服务器和网管相关的问题。

网站和 IRC 论坛

本地的用户群组(user group),或许你所用的 Linux 发行版别或许正在宣传他们的网页论坛或 IRC 频道,并供给新手帮忙(在一些非英语国家,新手论坛很或许仍是邮件列表),这些都是开始发问的好地方,特别是当你觉得遇到的或许仅仅相对简单或许很普通的问题时。有广告资助的 IRC 频道是揭露欢迎发问的地方,一般能够即时得到回应。

事实上,假如程序出的问题只发生在特定 Linux 发行版供给的版别(这很常见),最好先去该发行版的论坛或邮件列表中发问,再到程序本身的论坛或邮件列表发问。(不然)该项意图黑客或许仅仅回复“运用咱们的版别”。

在任何论坛发文曾经,先确认一下有没有查找功用。假如有,就试着查找一下问题的几个关键词,或许这会有帮忙。假如在此之前你已做过通用的网页查找(你也该这样做),仍是再查找一下论坛,查找引擎有或许没来得及索引此论坛的全部内容。

经过论坛或 IRC 频道来供给用户支撑服务有增长的趋势,电子邮件则大多为项目开发者间的沟通而保留。所以最好先在论坛或 IRC 中寻求与该项目相关的帮忙。

在运用 IRC 的时分,首先最好不要发布很长的问题描绘,有些人称之为频道洪水。最好经过一句话的问题描绘来开始聊天。

第二步,运用项目邮件列表

当某个项目供给开发者邮件列表时,要向列表而不是其间的单个成员发问,即使你坚信他能最好地答复你的问题。查一查项意图文件和首页,找到项意图邮件列表并运用它。有几个很好的理由支撑咱们采用这种办法:

  • 任何好到需求向单个开发者提出的问题,也将对整个项目群组有益。反之,假如你以为自己的问题对整个项目群组来说太愚笨,那这也不能成为骚扰单个开发者的理由。
  • 向列表发问能够分散开发者的负担,单个开发者(尤其是项目领导人)或许太忙以至于没法答复你的问题。
  • 大多数邮件列表都会被存档,那些被存档的内容将被查找引擎索引。假如你向列表发问并得到解答,将来其他人能够经过网页查找找到你的问题和答案,也就不必再次发问了。
  • 假如某些问题经常被问到,开发者能够使用此信息来改善阐明文件或软件本身,以使其更清楚。假如仅仅暗里发问,就没有人能看到最常见问题的完好场景。

假如一个项目既有“用户”也有“开发者”(或“黑客”)邮件列表或论坛,而你又不会动到那些源代码,那么就向“用户”列表或论坛发问。不要假设自己会在开发者列表中遭到欢迎,那些人八成会将你的发问视为干扰他们开发的噪音。

然而,假如你坚信你的问题很特别,并且在“用户”列表或论坛中几天都没有回复,能够试试前往“开发者”列表或论坛发问。主张你在粘贴前最好先暗地里调查几天以了解那里的行事方式(事实上这是参与任何私有或半私有列表的好主意)

假如你找不到一个项意图邮件列表,而只能查到项目维护者的电子邮件地址,尽管向他发信。即使是在这种情况下,也别假设(项目)邮件列表不存在。在你的电子邮件中,请陈述你现已试过但没有找到合适的邮件列表,也提及你不反对将自己的邮件转发给他人(许多人以为,即使没什么隐秘,私家电子邮件也不应该被揭露。经过允许将你的电子邮件转发他人,你给了相应人员处置你邮件的挑选)。

运用有意义且描绘明晰的标题

在邮件列表、新闻群组或论坛中,大约 50 字以内的标题是抓住资深专家留意力的好时机。别用喋喋不休的帮帮忙跪求(更别说救命啊!!!!这样让人反感的话,用这种标题会被条件反射式地疏忽)来糟蹋这个时机。不要妄想用你的痛苦程度来打动咱们,而应该是在这点空间中运用极简单简明的描绘方式来提出问题。

一个好标题范例是方针 —— 差异式的描绘,许多技术支撑组织便是这样做的。在方针部分指出是哪一个或哪一组东西有问题,在差异部分则描绘与期望的行为不一致的地方。

蠢问题:救命啊!我的笔记本电脑不能正常显示了!

聪明问题:X.org 6.8.1 的鼠标指针会变形,某牌显卡 MV1005 芯片组。

更聪明问题:X.org 6.8.1 的鼠标指针,在某牌显卡 MV1005 芯片组环境下 - 会变形。

编写方针 —— 差异 式描绘的过程有助于你组织对问题的细致考虑。是什么被影响了? 仅仅是鼠标指针或许还有其它图形?只在 X.org 的 X 版中呈现?或仅仅呈现在 6.8.1 版中? 是针对某牌显卡芯片组?或许仅仅其间的 MV1005 类型? 一个黑客只需瞄一眼就能够立即明白你的环境你遇到的问题。

总而言之,请想像一下你正在一个只显示标题的存档评论串(Thread)索引中查寻。让你的标题更好地反映问题,可使下一个查找相似问题的人能够重视这个评论串,而不必再次发问相同的问题。

假如你想在回复中提出问题,记得要修改内容标题,以表明你是在问一个问题, 一个看起来像 Re: 测试 或许 Re: 新 bug 的标题很难引起足够重视。另外,在不影响连贯性之下,适当引用并删减前文的内容,能给新来的读者留下线索。

关于评论串,不要直接点击回复来开始一个全新的评论串,这将限制你的观众。由于有些邮件阅览程序,比如 mutt ,允许用户按评论串排序并经过折叠评论串来隐藏音讯,这样做的人永久看不到你发的音讯。

仅仅改动标题还不够。mutt 和其它一些邮件阅览程序还会检查邮件标题以外的其它信息,以便为其指定评论串。所以宁可发一个全新的邮件。

在网页论坛上,好的发问方式稍有不同,由于评论串与特定的信息紧密结合,并且一般在评论串外就看不到里面的内容,故经过回复发问,而非改动标题是可接受的。不是一切论坛都允许在回复中呈现分离的标题,并且这样做了基本上没有人会去看。不过,经过回复发问,这本身便是暧昧的做法,由于它们只会被正在检查该标题的人读到。所以,除非你只想在该评论串当前活跃的人群中发问,不然仍是另起炉灶比较好。

使问题简单回复

请将你的回复发送到……来结束你的问题八成会使你得不到答复。假如你觉得花几秒钟在邮件客户端设置一下回复地址都麻烦,咱们也觉得花几秒钟考虑你的问题更麻烦。假如你的邮件程序不支撑这样做,换个好点的;假如是操作系统不支撑这种邮件程序,也换个好点的。

在论坛,要求经过电子邮件回复是十分无礼的,除非你以为回复的信息或许比较敏感(有人会为了某些未知的原因,只让你而不是整个论坛知道答案)。假如你仅仅想在有人回复评论串时得到电子邮件提醒,能够要求网页论坛发送给你。几乎一切论坛都支撑比如追踪此评论串有回复时发送邮件提醒等功用。

运用明晰、正确、精准且符合语法的句子 咱们从经验中发现,粗心的发问者一般也会粗心地写程序与考虑(我敢打包票)。答复粗心大意者的问题很不值得,咱们宁愿把时刻耗在别处。

正确的拼写、标点符号和大小写是很重要的。一般来说,假如你觉得这样做很麻烦,不想在乎这些,那咱们也觉得麻烦,不想在乎你的发问。花点额定的精力斟酌一下字句,用不着太僵硬与正式 —— 事实上,黑客文明很看重能精确地运用非正式、俚语和诙谐的句子。但它必须很精确,并且有迹象表明你是在考虑和重视问题。

正确地拼写、运用标点和大小写,不要将its混淆为it'sloose搞成lose或许将discrete弄成discreet。不要全部用大写,这会被视为无礼的大声嚷嚷(全部小写也好不到哪去,由于不易阅览。Alan Cox 或许能够这样做,但你不行)。

更白话的说,假如你写得像是个半文盲[译注:小白],那八成得不到答理。也不要运用即时通信中的简写或火星文,如将简化为d会使你看起来像一个为了少打几个键而省字的小白。更糟的是,假如像个小孩似地鬼画符那绝对是在找死,能够肯定没人会理你(或许最多是给你一大堆责备与挖苦)。

假如在运用非母语的论坛发问,你能够犯点拼写和语法上的小错,但决不能在考虑上马虎(没错,咱们一般能弄清两者的分别)。一起,除非你知道回复者运用的言语,不然请运用英语书写。繁忙的黑客一般会直接删去用他们看不懂的言语写的音讯。在网络上英语是通用言语,用英语书写能够将你的问题在尚未被阅览就被直接删去的或许性降到最低。

假如英文是你的外语(Second language),提示潜在回复者你有潜在的言语困难是很好的: [译注:以下附上原文以供运用]

English is not my native language; please excuse typing errors.

  • 英文不是我的母语,请原谅我的错字或语法。

If you speak $LANGUAGE, please email/PM me; I may need assistance translating my question.

  • 假如你说某言语,请向我发电邮/私信;
  • 我需求有人帮忙我翻译我的问题。

I am familiar with the technical terms, but some slang expressions and idioms are difficult for me.

  • 我对技术名词很熟悉,但关于俗话或是特别用法不甚了解。

I’ve posted my question in $LANGUAGE and English. I’ll be glad to translate responses, if you only use one or the other.

  • 我把我的问题用某言语和英文写出来。
  • 假如你只用其间的一种言语答复,我会乐意将回复翻译成为你运用的言语。

运用易于读取且规范的文件格局发送问题

假如你人为地将问题搞得难以阅览,它八成会被疏忽,人们更愿读易懂的问题,所以:

  • 运用纯文字而不是 HTML (关闭 HTML 并不难)。
  • 运用 MIME 附件一般是能够的,前提是真实有内容(譬如附带的源代码或 patch),而不仅仅是邮件程序生成的模板(譬如仅仅函件内容的拷贝)。
  • 不要发送一段文字仅仅一行句子但自动换行后会变成多行的邮件(这使得回复部分内容十分困难)。设想你的读者是在 80 个字符宽的终端机上阅览邮件,最好设置你的换行切割点小于 80 字。
  • 可是,对一些特殊的文件不要设置固定宽度(譬如日志文件拷贝或会话记载)。数据应该原样包括,让回复者有信心他们看到的是和你看到的相同的东西。
  • 在英语论坛中,不要运用Quoted-Printable MIME 编码发送音讯。这种编码关于粘贴非 ASCII 言语或许是必须的,但许多邮件程序并不支撑这种编码。当它们处理换行时,那些文本中四处散布的=20符号既难看也分散留意力,甚至有或许破坏内容的语意。
  • 绝对,永久不要指望黑客们阅览运用封闭格局编写的文档,像微软公司的 Word 或 Excel 文件等。大多数黑客对此的反响就像有人将还在冒热气的猪粪倒在你家门口时你的反响相同。即使他们能够处理,他们也很讨厌这么做。
  • 假如你从运用 Windows 的电脑发送电子邮件,关闭微软愚笨的智能引号功用 (从[选项] > [校订] > [自动校正选项],勾选掉智能引号单选框),以免在你的邮件中到处散布垃圾字符。
  • 在论坛,勿滥用表情符号HTML功用(当它们供给时)。一两个表情符号一般没有问题,但花哨的五颜六色文本倾向于使人以为你是个无能之辈。过滥地运用表情符号、色彩和字体会使你看来像个傻笑的小姑娘。这一般不是个好主意,除非你仅仅对性而不是对答案感兴趣。

假如你运用图形用户界面的邮件程序(如微软公司的 Outlook 或许其它相似的),留意它们的默认设置不一定满意这些要求。大多数这类程序有根据选单的检查源代码命令,用它来检查发送文件夹中的邮件,以保证发送的是纯文本文件一起没有一些奇怪的字符。

精确地描绘问题并言之有物

  • 仔细、清楚地描绘你的问题或 Bug 的症状。
  • 描绘问题发生的环境(机器配置、操作系统、应用程序、以及相关的信息),供给经销商的发行版和版别号(如:Fedora Core 4Slackware 9.1等)。
  • 描绘在发问前你是怎样去研究和了解这个问题的。
  • 描绘在发问前为确定问题而采取的确诊过程。
  • 描绘最近做过什么或许相关的硬件或软件变更。
  • 尽或许地供给一个能够重现这个问题的可控环境的办法。

尽量去揣测一个黑客会怎样反问你,在你发问之前预先将黑客们或许提出的问题答复一遍。

以上几点中,当你陈述的是你以为或许在代码中的问题时,给黑客一个能够重现你的问题的环境尤其重要。当你这么做时,你得到有效的答复的时机和速度都会大大的提升。

Simon Tatham 写过一篇名为《怎样有效的陈述 Bug》的出色文章。强力推荐你也读一读。

话不在多而在精

你需求供给精确有内容的信息。这并不是要求你简单的把成堆的出错代码或许材料完全转录到你的发问中。假如你有庞大而复杂的测试样例能重现程序挂掉的情境,尽量将它剪裁得越小越好。

这样做的用处至少有三点。 第一,表现出你为简化问题付出了尽力,这能够使你得到答复的时机增加; 第二,简化问题使你更有或许得到有用的答案; 第三,在精炼你的 bug 陈述的过程中,你很或许就自己找到了处理办法或权宜之计。

别动辄宣称找到 Bug

当你在运用软件中遇到问题,除非你十分、十分的有根据,不要动辄宣称找到了 Bug。提示:除非你能供给处理问题的源代码补丁,或许供给回归测试来表明前一版别中行为不正确,不然你都八成不够完全坚信。这同样适用在网页和文件,假如你(宣称)发现了文件的Bug,你应该能供给相应位置的修正或替代文件。

请记得,还有其他许多用户没遇到你发现的问题,不然你在阅览文件或查找网页时就应该发现了(你在抱怨前现已做了这些,是吧?)。这也意味着很有或许是你弄错了而不是软件本身有问题。

编写软件的人总是十分辛苦地使它尽或许完美。假如你宣称找到了 Bug,也便是在质疑他们的能力,即使你是对的,也有或许会得罪到其间某部分人。当你在标题中嚷嚷着有Bug时,这尤其严重。

发问时,即使你暗里十分坚信现已发现一个真实的 Bug,最好写得像是做错了什么。假如真的有 Bug,你会在回复中看到这点。这样做的话,假如真有 Bug,维护者就会向你抱歉,这总比你惹恼他人然后欠他人一个抱歉要好一点。

低声下气不能代替你的功课

有些人明白他们不该粗鲁或高傲的发问并要求得到答复,但他们挑选另一个极点 —— 低声下气:我知道我仅仅个可悲的新手,一个撸瑟,但...。这既使人困扰,也没有用,尤其是伴随着与实践问题含糊不清的描绘时更令人反感。

别用原始灵长类动物的把戏来糟蹋你我的时刻。取而代之的是,尽或许清楚地描绘背景条件和你的问题情况。这比低声下气更好地定位了你的位置。

有时网页论坛会设有专为新手发问的版面,假如你真的以为遇到了初学者的问题,到那去便是了,但相同别那么低声下气。

描绘问题症状而非你的猜测

告知黑客们你以为问题是怎样造成的并没什么帮忙。(假如你的揣度如此有效,还用向他人求助吗?),因而要坚信你原原本本告知了他们问题的症状,而不是你的解释和理论;让黑客们来推测和确诊。假如你以为陈述自己的猜测很重要,清楚地阐明这仅仅你的猜测,并描绘为什么它们不起作用。

蠢问题

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

聪明问题

我的组装电脑是 FIC-PA2007 主机板搭载 AMD K6/233 CPU(威盛 Apollo VP2 芯片组), 256MB Corsair PC133 SDRAM 内存,在编译内核时,从开机 20 分钟今后就一再发生 SIG11 过错, 可是在头 20 分钟内从没发生过相同的问题。重新启动也没有用,可是关机一晚上就又能作业 20 分钟。 一切内存都换过了,没有效果。相关部分的规范编译记载如下…。

由于以上这点似乎让许多人觉得难以配合,这里有句话能够提醒你:一切的确诊专家都来自密苏里州。 美国国务院的官方座右铭则是:让我看看(出自国会议员 Willard D. Vandiver 在 1899 年时的讲话:我来自一个出产玉米,棉花,牛蒡和民主党人的国家,滔滔雄辩既不能说服我,也不会让我满意。我来自密苏里州,你必须让我看看。) 针对确诊者而言,这并不是一种置疑,而仅仅一种真实而有用的需求,以便让他们看到的是与你看到的原始证据尽或许一致的东西,而不是你的猜测与概括的结论。所以,大方的展示给咱们看吧!

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

问题发生前的一系列操作,往往便是对找出问题最有帮忙的线索。因而,你的阐明里应该包括你的操作过程,以及机器和软件的反响,直到问题发生。在命令行处理的情况下,供给一段操作记载(例如运转脚本东西所生成的),并引用相关的若干行(如 20 行)记载会十分有帮忙。

假如挂掉的程序有确诊选项(如 -v 的胪陈开关),试着挑选这些能在记载中增加调试信息的选项。记住,不等于。试着选取适当的调试级别以便供给有用的信息而不是让读者淹没在垃圾中。

假如你的阐明很长(如超越四个段落),在最初简述问题,接下来再按时刻顺序胪陈会有所帮忙。这样黑客们在读你的记载时就知道该留意哪些内容了。

描绘方针而不是过程

假如你想弄清楚怎样做某事(而不是陈述一个 Bug),在最初就描绘你的方针,然后才陈述重现你所卡住的特定过程。

经常寻求技术帮忙的人在心中有个更高层次的方针,而他们在自以为能达到方针的特定道路上被卡住了,然后跑来问该怎样走,但没有意识到这条路本身就有问题。成果要费很大的劲才干搞定。

蠢问题

我怎样才干从某绘图程序的颜色挑选器中取得十六进制的 RGB 值?

聪明问题

我正试着用替换一幅图片的色码(color table)成自己选定的色码,我现在知道的唯一办法是编辑每个色码区块(table slot), 但却无法从某绘图程序的颜色挑选器取得十六进制的 RGB 值。

第二种发问法比较聪明,你或许得到像是主张采用另一个更合适的东西的回复。

别要求运用私家电邮回复

黑客们以为问题的处理过程应该揭露、透明,此过程中假如更有经验的人留意到不完好或许不当之处,最初的回复才干够、也应该被纠正。一起,作为供给帮忙者能够得到一些奖赏,奖赏便是他的能力和学识被其他同行看到。

当你要求暗里回复时,这个过程和奖赏都被中止。别这样做,让回复者来决定是否暗里答复 —— 假如他真这么做了,一般是由于他以为问题编写太差或许太浅薄,以至于不或许使其他人发生兴趣。

这条规则存在一条有限的例外,假如你坚信发问或许会引来大量雷同的回复时,那么这个神奇的发问句会是向我发电邮,我将为论坛概括这些回复。试着将邮件列表或新闻群组从洪水般的雷同回复中解救出来是十分有礼貌的 —— 但你必须信守诺言。

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

漫无边际的发问是近乎无休无止的时刻黑洞。最有或许给你有用答案的人一般也正是最忙的人(他们忙是由于要亲自完成大部分作业)。这样的人对无节制的时刻黑洞相当讨厌,所以他们也倾向于讨厌那些漫无边际的发问。

假如你明晰表述需求答复者做什么(如供给点拨、发送一段代码、检查你的补丁、或是其他等等),就最有或许得到有用的答案。由于这会定出一个时刻和精力的上限,便于答复者能集中精力来帮你。这么做很棒。

要了解专家们所处的世界,请把专业技能想像为充裕的资源,而回复的时刻则是稀缺的资源。你要求他们奉献的时刻越少,你越有或许从真实专业并且很忙的专家那里得到解答。

所以,界定一下你的问题,使专家花在辨识你的问题和答复所需求付出的时刻减到最少,这技巧对你有用答案相当有帮忙 —— 但这技巧一般和简化问题有所区别。因而,问我想更好地了解 X,可否点拨一下哪有好一点阐明?一般比问你能解释一下 X 吗?更好。假如你的代码不能运作,一般请他人看看哪里有问题,比要求他人替你改正要明智得多。

询问有关代码的问题时

别要求他人帮你调试有问题的代码,不提示一下应该从何下手。粘贴几百行的代码,然后说一声:它不能作业会让你完全被疏忽。只贴几十行代码,然后说一句:在第七行今后,我期待它显示,但实践呈现的是比较有或许让你得到回应。

最有效描绘程序问题的办法是供给最精简的 Bug 展示测试用例(bug-demonstrating test case)。什么是最精简的测试用例?那是问题的缩影;一小个程序片段能刚好展示出程序的异常行为,而不包括其他令人分散留意力的内容。怎样制作最精简的测试用例?假如你知道哪一行或哪一段代码会造成异常的行为,复制下来并参加足够重现这个状况的代码(例如,足以让这段代码能被编译/直译/被应用程序处理)。假如你无法将问题缩减到一个特定区块,就复制一份代码并移除不影响发生问题行为的部分。总之,测试用例越小越好(检查话不在多而在精一节)。

一般而言,要得到一段相当精简的测试用例并不太简单,但永久先测验这样做的是种好习惯。这种方式能够帮忙你了解怎样自行处理这个问题 —— 并且即使你的测验不成功,黑客们也会看到你在测验取得答案的过程中付出了尽力,这能够让他们更愿意与你合作。

假如你仅仅想让他人帮忙审查(Review)一下代码,在信的最初就要说出来,并且一定要提到你以为哪一部分特别需求重视以及为什么。

别把自己家庭作业的问题贴上来

黑客们很擅长分辩哪些问题是家庭作业式的问题;由于咱们中的大多数都曾自己处理这类问题。同样,这些问题得由来搞定,你会从中学到东西。你能够要求给点提示,但别要求得到完好的处理计划。

假如你置疑自己碰到了一个家庭作业式的问题,但仍然无法处理,试试在用户群组,论坛或(最后一招)在项意图用户邮件列表或论坛中发问。尽管黑客们看出来,但一些有经验的用户或许仍会给你一些提示。

去掉无意义的发问句

防止用无意义的话结束发问,例如有人能帮我吗?或许这有答案吗?

首先:假如你对问题的描绘不是很好,这样问更是弄巧成拙。

其次:由于这样问是弄巧成拙,黑客们会很厌烦你 —— 并且一般会用逻辑上正确,但毫无意义的答复来表明他们的鄙视, 例如:没错,有人能帮你或许不,没答案

一般来说,防止用 是或否对或错有或没有类型的问句,除非你想得到是或否类型的答复

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

这是你的问题,不是咱们的。宣称紧迫极有或许事与愿违:大多数黑客会直接删去无礼和自私地妄图即时引起重视的问题。更严重的是,紧迫这个字(或是其他妄图引起重视的标题)一般会被垃圾信过滤器过滤掉 —— 你希望能看到你问题的人或许永久也看不到。

有半个例外的情况是,假如你是在一些很高调,会使黑客们兴奋的地方,或许值得这样去做。在这种情况下,假如你有时刻压力,也很有礼貌地提到这点,人们或许会有兴趣答复快一点。

当然,这危险很大,由于黑客们兴奋的点八成与你的不同。譬如从 NASA 国际空间站(International Space Station)发这样的标题没有问题,但用自我感觉杰出的慈善行为或政治原因发肯定不行。事实上,粘贴比如紧迫:帮我救救这个毛茸茸的小海豹!肯定让你被黑客疏忽或惹恼他们,即使他们以为毛茸茸的小海豹很重要。

假如你觉得这点很不行思议,最好再把这份攻略剩下的内容多读几遍,直到你弄懂了再发文。

礼多人不怪,并且有时还很有帮忙

彬彬有礼,多用谢谢您的重视,或谢谢你的照顾。让大家都知道你对他们花时刻免费供给帮忙心存感谢。

坦白说,这一点并没有比运用明晰、正确、精准且符合语法和防止运用专用格局重要(也不能取而代之)。黑客们一般宁可读有点唐突但技术上鲜明的 Bug 陈述,而不是那种有礼但含糊的陈述。(假如这点让你不解,记住咱们是按问题能教给咱们什么来点评问题的价值的)

然而,假如你有一串的问题待处理,客气一点肯定会增加你得到有用回应的时机。

(咱们留意到,自从本攻略发布后,从资深黑客那里得到的唯一严重缺点反馈,便是对预先道谢这一条。一些黑客觉得先谢了意味着事后就不必再感谢任何人的暗示。咱们的主张是要么先说先谢了然后事后再对回复者表明感谢,或许换种方式表达感谢,譬如用谢谢你的重视谢谢你的照顾。)

问题处理后,加个简短的弥补阐明

问题处理后,向一切帮忙过你的人发个阐明,让他们知道问题是怎样处理的,并再一次向他们表明感谢。假如问题在新闻组或许邮件列表中引起了广泛重视,应该在那里贴一个阐明比较恰当。

最理想的方式是向最初发问的论题回复此音讯,并在标题中包括已修正已处理或其它同等含义的显着标记。在人来人往的邮件列表里,一个看见评论串问题 X问题 X - 已处理的潜在回复者就明白不必再糟蹋时刻了(除非他个人觉得问题 X的风趣),因而能够使用此时刻去处理其它问题。

弥补阐明不必很长或是很深入;简单的一句你好,原来是网线出了问题!谢谢大家 – Bill比什么也不说要来的好。事实上,除非结论真的很有技术含量,不然简短可爱的小结比长篇大论更好。阐明问题是怎样处理的,但大可不必将处理问题的过程复述一遍。

关于有深度的问题,粘贴调试记载的摘要是有帮忙的。描绘问题的最终状态,阐明是什么处理了问题,在此之后才指明能够防止的盲点。防止盲点的部分应放在正确的处理计划和其它总结材料之后,而不要将此信息搞成侦探推理小说。列出那些帮忙过你的名字,会让你交到更多朋友。

除了有礼貌和有内涵以外,这种类型的弥补也有助于他人在邮件列表/新闻群组/论坛中查找到真实处理你问题的计划,让他们也从中受益。

至少,这种弥补有助于让每位参与帮忙的人因问题的处理而从中得到满意感。假如你自己不是技术专家或许黑客,那就信任咱们,这种感觉关于那些你向他们求助的大师或许专家而言,是十分重要的。问题悬而未决会让人灰心;黑客们渴望看到问题被处理。好人有好报,满意他们的渴望,你会在下次发问时尝到甜头。

考虑一下怎样才干防止他人将来也遇到相似的问题,自问写一份文件或加个常见问题(FAQ)会不会有帮忙。假如是的话就将它们发给维护者。

在黑客中,这种杰出的后继行动实践上比传统的礼节更为重要,也是你怎样透过善待他人而赢得声誉的方式,这是十分有价值的资产。

怎样解读答案 ### RTFM 和 STFW:怎样知道你已完全搞砸了

有一个古老而崇高的传统:假如你收到RTFM(Read The Fucking Manual)的回应,答复者以为你应该去读他妈的手册。当然,基本上他是对的,你应该去读一读。

RTFM 有一个年轻的亲戚。假如你收到STFW(Search The Fucking Web)的回应,答复者以为你应该到他妈的网上查找。那人八成也是对的,去查找一下吧。(更温和一点的说法是 Google 是你的朋友!)

在论坛,你也或许被要求去爬爬论坛的旧文。事实上,有人甚至或许热心地为你供给曾经处理此问题的评论串。但不要依赖这种照顾,发问前应该先查找一下旧文。

一般,用这两句之一答复你的人会给你一份包括你需求内容的手册或许一个网址,并且他们打这些字的时分也正在读着。这些答复意味着答复者以为

  • 你需求的信息十分简单取得
  • 你自己去查找这些信息比灌给你,能让你学到更多

你不应该因而不爽;按照黑客的规范,他现已表明了对你一定程度的重视,而没有对你的要求视而不见。你应该对他祖母般的慈祥表明感谢。

假如仍是搞不懂

假如你看不懂回应,别马上要求对方解释。像你曾经试着自己处理问题时那样(使用手册,FAQ,网络,身边的高手),先试着去搞懂他的回应。假如你真的需求对方解释,记得表现出你现已从中学到了点什么。

比方说,假如我答复你:看来似乎是 zentry 卡住了;你应该先铲除它。,然后,这是一个很糟的后续问题回应:zentry 是什么? 的问法应该是这样:哦~~~我看过阐明了可是只有 -z 和 -p 两个参数中提到了 zentries,并且还都没有清楚的解释怎样铲除它。你是指这两个中的哪一个吗?仍是我看漏了什么?

处理无礼的回应

许多黑客圈子中看似无礼的行为并不是居心得罪。相反,它是直截了当,一针见血式的沟通风格,这种风格更注重处理问题,而不是使人感觉舒服而却模模糊糊。

假如你觉得被得罪了,试着平静地反响。假如有人真的做了出格的事,邮件列表、新闻群组或论坛中的前辈八成会招呼他。假如这没有发生而你却发火了,那么你发火对象的言语或许在黑客社区中看起来是正常的,而将被视为有错的一方,这将伤害到你获取信息或帮忙的时机。

另一方面,你偶尔真的会碰到无礼和无聊的言行。与上述相反,对真实的得罪者狠狠地打击,用犀利的言语将其驳得体无完肤都是能够接受的。然而,在行事之前一定要十分十分的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔,黑客们自己鲁莽地越线的情况并不鲜见。假如你是新手或外人,避开这种鲁莽的时机并不高。假如你想得到的是信息而不是消磨时光,这时最好不要把手放在键盘上以免冒险。

(有些人断言许多黑客都有轻度的自闭症或亚斯伯格综合症,缺少用于光滑人类社会正常交往所需的神经。这既或许是真也或许是假的。假如你自己不是黑客,兴许你以为咱们脑袋有问题还能帮忙你应付咱们的古怪行为。只管这么干好了,咱们不在乎。咱们喜欢咱们现在这个样子,并且一般对病患标记都有站得住脚的置疑。)

Jeff Bigler 的调查总结和这个相关也值得一读 (tact filters)。

在下一节,咱们会谈到另一个问题,当行为不当时所会遭到的得罪

怎样防止扮演失败者

在黑客社区的论坛中,你以本攻略所描绘的或相似的方式,或许会有那么几次搞砸了。而你会在揭露场合中被告知你是怎样搞砸的,或许攻击的言语中还会带点夹七夹八的颜色。

这种事发生今后,你能做的最糟糕的事莫过于哀嚎你的遭遇、宣称被言语攻击、要求抱歉、高声尖叫、憋闷气、要挟诉诸法律、向其雇主报怨、不去关马桶盖等等。相反地,你该这么做:

熬过去,这很正常。事实上,它是有益健康且合理的。

社区的规范不会自行保持,它们是经过参与者积极而揭露地执行来保持的。不要哭嚎一切的批评都应该经过暗里的邮件传送,它不是这样运作的。当有人评论你的一个说法有误或许提出不同看法时,坚持宣称遭到个人攻击也毫无益处,这些都是失败者的态度。

也有其它的黑客论坛,受过高礼节要求的误导,禁止参与者粘贴任何对他人帖子挑缺点的音讯,并宣称假如你不想帮忙用户就闭嘴。 成果造成有想法的参与者纷纷脱离,这么做只会使它们沦为毫无意义的唠叨与无用的技术论坛。

夸张的讲法是:你要的是“友善”(以上述方式)仍是有用?两个里面挑一个。

记着:当黑客说你搞砸了,并且(无论多么刺耳)告知你别再这样做时,他正在为关心他的社区而行动。对他而言,不睬你并将你从他的日子中滤掉更简单。假如你无法做到感谢,至少要表现得有点尊严,别大声哀嚎,也别由于自己是个有戏剧性超级敏感的魂灵和自以为有资格的新来者,就指望他人像对待软弱的洋娃娃那样对你。

有时分,即使你没有搞砸(或许仅仅在他的想像中你搞砸了),有些人也会无缘无故地攻击你本人。在这种情况下,抱怨倒是真的会把问题搞砸。

这些来找麻烦的人要么是毫无办法但自以为是专家的不中用家伙,要么便是测试你是否真会搞砸的心理专家。其它读者要么不睬睬,要么用自己的方式对付他们。这些来找麻烦的人在给他们自己找麻烦,这点你不必操心。

也别让自己卷进口水战,最好不要答理大多数的口水战 —— 当然,这是在你检验它们仅仅口水战,并且未指出你有搞砸的地方,一起也没有巧妙地将问题真实的答案藏于其后(这也是有或许的)。

不该问的问题

以下是几个经典蠢问题,以及黑客没答复时心中所想的:

问题:我能在哪找到 X 程序或 X 资源?

问题:我怎样用 X 做 Y?

问题:怎样设定我的 shell 提示?

问题:我能够用 Bass-o-matic 文件转换东西将 AcmeCorp 文件转换为 TeX 格局吗?

问题:我的程序/设定/SQL 句子没有用

问题:我的 Windows 电脑有问题,你能帮我吗?

问题:我的程序不会动了,我以为系统东西 X 有问题

问题:我在装置 Linux(或许 X )时有问题,你能帮我吗?

问题:我怎样才干破解 root 帐号/盗取 OP 特权/读他人的邮件呢?

— > 问题:我能在哪找到 X 程序或 X 资源?

答复:就在我找到它的地方啊,白痴 —— 查找引擎的那一头。天哪!莫非还有人不会用 Google 吗? > 问题:我怎样用 X 做 Y?

答复:假如你想处理的是 Y ,发问时别给出或许并不恰当的办法。这种问题阐明发问者不但对 X 完全无知,也对 Y 要处理的问题糊涂,还被特定形势禁锢了思维。最好疏忽这种人,等他们把问题搞清楚了再说。 >问题:怎样设定我的 shell 提示??

答复:假如你有足够的智慧提这个问题,你也该有足够的智慧去 RTFM,然后自己去找出来。 > 问题:我能够用 Bass-o-matic 文件转换东西将 AcmeCorp 文件转换为 TeX 格局吗?

答复:试试看就知道了。假如你试过,你就知道了答案,就不必糟蹋我的时刻了。 > 问题:我的{程序/设定/SQL 句子}没有用

答复:这不算是问题吧,我对要我问你二十个问题才找得出你真实问题的问题没兴趣 —— 我有更有意思的事要做呢。在看到这类问题的时分,我的反响一般不外如下三种

  • 你还有什么要弥补的吗?
  • 真糟糕,希望你能搞定。
  • 这关我屁事? > 问题:我的 Windows 电脑有问题,你能帮我吗?

答复:能啊,扔掉微软的垃圾,换个像 Linux 或 BSD 的开源操作系统吧。

留意:假如程序有官方版 Windows 或许与 Windows 有互动(如 Samba),你能够问与 Windows 相关的问题,仅仅别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶, 由于 Windows 一般来说实在太烂,这种说法一般都是对的。 > 问题:我的程序不会动了,我以为系统东西 X 有问题

答复:你完全有或许是第一个留意到被成千上万用户反复运用的系统调用与函数库文件有显着缺点的人,更有或许的是你完全没有根据。不同凡响的说法需求不同凡响的证据,当你这样宣称时,你必须有清楚而详尽的缺点阐明文件作后盾。 > 问题:我在装置 Linux(或许 X )时有问题,你能帮我吗?

答复:不能,我只有亲自在你的电脑上动手才干找到缺点。仍是去找你当地的 Linux 运用群组者寻求实践的指导吧(你能在这儿找到用户群组的清单)。

留意:假如装置问题与某 Linux 的发行版有关,在它的邮件列表、论坛或本地用户群组中发问或许是恰当的。此时,应描绘问题的精确细节。在此之前,先用 Linux一切被置疑的硬件作关键词仔细查找。 > 问题:我怎样才干破解 root 帐号/盗取 OP 特权/读他人的邮件呢?

答复:想要这样做,阐明了你是个卑鄙小人;想找个黑客帮你,阐明你是个白痴!

好问题与蠢问题

最后,我将透过举一些例子,来阐明怎样聪明的发问;同一个问题的两种问法被放在一起,一种是愚笨的,另一种才是明智的。

蠢问题

我能够在哪儿找到关于 Foonly Flurbamatic 的材料?

这种问法无非想得到 STFW 这样的答复。

聪明问题

我用 Google 查找过 “Foonly Flurbamatic 2600”,可是没找到有用的成果。谁知道上哪儿去找对这种设备编程的材料?

这个问题现已 STFW 过了,看起来他真的遇到了麻烦。

蠢问题

我从 foo 项目找来的源码没法编译。它怎样这么烂?

他觉得都是他人的错,这个高傲自大的发问者。

聪明问题

foo 项目代码在 Nulix 6.2 版下无法编译经过。我读过了 FAQ,但里面没有提到跟 Nulix 有关的问题。这是我编译过程的记载,我有什么做的不对的地方吗?

发问者现已指明了环境,也读过了 FAQ,还列出了过错,并且他没有把问题的责任推到他人头上,他的问题值得被重视。

蠢问题

我的主机板有问题了,谁来帮我?

某黑客对这类问题的答复一般是:好的,还要帮你拍拍背和换尿布吗?,然后按下删去键。

聪明问题

我在 S2464 主机板上试过了 X 、 Y 和 Z ,但没什么作用,我又试了 A 、 B 和 C 。请留意当我测验 C 时的奇怪现象。显然 florbish 正在 grommicking,但成果出人意料。一般在 Athlon MP 主机板上引起 grommicking 的原因是什么?有谁知道接下来我该做些什么测试才干找出问题?

这个家伙,从另一个角度来看,值得去答复他。他表现出了处理问题的能力,而不是坐等天上掉答案。

在最后一个问题中,留意告知我答案给我启示,指出我还应该做什么确诊作业之间微妙而又重要的区别。

事实上,后一个问题源自于 2001 年 8 月在 Linux 内核邮件列表(lkml)上的一个真实的发问。我(Eric)便是那个提出问题的人。我在 Tyan S2464 主板上调查到了这种无法解释的锁定现象,列表成员们供给了处理这一问题的重要信息。

经过我的发问办法,我给了他人能够咀嚼玩味的东西;我设法让人们很简单参与并且被吸引进来。我显示了自己具备和他们同等的能力,并邀请他们与我共同讨论。经过告知他们我所走过的弯路,以防止他们再糟蹋时刻,我也表明了对他们宝贵时刻的尊重。

事后,当我向每个人表明感谢,并且赞赏这次杰出的评论经历的时分,一个 Linux 内核邮件列表的成员表明,他觉得我的问题得到处理并非由于我是这个列表中的人,而是由于我用了正确的方式来发问。

黑客从某种角度来说是拥有丰厚知识但缺乏人情味的家伙;我信任他是对的,假如我个乞讨者那样发问,不论我是谁,一定会惹恼某些人或许被他们忽视。他主张我记下这件事,这直接导致了本攻略的呈现。

假如得不到答复

假如仍得不到答复,请不要以为咱们觉得无法帮忙你。有时仅仅看到你问题的人不知道答案罢了。没有回应不代表你被忽视,尽管不行否认这种不同很难区分。

总的来说,简单的重复粘贴问题是个很糟的点子。这将被视为无意义的喧哗。有点耐心,知道你问题答案的人或许日子在不同的时区,或许正在睡觉,也有或许你的问题一开始就没有组织好。

你能够经过其他途径取得帮忙,这些途径一般更适合初学者的需求。

有许多网上的以及本地的用户群组,由热情的软件爱好者(即使他们或许从没亲自写过任何软件)组成。一般人们组建这样的团体来互相帮忙并帮忙新手。

另外,你能够向许多商业公司寻求帮忙,不论公司大仍是小。别为要付费才干取得帮忙而感到沮丧!毕竟,假使你的汽车发动机汽缸密封圈爆掉了 —— 完全或许如此 —— 你还得把它送到修车铺,并且为维修付费。就算软件没花费你一分钱,你也不能强求技术支撑总是免费的。

对像是 Linux 这种大众化的软件,每个开发者至少会对应到上万名用户。根本不或许由一个人来处理来自上万名用户的求助电话。要知道,即使你要为这些帮忙付费,和你所购买的同类软件相比,你所付出的也是微乎其微的(一般封闭源代码软件的技术支撑费用比开源软件的要高得多,且内容也没那么丰厚)。

怎样更好地答复问题

态度和善一点。 问题带来的压力常使人显得无礼或愚笨,其实并不是这样。

对初犯者暗里回复。 对那些坦诚犯错之人没有必要当众侮辱,一个真实的新手或许连怎样查找或在哪找常见问题都不知道。

假如你不确定,一定要说出来! 一个听起来权威的过错回复比没有还要糟,别由于听起来像个专家很好玩,就给他人乱指路。要谦善和诚实,给发问者与同行都树个好榜样。

假如帮不了忙,也别阻碍他。 不要在实践过程上开玩笑,那样或许会毁了发问者的设置 —— 有些可怜的呆瓜会把它当成真的指令。

试探性的反问以引出更多的细节。 假如你做得好,发问者能够学到点东西 —— 你也能够。试试将蠢问题转变成好问题,别忘了咱们都曾是新手。

尽管对那些懒虫抱怨一声 RTFM 是合理的,但能给出文档的链接(即使仅仅主张个 Google 查找关键词)会更好。

假如你决定答复,就请给出好的答案。 当他人正在用过错的东西或办法时别主张笨拙的权宜之计(workaround),应推荐更好的东西,重新界定问题。

正面地答复问题! 假如这个发问者现已很深入的研究并且也表明现已试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到成果,答复 试试看 A 或是 B 或许 试试 X 、 Y 、 Z 、 A 、 B 、 C 并附上一个链接一点用都没有。

帮忙你的社区从问题中学习。 当回复一个好问题时,问问自己怎样修改相关文件或常见问题文件以免再次解答同样的问题?,接着再向文件维护者发一份补丁。

假如你在研究一番后才作出了答复,展现你的技巧而不是直接端出成果。毕竟授人以鱼不如授人以渔

相关资源

假如你需求个人电脑、Unix 系统和网络怎样运作的基础知识,参阅 Unix 系统和网络基本原理

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

鸣谢

Evelyn Mitchel 贡献了一些愚笨问题例子并启发了编写怎样更好地答复问题这一节, Mikhail Ramendik 贡献了一些特别有价值的主张和改善。


最后修改于 2001-08-01