在问答网站提问
在提问之前
在准备要通过电子邮件、新闻群组或者聊天室提出技术问题前，应做到以下事情：
- 尝试在准备提问的论坛的旧文章中搜索答案。
- 尝试上网搜索以找到答案。
- 尝试阅读手册以找到答案。
- 尝试阅读常见问题文件（FAQ）以找到答案。
- 尝试自己检查或试验以找到答案。
- 向身边的强者朋友打听以找到答案。
- 程序开发者请尝试阅读源代码以找到答案。
提出问题的时候，应先表明自己已经做了上述的努力；这将有助于树自己并不是一个不劳而获且浪费别人的时间的提问者的形象。如果能一并表达在做了上述努力的过程中所学到的东西会更好，因为回答者更乐于回答那些表现出能从答案中学习的人的问题。
准备好自己的问题，再将问题仔细的思考过一遍.
在提问时
应该要小心选择自己提问的场合，避免做下述事情：
- 在与主题不和的论坛上贴出自己的问题。
- 在探讨进阶技术问题的论坛张贴非常初级的问题；反之亦然。
- 在太多的不同新闻群组上重复转贴同样的问题（cross-post）。
- 向既非熟人也没有义务解决我们问题的人发送私人电邮。
黑客会剔除掉那些搞错场合的问题，以保护他们沟通的渠道不被无关的东西淹没。
因此，第一步是找到对的论坛。
在选择论坛、新闻群组或邮件列表时，别太相信名字，先看看 FAQ 或者许可书以弄清楚自己的问题是否切题。发文前先翻翻已有的话题，这样可以帮助我们感受那里的文化。
事先在新闻组或邮件列表的历史记录中搜索与自己的问题相关的关键词是个很好的主意，也许这样就找到答案了。即使没有，也能帮助我们归纳出更好的问题。
这里有两个推荐的技术类问答网站：
http://segmentfault.com -（国内）
https://stackoverflow.com -（国外）
在任何论坛发文以前，先确认一下有没有搜索功能。如果有，就试着搜索一下问题的几个关键词，也许这会有帮助。
第二部 使用项目邮件列表
当某个项目提供开发者邮件列表时，要向列表而不是其中的个别成员提问，即使确信他能最好地回答你的问题。查一查项目的文件和首页，找到项目的邮件列表并使用它。
如果一个项目既有"使用者" 也有"开发者"（或"黑客"）邮件列表或论坛，而自己又不会动到那些源代码，那么就向"使用者"列表或论坛提问。
如果确信自己的问题很特别，而且在"使用者" 列表或论坛中几天都没有回复，可以试试前往"开发者"列表或论坛发问。最好在张贴前最好先暗地里观察几天以了解那里的行事方式。
如果找不到一个项目的邮件列表，而只能查到项目维护者的电子邮件地址，尽管向他发信。但在自己的电子邮件中要陈述自己已经试过但没有找到合适的邮件列表，也说明自己不反对将自己的邮件转发给他人。
要注意的地方
使用有意义且描述明确的标题
在邮件列表、新闻群组或论坛中，大约 50 字以内的标题是抓住资深专家注意力的好机会。
一个好标题的范例是目标—差异式的描述，在目标部分指出哪一个或哪一组东西有问题，在差异部分则描述与期望的行为不一致的地方。
如：
蠢问题：救命啊！我的笔记本电脑不能正常显示了！
聪明问题：X.org 6.8.1鼠标光标会变形，某牌显卡MV1005芯片组。
更聪明的问题：X.org 6.8.1鼠标光标，在某牌显卡MV1005芯片组环境下 - 会变形。
如果想在回复中提出问题，记得要修改内容标题，以表明自己是在问一个问题。
不要直接点击回复来开始一个全新的讨论串，因为有些邮件阅读程序会折叠讨论串，这将限制我们问题的观众。因此，宁可发一个全新的邮件。
使问题容易回复
在邮件客户端设置回复地址。
在论坛，要求通过电子邮件回复是非常无礼的。如果只是想在有人回复讨论串时得到电子邮件提醒，可以要求网页论坛发送给自己。几乎所有论坛都支持诸如追踪此讨论串、有回复时发送邮件提醒等功能。
用清晰、正确、精准并语法正确的语句
正确的拼写、标点符号和大小写是很重要的。可以使用非正式、俚语和幽默的语句，但它必须很准确，并且能表明自己是在思考和关注问题。
如果在使用非母语的论坛提问，可以犯点拼写和语法上的小错，但决不能在思考上马虎。
除非知道回复者使用的语言，否则应使用英语书写。英语非母语的我们，可以提示潜在回复者我们有语言困难，如：
English is not my native language; please excuse typing errors.
使用易于读取且标准的文件格式发送问题
- 使用纯文字而不是HTML。
- 使用MIME附件的前提是真正有内容（如源代码）。
- 不要发送一段文字只是一行句子但自动换行后会变成多行的邮件。设想读者是在 80 个字符宽的终端机上阅读邮件，最好设置换行分割点小于 80 字。
- 对日志档案拷贝等特殊文件不要设置固定宽度。数据应该原样包含。
- 在英语论坛中，不要使用
Quoted-PrintableMIME 编码发送消息。 - 绝对，永远不要指望黑客们阅读使用封闭格式编写的文档，像微软公司的 Word 或 Excel 文件等。
- 从使用 Windows 的电脑发送电子邮件时，关闭
智能引号功能。 - 在论坛，不要滥用表情符号和
HTML功能（当它们提供时）。
精确地描述问题并言之有物
- 仔细、清楚地描述自己的问题或Bug的症状。
- 描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息），提供经销商的发行版和版本号（如：
Fedora Core 4、Slackware 9.1等）。 - 描述在提问前自己是怎样去研究和理解这个问题的。
- 描述在提问前为确定问题而采取的诊断步骤。
- 描述最近做过什么可能相关的硬件或软件变更。
- 尽可能的提供一个可以
重现这个问题的可控环境的方法。
话不在多而在精
提问时应该提供精确有内容的信息，但这并不是说简单的把成堆的出错代码或者资料完全转录到提问中，尽量剪裁得越小越好。
别动辄声称找到Bug
在使用软件中遇到问题，除非自己能提供解决问题的源代码补丁，或者提供回归测试来表明前一版本中行为不正确，否则不要动辄声称自己找到了 Bug。
提问时，即使自己私下非常确信已经发现一个真正的 Bug，最好写得像是自己做错了什么。如果真的有 Bug，会在回复中看到这点的。这样做的话，如果真有 Bug，维护者就会向我们道歉，这比我们惹恼别人然后欠别人一个道歉要好一点。
低声下气不能代替功课
尽可能清楚地描述背景条件和自己的问题情况。这比低声下气更好地定位了自己的位置。
有时网页论坛会设有专为新手提问的版面，如果真的认为自己遇到了初学者的问题，就去那里提问，但也别低声下气。
描述问题症状而不是自己的猜测
要确信自己原原本本告诉了黑客们问题的症状，而不是解释和理论；让黑客们来推测和诊断。如果认为陈述自己的猜测很重要，要清楚地说明这只是自己的猜测，并描述为什么它们不起作用。
按发生时间先后列出问题症状
问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，问题说明里应该包含自己的操作步骤，以及机器和软件的反应，直到问题发生。在命令行处理的情况下，提供一段操作记录（例如运行脚本工具所生成的），并引用相关的若干行（如 20 行）记录会非常有帮助。
描述目标而不是过程
如果想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述自己的目标，然后才陈述重现自己所卡住的特定步骤。
别要求使用私人电邮回复
黑客们认为问题的解决过程应该公开、透明，此过程中如果更有经验的人注意到不完整或者不当之处，最初的回复才能够、也应该被纠正。同时，作为提供帮助者可以得到一些奖励，奖励就是他的能力和学识被其他同行看到。
让回复者来决定是否私下回答。
清楚明确地表达自己地问题及需求
明确表述需要回答者做什么，界定一下自己地问题，使专家花在辨识问题和回答所需要付出的时间减到最少，就最有可能得到有用的答案。
询问有关代码地问题时
最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例，即就是问题的缩影，一小个刚好能展示出程序地异常行为地程序片段。
如果知道哪一行或哪一段代码会造成异常的行为，复制下来并加入足够重现这个状况的代码。如果无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。测试用例越小越好。
如果只是想让别人帮忙审（Review）一下代码，在信的开头就要说出来，并且一定要提到自己认为哪一部分特别需要关注以及为什么。
别把自己家庭作业的问题贴上来
因为这些问题得由我们自己来搞定，我们会从中学到东西。可以要求别人给点提示，但别要求得到完整的解决方案。
如果怀疑自己碰到了一个家庭作业式的问题，但仍然无法解决，试试在使用者群组，论坛或（最后一招）在项目的使用者邮件列表或论坛中提问。
去掉无意义的提问句
避免用无意义的话结束提问，例如有人能帮我吗？或者这有答案吗？。
一般来说，避免用 是或否、对或错、有或没有类型的问句，除非想得到是或否类型的回答。
即使很紧急也不要在标题写 紧急
这是我们自己的问题，不是回答者们的。
这样的标题很可能会被回答者们删除甚至会惹怒他们。
礼多人不怪，而且有时还很有帮助。
彬彬有礼，多用请和谢谢您的关注或谢谢你的关照，让回答者们知道我们对他们花时间免费提供帮助心存感激。
问题解决后，加个简短的补充说明
问题解决后，向所有帮助过自己的人发个说明，让他们知道问题是怎样解决的，并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注，应该在那里贴一个说明比较恰当。
最理想的方式是向最初提问的话题回复此消息，并在标题中包含已修正，已解决或其它同等含义的明显标记。
如何解读答案
RTFM 和 STFW
RTFM (Read The Fucking Manual)
STFW (Search The Fucking Web)
这两句答复意味着：
- 我们需要的信息非常容易获得
- 我们应该自己去搜索这些信息
如果还是搞不懂
如果看不懂回应，别立刻要求对方解释。像以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。如果真的需要对方解释，记得要表现出自己已经从中学到了点什么。
处理无礼的回应
如果觉得自己被冒犯了，试着平静地反应。如果有人真的做了出格的事，邮件列表、新闻群组或论坛中的前辈多半会招呼他。如果这没有发生而我们自己却发火了，那么我们发火对象的言语可能在黑客社区中看起来是正常的，而我们将被视为有错的一方，这将伤害到我们获取信息或帮助的机会。
如果得不到回答
如果得不到回复，最好不要简单的重复张贴问题。还可以通过其他渠道获得帮助，如网上及本地的使用者群组，或者向很多商业公司寻求帮助。
如何更好地回答问题
在学习过程中，我们一定会有许多问题需要别人帮助解答，随着学习的深入，我们也会有帮别人解答问题的能力。推己及人，回答别人的问题时，我们应该：
- 态度和善一点。
- 对初犯者私下回复。
- 如果不确定，一定要说出来！
- 如果帮不了忙，也别妨碍他！
- 试探性地反问以引导出更多的细节。
- 如果决定回答，就请给出好的答案。
- 正面地回答问题！
- 帮助社区从问题中学习。
- 展现技巧而不是直接端出结果。
当面向人请教技术问题
当面向别人请教问题时，出了提问网站使用的一些技术点外，基本的方式方法是相通的。
当我们要当面请教别人问题时应该：
- 在请教前首先在网站和论坛上搜索自己的问题，能自己在依靠资料解决的问题就不要去麻烦别人。
- 请教问题前先精炼自己的问题，抓住重点，将实质问题资料，如故障的计算机，有问题的代码块等，提前准备好，节约别人的时间。
- 描述问题时，把自己为了解决这个问题所作的尝试也说出来，无论有没有效。
- 请教问题时注意礼貌用语。
- 语气也不必太低声下气，弄得彼此都不自在。
- 表达感谢，无论对方有没有解决问题。
- 如果对方没有解决问题，再自己找到解决的办法后，分享给对方。或者之后找到了更加好的解决办法，也可以分享给对方，共同进步。
小黄鸭调试法
有时当我们像别人描述自己遇到的问题时，在倾诉中途我们就会恍然大悟，自己找到解决的办法。但是别人并非一直有空，甚至有些人也不喜欢向别人倾诉，那么我们就可以向其他东西倾诉。
小黄鸭调试法是软件在工程中使用的调试代码方法之一。就是在程序的调试、纠错或测试过程中，耐心地向小黄鸭解释每一行程序地作用，以此来激发灵感。
在流传的故事中，程序大师会向一只随身携带的小黄鸭解释代码，因而这种方法被称为小黄鸭调试法。
我们也可以选择自己喜欢的任意物品。
