Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. Anyone may Create an Issue (see #Create Issue Detailed Instructions)
  2. Assignee will Review issue is for accuracy and completeness of information.
    • The issue maybe resolved as Duplicate, Incomplete, or Cannot Reproduce if appropriate (see #Resolution). All issues resolved with a resolution other than "Fixed" should not have a Fix Versions set, (they were not fixed!) Their Fix Version should be "Unknown".
    • The issue may be linked to other related issues.
    • The issue may be assigned to someone else in a better position to review and/or resolve.
    • The Priority may be adjusted
    • Other attributes may be changed as appropriate, such as Components, Affects Version, Security Level, Original Estimate, etc.
  3. Assignee selects Start Progress and begins to work on the issue
    • If you are implementing a Feature Request or Contributed Patch, first use Move to covert the issue type to a Task
    • If working in a branch, first merge your branch to trunk before resolving the issue
  4. Assignee selects Resolve Issue with relevant #Resolution when work is completed, and updates Fix Version to the next major release version
    • Assignee edits the issue and adds a Test Plan under "Testing"
    • Assignee edits the issue and adds relevant "Release Notes"
    • Assignee edits the issue and selects Merge for previous supported and affected releases (e.g. 2.8 Status)
    • For Tasks, if there is nothing explicit for the QA team to test, then please Close the issue.
  5. QA team verifies resolution of issue and adds a comment with details of the testing.
    • If it fails verification, then it is Reopened and re-assigned for further work, and the Affects Version is updated to include the version tested.
    • 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 if the original problem is still present.
    • Some issues can not be easily verified and may require special testing conditions or input from developers.
    • Close the issue. This will move the issue from the "Awaiting Verification" to the "Verified" list in Jira.
  6. Release Manager merges the issue to previous supported and affected releases
    • The associated merge status is set to Resolved
    • The issue is Closed when all merges to previous releases have been completed


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

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="a4d23630a2badc39-9368e522-4fc749d7-b54eb32b-759578f4b9bb0632add636c9"><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!]



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.