------
 Committers - JIRA Conventions
 ------
 Apache Onami Documentation Team
 ------
 2012-11-16
 ------

~~
~~ Licensed to the Apache Software Foundation (ASF) under one
~~ or more contributor license agreements.  See the NOTICE file
~~ distributed with this work for additional information
~~ regarding copyright ownership.  The ASF licenses this file
~~ to you under the Apache License, Version 2.0 (the
~~ "License"); you may not use this file except in compliance
~~ with the License.  You may obtain a copy of the License at
~~
~~   http://www.apache.org/licenses/LICENSE-2.0
~~
~~ Unless required by applicable law or agreed to in writing,
~~ software distributed under the License is distributed on an
~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
~~ KIND, either express or implied.  See the License for the
~~ specific language governing permissions and limitations
~~ under the License.
~~

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.

** Time Tracking

 We never uses it. Committers could do it, but like said, it will never be used.

* Further Links

 * {{{http://www.atlassian.com/software/jira/docs/latest/}JIRA Documentation}}

 * {{{http://www.atlassian.com/software/jira/docs/latest/issues.html}What is an Issue?}}

 * {{{http://www.atlassian.com/software/jira/docs/latest/projects.html}What is a project?}}

 []