21

This is a Canonical Question / FAQ Candidate to help our new users ask better questions, and hopefully get better answers. Similar questions:

How can I ask better questions on Server Fault?

How do I get better answers?
How can I get people to fully read my question?


Why yes we do please see the list in the answer below.

2 Answers 2

21

Question Checklist

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

Please Remember.

You're basically asking other people to help you out of the goodness of their heart - make that as simple as possible for them.


End Notes:

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.

1
  • 1
    I would add to this checklist: Are you asking a question? Far too many posts, especially from newcomers, are merely statements of fact. It's much easier to answer a question when the question is explicit about what the OP wants to know. For extra points, are you asking a single question?
    – user
    Commented Aug 18, 2017 at 12:32
7

Have you at any point told us you've done something when you could instead have shown us?

SF is replete with questions where the author asserted eg "I have configured syslog to write to /var/log/foo" when it turned out they'd actually configured it to write to /var/lgo/foo, and since that didn't exist, it wasn't being created and no logs were appearing. Or the author asserted "I have set the NS records for example.com to ns1.example.org and ns2.example.org in the zonefile" but after they'd agreed to post the zonefile it turned out they'd forgotten to canonicalise them, and they were actually being set to ns1.example.org.example.com and ns2.example.org.example.com.

Obviously, huge screenshots can become excessive really quickly, but if you can cut-and-paste (not re-type) a couple of lines from a terminal session that show us what you're doing, and what results, we can often shed light more quickly. Imagine that you're trying to prove your case to an audience of sceptics, and your question will often be better, and answered more quickly.

Corollary 1: command lines are better than GUIs for constructing evidence-based questions: posting samples from GUIs can be hard; from shells, it's easy. Do it from the command line, if you can.

Corollary 2: don't redact unless you really have to. It should now be obvious why; everything you post that isn't exactly what you did increases the chance of the real error being concealed. OK, it may be (slightly) embarrassing that you screwed up your corporate DNS; but would you prefer embarrassment and a quick fix, or deniability but no answer?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .