https://mp.weixin.qq.com/s/30_F_kOzmjDBiijslvRPEg
http://www.catb.org/esr/faqs/smart-questions.html
The first thing to understand is that hackers actually like hard problems and good, thought-provoking questions about them. If we didn't, we wouldn't be here. If you give us an interesting question to chew on we'll be grateful to you; good questions are a stimulus and a gift. Good questions help us develop our understanding, and often reveal problems we might not have noticed or thought about otherwise. Among hackers, “Good question!” is a strong and sincere compliment.
Before asking a technical question by e-mail, or in a newsgroup, or on a website chat board, do the following:
Better yet, display what you have learned from doing these things. We like answering questions for people who have demonstrated they can learn from the answers.
Use tactics like doing a Google search on the text of whatever error message you get (searching Google groups as well as Web pages). This might well take you straight to fix documentation or a mailing list thread answering your question. Even if it doesn't, saying “I googled on the following phrase but didn't get anything that looked promising” is a good thing to do in e-mail or news postings requesting help, if only because it records what searches won't help. It will also help to direct other people with similar problems to your thread by linking the search terms to what will hopefully be your problem and resolution thread.
Take your time. Do not expect to be able to solve a complicated problem with a few seconds of Googling. Read and understand the FAQs, sit back, relax and give the problem some thought before approaching experts. Trust us, they will be able to tell from your questions how much reading and thinking you did, and will be more willing to help if you come prepared. Don't instantly fire your whole arsenal of questions just because your first search turned up no answers (or too many).
Prepare your question. Think it through. Hasty-sounding questions get hasty answers, or none at all. The more you do to demonstrate that having put thought and effort into solving your problem before seeking help, the more likely you are to actually get help.
Don't ask others to debug your broken code without giving a hint what sort of problem they should be searching for. Posting a few hundred lines of code, saying "it doesn't work", will get you ignored. Posting a dozen lines of code, saying "after line 7 I was expecting to see <x>, but <y> occurred instead" is much more likely to get you a response.
If you don't understand the answer, do not immediately bounce back a demand for clarification. Use the same tools that you used to try and answer your original question (manuals, FAQs, the Web, skilled friends) to understand the answer. Then, if you still need to ask for clarification, exhibit what you have learned.
For example, suppose I tell you: “It sounds like you've got a stuck zentry; you'll need to clear it.” Then: here's a bad followup question: “What's a zentry?” Here's a good followup question: “OK, I read the man page and zentries are only mentioned under the -z and -p switches. Neither of them says anything about clearing zentries. Is it one of these or am I missing something here?”
Write in clear, grammatical, correctly-spelled language
Send questions in accessible, standard formats
Be precise and informative about your problem
Volume is not precision
Don't rush to claim that you have found a bug
Grovelling is not a substitute for doing your homework
Describe the problem's symptoms, not your guesses
Describe your problem's symptoms in chronological order
Describe the goal, not the step
Don't ask people to reply by private e-mail
Be explicit about your question
When asking about code
提问也有技巧，不同的提问方式，可能会带来不同的效果；提问也是有模式的，具体来说可以总结为三种：
第一种，封闭式提问
人在面对封闭式提问时，一般只能正面回答，给出直接的答案，封闭式提问适用于得到明确答案时提出，在职场和商业场上很有用处。
1.快速决断，终结无休止的讨论
当发现一个人说话都是在不停地兜圈子，就要果断打断他，直接一句：“你要表达的东西太多，可不可以一句话概括？”、“你的结论是什么？”
2.单选题，锁定条件
有些场景，不需要太多的讨论，不然很难做决定，这个时候把问题说具体一点，只提供单选题，锁定条件，这样反而能够拿到答案。
我发现每个月的小团建，如果问大家想搞什么，每次都很难统一，所以我只能通过封闭式的问题来做出决定：“是希望工作日下班的一个晚上、还是周末白天？”、“是想吃饭还是打球？”；因为最终还是要一个人排版，但又不能让大家觉得很独断，就只能用一个个的单选题来锁定条件。
3.是非题，直指要害
有时候咱们只需要对方说“是”或者“不是”，不需要过多的啰嗦，这种问题会让人感觉很强势，但越简单粗暴越有效率，能够让我们快速得到明确的答案。
第二种，开放式提问
以前考试的时候一般最后都会有一些问答题，这些就是开放式的问题。所谓开放性，就是没有固定的答案，每个人都可能会有自己的想法，可以随便发表意见。职场上利用好“开放性问题”，有时候发挥很大威力。
1.打开话闸
我们在做技术分享的时候，大家习得的第一的技巧就是：通过一个问题开场，可以激发大家的兴趣；而这个问题，一般都是开放性的问题。比如我们在做《函数计算-serverless简介》的时候，开场就会说：“什么是函数计算？”，这时就可以引发大家思考和解说。
想要跟同事讨论问题，常常的做法也是通过一个开放性的问题打开话闸，比如想要获取对方的意见：“你对这个月测试资源不足这个问题有什么看法？”
2.发散思维
开放性的问题可以引出大家的思考，在一些讨论问题的关键节点，如果能巧妙抛出适当的开放性问题，能瞬间点燃大家的热情，收获更多的建设性意见；虽然这个很好理解，但实际操作起来很多时候都做的不够，因为做到需要具备比较强的意识。
3.激发善意
开放性问题，我会在一对一沟通的场景用的比较多，一对一的时候我们要获取对方的信任、更多的倾听对方的感受，这个时候多提一些“为什么”、“如何”、“你觉得”这些问题，可以很好的做出引导。
第三种，追问式提问
“追问”的形式适用于在复杂情况中寻找核心问题，通过一连串的提问，引发深刻的思考，从而找到本质答案。
1.排查问题
有些复杂的问题，很久都找不到答案，如果通过追问的方式，可以梳理思路，通过一连串的“为什么”，最终找到根本原因。
2.复盘项目
追问的提问方式，还可以用在复盘，比如我们熟悉的“5W2H”法则：
WHAT(何事) ：做什么
WHO(何人) ：谁来做
WHY(何因) ：为什么做
WHEN(何因) ：何时做
WHERE(何时) ：在那里做
HOW(如何做) ：怎么做
HOW MUCH(做多少) ：做到什么程度
好，总结一下，我认为学会提问，能够让自己在很多工作场景中变得更有效，甚至可以更好的影响家人、朋友，提问分为封闭式提问、开放式提问、以及追问，封闭式提问适用于要求得到明确答案，开放式提问适用于引入思考、发散思维，追问适用于在复杂情况中寻找核心问题，每一种方式对应解决的场景和问题有所不同，我们要学会区分、巧妙利用；学会提问也是一种很好的技能，它能让我们更轻松、从容的应对生活和工作。
The first thing to understand is that hackers actually like hard problems and good, thought-provoking questions about them. If we didn't, we wouldn't be here. If you give us an interesting question to chew on we'll be grateful to you; good questions are a stimulus and a gift. Good questions help us develop our understanding, and often reveal problems we might not have noticed or thought about otherwise. Among hackers, “Good question!” is a strong and sincere compliment.
- 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.
Use tactics like doing a Google search on the text of whatever error message you get (searching Google groups as well as Web pages). This might well take you straight to fix documentation or a mailing list thread answering your question. Even if it doesn't, saying “I googled on the following phrase but didn't get anything that looked promising” is a good thing to do in e-mail or news postings requesting help, if only because it records what searches won't help. It will also help to direct other people with similar problems to your thread by linking the search terms to what will hopefully be your problem and resolution thread.
Take your time. Do not expect to be able to solve a complicated problem with a few seconds of Googling. Read and understand the FAQs, sit back, relax and give the problem some thought before approaching experts. Trust us, they will be able to tell from your questions how much reading and thinking you did, and will be more willing to help if you come prepared. Don't instantly fire your whole arsenal of questions just because your first search turned up no answers (or too many).
Prepare your question. Think it through. Hasty-sounding questions get hasty answers, or none at all. The more you do to demonstrate that having put thought and effort into solving your problem before seeking help, the more likely you are to actually get help.
Beware of asking the wrong question. If you ask one that is based on faulty assumptions, J. Random Hacker is quite likely to reply with a uselessly literal answer while thinking “Stupid question...”, and hoping the experience of getting what you asked for rather than what you needed will teach you a lesson.
Never assume you are entitled to an answer. You are not; you aren't, after all, paying for the service. You will earn an answer, if you earn it, by asking a substantial, interesting, and thought-provoking question — one that implicitly contributes to the experience of the community rather than merely passively demanding knowledge from others.
On the other hand, making it clear that you are able and willing to help in the process of developing the solution is a very good start. “Would someone provide a pointer?”, “What is my example missing?”, and “What site should I have checked?” are more likely to get answered than “Please post the exact procedure I should use.” because you're making it clear that you're truly willing to complete the process if someone can just point you in the right direction.
Never assume you are entitled to an answer. You are not; you aren't, after all, paying for the service. You will earn an answer, if you earn it, by asking a substantial, interesting, and thought-provoking question — one that implicitly contributes to the experience of the community rather than merely passively demanding knowledge from others.
On the other hand, making it clear that you are able and willing to help in the process of developing the solution is a very good start. “Would someone provide a pointer?”, “What is my example missing?”, and “What site should I have checked?” are more likely to get answered than “Please post the exact procedure I should use.” because you're making it clear that you're truly willing to complete the process if someone can just point you in the right direction.
Choose your forum carefully
- cross-post to too many different newsgroups
- post a personal e-mail to somebody who is neither an acquaintance of yours nor personally responsible for solving your problem
Don't shotgun-blast all the available help channels at once, that's like yelling and irritates people. Step through them softly.
If a commenter asks you for more information, edit your main post to include it. If any answer is helpful, click the up arrow to upvote it; if an answer gives a solution to your problem, click the check under the voting arrows to accept it as correct.
Before posting to any Web forum, check if it has a Search feature. If it does, try a couple of keyword searches for something like your problem; it just might help. If you did a general Web search before (as you should have), search the forum anyway; your Web-wide search engine might not have all of this forum indexed recently.
There is an increasing tendency for projects to do user support over a Web forum or IRC channel, with e-mail reserved more for development traffic. So look for those channels first when seeking project-specific help.
In IRC, it's probably best not to dump a long problem description on the channel first thing; some people interpret this as channel-flooding. Best to utter a one-line problem description in a way pitched to start a conversation on the channel.
There is an increasing tendency for projects to do user support over a Web forum or IRC channel, with e-mail reserved more for development traffic. So look for those channels first when seeking project-specific help.
In IRC, it's probably best not to dump a long problem description on the channel first thing; some people interpret this as channel-flooding. Best to utter a one-line problem description in a way pitched to start a conversation on the channel.
When asking about code
RTFM
Read The Fucking Manual
How To Interpret Answers
RTFM and STFW: How To Tell You've Seriously Screwed Up
STFW Searched The Fucking web
Google is your friend
You shouldn't be offended by this; by hacker standards, your respondent is showing you a rough kind of respect simply by not ignoring you. You should instead be thankful for this grandmotherly kindness.
If you don't understand...
For example, suppose I tell you: “It sounds like you've got a stuck zentry; you'll need to clear it.” Then: here's a bad followup question: “What's a zentry?” Here's a good followup question: “OK, I read the man page and zentries are only mentioned under the -z and -p switches. Neither of them says anything about clearing zentries. Is it one of these or am I missing something here?”
https://mp.weixin.qq.com/s/6n0UOwug-rOYMbr6RHuViQ
要想让别人高质量地回答你的问题，首先是要明白他为什么会回答你，他的动力是什么？这里，我们姑且有这几种猜测：
- 一颗当网红的心。有那么一部分人（包括但不限于程序员）会希望得到认可，不管是为了扩大影响力还是说为了内心的满足感，他们会去回答问题。这些可能不是全部的驱动力，但是可能会是其中一部分的影响因素。
- 交流使我进步。技术的交流是互利互惠的，通过回答别人的问题，一是能帮助别人，另一个是能帮助自己梳理思路，在回答别人的时候能让自己的方法路更加完善，而且在和提问者的交流中有时候还能得到更多的反馈，帮助自己改进自己的想法。我帮了你，下次你也会帮我？
- 期待回报？有回报当然是最好的，现在都在讲知识付费，作为了一个程序员我如果能通过回答别人财富自由多好啊！哈哈，当然不是所有人都这么俗，但是如果回答的问题被认可后能有一个6毛6的红包还是很能鼓舞人心的。（你要相信，能帮你回答的程序员，大部分的时薪都不止100，没人欠几块钱的，这主要是劳动有了回报的满足感）
- 清晰的描述问题。有条理地表明需求、描述问题、列出你认为的难点、想达到的目标，让别人一眼就能看懂你的整体需求和核心想解决的问题。
- 写出来自己的想法。既然提问题，自己难道一点就没思考吗？有想法，但是感觉不太确定的话，就列出来，让人帮忙看一下，完善你的想法也是好的。
- 拆解问题。不要上来就问很大范围的问题。前面的例子，假设你问了这个问题：“求问，我想建设我们的数据仓库，大家有什么意见吗？” 别人该怎么回答，你短短的十几个字就想让别人写一本书回答你吗？既然你这些少的描述内容，那我也少一些好了，所以可以这样回答：“那就参考一下阿里它们对外的方案就好了。” 是不是就没得聊了？
- 摆明请教的态度（除非你是抛出问题大家一起讨论）。大部分时候别人没有任何义务回答你的问题的，因此在提问题的时候用词要适当一些，不要有那种你不回答我的问题就不对的态度。
提问的过程中，和回答者的交流是必不可少的，不要一直问，在别人回答过之后，适当地总结一下对方的想法，然后表述出来询问一下对方这样理解是否正确。然后继续提出你的疑问。
不要总是一个接一个问题去问，很有可能你根本就没理解对方的方案，这样越聊越聊不下去的。因此适时地加入自己的理解等对方反馈。
- 方案的反馈，对方既然回答你问题，不管是否有用，过段时间后给对方反馈，告诉对方你用了方案的哪部分，自己做了哪些改进，一起进步才是王道，既然别人帮你了，你理应回馈一下对方。
- 自己的总结就不提了，定期整理一下大家的回答，多方案对比学习是基本功。
