How To Ask Questions
These are a few hints for the first-timers and other newbies to maximize your chances to get a useful answer to your question and have the community pleased to help you rather than annoyed by your complaints. It has been inspirated by ["How to ask questions the smart way"|http://www.google.com/search?hl=en&ie=UTF-8&q=How+to+ask+questions+the+smart+way&btnG=Google+Search] document which you can easily retreive with a google search :)
Identify Yourself
Take the time to set up a user account up front, with a recognizable user name and avatar. Trying to figure out if "aetroi" is the same guy as "sdfoiu" based on the problem description and IP address will lead to the same questions asked again and again. Your user account gives us a way to contact you in private, sending replies by e-mail if we feel the response would be off-topic or too long. A unique avatar helps recognizing your posts at one glance.
Use a meaningful thread title.
This helps us identifying subjects we know about. "Kernel Question" is a bad thread title. "IVT Question" is a marginally better thread title. "Interrupt Handler Triple-Fault on Mouse Movement" is an excellent thread title.
Not being good at English is OK, but being lazy is not.
Bad grammar / spelling makes your post much harder to understand. You will end up with people either ignoring your post or debugging your language instead of debugging your problem. Stay away from 1337 and SMS shortcuts, too.
Check the FAQ.
The FAQ is constantly extended and revised. Chances are good that the answer to your question is already in there.
Check your favourite search engine before asking here.
If your question is "where can I find X", or "are there any programs that do Y", a search engine will almost certainly give you a faster, and possibly even better-informed answer than we here.
It is quite common to stick with a solution once you found one - many people around here could point you to one or two options, but might be missing the very one that would suit you best.
Give all the information needed to reproduce the problem.
OS code is highly interdependent. If you give us only the source code for the interrupt handler that tripple-faults, we will be unable to find the bug in your IVT setup that actually causes the error. We also need to know what compiler / assembler / linker you are using, in which version, and which command line options you are using.
Creating an entry describing your project and environment in the [OSID database|http://oslib.codymays.net/index.php?page=4], and adding a link to that entry to your forum signature, will also allow us to quickly get answers to trivial questions such as "what compiler do you use?" or "what's your devlopment environment?" or "are you using GRUB? Bochs? VMware?" etc.
Try to identify the minimum environment necessary to reproduce the problem.
Just as giving too little information, too much can be just as harmful. It is easy to give the wrong impression ("I have a problem, but cannot be bothered to narrow it down. Fix it for me!").
While your project structure might be completely logical and intuitive for you, others might still be confused, and no-one likes digging through several dozen source files to find out what's happening.
Try to find a minimum code subset sufficient to reproduce the problem. (That's also a good debug technique; you might locate the error yourself in the process.)
Make your post easy to read
The forum has a [code] ... [/code] formatting command that you can use to highlight your code snippets and avoid smilies/fontifying tags to mess up your post.
Split your post in paragraphs of a few sentences. Do not shout (e.g. WRITING IN CAPITALS) or use nifty but useless formatting (like glowing colored fonts, moving text, lines of smilies etc.). Use the 'preview' feature if possible.
Following above guidelines significantly improves your chances to get a quick and helpful reply. (And it makes helping you more fun, so those with the know-how will stick around and still be available to help you tomorrow.)