Introduction
There are a few key things to remember when asking question on Server Fault:
- First and foremost is that we really DO want to help you solve your problem.
- Second is that nobody on this site has access to your environment - we only know what you tell us.
- Lastly there is a Stack Exchange axiom:
Good questions get good answers. Crap questions get crap answers.
So what makes a good question?
Good questions are clear, concise, and complete.
There is no true "one size fits all" question formula because all questions are different, however when our users look at questions we are ourselves asking some key questions - things we need to know in order to help you.
A good question generally will tell us the things we are looking for right away so we can get right to giving you an answer.
The things we are looking for are:
- What are you trying to do?
- What have you tried in order to make it happen?
- What results did you expect?
- What actually happened?
(those of you familiar with the New York State science education curriculum will recognize these four questions).
Let's take each of these elements one at a time:
What are you trying to do?
What is your end goal -- This is the most fundamental thing we need to know in order to help you.
If we can't figure out what you're trying to accomplish our users will gather around your question like a bunch of confused apes and try to figure it out. We may prod you with questions, but if we are ultimately left stumped your question will be bludgeoned with an antelope's thigh bone (or close votes - whichever we find first).
Note that your end goal and your immediate problem are not the same thing. Your immediate problem might be How do I log tls-encrypted smtp traffic?, but your end goal might be "How do I get my mail server to record enough of an encrypted SMTP session to debug problems?".
(In this example both questions got answered, but I pity the admin who implements my complex man-in-the-middle SSL capture solution for something that could be resolved by simply asking the SMTP server to log more verbosely!)
Try to avoid The XY Problem when asking your questions -- ask about your problem, not what you think the solution might be.
What have you tried in order to make it happen?
This may seem silly, but Server Fault is a site for information technology professionals -- as such we have certain professional expectations when people ask a question here, and one of those expectations is that you will have done some research and/or tried a solution before asking the internet for help.
This doesn't mean we expect you to have found the answer (though if you did find an answer and you want to ask and answer your own question that's encouraged!), but we expect some effort on your part.
For example:
My system won't boot. It says "UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY". What should I do?
...is a terrible question. People are going to look at you like you are illiterate, because the system told you what to do, and they will tell you to run fsck like your system said.
The missing nugget of information?
My system won't boot. It says "UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY", but when I drop to single-user mode and try to run fsck on the affected filesystem it tells me that the superblock is bad.
What should I do?
Now we know your problem (you tried what your system told you to do, and it didn't work) and we can give you a good answer (how to use alternate superblock addresses with fsck).
What results did you expect?
If you've tried something (or your research has lead you to something you think is a possible solution) it helps if you tell us what you expect to happen when the solution is applied.
Sometimes this isn't necessary -- In the fsck example above the expected outcome is pretty obvious (the user expects fsck to run and fix the filesystem). Other times it's critical.
Note that this doesn't just apply to cases where you've tried a solution.
If you have configured a system and it is not working as expected it's important to tell us what you expected to have happen. You may have configured something incorrectly for your environment, but it may be perfectly valid for some other use case.
If we don't know what you're expecting we have no way of knowing if we're pointing you in the right direction.
What actually happened?
Going back to our fsck example for the third (and last, I promise) time -- If you have tried a solution What actually happened? is important.
If our hypothetical questioner had simply said "It told me to run fsck and I did, but it's still broken!" there's nothing we can glean from that. We are left with a situation akin to the mystery of the dead cat: A bunch of possible causes, and insufficient information to know which to pursue.
Knowing the message that fsck gave to our intrepid user when it refused to run we now known enough to aim them down the path that will take them to a solution.
There is a final thing we need in any good question which I haven't yet mentioned:
Enough relevant information about your environment to offer solutions.
This is a bit more nebulous than the other items -- the definition of "enough" is hard to pin down, but like Justice Potter Stewart, We'll know it when we see it.
This all comes back to the second thing I said in this answer: Nobody on this site has access to your system.
When you ask us a question we are getting a small peephole into your environment.
Every answer we offer you will be based on what we can see through that peephole, so it is important that you tell us enough about your environment that we can give you helpful answers.
Implementation constraints are especially important here (like "I have to use Foobarco's ShinyWidget because the company has a site license for it and won't approve a budget for something better") -- If we don't know your constraints you may get lots of great solutions that you simply can't use. If we do know your constraints you may still get a bunch of alternatives, but your chance of getting something that you can drop in to your environment is substantially better.
This does not mean that it's OK to just dump an entire log file, stack trace, SMTP session, or equivalent on the site and expect us to wade through it for you and figure out what is or isn't important.
The folks answering questions here are all volunteers -- this isn't a primary (or even paying) job for us. We are here because we want to help our colleagues out, but remember that much like you our primary paying job often requires us to slog through a few hundred (or thousand) lines of log files to figure out what blew up. That's not fun, and generally speaking none of us want to be doing it for free.
If you don't know what's relevant that's OK
Server Fault is not just a site for the old graybeards of the sysadmin profession who can spot a problem line in a log file from 20 miles away. If you're unsure you can:
- Post what you think is unusual, and let us know that there's more available.
- If you have the reputation points, pop into chat after you post your question and ask us if there's anything else you should add.
- Edit your question to include additional information when asked.
(Please edit your question logically: There is no need to say "Edited to add xxxx" -- This isn't LiveJournal. Your edits should make the question flow logically according to the 4 big items highlighted earlier).
Some final general tips/comments:
- Server Fault has a strong culture of "Do it right or don't do it at all".
This is part and parcel with our being a site for professionals:
- We don't recommend hacks, duct-tape solutions, or unsupported configurations.
- We don't encourage people to do things that will lead to problems later.
- If we tell you something is a bad idea, think about why we're saying that.
- If you know you are heading down the path of endless agony into the pit of eternal suffering, and you know you have to travel that road for some reason, tell us.
Our culture of "Do it Right" is not without sympathy for those bound by circumstance. We will help you aim the foot-gun as long as we're sure you know it's loaded.
- People here may disagree with you.
Many people have "left Server Fault forever" because they were told that something they asked how to do was a bad idea, or because an answer they were proposing was wrong/dangerous, or some variation on these situations.
Server Fault is a place to learn - if something you are talking about seems like a bad idea we will point out the problems we see. This is an opportunity for you to improve or clarify your question/answer, or to spot a problem you missed and backtrack before you wind up in the aforementioned Pit of Eternal Suffering.
No is sometimes the answer.
Many people have also "left Server Fault forever" because they didn't like that the answer to their question was "No".
Bluntly: Sometimes "No" is the answer. -- This may be unfortunate if you have encountered a situation where No is the best answer we can offer, but in the words of Montgomery Scott Ye cannae change the laws o' physics!.
- Sometimes we answer incomprehensibly.
If you can't figure out what we mean in an answer, ask for clarification with a (polite) comment.
- Sometimes we get the answer wrong!
Sometimes despite your best efforts to write a superlative question and our best efforts to provide a stellar answer.... we screw it up. We're human - it happens.
When it happens:
- Leave a polite comment and tell us why the answer doesn't work.
- If the answer given is egregiously wrong or outright dangerous, downvote it.
(Really, go ahead. we don't mind).
- In case my last two points didn't make it clear: BE. POLITE.
Starting arguments in comments, name calling, etc. are not tolerated anywhere on the Stack Exchange network.
This applies equally to askers, answerers, and commentators. If someone is being rude, offensive or abusive in comments please flag them, and a moderator will deal with the situation as necessary.
