Versions Compared


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


  1. A user (anyone) creates an Issue (please see #Create Issue Detailed Instructions first)
    • Issue is automatically assigned to a Awaiting Review status
  2. CLE team member verifies the issue for accuracy (i.e. is it an actual issue) and completeness of details.
    • Complete and valid issues are set to status Open
    • The team member may resolve the issue as Duplicate, Incomplete, or Cannot Reproduce if appropriate (see #Resolution).
    • The issue may be linked to other related issues.
    • The issue will be assigned to a user or group (e.g. Samigo Team or CLE Team) who can resolve it.
    • The Priority may be adjusted
    • Other attributes may be changed as needed, (Components, Affects Version, Security Level, Original Estimate, etc.)
  3. Assignee selects Start Progress and begins to work on the issue (as time and priorities allow)
    • Assignee selects Stop Progress if they are not going to work on the issue anymore for a few days and it is not resolved
  4. Assignee sets the issue to Resolved with the relevant #Resolution when work is completed
    • For tasks, if there is nothing explicit for the QA team to test, then the issue is Closed without testing.
  5. QA team select Start QA and begins verifying the issue
    • QA team member selects Stop QA if they are not going to complete the testing on the issue within a short time frame
  6. QA team verifies resolution of the issue and adds a comment with details of the testing results and process.
    • If verification fails, then it is Reopened for further work (automatically re-assigned to the user who resolved it)
    • If verification succeeds then QA marks the status as Verified (indicating it has been Tested)
  7. Release Manager merges the issue (if it is a bug) to previous supported and affected releases
    • The associated version merge status is set to Resolved
    • The issue is Closed by the Release Manager when the last merge has 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="73c3ac9d345c93f4-bace852e-4ab44cb3-ab9f932b-9fbbb4485427bd59348e0c1b"><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.