Eric Steven Raymond — Thyrsus Enterprises — <esr@thyrsus.com>
Rick Moen — <respond-auto@linuxmafia.com>
版权所有 © 2001, 2006, 2014 Eric S. Raymond, Rick Moen
目录
翻译版本
已有多种语言的翻译版本： 巴西葡萄牙语、 繁体中文、 捷克语、 荷兰语、 爱沙尼亚语、 法语、 格鲁吉亚语、 德语、 希腊语、 印地语、 匈牙利语、 印度尼西亚语、 日语、 立陶宛语、 波兰语、 葡萄牙语、 俄语、 西班牙语、 乌克兰语、 乌兹别克语。
如果你想复制、镜像、翻译或摘录此文档，请查阅作者的复制政策。
免责声明
许多项目网站在"如何获取帮助"部分链接了此文档。这没问题，这正是我们所希望的用途——但如果你是为你的项目页面创建此类链接的网站管理员，请在链接旁边显著注明：我们不是你项目的技术支持！
我们从痛苦的经验中得知，如果没有这样的声明，我们会不断被一些白痴骚扰，他们以为发布这篇文档就意味着解决全世界的技术问题是我们的工作。
如果你正在阅读此文档是因为你需要帮助，并且你觉得可以直接从本文的作者那里获得帮助，那么你就是我们所说的那些白痴之一。不要问我们问题。我们只会忽略你。我们在这里是为了向你展示如何从真正了解你所使用的软件或硬件的人那里获得帮助，但 99.9% 的情况下那个人不是我们。除非你确定作者之一恰好是你所遇到问题的专家，否则请不要打扰我们，这样大家都会更开心。
引言
在黑客的世界里，你得到的技术问题的回答很大程度上取决于你提问的方式，而不仅仅是问题本身的难度。本指南将教你如何以更有可能获得满意回答的方式来提问。
现在开源的使用已经非常普遍，你通常可以从其他更有经验的用户那里获得与黑客同样好的回答。这是一件好事；用户通常对新手常犯的错误会更宽容一些。不过，以我们在这里推荐的方式对待有经验的用户，通常也是从他们那里获得有用回答的最有效方法。
首先要理解的是，黑客其实喜欢难题和能引发思考的好问题。如果不是这样，我们就不会在这里了。如果你给我们一个有趣的问题来思考，我们会感谢你；好的问题是一种激励和馈赠。好的问题有助于我们加深理解，并且常常揭示我们未曾注意或思考过的问题。在黑客之间，"好问题！"是一种强烈而真诚的赞美。
尽管如此，黑客在面对简单问题时，有时看起来像是怀有敌意或傲慢。这有时看起来好像我们本能地对新手和无知者很粗鲁。但事实并非如此。
我们毫不掩饰的是，我们对那些看起来不愿思考或在提问前不愿自己做功课的人抱有敌意。这样的人是时间的黑洞——他们只索取不回馈，浪费了我们本可以用在更有趣的问题和更值得回答的人身上的时间。我们把这样的人称为"失败者"（loser），出于历史原因，有时我们也拼写成"luser"。
我们知道有很多人只是想使用我们编写的软件，对学习技术细节毫无兴趣。对大多数人来说，计算机只是一个工具，一种达到目的的手段；他们有更重要的事要做，有自己的生活要过。我们承认这一点，也不期望每个人都对让我们着迷的技术问题感兴趣。然而，我们回答问题的风格是为那些确实有此兴趣并愿意积极参与问题解决的人量身定做的。这一点不会改变。也不应该改变；如果改变了，我们在自己最擅长的事情上就会变得不那么有效。
我们（大部分）是志愿者。我们从繁忙的生活中抽出时间来回答问题，有时候我们会被问题淹没。所以我们会无情地筛选。特别是，我们会丢弃那些看起来像失败者提出的问题，以便更高效地把回答问题的时间花在赢家身上。
如果你觉得这种态度令人反感、居高临下或傲慢，请检查一下你的假设。我们并没有要求你对我们卑躬屈膝——事实上，如果你付出必要的努力，我们中的大多数人非常乐意以平等的姿态与你交流并欢迎你加入我们的文化。但是，帮助那些不愿自助的人对我们来说确实是低效的。不懂没关系；装傻就不行了。
所以，虽然你不必已经具备技术能力才能引起我们的注意，但你必须展现出一种能够通向技术能力的态度——警觉、善于思考、善于观察、愿意积极参与解决方案的开发。如果你不能接受这种区别对待，我们建议你花钱购买商业支持合同，而不是请求黑客为你免费提供帮助。
如果你决定向我们求助，你不会想成为一个失败者。你也不想看起来像一个。获得快速而有效回答的最好方法是，像一个有智慧、有信心、有线索的人那样提问——而你恰好在某个特定问题上需要帮助。
（欢迎对本指南提出改进建议。你可以将建议发至 esr@thyrsus.com 或 respond-auto@linuxmafia.com。但请注意，本文档的目的不是一般性的网络礼仪指南，我们通常会拒绝与在技术论坛中如何有效获取回答无关的建议。）
提问之前
在通过邮件、新闻组或网站聊天板发送技术问题之前，请先做以下事情：
- 尝试在你打算发帖的论坛或邮件列表的历史存档中搜索答案。
- 尝试通过搜索互联网来找到答案。
- 尝试通过阅读手册来找到答案。
- 尝试通过阅读 FAQ 来找到答案。
- 尝试通过自己检查或实验来找到答案。
- 尝试向有经验的朋友请教。
- 如果你是程序员，尝试通过阅读源代码来找到答案。
当你提出问题时，请先展示你已经做过上述这些事情；这将有助于表明你不是一个懒惰的吸血鬼，不会浪费别人的时间。更好的做法是，展示你从这些工作中学到了什么。我们喜欢回答那些已经证明自己能够从回答中学习的人的问题。
使用一些策略，比如在 Google 上搜索你得到的错误信息文本（搜索 Google Groups 以及网页）。这很可能直接把你带到修复文档或一个回答了你问题的邮件列表线程。即使找不到，在请求帮助的邮件或帖子中说"我在 Google 上搜索了以下词组但没有找到看起来有用的结果"也是件好事，至少它记录了哪些搜索不会有帮助。这也有助于将其他有类似问题的人引导到你的帖子，将搜索词与你的问题和解决方案线程联系起来。
不要急。不要指望几秒钟的 Google 搜索就能解决一个复杂的问题。在向专家求助之前，先阅读并理解 FAQ，坐下来放松一下，给问题一些思考的时间。相信我们，专家们能从你的问题中看出你做了多少阅读和思考的工作，如果你有备而来，他们会更愿意帮忙。不要因为第一次搜索没有找到答案（或找到了太多答案）就立刻发射你全部的问题。
准备好你的问题。认真想一想。草率的问题只会得到草率的回答，或者根本没有回答。你在提问前越能表现出你为解决问题所付出的思考和努力，你就越有可能真正得到帮助。
当心提出错误的问题。如果你问了一个基于错误假设的问题，某个黑客很可能会回复一个字面上正确但毫无用处的答案，同时心里想着"蠢问题……"，并希望你从"得到你要求的而不是你需要的"这个经历中吸取教训。
永远不要假定自己有权得到回答。毕竟你没有为此付费。你将通过提出一个有实质内容的、有趣的、引人思考的问题来赢得答案——这种问题隐含地为社区的经验做出贡献，而不仅仅是被动地向他人索取知识。
另一方面，表明你愿意并能够参与解决方案的开发过程是一个很好的开始。"谁能给一个指引？"、"我的示例缺少什么？"、"我应该查看哪个网站？"比"请告诉我确切的步骤"更容易得到回答，因为你表明了只要有人为你指明方向，你就真正愿意完成接下来的过程。
提问时
谨慎选择论坛
在选择提问的地方时要敏感。如果你出现以下行为，你很可能会被忽略或被视为失败者：
- 在与主题无关的论坛发帖
- 在期望高级技术问题的论坛发布非常基础的问题，反之亦然
- 在太多不同的新闻组交叉发帖
- 给与你既不相识、也对你的问题没有个人责任的人发送私人邮件
黑客会忽略那些不当投放的问题，以保护他们的交流渠道不被淹没在无关信息中。你不会希望这种事发生在你身上。
因此，第一步是找到正确的论坛。同样，Google 和其他网络搜索方法是你的好帮手。用它们找到与给你带来困难的硬件或软件最相关的项目网页。通常这个网页会有 FAQ（常见问题）列表的链接，以及项目邮件列表和存档的链接。这些邮件列表是你寻求帮助的最终去处——如果你自己的努力（包括阅读你找到的那些 FAQ）没能让你找到解决方案的话。项目网页也可能描述了 bug 报告流程，或有相关链接；如果有的话，请遵循它。
给你不熟悉的人或论坛发邮件风险很大。例如，不要假定一个信息丰富的网页的作者想成为你的免费顾问。不要对你的问题是否受欢迎做乐观的猜测——如果你不确定，就发到别处去，或者干脆不发。
在选择 Web 论坛、新闻组或邮件列表时，不要只看名字就下判断；查看 FAQ 或版规来确认你的问题是否切合主题。在发帖之前先阅读一些以前的帖子，这样你就能了解那里的行事方式。事实上，在发帖之前，在新闻组或邮件列表存档中用与你问题相关的关键词搜索是一个非常好的主意。它可能为你找到答案，即使找不到，也能帮你形成一个更好的问题。
不要把所有可用的帮助渠道同时轰炸一遍，这就像大声喊叫，会惹恼别人。要一步一步轻声细语地来。
要知道你的话题是什么！经典错误之一是在致力于跨平台语言、库或工具的论坛中提出关于 Unix 或 Windows 编程接口的问题。如果你不明白为什么这是个错误，在搞明白之前最好不要提任何问题。
一般来说，在一个精心选择的公共论坛中提问，比在私人论坛中提出同样的问题更有可能得到有用的回答。这有多个原因。一个是潜在回答者的数量更多。另一个是受众更多；黑客宁愿回答能教育许多人的问题，而不是只对少数人有用的问题。
可以理解，熟练的黑客和流行软件的作者已经收到了超过他们应得份额的错误投递的消息。你的加入可能成为压垮骆驼的最后一根稻草——曾有不少流行项目的贡献者撤回了他们的支持，因为涌入他们个人邮箱的无用邮件已经让他们无法忍受。
Stack Overflow
先搜索，再到 Stack Exchange 提问。
近年来，Stack Exchange 社区网站群已成为回答技术及其他问题的主要资源，甚至是许多开源项目的首选论坛。
先用 Google 搜索，再去看 Stack Exchange；Google 对其进行实时索引。很有可能已经有人问过类似的问题了，而且 Stack Exchange 网站通常在搜索结果的前列。如果通过 Google 没有找到任何东西，再到与你问题最相关的特定网站上搜索（见下文）。使用标签搜索可以帮助缩小结果范围。
如果你仍然没有找到任何东西，请将你的问题发布到最切合主题的那一个网站上。使用格式化工具，尤其是代码格式化，并添加与你问题实质相关的标签（特别是你遇到问题的编程语言、操作系统或库的名称）。如果有评论者向你要求更多信息，编辑你的原始帖子来补充。如果任何回答有帮助，点击向上箭头投票赞同；如果某个回答解决了你的问题，点击投票箭头下方的对勾标记将其接受为正确答案。
Stack Exchange 已经发展到超过 100 个站点，以下是最可能相关的几个：
- Super User 用于一般计算问题。如果你的问题与代码无关，也不是关于只通过网络连接交互的程序，那它可能属于这里。
- Stack Overflow 用于编程问题。
- Server Fault 用于服务器和网络管理问题。
有些项目有自己专门的站点，包括 Android、Ubuntu、TeX/LaTeX 和 SharePoint。请查看 Stack Exchange 网站以获取最新列表。
Web 和 IRC 论坛
你当地的用户组或你的 Linux 发行版可能会有一个 Web 论坛或 IRC 频道供新手获取帮助。（在非英语国家，新手论坛仍然更可能是邮件列表。）这些是很好的首选求助地点，尤其是当你认为自己遇到的是一个相对简单或常见的问题时。公开宣传的 IRC 频道就是一个公开的邀请，你可以在那里提问，通常能实时得到回答。
事实上，如果导致问题的程序是你从 Linux 发行版获得的（这在今天很常见），在尝试程序的项目论坛/列表之前，在发行版的论坛/列表中提问可能更好。项目的黑客可能只会说"用我们的构建版本"。
在任何 Web 论坛发帖之前，先检查它是否有搜索功能。如果有的话，尝试用与你问题相关的关键词搜索几次；这可能会有帮助。如果你之前做过通用的 Web 搜索（你应该做过），仍然要搜索论坛本身；你的全网搜索引擎可能没有最近索引过这个论坛的所有内容。
项目越来越倾向于通过 Web 论坛或 IRC 频道提供用户支持，而将邮件更多地保留给开发流量。所以在寻求特定项目的帮助时，先找这些渠道。
在 IRC 中，最好不要一上来就在频道里倾倒一长段问题描述；有些人会将此视为刷屏。最好用一句话描述问题，以此来引发频道里的对话。
第二步，使用项目邮件列表
当一个项目有开发邮件列表时，即使你认为你知道谁能最好地回答你的问题，也应该写给邮件列表而不是个人开发者。查看项目的文档和主页以找到项目邮件列表的地址，然后使用它。这个策略有几个好理由：
- 任何值得向一个开发者提出的好问题，对整个团队同样有价值。反过来，如果你怀疑自己的问题对邮件列表来说太傻了，这也不是骚扰个人开发者的借口。
- 在列表中提问可以将负载分散到开发者之间。个别开发者（尤其是项目负责人）可能太忙了，无法回答你的问题。
- 大多数邮件列表都有存档，并且存档会被搜索引擎索引。如果你在列表中提问并得到了回答，未来的提问者可以在网上找到你的问题和答案，而不用再问一遍。
- 如果某些问题经常被问到，开发者可以利用这些信息来改进文档或软件本身，使其不那么令人困惑。但如果这些问题都是私下提出的，就没有人能全面了解哪些问题最常被问到。
如果一个项目同时有"用户"和"开发者"（或"黑客"）邮件列表或 Web 论坛，而你又不是在修改代码，那就在"用户"列表/论坛中提问。不要假定你在开发者列表上会受到欢迎，在那里你的问题可能被视为干扰开发者交流的噪音。
然而，如果你确定你的问题不简单，并且在"用户"列表/论坛中几天都没有得到回答，可以尝试"开发者"列表。建议你在发帖之前先在那里潜水几天——或者至少查看最近几天的存档消息——以了解当地的行事规则（实际上这在任何私有或半私有列表上都是好建议）。
如果你找不到项目的邮件列表地址，只能看到项目维护者的地址，那就直接写信给维护者。但即使在这种情况下，也不要假定邮件列表不存在。在你的邮件中提到你试图寻找但找不到合适的邮件列表。同时提到你不反对你的邮件被转发给其他人。（许多人认为私人邮件应该保持私密，即使内容没有任何秘密。通过允许你的消息被转发，你给了你的通信对象一个关于如何处理你邮件的选择。）
使用有意义且具体的标题
在邮件列表、新闻组或 Web 论坛中，标题是你吸引合格专家注意力的黄金机会——大约 50 个字符以内。不要把它浪费在诸如"请帮帮我"这样的废话上（更不用说"请帮帮我！！！！"；标题是这样的消息会被条件反射地丢弃）。不要试图用你的痛苦深度来打动我们；请用这个空间来做一个超级简洁的问题描述。
一个很好的标题惯例是"对象——偏差"，被许多技术支持组织使用。"对象"部分指出是什么东西或哪一组东西出了问题，"偏差"部分描述与预期行为的偏差。
蠢问题：
救命！视频在我的笔记本上不能正常工作！
聪明的问题：
X.org 6.8.1 鼠标光标变形，Fooware MV1005 显卡芯片组
更聪明的问题：
X.org 6.8.1 鼠标光标在 Fooware MV1005 显卡芯片组上变形
写一个"对象——偏差"式描述的过程将帮助你更详细地组织对问题的思考。什么受到了影响？只是鼠标光标还是其他图形也是？这是 X.org 版本的 X 特有的吗？是 6.8.1 版本特有的吗？这是 Fooware 显卡芯片组特有的吗？是 MV1005 型号特有的吗？看到结果的黑客可以立刻明白你遇到了什么问题以及问题是什么，一目了然。
更一般地说，想象一下看着一个问题存档的索引，只能看到标题行。让你的标题充分反映你的问题，这样下一个搜索存档的人如果有类似的问题，就能根据帖子线索找到答案，而不用再发一遍。
如果你在回复中提问，请确保更改标题以表明你在提一个问题。看起来像"Re: 测试"或"Re: 新 bug"的标题不太可能吸引足够的注意力。同时，将对以前消息的引用减少到对新读者有帮助的最低限度。
不要简单地点击邮件列表消息的回复按钮来开始一个全新的话题。这会限制你的受众。某些邮件阅读器，如 mutt，允许用户按线程排序然后折叠线程来隐藏消息。这样做的人永远不会看到你的消息。
更改标题是不够的。Mutt 和其他可能的邮件阅读器会查看邮件头中的其他信息来将其分配到线程中，而不是标题行。请开始一封全新的邮件。
在 Web 论坛上，良好实践的规则略有不同，因为消息通常与特定的讨论线程绑定得更紧密，在那些线程之外通常不可见。在回复中提问时更改标题不是必须的。并非所有论坛都允许在回复中设置单独的标题，即使允许也几乎没有人会读。然而，在回复中提问本身就是一个可疑的做法，因为只有关注这个线程的人才能看到。所以，除非你确定你只想向当前线程中活跃的人提问，否则请开一个新帖。
让回复更容易
用"请把你的回复发送到……"结束你的提问几乎保证你不会得到回答。如果你连花几秒钟在邮件程序中设置正确的 Reply-To 头都嫌麻烦，我们也懒得花几秒钟来思考你的问题。如果你的邮件程序不允许这样做，换一个更好的邮件程序。如果你的操作系统不支持任何允许这样做的邮件程序，换一个更好的操作系统。
在 Web 论坛中，要求通过邮件回复是彻底的无礼行为，除非你认为信息可能很敏感（而且有人会出于某种未知原因只让你知道而不告诉整个论坛）。如果你想在有人回复帖子时收到邮件副本，请让 Web 论坛发送；这个功能几乎到处都支持，在"关注此帖"、"有回复时发邮件"等选项中。
用清晰、合乎语法、拼写正确的语言书写
我们从经验中发现，粗心和马虎的写作者通常也是粗心和马虎的思考者和编码者（足以让我们打赌）。回答粗心和马虎的思考者的问题是没有回报的；我们宁愿把时间花在别的地方。
因此，清楚而准确地表达你的问题很重要。如果你连这点都懒得做，我们也懒得关注你。花额外的精力打磨你的语言。它不需要刻板或正式——事实上，黑客文化重视非正式的、俚语化的、幽默的语言，只要使用精确。但它必须精确；必须有某些迹象表明你在思考和注意。
正确使用拼写、标点和大小写。不要混淆"its"和"it's"、"loose"和"lose"、"discrete"和"discreet"。不要全部用大写字母打字；这被视为大声喊叫，被认为是不礼貌的。（全小写也只是稍微好一点，因为难以阅读。Alan Cox 可以这样做，但你不行。）
更一般地说，如果你写得像一个半文盲的蠢货，你很可能会被忽略。所以不要使用即时通讯的缩写。把"you"拼成"u"只会让你看起来像一个为了省两个键就让自己显得像半文盲蠢货的人。更糟糕的是：像 l33t script kiddie hax0r 那样写字是绝对的死亡之吻，保证你只会收到冷冰冰的沉默（或者，最多，一大堆轻蔑和讽刺）。
如果你在一个不使用你母语的论坛中提问，你在拼写和语法错误上会得到一些宽容——但在懒惰方面不会有任何额外的宽容（是的，我们通常能分辨出两者的区别）。另外，除非你知道回复者会什么语言，否则用英语写。忙碌的黑客倾向于直接丢弃他们不懂的语言写的问题，而英语是互联网的工作语言。用英语写作可以最大限度地减少你的问题被未读就丢弃的机会。
如果你用英语写作但英语是你的第二语言，提醒潜在的回答者你可能存在语言困难以及克服这些困难的方式是一种好做法。例如：
- 英语不是我的母语；请原谅打字错误。
- 如果你会说某种语言，请给我发邮件/私信；我可能需要帮助翻译我的问题。
- 我熟悉技术术语，但一些俚语表达和惯用语对我来说很困难。
- 我已经用某种语言和英语发布了我的问题。如果你只使用其中一种语言，我很乐意翻译回复。
用易于访问的标准格式发送问题
如果你故意让你的问题难以阅读，它更可能被跳过而不被回答。所以：
- 发送纯文本邮件，而不是 HTML。（关闭 HTML 并不难。）
- MIME 附件通常没问题，但只有在它们是真正的内容时（如附带的源文件或补丁），而不仅仅是你的邮件客户端生成的样板（如你消息的另一个副本）。
- 不要发送整个段落都是单行长句自动换行的邮件。（这使得只回复消息的一部分变得太困难。）假定你的回复者会在 80 个字符宽的文本显示器上阅读邮件，并相应地设置你的换行，设为 80 以下。
- 但是，不要对数据（如日志文件转储或会话记录）进行固定列宽换行。数据应该按原样包含，这样回复者可以确信他们看到的就是你看到的。
- 不要在英语论坛中发送 MIME Quoted-Printable 编码。当你用 ASCII 不能涵盖的语言发帖时，这种编码可能是必要的，但许多邮件客户端不支持它。当它们失效时，散布在文本中的那些 =20 符号既丑陋又令人分心——或者可能主动破坏你文本的语义。
- 永远，永远不要指望黑客能够阅读封闭的专有文档格式，如 Microsoft Word 或 Excel。大多数黑客对这些格式的反应，大概跟你在家门口发现一堆热气腾腾的猪粪差不多。即使他们能处理，他们也讨厌这么做。
- 如果你从 Windows 机器发送邮件，关闭 Microsoft 有问题的"智能引号"功能（从工具 > 自动更正选项中，在"键入时自动套用格式"下清除智能引号复选框）。这样你就不会在邮件中散布乱码字符了。
- 在 Web 论坛中，不要滥用"表情"和"HTML"功能（如果有的话）。一两个表情通常没问题，但花哨的彩色文本往往会让人觉得你很低级。过度使用表情符号、颜色和字体会让你看起来像一个咯咯笑的小女生，这通常不是一个好主意——除非你对性趣比对答案更感兴趣。
如果你使用图形化邮件客户端（如 Netscape Messenger、MS Outlook 或类似软件），要注意它在使用默认设置时可能会违反这些规则。大多数此类客户端有一个基于菜单的"查看源代码"命令。在已发送邮件文件夹中的某封邮件上使用此功能，验证发送的是纯文本且没有不必要的附加物。
精确描述你的问题并提供足够的信息
- 仔细清楚地描述你的问题或 bug 的症状。
- 描述问题发生的环境（机器、操作系统、应用程序等）。提供你的发行版及其版本号（例如："Fedora Core 7"、"Slackware 9.1"等）。
- 描述你在提问之前为理解问题所做的研究。
- 描述你在提问之前为定位问题所采取的诊断步骤。
- 描述你的计算机或软件配置中任何可能相关的近期变化。
- 如果可能的话，提供一种在受控环境中重现问题的方法。
尽你所能预测黑客会问的问题，并在你的求助请求中提前回答它们。
让黑客能够在受控环境中重现问题尤其重要——如果你报告的是你认为的代码 bug 的话。当你这样做时，你得到有用回答的几率和得到回答的速度都会大大提高。
Simon Tatham 写了一篇名为《如何有效地报告 Bug》的优秀文章。我强烈建议你阅读它。
篇幅不等于精确
你需要精确和有信息量。但这不意味着你应该简单地把大量的代码或数据倾倒到求助请求中。如果你有一个大型的、复杂的测试用例导致程序崩溃，尝试把它修剪到尽可能小。
这至少有三个原因有用。第一：别人看到你投入了精力来简化问题，就更可能给你回答。第二：简化问题使你更可能得到有用的回答。第三：在精炼 bug 报告的过程中，你可能自己就找到了修复方法或变通方案。
不要急于声称你发现了 Bug
当你在使用某个软件时遇到问题，不要声称发现了 bug，除非你非常、非常有把握。提示：除非你能提供修复问题的源代码补丁，或者针对先前版本的回归测试来证明错误行为，否则你可能不够有把握。这也适用于网页和文档；如果你发现了文档"bug"，你应该提供替换文本以及它应该出现在哪些页面上。
记住，还有许多其他用户没有遇到你的问题。否则你在阅读文档和搜索网络时就会发现了（你在投诉之前确实做了吧？）。这意味着很可能是你做错了什么，而不是软件有问题。
编写软件的人非常努力地工作以使其尽可能完善。如果你声称发现了 bug，你就是在质疑他们的能力，即使你是对的，也可能冒犯他们中的一些人。在标题中喊"bug"尤其不外交。
在提问时，最好写得好像你假定你自己做错了什么，即使你私下里相当确定你发现了一个实际的 bug。如果真的有 bug，你会在回答中了解到。这样做的话，如果 bug 是真的，维护者会想向你道歉，而不是如果你搞错了你得向他们道歉。
卑躬屈膝不能替代做功课
有些人明白了不应该粗鲁或傲慢地要求回答，却走向了另一个极端——卑躬屈膝。"我知道我只是一个可怜的新手失败者，但……"。这既令人分心又没有帮助。当它与关于实际问题的含糊描述结合在一起时尤其烦人。
不要浪费你的时间或我们的时间在粗陋的灵长类政治上。相反，尽可能清楚地呈现背景事实和你的问题。这比卑躬屈膝更能让你处于有利位置。
有时 Web 论坛有专门的新手提问区。如果你觉得你有一个新手问题，就去那里。但也不要在那里卑躬屈膝。
描述问题的症状，而非你的猜测
告诉黑客你认为问题的原因是什么是没用的。（如果你的诊断理论那么厉害，你还用向别人咨询吗？）所以，确保你告诉他们的是出了什么问题的原始症状，而不是你的解读和理论。让他们来做解读和诊断。如果你觉得陈述你的猜测很重要，明确标注它只是猜测，并描述为什么那个答案对你不适用。
蠢问题：
我在内核编译时不断遇到 SIG11 错误，我怀疑主板的某条走线有裂纹。检查这种问题的最佳方法是什么？
聪明的问题：
我自己组装的 K6/233 电脑，搭配 FIC-PA2007 主板（VIA Apollo VP2 芯片组）和 256MB Corsair PC133 SDRAM，在内核编译过程中开机约 20 分钟后开始频繁出现 SIG11 错误，但在前 20 分钟内从不出现。重启不会重置这个计时，但整夜关机后会。更换所有内存没有帮助。下面是一次典型编译会话日志的相关部分。
由于上述观点似乎对很多人来说很难理解，这里有一句话可以提醒你："所有的诊断者都来自密苏里州。"那个美国州的官方格言是"给我看看"（Show me），在诊断者的情况下，这不是怀疑态度的问题，而是一种字面上的、功能性的需求——他们需要看到与你看到的尽可能接近的原始证据，而不是你的推测和总结。给我们看。
按时间顺序描述问题的症状
找出问题所在最有用的线索通常在紧接发生之前的事件中。因此，你的描述应该精确地说明你做了什么，以及机器和软件做了什么，直到问题爆发。对于命令行操作，保留会话日志（例如，使用 script 工具）并引用相关的大约二十行是非常有用的。
如果导致问题的程序有诊断选项（如 -v 表示详细输出），尝试选择能在记录中添加有用调试信息的选项。记住，多不一定好；尝试选择一个能提供信息而不是用垃圾淹没读者的调试级别。
如果你的描述最终变得很长（超过大约四段），在开头简洁地陈述问题，然后按时间顺序叙述可能会有用。这样，黑客在阅读你的描述时就知道该注意什么。
描述目标，而非过程
如果你试图找出如何做某事（而不是报告 bug），先描述目标。然后才描述你被卡住的那个特定步骤。
通常，需要技术帮助的人心中有一个高级目标，但卡在了他们认为是通往目标的某条特定路径上。他们来寻求对步骤的帮助，却没有意识到路径是错误的。要绕过这一点可能需要付出大量的努力。
蠢问题：
如何让 FooDraw 程序的颜色选择器接受十六进制 RGB 值？
聪明的问题：
我正在尝试用我选择的值替换图像上的颜色表。目前我能看到的唯一方法是编辑每个表格槽位，但我无法让 FooDraw 的颜色选择器接受十六进制 RGB 值。
第二个版本的问题是聪明的。它允许给出一个可能建议更适合该任务的工具的答案。
不要要求别人通过私人邮件回复
黑客认为解决问题应该是一个公开透明的过程，在这个过程中，对答案的第一次尝试可以也应该在更有知识的人注意到它不完整或不正确时被纠正。同时，帮助者从被同行看到自己的能力和知识中获得一部分回报。
当你要求私人回复时，你同时破坏了过程和回报。不要这样做。回复是否私下发送是回复者的选择——如果他或她这样做了，通常是因为他或她认为这个问题太不成形或太明显了，对其他人没有意思。
这个规则有一个有限的例外。如果你认为这个问题可能会收到许多非常相似的答案，那么说"请给我发邮件，我会为大家汇总答案"就是合适的。尝试避免邮件列表或新闻组被大量基本相同的帖子淹没是有礼貌的——但你必须信守汇总的承诺。
明确表述你的问题
开放式的问题往往被视为开放式的时间黑洞。那些最有可能给你有用答案的人往往也是最忙的人（如果只是因为他们承担了最多的工作）。这样的人对开放式的时间黑洞过敏，因此他们倾向于对开放式的问题过敏。
如果你明确说明你希望回复者做什么（提供指引、发送代码、检查你的补丁等），你更可能得到有用的回复。这会聚焦他们的精力，并隐含地为回复者必须为帮助你所投入的时间和精力设定一个上限。这是好事。
要理解专家所处的世界，把专业知识看作丰富的资源，把响应时间看作稀缺的资源。你隐含要求的时间承诺越少，你就越有可能从真正厉害且真正繁忙的人那里得到回答。
所以，组织你的问题以最小化专家回答所需的时间承诺是有用的——但这通常不等同于简化问题。因此，例如，"你能给我一个关于 X 的好解释的链接吗？"通常比"你能解释一下 X 吗？"更聪明。如果你有一些出了问题的代码，请求某人解释什么地方出了错通常比请求某人修复它更聪明。
关于代码的提问
不要在不暗示应该查找什么类型的问题的情况下要求别人调试你的坏代码。发布几百行代码然后说"不能工作了"会让你被忽略。发布十几行代码然后说"在第 7 行之后我期望看到 X，但实际出现的是 Y"更可能得到回复。
关于代码问题最有效的精确描述方式是提供一个最小的能展示 bug 的测试用例。什么是最小测试用例？它是对问题的图解说明；刚好足够展示不良行为的代码，不多不少。如何制作最小测试用例？如果你知道哪一行或哪段代码产生了有问题的行为，复制一份并添加刚好足够的支持代码来产生一个完整的示例（即足以让编译器/解释器/任何处理它的应用程序接受的源代码）。如果你无法缩小到特定的部分，复制一份源代码并开始删除不影响有问题行为的部分。你的最小测试用例越小越好。
生成一个真正小的最小测试用例并不总是可能的，但尝试这样做是好的训练。它可能帮你学到解决问题所需的东西——即使不能，黑客也喜欢看到你做了尝试。这会让他们更愿意配合。
如果你只是想要一个代码审查，请在开头就说明，并确保提到你认为哪些地方可能特别需要审查以及为什么。
不要发布作业题
黑客善于识别作业题；我们大多数人自己也做过。那些问题是让你自己去解决的，这样你才能从经验中学习。可以请求提示，但不要请求完整的解答。
如果你怀疑你遇到的是一道作业题，但还是无法解决，试着在用户组论坛中提问，或者（作为最后的手段）在项目的"用户"列表/论坛中提问。虽然黑客会识别出来，但一些高级用户可能至少会给你一个提示。
删去无意义的追问
抵制在求助请求后附加"有人能帮帮我吗？"或"有答案吗？"等语义空洞问题的诱惑。第一：如果你的问题描述写得还算合格，这种附加的问题充其量是多余的。第二：因为它们是多余的，黑客会觉得烦——而且很可能回复逻辑上无懈可击但毫无帮助的答案，比如"是的，你可以得到帮助"和"不，没有人能帮你"。
一般来说，避免问是或否的问题是好的，除非你只想要一个是或否的答案。
即使对你很紧急，也不要标注"紧急"
那是你的问题，不是我们的。声称紧急很可能适得其反：大多数黑客会直接删除此类消息，认为它们是粗鲁且自私的企图以求获得即时和特殊的关注。此外，"紧急"这个词（以及其他类似的在标题中引人注意的企图）常常触发垃圾邮件过滤器——你预期的收件人可能根本看不到。
有一个半例外。如果你在某个引人注目的地方使用这个程序，一个会让黑客们兴奋的地方，那值得一提；在这种情况下，如果你有时间压力，礼貌地说出来，人们可能会因为足够感兴趣而更快地回答。
然而，这样做风险很大，因为黑客对什么是令人兴奋的判断标准可能和你的不同。比如从国际空间站发帖就够格，但代表一个让人感觉良好的慈善或政治事业发帖几乎肯定不行。事实上，发布"紧急：帮我拯救毛茸茸的小海豹！"将可靠地让你被回避或被痛骂，即使是那些认为毛茸茸的小海豹很重要的黑客也一样。
如果你觉得这很费解，在发帖之前请反复重读本指南的其余部分，直到你理解为止。
礼貌不会有坏处，有时还有帮助
要有礼貌。使用"请"和"感谢你的关注"或"感谢你的考虑"。让对方清楚你感激他们免费花时间帮助你。
说实话，这一点不如（也不能替代）语法正确、表述清晰、内容精确、描述详尽、避免使用专有格式等那么重要；黑客总体上宁愿收到有些生硬但技术上尖锐的 bug 报告，而不是礼貌但含糊的描述。（如果这让你困惑，请记住我们以问题能教给我们什么来评价一个问题。）
然而，如果你的技术细节已经准备就绪，礼貌确实能增加你获得有用回答的机会。
（我们必须指出，我们从资深黑客那里收到的对本 HOWTO 唯一严肃的反对意见，是关于我们之前建议使用"提前感谢"的。一些黑客觉得这暗示了之后不打算感谢任何人。我们的建议是要么先说"提前感谢"然后事后再感谢回答者，要么用不同的方式表达礼貌，比如说"感谢你的关注"或"感谢你的考虑"。）
问题解决后，发一个简短的总结
在问题解决后向所有帮助过你的人发一个说明；让他们知道结果如何，并再次感谢他们的帮助。如果这个问题在邮件列表或新闻组中引起了广泛的兴趣，在那里发布后续跟进是合适的。
最理想的情况是，回复应该是对原始提问帖子的跟帖，并且标题中应该有"已修复"、"已解决"或同样明显的标记。在周转速度快的邮件列表上，一个看到关于"问题 X"的帖子以"问题 X——已修复"结束的潜在回复者，就知道不必浪费时间阅读该帖子（除非他/她个人觉得问题 X 有趣），因此可以用这段时间去解决另一个问题。
你的后续跟进不需要很长很详细；一句简单的"嗨——原来是网线坏了！谢谢大家。—— Bill"就比什么都没有好。事实上，一个简短精炼的总结比一篇长篇大论要好，除非解决方案有真正的技术深度。说明是什么操作解决了问题，但你不必重播整个排查过程。
对于有一定深度的问题，发布一个排查历史的摘要是合适的。描述你最终的问题陈述。描述什么作为解决方案有效，并在之后指出应该避免的弯路。弯路应该放在正确的解决方案和其他摘要材料之后，而不是把后续跟进变成一个侦探故事。列出帮助过你的人的名字；你会因此交到朋友。
除了有礼貌和提供信息外，这种后续跟进还会帮助其他人在搜索邮件列表/新闻组/论坛的存档时，确切地知道哪个解决方案帮助了你，从而也可能帮助他们。
最后，同样重要的是，这种后续跟进能帮助每个提供过帮助的人对问题有一个令人满意的结局感。如果你自己不是技术人员或黑客，请相信我们，这种感觉对你求助的高手和专家来说非常重要。无疾而终的问题叙述是令人沮丧的东西；黑客渴望看到它们被解决。你因此挠到的痒处所赢得的善意，将在你下次需要提问时非常、非常有帮助。
想想你怎样才能防止其他人将来遇到同样的问题。问问自己一个文档或 FAQ 补丁是否有帮助，如果答案是肯定的，就把那个补丁发给维护者。
在黑客之间，这种良好的后续跟进行为实际上比传统的礼貌更重要。它是你建立与他人良好合作关系声誉的方式，这可以是一项非常有价值的资产。
如何理解回答
RTFM 和 STFW：如何判断你搞砸了
有一个古老而神圣的传统：如果你收到一条写着"RTFM"的回复，发送者认为你应该去读那该死的手册（Read The Fucking Manual）。他或她几乎肯定是对的。去读吧。
RTFM 有一个更年轻的亲戚。如果你收到一条写着"STFW"的回复，发送者认为你应该去搜索那该死的网络（Search The Fucking Web）。他或她几乎肯定是对的。去搜索吧。（更温和的版本是你被告知"Google 是你的朋友！"）
在 Web 论坛中，你也可能被告知去搜索论坛存档。事实上，有人甚至可能好心到提供一个指向解决了这个问题的先前帖子的链接。但不要依赖这种体贴；在提问之前先自己搜索存档。
通常，告诉你去搜索的人正在查看包含你需要信息的手册或网页，而且在打字的时候正看着它。这些回复意味着回复者认为 (a) 你需要的信息很容易找到，而且 (b) 你自己去找会比被人喂到嘴里学到更多。
你不应该为此感到被冒犯；按黑客的标准，你的回复者是在向你表示一种粗犷的尊重——仅仅因为没有忽略你。你应该感谢这种慈祥的善意。
如果你不理解……
如果你不理解回答，不要立刻反弹一条要求澄清的请求。使用你在尝试回答原始问题时用过的那些工具（手册、FAQ、网络、有经验的朋友）来理解回答。然后，如果你仍然需要求助澄清，展示你已经学到了什么。
例如，假设我告诉你："听起来你的 zentry 卡住了；你需要清除它。"那么：下面是一个坏的后续问题："什么是 zentry？"下面是一个好的后续问题："好的，我读了手册页，zentries 只在 -z 和 -p 选项下提到了。它们都没有说如何清除 zentries。是这两个中的一个还是我遗漏了什么？"
应对粗鲁的回复
在黑客圈子里，很多看起来像是粗鲁的行为并非有意冒犯。相反，它是直截了当的、不废话的沟通风格的产物，这种风格对于更关心解决问题而不是让别人感到温暖舒适的人来说是自然的。
当你觉得受到了粗鲁对待，尝试冷静地反应。如果某人确实在过分，很可能列表或新闻组或论坛中的资深成员会指出来。如果没有这样做而你又动了怒，那么你发脾气的对象很可能是在黑客社区的规范范围内行事，而你会被认为是有错的一方。这会损害你获得所需信息或帮助的机会。
另一方面，你偶尔也会遇到完全没有理由的粗鲁和自以为是。上述情况的反面是，对真正的冒犯者进行严厉反击是可以接受的，用锋利的言语手术刀剖析他们的不当行为。但在你这样做之前，要非常、非常确定你的立场。纠正无礼行为和引发无意义口水战之间的界限很细，以至于黑客自己也时常越线；如果你是新手或局外人，避免犯这种错误的机会很低。如果你追求的是信息而不是娱乐，那最好让你的手指远离键盘，而不是冒这个险。
（有些人认为许多黑客有轻度的自闭症或阿斯伯格综合征，实际上缺少了一些润滑"正常"人类社交互动的大脑回路。这可能是真的也可能不是。如果你自己不是黑客，把我们想象成"大脑有缺陷"可能有助于你应对我们的怪癖。尽管如此。我们不在意；我们喜欢自己的样子，而且通常对临床标签持健康的怀疑态度。）
Jeff Bigler 关于圆滑过滤器的观察也相关且值得一读。
在下一节中，我们将谈论一个不同的问题；当你行为不当时你会看到的那种"粗鲁"。
不要像失败者一样反应
你很可能在黑客社区论坛上犯几次错误——以本文所详述的方式，或类似的。你会被确切地告知你哪里搞砸了，可能还附带一些色彩丰富的旁白。而且是公开的。
当这种情况发生时，你能做的最糟糕的事情就是抱怨这段经历、声称自己受到了人身攻击、要求道歉、尖叫、屏住呼吸、威胁诉讼、向他们的雇主投诉、不放马桶圈等等。取而代之，你应该这样做：
克服它。这很正常。事实上，这是健康的和合适的。
社区标准不会自我维持：它们是由人们积极地、可见地、公开地应用来维持的。不要抱怨所有批评都应该通过私人邮件传达：事情不是这样运作的。坚持认为当有人评论你的某个说法有错或他的观点与你不同时你就受到了人身侮辱，也是没用的。那些都是失败者的态度。
曾有一些黑客论坛，出于某种误导性的过度礼貌感，禁止参与者对他人的帖子提出任何批评，并被告知"如果你不愿意帮助用户就什么也不要说"。结果是有见识的参与者纷纷离开去了别处，论坛沦为毫无意义的废话堆而变得毫无用处。
过分"友好"（以那种方式）或有用：二选一。
记住：当那个黑客告诉你你搞砸了，并且（不管多么粗暴地）告诉你不要再犯时，他是出于对 (1) 你和 (2) 他的社区的关心。对他来说忽略你并把你从他的生活中过滤掉要容易得多。如果你做不到感激，至少保持一点尊严，不要抱怨，也不要仅仅因为你是一个有着戏剧性过敏灵魂和权利错觉的新来者就期望被像易碎的娃娃一样对待。
有时候人们会无端地人身攻击你、无来由地喷你等等，即使你没有搞砸（或者只是在他们的想象中搞砸了）。在这种情况下，抱怨才是真正搞砸的方式。
这些喷子要么是不懂装懂的蠢货，自以为是专家，要么是想测试你会不会崩溃的业余心理学家。其他读者要么忽略他们，要么自己想办法应对。喷子的行为给他们自己制造了问题，你不需要为此操心。
不要让自己卷入口水战。大多数口水帖最好无视——在你确认它们确实只是口水帖之后，而不是你搞砸了的指示，也不是对你真正问题的巧妙加密的回答（这种情况也存在）。
不该问的问题
以下是一些经典的蠢问题，以及黑客在不回答它们时心里在想什么。
问： 我在哪里能找到程序或资源 X？ 答： 跟我在同一个地方，笨蛋——在网络搜索的另一端。天哪，难道不是每个人都知道怎么用 Google 吗？
问： 我如何用 X 来做 Y？ 答： 如果你想做的是 Y，你应该直接问那个问题，而不要预设使用某种可能不合适的方法。这种形式的问题通常表明提问者不仅对 X 无知，而且对要解决的 Y 问题也很困惑，过于执着于自己特定情况的细节。通常最好忽略这样的人，直到他们更好地定义了他们的问题。
问： 我如何配置我的 shell 提示符？ 答： 如果你够聪明能问出这个问题，你就够聪明自己去 RTFM 然后找到答案。
问： 我可以用 Bass-o-matic 文件转换器将 AcmeCorp 文档转换为 TeX 文件吗？ 答： 试试看就知道了。如果你那样做了，你就会 (a) 知道答案，并且 (b) 不再浪费我的时间。
问： 我的{程序、配置、SQL 语句}不工作了 答： 这不是一个问题，而我也没有兴趣和你玩二十个问题的游戏来套出你的实际问题——我有更好的事情要做。看到这类消息，我的反应通常是以下之一：
- 你还有什么要补充的吗？
- 哦，太糟糕了，希望你能修好。
- 这跟我有什么关系？
问： 我的 Windows 机器有问题。你能帮忙吗？ 答： 可以。扔掉那些微软垃圾，安装一个开源操作系统，比如 Linux 或 BSD。 注意：你可以问与 Windows 机器相关的问题——如果它们是关于有官方 Windows 构建的程序，或与 Windows 机器交互的程序（如 Samba）。只是不要惊讶于回复说问题出在 Windows 上而不是程序上，因为 Windows 总体上是如此不可靠，这种情况非常常见。
问： 我的程序不工作了。我认为系统设施 X 有问题。 答： 虽然你可能是第一个注意到被成百上千人大量使用的系统调用和库中明显缺陷的人，但更有可能的是你完全不知道自己在做什么。非同寻常的声明需要非同寻常的证据；当你做出这样的声明时，你必须用清晰而详尽的失败案例文档来支持它。
问： 我在安装 Linux 或 X 时遇到了问题。你能帮忙吗？ 答： 不能。我需要亲手操作你的机器才能排查这个问题。去找你当地的 Linux 用户组寻求实际帮助。（你可以在这里找到用户组列表。） 注意：如果你在某个特定发行版的论坛或邮件列表上，并且问题是关于那个发行版的，关于安装 Linux 的问题可能是合适的。在这种情况下，请务必描述故障的确切细节。但先仔细搜索，用"linux"和所有可疑的硬件名称。
问： 我如何破解 root/窃取频道管理员权限/阅读别人的邮件？ 答： 你想做这种事是个卑鄙小人，要求黑客帮你做是个白痴。
好问题与坏问题
最后，我将通过示例来说明如何聪明地提问；关于同一个问题的成对问题，一个用蠢方式提问，一个用聪明方式提问。
蠢问题： 我在哪里可以找到关于 Foonly Flurbamatic 的信息？
这个问题只会招来 "STFW" 的回复。
聪明的问题： 我用 Google 搜索了"Foonly Flurbamatic 2600"，但没有找到有用的结果。谁能给我一个关于这个设备编程信息的链接吗？
这个人已经搜索过了，而且听起来可能有一个真正的问题。
蠢问题： 我无法编译项目 foo 的代码。它为什么是坏的？
提问者假定是别人搞砸了。傲慢的家伙……
聪明的问题： 项目 foo 的代码在 Nulix 6.2 版本下无法编译。我读了 FAQ，但其中没有关于 Nulix 相关问题的内容。这是我编译尝试的记录；是我做错了什么吗？
提问者指定了环境，读了 FAQ，展示了错误，而且没有假定问题是别人的错。这个值得关注。
蠢问题： 我的主板有问题。谁能帮帮忙？
某个黑客对此的回应可能是"好吧。你还需要人帮你拍嗝和换尿布吗？"然后按下删除键。
聪明的问题： 我在 S2464 主板上试了 X、Y 和 Z。都不行，然后我试了 A、B 和 C。注意我试 C 时出现的奇怪症状。显然 florbish 正在 grommicking，但结果不是人们期望的那样。Athlon MP 主板上 grommicking 的常见原因是什么？有人有什么额外的测试建议来帮我定位问题吗？
这个人，另一方面，看起来值得回答。他/她展现了解决问题的智慧，而不是被动地等待答案从天上掉下来。
在最后一个问题中，注意"给我一个答案"和"请帮我弄清楚我还能做什么诊断来找到答案"之间微妙但重要的区别。
事实上，最后那个问题的形式密切基于 2001 年 8 月发生在 linux-kernel 邮件列表（lkml）上的一个真实事件。当时提问的是我（Eric）。我在一块 Tyan S2462 主板上遇到了神秘的系统锁死。列表成员提供了我解决它们所需的关键信息。
通过以那种方式提问，我给了人们一些值得思考的东西；我让他们参与进来变得容易且有吸引力。我展示了对同行能力的尊重，邀请他们作为同行与我商讨。我也通过告诉他们我已经走过的弯路来展示了对他们时间的尊重。
之后，当我感谢大家并评论这个过程运作得多好时，一位 lkml 成员观察说，他认为这之所以成功，不是因为我在那个列表上是一个"名人"，而是因为我以正确的方式提了问题。
黑客在某些方面是一个非常无情的精英制度；我确信他是对的，如果我表现得像一个吸血鬼，不管我是谁都会被痛骂或忽略。他建议我把整个事件写成一份对他人的指导，这直接导致了本指南的编写。
如果得不到回答
如果你得不到回答，请不要因为我们觉得无法帮助你而把它当做人身问题。有时候被问到的群体的成员确实不知道答案。没有回应与被忽略不同，尽管从外部来看确实很难分辨。
一般来说，简单地重新发布你的问题是一个坏主意。这会被视为毫无意义的烦人行为。要有耐心：拥有你答案的人可能在不同的时区并且正在睡觉。或者也许你的问题从一开始就没有形成好的表述。
还有其他你可以求助的来源，通常是更适合新手需求的来源。
有许多在线和本地用户组，他们是软件的爱好者，即使他们自己可能从未写过任何软件。这些群体通常是为了互相帮助和帮助新用户而形成的。
还有许多你可以签约获取帮助的商业公司，大的小的都有。不要因为需要付费获取帮助而感到沮丧！毕竟，如果你的汽车发动机爆了缸垫，你很可能会把它送到修理店并付费修理。即使软件没花你一分钱，你也不能期望技术支持总是免费的。
对于像 Linux 这样流行的软件，每个开发者至少有 10,000 个用户。一个人不可能处理来自超过 10,000 个用户的技术支持请求。请记住，即使你必须付费获取支持，你支付的费用仍然远少于你必须同时购买软件的情况（而且闭源软件的支持通常比开源软件的支持更贵且更不称职）。
如何有效地回答问题
温柔些。 与问题相关的压力会让人看起来粗鲁或愚蠢，即使他们并非如此。
对初犯者私下回复。 对于可能只是犯了诚实错误的人，没有必要公开羞辱。真正的新手可能不知道如何搜索存档或 FAQ 存放在哪里。
如果你不确定，就说出来！ 一个听起来很权威但错误的回答比没有回答更糟糕。不要仅仅因为觉得听起来像专家很有趣就把人引向错误的路。要谦虚和诚实；为提问者和你的同行树立好榜样。
如果你帮不了忙，就不要添乱。 不要拿可能会毁掉用户系统的操作开玩笑——那个可怜虫可能会把这些当做指令来执行。
提出探测性问题以获取更多细节。 如果你擅长这个，提问者会学到一些东西——你也可能会。尝试把坏问题变成好问题；记住我们都曾经是新手。
虽然在回复一个只是懒虫的人时，嘟囔一声 RTFM 有时是合理的，但一个指向文档的链接（即使只是建议搜索一个关键短语的 Google 链接）会更好。
如果你要回答，就给出好的回答。 当某人在使用错误的工具或方法时，不要建议权宜之计。建议好的工具。重新构建问题。
回答真正的问题！如果提问者已经足够彻底地做了研究，并在提问中包含了 X、Y、Z、A、B 和 C 已经被尝试过但没有好结果，那么回复"试试 A 或 B"或者给出一个只说"试试 X、Y、Z、A、B 或 C"的链接是极其没有帮助的。
帮助你的社区从问题中学习。 当你回答了一个好问题时，问自己"相关的文档或 FAQ 需要怎样改变才能让以后没有人需要再回答这个问题？"然后把补丁发给文档维护者。
如果你做了研究来回答问题，展示你的研究技能，而不是写得好像你是凭空想出来的。 回答一个好问题就像给一个饥饿的人一顿饭，但通过示范教他们研究技能就是教他们如何终生种出食物。
相关资源
如果你需要关于个人电脑、Unix 和互联网如何工作的基础知识，请参阅《Unix 和互联网基础 HOWTO》。
当你发布软件或为软件编写补丁时，请尝试遵循《软件发布实践 HOWTO》中的指南。
致谢
Evelyn Mitchell 贡献了一些蠢问题的示例，并启发了"如何给出好答案"部分。Mikhail Ramendik 贡献了一些特别有价值的改进建议。
Comments (0)
No comments yet. Be the first to share your thoughts!