JIRA Conventions
This document describes how committers should use JIRA, our issue tracking.
When To Create a JIRA Issue?
This section discusses when to create a JIRA issue versus just committing a change in SVN.
- Minor changes, like code reformatting, documentation fixes, etc. that aren't going to impact other users can be committed without much issue.
- Larger changes, like bug fixes, API changes, significant refactoring, new classes, and pretty much any change of more than 100 lines, should have a JIRA ticket associated with it, or at least an email discussion.
How To Use Issue Details?
This section presents some conventions about the issue fields.
Priority
Committers has the responsibility to realign priority by editing the issue.
Reasoning: having a correct release note.
Assignee
Committers could assign an issue to a specific committer if he thinks it is the right committer.
Component/s
Committers has the responsibility to specify the correct the component by editing the issue.
Reasoning: having a correct release note.
Affects Version/s
By default we consider that an issue, which affects a given version, affects also precedent versions, i.e. issue which affects Foo 2.0.9 will affect also 2.0, 2.0.1 ... 2.0.9. If it is a regression, the committers should specify the affected versions.
Reasoning: having a correct release note.