Tips to increase chance of your question being answered.

Do not use abbreviations, use the full word or words in the title and at least once in the main entry.
Search engines do not respond well to abbreviations, try a search for VB so often used for" Virtual Box " the results are no use.
Abbreviations often apply only to one country so are meaningless in others country's.
LQ like many forums is international.
Try a search for DHS, The Security network in the USA, Hospitals in the UK, and even Dead Hackers Society.
If you wish for an answer add the full words and spell correctly.
If English is not your first language or like me dyslexic add a spell checker to your browser or Goggle the word to check.
I hope this helps.
Trev

Include your linux distribution in the question.
If you're following a How-To and get stuck then include a link to the How-To.
Detail what you've already tried.
Give your thread a MEANINGFUL title "HELP!" is NOT a meaningful title. "URGENT" isn't either, it may be urgent for you, but it's not urgent for us!
Don't "hate", be open to the suggestion that sometimes (shockingly!) linux is not necessarily the best O/S for the job.
If you're using RedHat then call RedHat support, that's what you're paying for!
Detail what you've already tried. (Yes, I've said it twice, it's THAT important)
"Help me make proxy give me all instructions." - No, we'll try and help with specific squid problems once you come across them.

And if this is a virtual install make 100% sure that is in the FIRST post !

so that by the 8 post we do not just then find out about that VERY important bit of information

If it's hardware-related question, include the make/model of the hardware, whether it's a printer, router, network device, webcam, computer, external HDD, etc.

For scripting/coding questions, start by explaining clearly what you want to accomplish, rather than just posting the non-working code. Give some background context for the request as well.

Be sure to include representative examples of both the input and the desired output. This can include examples of the file/directory tree and even the output of common commands, since not everyone will have access to the same commands and set-up you do.

Be sure to explain clearly what parts of that input need to be included in the output and what needs to be excluded, and how to tell the difference between them. Often there are many ways to create the exact output example in the posted request, and only some of them may be applicable the user's actual needs.

Clearly specify the environment you're working in, if you aren't using a standard GNU/Linux system. We need to know what tools are available to you and what aren't. If the code you post depends on variables or commands that are defined elsewhere, be sure to post what they contain as well.

When you execute a command and it doesn't work, don't just say it failed, post the actual command(s) you used and whatever output/errors you got. Remember, we can't see your screen.

However, don't post 10 pages of nearly-identical error messages either. We don't need walls of text. Just supply a short example of what you have.


In short, don't assume that readers will recognize what your code is doing just from the bit you post. Do whatever you can to ensure that others understand what it's supposed to be doing, and can directly replicate it themselves in testing.

Originally Posted by frankbell If it's hardware-related question, include the make/model of the hardware, whether it's a printer, router, network device, webcam, computer, external HDD, etc.

If possible, when you're not sure of the specifics, include any relevant output from the lspci command.

For scripting/coding questions, start by explaining clearly what you want to accomplish, rather than just posting the non-working code. Give some background context for the request as well. Be sure to include representative examples of both the input and the desired output. This can include examples of the file/directory tree and even the output of common commands, since not everyone will have access to the same commands and set-up you do.

+100

One thing I would add is: try to provide relevant information and exclude non-relevant information. I've seen a number of posts that are walls of text, much of which is irrelevant to the problem. If I have limited time and a choice between reading through a wall of text or reading a shorter, more concise, more to the point question ...

Certainly providing more information is good, but it's much more important to provide it in a way that can be easily interpreted. Make sure to use [code tags for sure, because posting a wall of code is even worse than a wall of text.

Originally Posted by H_TeXMeX_H One thing I would add is: try to provide relevant information and exclude non-relevant information.

I don't know if this is doable or practical, but maybe a sticky with a short synopsis of to get relevant information with a few common cases? New users aren't likely to know where to look at lspci output for certain things, dmesg, etc, and often the first reply is asking for the output of related commands.

Originally Posted by goumba I don't know if this is doable or practical, but maybe a sticky with a short synopsis of to get relevant information with a few common cases? New users aren't likely to know where to look at lspci output for certain things, dmesg, etc, and often the first reply is asking for the output of related commands.

Output of commands is fine, you can put them, but don't tell a long story with unrelated information. I'm not relying on people knowing technical things that are not relevant, but rather practical things that are not relevant. Stay on topic, stay relevant to the question at hand.