Maven JIRA Convention
This document describes how Maven developers 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, the Maven team considers that an issue, which affects a given version, affects also precedent versions, i.e. issue which affects Maven 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.
Fix Version/s
TO BE DISCUSSED
Time Tracking
The Maven team never uses it. Committers could do it, but like said, it will never be used.