Versions Compared


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


  1. User searches JIRA to see if the issue already exists (Sakai Jira Search)
    • Search strategies include searching for a particular component, sorting by update date, and exporting as an MS Excel file (in Views)
  2. User searches the sakai mailing lists archives (nabble sakai lists archives)
  3. If user is not sure if the problem is a bug, they send a note to the sakai-dev mailing list first to ask
  4. User creates an issue in Jira of the appropriate #Issue Type
    • The component should be set if it is known (leave blank if not sure)based on where the problem appears to exist
    • The Assignee should be set as Unassigned (ideally) or left as -Automatic- (do NOT assign to a developer directly)
    • The Affects Version should be set to the released version of the instance of Sakai being used.
    • The Fix Version should be left set to the default of Unknown. The project teams will set the Fix Version once they have had time to review the issue and estimate when they believe they will be able to address it.
    • As much of the following information should be included as possible (to avoid the issue being closed as incomplete)
      • Sakai version
      • (bugs) Steps to reproduce (detailed and step by step)
      • Environment details (DB type and version, tomcat version, OS type and version, Browser and version, etc.)
      • (bugs) URL to the page where the error occurs
      • (bugs) Stacktrace (traceback) if available
      • (bugs) relevant portions of the server logs (do not attach your entire logs, we do not have time to read through 1000s of lines of logs and figure out where the relevant parts are)
      • (bugs) Screenshots showing the error
      • (feature) Use cases and detailed requirements
      • The desired resolution

Typically you will be creating Task issues to describe new features or functionality you are planning to implement. If the change is significant or experimental in nature, consider creating a Branch issue instead and doing the work in a Jira Branch. (See the Release Practice Guidelines for more details on Jira Branches.) You may also need to create Bug issues for problems you uncover and need to fix in your project.

For all issues, please provide a simple Summary and Description that can be understood by all in the community, not just yourself or other developers. If you need to include some techno-babble, in addition to the plain language, for other developer types to understand the full details that's fine, but consider placing it in a comment on the issue.


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="5a15987b9072f3d3-79af2ff2-489d4361-892a82c8-82949f71ed1c140d0f47a836"><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.