# 问题解决后 (/docs/after-questions)
问题解决后，不要让讨论无声无息地停在半路。向所有帮助过你的人发一条说明，让他们知道问题是怎样解决的，并再次表达感谢。如果问题曾在新闻组、邮件列表、论坛或 Issue 区引起关注，最好就在原讨论串里补充结论。
## 在原讨论中标记结果 [#在原讨论中标记结果]
最理想的方式是回复最初提问的话题，并在标题中包含 `已修正`、`已解决` 或其它含义明确的标记。在人来人往的邮件列表里，一个看见讨论串 `问题 X` 和 `问题 X - 已解决` 的潜在回复者，会立刻明白自己不必再投入时间，除非他对这个问题本身感兴趣。
这能节省社区的注意力，也能让后来搜索相同问题的人直接找到结论。
## 写一个足够有用的小结 [#写一个足够有用的小结]
补充说明不必很长，也不必把整个过程复述一遍。简单的一句 `你好，原来是网线出了问题！谢谢大家 - Bill`，也比什么都不说要好。除非结论本身很有技术含量，否则简短、明确的小结通常比长篇大论更有价值。
一个好的结案回复通常包含：
* 最终确认的问题原因。
* 真正有效的解决办法。
* 关键环境、版本或配置差异。
* 哪些猜测最终被排除。
* 对帮助者的感谢。
对于有深度的问题，张贴调试记录摘要也很有帮助。先描述最终状态和解决方案，**之后**再说明过程中有哪些可以避免的盲点。不要把结论写成侦探小说；后来者最需要的是可检索、可复现、可参考的答案。
## 把经验留给后来者 [#把经验留给后来者]
除了礼貌之外，这类补充还能帮助其他人在邮件列表、新闻群组、论坛或搜索引擎中找到真正解决问题的方案。你的结案回复可能会在很长一段时间里节省许多人的时间。
如果这个问题暴露了文档缺口、FAQ 缺失或教程误导，请进一步想一想：是否可以补一段文档、提交一个 FAQ 条目，或者向维护者发一个小补丁？这类后续行动往往比单纯说“谢谢”更有价值。
## 让帮助者看到结果 [#让帮助者看到结果]
至少，这种补充能让每位参与协助的人从问题解决中得到满足感。如果你自己不是技术专家，就相信我们：这种满足感对那些自愿帮助你的人非常重要。问题悬而未决会让人灰心；看到问题被解决，会让人愿意继续帮助下一个认真提问的人。
在黑客文化中，良好的后续行动不仅是礼貌，更是声誉的一部分。你善待帮助过你的人，也是在为下一次获得帮助积累信用。
# 在提问之前 (/docs/before-questions)
在你准备通过电子邮件、论坛、Issue 区、新闻群组或聊天室提出技术问题之前，请先停下来做一轮准备。提问不是把麻烦转交给别人，而是把你已经观察到的事实、已经尝试过的路径，以及仍然无法理解的部分整理出来，让别人可以接着判断。
## 先自己找一轮答案 [#先自己找一轮答案]
在发出问题之前，至少尝试下面这些事情：
1. 在你准备提问的论坛、邮件列表或 Issue 区中搜索旧文章。
2. 使用搜索引擎查找错误信息、关键日志、异常名称或具体行为。
3. 阅读手册、官方文档、命令帮助或 API 说明。
4. 阅读常见问题文件（FAQ）、故障排查指南和已知问题列表。
5. 自己做最小化检查或实验，确认问题是否能稳定复现。
6. 向身边更有经验的朋友、同事或同学请教。
7. 如果你是程序开发者，请阅读相关源代码、测试用例或变更记录。
这一步的目的不是证明你已经无所不知，而是尽量排除那些已经有明确答案、只需要耐心查找的问题。你先完成这轮工作，别人接手时才不必从最基础的地方重新替你走一遍。
## 让别人看见你的努力 [#让别人看见你的努力]
当你提出问题时，请主动说明你已经做过哪些尝试。比如你搜索过哪些关键词，读过哪些文档，尝试过哪些配置，得到过哪些错误结果。这样做能让回答者知道，你并不是一个不劳而获、随手把问题丢给社区的人。
如果可以，请进一步说明你在这些尝试中**学到了什么**。例如：
* 你发现问题只在某个版本出现。
* 你确认同一段配置在另一台机器上可以工作。
* 你排除了权限、网络、路径或依赖版本中的某一类原因。
* 你找到过相似问题，但它的前提条件与你不同。
这些信息比一句“我试过了，没用”有价值得多。它们能帮助别人快速判断下一步该看哪里，也能让你的问题成为后来者可以搜索和复用的资料。
## 搜索不是形式，而是缩小问题 [#搜索不是形式而是缩小问题]
善用搜索引擎，尤其要搜索完整的错误信息、异常类型、关键日志片段、命令输出和库版本号。对于历史资料较多的技术，也可以搜索 [Google 论坛](http://groups.google.com/)、项目邮件列表、Issue 区和问答站点。
即使搜索没有直接给出答案，也请把搜索过程写进问题中。例如：
`我用 Google 搜索过 "exact error message here"、"library name version error"，但找到的结果都针对旧版本，和我现在的环境不一致。`
这句话的价值不只是表明你努力过。它还告诉回答者哪些路径已经走不通，避免他们重复给出你已经验证过的建议。同时，包含搜索词的问题也更容易被搜索引擎收录，未来遇到相似问题的人更可能找到你的讨论。
## 给问题一点冷却时间 [#给问题一点冷却时间]
别着急，不要指望几秒钟的搜索就解决一个复杂问题。很多技术问题需要你多读几段文档、多试几个变量、多比较几组现象，才能看清真正的矛盾在哪里。
在向专家求助之前，可以再做一次短暂复盘：
1. 我能否用一句话说清楚我想达到的目标？
2. 我能否稳定复现这个问题？
3. 我是否记录了环境、版本、输入、输出和错误信息？
4. 我是否知道哪些因素已经被排除？
5. 我的问题是否只包含一个清晰的主题，而不是把许多无关问题混在一起？
草率的问题通常只能得到草率的回答，甚至根本得不到回答。越能表现出你在求助前付出的阅读、实验和思考，你越有可能得到实质性的帮助。
## 避免带着错误假设发问 [#避免带着错误假设发问]
小心别问错了问题。很多糟糕的问题并不是因为提问者不会描述现象，而是因为他们过早认定了原因。例如，问题明明可能是权限、路径、版本冲突或输入格式导致的，却直接问“为什么这个库有 bug”。
如果你的问题建立在错误假设上，回答者可能只能纠正你的假设，而不是给出你期待的答案。更好的做法是把事实和猜测分开：
* 事实：我执行了什么命令，输入是什么，实际输出是什么。
* 预期：我原本以为会发生什么。
* 猜测：我怀疑可能和某个配置有关，但还没有证据。
* 求助点：我应该继续检查哪一层？
这样写能给回答者留下判断空间，也能减少他们被迫拆解错误前提的成本。
## 用行动换来答案 [#用行动换来答案]
绝不要自以为**理应**得到答案。你没有为社区成员的时间付费，也没有资格要求别人无条件替你解决问题。你能得到答案，是靠自己提出有内涵、有边界、有思考价值的问题去**挣到**的。
这并不意味着你必须已经接近答案。相反，只要你表现出愿意继续行动，问题就更容易得到回应。下面这些问法通常比“请把完整步骤发给我”更有效：
* `谁能给我一点排查方向？`
* `这个最小示例里还缺了什么关键信息？`
* `我应该优先检查权限、依赖版本，还是输入格式？`
* `我目前的推断是否有明显错误？`
这些问法传达了一件重要的事：只要有人能指出正确方向，你就愿意继续完成剩下的工作。对技术社区来说，这样的提问者值得帮助。
# 好问题和坏问题 (/docs/good-or-bad-question)
最后，我们通过几个对照例子来说明什么叫“聪明地提问”。同一个问题会以两种方式出现：一种暴露出懒惰、傲慢或信息不足，另一种则展示了准备、边界和可协作性。
阅读这些例子时，不要只记住句式。真正重要的是背后的判断标准：你是否说明了目标，是否展示了尝试，是否给出了环境，是否把责任推给别人，是否让回答者有足够的信息继续分析。
## 查找资料类问题 [#查找资料类问题]
**蠢问题**：
> 我可以在哪儿找到关于 Foonly Flurbamatic 的资料？
这种问法无非想得到 [STFW](#RTFM) 这样的回答。
**聪明问题**：
> 我用 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 内核邮件列表的成员表示，他觉得我的问题得到解决并非由于我是这个列表中的**名**人，而是因为我用了正确的方式来提问。
黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙；我相信他是对的，如果我**像**个乞讨者那样提问，不论我是谁，一定会惹恼某些人或者被他们忽视。他建议我记下这件事，这直接导致了本指南的出现。
一个好问题不保证一定有人回答，但它会显著提高别人愿意投入时间的概率。它传达的不是“替我完成工作”，而是“我已经做了该做的准备，现在需要更有经验的人帮助我继续判断”。
# 如何更好的回答问题 (/docs/how-to-answer-well)
好的技术社区不只需要会提问的人，也需要会回答的人。回答问题时，你既是在解决一个具体问题，也是在示范社区如何思考、如何表达、如何维护质量。
## 先假设对方可能只是紧张 [#先假设对方可能只是紧张]
**态度和善一点。** 问题带来的压力常使人显得无礼或愚蠢，但很多时候他们只是焦虑、困惑或缺乏经验。
**对初犯者私下回复。** 对那些坦诚犯错的人，没有必要当众羞辱。一个真正的新手也许连怎么搜索、该去哪里找 FAQ、怎样贴错误日志都不知道。私下提醒能解决的问题，不必公开放大。
## 不确定时要诚实 [#不确定时要诚实]
**如果你不确定，一定要说出来！** 一个听起来权威的错误回复，比没有回复还糟。不要因为扮演专家很有趣，就给别人乱指路。谦虚和诚实能给提问者与旁观者都树立好榜样。
**如果帮不了忙，也别妨碍他。** 不要在实际操作步骤上开玩笑。错误命令、伪造参数或危险建议可能会毁掉提问者的环境；总有人会把它们当成真的指令执行。
## 用反问帮助对方补齐信息 [#用反问帮助对方补齐信息]
**试探性的反问以引出更多细节。** 如果你做得好，提问者可以学到东西，你也可以。试着把一个粗糙问题引导成好问题：询问版本、环境、复现步骤、完整错误信息、预期结果和已经尝试过的路径。
尽管对懒惰问题抱怨一句 RTFM 有时是正当的，但给出文档链接、FAQ 入口，甚至只是建议几个更有效的搜索关键词，通常会更有帮助。
## 真要回答，就认真回答 [#真要回答就认真回答]
**如果你决定回答，就请给出好的答案。** 当别人正在使用错误工具或错误方法时，不要只给一个笨拙的权宜之计（workaround）。更好的回答是推荐合适的工具，重新界定问题，并解释为什么原方向不合适。
**正面地回答问题。** 如果提问者已经深入研究，并说明试过 X、Y、Z、A、B、C 但没有结果，回答 `试试看 A 或 B`，或者把同一组建议原样贴回去并附一个链接，几乎没有价值。你应该基于他已经提供的信息继续推进。
## 让社区从一次回答中受益 [#让社区从一次回答中受益]
**帮助你的社区从问题中学习。** 当你回复一个好问题时，可以问问自己：`如何修改相关文档或 FAQ，才能避免以后反复回答同样的问题？` 如果答案明确，就向文档维护者提交补丁或建议。
如果你是在研究一番后才作出回答，**展现你的技巧，而不是只端出结果**。解释你如何定位问题、如何排除可能性、为什么选择这个方案。毕竟，`授人以鱼不如授人以渔`。
# 如何避免扮演失败者 (/docs/how-to-avoid-being-loser)
在黑客社区的论坛中，即使你已经努力遵循本指南，也可能有几次搞砸。你可能会在公开场合被指出哪里做错了，而且语气未必温和。
## 被指出错误时先稳住 [#被指出错误时先稳住]
这种事发生以后，最糟糕的反应是哀嚎自己的遭遇、宣称遭到攻击、要求对方道歉、高声尖叫、憋闷气、威胁诉诸法律，或者跑去向对方的雇主投诉。相反，你应该先熬过去。
这很正常。事实上，它对社区是有益且合理的。公开技术社区需要公开的标准，而标准不会自行维持，它们是通过参与者积极而**公开地**执行来维持的。
不要坚持认为所有批评都应该通过私下邮件传送。它通常不是这样运作的。当有人指出你的说法有误、问题描述不足或假设站不住脚时，把这类反馈一概理解为人身攻击并没有帮助。
## 分清“不舒服”和“没价值” [#分清不舒服和没价值]
也有一些论坛受过度礼节要求误导，禁止参与者指出别人帖子里的问题，并声称 `如果你不想帮助用户就闭嘴。` 结果往往是有想法的参与者纷纷离开，留下毫无意义的唠叨和低质量讨论。
夸张地说，你要的是这种表面“友善”，还是能真正解决问题的讨论？两个里面通常只能挑一个。
记住：当黑客说你搞砸了，并且告诉你不要再这样做时，他通常是在关心**你**和**他的社区**。对他而言，完全忽略你、把你从自己的生活中过滤掉，反而更省事。如果你做不到感谢，至少要表现得有尊严，别把每一次刺耳反馈都当成别人必须照顾你的证明。
## 遇到真正的攻击怎么办 [#遇到真正的攻击怎么办]
有时候，即使你没有搞砸，或者只是在对方想象中搞砸了，也会有人无缘无故地攻击你本人。在这种情况下，抱怨反而**真的**可能把问题搞砸。
这些来找麻烦的人，要么是毫无办法却自以为是专家的家伙，要么是在测试你是否真的会失控。其他读者通常会忽略他们，或用自己的方式处理他们。这些人在给自己制造麻烦，不一定需要你亲自处理。
## 不要卷入口水战 [#不要卷入口水战]
最好不要理睬大多数口水战。当然，在忽略之前，你需要先确认两件事：
1. 它确实只是口水战，而不是指出了你真实的问题。
2. 它没有把真正的答案或关键线索藏在刺耳表达后面。
如果确认只是挑衅，就让它过去。你越能把注意力放回事实、证据、复现步骤和解决方案上，就越不像一个失败者。
# 如果无法得到解答 (/docs/if-cannot-get-answer)
如果仍得不到回答，请不要以为我们觉得无法帮助你。有时只是看到你问题的人不知道答案罢了。没有回应不代表你被忽视，虽然不可否认这种差别很难区分。
## 不要立刻重复张贴 [#不要立刻重复张贴]
总的来说，简单地重复张贴问题是个很糟的点子。这会被视为无意义的喧闹。有点耐心，知道答案的人可能生活在不同的时区，可能正在睡觉，也可能暂时没有看到你的问题。
也有可能，你的问题一开始就没有组织好。与其原样重发，不如先重新检查标题、环境信息、复现步骤、错误输出和你已经尝试过的路径。
## 换一个更合适的渠道 [#换一个更合适的渠道]
你可以通过其他渠道获得帮助，而这些渠道通常更适合初学者。许多线上和本地用户群组由热情的软件爱好者组成，他们未必亲自写过软件，但很愿意互相帮助，也更习惯回答入门问题。
如果问题属于特定发行版、硬件、商业软件、云服务或组织内部环境，也应该优先寻找对应的用户群、供应商支持、官方论坛或本地社区。换渠道不是逃避，而是把问题送到更可能有人理解上下文的地方。
## 接受付费支持也是正常选择 [#接受付费支持也是正常选择]
另外，你也可以向商业公司寻求帮助，不论公司大还是小。别因为需要付费才能获得帮助而感到沮丧。假如你的汽车发动机汽缸密封圈爆掉了，你会把车送到修车铺，并为维修付费。软件没有花钱，并不意味着技术支持也必须永久免费。
对于 Linux 这类大众化软件，每个开发者可能对应成千上万名用户。一个人不可能处理所有求助请求。即使你要为协助付费，和购买同类封闭软件相比，成本通常也并不夸张；而且开源生态中的付费支持往往更直接、更透明。
## 重新整理后再回来 [#重新整理后再回来]
如果你仍想在原社区继续提问，请先改进问题本身，而不是机械重复。把你新增的发现、缩小后的范围、排除过的原因、仍然卡住的地方写清楚。一个经过重新整理的问题，远比同一段文字的第二次、第三次张贴更值得回应。
# 提问的智慧 (/docs)
这份文档讨论的不是“怎样显得礼貌”，而是怎样把一个混乱的问题，整理成值得他人投入判断的问题。
在技术社区里，提问是一种协作邀请。你给出的事实越清楚，推理越诚实，边界越分明，回答者就越容易与你站到同一张地图前，判断下一步该往哪里走。
## 从哪里开始 [#从哪里开始]
如果你第一次阅读，可以先从“简介”和“在提问之前”开始，理解技术社区为什么如此看重准备工作。真正准备发问时，再进入“正在提问时”，逐项检查你的标题、上下文、症状、目标和尝试。
如果你已经得到了回复，也不要急着结束。后续的总结、感谢、归档和反馈，同样会影响别人是否愿意在下一次继续帮助你。
# 简介 (/docs/introduction)
## 为什么提问方式很重要 [#为什么提问方式很重要]
在[黑客](http://www.catb.org/~esr/faqs/hacker-howto.html)的世界里，你能否得到一个有用、准确且迅速的答案，往往不取决于你问题的严重程度，而是你**如何提问**。换句话说，**会提问，才能真正得到帮助**。本指南正是为了帮助你学会提问的艺术，从而提高你获取有效技术支持的概率。
如今，随着开源（Open Source）软件的蓬勃发展，越来越多的用户不再依赖官方客服，而是通过邮件列表、论坛、Issue 区、IRC、Discord 等社区渠道向其他用户寻求帮助。幸运的是，这些社区中有许多经验丰富、乐于分享的人，愿意提供近乎“黑客级别”的回答——甚至有时比开发者还专业。这是一件**好事**。
不过，要想让这些人认真对待你的问题，你也必须表现出一定的基本素养。我们在本指南中推荐的方法，不仅适用于黑客社区，同样适用于任何由资深用户主导的技术社群。你对他人时间和认知的尊重，是你能否获得帮助的第一步。
## 什么是“好问题”？ [#什么是好问题]
黑客喜欢富有挑战的问题、逻辑清晰的问题、能激发他们思维的问题。一个问题如果能引发深入的技术讨论、揭示软件设计的盲点，甚至带来工具层面的改进，那么它不仅是你的一次求助，更可能是一次对整个社区的馈赠。**“好问题！”** 是我们能给予他人的最高赞美之一。
一个提出得当的问题，可以帮助他人更深入理解自己的系统或代码，也可能揭示文档中的遗漏与设计中的缺陷。这种问题，我们不但愿意回答，还会乐在其中。
## 为什么我们不喜欢“差问题”？ [#为什么我们不喜欢差问题]
黑客群体常被人误解为“对新手不友善”，但问题的关键并不是“你是不是新手”，而是你有没有付出足够的努力。
我们鄙视的是那些不愿意动脑、不做任何尝试、不搜索就伸手的人。他们一上来就说“XX 不能用，帮我解决”，连一句清晰的描述、环境信息都不提供。这些人只想索取，从不考虑反馈、总结、归档或贡献。他们浪费了所有人的时间，我们称他们为 `失败者（loser）`，有时为了幽默也写作 `luser`。
请记住，我们并不是职业客服。我们是因为热爱技术而自愿抽出宝贵时间来维护社区、分享知识的人。我们每天都可能收到几十甚至上百个问题，不可能一一回答。为了效率和精神健康，我们必须对问题进行优先级筛选。你表现得像个 winner，你的问题才会被认真对待。
## 我们理解你的角色，但你也要理解我们的边界 [#我们理解你的角色但你也要理解我们的边界]
我们知道，大多数人使用计算机是为了完成自己的工作，而不是沉迷于技术细节。他们有其他的兴趣、职业与生活目标，不愿投入过多时间去研究底层原理。这很正常，我们完全接受这一点。
但这也意味着，如果你不愿自己解决问题，那你可以通过签约商业技术支持服务获得帮助，而不是试图免费获得黑客社区的时间。
我们欢迎所有愿意学习、尊重知识、尊重时间的人加入我们的文化。无知不可怕，愿意成长的人随时受到欢迎。但如果你不愿思考，甚至拒绝学习，我们不会勉强你，只是也不会浪费时间在你身上。
## 想得到解答？那就学会如何提问 [#想得到解答那就学会如何提问]
你不需要是专家，也不必装作无所不知。你只需要展现出你正在努力思考、观察现象、排查可能性，并且愿意主动配合。你的问题应该具体、清晰、有条理；你应该展示你做过哪些尝试；你应该在提问前搜索是否有相似问题已经解决。
表现得像个 winner：**机敏、自信、条理清晰，具备基本逻辑思维，并尊重他人的时间**。哪怕你暂时遇到了瓶颈，只要方法得当，社区几乎一定愿意提供帮助。
## 最后 [#最后]
如果你想为本指南提供反馈或提出改进建议，我们也欢迎。但请注意，这不是一份通用的“网络礼仪”文档，而是一份**针对技术社区有效提问方式的实战指南**。我们通常不会接受那些无助于提升问题质量的建议。
你可以将建议发送至：
[01@liushen.fun](mailto:01@liushen.fun)
让我们共同努力，构建一个更加高效、友好、互助的技术社区。
# 一些不该问的问题 (/docs/questions-you-cannot-ask)
以下是几个经典的糟糕问题，以及黑客没有回答时心中可能会想的事情。它们的共同点不是“问题太简单”，而是提问者没有展示必要的准备、边界和判断。
先看目录，再看每个例子背后的原因：
问题：[我能在哪找到 X 程序或 X 资源？](#q1)
问题：[我怎样用 X 做 Y？](#q2)
问题：[如何设定我的 shell 提示？](#q3)
问题：[我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 文件转换为 TeX 格式吗？](#q4)
问题：[我的程序/设定/SQL 语句没有用](#q5)
问题：[我的 Windows 电脑有问题，你能帮我吗？](#q6)
问题：[我的程序不会动了，我认为系统工具 X 有问题](#q7)
问题：[我在安装 Linux（或者 X ）时有问题，你能帮我吗？](#q8)
问题：[我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？](#q9)
***
## 把搜索任务直接丢给别人 [#把搜索任务直接丢给别人]
> 问题：我能在哪找到 X 程序或 X 资源？
回答：就在我找到它的地方啊，白痴 —— 搜索引擎的那一头。天哪！难道还有人不会用 [Google](https://www.google.com) 吗？
这类问题的问题在于，它没有展示任何搜索或筛选过程。更好的问法应该说明你查过哪些关键词、找到了哪些候选结果、为什么它们不适用。
## 把手段误当成目标 [#把手段误当成目标]
> 问题：我怎样用 X 做 Y？
回答：如果你想解决的是 Y ，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对 X 完全无知，也对 Y 要解决的问题糊涂，还被特定形势禁锢了思维。最好忽略这种人，等他们把问题搞清楚了再说。
如果你真正想解决的是 Y，就直接描述 Y 的目标、约束和上下文。也许 X 根本不是合适工具，过早限定手段只会让回答者被迫沿着错误方向帮你。
## 不愿阅读基础文档 [#不愿阅读基础文档]
> 问题：如何设定我的 shell 提示？？
回答：如果你有足够的智慧提这个问题，你也该有足够的智慧去 [RTFM](#RTFM)，然后自己去找出来。
这类问题通常可以从手册、FAQ 或入门文档里直接找到答案。如果你已经阅读过相关材料，请指出你卡住的具体段落，而不是把整件事交给别人重讲一遍。
## 不愿自己做最小实验 [#不愿自己做最小实验]
> 问题：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 文件转换为 TeX 格式吗？
回答：试试看就知道了。如果你试过，你就知道了答案，就不用浪费我的时间了。
如果实验成本很低，请先自己试。提问可以围绕“为什么这个实验结果和预期不一致”，而不是要求别人替你做本该由你完成的确认。
## 没有描述具体问题 [#没有描述具体问题]
> 问题：我的「程序/设定/SQL 语句」没有用
回答：这不算是问题吧，我对要我问你二十个问题才找得出你真正问题的问题没兴趣 —— 我有更有意思的事要做呢。在看到这类问题的时候，我的反应通常不外如下三种
* 你还有什么要补充的吗？
* 真糟糕，希望你能搞定。
* 这关我屁事？
“没有用”不是可诊断的信息。你需要说明你做了什么、期望发生什么、实际发生什么、完整错误信息是什么，以及你已经排除了哪些原因。
## 把平台问题扔给不相关的人 [#把平台问题扔给不相关的人]
> 问题：我的 Windows 电脑有问题，你能帮我吗？
回答：能啊，扔掉微软的垃圾，换个像 Linux 或 BSD 的开源操作系统吧。
注意：如果程序有官方版 Windows 或者与 Windows 有互动（如 Samba），你**可以**问与 Windows 相关的问题，只是别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶， 因为 Windows 一般来说实在太烂，这种说法通常都是对的。
关键不是“不能问 Windows”，而是要问对地方、问对范围。与项目本身有关的问题可以问项目社区；纯粹的系统使用问题则应找更合适的 Windows 支持渠道。
## 指控基础工具有问题却没有证据 [#指控基础工具有问题却没有证据]
> 问题：我的程序不会动了，我认为系统工具 X 有问题
回答：你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与函数库文件有明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据，当你这样声称时，你必须有清楚而详尽的缺陷说明文件作后盾。
越是指向底层、通用、被大量使用的组件，就越需要严谨证据。先假设自己的环境、输入、用法或理解可能有误，再用最小复现和清晰日志支持你的判断。
## 需要现场操作的问题 [#需要现场操作的问题]
> 问题：我在安装 Linux（或者 X ）时有问题，你能帮我吗？
回答：不能，我只有亲自在你的电脑上动手才能找到毛病。还是去找你当地的 Linux 使用群组者寻求实际的指导吧（你能在[这儿](http://www.linux.org/groups/index.html)找到用户群组的清单）。
注意：如果安装问题与某 Linux 的发行版有关，在它的邮件列表、论坛或本地用户群组中提问也许是恰当的。此时，应描述问题的准确细节。在此之前，先用 `Linux` 和**所有**被怀疑的硬件作关键词仔细搜索。
安装类问题常常依赖现场环境、硬件状态和屏幕输出。如果无法提供足够细节，本地用户群组、发行版社区或能远程查看环境的支持渠道，通常更适合处理这类问题。
## 请求非法或恶意行为 [#请求非法或恶意行为]
> 问题：我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？
回答：想要这样做，说明了你是个卑鄙小人；想找个黑客帮你，说明你是个白痴！
不要把破坏、窃取、绕过授权或侵犯隐私包装成“技术问题”。负责任的技术社区不会帮助你伤害别人，也不会为了展示技术能力而参与违法或不道德的行为。
## 总结 [#总结]
这些问题之所以糟糕，是因为它们把搜索、实验、定义目标、提供证据和承担责任都推给了回答者。真正值得问的问题，应该让别人看到：你已经做了合理准备，现在只是在某个具体、清晰、可讨论的点上需要帮助。
# 相关资源 (/docs/related-resource)
下面这些资源可以帮助你补齐技术背景。它们并不是提问模板，而是让你更容易理解系统、网络、软件发布与社区协作的基础材料。
## 基础知识 [#基础知识]
如果你需要个人电脑、Unix 系统和网络如何运作的基础知识，参阅 [Unix 系统和网络基本原理](http://en.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/)。
阅读这类材料的意义在于：当你能说清楚文件系统、进程、网络连接、权限、标准输入输出等基本概念时，你的问题会更准确，回答者也更容易判断你卡在哪一层。
## 发布软件或补丁 [#发布软件或补丁]
当你发布软件或补丁时，试着按[软件发布实践](http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html)操作。
良好的发布习惯能减少他人使用、测试和反馈时的成本。版本号、变更记录、构建方式、依赖说明和已知问题写得越清楚，别人越容易给出有效反馈。
# 引言 (/docs/statement)
本指南自发布以来，得到了广泛的引用和传播。我们注意到，许多开源项目和工具在它们的官方网站或帮助文档中都链接了本指南，这是非常值得鼓励的行为——这正是我们设计和撰写本指南的初衷之一：帮助用户学习如何更有效地寻求技术支持。
## 这不是技术支持入口 [#这不是技术支持入口]
然而，我们必须强调一个极为重要的事实：
> **本指南不提供任何特定项目的实际支持服务！**
如果你是某个项目的管理员，并希望在你项目的网站或文档中引用本指南，请务必在链接的显著位置加上这一声明。不要假设用户会自动明白这点——现实是：他们不会。
## 为什么必须说清楚 [#为什么必须说清楚]
我们之所以如此强调这一点，是因为我们已经亲身体验到了未加声明所带来的后果：我们不断地接到来自世界各地的请求，这些请求通常毫无头绪、语焉不详，甚至理所当然地认为我们负责解决他们遇到的所有技术问题。显然，这完全不是我们所愿意承担的责任。
请理解，我们撰写本指南的目的，是为了教会你如何更有礼貌、更高效、更理性地向真正了解你所用软件或硬件的人寻求帮助。在绝大多数（我们估计是 **99%**）情况下，那些人都不是我们。
## 你应该去哪里提问 [#你应该去哪里提问]
如果你现在正在阅读这本指南，是因为你在某个项目中遇到了问题，并希望获得帮助，那么请仔细想一想：你真的认为本指南的作者就刚好是那个项目的维护者、开发者或技术支持吗？我们很可能完全不知道你遇到的问题是关于什么的。如果你看完本指南之后，仍然直接跑来找我们提问，那你很可能正是我们前面所说的那类人——**我们并不想与你交流的那类人**。
我们不会回答你的问题。我们会忽略它们。我们希望你从这本指南中获得的，是寻求真正有效帮助的能力，而不是错误地把我们当作“万能客服”的联系方式。
请去项目自己的 Issue 区、论坛、邮件列表、聊天室、用户群组或商业支持渠道提问。那里才有熟悉具体软件、硬件、环境和历史背景的人。
## 最后提醒 [#最后提醒]
请记住：**尊重别人的时间，是你能获得帮助的第一步。**
# 致谢 (/docs/thanks)
这份指南不是凭空完成的。许多人的反馈、例子和修订建议，让它从一篇关于提问方式的文章，逐渐变成一份更完整的技术社区协作指南。
## 贡献者 [#贡献者]
Evelyn Mitchel 贡献了一些愚蠢问题例子，并启发了 `如何更好地回答问题` 这一节的编写。
Mikhail Ramendik 贡献了一些特别有价值的建议和改进。
## 为什么保留致谢 [#为什么保留致谢]
技术社区依赖持续的修正和补充。把贡献者记录下来，不只是礼貌，也是在提醒读者：好的文档和好的问题一样，都是多人协作、反复打磨的结果。
# 处理无礼的回应 (/docs/how-to-read-answer/Deal-with-offensive)
很多黑客圈子中看似无礼的行为并不是存心冒犯。相反，它是直截了当，一针见血式的交流风格，这种风格更注重解决问题，而不是使人感觉舒服而却模模糊糊。
## 先判断是否只是直接 [#先判断是否只是直接]
如果你觉得被冒犯了，试着平静地反应。如果有人真的做了出格的事，邮件列表、新闻群组或论坛中的前辈多半会招呼他。如果这**没有**发生而你却发火了，那么你发火对象的言语可能在黑客社区中看起来是正常的，而**你**将被视为有错的一方，这将伤害到你获取信息或帮助的机会。
刺耳不一定等于无礼。很多技术反馈会直接指出错误、遗漏、重复问题或错误假设。先看里面是否包含有用信息，再决定是否需要回应语气本身。
## 真正越界时也要有根据 [#真正越界时也要有根据]
另一方面，你偶尔真的会碰到无礼和无聊的言行。与上述相反，对真正的冒犯者狠狠地打击，用犀利的语言将其驳得体无完肤都是可以接受的。然而，在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔，黑客们自己莽撞地越线的情况并不鲜见。如果你是新手或外人，避开这种莽撞的机会并不高。如果你想得到的是信息而不是消磨时光，这时最好不要把手放在键盘上以免冒险。
如果你的目标是解决问题，很多时候最有效的做法是忽略语气，抓住技术线索继续推进。公开争执会迅速消耗讨论的注意力，也可能让愿意帮你的人离开。
## 关于“古怪行为”的一种解释 [#关于古怪行为的一种解释]
（有些人断言很多黑客都有轻度的自闭症或亚斯伯格综合症，缺少用于润滑人类社会**正常**交往所需的神经。这既可能是真也可能是假的。如果你自己不是黑客，兴许你认为我们脑袋有问题还能帮助你应付我们的古怪行为。只管这么干好了，我们不在乎。我们**喜欢**我们现在这个样子，并且通常对病患标记都有站得住脚的怀疑。）
Jeff Bigler 的观察总结和这个相关也值得一读 (**[tact filters](http://www.mit.edu/~jcb/tact.html)**)。
## 回到你真正想要的东西 [#回到你真正想要的东西]
在下一节，我们会谈到另一个问题，当**你**行为不当时所会受到的`冒犯`。
在多数情况下，你来社区是为了获得信息、解决问题、学习判断，而不是赢得一场情绪争执。把注意力放回事实、证据和下一步行动上，通常是收益最高的选择。
# 如果还是搞不懂 (/docs/how-to-read-answer/if-still-not-understand)
如果你看不懂回应，别立刻要求对方解释。像你以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。
## 先消化，再追问 [#先消化再追问]
回答者给你的可能只是一个关键词、一个方向或一个判断。你需要先围绕这个线索做基本功：查手册、读 FAQ、搜索旧讨论、试验命令或询问身边更熟悉的人。
如果你真的需要对方继续解释，请展示你已经做过的这一步。这样对方知道你不是把下一轮思考也推回给他。
## 糟糕追问和好追问 [#糟糕追问和好追问]
比方说，如果我回答你：`看来似乎是 zentry 卡住了；你应该先清除它。`
这是一个**很糟的**后续回应：
`zentry 是什么？`
更好的问法是：
`哦，我看过说明了，但是只有 -z 和 -p 两个参数中提到了 zentries，而且还都没有清楚解释如何清除它。你是指这两个中的哪一个吗？还是我看漏了什么？`
## 追问也要继续提供信息 [#追问也要继续提供信息]
好的追问会说明三件事：你读了什么、你理解到了哪里、你具体卡在哪个点。这样别人只需要纠正你的理解或补充缺失部分，而不必重新从零开始教你。
# 如何理解答案 (/docs/how-to-read-answer)
得到回答之后，真正的工作还没有结束。你需要读懂回答者给出的线索，判断哪些内容是直接答案，哪些内容是在要求你继续阅读、搜索、补充信息或修正自己的假设。
## 回答不一定会像教程 [#回答不一定会像教程]
技术社区里的回答常常很短，也可能很直接。它们不一定会把背景知识重新讲一遍，而是指向手册、关键词、错误位置或下一步排查方向。你要学会从这些提示中继续推进，而不是期待别人把完整学习路径铺好。
## 阅读答案时先做三件事 [#阅读答案时先做三件事]
1. 找出回答者指出的具体线索，例如文档章节、命令、错误原因或关键词。
2. 自己先阅读、搜索和验证，不要立刻要求对方展开讲解。
3. 如果仍然不懂，再带着你新学到的内容继续追问。
## 本章会讲什么 [#本章会讲什么]
本章会说明如何理解 `RTFM`、`STFW` 这类简短回应，如何在仍然不懂时继续追问，以及如何处理看起来刺耳甚至无礼的回复。
# RTFM 和 STFW (/docs/how-to-read-answer/rtfm-and-stfw)
有一个古老而神圣的传统：如果你收到`RTFM（Read The Fucking Manual）`的回应，回答者认为你**应该去读他妈的手册**。当然，基本上他是对的，你应该去读一读。
RTFM 有一个年轻的亲戚。如果你收到`STFW（Search The Fucking Web）`的回应，回答者认为你**应该到他妈的网上搜索**。那人多半也是对的，去搜索一下吧。（更温和一点的说法是 **[Google 是你的朋友](http://lmgtfy.com/)**！）
## 这通常不是拒绝帮助 [#这通常不是拒绝帮助]
在论坛，你也可能被要求去爬爬论坛的旧文。事实上，有人甚至可能热心地为你提供以前解决此问题的讨论串。但不要依赖这种关照，提问前应该先搜索一下旧文。
通常，用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他们打这些字的时候也正在读着。这些答复意味着回答者认为：
* **你需要的信息非常容易获得**；
* **你自己去搜索这些信息比灌给你，能让你学到更多**。
## 你应该怎么做 [#你应该怎么做]
收到这类回复后，正确反应不是生气，而是顺着线索去读。打开手册，搜索关键词，翻旧讨论，确认答案是否已经在那里。如果你读完仍然不懂，再带着具体卡点回来提问。
例如，不要回 `我看不懂`，而要回：`我读了手册里关于 X 的段落，但不确定这里的 Y 是否就是你说的原因；我理解得对吗？`
你不应该因此不爽；**依照黑客的标准，他已经表示了对你一定程度的关注，而没有对你的要求视而不见**。你应该对他祖母般的慈祥表示感谢。
# 慎选提问的论坛 (/docs/when-questions/carefully-select-forum)
选择提问场合，是提问质量的一部分。一个问题即使描述得很好，发错地方也可能被忽略；而一个普通问题如果发到合适的社区，反而更容易得到准确回应。
## 发错地方会发生什么 [#发错地方会发生什么]
小心选择你要提问的场合。如果你做了下面这些事，很可能会被忽略，或者被看作失败者：
* 在与主题不合的论坛上贴出你的问题。
* 在探讨进阶技术问题的论坛张贴非常初级的问题；反之亦然。
* 在太多的不同新闻群组上重复转贴同样的问题（cross-post）。
* 向既非熟人也没有义务解决你问题的人发送私人电邮。
黑客会剔除掉那些搞错场合的问题，以保护他们沟通的渠道不被无关的东西淹没。你不会想让这种事发生在自己身上的。
## 先找到真正相关的社区 [#先找到真正相关的社区]
因此，第一步是找到对的论坛。再说一次，Google 和其它搜索引擎还是你的朋友，用它们来找到与你遭遇到困难的软硬件问题最相关的网站。通常那儿都有常见问题（FAQ）、邮件列表及相关说明文件的链接。如果你的努力（包括**阅读** FAQ）都没有结果，网站上也许还有报告 Bug（Bug-reporting）的流程或链接，如果是这样，链过去看看。
向陌生的人或论坛发送邮件最可能是风险最大的事情。举例来说，别假设一个提供丰富内容的网页的作者会想充当你的免费顾问。不要对你的问题是否会受到欢迎做太乐观的估计 —— 如果你不确定，那就向别处发送，或者压根别发。
## 先观察社区文化 [#先观察社区文化]
在选择论坛、新闻群组或邮件列表时，别太相信它的名字，先看看 FAQ 或者许可书以弄清楚你的问题是否切题。发文前先翻翻已有的话题，这样可以让你感受一下那里的文化。事实上，事先在新闻组或邮件列表的历史记录中搜索与你问题相关的关键词是个极好的主意，也许这样就找到答案了。即使没有，也能帮助你归纳出更好的问题。
别像机关枪似的一次“扫射”所有的帮助渠道，这就像大喊大叫一样会使人不快。要一个一个地来。
## 确认问题属于这里 [#确认问题属于这里]
搞清楚你的主题！最典型的错误之一是在某种致力于跨平台可移植的语言、套件或工具的论坛中提关于 Unix 或 Windows 操作系统程序界面的问题。如果你不明白为什么这是大错，最好在搞清楚这之间差异之前什么也别问。
一般来说，在仔细挑选的公共论坛中提问，会比在私有论坛中提同样的问题更容易得到有用的回答。有几个理由可以支持这点，一是看潜在的回复者有多少，二是看观众有多少。黑客较愿意回答那些能帮助到许多人的问题。
## 不要滥用私人渠道 [#不要滥用私人渠道]
可以理解的是，老练的黑客和一些热门软件的作者正在接受过多的错发信息。就像那根最后压垮骆驼背的稻草一样，你的加入也有可能使情况走向极端 —— 已经好几次了，一些热门软件的作者由于涌入其私人邮箱的大量不堪忍受的无用邮件而不再提供支持。
除非对方明确邀请你私下联系，否则优先使用公共渠道。公共讨论不仅更容易得到回答，也能让后来遇到同样问题的人受益。
# 明确表达你的问题以及需求 (/docs/when-questions/clearly-express-your-question)
漫无边际的提问是近乎无休无止的时间黑洞。最有可能给你有用答案的人通常也正是最忙的人（他们忙是因为要亲自完成大部分工作）。这样的人对无节制的时间黑洞相当厌恶，所以他们也倾向于厌恶那些漫无边际的提问。
## 明确你希望别人做什么 [#明确你希望别人做什么]
如果你明确表述需要回答者做什么（如提供指点、发送一段代码、检查你的补丁、或是其他等等），就最有可能得到有用的答案。因为这会定出一个时间和精力的上限，便于回答者能集中精力来帮你。这么做很棒。
你可以明确请求：
* 帮你判断下一步排查方向。
* 检查一个最小复现示例。
* 看看补丁思路是否合理。
* 指出相关文档或关键概念。
* 判断错误信息是否指向某类常见原因。
这些请求都有边界。它们不会要求别人无期限地接管你的问题。
## 尊重专家最稀缺的资源 [#尊重专家最稀缺的资源]
要理解专家们所处的世界，请把专业技能想像为充裕的资源，而回复的时间则是稀缺的资源。你要求他们奉献的时间越少，你越有可能从真正专业而且很忙的专家那里得到解答。
因此，你的问题应该让回答者能快速决定：我是否懂这个问题，我需要看哪些信息，我能否在几分钟内给出方向。
## 简化问题不等于隐藏信息 [#简化问题不等于隐藏信息]
所以，界定一下你的问题，使专家花在辨识你的问题和回答所需要付出的时间减到最少，这技巧对你获得有用的答案相当有帮助 —— 但这技巧通常和简化问题有所区别。因此，问`我想更好地理解 X，可否指点一下哪有好一点说明？`通常比问`你能解释一下 X 吗？`更好。如果你的代码不能运作，通常请别人看看哪里有问题，比要求别人替你改正要明智得多。
好的提问会把问题缩小到一个可处理的范围，但不会删掉诊断所需的关键事实。你要减少的是噪声，而不是证据。
# 礼多人不怪 (/docs/when-questions/courtesy-costs-nothing)
彬彬有礼，多用`请`和`谢谢您的关注`，或`谢谢你的关照`。让大家都知道你对他们花时间免费提供帮助心存感激。
## 礼貌不能替代内容 [#礼貌不能替代内容]
坦白说，这一点并没有比使用清晰、正确、精准且合乎语法和避免使用专用格式重要（也不能取而代之）。黑客们一般宁可读有点唐突但技术上鲜明的 Bug 报告，而不是那种有礼但含糊的报告。（如果这点让你不解，记住我们是按问题能教给我们什么来评价问题的价值的）
也就是说，礼貌是加分项，不是遮羞布。一个没有环境、没有错误信息、没有尝试记录的问题，哪怕写满“麻烦您了”，也仍然是一个难以回答的问题。
## 礼貌会影响长期回应 [#礼貌会影响长期回应]
然而，如果你有一串的问题待解决，客气一点肯定会增加你得到有用回应的机会。
技术社区是有记忆的。别人会记得你是否尊重时间、是否反馈结果、是否在得到帮助后补充总结。客气、诚实、及时感谢，会让人更愿意在下一次继续理你。
## 关于“先谢了” [#关于先谢了]
（我们注意到，自从本指南发布后，从资深黑客那里得到的唯一严重缺陷反馈，就是对预先道谢这一条。一些黑客觉得`先谢了`意味着事后就不用再感谢任何人的暗示。我们的建议是要么先说`先谢了`，**然后**事后再对回复者表示感谢，或者换种方式表达感激，譬如用`谢谢你的关注`或`谢谢你的关照`。）
最稳妥的做法是：提问时表达对他人关注的感谢，问题解决后再明确感谢具体帮助你的人，并补充最终结果。
# 描述目标而不是过程 (/docs/when-questions/describe-goal-not-process)
如果你想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。
## 为什么目标比步骤更重要 [#为什么目标比步骤更重要]
经常寻求技术帮助的人在心中有个更高层次的目标，而他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。
如果你只问某一步怎么做，回答者只能帮你修补这一步；如果你说明真正目标，回答者可能会指出更简单、更稳妥、更符合工具设计的方案。
## 反例：只问卡住的步骤 [#反例只问卡住的步骤]
**蠢问题：**
> 我怎样才能从某绘图程序的颜色选择器中取得十六进制的 RGB 值？
## 好例子：先说明真正目标 [#好例子先说明真正目标]
**聪明问题：**
> 我正试着用替换一幅图片的色码（color table）成自己选定的色码，我现在知道的唯一方法是编辑每个色码区块（table slot），
> 但却无法从某绘图程序的颜色选择器取得十六进制的 RGB 值。
第二种提问法比较聪明，因为它让回答者知道你真正想完成的是修改图片色码，而不是单纯获取某个颜色值。你可能得到像是 `建议采用另一个更合适的工具` 这样的回复。
## 写法建议 [#写法建议]
可以用这样的顺序组织问题：
1. 我最终想达到什么结果。
2. 我目前选择了什么方法。
3. 我卡在这个方法的哪一步。
4. 我是否接受换一种方法。
最后一点尤其重要。很多时候，最好的答案不是把你从错误路径上继续往前推，而是帮你换一条更合适的路。
# 描述问题症状而非你的猜测 (/docs/when-questions/describe-symptoms-not-guesses)
告诉黑客们你认为问题是怎样造成的并没什么帮助。（如果你的推断如此有效，还用向别人求助吗？），因此要确信你原原本本告诉了他们问题的症状，而不是你的解释和理论；让黑客们来推测和诊断。如果你认为陈述自己的猜测很重要，清楚地说明这只是你的猜测，并描述为什么它们不起作用。
## 先给证据，再给猜测 [#先给证据再给猜测]
事实应该放在前面：发生了什么、什么时候发生、如何复现、错误信息是什么、你观察到哪些规律。猜测可以写，但要标明它只是猜测，不要把它包装成结论。
## 反例：过早下结论 [#反例过早下结论]
**蠢问题：**
> 我在编译内核时接连遇到 SIG11 错误，
> 我怀疑某条飞线搭在主板的走线上了，这种情况应该怎样检查最好？
这个问题把注意力引向了一个未经证实的硬件猜测，反而隐藏了真正有诊断价值的现象。
## 好例子：描述可观察现象 [#好例子描述可观察现象]
**聪明问题：**
> 我的组装电脑是 FIC-PA2007 主机板搭载 AMD K6/233 CPU（威盛 Apollo VP2 芯片组），
> 256MB Corsair PC133 SDRAM 内存，在编译内核时，从开机 20 分钟以后就频频产生 SIG11 错误，
> 但是在头 20 分钟内从没发生过相同的问题。重新启动也没有用，但是关机一晚上就又能工作 20 分钟。
> 所有内存都换过了，没有效果。相关部分的标准编译记录如下…
这里的价值在于，它提供了硬件环境、时间规律、已做排除和相关日志。回答者可以基于事实继续诊断，而不是被迫先拆掉提问者的猜测。
## “让我看看” [#让我看看]
由于以上这点似乎让许多人觉得难以配合，这里有句话可以提醒你：`所有的诊断专家都来自密苏里州。` 美国国务院的官方座右铭则是：`让我看看`（出自国会议员 Willard D. Vandiver 在 1899 年时的讲话：`我来自一个出产玉米，棉花，牛蒡和民主党人的国家，滔滔雄辩既不能说服我，也不会让我满意。我来自密苏里州，你必须让我看看。`） 针对诊断者而言，这并不是一种怀疑，而只是一种真实而有用的需求，以便让他们看到的是与你看到的原始证据尽可能一致的东西，而不是你的猜测与归纳的结论。所以，大方地展示给我们看吧！
# 别要求使用私人电邮回复 (/docs/when-questions/donnot-ask-for-private-email)
黑客们认为问题的解决过程应该公开、透明，此过程中如果更有经验的人注意到不完整或者不当之处，最初的回复才能够、也应该被纠正。同时，作为提供帮助者可以得到一些奖励，奖励就是他的能力和学识被其他同行看到。
## 公开讨论能提高答案质量 [#公开讨论能提高答案质量]
当你要求私下回复时，这个过程和奖励都被中止。别这样做，让**回复者**来决定是否私下回答 —— 如果他真这么做了，通常是因为他认为问题编写太差或者太肤浅，以至于不可能使其他人产生兴趣。
公开回复有几个好处：别人可以纠正错误答案，后来者可以搜索到解决方案，参与者也能从讨论中学习。私下回复则把这些价值都切断了。
## 有限例外：你负责整理 [#有限例外你负责整理]
这条规则存在一条有限的例外，如果你确信提问可能会引来大量雷同的回复时，那么这个神奇的提问句会是`向我发电邮，我将为论坛归纳这些回复`。试着将邮件列表或新闻群组从洪水般的雷同回复中解救出来是非常有礼貌的 —— 但你必须信守诺言。
如果你这样承诺，就要真的把收到的信息整理回公开讨论中。否则，你只是把社区知识吸走，并没有回馈任何东西。
# 别问自己的家庭作业 (/docs/when-questions/donnot-ask-homework)
黑客们很擅长分辨哪些问题是家庭作业式的问题；因为我们中的大多数都曾自己解决这类问题。同样，这些问题得由**你**来搞定，你会从中学到东西。你可以要求给点提示，但别要求得到完整的解决方案。
## 作业的目的就是让你练习 [#作业的目的就是让你练习]
家庭作业式问题并不限于学校作业。任何本质上要求你通过练习来掌握概念、完成推理或写出实现的问题，都属于这一类。别人直接给你完整答案，只会剥夺你学习的过程。
可以问：
* `我对题意的理解是否正确？`
* `我这个思路卡在某一步，是否有明显误区？`
* `我应该复习哪部分概念？`
不要问：
* `谁能直接给我完整代码？`
* `把答案发我一下。`
* `明天要交，帮我做完。`
## 去更合适的新手渠道 [#去更合适的新手渠道]
如果你怀疑自己碰到了一个家庭作业式的问题，但仍然无法解决，试试在用户群组，论坛或（最后一招）在项目的**用户**邮件列表或论坛中提问。尽管黑客们**会**看出来，但一些有经验的用户也许仍会给你一些提示。
即使在那里，也要展示你已经尝试过什么。请求提示和请求代做，是完全不同的两件事。
# 低声下气不能代替你的功课 (/docs/when-questions/humble-not-substitute-homewoek)
有些人明白他们不该粗鲁或傲慢的提问并要求得到答复，但他们选择另一个极端 —— 低声下气：`我知道我只是个可悲的新手，一个失败者，但...`。这既使人困扰，也没有用，尤其是伴随着与实际问题含糊不清的描述时更令人反感。
## 自贬不会让问题更清楚 [#自贬不会让问题更清楚]
低声下气看似谦虚，实际会把注意力从问题本身转移到你的情绪上。回答者需要的是事实、背景、目标和尝试记录，不是你对自己的评价。
别用原始灵长类动物的把戏来浪费你我的时间。取而代之的是，尽可能清楚地描述背景条件和你的问题情况。这比低声下气更好地定位了你的位置。
更好的表达是：`我是第一次使用这个库，已经读过入门文档和 FAQ，但仍不理解下面这个错误。` 这既说明了你的经验水平，也提供了有效背景。
## 新手也要认真提问 [#新手也要认真提问]
有时网页论坛会设有专为新手提问的版面，如果你真的认为遇到了初学者的问题，到那去就是了，但一样别那么低声下气。
新手身份不是问题，拒绝做功课才是问题。坦诚说明自己在哪里不懂，然后给出你已经尝试过的东西，比反复道歉更有用。
# 正在提问时 (/docs/when-questions)
真正开始提问时，你要做的不只是把问题发出去。你需要选择合适的场合、写清楚标题、使用可读格式、提供事实、描述目标，并让回答者能快速判断自己是否帮得上忙。
## 提问时的核心原则 [#提问时的核心原则]
当你提出问题的时候，请先表明你已经做过准备。这能帮助别人判断你不是一个不劳而获、随手浪费他人时间的提问者。如果你还能说明自己在准备过程中**学到了什么**，效果会更好；我们更乐于回答那些表现出能从答案中继续学习的人。
一个好的问题通常具备这些特征：
* 发在正确的社区或讨论区。
* 标题能概括目标、环境和异常。
* 正文格式清楚，方便引用和回复。
* 描述事实，而不是只给猜测。
* 说明目标，而不是只描述你卡住的步骤。
* 展示你已经搜索、阅读、尝试和排除过什么。
## 如何阅读本章 [#如何阅读本章]
本章的每一节都处理提问时的一个具体动作：选论坛、写标题、描述问题、贴代码、避免无效句式、保持礼貌等。你不必一次记住所有规则，但在真正发问前，至少应该逐项检查一遍。
提问质量不是靠客气话堆出来的，而是靠准确的信息、明确的边界和可协作的态度建立起来的。
# 按时间先后列出问题 (/docs/when-questions/list-problems-by-time)
问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，你的说明里应该包含你的操作步骤，以及机器和软件的反应，直到问题发生。在命令行处理的情况下，提供一段操作记录（例如运行脚本工具所生成的），并引用相关的若干行（如 20 行）记录会非常有帮助。
## 记录从哪里开始 [#记录从哪里开始]
时间顺序不需要从你安装系统那天开始。它应该从“与问题可能相关的第一步”开始，例如最近一次升级、配置变更、依赖安装、数据导入、命令执行或重启。
一个有用的时间线通常包含：
1. 你做了什么。
2. 系统返回了什么。
3. 你接着尝试了什么。
4. 问题第一次出现在哪里。
5. 之后你如何确认它仍然存在。
## 调试信息要适量 [#调试信息要适量]
如果挂掉的程序有诊断选项（如 -v 的详述开关），试着选择这些能在记录中增加调试信息的选项。记住，`多`不等于`好`。试着选取适当的调试级别以便提供有用的信息而不是让读者淹没在垃圾中。
一大段未经筛选的日志会增加阅读成本。更好的做法是保留完整日志的链接或附件，同时在正文里引用最相关的几十行，并说明它们为什么重要。
## 长问题先给摘要 [#长问题先给摘要]
如果你的说明很长（如超过四个段落），在开头简述问题，接下来再按时间顺序详述会有所帮助。这样黑客们在读你的记录时就知道该注意哪些内容了。
摘要可以很短，例如：`升级到 2.4.1 后，导入 CSV 会在第三步报 UnicodeDecodeError；回退到 2.3.8 后恢复正常。下面是完整时间线。` 这样的开头能让回答者先建立整体判断，再进入细节。
# 使问题容易回复 (/docs/when-questions/make-questions-easily)
以`请将你的回复发送到……`来结束你的问题多半会使你得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都麻烦，我们也觉得花几秒钟思考你的问题更麻烦。如果你的邮件程序不支持这样做，[换个好点的](http://linuxmafia.com/faq/Mail/muas.html)；如果是操作系统不支持这种邮件程序，也换个好点的。
## 不要把回复成本转嫁给别人 [#不要把回复成本转嫁给别人]
回答者愿意花时间思考你的问题，已经是在帮你。不要再要求他们绕过正常讨论渠道、复制到私人地址、单独通知你，或者用额外步骤满足你的收信习惯。
如果你需要邮件提醒，请配置自己的客户端或论坛通知，而不是让每个回复者替你处理。
## 论坛里不要要求邮件回复 [#论坛里不要要求邮件回复]
在论坛，要求通过电子邮件回复是非常无礼的，除非你认为回复的信息可能比较敏感（有人会为了某些未知的原因，只让你而不是整个论坛知道答案）。如果你只是想在有人回复讨论串时得到电子邮件提醒，可以要求网页论坛发送给你。几乎所有论坛都支持诸如`追踪此讨论串`、`有回复时发送邮件提醒`等功能。
问题在哪里公开提出，答案通常也应该在哪里公开留下。这样才能让后来的人搜索、引用和补充。
# 不要在标题写`紧急` (/docs/when-questions/never-write-urgent)
这是你的问题，不是我们的。宣称`紧急`极有可能事与愿违：大多数黑客会直接删除无礼和自私地企图即时引起关注的问题。更严重的是，`紧急`这个字（或是其他企图引起关注的标题）通常会被垃圾信过滤器过滤掉 —— 你希望能看到你问题的人可能永远也看不到。
## 你的紧急不等于社区的紧急 [#你的紧急不等于社区的紧急]
对你来说，系统无法启动、作业快截止、客户正在等待，都可能非常紧急。但对陌生的回答者来说，这并不会自动制造义务。标题里写 `紧急`，通常只会传达一种信息：你希望别人把你的时间压力放在自己的事情前面。
## 少数例外也要谨慎 [#少数例外也要谨慎]
有半个例外的情况是，如果你是在一些很高调，会使黑客们兴奋的地方，也许值得这样去做。在这种情况下，如果你有时间压力，也很有礼貌地提到这点，人们也许会有兴趣回答快一点。
当然，这风险很大，因为黑客们兴奋的点多半与你的不同。譬如从 NASA 国际空间站（International Space Station）发这样的标题没有问题，但用自我感觉良好的慈善行为或政治原因发肯定不行。事实上，张贴诸如`紧急：帮我救救这个毛茸茸的小海豹！`肯定让你被黑客忽略或惹恼他们，即使他们认为毛茸茸的小海豹很重要。
## 更好的写法 [#更好的写法]
如果确实有时间限制，可以在正文里平实说明，而不是用标题抢注意力。例如：`这个问题影响今晚的发布；如果没人能及时回复，我会先回滚到上一版本。` 这比 `紧急！！！` 更成熟，也让别人知道你有备用方案。
如果你觉得这点很不可思议，最好再把这份指南剩下的内容多读几遍，直到你弄懂了再发文。
# 话再多而不在精 (/docs/when-questions/not-more-words-but-essence)
你需要提供精确有内容的信息。这并不是要求你简单的把成堆的出错代码或者资料完全转录到你的提问中。如果你有庞大而复杂的测试样例能重现程序挂掉的情境，尽量将它剪裁得越小越好。
## 信息要足够，但不要堆砌 [#信息要足够但不要堆砌]
“详细”不等于“把所有东西都贴上来”。日志、配置、代码、截图和错误信息都应该经过筛选。你需要保留能支持诊断的事实，删掉和问题无关的噪声。
如果问题可以用 20 行代码复现，就不要贴整个项目。如果错误只出现在最后 30 行日志里，就不要把几万行日志直接塞进正文。
## 最小化问题的三个价值 [#最小化问题的三个价值]
这样做的用处至少有三点。
第一，表现出你为简化问题付出了努力，这可以使你得到回答的机会增加；
第二，简化问题使你更有可能得到**有用**的答案；
第三，在精炼你的 bug 报告的过程中，你很可能就自己找到了解决方法或权宜之计。
## 一个实用标准 [#一个实用标准]
在发问前问自己：回答者是否能用你给出的材料复现或理解问题，同时又不必在大量无关内容里搜寻线索？如果不能，就继续裁剪、整理和标注重点。
# 别动辄声称找到 Bug (/docs/when-questions/not-say-find-bug-easily)
当你在使用软件中遇到问题，除非你非常、**非常**的有根据，不要动辄声称找到了 Bug。提示：除非你能提供解决问题的源代码补丁，或者提供回归测试来表明前一版本中行为不正确，否则你都多半不够完全确信。这同样适用在网页和文件，如果你（声称）发现了文件的`Bug`，你应该能提供相应位置的修正或替代文件。
## “可能是 Bug”需要证据 [#可能是-bug需要证据]
请记得，还有其他许多用户没遇到你发现的问题，否则你在阅读文件或搜索网页时就应该发现了（你在抱怨前[已经做了这些，是吧](#在提问之前)？）。这也意味着很有可能是你弄错了而不是软件本身有问题。
如果你怀疑是 Bug，请尽量提供：
* 最小复现步骤。
* 当前版本和历史版本的行为差异。
* 明确的预期行为依据，例如文档或规范。
* 日志、测试用例、补丁或失败的回归测试。
## 指控会影响对话气氛 [#指控会影响对话气氛]
编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了 Bug，也就是在质疑他们的能力，即使你是对的，也有可能会冒犯到其中某部分人。当你在标题中嚷嚷着有`Bug`时，这尤其严重。
## 用谦逊但清楚的方式报告 [#用谦逊但清楚的方式报告]
提问时，即使你私下非常确信已经发现一个真正的 Bug，最好写得像是**你**做错了什么。如果真的有 Bug，你会在回复中看到这点。这样做的话，如果真有 Bug，维护者就会向你道歉，这总比你惹恼别人然后欠别人一个道歉要好一点。
比如，把 `这个库有 Bug` 改成 `在这个最小示例中，2.1.0 的行为与文档描述不一致；我是否遗漏了某个配置？`。这种写法既保留了问题的严重性，也给维护者留下判断空间。
# 精确描述问题 (/docs/when-questions/precisely-describe-problem)
精确描述问题，是让别人能够继续诊断的前提。你不需要一次写成论文，但必须提供足够事实，让回答者不用先反复追问最基本的信息。
## 需要写清楚的信息 [#需要写清楚的信息]
* 仔细、清楚地描述你的问题或 Bug 的症状。
* 描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息），提供经销商的发行版和版本号（如：`Fedora Core 4`、`Slackware 9.1`等）。
* 描述在提问前你是怎样去研究和理解这个问题的。
* 描述在提问前为确定问题而采取的诊断步骤。
* 描述最近做过什么可能相关的硬件或软件变更。
* 尽可能地提供一个可以`重现这个问题的可控环境`的方法。
## 预先回答可能的追问 [#预先回答可能的追问]
尽量去揣测一个黑客会怎样反问你，在你提问之前预先将黑客们可能提出的问题回答一遍。
你可以把自己放在回答者的位置上想一想：
* 我知道问题在哪个版本、哪台机器、哪种配置下发生吗？
* 我知道它是稳定复现，还是偶尔出现吗？
* 我知道提问者已经排除了哪些原因吗？
* 我能照着描述复现同样的问题吗？
如果答案是否定的，就继续补充信息。
## 可复现环境尤其重要 [#可复现环境尤其重要]
以上几点中，当你报告的是你认为可能在代码中的问题时，给黑客一个可以重现你的问题的环境尤其重要。当你这么做时，你得到有效的回答的机会和速度都会大大的提升。
“可复现”不一定意味着完整复制你的生产环境。一个最小示例、一段触发错误的配置、一组输入数据，或者一条明确的命令，都可能足以让别人观察同样的现象。
## 延伸阅读 [#延伸阅读]
[Simon Tatham](http://www.chiark.greenend.org.uk/~sgtatham/) 写过一篇名为《[如何有效地报告Bug](http://www.chiark.greenend.org.uk/~sgtatham/bugs-cn.html)》的出色文章。强力推荐你也读一读。
# 去掉无意义的提问句 (/docs/when-questions/remove-questional-sentence)
避免用无意义的话结束提问，例如`有人能帮我吗？`或者`这有答案吗？`。
## 为什么这类句子没有价值 [#为什么这类句子没有价值]
首先：如果你对问题的描述不是很好，这样问更是画蛇添足。
其次：由于这样问是画蛇添足，黑客们会很厌烦你 —— 而且通常会用逻辑上正确，但毫无意义的回答来表示他们的蔑视， 例如：`没错，有人能帮你`或者`不，没答案`。
这类句子没有提供任何诊断信息，也没有说明你希望别人做什么。它们只是在要求别人先承诺会不会帮你。
## 换成具体请求 [#换成具体请求]
与其写 `有人能帮我吗？`，不如写：
* `我应该优先检查哪一层？`
* `这个错误是否说明依赖版本不兼容？`
* `这个最小示例是否足以说明问题？`
* `有没有我遗漏的常见配置项？`
这些问题能让回答者直接进入技术判断。
## 避免只会得到“是/否”的问题 [#避免只会得到是否的问题]
一般来说，避免用 `是或否`、`对或错`、`有或没有`类型的问句，除非你想得到[是或否类型的回答](https://strcat.de/questions-with-yes-or-no-answers.html)。
如果你真正需要的是解释、方向或诊断建议，就不要把问题写成只能回答“是”或“不是”的形式。
# Stack Overflow (/docs/when-questions/stack-overflow)
搜索，*然后*在 Stack Exchange 问。
近年来，Stack Exchange 社区已经成为回答技术及其他问题的主要渠道，尤其是那些开放源码的项目。
## 先搜索已有答案 [#先搜索已有答案]
因为 Google 索引是即时的，在看 Stack Exchange 之前先在 Google 搜索。有很高的几率某人已经问了一个类似的问题，而且 Stack Exchange 网站们往往会是搜索结果中最前面几个。如果你在 Google 上没有找到任何答案，你再到特定相关主题的网站去找。用标签（Tag）搜索能让你更缩小你的搜索结果。
搜索时可以同时使用错误信息、库名、语言名、版本号和关键 API 名称。Stack Exchange 的历史问题很多，重复问题通常不会受到欢迎。
## 提问时遵守平台习惯 [#提问时遵守平台习惯]
如果你还是找不到任何对你的问题有用的内容，请把你的问题发在与它最相关的网站上。提问的时候请善用格式化工具，尤其注意为代码添加格式，并且添加相关的标签（特别是编程语言、操作系统或库/包的名称）。当有人要求你提供更多相关信息时，请编辑你的贴子来补充它们\[译注：而不是发一个回帖或回答！]。如果你觉得一个答案对你有帮助，点击向上的箭头来为它投票；如果一个答案提供了问题的正确解决方案，点击投票按钮下方的对勾来将它标记为正解。
这不是形式主义。格式、标签、编辑补充、投票和接受答案，都是 Stack Exchange 用来维护知识库质量的机制。
## 选择正确的网站 [#选择正确的网站]
Stack Exchange 已经成长到[超过一百个网站](https://stackexchange.com/sites)，以下是最常用的几个站：
* Super User 是问一些通用的电脑问题，如果你的问题跟代码或是写程序无关，只是一些网络连线之类的，请到这里。
* Stack Overflow 是问写程序有关的问题。
* Server Fault 是问服务器和网管相关的问题。
如果你把问题发错站点，即使问题本身不错，也可能被关闭或迁移。先确认站点范围，比发完以后再解释要有效得多。
# 用清晰、正确、精准的语句 (/docs/when-questions/use-correctly-sentence)
我们从经验中发现，粗心的提问者通常也会粗心地写程序与思考（我敢打包票）。回答粗心大意者的问题很不值得，我们宁愿把时间耗在别处。
## 语言质量会影响别人对你的判断 [#语言质量会影响别人对你的判断]
正确的拼写、标点符号和大小写是很重要的。一般来说，如果你觉得这样做很麻烦，不想在乎这些，那我们也觉得麻烦，不想在乎你的提问。花点额外的精力斟酌一下字句，用不着太僵硬与正式 —— 事实上，黑客文化很看重能准确地使用非正式、俚语和幽默的语句。但它**必须很**准确，而且有迹象表明你是在思考和关注问题。
清晰表达不是为了显得文雅，而是为了减少误解。一个标点混乱、大小写随意、句子断裂的问题，会让别人怀疑你在代码、日志和测试上也同样粗心。
## 避免制造阅读障碍 [#避免制造阅读障碍]
正确地拼写、使用标点和大小写，不要将`its`混淆为`it's`，`loose`搞成`lose`或者将`discrete`弄成`discreet`。不要**全部用大写**，这会被视为无礼的大声嚷嚷（全部小写也好不到哪去，因为不易阅读。[Alan Cox](http://en.wikipedia.org/wiki/Alan_Cox) 也许可以这样做，但你不行）。
更白话的说，如果你写得像是个半文盲\[译注：[小白](http://zh.wikipedia.org/wiki/小白)]，那多半得不到理睬。也不要使用即时通信中的简写或[火星文](http://zh.wikipedia.org/wiki/火星文)，如将`的`简化为`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.
* 我把我的问题用**某语言**和英文写出来。
* 如果你只用其中的一种语言回答，我会乐意将回复翻译成为你使用的语言。
## 最后的标准 [#最后的标准]
语言可以不完美，但必须看得出你认真。回答者通常能区分“外语不熟”和“思考混乱”，也能区分“表达朴素”和“完全不尊重阅读者”。
# 使用标准的文件格式发送问题 (/docs/when-questions/use-easy-to-read-file-format)
如果你人为地将问题搞得难以阅读，它多半会被忽略，人们更愿读易懂的问题，所以：
## 让正文容易阅读和引用 [#让正文容易阅读和引用]
* 使用纯文字而不是 HTML ([关闭 HTML](http://archive.birdhouse.org/etc/evilmail.html) 并不难）。
* 使用 MIME 附件通常是可以的，前提是真正有内容（譬如附带的源代码或 patch），而不仅仅是邮件程序生成的模板（譬如只是信件内容的拷贝）。
* 不要发送一段文字只是一行句子但自动换行后会变成多行的邮件（这使得回复部分内容非常困难）。设想你的读者是在 80 个字符宽的终端机上阅读邮件，最好设置你的换行分割点小于 80 字。
* 但是，对一些特殊的文件**不要**设置固定宽度（譬如日志文件拷贝或会话记录）。数据应该原样包含，让回复者有信心他们看到的是和你看到的一样的东西。
## 避免奇怪编码和封闭格式 [#避免奇怪编码和封闭格式]
* 在英语论坛中，不要使用`Quoted-Printable` MIME 编码发送消息。这种编码对于张贴非 ASCII 语言可能是必须的，但很多邮件程序并不支持这种编码。当它们处理换行时，那些文本中四处散布的`=20`符号既难看也分散注意力，甚至有可能破坏内容的语意。
* 绝对，**永远**不要指望黑客们阅读使用封闭格式编写的文档，像微软公司的 Word 或 Excel 文件等。大多数黑客对此的反应就像有人将还在冒热气的猪粪倒在你家门口时你的反应一样。即便他们能够处理，他们也很厌恶这么做。
* 如果你从使用 Windows 的电脑发送电子邮件，关闭微软愚蠢的`智能引号`功能 （从\[选项] > \[校订] > \[自动校正选项]，勾选掉`智能引号`单选框），以免在你的邮件中到处散布垃圾字符。
## 不要用装饰干扰内容 [#不要用装饰干扰内容]
* 在论坛，勿滥用`表情符号`和`HTML`功能（当它们提供时）。一两个表情符号通常没有问题，但花哨的彩色文本倾向于使人认为你是个无能之辈。过滥地使用表情符号、色彩和字体会使你看来像个傻笑的小姑娘。这通常不是个好主意，除非你只是对性而不是对答案感兴趣。
如果你使用图形用户界面的邮件程序（如微软公司的 Outlook 或者其它类似的），注意它们的默认设置不一定满足这些要求。大多数这类程序有基于选单的`查看源代码`命令，用它来检查发送文件夹中的邮件，以确保发送的是纯文本文件同时没有一些奇怪的字符。
## 归根结底：降低阅读成本 [#归根结底降低阅读成本]
格式不是小事。可复制的文本、原样保留的日志、清楚的换行和开放格式，都会让别人更容易引用、测试和回复你的问题。你让问题越容易处理，别人越可能愿意处理。
# 使用有意义且描述明确的标题 (/docs/when-questions/use-meaningful-headlines)
在邮件列表、新闻群组或论坛中，大约 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 和其它一些邮件阅读程序还会检查邮件标题以外的其它信息，以便为其指定讨论串。所以宁可发一个全新的邮件。
## 网页论坛的差异 [#网页论坛的差异]
在网页论坛上，好的提问方式稍有不同，因为讨论串与特定的信息紧密结合，并且通常在讨论串外就看不到里面的内容，故通过回复提问，而非改变标题是可接受的。不是所有论坛都允许在回复中出现分离的标题，而且这样做了基本上没有人会去看。不过，通过回复提问，这本身就是暧昧的做法，因为它们只会被正在查看该标题的人读到。所以，除非你**只想**在该讨论串当前活跃的人群中提问，不然还是另起炉灶比较好。
一个可靠的判断标准是：只看标题时，陌生读者能否知道你在什么环境下遇到了什么异常。如果不能，标题就还不够好。
# 使用项目邮件列表 (/docs/when-questions/use-project-email-list)
当某个项目提供开发者邮件列表时，要向列表而不是其中的个别成员提问，即使你确信他能最好地回答你的问题。查一查项目的文件和首页，找到项目的邮件列表并使用它。有几个很好的理由支持我们采用这种办法：
## 为什么要发到列表 [#为什么要发到列表]
* 任何好到需要向个别开发者提出的问题，也将对整个项目群组有益。反之，如果你认为自己的问题对整个项目群组来说太愚蠢，那这也不能成为骚扰个别开发者的理由。
* 向列表提问可以分散开发者的负担，个别开发者（尤其是项目领导人）也许太忙以至于没法回答你的问题。
* 大多数邮件列表都会被存档，那些被存档的内容将被搜索引擎索引。如果你向列表提问并得到解答，将来其他人可以通过网页搜索找到你的问题和答案，也就不用再次发问了。
* 如果某些问题经常被问到，开发者可以利用此信息来改进说明文件或软件本身，以使其更清楚。如果只是私下提问，就没有人能看到最常见问题的完整场景。
公开列表让问题、答案、纠正和后续总结都留在项目知识库里。私下发给某个开发者，通常只会增加对方负担，并减少其他人受益的机会。
## 用户列表和开发者列表不要混用 [#用户列表和开发者列表不要混用]
如果一个项目既有“用户”也有“开发者”（或“黑客”）邮件列表或论坛，而你又不会动到那些源代码，那么就向“用户”列表或论坛提问。不要假设自己会在开发者列表中受到欢迎，那些人多半会将你的提问视为干扰他们开发的噪音。
开发者列表通常用于讨论实现、补丁、设计、回归和发布。普通使用问题放在那里，往往会显得你没有尊重列表用途。
## 何时升级到开发者渠道 [#何时升级到开发者渠道]
然而，如果你**确信**你的问题很特别，而且在“用户”列表或论坛中几天都没有回复，可以试试前往“开发者”列表或论坛发问。建议你在张贴前最好先暗地里观察几天以了解那里的行事方式（事实上这是参与任何私有或半私有列表的好主意）
升级提问时，要说明你已经在用户渠道问过、等待了多久、得到了哪些信息，以及为什么你认为这个问题可能需要开发者判断。
## 找不到列表时再联系维护者 [#找不到列表时再联系维护者]
如果你找不到一个项目的邮件列表，而只能查到项目维护者的电子邮件地址，尽管向他发信。即使是在这种情况下，也别假设（项目）邮件列表不存在。在你的电子邮件中，请陈述你已经试过但没有找到合适的邮件列表，也提及你不反对将自己的邮件转发给他人（许多人认为，即使没什么秘密，私人电子邮件也不应该被公开。通过允许将你的电子邮件转发他人，你给了相应人员处置你邮件的选择）。
这能让维护者更容易把问题转给合适的人，也避免他们因为隐私顾虑而无法公开你的问题。
# 网站和 IRC 论坛 (/docs/when-questions/website-and-irc)
本地的用户群组（user group），或者你所用的 Linux 发行版本也许正在宣传他们的网页论坛或 IRC 频道，并提供新手帮助（在一些非英语国家，新手论坛很可能还是邮件列表），这些都是开始提问的好地方，特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。有广告赞助的 IRC 频道是公开欢迎提问的地方，通常可以即时得到回应。
## 新手问题先找用户支持渠道 [#新手问题先找用户支持渠道]
用户群组、发行版论坛、网页论坛和 IRC 频道，往往比开发者邮件列表更适合入门问题。那里的人更熟悉常见安装、配置、环境差异和使用误区，也更愿意处理“我刚开始用”的问题。
## 发行版问题先问发行版社区 [#发行版问题先问发行版社区]
事实上，如果程序出的问题只发生在特定 Linux 发行版提供的版本（这很常见），最好先去该发行版的论坛或邮件列表中提问，再到程序本身的论坛或邮件列表提问。（否则）该项目的黑客可能仅仅回复“使用**我们的**版本”。
发行版常常会修改编译选项、补丁、默认配置和依赖版本。上游项目不一定知道这些差异，因此先问发行版社区通常更有效。
## 发问前搜索论坛内部 [#发问前搜索论坛内部]
在任何论坛发文以前，先确认一下有没有搜索功能。如果有，就试着搜索一下问题的几个关键词，也许这会有帮助。如果在此之前你已做过通用的网页搜索（你也该这样做），还是再搜索一下论坛，搜索引擎有可能没来得及索引此论坛的全部内容。
论坛内部搜索能发现搜索引擎还没收录、或被登录权限挡住的讨论。先搜索，也能让你了解这个社区喜欢怎样描述问题。
## 选择同步或异步渠道 [#选择同步或异步渠道]
通过论坛或 IRC 频道来提供用户支持服务有增长的趋势，电子邮件则大多为项目开发者间的交流而保留。所以最好先在论坛或 IRC 中寻求与该项目相关的协助。
在使用 IRC 的时候，首先最好不要发布很长的问题描述，有些人称之为频道洪水。最好通过一句话的问题描述来开始聊天。
IRC 更适合快速澄清和短互动；论坛更适合长问题、日志、代码和后续总结。选择渠道时，先想清楚你的问题需要即时对话，还是需要可搜索、可沉淀的长文本。
# 询问有关代码的问题时 (/docs/when-questions/when-ask-code)
如果没有提示别人应该从何入手，别要求他人帮你调试有问题的代码。张贴几百行的代码，然后说一声：`它不能工作`会让你完全被忽略。只贴几十行代码，然后说一句：`在第七行以后，我期待它显示 ，但实际出现的是 `比较有可能让你得到回应。
## 给出入口点 [#给出入口点]
别人看你的代码时，需要知道该从哪里开始看、期望行为是什么、实际行为是什么。没有这些信息，代码越多，越像是在把排查工作整体转交给别人。
一个更好的代码问题通常包含：
* 最小可运行代码片段。
* 运行方式或编译命令。
* 预期输出和实际输出。
* 错误发生的位置。
* 你已经尝试过的修改。
## 提供最小复现 [#提供最小复现]
最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例（bug-demonstrating test case）。什么是最精简的测试用例？那是问题的缩影；一小个程序片段能**刚好**展示出程序的异常行为，而不包含其他令人分散注意力的内容。怎么制作最精简的测试用例？如果你知道哪一行或哪一段代码会造成异常的行为，复制下来并加入足够重现这个状况的代码（例如，足以让这段代码能被编译/直译/被应用程序处理）。如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。总之，测试用例越小越好（查看[话不在多而在精](#话不在多而在精)一节）。
## 即使缩不小，也要展示努力 [#即使缩不小也要展示努力]
一般而言，要得到一段相当精简的测试用例并不太容易，但永远先尝试这样做是一个好习惯。这种方式可以帮助你了解如何自行解决这个问题 —— 而且即使你的尝试不成功，黑客们也会看到你在尝试取得答案的过程中付出了努力，这可以让他们更愿意与你合作。
## 如果你想要代码审查 [#如果你想要代码审查]
如果你只是想让别人帮忙审查（Review）一下代码，在信的开头就要说出来，并且一定要提到你认为哪一部分特别需要关注以及为什么。
“请帮我看看”太宽泛。更好的说法是：`我想确认这个错误处理是否会吞掉异常`，或者 `这段锁的使用是否可能导致死锁`。明确审查目标，别人才能有效投入。