Jira and Confluence share user accounts. You can obtain an account for both by self-registering. (Note that this account is separate from your Sakai account on Collab, http://collab.sakaiproject.org, and any account you may have associated with the Sakai website, http://www.sakaiproject.org.)


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.


Issue Type

Issue Type

Definition for Sakai


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


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="0da34ccd-f76c-4391-8384-5b29a3fd08ec"><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 orignal issue in order to track Sakai's work on the issue. [Use at your own risk!]




Definition for Sakai


Issue is under consideration.

In Progress

Issue is actively being worked on.


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


Issue has been addressed and is ready for testing.


Work on issue is complete and has passed testing.



Definition for Sakai


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


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. Such an issue might become a Feature Request.


Issue turned out not to be a problem with Sakai. Such an issue might result in a Feature Request or become an entry in the Sakaipedia if it is a common point of confusion.


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


Not enough information has been provided to identify the issue.

Cannot Reproduce

Issue cannot be reproduced. Perhaps it was a non-Sakai problem or it was resolved as a by-product of other work.


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

Both of these versions, however, are not necessarily meaningful for all issue types. The table below summarizes how they are used in the context of specific issue types.

Issue Type

Affects Version

Fix Version


Version in which bug was identified.

Version in which bug is expected to be or has actually been resolved. (star)


Not required, but may provide useful context for comments on the issue.

Version in which new capabilitity is expected to appear or has appeared. (star)

Feature Request

Not required, but may provide useful context for comments on the issue.

Not applicable. (Note that Feature Requests selected for implementation are currently converted to one or more Tasks for tracking the actual work.)

Contributed Patch

Version to which the patch can be applied.

Not applicable. (Note that Contributed Patches are cloned to provide a separate Bug or Feature Request for tracking Sakai work on the issue.)

(star) For both Bug and Task issues the fix version depends on whether the issues is unresolved ("expected" fix version) or resolved ("actual" fix version).

After a release is made, the interim QA release versions are merged into the last QA version number for clarity, (i.e.,,,, and were merged into, and that version is renamed to the release version (i.e., 2.1.0).

Further notes on Version Numbers

When development work predominates on a branch – prior to a the branch entering QA – the version number to report issues against is basically a moving target. In other words, as fixes are checked into a branch, there is currently no change in the version used to refer to that branch; the SVN revision number, however, does change, so use that if you need to track that level of granuliarty. For instance, for issues encountered on the trunk branch, report the Affects Version as "Nightly/SVN-Trunk. When such issues are resolved prior to QA, the Fix Version is similarly set, which helps identify potentially transient issues that might not need full attention during QA.


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

In practice, the Jira Priority field is utlized by Sakai at two times: during prioritization of requirments 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, prorities will also be adjusted – and lowered, if necessary – to reflect the decreasing availability of time and resources.


Definition for Sakai


Release will not be completed until issue is resolved.


Issue will most likely be resolved for release.


Issue should be resolved for release.


Issue may be resolved for release.


Issues that might be resolved before a release.





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 variours groups interactig 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


  1. Issue is Opened.
  2. Issue is vetted for accuracy and completeness of information and linked to related issues.
  3. Initial estimates of the scope of the bug and the resources required to address it are made and the reported Priority and Fix Version are updated accordingly.
  4. Issue is assigned to an appropriate individual.
  5. An issue may be re-assigned to others or Watchers added to facilitate discussion of its resolution. The Priority, Fix Version, Components, etc. may also be updated as necessary.
  6. Assignee Resolves issue with relevant Resolution, when work is completed, and updates Fix Version as necessary.
  7. QA team verifies resolution of issue. (QA verification only occurs against known releases, not against the SVN Trunk.)


Feature Requests


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 Reprsentatives 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; coverted to one or more Tasks in the Sakai Jira project to track its implementation. For requirements which are being worked on by volunteers in collaboration with existing Project Teams, the Requirements should be converted to either one or more Tasks or a Contributed Patch, depending the level of intereaction and commitment to integration with Sakai in the desired time-frame.

Contibuted Patches

General Workflow by Task


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

Designers and Developers

  1. Assign a Bug or Task to yourself to work on.
  2. Work on the issue, updating, modifying, re-asssigning, etc. as necessary to achieve resolution.
  3. When work is complete, Resolve the issue as Fixed (or other appropriate resolution, such as "Won't Fix", if necessary) and set the Fix Version to "Nightly/SVN-Trunk".
  4. For Tasks, if there is nothing explicit for the QA team to test, then please Close the issue. Otherwise, for Bugs, just leave the issue as Resolved, and the QA team will Close it after it passes testing, or Reopen it for further development.

Quality Assurance (QA)

  1. Select an appropriate issue from the list of issues "QA Awaiting Verification".
  2. Attempt to verify the issue. In the process of verifying the issue, if you discover a different problem, create a new issue to capture it, rather than re-opening the current issue and re-using it; reserve re-opening only for the orginal problem. Some issues can not be easily verified and may require special testing conidtions or input from developers, and further discussion is conducted as necessary.


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 Peter A. Knoop