Introduction

This document will provide a set of guidelines for the usage of Jira in the Igniterealtime community.  This is meant to guide all members of our community in the usage of Jira, including Project leads, committers and users alike.

Entering new tasks

• When entering new tasks, leave them assigned to the default of Automatic.  This will then be assigned to the project lead.
  • The exception to this is when the reporter is a contributor who will start work on the task in the very near future and thus they can assign it to themselves.
  • This exception does not apply to parent tasks.  These are organizational, not actionable, so leave them assigned to the project leads.
• Write a title that summarizes the problem or symptoms.
  • It should be clear enough to understand the basic problem/issue.
  • Do not propose fixes in the title, that can be done in the description or comments.
• Always write a description.  I know you think the subject line is beautiful in its simple clarity, but the opinions of others is likely to differ.  This can include things like:
  • Actual details of the problem.
  • Stacktraces, if you have one, include it.  They are invaluable sources of information.
  • Details of where the problem is or where you think it might be.
  • Potential fixes.  Please be careful in suggesting the potential fixes, as they can easily cause just as many (or more) problems then  solutions if they are wrong.  Wild goose chases are not fun.
• Include a link to the forums in the assigned text box if appropriate.
• Parent/Sub tasks
  • Use a parent task to define a large tasks that can be broken up into several parts. It is meant to define and organize a large task, but is not in itself a work item.
  • Sub tasks are grouped under the parent. These define the individual tasks to accomplish the parent.
• Link related issues using the appropriate link type. 
  • This will help debugging efforts when the assignee knows that the problem may have associated issues or repercussions.
  • It may also help group tasks as parts of a larger overall task (Parent/Sub-task).

Task Workflow

For the project leads

Review all new tasks as soon as possible (within a couple of days of entry) and update them.

• Check validity and close if appropriate.
  • Duplicates
  • New features that don't align with the projects future.
  • Bugs that are either irrelevant or won't be fixed due to existing or future planned changes, really custom behaviour or simply violate the spec.
• Check/Set Priority
• Check/Set Components
• Check/Set Versions
• Set assignee to unassigned.
• Check that the description is adequate.
• Periodically review tasks.
  • Tasks that are Assigned or In Progress that have not had any activity (change in status or commits) should be put back to Unassigned.
  • Check to see if older tasks are still valid.

For committers

Please note that all of the following instructions only apply to actionable tasks, that is, tasks that do not have a parent.  Parent tasks are not to be assigned, marked as in progress or have code committed against them.  Parent tasks are purely informational and organizational.  They will be resolved by the project lead when all of the sub tasks are completed.

Comments

• Comments are not for chatting or discussions.  We have forums which are much better suited for that.
• Comments should added value to the issue (the following is not a definitive list, just some examples).
  • fix suggestions
  • improvements on an applied fix or included patch
  • additional information about the issue (additional requirements, more debugging info ...)
• No "me too's"  (See previous point)
• Comments that are deemed inappropriate may be deleted, this will be handled on a case by case basis.