https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/master/README-zh_CN.md 当你拋出一个技术问题时，最终是否能得到有用的回答，往往取决于你所提问和追问的方式。 我们不讳言我们对那些不愿思考、或者在发问前不做他们该做的事的人的蔑视。那些人是时间杀手 —— 他们只想索取，从不付出，消耗我们可用在更有趣的问题或更值得回答的人身上的时间。我们称这样的人为 失败者（撸瑟） 我们回答问题的风格是指向那些真正对此有兴趣并愿意主动参与解决问题的人，这一点不会变，也不该变。如果连这都变了，我们就是在降低做自己最擅长的事情上的效率。 我们（在很大程度上）是自愿的，从繁忙的生活中抽出时间来解答疑惑，而且时常被提问淹没。所以我们无情的滤掉一些话题，特别是拋弃那些看起来像失败者的家伙，以便更高效的利用时间来回答赢家（winner）的问题。 如果你厌恶我们的态度，高高在上，或过于傲慢，不妨也设身处地想想。我们并没有要求你向我们屈服 —— 事实上，我们大多数人非常乐意与你平等地交流，只要你付出小小努力来满足基本要求，我们就会欢迎你加入我们的文化。但让我们帮助那些不愿意帮助自己的人是没有效率的。 如果你做不到这些，我们建议你花点钱找家商业公司签个技术支持服务合同，而不是要求黑客个人无偿地帮助你。 提问之前
- 尝试在你准备提问的论坛的旧文章中搜索答案。
- 尝试上网搜索以找到答案。
- 尝试阅读手册以找到答案。
- 尝试阅读常见问题文件（FAQ）以找到答案。
- 尝试自己检查或试验以找到答案。
- 向你身边的强者朋友打听以找到答案。
- 如果你是程序开发者，请尝试阅读源代码以找到答案。
当你提出问题的时候，请先表明你已经做了上述的努力；这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。 先用 Google 搜索你所遇到的各种错误信息（既搜索 Google 论坛，也搜索网页） 草率的发问只能得到草率的回答 当你提问时 Stack Exchange 已经成长到超过一百个网站，以下是最常用的几个站：
- Super User 是问一些通用的电脑问题，如果你的问题跟代码或是写程序无关，只是一些网络连线之类的，请到这里。
- Stack Overflow 是问写程序有关的问题。
- Server Fault 是问服务器和网管相关的问题。
邮件列表 大多数邮件列表都会被存档，那些被存档的内容将被搜索引擎索引。 花几秒钟在邮件客户端设置一下回复地址，如果你的邮件程序不支持这样做，换个好点的 不要使用即时通信中的简写 在使用非母语的论坛提问，你可以犯点拼写和语法上的小错，但决不能在思考上马虎 如果英文是你的外语： English is not my native language; please excuse typing errors. 最好设置你的换行分割点小于 80 字。 精确地描述问题： 描述问题发生的环境（操作系统，版本号）
- 描述在提问前为确定问题而采取的诊断步骤。
- 描述最近做过什么可能相关的硬件或软件变更。
- 尽可能的提供一个可以重现这个问题的的方法
问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，你的说明里应该包含你的操作步骤，以及机器和软件的反应，直到问题发生。 最有可能给你有用答案的人通常也正是最忙的人 问题解决后，加个简短的补充说明 问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再一次向他们表示感谢。 并在标题中包含已修正，已解决 以下是几个经典蠢问题，以及黑客没回答时心中所想的： 我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗？ 回答：试试看就知道了。如果你试过，你既知道了答案，就不用浪费我的时间了。 我的{程序/设定/SQL 语句}不工作 回答：这不算是问题吧，我对要我问你二十个问题才找得出你真正问题的问题没兴趣 如果仍得不到回答，请不要以为我们觉得无法帮助你。有时只是看到你问题的人不知道答案罢了。没有回应不代表你被忽视，虽然不可否认这种差别很难区分。 对初犯者私下回复。对那些坦诚犯错之人没有必要当众羞辱，一个真正的新手也许连怎么搜索或在哪找常见问题都不知道。 如果帮不了忙，也别妨碍他。 如果你决定回答，就请给出好的答案。 如果你需要个人电脑、Unix 系统和网络如何运作的基础知识，参阅 Unix 系统和网络基本原理。 当你发布软件或补丁时，试着按软件发布实践操作。
时间宝贵，只能复制+粘贴，若图片无法显示或排版混乱，请访问elesos.com查找原文
