diff --git a/how-to-ask-questions-the-smart-way/README.md b/how-to-ask-questions-the-smart-way/README.md index 994f000..7ae7b44 100644 --- a/how-to-ask-questions-the-smart-way/README.md +++ b/how-to-ask-questions-the-smart-way/README.md @@ -49,8 +49,8 @@ - [礼貌总是有益的](core.md#礼貌总是有益的) - [问题解决后追加一条简要说明](core.md#问题解决后追加一条简要说明) - [如何解读回答](core.md#如何解读回答) - - [『读读他妈的手册（`RTFM`）』和『搜搜他妈的网络（`STFW`）』：在告知你的问题根本不该提出来](core.md#读读他妈的手册rtfm和搜搜他妈的网络stfw在告知你的问题根本不该提出来) - - [如果还不明白……](core.md#如果还不明白) + - [『读读他妈的手册（`RTFM`）』和『搜搜他妈的网络（`STFW`）』：是在告知你的问题根本不该提出来](core.md#读读他妈的手册rtfm和搜搜他妈的网络stfw是在告知你的问题根本不该提出来) + - [如果你还是不明白……](core.md#如果你还是不明白) - [对待无礼](core.md#对待无礼) - [别像失败者那样反应](others.md#别像失败者那样反应) - [提问禁忌](others.md#提问禁忌) diff --git a/how-to-ask-questions-the-smart-way/core.md b/how-to-ask-questions-the-smart-way/core.md index c5c11d7..3c7a271 100644 --- a/how-to-ask-questions-the-smart-way/core.md +++ b/how-to-ask-questions-the-smart-way/core.md @@ -33,7 +33,8 @@ 提问时的注意 ================== -## 仔细挑选论坛 +仔细挑选论坛 +------------------- 要对在哪提问留心，如果你做了下述事情，多半会被一笔勾销或被看成『失败者』： @@ -61,7 +62,8 @@ 可以理解，老练的黑客和一些流行软件的作者正在承受过多的不当消息。就像那根最后压垮骆驼背的稻草一样， 你的加入也有可能使情况走向极端 —— 已经好几次了，一些流行软件的作者退出了对自己软件的支持，因为伴随而来的涌入其私人邮箱的垃圾邮件变得无法忍受。 -## `Stack Overflow` +`Stack Overflow` +------------------- 搜索 **_之后_** 再在`Stack Exchange`提问。 @@ -82,7 +84,8 @@ 有几个项目有自己的特定站点，包括[`Android`](http://android.stackexchange.com/)、[`Ubuntu`](http://askubuntu.com/)、[`TeX/LaTeX`](http://tex.stackexchange.com/)和[`SharePoint`](http://sharepoint.stackexchange.com/)。请检查一下`Stack Exchange`以确定现在具体有哪些站点。 -## 面向新手的论坛和互联网中继聊天（`IRC`）通常响应最快 +面向新手的论坛和互联网中继聊天（`IRC`）通常响应最快 +------------------- 本地的用户组织或者你所用的`Linux`发行版也许正在宣传新手取得帮助的论坛或`IRC`通道（在一些非英语国家，新手论坛很可能还是邮件列表），这些地方是开始提问的好去处，特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。 经过宣传的`IRC`通道是公开邀请提问的地方，通常可以得到实时的回复。 @@ -93,7 +96,8 @@ 通过论坛或`IRC`通道提供项目的用户支持有增长的趋势，电子邮件交流则更多地为项目开发者保留。所以先在论坛或`IRC`中寻求与该项目相关的帮助。 -## 第二步，使用项目的邮件列表 +第二步，使用项目的邮件列表 +------------------- 当某个项目存在开发者邮件列表时，要向列表而不是其中的个别成员提问，即使你确信他能最好地回答你的问题。查一查项目的文档和主页，找到项目的邮件列表并使用它。采用这种办法有几个很好的理由： @@ -111,7 +115,8 @@ 即便在这种情况下，也别假设项目的邮件列表不存在。在你的电子邮件中陈述你已经试过但没有找到合适的邮件列表，也提及你不反对将自己的邮件转发给他人 （许多人认为，即使没什么秘密，私人电子邮件也不应该被公开。通过允许将你的电子邮件转发他人，你给了相应人员处置你邮件的选择）。 -## 使用有意义且明确的主题 +使用有意义且明确的主题 +------------------- 在邮件列表、新闻组或论坛中，主题是你在五十个或更少的字以内吸引有资格专家注意的黄金机会，不要用诸如 『请帮我』 （更别提大写的 『请帮我！！！！』，这种主题的消息会被条件反射式地删掉）之类的唠叨浪费机会。 不要用你痛苦的深度来打动我们，相反，要在这点空间中使用超级简明扼要的问题描述。 @@ -144,7 +149,8 @@ 在论坛，因为消息与特定的线索紧密结合，并且通常在线索之外不可见，好的提问方式略有不同，通过回复提问并不要紧。不是所有论坛都允许在回复中出现分离的主题，而且这样做了基本上没有人会去看。 不过，通过回复提问本身就是令人怀疑的做法，因为它们只会被正在查看该线索的人读到。所以，除非你 **_只想_** 在该线索当前活跃的人群中提问，还是另起炉灶比较好。 -## 使问题容易回复 +使问题容易回复 +------------------- 以『请向……回复』来结束问题多半会使你得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都麻烦，我们也觉得花几秒钟考虑你的问题更麻烦。 如果你的邮件客户端程序不支持这样做，[换个好点的](http://linuxmafia.com/faq/Mail/muas.html)；如果是操作系统不支持所有这种邮件客户端程序，也换个好点的。 @@ -152,7 +158,8 @@ 在论坛，要求通过电子邮件回复是完全无礼的，除非你确信回复的信息也许是敏感的（而且有人会为了某些未知的原因，只让你而不是整个论坛知道答案）。 如果你只是想在有人回复线索时得到电子邮件提醒，可以要求论坛发送。几乎所有论坛都支持诸如『留意本线索』、『有回复发送邮件』等功能。 -## 用清晰、语法、拼写正确的语句书写 +用清晰、语法、拼写正确的语句书写 +------------------- 经验告诉我们，粗心与草率的作者通常也粗心与草率地思考和编程（我敢打赌）。为这些粗心与草率的思考者回答问题没有什么好处，我们宁可将时间花在其它地方。 @@ -177,8 +184,8 @@ * 对于这个技术术语本身我很熟悉，但对于它的一些俚语或习惯表达方式就不太明白了。 * 我已经同时用某某语及英语提问，如果您使用两者之一回复，我很乐意翻译。 -## 使用易于读取且标准的文件格式发送问题 - +使用易于读取且标准的文件格式发送问题 +------------------- 如果你人为地将问题搞得难以阅读，它多半会被忽略，人们更愿读易懂的问题，所以： @@ -197,7 +204,8 @@ 如果你使用图形用户界面的邮件客户端程序（如网景公司的`Messenger`、微软公司的`Outlook`或者其它类似的），注意它们的缺省配置不一定满足这些要求。 大多数这类程序有基于菜单的『查看源码』命令，用它来检查发送文件夹中的消息，以确保发送的是没有多余杂质的纯文本文件。 -## 描述问题应准确且有内容 +描述问题应准确且有内容 +------------------- * 仔细、清楚地描述问题的症状 * 描述问题发生的环境（主机、操作系统、应用程序，任何相关的），提供销售商的发行版和版本号（如：『`Fedora Core 7`』、『`Slackware 9.1`』等） @@ -212,20 +220,22 @@ 西蒙 · 泰瑟姆（_Simon Tatham_）写过一篇 [如何有效报告`Bug`](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html) 的文章，我强烈推荐各位阅读。 -## 量不在多，精炼则灵 +量不在多，精炼则灵 +------------------- 你应该写得精炼且有内容，简单地将一大堆代码或数据罗列在求助消息中达不到目的。如果你有一个很大且复杂的测试样例让程序崩溃，尝试将其裁剪得越小越好。 至少有三个理由支持这点。第一，让别人看到你在努力简化问题使你更有可能得到回复。 第二，简化问题使你更有可能得到 **_有用的_** 回复。第三，在提纯`Bug`报告的过程中，你可能自己就找到了解决办法或权宜之计。 -## 别急于宣称找到`Bug` +别急于宣称找到`Bug` +------------------- 当你在一个软件中遇到问题，除非你 **_非常、非常_** 的有根据，不要动辄声称找到了`Bug`。 提示：除非你能提供解决问题的源代码补丁，或者对前一版本的回归测试表现出不正确的行为，否则你都多半不够完全确信。 对于网页和文档也如此，如果你发现了文档的『`Bug`』，你应该能提供相应位置的替代文本。 -记住，还有许多其它用户并未经历你遇到的问题，否则你在阅读文档或搜索网页时就应该发现了（你在报怨前已经做了这些，[是吧](#提问前) ？）。 +记住，还有许多其它用户并未经历你遇到的问题，否则你在阅读文档或搜索网页时就应该发现了（你在报怨前已经做了这些，[是吧](#提问前的准备) ？）。 这也意味着很有可能是你弄错了而不是软件本身有问题。 编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了`Bug`，也就置疑了他们的能力，即使你是对的，也有可能会使其中的部分人感到不快。 @@ -234,7 +244,8 @@ 提问时，即使你私下非常确信已经发现一个真正的`Bug`，最好写得像是 **_你_** 做错了什么。如果真的有`Bug`，你会在回复中看到这点。 这样做的话，如果真有`Bug`，维护者就会向你道歉，这总比你弄砸了然后欠别人一个道歉要强。 -## 低声下气代替不了做自己的家庭作业 +低声下气代替不了做自己的家庭作业 +------------------- 有些人明白他们不应该粗鲁或傲慢地行事并要求得到答复，但他们退到相反的低声下气的极端： 『我知道我只是个可怜的新丁，一个失败者，但……』。这既使人困扰，也没有用，当伴随着对实际问题含糊的描述时还特别令人反感。 @@ -243,7 +254,8 @@ 有时，论坛设有单独的初学者提问版面，如果你真的认为遇到了肤浅的问题，到那去就是了，但一样别低声下气。 -## 描述问题症状而不是猜测 +描述问题症状而不是猜测 +------------------- 告诉黑客是什么导致了问题是没用的（如果你的诊断理论是了不起的东西，你还会向别人咨询求助吗？）。 所以，确保只是告诉他们问题的原始症状，而不是你的解释和理论，让他们来解释和诊断。如果你认为陈述自己的猜测很重要，应清楚地说明这只是你的猜测并描述为什么它们不起作用。 @@ -262,7 +274,8 @@ 『我来自一个出产玉米、棉花、牛蒡和民主党人的国家，滔滔雄辩既不能说服我，也不会让我满意。我来自密苏里州，你必须让我看看。』） 针对诊断者而言，这并不是怀疑，而只是一种真实而有用的需求，以便让他们看到与你看到的原始证据尽可能一致的东西，而不是你的猜测与总结。所以，让我们看看。 -## 按时间先后罗列问题症状 +按时间先后罗列问题症状 +------------------- 刚出问题之前发生的事情通常包含有解决问题最有效的线索。所以，记录中应准确地描述你、电脑和软件在崩溃前都做了什么。 在命令行处理的情况下，有会话日志（如运行脚本工具生成的）并引用相关的若干（如20）行记录会非常有帮助。 @@ -272,7 +285,8 @@ 如果你的记录很长（如超过四段），在开头简述问题随后按时间先后罗列详细过程也许更有用。这样，黑客在读你的记录时就知道该注意哪些内容了。 -## 描述目标而不是过程 +描述目标而不是过程 +------------------- 如果你想弄清楚如何做某事（而不是报告一个`Bug`），在开头就描述你的目标，然后才陈述遇到问题的特定步骤。 @@ -288,7 +302,8 @@ 第二种提法是明智的，它使得建议采用更合适的工具以完成任务的回复成为可能。 -## 别要求私下回复电邮 +别要求私下回复电邮 +------------------- 黑客们认为问题的解决过程应该公开、透明，此过程中如果更有才能的人注意到不完整或者不当之处，最初的回复才能够、也应该被纠正。同时，作为回复者也因为能力和学识被其它同行看到而得到某种回报。 @@ -297,7 +312,8 @@ 对这条规则存在一条有限的例外，如果你确信提问可能会引来大量雷同的回复时，那么『向我发电邮，我将为论坛归纳这些回复』将是神奇的句子。 试着将邮件列表或新闻组从洪水般雷同的回复中解救出来是非常有礼貌的 —— 但你必须信守诺言。 -## 提问应明确 +提问应明确 +------------------- 漫无边际的问题通常也被视为没有明确限制的时间无底洞。 最有可能给你有用答案的人通常也是最忙的人（假如只是因为他们承担了太多工作的话），这些人对于没有止境的时间无底洞极其敏感，所以他们也倾向于讨厌那些漫无边际的问题。 @@ -310,7 +326,8 @@ 所以限定你的问题以使专家回答时需要付出的时间最少 —— 这通常与简化问题还不太一样。 举个例，『请问可否指点一下哪有好一点的 X 解释？』通常要比『请解释一下 X』明智。如果你的代码不运行了，通常请别人看看哪有问题比叫他们帮你改正更明智。 -## 关于代码的问题 +关于代码的问题 +------------------- 别要求他人给你出问题的代码排错而不提及应该从何入手。张贴几百行的代码，然后说一声『它不能运行』会让你得不到理睬。 只贴几十行代码，然后说一句『在第七行以后，本应该显示，但实际出现的是』非常有可能让你得到回复。 @@ -325,21 +342,23 @@ 如果你只是想让别人帮忙审一下代码，在最开头就要说出来，并且一定要提到你认为哪一部分特别需要关注以及为什么。 -## 别张贴家庭作业式问题 +别张贴家庭作业式问题 +------------------- 黑客们善于发现『家庭作业』式的问题。我们中的大多数人已经做了自己的家庭作业，那是该 **_你_** 做的，以便从中学到东西。问一下提示没有关系，但不是要求完整的解决方案。 如果你怀疑自己碰到了一个家庭作业式的问题，但仍然无法解决，试试在用户组、论坛或（作为最后一招）在项目的『用户』邮件列表或论坛中提问。尽管黑客们 **_会_** 看出来，一些老用户也许仍会给你提示。 -## 删除无意义的要求 - +删除无意义的要求 +------------------- 抵制这种诱惑，即在求助消息末尾加上诸如『有人能帮我吗？』或『有没有答案？』之类在语义上毫无意义的东西。 第一，如果问题描述还不完整，这些附加的东西最多也只能是多余的。第二，因为它们是多余的，黑客们会认为这些东西烦人 —— 就很有可能用逻辑上无误但打发人的回复，诸如『是的，你可以得到帮助』和『不，没有给你的帮助』。 一般来说，避免提『是或否』类型的问题，除非你想得到 [『是或否』类型的回答](http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/questions-with-yes-or-no-answers.html)。 -## 不要把问题标记为『紧急』，即使对你而言的确如此 +不要把问题标记为『紧急』，即使对你而言的确如此 +------------------- 这是你的问题，不要我们的。宣称『紧急』极有可能事与愿违： 大多数黑客会直接删除这种消息，他们认为这是无礼和自私地企图得到即时与特殊的关照。而且『紧急』或其它有类似含义的主题有可能触发垃圾过滤规则，潜在的回复者可能永远看不到你的问题！ @@ -352,7 +371,8 @@ 如果你觉得这不可思议，再把剩下的内容多读几遍，直到弄懂了再发贴也不迟。 -## 礼貌总是有益的 +礼貌总是有益的 +------------------- 礼貌一点，使用『请』和『谢谢你的关注』或者『谢谢你的关照』，让别人明白你感谢他们无偿花时间帮助你。 @@ -364,7 +384,8 @@ （我们必须指出，本文唯一受到一些老黑客认真反对的地方是以前曾经推荐过的『提前谢了』，一些黑客认为这隐含着事后不用再感谢任何人的暗示。 我们的建议是要么先说 『提前谢了』，事后 **_再_** 对回复者表示感谢，要么换种方式表达，譬如用『谢谢你的关注』或『谢谢你的关照』）。 -## 问题解决后追加一条简要说明 +问题解决后追加一条简要说明 +------------------- 问题解决后向所有帮助过的人追加一条消息，让他们知道问题是如何解决的并再次感谢。如果问题在邮件列表或新闻组中受到广泛关注，在那里追加此消息比较恰当。 @@ -389,7 +410,8 @@ 如何解读回答 ================== -## 『读读他妈的手册（`RTFM`）』和『搜搜他妈的网络（`STFW`）』：在告知你的问题根本不该提出来 +『读读他妈的手册（`RTFM`）』和『搜搜他妈的网络（`STFW`）』：是在告知你的问题根本不该提出来 +------------------- 有一个古老而神圣的传统：如果你收到『读读他妈的手册（`RTFM`）』的回复，发信人认为你应该去『读读他妈的手册』。他或她多半是对的，去读一下吧。 @@ -401,14 +423,16 @@ 你不应该觉得这样就被冒犯了，按黑客的标准，回复者没有不理你就是在向你表示某种尊敬，你反而应该感谢他热切地想帮助你。 -## 如果还不明白…… +如果你还是不明白…… +------------------- 如果你看不懂回答，不要马上回复一个要求说明的消息，先试试那些最初提问时用过的相同工具（如手册、`FAQ`、网页、懂行的朋友等）试着搞懂回答。如果还是需要说明，展现你已经明白的。 譬如，假如我告诉你：『看起来像是某输入项有问题，你需要清除它』，接着是个 **_不好_** 的回帖：『什么是某输入项？』。 而这是一个 **_很好_** 的跟帖：『是的，我读了手册，某某输入项只在`-z`和`-p`开关中被提到，但都没有涉及到如何清除它们，你指的是哪一个还是我弄错了什么？』 -## 对待无礼 +对待无礼 +------------------- 很多黑客圈子中看似无礼的行为并不是存心冒犯。相反，它是直接了当、一针见血式的交流风格，这种风格对于更关注解决问题而不是使别人感觉舒服而混乱的人是很自然的。 diff --git a/how-to-ask-questions-the-smart-way/others.md b/how-to-ask-questions-the-smart-way/others.md index 1339b7a..db0512e 100644 --- a/how-to-ask-questions-the-smart-way/others.md +++ b/how-to-ask-questions-the-smart-way/others.md @@ -55,7 +55,7 @@ **问：** 如何配置我的`shell`提示？ **答：** -如果你有足够的智慧提这个问题，你也该有足够的智慧去 [『读读他妈的手册（`RTFM`）』](#读读他妈的手册rtfm和搜搜他妈的网络stfw如何明白你已完全搞砸)，然后自己去找出来。 +如果你有足够的智慧提这个问题，你也该有足够的智慧去 [『读读他妈的手册（`RTFM`）』](core.md#读读他妈的手册rtfm和搜搜他妈的网络stfw是在告知你的问题根本不该提出来)，然后自己去找出来。 **问：** @@ -107,7 +107,7 @@ 最后，我将通过举例来演示提问的智慧。同样的问题两种提法，一种愚蠢，另一种明智。 **愚蠢：** 我在哪能找到关于`Foonly Flurbamatic`设备的东西？ -这个问题在乞求得到 [『搜搜他妈的网络（`STFW`）』](#读读他妈的手册rtfm和搜搜他妈的网络stfw如何明白你已完全搞砸) 式的回复。 +这个问题在乞求得到 [『搜搜他妈的网络（`STFW`）』](core.md#读读他妈的手册rtfm和搜搜他妈的网络stfw是在告知你的问题根本不该提出来) 式的回复。 **明智：** 我用谷歌搜索过『`Foonly Flurbamatic 2600`』，但没有找到什么有用的，有谁知道在哪能找到这种设备的编程信息？ 这个人已经搜索过网络了，而且听起来他可能真的遇到了问题。