How to Write a Bug Report
The better the bug report the more likely the bug will get fixed. What makes a good report?
What Revisions of the Server and DataPack 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.
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.
Provide clear and minimal steps to reproduce the bug
Certainly there are unexplained problems with software but often one can cause the bug to happen upon command. 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?
Describe the problem well.
This includes the bug report title. "Server crashes" isn't a particularly descriptive title.
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
- stack trace (from the server screen)
- Snippets from the server error log
- Snippets from the server access log
It is important to set the Severity, Priority and Component correctly. Setting them wrongly wastes a programmers time when he is looking for work to do. Work is usually done on a priority basis.
Severity is an objective measure of the effect on the system of the bug. Severity is "what's the worst that could happen?"
- - Blocker. Blocks development and/or testing work
- - Critical. Typically: system crash, security violation, data loss. (ex. Server Terminated Abnormally)
- - Major. Because of this bug, a major function cannot be made to work. (Server starts, feature engine not working)
- - Normal. The bug interferes with functionality but an alternative way to accomplish the same function is possible. (Server starts, feature needed but not working)
- - Minor. The bug does not interfere with functionality. (Server starts, feature not working)
- - Trivial. Bug appears but normally you would not notice that it happened. (Server starts, small feature or item missing)
- - Enhancement. Reserved for code that could improve game quality.
Priority is a measure of how important we judge the bug to be.
- - 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.
- - 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.
- - Normal. This bug impairs one or more use cases of the package.
- - Low. This bug should be fixed before next milestone.
- - Lowest. "Back Burner", To be corrected one day.
Component is the part of the datapack that contains the bug.
- - Blank. The default selection. Leave this blank if you do not know what component your bug belongs to.
- - HTML,other. For bugs in HTML or bugs that do not belong in the other components.
- - QUESTS. For bugs related to quests.
- - SQL,CSV. For bugs in SQL file data or CSV file data.
- - XML. For bugs in the XML files.
And remember -- " Every time you submit a bad bug report, god kills a kitten."
Now that you're ready to write a Bug Report, go here: http://l2jdp.com/trac/newticket
