Jira

Sakai uses Atlassian's Jira software for issue management. It is used to track a variety of issues, including bug reports, suggestions for new functionality, tasked work, and community contributions. Outlined below are the general practices, procedures, and definitions adopted by the Sakai community for using Jira. If you have questions regarding Jira, please send them to jira-admins@collab.sakaiproject.org.

You can search and view content in Jira without an account, however, you do need one to comment on or post information. Jira accounts are available through self-registration. (Note that Jira and Confluence share accounts, however, Jira/Confluence accounts are separate from Collab accounts.)

Definitions

Issue Type

Issue Type

Definition for Sakai

Bug

An error in design or implementation which directly impedes a user from achieving their expected result.

Task

A new capability being added to Sakai.

Feature Request/Requirement

A desired capability, for inclusion in a future release of Sakai; ideas that come with resources interested in implementing them are more likely to be developed than those offered with the hope that someone else will step forward to do the work.

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="31eae43c-b8d0-4c75-a31e-ce73dabcdf18"><ac:plain-text-body><![CDATA[

Contributed Patch

A community-contributed patch to a particular version of Sakai. The origin of such issues may lie in Bugs or Feature Requests which Sakai has not yet evaluated for implementation. Under such circumstances a linked issue is generally created by cloning the original issue in order to track Sakai's work on the issue. [Use at your own risk!]

]]></ac:plain-text-body></ac:structured-macro>

Branch

An experimental branch of code, which may or may not be merged back into the main code after the experiment completes; identified in SVN by a branch named with the Jira Key.

Status

Status

Definition for Sakai

Open

Issue is under consideration.

In Progress

Issue is actively being worked on.

Reopened

Issue was thought to be resolved, however, it did not pass QA and needs further work.

Resolved

Issue has been addressed and is ready for testing.

Closed

Work on issue is complete and has passed testing.

Resolution

Resolution

Definition for Sakai

Unresolved

Issue is under consideration and/or actively being worked on.

Fixed

Issue has been addressed through changes to the design or code. When viewing an issue, the "Subversion Commits" tab provides specific details regarding code changes.

Won't Fix

Issue will not be addressed because it does not match project goals.

Non-Issue

Issue turned out not to be a problem with Sakai.

Duplicate

Issue is a duplicate of a previously submitted issue. A link to the other issue is added so that progress on the issue can be easily accessed.

Incorporated

Issue has been incorporated into another issue. A link to the other issue is added so that progress on the issue can be easily accessed.

Incomplete

Not enough information has been provided to identify the issue.

Cannot Reproduce

Issue cannot be reproduced.

Version

Each Jira issue has an Affects Version, Target Version, and a Fix Version. Generally speaking Sakai uses these values to indicate:

Further notes on Version Numbers

Maintenance Branch Version Numbers

A ".x" version is used to track issues relating to maintenance branches. For instance, 2.4.x is the version number representing the 2.4 release's maintenance branch.

If someone is basing their deployment on a maintenance branch, then it may be used as an Affects Version, however, be forewarned of the potential for confusion since the maintenance branch is a moving target. In such a situation it is important to indicate the revision number in the issue, either as part of the Summary, an additional Comment, or in the Environment field, so that folks know to which revision of the maintenance branch you are referring.

Priority

The Priority field in Jira is used by Sakai to reflect a combination of issue characteristics, including:

In practice, the Jira Priority field is utilized by Sakai at two times: during prioritization of requirements for implementation and when making decisions on what will actually appear in a release. Initial priorities, when an issue is first reported, may be changed to reflect those needs.

As a release date approaches, priorities will also be adjusted – and lowered, if necessary – to reflect the decreasing availability of time and resources.

Priority

Definition for Sakai

Blocker

Release will not be completed until issue is resolved.

Critical

Issue will most likely be resolved for release.

Major

Issue should be resolved for release.

Minor

Issue may be resolved for release.

Trivial

Issues that might be resolved before a release.

Summary

Environment

Description

Component

Security Level

General Workflow

What happens when an issue is created in Jira? The workflow for a given issue is dependent on what type of issue it is. The sections below describe the overall path an issue of given type will follow. Guidelines are also presented for the various groups interacting with issues, such as Designers, Developers and QA, and discuss when and how to adjust an issue's status, resolution, versions, etc.

General Workflow by Issue Types

