Here's a short list of items you should consider when asking a question on Server Fault. Please address as much of this material as reasonably possible:
- Have you read our about and are sure that Server Fault is the correct site to ask your question?1
- Have you done some research before asking the question? 2
- Have you explained what you've already tried to solve your problem?
- Have you explained why this question is important for you to resolve?3
- Have you provided some relevant context about the needs of the business environment and/or software applications that you're supporting?
- Have you included a diagram of the problem (especially if it involves more than two devices)?
- Are you sure you've provided enough details such as operating systems, addresses, protocols, link types, link speeds, or interface names?
- Have you included information about what manuals or reference material you consulted when trying to resolve your question?
- Have you specified which hardware you're using, including firmware version numbers?
- If your question includes a configuration, have you checked that it's correctly formatted? 4
- Have you included relevant details about timing, syslog, or application log entries?
- If your configuration results in an error, have you included the exact error, as well as any tracebacks?
- If your question doesn't include a configuration, are you sure the configurations are not required? Hint: most people will want to see configurations even if you think they aren't necessary
- If your configuration produces different results to what you expected, have you stated what you expected, why you expected it, and the actual results?
- Have you checked that your question looks reasonable in terms of formatting?
- Have you checked the spelling and grammar to the best of your ability? 5
- Have you read the whole question to yourself carefully, to make sure it makes sense and contains enough information for someone coming to it without any of the context that you already know? 6
- Are you coming at this process with an open mind? The right answer may be something you don't want to hear. Are you willing to accept that?
Any "no" answers?
If the answer to any of these questions is "no" you should take the time to fix up your question before posting, by going through this list. This may seem like a lot of effort, but it will help you to get a useful answer as quickly as possible; and you might even solve your own problem in the process! 6
You're basically asking other people to help you out of the goodness of their heart - make that as simple as possible for them.
1 Lots of people mistake our scope based on our name. Frequently Super User, Stack Overflow or Unix & Linux are better places to ask a question, especially for home use and developer environments.
2 If you went from "something is wrong" to "asking a question" in less than 10 minutes, you probably haven't done enough research. This should include things like normal web searches (e.g. for an error message you're receiving), checking the documentation, debugging / troubleshooting, and searching on Google itself for similar questions. When you explain the problem, try to avoid making assumptions about the solution.
3 While it might be obvious to you that this is important to resolve, other people might wonder why you're even asking (particularly for hypothetical or protocol-theory questions). Explaining why the question is important increases your chances of getting an answer.
4 Try to avoid configurations which make users scroll horizontally. You may well need to manually line-wrap a few lines. Take the time to make it as clear as possible for those trying to help you.
5 English isn't the first language for many Stack Exchange users; we're not looking for perfection - just some effort. If you know your English isn't good, see if a colleague or friend can help you with your question before you post it.
6 This is a bit like rubber duck debugging
Many thanks to Jon Skeet, whose Short question checklist was inspiration for most of this material.