The Koha project makes use of a Bugzilla based bug tracking system. It is very important for Koha to have bugs listed on bugzilla. That is the list that the developers work from. If a bug is just mentioned in a posting to a mailling list, or just mentioned on IRC (chat) it can very easily slip through the cracks.
A bug can be quickly identified as a problem with Koha. However, it is much more complicated than that. It can be a behavioural problem, or a component that does not work at all. It even applies to documentation that is incorrect. We also utilize Bugzilla for “future enhancements” or “feature requests”.
The first step to submitting a bug is to see if someone else has a similar problem to you.
Effective bug reports are the most likely to be fixed. These guidelines explain how to write such reports.
If you have reproduced the bug in a recent build and no-one else appears to have reported it, then:
Component: Select the appropriate component. If you are unsure what area of Koha to report the error under, view the component list.
Platform: In most cases you can leave this as 'PC', as the OS is much more relevant.
OS: Select your operating system. If you are unable to find your exact operating system, please pick the closest approximation and in the body of the ticket explain what operating system you are using.
Priority: The ticket priority helps us triage issues. Setting an appropriate level of priority helps us immensely.
| Priority | Description |
|---|---|
| P1 | This bug blocks development or testing work and should be fixed ASAP |
| P2 | This bug blocks usability of a large portion of Koha, and really should be fixed before the next planned release |
| P3 | Seriously broken, but not high impact. Should be fixed before next major release. Can include cosmetic bugs of particularly high visibility, and more minor bugs that are frequently reported |
| P4 | Either a fairly straightforward workaround exists or the functionality is not very important and/or not frequently used |
| P5 | Not that important, just fix when time permits |
Severity: This goes hand-in-hand with the priority line – how bad do you think this bug is? This field describes the impact of a bug on a user. If a bug occurs with great frequency, it can be moved up in severity even if it doesn't meet the other criteria in that category.
| Severity | Description |
|---|---|
| Blocker | Needs to be fixed and an update released immediately. |
| Critical | Koha or component crashes and/or there is a potential loss of data |
| Major | A major part of the component is nonfunctional. |
| Normal | A minor part of the component is nonfunctional. |
| Minor | The component mostly works, but causes some irritation to users. |
| Trivial | The component works with 100% functionality, but has visible typos or other cosmetic problems |
| Enhancement | Generally a feature request for functionality that does not currently exist. These can be useful as guides for future product improvements. |
Summary: How would you describe the bug, in approximately 60 or fewer characters? A good summary should quickly and uniquely identify a bug report. It should explain the problem, not your suggested solution.
The details of your problem report, including:
Overview: More detailed restatement of summary.
Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps.
Example:
1. View any web page. (I used the default sample page, resource:/res/samples/test0.html)
2. Drag-select the page. (Specifically, while holding down the mouse button, drag the mouse pointer downwards from any point in the browser's content region to the bottom of the browser's content region.)
Actual Results: What the application did after performing the above steps. Example:
The application crashed.
Expected Results: What the application should have done, were the bug not present. Example:
The window should scroll downwards. Scrolled content should be selected.
(Or, at least, the application should not crash.)
Version: Select the version of Koha you are experiencing this issue under. (If you are unsure of the version of Koha you are using you can find the version in either the Intranet interface by selecting the “About” page, or else view the contents of your koha.conf file.) Additional Builds and Platforms: Whether or not the bug takes place on other platforms (or browsers, if applicable).
Doesn't Occur in 3.0.5
Additional Information: Any other useful information.
Double-check your report for errors and omissions, then press “Commit”. Your bug report will now be in the Bugzilla database.
Bugzilla includes a general purpose bug writing guidelines page that you should review in its entirety before submitting a bug to Koha.
All Enhancements or sponsored items will be entered into http://bugs.koha.org which will allow users and developers access to what is currently in development as well as items that are being considered by libraries. Comments can be made on enhancements which will provide details for the development of the enhancement and to work out details with the libraries interested in the enhancement. This page of Enhancement instructions outlines what needs to be put into the enhancement when entering into bugzilla.
If you think that you may have discovered a bug but are not quite sure or comfortable posting it on Bugzilla post a message to one of the mailing lists and others can give advice:
Bugzilla is a database of bugs and feature requests developed by the [http://www.mozilla.org Mozilla] project. It helps developers keep track of what's broken and who's fixing it. Users can help by making bug reports clear and specific. The better your bug report, the easier it is to identify the cause, and fix the bug.