How to report bugs efficiently ?

If you decided to report a bug, an improvement or a feature request to us, we are very thankful to you, but it is important to be very specific and not to miss information. This page is here to explain to anybody facing an Issue how to report it effectively in [Jira](http://ci-obm.linagora.com/jira).

##Do a similar bug already exists ?

First, before creating a new one, you should search if an existing issue is not already filled in the bug tracker with this [search page](http://ci-obm.linagora.com/jira/secure/IssueNavigator.jspa?mode=show&cre...).

##What must contain a bug report ?

Here's a list of the information that must be filled.

###Summary

An efficient summary of an issue is a summary understandable, with important information and not too detailed. It is just a one line summary of the bug.

Examples to avoid:
- **It does not work** : we released it, we know that it work in most cases, you have to be more specific
- **I can't reply to an invitation** : again, this is one of the big feature of OBM, so it is possible to reply to an invitation, maybe one specific invitation is wrong and you are the one who face it
- **When I accept an event with the email received, then finally decline it in ligthning, and the organizer change the date, I receive an email with a wrong summary of the new event** : This is the description of the bug not the summary

A good summary can be:
- **Synchronization of contacts fails on iPhone with a contact containing a 'ç' in the firstname**
- **An incorrect update email is received after the modification of a declined event**

### Issue type

With Jira, you should only use one of these 3 types:
- **Improvement**: used for a functionnality that works but you think that it needs an enhancement
- **New Feature**: for a missing feature
- **Bug**: your report is not an improvement and not a new feature, so if you face a wrong behavior, this is probably a bug

### Priority

An issue has a priority level which indicates its importance. The currently defined priorities are listed below:
- **Trivial**: Cosmetic problem like misspelt words or misaligned text
- **Minor**: Minor loss of function, or other problem where easy workaround is present
- **Normal**: Between Minor and Major (is not a regression but is not trivial, this is a normal bug)
- **Major**: Major loss of function, regression
- **Critical**: Crashes, loss of data, severe memory leak
- **Blocker**: Blocks development and/or testing work, production could not run

### Component/s

This is not a required information, because most of the time this information will be known when the Issue fix will be known. You should sometimes guess what component is affected, but it is better not to guess and concentrate on other information.

### Affects Version/s

This is a very important information. Type here the software version you are using when you came across the bug.

### Fix Version/s

This is the version number in which we are planning to add the fix. Just type "Issues", this field will be used by the Core Team for future planification.

### Environment

You face the issue in your own environment, but because we need to reproduce you need to be very specific about your environment. For example:
- if you use a smartphone, don't just give the model, but also the ROM version for an Android, or the iOS version if it is an Apple device
- OBM can be installed on a Debian, or on a CentOs, with MySQL or with PostgreSQL. Please write down the specifics of your installation
- if you use Thunderbird, give us the version number of Thunderbird, the obm-connector you use and lightning version
...etc

The more precise you will be, the quicker the Core Team will reproduce the bug and the quicker it can be fixed.

### Description
This is probably the most important field to fill. Please use the following template (with a copy/paste) :

h4. Pre-conditions

h4. Reproduction steps
# As _usera_ with {TB/ui/iPhone}, do this...
# As _userb_ with {TB/ui/iPhone}, do this...

h4. Current behavior
# I see that ...{color:red}NOK{color}
# And that...{color:red}NOK{color}

h4. Expected behavior
# I should see that...{color:green}OK{color}
# I should also see that...{color:green}OK{color}

h4. Additional information

- Pre-conditions are information about the state of the product before executing the test. For example, read and/or write rights placed between users used for the test, type of calendar view to display before the test, minimum number of emails waiting to be synchronized...etc
- Reproduction steps are a sequence of several steps to execute before causing the bug. All these steps must not fail
- Current behavior explains what you notice not being a desired behavior. If there is several abnormal behaviors, please note them on separated lines
- Expected behavior must replace current behavior by the behavior you were expecting to have
- In "Additional information" you can add any information that can be useful for reproduction and fixing. Logs are very important, if you have access to your server, please add logs related to the issue (as an attached file if it is big, or include it in this field enclosed into markdown {code} separator.

Here's an example of a good simple bug report (formatted for Jira wiki markup):

h4. Pre-conditions
_usera_ has rights for adding a resource _resource_
_userb_ has rights to display the calendar of the resource _resource_

h4. Reproduction steps
# As _usera_ with ui, create an all-day event with the resource _resource_ and an attendee _userb_
# As _userb_ with TB, show the calendar of the resource _resource_

h4. Current behaviour
# The all-day event does not appear in the box all-day but beginning at 00h00 and ending at 00h00 the next day {color:red}NOK{color}

h4. Expected behaviour
# The all-day event appears daily in the calendar {color:green}OK{color}

h4. Additional information
This bug is easily reproductible with at least Firefox and Chrome.

### Attachments
You can add any interesting file as an attachment. For example, don't hesitate to add screenshots, or videos. Showing the issue in action is always better than any speech.
You can also add logs, being aware that it does not contain private information.
Racing Archives