Bugs

  1. Issue is Opened.
  2. Issue is vetted for accuracy and completeness of information and linked to related issues.
  3. Issue is assigned to the appropriate project lead.
    **Further vetting, as above, may be necessary for particularly complex issues.
  4. Initial estimates of the scope of the bug and the resources required to address it are made and the reported Priority and Target Version are updated accordingly.
  5. An issue may be re-assigned to others or Watchers added to facilitate discussion of its resolution. The Priority, Target Version, Components, etc. should also be updated as necessary as discussion around the issue evolves.
  6. Assignee Resolves issue with relevant Resolution when work is completed, and updates Fix Version to "Nightly/SVN-Trunk" (or other version in special circumstances.)
  7. QA team verifies resolution of issue.

Tasks

Feature Requests

  1. Issue is vetted for accuracy and completeness of information.
  2. If the issue represents a broad change for Sakai, then it is treated as a Requirement, and moved to the Sakai Requirements project for further handling. (See requirements process.) Otherwise, smaller-scope suggestions, such as re-naming buttons, changing a tool's layout, choosing different defaults, etc, are left as Feature Requests and assigned to the appropriate project lead.
  3. Project team evaluates and discusses the issue as needed to determine whether to work on it.
  1. When a project team is ready to address the issue, it should be Moved to a Task and an initial estimate of the Fix Version set.

Requirements

The requirements process is still under development. During the the first requirements gathering phase over 300 issues were submitted. A rough attempt to clump and cluster related requirements resulted in over 200 requirements put forth to the greater Sakai community and the Sakai Institutional Representatives for polling on relative importance; see results.

Requirement Issues which are adopted by existing Project Management Committees or Project Teams will be handled as Feature Requests are above; converted to one or more Tasks in the Sakai Jira project to track its implementation.

Contributed Patches

Branches

Under construction...

General Workflow by Task

Community

The Sakai community is encouraged to report issues, however, it should not consider posting issues in Jira as a primary destination for users of their own instance of Sakai to report issues. Rather, each organization running Sakai is expected to provide its own front-line support, which can post issues to Sakai's Jira on behalf of users, when the issue is deemed to affect Sakai and not just the local installation of Sakai.

  1. User posts an issue in Jira.

Requirements Working Group

The workflow for the requirements process is being further developed in the Sakai Working Group: Requirements Process. The general steps are:

Designers and Developers

Planning

  1. As new issues come in and as you periodically review the status of existing issues, use the Target Version to indicate for what version you expect to implement a solution for the issue.

Addressing an Issue

  1. Assign the issue to yourself to work on.
  2. If you are implementing a Feature Request, Requirement, or Contributed Patch, first use Move to covert the issue type to a Task and set the Target Version to reflect for which version you expect to complete your work.
  3. Work on the issue, updating, modifying, commenting, re-assigning, etc. as necessary to achieve resolution.
  4. When work is complete, and if the resolution of the issue is Fixed, then Resolve the issue and set the Fix Version to Nightly/SVN-Trunk. If the resolution is other than Fixed (e.g., Duplicate, Non-Issue, Cannot Reproduce), then set the Target and Fix Version to Unknown.

Maintenance Branches

See Maintenance Branch Guidelines.

Security Releases

To be filled in...

Quality Assurance (QA)

Releases

  1. Select an appropriate issue from the list of issues "QA Awaiting Verification".
  2. Attempt to verify the issue.
  3. If the issue passes verification:
  4. If it fails verification:

Maintenance Branches

See Maintenance Branch Guidelines.

Security Releases

To be filled in...

Notifications

Whenever a Jira issue is modified, the issue's Reporter, Assignee, and any Watchers will receive an email notifying them of the chage. To become a Watcher on an issue, go to the issue and view it, and click on the "Watch It" link.

There are also a couple of strategies for monitoring Jira issues en masse:

Email Summaries of Jira Filters

You can subscribe to filters in Jira and receive an email summary of the filter's contents at a time interval you specify.

For folks interested in a daily summary of updates in the Sakai project in Jira, you should subscribe to the "Updated in Last 24 Hours" filter, and specify a 24-hour or 1-day time interval. (Note that the time of day when you subscribe is the time of day when Jira will send the digest, so you probably want to subscribe to the filter early one morning.)

On-Event Automated Notifications

Jira can also send on-event notification emails, such as whenever an issue is created, updated, resolved, closed, etc. If you are interested in receiving such emails, then please contact jira-admins@collab.sakaiproject.org.

Tips