How to answer questions better

Good technical communities don't just need people who can ask questions, they also need people who can answer them. By answering questions, you are both solving a specific problem and modeling how the community thinks, expresses itself, and maintains quality.

Start by Assuming They May Be Stressed

** Be kind. ** Stress from problems often makes people seem rude or stupid, but often they are just anxious, confused or inexperienced.

** Respond privately to first-time offenders. ** There is no need for public shaming of those who are honest about their mistakes. A true newbie may not even know how to search, where to find the FAQ, or how to post an error log. There's no need to publicly magnify a problem that can be solved with a private reminder.

Be Honest When You Are Not Sure

** If you're not sure, always say so! ** A wrong response that sounds authoritative is worse than no response at all. Don't give people random directions just because it's fun to play the expert. Humility and honesty set a good example for both the questioner and the onlooker.

** Don't get in his way if you can't help it. ** Don't joke about the actual procedure. False commands, forged parameters, or dangerous suggestions can ruin the questioner's environment; someone will always execute them as if they were real instructions.

Use rhetorical questions to help the other person fill in the information

** Test the rhetorical questions to elicit more details. ** If you do this well, the questioner can learn and so can you. Try to steer a rough question into a good one: ask about the version, the environment, the steps to reproduce it, the full error message, the expected result, and the paths that have been tried.

While an RTFM complaint about laziness is sometimes justified, it's often more helpful to give a link to the documentation, an FAQ entry, or even just suggest a couple of more effective search terms.

If You Answer, Answer Seriously

** If you decide to answer, give good answers. ** Don't just give a clumsy expedient (workaround) when someone is using the wrong tool or the wrong approach. A better answer is to recommend the right tool, redefine the problem, and explain why the original direction was inappropriate.

** Answer the question positively. ** If the questioner has already delved deeper and states that he has tried X, Y, Z, A, B, and C with no results, answering Try A or B or posting the same set of suggestions back as is with a link is of little or no value. You should move forward based on the information he has already provided.

Let the community benefit from one answer

** Help your community learn from questions. ** When you respond to a good question, ask yourself, `How can I change the relevant documentation or FAQ to avoid answering the same question over and over again in the future? ' If the answer is clear, submit a patch or suggestion to the documentation maintainer.

If you are responding after some research, Show your skills rather than just serving up the results. Explain how you positioned the problem, how you ruled out the possibilities, and why you chose the option. After all, `It's better to teach a man to fish than to give him a fish'.