遇到问题，当然应该大胆提问！但绝对不是随便截个图丢给其他人，等待解决方案。
原文请见 提问的智慧 (How To Ask Questions The Smart Way) 。这篇文章对于社区提问给出了很多建议，现作要点精简如下。
请你做到
-
完成了 RTFM (Read The Fucking Manual) 和 STFW (Search The Fucking Web) 两个步骤。
通常，用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他们打这些字的时候也正在读着。这些答复意味着回答者认为
-
你需要的信息非常容易获得；
-
你自己去搜索这些信息比灌给你，能让你学到更多。
-
-
按发生时间先后列出问题症状
问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，你的说明里应该包含你的操作步骤，以及机器和软件的反应，直到问题发生。在命令行处理的情况下，提供一段操作记录（例如运行脚本工具所生成的），并引用相关的若干行（如 20 行）记录会非常有帮助。
-
如果程序有诊断选项（如
-v--verbose--debugLOG_LEVEL=DEBUG的详情指令），试着选择这些能在记录中增加调试信息的选项。记住，多不等于好。试着选取适当的调试级别以便提供有用的信息而不是让读者淹没在垃圾中。 -
如果你的说明很长，在开头简述问题，接下来再按时间顺序详述会有所帮助。
-
-
描述目标而不是过程
如果你想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。
😒
BAD| 我怎样才能从某绘图程序的颜色选择器中取得十六进制的 RGB 值？😊
GOOD| 我正试着用替换一幅图片的色码（color table）成自己选定的色码，我现在知道的唯一方法是编辑每个色码区块（table slot）， 但却无法从某绘图程序的颜色选择器取得十六进制的 RGB 值。 -
问题解决后，加个简短的补充说明
-
补充说明不必很长或是很深入。简单的一句
你好，原来是网线出了问题！谢谢大家。比什么也不说要来的好。 -
事实上，除非结论真的很有技术含量，一句话就够了：说明问题是怎样解决的，但大可不必将解决问题的过程复述一遍。
-
对于有深度的问题，张贴调试记录的摘要是有帮助的。但请记住，先描述问题的最终状态，说明是什么解决了问题，在此之后才指明踩坑的地方。
-
在即时聊天软件里问问题
为了避免重复答疑，你应该在群里询问常见问题。由于部分聊天软件没有话题串的功能（或着实现很差），同时群里还可能有多个同时讨论的话题，你应当避免在聊天里刷屏。
为了展示足够多的日志信息，让大家能了解你的问题，同时避免刷屏，请使用 Pastebin 来展示你的日志/代码/操作过程。
