Apache Shindig JIRA Conventions¶

This document describes how Apache Shindig 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 Apache Shindig team never uses it. Committers could do it, but like said, it will never be used.

Further Links¶

• JIRA Documentation
• What is an Issue?
• What is a project?