How To Ask Questions: Difference between revisions

From OSDev.wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
(Revamped)
(removed PFR tag, formatted, added category 'OS development')
Line 1: Line 1:
{{Convert}}

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 inspired by [http://www.google.com/search?hl=en&ie=UTF-8&q=How+to+ask+questions+the+smart+way&btnG=Google+Search How to ask questions the smart way] document which you can easily retrieve with a Google search :)
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 inspired by [http://www.google.com/search?hl=en&ie=UTF-8&q=How+to+ask+questions+the+smart+way&btnG=Google+Search How to ask questions the smart way] document which you can easily retrieve with a Google search :)



== Identification ==
== Identification ==

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.
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.



== Title ==
== 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.
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.



== Grammar ==
== Grammar ==

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. Basically '''use English'''.
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. Basically '''use English'''.



== Research ==
== Research ==

The wiki is constantly extended and revised. Chances are good that the answer to your question is already in there.
The wiki is constantly extended and revised. Chances are good that the answer to your question is already in there.


Line 26: Line 16:


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.
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.



== Details ==
== Details ==

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.
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.


Line 39: Line 27:


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.)
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.)



== Formatting ==
== Formatting ==

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.
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.
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.)


{{Category:OS development}}
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.)

Revision as of 01:03, 16 September 2007

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 inspired by How to ask questions the smart way document which you can easily retrieve with a Google search :)

Identification

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.

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.

Grammar

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. Basically use English.

Research

The wiki is constantly extended and revised. Chances are good that the answer to your question is already in there.

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.

Details

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, 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 development environment?" or "are you using GRUB? Bochs? VMware?" etc.

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.)

Formatting

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.)

Category:OS development