开发过程中遇到问题提问，让他人快速理解你的问题、同时如何在提问中学习成长
相关阅读链接: How To Ask Questions The Smart Way
注：中文部分修改
①Before You Ask
Before asking a technical question by e-mail, or in a newsgroup, or on a website chat board, do the following:
- Try to find an answer by searching the archives of the forum or mailing list you plan to post to.
- Try to find an answer by searching the Web.
- Try to find an answer by reading the manual.
- Try to find an answer by reading a FAQ.
- Try to find an answer by inspection or experimentation.
- Try to find an answer by asking a skilled friend.
- If you’re a programmer, try to find an answer by reading the source code.
① 在问之前
在通过电子邮件、新闻组或网站聊天板询问技术问题之前，请执行以下操作:
- 通过搜索论坛的档案或计划发布到的邮件列表来找到答案。
- 在网上搜索答案。
- 通过阅读手册找到答案。
- 通过阅读常见问题来找到答案。
- 通过观察或实验找到答案。
- 向一个有经验的朋友寻求答案。
- 如果您是一名程序员，请尝试通过阅读源代码来找到答案。
②Stack Overflow
Search, then ask on Stack Exchange Start with a Google search，the Stack Exchange sites are often near the top of the search results.
If you didn’t find anything through Google, search again on the specific site most relevant to your question (see below). Searching with tags can help narrow down the results.
If you still didn’t find anything, post your question on the one site where it’s most on-topic.
add tags that are related to the substance of your question (particularly the name of the programming language, operating system, or library you’re having trouble with).
② Stack Overflow(CSDN)
搜索，然后询问Stack Overflow（全球IT界最受欢迎的技术问答网站），或者CSDN（对于初学者来说足够了)。
百度搜索时，CSDN相关问题的站点通常位于搜索结果的顶部。
如果没有通过百度找到想要的东西，再次搜索与你的问题最相关的特定网站。使用标签搜索可以帮助缩小搜索结果的范围。
如果仍然没有找到任何东西，把问题贴在最热门的网站上。 添加与问题的实质相关的标记(特别是编程语言、操作系统或有问题的库的名称)。
③Be precise and informative about your problem
1.Describe the symptoms of your problem or bug carefully and clearly.
2.Describe the environment in which it occurs (machine, OS, application, whatever). Provide your vendor’s distribution and release level (e.g.: “Fedora Core 7”, “Slackware 9.1”, etc.).
3.Describe the research you did to try the problem before you asked the question.
4.Describe the diagnostic steps you took to try and pin down the problem yourself.
5.Describe any possibly relevant recent changes in your computer or software configuration.
If at all possible, provide a way to reproduce the problem in a controlled environment.
③ 精确描述关于你的问题
- 仔细清楚地描述问题或bug的症状。
- 描述它发生的环境(机器、操作系统、应用程序等)。提供你的供应商的发行和发布级别(例如:“Fedora Core 7”，“Slackware 9.1”等等)。
- 描述在你问这个问题之前，你为解决这个问题所做的研究。
- 描述一下你自己试图确定问题的诊断步骤。
- 请描述您的计算机或软件配置中最近可能发生的任何相关更改。 如果可能的话，提供一种在受控环境中重现问题的方法。
④Describe the problem’s symptoms, not your guesses
If you feel it’s important to state your guess, clearly label it as such and describe why that answer isn’t working for you.
Example：
I’m getting back-to-back SIG11 errors on kernel compiles, and suspect a hairline crack on one of the motherboard traces. What’s the best way to check for those?
Smarter:
My home-built K6/233 on an FIC-PA2007 motherboard (VIA Apollo VP2 chipset) with 256MB Corsair PC133 SDRAM starts getting frequent SIG11 errors about 20 minutes after power-on during the course of kernel compiles, but never in the first 20 minutes. Rebooting doesn’t restart the clock, but powering down overnight does. Swapping out all RAM didn’t help. The relevant part of a typical compile session log follows.
④ 描述问题的症状,而不是你的猜测
如果你觉得说出你的猜测很重要，就清楚地把它标出来，并说明为什么这个答案对你不合适。
例子:我在内核编译中遇到了连续的SIG11错误，并怀疑在一个主板跟踪中出现了细微的裂纹。检查这些的最好方法是什么?
更好的表达: 我在一个ficc - pa2007主板(通过Apollo VP2芯片组)上自制的K6/233具有256MB的Corsair PC133 SDRAM，在内核编译过程中，在开机大约20分钟后开始频繁地出现SIG11错误，但在最初的20分钟内从未出现过。重启不会重启时钟，但夜间关机会。换出所有内存没有帮助。下面是典型编译会话日志的相关部分。
⑤Describe your problem’s symptoms in chronological order
The clues most useful in figuring out something that went wrong often lie in the events immediately prior. So, your account should describe precisely what you did, and what the machine and software did, leading up to the blowup. In the case of command-line processes, having a session log (e.g., using the script utility) and quoting the relevant twenty or so lines is very useful.
If the program that blew up on you has diagnostic options (such as -v for verbose), try to select options that will add useful debugging information to the transcript. try to choose a debug level that will inform rather than drowning the reader in junk.
If your account ends up being long (more than about four paragraphs), it might be useful to succinctly state the problem up top, then follow with the chronological tale.
⑤ 按时间顺序描述你的问题的症状
最有用的线索往往是在事件发生之前。所以，你的账户应该准确地描述你做了什么，以及机器和软件做了什么，从而导致爆炸。对于命令行进程，使用会话日志(例如使用脚本工具)并引用相关的20行左右是非常有用的。
如果发生故障的程序具有诊断选项(例如-v表示verbose)，请尝试选择将有用的调试信息添加到记录的选项。试着选择一个能够通知读者的调试级别，而不是让读者陷入垃圾中。
如果你的叙述很长(超过四段)，那么在最上面简明地陈述问题，然后按照时间顺序叙述可能会很有用。
⑥Describe the goal, not the step
If you are trying to find out how to do something (as opposed to reporting a bug), begin by describing the goal. Only then describe the particular step towards it that you are blocked on.
Example：
How do I get the color-picker on the FooDraw program to take a hexadecimal RGB value?
Smarter:
I’m trying to replace the color table on an image with values of my choosing. Right now the only way I can see to do this is by editing each table slot, but I can’t get FooDraw’s color picker to take a hexadecimal RGB value.
The second version allows an answer that suggests a tool better suited to the task.
⑥描述问题目标，而不是步骤
如果您试图找出如何做某事(与报告错误相反)，那么从描述目标开始。只有这样，你才能描述你被阻止的具体步骤。
例子:我如何让颜色选择器在FooDraw程序采取一个十六进制RGB值?
更好的表达:我试图用我选择的值替换图像上的颜色表。现在我能看到的唯一的方法是编辑每个表槽，但是我不能让FooDraw的颜色选择器取一个十六进制的RGB值。
第二个版本给出的答案是一种更适合这项任务的工具。
开发过程中遇到问题提问，让他人快速理解你的问题、同时如何在提问中学习成长
相关阅读链接: How To Ask Questions The Smart Way
注：中文部分修改
笔记摘要（中英对照）
- ①Before You Ask
- ②Stack Overflow
- ③Be precise and informative about your problem
- ④Describe the problem's symptoms, not your guesses
- ⑤Describe your problem's symptoms in chronological order
- ⑥Describe the goal, not the step
①Before You Ask
Before asking a technical question by e-mail, or in a newsgroup, or on a website chat board, do the following:
- Try to find an answer by searching the archives of the forum or mailing list you plan to post to.
- Try to find an answer by searching the Web.
- Try to find an answer by reading the manual.
- Try to find an answer by reading a FAQ.
- Try to find an answer by inspection or experimentation.
- Try to find an answer by asking a skilled friend.
- If you’re a programmer, try to find an answer by reading the source code.
① 在问之前
在通过电子邮件、新闻组或网站聊天板询问技术问题之前，请执行以下操作:
- 通过搜索论坛的档案或计划发布到的邮件列表来找到答案。
- 在网上搜索答案。
- 通过阅读手册找到答案。
- 通过阅读常见问题来找到答案。
- 通过观察或实验找到答案。
- 向一个有经验的朋友寻求答案。
- 如果您是一名程序员，请尝试通过阅读源代码来找到答案。
②Stack Overflow
Search, then ask on Stack Exchange Start with a Google search，the Stack Exchange sites are often near the top of the search results.
If you didn’t find anything through Google, search again on the specific site most relevant to your question (see below). Searching with tags can help narrow down the results.
If you still didn’t find anything, post your question on the one site where it’s most on-topic.
add tags that are related to the substance of your question (particularly the name of the programming language, operating system, or library you’re having trouble with).
② Stack Overflow(CSDN)
搜索，然后询问Stack Overflow（全球IT界最受欢迎的技术问答网站），或者CSDN（对于初学者来说足够了)。
百度搜索时，CSDN相关问题的站点通常位于搜索结果的顶部。
如果没有通过百度找到想要的东西，再次搜索与你的问题最相关的特定网站。使用标签搜索可以帮助缩小搜索结果的范围。
如果仍然没有找到任何东西，把问题贴在最热门的网站上。 添加与问题的实质相关的标记(特别是编程语言、操作系统或有问题的库的名称)。
③Be precise and informative about your problem
1.Describe the symptoms of your problem or bug carefully and clearly.
2.Describe the environment in which it occurs (machine, OS, application, whatever). Provide your vendor’s distribution and release level (e.g.: “Fedora Core 7”, “Slackware 9.1”, etc.).
3.Describe the research you did to try the problem before you asked the question.
4.Describe the diagnostic steps you took to try and pin down the problem yourself.
5.Describe any possibly relevant recent changes in your computer or software configuration.
If at all possible, provide a way to reproduce the problem in a controlled environment.
③ 精确描述关于你的问题
- 仔细清楚地描述问题或bug的症状。
- 描述它发生的环境(机器、操作系统、应用程序等)。提供你的供应商的发行和发布级别(例如:“Fedora Core 7”，“Slackware 9.1”等等)。
- 描述在你问这个问题之前，你为解决这个问题所做的研究。
- 描述一下你自己试图确定问题的诊断步骤。
- 请描述您的计算机或软件配置中最近可能发生的任何相关更改。 如果可能的话，提供一种在受控环境中重现问题的方法。
④Describe the problem’s symptoms, not your guesses
If you feel it’s important to state your guess, clearly label it as such and describe why that answer isn’t working for you.
Example：
I’m getting back-to-back SIG11 errors on kernel compiles, and suspect a hairline crack on one of the motherboard traces. What’s the best way to check for those?
Smarter:
My home-built K6/233 on an FIC-PA2007 motherboard (VIA Apollo VP2 chipset) with 256MB Corsair PC133 SDRAM starts getting frequent SIG11 errors about 20 minutes after power-on during the course of kernel compiles, but never in the first 20 minutes. Rebooting doesn’t restart the clock, but powering down overnight does. Swapping out all RAM didn’t help. The relevant part of a typical compile session log follows.
④ 描述问题的症状,而不是你的猜测
如果你觉得说出你的猜测很重要，就清楚地把它标出来，并说明为什么这个答案对你不合适。
例子:我在内核编译中遇到了连续的SIG11错误，并怀疑在一个主板跟踪中出现了细微的裂纹。检查这些的最好方法是什么?
更好的表达: 我在一个ficc - pa2007主板(通过Apollo VP2芯片组)上自制的K6/233具有256MB的Corsair PC133 SDRAM，在内核编译过程中，在开机大约20分钟后开始频繁地出现SIG11错误，但在最初的20分钟内从未出现过。重启不会重启时钟，但夜间关机会。换出所有内存没有帮助。下面是典型编译会话日志的相关部分。
⑤Describe your problem’s symptoms in chronological order
The clues most useful in figuring out something that went wrong often lie in the events immediately prior. So, your account should describe precisely what you did, and what the machine and software did, leading up to the blowup. In the case of command-line processes, having a session log (e.g., using the script utility) and quoting the relevant twenty or so lines is very useful.
If the program that blew up on you has diagnostic options (such as -v for verbose), try to select options that will add useful debugging information to the transcript. try to choose a debug level that will inform rather than drowning the reader in junk.
If your account ends up being long (more than about four paragraphs), it might be useful to succinctly state the problem up top, then follow with the chronological tale.
⑤ 按时间顺序描述你的问题的症状
最有用的线索往往是在事件发生之前。所以，你的账户应该准确地描述你做了什么，以及机器和软件做了什么，从而导致爆炸。对于命令行进程，使用会话日志(例如使用脚本工具)并引用相关的20行左右是非常有用的。
如果发生故障的程序具有诊断选项(例如-v表示verbose)，请尝试选择将有用的调试信息添加到记录的选项。试着选择一个能够通知读者的调试级别，而不是让读者陷入垃圾中。
如果你的叙述很长(超过四段)，那么在最上面简明地陈述问题，然后按照时间顺序叙述可能会很有用。
⑥Describe the goal, not the step
If you are trying to find out how to do something (as opposed to reporting a bug), begin by describing the goal. Only then describe the particular step towards it that you are blocked on.
Example：
How do I get the color-picker on the FooDraw program to take a hexadecimal RGB value?
Smarter:
I’m trying to replace the color table on an image with values of my choosing. Right now the only way I can see to do this is by editing each table slot, but I can’t get FooDraw’s color picker to take a hexadecimal RGB value.
The second version allows an answer that suggests a tool better suited to the task.
⑥描述问题目标，而不是步骤
如果您试图找出如何做某事(与报告错误相反)，那么从描述目标开始。只有这样，你才能描述你被阻止的具体步骤。
例子:我如何让颜色选择器在FooDraw程序采取一个十六进制RGB值?
更好的表达:我试图用我选择的值替换图像上的颜色表。现在我能看到的唯一的方法是编辑每个表槽，但是我不能让FooDraw的颜色选择器取一个十六进制的RGB值。
第二个版本给出的答案是一种更适合这项任务的工具。
