How to write a Bug Report

The better the bug report the more likely the bug will get fixed. What makes a good report?

See if the bug already exists
Before entering a new bug do a quick search of existing ones to see if you have found a known issue/problem.

What Revision of the Server are you using?
This is extremely important. The Latest is not an answer. The Devs need a number so that if they need to they can look at that revision and determine if something else is causing the problem (or if the bug hasn't already been fixed).

Describe the problem well.
This includes the bug title. "Server crashes" isn't a particularly descriptive title.

Provide clear and minimal steps to reproduce the bug
Certainly there are unexplained problems with software but more often than not one can cause the bug to happen upon command (reproduce it). If this is the case, in as few steps as possible, clearly describe what you are doing. If this includes some specific data, include that as well (possibly as an attachment).

If you do have an unexplained crash, include as much information as possible as to what was going on: Was the server under load? How long had it been running? Did you run out of memory? Was the machine doing anything else at the time?

Include only one issue per bug report
This is for your benefit and for the developers. It will help ensure that things don't slip through the cracks.

Other things you might want to include (mostly helps alot)

 * stack trace (from the server screen)
 * Snippets from the server error log
 * Snippets from the server access log
 * Custom code applied (if any) (Many problems occur because of wrongly applied / incompatible code)

It is important to set the Severity and Priority correctly. Setting them wrongly wastes a programmers time when he is looking for work to do, since work is usually done on a priority basis.

Severity is an objective measure of the effect of the bug on the system.
Severity is "what's the worst that could happen?"
 * 1)  Blocker. Blocks development and/or testing work.
 * 2)  Critical. Typically: system crash, security violation, data loss (ex. Server Terminated Abnormally).
 * 3)  Major. Because of this bug, a major function cannot be made to work (server starts, feature engine not working).
 * 4)  Normal. The bug interferes with functionality but an alternative way to accomplish the same function is possible (server starts, feature needed but not working).
 * 5)  Minor. The bug does not interfere with functionality (server starts, feature not working).
 * 6)  Trivial. Bug appears, but normally You would not notice that it happened (server starts, small feature or item missing).
 * 7)  Enhancement. Reserved for code that could improve game quality.

Priority is a measure of how important we judge the bug to be.

 * 1)  Highest. This bug has severe consequences for current users and its resolution is judged more important than new features or other bugs in the package. If a developer has time to work on the package at all, the developer is asked to attempt to resolve any urgent bugs before doing new work. Priority 1 bugs may warrent new bug-fix releases. Priority 1 should be used sparingly.
 * 2)  High. Should be fixed before next release. This bug seriously impairs common use cases or functions. This bug must be resolved (closed or deliberately postponed) before the next release.
 * 3)  Normal. This bug impairs one or more use cases of the package.
 * 4)  Low. This bug should be fixed before next milestone.
 * 5)  Lowest. "Back Burner", To be corrected one day.

And remember -- " Every time you submit a bad bug report, god kills a kitten."