Guidelines for using Jira

Version 3


    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.


      Current StatusAction
      • Assign it to yourself and get busy.
      • If it has been recently assigned, then give the assignee a chance. If you have information that you think is relevant, more details about the task, ideas for fixing it or a point you want to make sure are not forgotten, then by all means leave a comment.
      • If it has been assigned for a while and you would like to take the task, then contact the assignee and see if they are willing to have it reassigned.  If you cannot get any response, contact the project lead.
      In Progress
      • It is the responsibility of all developers to set their tasks to this state when they are actively working on them. 
      • Feel free to add comments to these tasks.
      • It is the responsibility of the developer to mark their task to this state when they are finished. 
      • SVN comments MUST include the Jira task id so the code can be linked to the task.  This allows for easy review of the code.
      • If you believe it is still not fixed, then reopen it.  Add a comment as to why you believe this. 
      • If you think the solution can be improved, then add a comment with your ideas and contact the project lead.
      • Only the project lead sets tasks to this state.
      • Resolved tasks should be set to this state after the release has been completed.  We assume the fix has been confirmed by this point.
      • Should only be rare to have to change the status here.  If there are related issues they will probably require a new task to be created.  It is still possible to reopen at the discretion of the project lead.



      • 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.