埃里克·史蒂文·雷蒙德
里克·摩恩
版权所有 © 2001，2006，2014 Eric S. Raymond， Rick Moen
我们已经艰难地认识到，如果没有这样的通知，我们将一再被白痴所困扰，他们认为发表这份文件使我们的工作是解决世界上所有的技术问题。
如果你正在阅读本文档是因为你需要帮助，而你走开了，你的印象是你可以直接从本文档的作者那里得到它，那么你就是我们正在谈论的白痴之一。不要问我们问题。我们只是忽略你。我们在这里向您展示如何从真正了解您正在处理的软件或硬件的人那里获得帮助，但99.9%的时间不会是我们。除非你确定其中一位作者是你正在处理的事情的专家，否则不要管我们，每个人都会更开心。
在黑客的世界里，你得到的技术问题的答案类型既取决于你提出问题的方式，也取决于开发答案的难度。本指南将教您如何以更有可能获得满意答案的方式提出问题。
现在开源的使用已经变得普遍，你通常可以从其他更有经验的用户那里得到和黑客一样好的答案。这是一件好事;用户往往对新手经常遇到的失败更加宽容。尽管如此，以我们在这里推荐的方式将有经验的用户视为黑客通常也是从他们那里获得有用答案的最有效方法。
首先要了解的是，黑客实际上喜欢困难的问题和关于它们的好的，发人深省的问题。如果我们不这样做，我们就不会在这里。如果您给我们一个有趣的问题，我们将非常感谢您;好的问题是一种刺激，也是一种礼物。好的问题可以帮助我们发展我们的理解，并且经常揭示我们可能没有注意到或想到的问题。在黑客中，"好问题！"是一个强烈而真诚的赞美。
尽管如此，黑客仍然以以看似敌意或傲慢的方式解决简单的问题而闻名。有时看起来我们对新手和无知者条件反射地粗鲁。但事实并非如此。
我们毫无歉意地对那些似乎不愿意在提问之前思考或做足功课的人充满敌意。像这样的人是时间的沉没——他们拿走了却没有回馈，他们浪费时间，我们本可以把时间花在另一个更有趣的问题上，另一个人更值得回答。我们称这样的人为"失败者"（由于历史原因，我们有时将其拼写为"lusers"）。
我们意识到，有很多人只想使用我们编写的软件，而对学习技术细节没有兴趣。对大多数人来说，计算机只是一种工具，一种达到目的的手段;他们有更重要的事情要做，有更重要的生活要活。我们承认这一点，并不期望每个人都对令我们着迷的技术问题感兴趣。尽管如此，我们回答问题的风格是为那些确实有兴趣并愿意积极参与解决问题的人调整的。这不会改变。也不应该这样做。如果是这样的话，我们在最擅长的事情上就会变得不那么有效。
我们（很大程度上）是志愿者。我们从繁忙的生活中抽出时间来回答问题，有时我们会被它们淹没。所以我们无情地过滤。特别是，我们抛弃了那些看似失败者的问题，以便更有效地将我们的问答时间花在赢家身上。
如果你发现这种态度令人讨厌，居高临下或傲慢，请检查你的假设。我们并不是要求你真诚地对待我们——事实上，我们大多数人只想与你平等相处，欢迎你加入我们的文化，如果你付出必要的努力，使这成为可能的话。但是，对我们来说，试图帮助那些不愿意帮助自己的人是没有效率的。无知是可以的;玩傻是不行的。
因此，虽然在技术上不一定有能力才能引起我们的注意，但有必要表现出那种导致能力的态度 - 警觉，深思熟虑，观察，愿意成为开发解决方案的积极合作伙伴。如果您无法忍受这种歧视，我们建议您向某人支付商业支持合同，而不是要求黑客亲自向您提供帮助。
如果您决定向我们寻求帮助，您不想成为失败者之一。你也不想看起来像一个。获得快速响应的答案的最好方法是像一个有智慧，自信和线索的人一样问它，他只是碰巧在某个特定问题上需要帮助。
（欢迎对本指南进行改进。您可以将建议邮寄给 esr@thyrsus.com 或 respond-auto@linuxmafia.com。但请注意，本文档并非旨在作为网络礼仪的一般指南，我们通常会拒绝与在技术论坛中引出有用答案没有具体关系的建议。
在通过电子邮件、新闻组或网站聊天板上提出技术问题之前，请执行以下操作：
-
尝试通过搜索您计划发帖的论坛或邮件列表的存档来查找答案。
-
尝试通过搜索网络来找到答案。
-
尝试通过阅读手册找到答案。
-
尝试通过阅读常见问题解答来找到答案。
-
尝试通过检查或实验找到答案。
-
尝试通过询问熟练的朋友来找到答案。
-
如果您是程序员，请尝试通过阅读源代码来找到答案。
当你问你的问题时，展示你首先做了这些事情的事实;这将有助于确定你不是懒惰的海绵，浪费人们的时间。更好的是，展示你从做这些事情中学到的东西。我们喜欢为那些已经证明可以从答案中学习的人回答问题。
使用一些策略，例如对您收到的任何错误消息的文本进行Google搜索（搜索Google组以及网页）。这可能会直接带您修复文档或邮件列表线程来回答您的问题。即使没有，说"我在谷歌上搜索了以下短语，但没有得到任何看起来很有希望的东西"在电子邮件或新闻帖子中寻求帮助也是一件好事，即使只是因为它记录了搜索无济于事。它还有助于通过将搜索词链接到希望是您的问题和解决线程的其他人到您的线程。
别着急。不要指望能够通过几秒钟的谷歌搜索来解决一个复杂的问题。阅读并理解常见问题解答，坐下来，放松一下，并在与专家联系之前对问题进行一些思考。相信我们，他们将能够从您的问题中看出您做了多少阅读和思考，并且如果您准备好了，他们会更愿意提供帮助。不要仅仅因为你的第一次搜索没有发现答案（或太多）就立即解雇了你的整个问题库。
准备您的问题。仔细想想。听起来很匆忙的问题会得到仓促的答案，或者根本没有答案。你越是证明在寻求帮助之前已经投入了思想和精力来解决你的问题，你就越有可能真正得到帮助。
当心问错问题。如果你问一个基于错误假设的问题，J. Random Hacker很可能会用一个无用的字面答案来回答，同时思考"愚蠢的问题......"，并希望得到你所要求的而不是你需要的东西的经验会给你一个教训。
永远不要假设你有权得到答案。你不是;毕竟，您不是在为服务付费。如果你通过提出一个实质性的、有趣的、发人深省的问题来获得答案，你就会得到一个答案——一个隐含地有助于社区体验的问题，而不仅仅是被动地向他人索取知识。
另一方面，明确表示您能够并愿意在开发解决方案的过程中提供帮助是一个非常好的开始。"有人会提供指针吗？"，"我缺少什么示例？"和"我应该检查哪个网站？"比"请发布我应该使用的确切程序"更有可能得到回答。因为你清楚地表明，如果有人能为你指出正确的方向，你真的愿意完成这个过程。
在选择提问的地方时要敏感。如果您符合以下条件，您很可能会被忽视或被注销为失败者：
-
将您的问题发布到偏离主题的论坛
-
将一个非常基本的问题发布到一个需要高级技术问题的论坛上，反之亦然
-
交叉发布到太多不同的新闻组
-
将个人电子邮件发布给既不是您的熟人，也不亲自负责解决您的问题的人
黑客会抛出不恰当地针对的问题，以保护他们的通信渠道不被淹没在无关紧要的环境中。你不希望这种情况发生在你身上。
因此，第一步是找到合适的论坛。同样，谷歌和其他网络搜索方法是你的朋友。使用它们来查找与硬件或软件最密切相关的项目网页，这些硬件或软件给您带来了困难。通常，它将具有指向FAQ（常见问题解答）列表的链接，以及项目邮件列表及其存档的链接。这些邮件列表是寻求帮助的最后一个地方，如果您自己的努力（包括阅读您找到的常见问题解答）没有找到解决方案。项目页面还可以描述错误报告程序，或者有一个链接;如果是这样，请遵循它。
向你不熟悉的人或论坛发送电子邮件充其量是有风险的。例如，不要假设信息网页的作者想成为您的免费顾问。不要乐观地猜测你的问题是否会受到欢迎 - 如果你不确定，把它发送到其他地方，或者根本不发送它。
在选择Web论坛，新闻组或邮件列表时，不要太过信任名称本身;查找常见问题解答或章程以验证您的问题是否与主题相关。在发布之前阅读一些后面的流量，这样您就可以了解那里是如何完成的。实际上，在发布之前，最好在新闻组或邮件列表存档中搜索与您的问题相关的单词的关键字。它可能会给你找到一个答案，如果没有，它会帮助你制定一个更好的问题。
不要一次用霰弹枪炸毁所有可用的帮助渠道，这就像大喊大叫，激怒人们。轻轻地穿过它们。
了解您的主题是什么！其中一个经典的错误是在专门讨论一种语言、库或工具可移植的论坛中询问有关 Unix 或 Windows 编程接口的问题。如果你不明白为什么这是一个错误，你最好在得到它之前不要问任何问题。
一般来说，向精心挑选的公共论坛提出的问题比向私人论坛提出的问题更有可能获得有用的答案。造成这种情况的原因有很多。一个只是潜在受访者群体的规模。另一个是观众的规模;黑客宁愿回答教育许多人的问题，也不愿回答只为少数人服务的问题。
Understandably, skilled hackers and authors of popular software are already receiving more than their fair share of mis-targeted messages. By adding to the flood, you could in extreme cases even be the straw that breaks the camel's back — quite a few times, contributors to popular projects have withdrawn their support because collateral damage in the form of useless e-mail traffic to their personal accounts became unbearable.
搜索，然后在 Stack Exchange 上询问
近年来，Stack Exchange网站社区已成为回答技术和其他问题的主要资源，甚至是许多开源项目的首选论坛。
从Google搜索开始，然后再查看Stack Exchange;谷歌实时将其编入索引。很有可能有人已经问过类似的问题，而Stack Exchange网站通常位于搜索结果的顶部附近。如果您没有通过 Google 找到任何内容，请在与您的问题最相关的特定网站上再次搜索（见下文）。使用标记进行搜索有助于缩小结果范围。
如果您仍然没有找到任何东西，请将您的问题发布在最切题的一个网站上。使用格式化工具，尤其是代码，并添加与问题的实质内容相关的标记（尤其是遇到问题的编程语言、操作系统或库的名称）。如果评论者要求您提供更多信息，请编辑您的主帖子以将其包括在内。如果任何答案有帮助，请单击向上箭头投赞成票;如果答案为您的问题提供了解决方案，请单击投票箭头下的检查以接受其正确。
Stack Exchange已经发展到100多个站点，但以下是最有可能的候选站点：
-
超级用户是关于通用计算的问题。如果您的问题不是关于仅通过网络连接与之通信的代码或程序，则可能会转到此处。
-
Stack Overflow用于有关编程的问题。
-
服务器故障是有关服务器和网络管理的问题。
有几个项目有自己的特定网站，包括Android，Ubuntu，TeX / LaTeX和SharePoint。查看堆栈交换站点以获取最新列表。
您的本地用户组或Linux发行版可能会宣传Web论坛或IRC频道，新手可以在其中获得帮助。（在非英语国家，新手论坛仍然更有可能是邮件列表。这些都是很好的第一个问题，特别是如果你认为你可能因为一个相对简单或常见的问题而绊倒了。一个广告的IRC频道是一个公开的邀请，在那里提出问题，并经常实时获得答案。
事实上，如果你从Linux发行版中获得了给你带来问题的程序（就像今天很常见的那样），那么在尝试程序的项目论坛/列表之前，最好在发行版的论坛/列表中询问。该项目的黑客可能只是说，"使用我们的构建"。
在发布到任何 Web 论坛之前，请检查它是否具有搜索功能。如果是这样，请尝试几个关键字搜索类似您的问题的内容;它可能会有所帮助。如果您之前进行了一般的Web搜索（您应该这样做），请无论如何都要搜索论坛;您的网络搜索引擎最近可能没有将所有这些论坛编入索引。
项目越来越倾向于通过 Web 论坛或 IRC 渠道提供用户支持，而电子邮件则更多地用于开发流量。因此，在寻求特定于项目的帮助时，请先寻找这些渠道。
在IRC中，最好不要首先在频道上转储很长的问题描述;有些人将此解释为渠道泛滥。最好以一种在频道上开始对话的方式说出一行问题描述。
当一个项目有一个开发邮件列表时，写信给邮件列表，而不是个别开发人员，即使你认为你知道谁能最好地回答你的问题。检查项目及其主页的文档以获取项目邮件列表的地址，并使用它。此策略有几个很好的理由：
-
任何足以向一个开发人员提出的问题对整个团队都有价值。相反，如果你怀疑你的问题对于邮件列表来说太愚蠢了，这不是骚扰个别开发人员的借口。
-
在列表中提出问题会在开发人员之间分配负载。单个开发人员（特别是如果他是项目负责人）可能太忙而无法回答您的问题。
-
大多数邮件列表都已存档，并且存档由搜索引擎编制索引。如果你在清单上问你的问题并且得到了回答，那么未来的querent可以在Web上找到你的问题和答案，而不是再次提出来。
-
如果某些问题经常被问到，开发人员可以使用该信息来改进文档或软件本身，以减少混淆。但是，如果这些问题是私下提出的，没有人能够全面了解最常被问到的问题。
如果一个项目同时有"用户"和"开发人员"（或"黑客"）邮件列表或Web论坛，并且您没有对代码进行黑客攻击，请在"用户"列表/论坛中询问。不要假设您将受到开发人员列表中的欢迎，他们可能会将您的问题视为干扰其开发人员流量的噪音。
但是，如果您确定您的问题并非微不足道，并且您在"用户"列表/论坛中几天没有得到答案，请尝试"开发人员"。建议您潜伏在那里几天，或者至少查看最近几天的存档消息，在发布之前了解当地的民俗（实际上，这是任何私人或半私人列表上的好建议）。
如果您找不到项目的邮件列表地址，但只能看到项目维护者的地址，请继续写信给维护者。但即使在这种情况下，也不要假设邮件列表不存在。在您的电子邮件中提及您尝试过但找不到相应的邮件列表。还要提到您不反对将您的信息转发给其他人。（许多人认为私人电子邮件应该保持私密，即使它没有任何秘密。通过允许转发您的邮件，您可以让您的通讯员选择如何处理您的电子邮件。
在邮件列表、新闻组或 Web 论坛上，主题标题是吸引合格专家关注的黄金机会，用大约 50 个字符或更少。不要把它浪费在像"请帮帮我"这样的喋喋不休上（更不用说"请帮帮我!!!!";带有类似主题的消息会被反射丢弃）。不要试图用你的痛苦的深度给我们留下深刻的印象;改用空格进行超级简洁的问题描述。
许多技术支持组织使用的主题标头的一个好约定是"对象 - 偏差"。"对象"部分指定了什么事物或一组事物有问题，"偏差"部分描述了与预期行为的偏差。
笨：
帮助！视频在我的笔记本电脑上无法正常工作！
聪明：
X.org 6.8.1 畸形鼠标光标，Fooware MV1005 视频芯片组
聪明：
X.org 6.8.1 鼠标光标在 Fooware MV1005 vid. 芯片组 - 畸形
编写"对象偏差"描述的过程将帮助您更详细地组织对问题的思考。哪些因素会受到影响？只是鼠标光标还是其他图形？这是否特定于 X 的 X.org 版本？到版本 6.8.1？这是否特定于Fooware视频芯片组？要型号 MV1005？看到结果的黑客可以立即了解您遇到的问题以及您遇到的问题。一目了然。
更一般地说，想象一下查看问题档案的索引，只显示主题行。使您的主题行能够很好地反映您的问题，以便下一个搜索具有与您的问题类似的问题的存档的人将能够跟随线程找到答案，而不是再次发布问题。
如果您在回复中提问，请务必更改主题行以指示您正在提问。看起来像"Re：test"或"Re：new bug"的主题行不太可能吸引有用的关注量。此外，将以前消息的引用减少到与新读者中的隐藏一致的最低限度。
不要简单地点击回复列表消息来启动一个全新的线程。这将限制您的受众。某些邮件阅读器（如 mutt）允许用户按线程排序，然后通过折叠线程将邮件隐藏在线程中。这样做的人永远不会看到你的信息。
仅仅改变主题是不够的。Mutt（可能还有其他邮件阅读器）会查看电子邮件标头中的其他信息，以将其分配给线程，而不是主题行。而是开始一封全新的电子邮件。
在 Web 论坛上，良好实践的规则略有不同，因为消息通常与特定的讨论线程绑定得更紧密，并且在这些线程之外通常不可见。在回答问题时改变主题并不重要。并非所有论坛都允许在回复上添加单独的主题行，而且几乎没有人阅读它们。但是，在回复中提问本身就是一种可疑的做法，因为只有那些正在观看此帖子的人才能看到它。因此，除非您确定只想询问线程中当前活动的人，否则请启动一个新线程。
以"请将您的回复发送到..."完成您的查询，您不太可能得到答案。如果您甚至懒得花几秒钟在邮件代理中设置正确的回复标头，我们甚至懒得花几秒钟来思考您的问题。如果您的邮件程序不允许这样做，请获取更好的邮件程序。如果您的操作系统不支持任何允许这样做的电子邮件程序，请购买更好的操作系统。
在Web论坛中，通过电子邮件请求回复是完全粗鲁的，除非您认为该信息可能是敏感的（并且出于某种未知原因，有人会让您而不是整个论坛都知道它）。如果您想要在有人在线程中回复时的电子邮件副本，请请求Web论坛发送它;此功能几乎在"观看此线程"，"在答案上发送电子邮件"等选项下都受支持。
我们通过经验发现，粗心大意和草率的作家通常也在思考和编码方面粗心大意和草率（无论如何，通常足以押注）。为粗心大意和草率的思想家回答问题没有回报;我们宁愿把时间花在其他地方。
因此，清晰而好地表达您的问题非常重要。如果你懒得这样做，我们就懒得去注意。花额外的精力来润色你的语言。它不必是僵硬的或正式的 - 事实上，黑客文化重视精确使用的非正式，俚语和幽默的语言。但它必须是精确的;必须有一些迹象表明你正在思考和注意。
正确拼写、标点符号和大写。不要将"its"与"it's"，"loose"与"lose"混淆，或将"discrete"与"谨慎"混淆。不要输入全部大写字母;这被解读为大喊大叫，被认为是粗鲁的。（全小的只是稍微不那么烦人，因为它很难阅读。艾伦·考克斯（Alan Cox）可以逃脱惩罚，但你不能。
更一般地说，如果你像一个半文盲的胸部一样写作，你很可能会被忽视。因此，不要使用即时消息快捷方式。将"you"拼写为"u"会使您看起来像一个半文盲的胸部，以节省两个完整的击键。更糟糕的是：像l33t脚本小子hax0r一样写作是死亡的绝对之吻，并保证你只会得到石头般的沉默（或者，充其量，一堆蔑视和讽刺的帮助）作为回报。
如果您在不使用母语的论坛中提问，您将获得有限的拼写和语法错误的松弛 - 但对于懒惰，您根本没有额外的松弛（是的，我们通常可以发现这种差异）。此外，除非您知道受访者的语言是什么，否则请用英语写作。忙碌的黑客倾向于简单地用他们不懂的语言来刷新问题，而英语是互联网的工作语言。通过用英语写作，您可以最大限度地减少您的问题在未读的情况下被丢弃的可能性。
如果您用英语写作，但它是您的第二语言，那么提醒潜在受访者注意潜在的语言困难和绕过他们的选择是很好的形式。例子：
-
英语不是我的母语;请原谅打字错误。
-
如果您$LANGUAGE说话，请发送电子邮件/PM我;我可能需要帮助翻译我的问题。
-
我熟悉技术术语，但一些俚语表达和习语对我来说很难。
-
我已经用$LANGUAGE和英语发布了我的问题。如果您只使用一个或另一个，我将很乐意翻译回复。
如果你人为地让你的问题难以阅读，它更有可能被忽略，而倾向于一个不是的问题。所以：
-
发送纯文本邮件，而不是 HTML。（关闭 HTML 并不难。
-
MIME 附件通常是可以的，但前提是它们是真实内容（如附加的源文件或修补程序），而不仅仅是由邮件客户端生成的样板文件（如邮件的另一个副本）。
-
不要发送整个段落都是单行乘换行的电子邮件。（这使得仅回复部分邮件变得太困难了。假设您的受访者将在 80 个字符宽的文本显示屏上阅读邮件，并相应地将换行设置为小于 80。
-
但是，不要以任何固定的列宽包装数据（如日志文件转储或会话脚本）。数据应按原样包含，以便受访者可以确信他们正在看到您所看到的内容。
-
不要将 MIME 引用可打印编码发送到英语论坛。当您使用 ASCII 未涵盖的语言进行发布时，可能需要此编码，但许多电子邮件代理不支持它。当它们断裂时，所有散落在文本中的=20个字形都是丑陋和分散注意力的 - 或者可能主动破坏文本的语义。
-
永远不要指望黑客能够读取封闭的专有文档格式，如Microsoft Word或Excel。大多数黑客对这些的反应就像你对把一堆热气腾腾的猪粪倒在家门口一样。即使他们能够应付，他们也讨厌不得不这样做。
-
如果要从 Windows 计算机发送电子邮件，请关闭 Microsoft 有问题的"智能引号"功能（从"工具">"自动更正选项"，清除"键入时自动套用格式"下的"智能引号"复选框）。这样您就可以避免通过邮件洒落垃圾字符。
-
在 Web 论坛中，不要滥用"笑脸"和"HTML"功能（当它们存在时）。一两个笑脸通常是可以的，但彩色的花哨文字往往会让人们认为你很瘸。严重过度使用表情符号，颜色和字体会让你变得像一个咯咯笑的十几岁的女孩，这通常不是一个好主意，除非你对性比对答案更感兴趣。
如果您使用的是图形用户界面邮件客户端（如 Netscape Messenger、MS Outlook 或其类似客户端），请注意，在使用其默认设置时，它可能会违反这些规则。大多数此类客户端都有基于菜单的"查看源"命令。在已发送邮件文件夹中的某些内容上使用它，以验证纯文本的发送，而不会出现不必要的附加内容。
-
仔细而清晰地描述您的问题或错误的症状。
-
描述它发生的环境（计算机，操作系统，应用程序等）。提供供应商的发行版和发行版级别（例如："Fedora Core 7"、"Slackware 9.1"等）。
-
在你提出问题之前，描述你为尝试理解问题所做的研究。
-
描述您在提出问题之前为尝试自己确定问题而采取的诊断步骤。
-
描述计算机或软件配置中任何可能相关的最近更改。
-
如果可能，请提供一种在受控环境中重现问题的方法。
尽最大努力预测黑客会问的问题，并提前在您的帮助请求中回答它们。
如果您要报告您认为代码中存在错误的内容，则让黑客能够在受控环境中重现问题尤其重要。当你这样做时，你得到一个有用答案的几率和你得到这个答案的速度都会大大提高。
Simon Tatham写了一篇题为《如何有效地报告错误》的优秀文章。我强烈建议您阅读它。
您需要准确且信息丰富。不能通过简单地将大量代码或数据转储到帮助请求中来实现此目的。如果您有一个大型、复杂的测试用例正在破坏程序，请尝试对其进行修剪并使其尽可能小。
这至少有三个原因。第一：被看成投入精力来简化问题，使你更有可能得到答案，第二：简化问题使你更有可能得到一个有用的答案。三：在优化错误报告的过程中，您可以自己开发修复或解决方法。
当你在软件上遇到问题时，不要声称你发现了一个错误，除非你非常非常确定你的立场。提示：除非您能提供修复问题的源代码补丁，或者针对以前版本进行回归测试以证明不正确的行为，否则您可能还不够确定。这也适用于网页和文档;如果您发现文档"错误"，则应提供替换文本以及它应该继续的页面。
请记住，还有许多其他用户没有遇到您的问题。否则，你会在阅读文档和搜索网络时了解它（你在抱怨之前确实这样做了，不是吗？）。这意味着很可能是你做错了什么，而不是软件。
编写软件的人非常努力地工作，使其尽可能好地工作。如果你声称你发现了一个错误，你会质疑他们的能力，即使你是正确的，这可能会冒犯他们中的一些人。在主题行中大喊"bug"尤其不合情理。
在问你的问题时，最好写得好像你认为你做错了什么，即使你私下里非常确定你已经发现了一个真正的错误。如果真的有错误，你会在答案中听到它。玩它，这样维护者就会想向你道歉，如果错误是真实的，而不是这样，如果你搞砸了，你会欠他们一个道歉。
有些人认为他们不应该粗鲁或傲慢地行事，要求得到答案，他们退回到相反的极端。"我知道我只是一个可怜的新手失败者，但是......"。这是分散注意力和无益的。当它与对实际问题的模糊性相结合时，它尤其令人讨厌。
不要把你或我们的时间浪费在粗陋的灵长类动物政治上。相反，尽可能清楚地呈现背景事实和您的问题。这是比摸索更好的定位方式。
有时，Web 论坛为新手问题提供了单独的位置。如果您觉得自己确实有新手问题，请去那里。但也不要在那里摸索。
告诉黑客您认为导致问题的原因没有用。（如果你的诊断理论是如此热门，你会向别人寻求帮助吗？所以，确保你告诉他们出了什么问题的原始症状，而不是你的解释和理论。让他们做解释和诊断。如果你觉得陈述你的猜测很重要，请清楚地标记它，并解释为什么这个答案对你不起作用。
笨：
我在内核编译时收到背靠背的SIG11错误，并怀疑其中一个主板痕迹上有发际线裂缝。检查这些内容的最佳方法是什么？
聪明：
我在FIC-PA2007主板（VIA Apollo VP2芯片组）上使用256MB Corsair PC133 SDRAM自制的K6 / 233在内核编译过程中开机后约20分钟开始出现频繁的SIG11错误，但从未在前20分钟内出现过。重新启动不会重新启动时钟，但夜间关闭电源会重新启动。换掉所有RAM没有帮助。典型编译会话日志的相关部分如下。
由于前一点对许多人来说似乎很难理解，这里有一句话提醒你："所有诊断学家都来自密苏里州。美国的官方座右铭是"Show me"（1899年获得，当时国会议员Willard D. Vandiver说："我来自一个种植玉米，棉花，蛤蜊和民主党人的国家，泡沫般的口才既不能说服我，也不能满足我。我来自密苏里州。你得给我看看。在诊断学家的案例中，这不是一个怀疑的问题，而是一个字面上的，功能性的需要，即看到尽可能接近你所看到的原始证据，而不是你的推测和总结。向我们展示。
在找出错误的地方时，最有用的线索往往在于之前的事件。因此，您的帐户应该准确地描述您做了什么，以及机器和软件做了什么，导致爆炸。在命令行进程的情况下，拥有会话日志（例如，使用脚本实用程序）并引用相关的二十行左右是非常有用的。
如果启动的程序具有诊断选项（如 -v 表示详细），请尝试选择将有用的调试信息添加到脚本中的选项。请记住，更多不一定更好;尝试选择一个调试级别，该级别将通知而不是将读者淹没在垃圾中。
如果您的帐户最终很长（超过四个段落），那么在顶部简洁地说明问题可能会很有用，然后按时间顺序排列故事。这样，黑客将知道在阅读您的帐户时要注意什么。
如果您正在尝试了解如何执行某些操作（而不是报告错误），请从描述目标开始。只有这样，才能描述您被阻止的特定步骤。
通常，需要技术帮助的人心中有一个高层次的目标，并被困在他们认为是实现目标的特定路径上。他们来寻求帮助，但没有意识到这条路是错误的。克服这一点可能需要付出巨大的努力。
笨：
如何让 FooDraw 程序上的颜色选取器获取十六进制 RGB 值？
聪明：
我正在尝试用我选择的值替换图像上的颜色表。现在，我能看到的唯一方法是编辑每个表槽，但我无法让FooDraw的颜色选择器获取十六进制RGB值。
问题的第二个版本是聪明的。它允许一个答案，建议一个更适合任务的工具。
黑客认为，解决问题应该是一个公开的、透明的过程，在这个过程中，如果有人更了解答案，那么第一次尝试答案可以而且应该得到纠正。此外，帮助者从被同龄人视为有能力和知识渊博的受访者中获得一些奖励。
当您要求私人回复时，您正在破坏流程和奖励。别这样。受访者可以选择是否私下回复 - 如果他或她这样做，通常是因为他或她认为这个问题太不规则或太明显，其他人不会感兴趣。
此规则有一个有限的例外。如果你认为这个问题是这样的，你可能会得到许多非常相似的答案，那么神奇的词是"给我发电子邮件，我会总结小组的答案"。尝试为邮件列表或新闻组保存大量实质上相同的帖子是礼貌的 - 但你必须信守承诺进行总结。
开放式问题往往被视为开放式时间沉没。那些最有可能给你一个有用答案的人也是最忙的人（如果只是因为他们自己承担了最多的工作）。像这样的人对开放式时间下沉过敏，因此他们往往对开放式问题过敏。
如果您明确表示希望受访者做什么（提供指针，发送代码，检查补丁等），则更有可能获得有用的响应。这将集中他们的精力，并隐含地为受访者必须分配的时间和精力来帮助您设定上限。这很好。
要了解专家所在的世界，请将专业知识视为丰富的资源，将响应时间视为稀缺资源。你隐含地要求的时间投入越少，你就越有可能从一个真正优秀和非常忙碌的人那里得到答案。
因此，构建您的问题以最大限度地减少专家提出问题所需的时间是很有用的 - 但这通常与简化问题不是一回事。因此，例如，"你能给我一个很好的X解释吗？"通常是一个比"你能解释X吗？"更聪明的问题。如果你有一些故障代码，通常要求某人解释它有什么问题比要求某人修复它更聪明。
不要要求其他人调试您损坏的代码，而不给出他们应该搜索哪种类型的问题的提示。发布几百行代码，说"它不起作用"，会让你忽略。发布十几行代码，说"在第7行之后，我期望看到<x>，但发生了<y>"更有可能得到你的回应。
精确解决代码问题的最有效方法是提供最小的 bug 演示测试用例。什么是最小测试用例？这是问题的例证;只是足够的代码来展示不良行为，仅此而已。如何制作最小的测试用例？如果您知道哪一行或哪段代码正在产生有问题的行为，请复制它并添加足够的支持代码来生成完整的示例（即，足以使源代码被编译器/解释器/任何应用程序处理它所接受）。如果无法将其缩小到特定部分，请创建源的副本，并开始删除不影响有问题的行为的块。最小测试用例越小越好（请参阅"体积不是精度"一节）。
生成一个非常小的最小测试用例并不总是可能的，但尝试是很好的纪律。它可以帮助您了解自己解决问题所需的内容 - 即使没有，黑客也希望看到您已经尝试过。这将使他们更加合作。
如果你只是想进行代码审查，请提前说很多，并确保提到你认为可能特别需要审查的领域以及为什么。
黑客善于发现家庭作业问题;我们大多数人都自己做过。这些问题是给你解决的，这样你就会从经验中学习。询问提示是可以的，但不能要求整个解决方案。
如果您怀疑自己已经通过了家庭作业问题，但无论如何都无法解决，请尝试在用户组论坛中提问，或者（作为最后的手段）在项目的"用户"列表/论坛中提问。虽然黑客会发现它，但一些高级用户可能至少会给你一个提示。
抵制住用语义上为空的问题关闭你的求助请求的诱惑，比如"有人能帮我吗？"或"有答案吗？"首先：如果你已经把问题描述写得半途而废了，那么这种附加的问题充其量是多余的。其次：因为它们是多余的，黑客发现它们很烦人 - 并且可能会返回逻辑上无可挑剔但不屑一顾的答案，例如"是的，你可以得到帮助"和"不，你没有帮助"。
一般来说，问是或否问题是一件好事，除非你想要一个是或否的答案。
那是你的问题，不是我们的问题。声称紧迫性很可能适得其反：大多数黑客会简单地删除诸如粗鲁和自私的尝试之类的消息，以引起立即和特别的关注。此外，"紧急"一词（以及其他类似的在主题行中吸引注意力的尝试）通常会触发垃圾邮件过滤器 - 您的目标收件人可能根本看不到它！
有一个半例外。值得一提的是，如果您在某个备受瞩目的地方使用该程序，黑客会对此感到兴奋;在这种情况下，如果你在时间压力下，你礼貌地说，人们可能会有兴趣更快地回答。
但是，这是一件非常冒险的事情，因为黑客对令人兴奋的指标可能与你的不同。例如，从国际空间站发帖将符合条件，但代表感觉良好的慈善或政治事业发帖几乎肯定不会。事实上，发布"紧急：帮我拯救模糊的婴儿海豹！"会让你避开或被那些认为模糊的婴儿海豹很重要的黑客点燃。
如果您发现这很神秘，请反复阅读本操作方法的其余部分，直到您理解它，然后再发布任何内容。
要有礼貌。使用"请"和"感谢您的关注"或"感谢您的考虑"。明确表示你很欣赏人们花在免费帮助你上的时间。
说实话，这并不像语法，清晰，精确和描述性，避免专有格式等那么重要（也不能替代）;一般来说，黑客宁愿得到一些粗暴但技术上尖锐的错误报告，而不是礼貌的含糊不清。（如果这让你感到困惑，请记住，我们重视一个问题，因为它教会了我们什么。
但是，如果你连续遇到技术鸭子，礼貌确实会增加你获得有用答案的机会。
（我们必须注意，我们从资深黑客那里收到的对此HOWTO的唯一严重反对意见是关于我们之前使用"提前致谢"的建议。一些黑客认为这意味着事后不感谢任何人的意图。我们的建议是先说"提前感谢"，然后感谢受访者，或者以不同的方式表达礼貌，例如说"谢谢你的关注"或"谢谢你的考虑"。
问题解决后，向所有帮助您的人发送便笺;让他们知道它是如何出来的，并再次感谢他们的帮助。如果问题引起了邮件列表或新闻组的普遍兴趣，则在那里发布后续内容是合适的。
理想情况下，回复应该是由原始问题发布开始的线程，并且应该在主题行中具有"FIXED"，"RESOLVE"或同样明显的标签。在具有快速周转的邮件列表中，看到有关"问题X"的帖子以"问题X - FIXED"结尾的潜在受访者知道即使阅读该帖子也不要浪费他/她的时间（除非他个人认为问题X很有趣），因此可以利用该时间解决其他问题。
您的跟进不必很长且涉及;一个简单的"你好-这是一根失败的网络电缆！谢谢大家。- 比尔"总比没有好。事实上，简短而甜蜜的总结比长篇论文更好，除非解决方案具有真正的技术深度。说出什么操作解决了问题，但您不需要重播整个故障排除序列。
对于具有一定深度的问题，应发布疑难解答历史记录的摘要。描述您的最终问题陈述。描述什么作为解决方案有效，并指出之后可避免的死胡同。死胡同应该遵循正确的解决方案和其他摘要材料，而不是将后续变成侦探故事。说出帮助你的人的名字;你会以这种方式交朋友。
除了礼貌和信息丰富之外，这种后续行动还将帮助其他人搜索邮件列表/新闻组/论坛的存档，以确切地知道哪个解决方案对您有所帮助，因此也可能对他们有所帮助。
最后，同样重要的是，这种后续行动可以帮助每个提供帮助的人对问题有一种满意的结束感。如果您自己不是技术人员或黑客，请相信我们，这种感觉对您寻求帮助的大师和专家非常重要。拖入未解决的虚无的问题叙述是令人沮丧的事情;黑客渴望看到它们得到解决。挠痒痒能给你带来善意，下次你需要提出问题时，对你非常有帮助。
考虑一下如何防止其他人将来遇到同样的问题。问问自己，文档或FAQ补丁是否有帮助，如果答案是肯定的，请将该补丁发送给维护者。
在黑客中，这种良好的跟进行为实际上比传统的礼貌更重要。这就是你如何获得与他人合作的声誉，这可能是一个非常宝贵的资产。
有一个古老而神圣的传统：如果你得到一个写着"RTFM"的回复，发送它的人认为你应该阅读他妈的手册。他或她几乎肯定是对的。去读吧。
RTFM有一个年轻的亲戚。如果你收到一个回复，上面写着"STFW"，发送它的人认为你应该搜索了The Fucking Web。他或她几乎肯定是对的。去搜索吧。（更温和的版本是当你被告知"谷歌是你的朋友！)
在 Web 论坛中，您可能还会被告知要搜索论坛存档。事实上，有人甚至可能非常友善，以至于提供了指向解决此问题的上一个线程的指针。但不要依赖这种考虑;在询问之前进行存档搜索。
通常，告诉您进行搜索的人打开了包含所需信息的手册或网页，并在他或她键入时查看它。这些回复意味着响应者认为（a）您需要的信息很容易找到，并且（b）如果您寻找信息，您将学到更多，而不是将勺子喂给您。
你不应该为此感到生气;按照黑客的标准，你的受访者只是通过不忽视你来向你展示一种粗暴的尊重。相反，你应该感谢这种祖母般的善良。
如果您不明白答案，请不要立即反弹澄清要求。使用您用来尝试回答原始问题的相同工具（手册，常见问题解答，Web，熟练的朋友）来理解答案。然后，如果您仍然需要要求澄清，请展示您学到的知识。
例如，假设我告诉你："听起来你有一个卡住的禅宗;你需要清除它。然后：这里有一个不好的后续问题："什么是禅术？这里有一个很好的后续问题："好的，我读了手册页，zentries只在-z和-p开关下提到。他们都没有说任何关于清除中间地带的事情。是其中之一，还是我在这里错过了什么？
在黑客圈子里，许多看似粗鲁的东西并不是为了冒犯他人。相反，它是直接的，直截了当的废话沟通风格的产物，对于那些更关心解决问题而不是让别人感到温暖和模糊的人来说，这是很自然的。
当你察觉到粗鲁时，试着冷静地做出反应。如果有人真的在表演，那么列表或新闻组或论坛上的资深人士很可能会打电话给他或她。如果没有发生这种情况，你发脾气，那么你失去脾气的人很可能在黑客社区的规范范围内行事，你会被认为是有错的。这将损害您获得所需信息或帮助的机会。
另一方面，你偶尔会遇到粗鲁和姿态，这是非常无端的。上述内容的另一面是，用锋利的口头手术刀剖析他们的不当行为，用严厉的言语攻击手法，这是可以接受的。但是，在尝试之前，请非常非常确定您的位置。纠正不文明行为和开始毫无意义的火焰战争之间的界限足够细，黑客自己并不经常犯错。如果你是新手或局外人，你避免这种错误的机会很低。如果你追求的是信息而不是娱乐，那么最好让手指远离键盘，而不是冒险。
（有些人断言，许多黑客患有轻度自闭症或阿斯伯格综合症，实际上缺少一些润滑"正常"人类社交互动的大脑回路。这可能是也可能不是真的。如果你自己不是黑客，如果你认为我们脑残，它可能会帮助你应对我们的怪癖。继续前进。我们不会在乎;我们喜欢成为我们自己，并且通常对临床标签有健康的怀疑态度。
杰夫·比格勒（Jeff Bigler）对机敏过滤器的观察也是相关的，值得一读。
在下一节中，我们将讨论一个不同的问题;当你行为不端时，你会看到的那种"粗鲁"。
您很可能会在黑客社区论坛上搞砸几次 - 以本文或类似方式详细介绍的方式。你会被告知你是如何搞砸的，可能是五颜六色的。当众。
当这种情况发生时，你能做的最糟糕的事情就是抱怨这种经历，声称自己遭到了口头攻击，要求道歉，尖叫，屏住呼吸，威胁诉讼，向人们的雇主投诉，把马桶座圈放下，等等。相反，这是您要执行的操作：
克服它。这很正常。事实上，它是健康和适当的。
社区标准不会自我维护：它们是由人们在公共场合积极应用它们来维护的。不要抱怨所有的批评都应该通过私人电子邮件传达：这不是它的工作方式。当有人评论你的一个说法是错误的，或者他的观点不同时，坚持认为你受到了人身侮辱，这也是没有用的。这些都是失败者的态度。
在黑客论坛上，出于某种被误导的过度礼貌，参与者被禁止在别人的帖子中发布任何故障发现，并被告知"如果你不愿意帮助用户，不要说什么。由此产生的无知参与者离开到其他地方，导致他们陷入毫无意义的胡言乱语，并变得无用的技术论坛。
夸张的"友好"（以这种方式）或有用：选择一个。
记住：当那个黑客告诉你你搞砸了，并且（无论多么粗鲁地）告诉你不要再这样做时，他的行为是出于对（1）你和（2）他的社区的关心。对他来说，忽略你并将你从他的生活中过滤掉会容易得多。如果你不能设法感恩，至少要有一点尊严，不要抱怨，不要指望仅仅因为你是一个具有戏剧超敏感灵魂和权利妄想的新人而被当作一个脆弱的娃娃对待。
有时人们会攻击你，没有明显的理由就燃烧，等等，即使你没有搞砸（或者只是在他们的想象中搞砸了）。在这种情况下，抱怨是真正搞砸的方法。
这些火焰人要么是没有线索但认为自己是专家的抨击者，要么是潜在的心理学家，考验你是否会搞砸。其他读者要么忽略它们，要么自己想办法处理它们。火焰兵的行为会给自己带来问题，而这些问题不一定与你有关。
也不要让自己被卷入一场火焰战争。大多数火焰最好被忽略 - 在你检查它们是否真的是火焰之后，而不是指向你搞砸的方式的指针，而不是巧妙地加密你真实问题的答案（这也会发生）。
以下是一些经典的愚蠢问题，以及黑客在不回答这些问题时的想法。
问：我可以使用 Bass-o-matic 文件转换器将 AcmeCorp 文档转换为 TeX 文件吗？
| Q: | 在哪里可以找到程序或资源 X？ |
| 一个： | 傻瓜，我会找到它的同一个地方 - 在网络搜索的另一端。Ghod，不是每个人都知道如何使用谷歌吗？ |
| Q: | 如何使用 X 执行 Y？ |
| 一个： | 如果你想要的是做Y，你应该问这个问题，而不是预先假设使用可能不合适的方法。这种形式的问题通常表明一个人不仅对X一无所知，而且对他们正在解决的问题Y感到困惑，并且过于关注他们特定情况的细节。通常最好忽略这些人，直到他们更好地定义自己的问题。 |
| Q: | 如何配置我的 shell 提示符？ |
| 一个： | 如果你足够聪明，可以问这个问题，那么你就足够聪明，可以RTFM并找出自己。 |
| Q: | 我可以使用Bass-o-matic文件转换器将AcmeCorp文档转换为TeX文件吗？ |
| 一个： | 试试看。如果你这样做了，你会（a）知道答案，（b）停止浪费我的时间。 |
| Q: | 我的 {程序、配置、SQL 语句} 不起作用 |
| 一个： | 这不是一个问题，我对玩二十个问题来撬开你的实际问题不感兴趣 - 我有更好的事情要做。看到这样的东西时，我的反应通常是以下之一：
|
| Q: | 我的 Windows 计算机出现问题。你能帮忙吗？ |
| 一个： | 是的。扔掉微软的垃圾箱，安装Linux或BSD等开源操作系统。 注意：如果与Windows计算机相关的问题与具有官方Windows版本或与Windows计算机（即Samba）交互的程序有关。只是不要对问题出在Windows而不是程序上的回复感到惊讶，因为Windows通常是如此破碎，以至于这种情况经常发生。 |
| Q: | 我的程序不起作用。我认为系统设施X坏了。 |
| 一个： | 虽然您可能是第一个注意到成百上千人大量使用的系统调用和库存在明显缺陷的人，但更有可能的是，您完全无能为力。非同寻常的索赔需要非同寻常的证据;当您提出这样的索赔时，您必须使用故障案例的清晰详尽的文档来支持它。 |
| Q: | 我在安装 Linux 或 X 时遇到问题。你能帮忙吗？ |
| 一个： | 不。我需要亲自动操作才能访问您的计算机才能解决此问题。去向你当地的 Linux 用户组寻求实践帮助。（您可以在此处找到用户组列表。 注意：如果您在有关特定发行版的论坛或邮件列表中，则有关安装Linux的问题可能是合适的，并且问题出在该发行版上;或在本地用户组论坛上。在这种情况下，请务必描述失败的确切详细信息。但是，首先要仔细搜索"linux"和所有可疑的硬件。 |
| Q: | 如何破解根目录/窃取频道操作权限/阅读某人的电子邮件？ |
| 一个： | 你是一个想要做这样的事情的贱人，也是一个要求黑客帮助你的白痴。 |
最后，我将通过示例说明如何以聪明的方式提出问题;关于同一问题的成对问题，一个以愚蠢的方式提出，一个以聪明的方式提出。
笨：在哪里可以找到有关Foonly Flurbamatic的信息？
这个问题只是乞求"STFW"作为回答。
聪明：我使用Google尝试在网络上找到"Foonly Flurbamatic 2600"，但我没有得到有用的点击。我能否获取指向此设备上编程信息的指针？
这个已经STFWed，听起来可能有一个真正的问题。
笨：我无法从项目foo中获取代码以进行编译。为什么会坏掉？
querent假设是别人搞砸了。傲慢的git...
聪明：来自 project foo 的代码无法在 Nulix 版本 6.2 下编译。我已经阅读了常见问题解答，但它没有任何关于Nulix相关问题的内容。这是我的编译尝试的记录;是我做的吗？
querent已经指定了环境，阅读了FAQ，显示了错误，并且没有假设他的问题是别人的错。这个可能值得关注。
笨：我的主板有问题。任何人都可以帮忙吗？
J. Random Hacker对此的回应很可能是"对。你还需要打嗝和尿布吗？后跟删除键的打孔。
聪明：我在S2464主板上尝试了X，Y和Z。当这不起作用时，我尝试了A，B和C.注意我尝试C时奇怪的症状.显然，florbish是令人眼花缭乱的，但结果不是人们所期望的。速龙 MP 主板上出现索花纹的常见原因是什么？有人有想法可以运行更多测试来确定问题吗？
另一方面，这个人似乎值得一个答案。他/她表现出解决问题的智慧，而不是被动地等待答案从高处掉下来。
在最后一个问题中，请注意要求"给我一个答案"和"请帮我弄清楚我可以运行哪些额外的诊断来实现启蒙"之间微妙但重要的区别。
事实上，最后一个问题的形式完全基于2001年8月在linux内核邮件列表（lkml）上发生的真实事件。我（埃里克）是那个时候问这个问题的人。我在Tyan S2462主板上看到神秘的锁定。列表成员提供了解决这些问题所需的关键信息。
通过以我的方式提出问题，我给了人们一些可以咀嚼的东西;我让他们很容易和有吸引力地参与其中。我尊重同龄人的能力，并邀请他们以同龄人的身份与我进行咨询。我还通过告诉他们我已经跑掉的死胡同来表达对他们时间价值的尊重。
之后，当我感谢大家并评论这个过程的运作情况时，一位lkml成员观察到他认为它之所以有效，不是因为我是该名单上的"名字"，而是因为我以适当的形式提出了这个问题。
黑客在某些方面是一个非常无情的精英统治;我确信他是对的，如果我表现得像海绵一样，无论我是谁，我都会被火焰或忽视。他建议我把整个事件写成对其他人的指导，这直接导致了本指南的撰写。
如果您无法得到答案，请不要认为我们觉得我们无法为您提供帮助。有时，被问小组的成员可能根本不知道答案。没有回应与被忽视是不一样的，尽管不可否认，很难从外部发现差异。
一般来说，简单地重新发布你的问题是一个坏主意。这将被视为毫无意义的烦人。要有耐心：有你答案的人可能在不同的时区，睡着了。或者可能是你的问题一开始就没有很好地形成。
您还可以获得其他帮助来源，通常这些来源更适合新手的需求。
有许多在线和本地用户组是该软件的爱好者，即使他们自己可能从未编写过任何软件。这些小组通常形成，以便人们可以互相帮助并帮助新用户。
您还可以与许多商业公司签订合同寻求帮助，无论大小。不要对不得不支付一点帮助的想法感到沮丧！毕竟，如果您的汽车发动机吹坏了头部垫圈，您很可能会将其带到维修店并支付修理费用。即使该软件没有花费您任何东西，您也不能指望这种支持总是免费的。
对于像Linux这样的流行软件，每个开发人员至少有10，000个用户。一个人不可能处理来自10，000多个用户的支持电话。请记住，即使您必须支付支持费用，您仍然需要支付的费用也比购买软件的费用要少得多（并且对闭源软件的支持通常比对开源软件的支持更昂贵，更不称职）。
要温柔。与问题相关的压力会使人们看起来粗鲁或愚蠢，即使他们不是。
离线回复初犯。对于可能犯了诚实错误的人来说，没有必要公开羞辱。真正的新手可能不知道如何搜索档案或常见问题解答的存储或发布位置。
如果您不确定，请说出来！一个错误但听起来很权威的答案总比没有更糟糕。不要仅仅因为听起来像专家很有趣，就把任何人指向一条错误的道路。谦虚诚实;为奎伦特和你的同行树立一个好榜样。
如果你无能为力，不要阻碍。不要拿那些可能会破坏用户设置的过程开玩笑——可怜的sap可能会把这些解释为指令。
提出探究性问题以引发更多细节。如果你擅长这个，querent会学到一些东西——你也会学到。试着把坏问题变成一个好问题;记得我们曾经都是新手。
虽然在回复只是一个懒惰的人时，嘀咕RTFM有时是合理的，但指向文档的指针（即使它只是谷歌搜索关键短语的建议）更好。
如果您要回答这个问题，请提供良好的价值。当有人使用错误的工具或方法时，不要建议笨拙的解决方法。建议好的工具。重新构建问题。
回答实际问题！如果 querent 已经非常彻底地进行了他或她的研究，并且已经在查询中包含了 X、Y、Z、A、B 和 C 已经尝试过而没有好的结果，那么用"尝试 A 或 B"来回应，或者用一个链接到只说"尝试 X， Y、Z、A、B 或 C."。
帮助您的社区从问题中学习。当你提出一个好问题时，问问自己"相关文档或常见问题解答必须如何更改，以便没有人必须再次回答这个问题？然后向文档维护者发送补丁。
如果你做了研究来回答这个问题，展示你的技能，而不是像你从屁股上拉出答案一样写作。回答一个好问题就像给饥饿的人喂一顿饭，但通过例子教他们研究技能是向他们展示如何种植一生的食物。
如果您需要有关个人计算机、Unix 和 Internet 如何工作的基础知识的说明，请参阅 The Unix 和 Internet Fundamentals HOWTO。
当您发布软件或为软件编写修补程序时，请尝试遵循软件发布实践操作指南中的准则。
伊芙琳·米切尔（Evelyn Mitchell）贡献了一些愚蠢的问题，并启发了"如何给出一个好答案"部分。米哈伊尔·拉门迪克（Mikhail Ramendik）提出了一些特别有价值的改进建议。
参考文献：
532
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
