Please help us to improve our source code quality. Bug reports in the forums are a good start, but we can make a lot more use of entries in the Bugzilla Bug Tracking System, because we have a solid and tested workflow for Bugzilla which assures that bugs are confirmed, assigned, fixed and verified by our QA. We do not have anything like that for the forum, as you might guess.
Open-Xchange depends on issues reported by the community. Open-Xchange as a company is dedicated to find and fix all bugs using advanced test automation, user testing, error prevention concepts and much more - but we certainly don't catch every single bug. You, the community users have different points of views, other use-cases for a component and various cultural and linguistic background. This is a invaluable advantage for the whole project when it comes to issue tracking.
If all those switches and forms at Bugzilla irritate you, just ignore them. As long as a report gets into Bugzilla instead of the forums, the most important step is done. Else the bug will probably be overlooked.
It helps a lot if you can bring as much information as possible about the problem you encounter. If you provide all the information, it is much easier for us to act! Otherwise bugs tend to become some kind quiz and most of the time is spent on getting all the information we need instead of getting to work and fix the issue.
We track, prioritize, fix and verify the reported bugs in a dedicated way. So if you find multiple issues, please open different bugs, each with a precise description.
Bugs are also valid if they cannot be reproduced, but usually it is much easier to find the cause, write tests and resolve the issue if the bug report contains steps to reproduce. Please make sure that the reported steps can be reproduced by another person. Double-check that the issue is really part of the Open-Xchange Server, not a bug at a mail system, build environment, missing configuration or missing credentials. If you don't know how to reproduce this exactly, please note it in the bug. Simply posting a stacktrace without steps to reproduce is better than reporting nothing but this bug report will take way longer to reproduce than a report that holds detail information how the issue can be reproduced.
Bugs can be classified for different severities. They contain information how critical this bug is. All bugs are bad, but to setting a priority and severity helps to classify the bug and set a fixing order. Before setting a exorbitant high severity because the bug seems to be very evil to you, please think twice how this influences the whole product. For example: A text inputbox is misaligned and look not nice. This may be a major bug to you because it annoys you, but for the product at all it is trivial or minor because no functionality gets lost. Please note that bug severities are reviewed before fixing them - reporting everything as a blocker will not automatically lead to a faster fixing if the severity is overcasted. A severity is usually derived from the impact and the frequency of a specific issue.
|Blocker||Blocks development, testing, working, security issues.||Login not possible after creating a new user.|
|Critical||Crashes, partly unavailability, severe resource usage problems||Saving a contact leads to a session termination.|
|Major||Major loss of function||Saving a reminder to a appointment does not work|
|Normal||Loss of function, bad usability experience||When sending a E-Mail, the mail will only be sent when clicking the send button twice|
|Minor||Minor loss of function, or other problem where easy workaround is present||Sorting tasks by flag does not work in list view, for split view it works|
|Trivial||Cosmetic problem like misspelled words or misaligned text||A textbox is slightly misaligned, trivial translation bugs|
|Enhancement||Request for enhancement||Implement a YouTube OXtender|
Table taken from Bugzilla documentation and modified
To fine-tune the bug a priority can be set. These are predefined from P1 to P5 where P1 is the highest priority and P5 is the lowest. From the personal point of view every bug is very important to be fixed, but think about how development resources can be used in a effective way. Reporting mostly "P1" bugs will block fixing other bugs. As a matter of fact those priorities will also be reviewed before actually fixing the issue.
Table taken from Bugzilla documentation and gcc.gnu.org
These are fictionary negative examples how a bug can be reported "wrong" which means that it will take much longer to grab all information about the issue, to fix and verify it.
"Webmail does not work."<eof>
"Translation is wrong at <here>, <here>, <here> and <there>, ah and btw. <this> does not work, too."
Lets take this example and see what will happen "behind the scenes":
You may guess it - this leads to a massive amount of overhead. Additionally, reviewing bugs with 30+ Comments may lead to misunderstandings between the reporter, the developer, the product management and QA team. This is not about laziness but about effective work. In the end, all participants of that issue tracking process will win if bugs are reported precise and dedicated.
A small check list of information you should collect for your bug: