Versions Compared


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


Basic Workflow

  1. A user (anyone) Anyone with a JIRA account creates an Issue (please see #Create Issue Detailed Instructions first)
    • Issue is automatically assigned to a Awaiting Review status
  2. A Sakai Core 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 and assigned to a user or group (e.g. Samigo Team or Sakai Core Team) who can resolve it.
    • The team member may resolve the issue as Duplicate , Incomplete , or Cannot Reproduce if appropriate (see #Resolution).
  3. The 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. The 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. The QA team (potentially you!) selects 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. The 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. The 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   (see  #MergeStatus )
    • The issue is Closed by the Release Manager when the last merge has been completed


The Sakai community is encouraged to report issues and post feature requests in Jira, however, it should not consider as a primary destination for users of their own instance of Sakai to report issues. The Community maintains a set of servers for testing. If you find an issue on your own institution's Sakai servers, please do not report that to the community. Rather, each organization running Sakai is expected to provide have its own front-line support.


issues list. However, should an issue on your institutions' Sakai be found, AND that issue also exists on one of the community's servers, it should be reported to the community. Here's how!

  1. You search 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 You might also check the sakai mailing lists archives (nabble sakai lists archives)
  3. If user is you're not sure if the problem is a bug, they then send a note to the sakai-dev mailing list first to ask
  4. User creates You then create an issue in Jira of the appropriate #Issue Type
    • The component should be set based on where the problem appears to exist. Do not use the Performance component however. Use a 'Performance' label to flag performance related issues so there is a consistent way to filter these issues across projects.
    • The Assignee should be left as -Automatic-
    • 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

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.

If you need to include a large piece of information in an issue, such as a stack trace, please do not put it in the Description field. Instead, add it as an attachment or a comment. (This makes it a lot easier to view and parse issues in most browsers.)

Sometimes you developers may uncover bugs in your own code and need to create a Bug issue. If you think the bug does not affect past versions of Sakai and only exists in the code you are actively working on in trunk, then use the tentative release version that trunk will become as the Affects Version (e.g., 2.6 [Tentative]). Or, if you're working in a Jira branch, then use "branch" as the Affects Version.