Maven JIRA Convention

This document describes how Maven developers should use JIRA, our issue management system.

When To Create a JIRA Issue?

This section discusses when to create a JIRA issue versus just committing a change in Git (eventually through a PR).

  • 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.
    Creating a JIRA issue and referring it in commit comment will ease tracking what changes happen in a release, using JIRA automatic release notes creation.

How To Use Issue Details?

This section presents some conventions about the issue fields.


Committers has the responsibility to realign priority by editing the issue.

Reasoning: having a correct release note.


Committers could assign an issue to a specific committer if he thinks it is the right committer.


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


Time Tracking

The Maven team never uses it. Committers could do it, but like said, it will never be used.

Further Links