Versions Compared


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


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="49960118a26d0fe3-59af1075-4c7c4793-ac4ba4ff-5d5ba3e416fb9fbe87807a2e"><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!]




  1. Issue is Opened.
  2. Affects Version:
    • This should be set to the version of Sakai in which the issue manifests itself.
    • Multiple versions can be specified.
  3. Issue is vetted for accuracy and completeness of information and linked to related issues.
    • (Duplicate) If it duplicates a previous issue, then the newly opened issue is:
      1. Linked to the original issue as "duplicates"
      2. Commented with a note to look at the original issue to track progress
      3. Closed with a Resolution of "Duplicate"
    • (Non-Issue) If it turns out that the issue was the result of a mis-understanding of how Sakai operates, then:
      1. An effort is made to clarify the situation.
      2. If the mis-understanding does not suggest a design flawyflaw, then it is Closed with a Resolution of "Non-issue"; otherwise, it maybe continue as the design flaw could be captured to a Bug or be turned into a Feature Request.
    • (Incomplete) If insufficient information is provided to describe the issue, then:
      1. An effort is made to obtain additional information.
      2. If insufficient information is provided in a reasonable time-frame, then the issue is closed with a Resolution of "Incomplete"; issue can always be Reopened.
    • (Cannot Reproduce) If the issue cannot be reproduced on one of the QA test servers, then:
      1. An effort is made to obatain additional information.
      2. If insufficient information is provided in a reasonable time-frame, then the issue is closed with a Resolution of "Cannot Reproduce"; issue can always be Reopened.
  4. Issue is assigned to the appropriate project lead.
    **Further vetting, as above, may be necessary for particularly complex issues.
  5. 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.
  6. Issue is assigned to an appropriate individual.
  7. An issue may be re-assigned to others or Watchers added to facilitate discussion of its resolution. The Priority, Fix Version, Components, etc. may should also be updated as necessary as discussion around the issue evolves.
  8. Assignee Resolves issue with relevant Resolution, when work is completed, and updates Fix Version as necessaryto "Nightly/SVN-Trunk" to reflect is availability.
    • (Fixed) Most issues that reach this stage are resolved and their resolution is set to "Fixed".
    • (Won't Fix) Some issues are identified as conflicting with the expectations of the currently adopted design or are determined to represent techinical "impossibilities" and resolved as "Won't Fix". Some of these issues may , or they can be Moved to become Feature Requeests for future consideration in re-designing the system.
  9. QA team verifies resolution of issue. (QA verification only occurs against known releases, not against the SVN Trunk.)
    • If it passes verification, then it is Closed.
    • If it failes verification, then it is Reopened and re-assigned for further work.


  • Issue is vetted for accuracy and completeness of information.
  • Tasks are used by project teams to track the addition of or changes to functionality.
  • When the task is completed, the assignee Resolves it as Fixed, as above with Bugs.

Feature Requests
Feature Requests
Feature Requests


  1. Issue is vetted for accuracy and completeness of information.


  1. If the issue represents a broad change for Sakai, then it is treated as a Requirement, and moved to the Sakai Requirements project for further handling. (See requirements process.) Otherwise, smaller-scope suggestions, such as re-naming buttons, changing a tool's layout, choosing different defaults, etc, are left as Feature Requests and assigned to the appropriate project lead.
  2. Project team evaluates and discusses the issue as needed to determine whether to work on it.
  • If it is decided not to implement it, then the issue should be resolved as "Won't Fix" with appropriate comments.
  1. When a project team is ready to address the issue, it should be Moved to a Task and an initial estimate of the Fix Version set.



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.

Contributed Patches
Contributed Patches
Contibuted Patches

  • Issue is vetted for accuracy and completeness of information.
  • A matching Bug or Feature Request issue is generated (Cloned) to track Sakai's progress on addressing the issue; cloning auotmatically links it to the original Contributed Patch issue.
  • The issue is evaluated by the appropriate project team, just like a Feature Request or Requirement, for inclusion in a future release of Sakai.
    • In some cases, a Contributed Patch may run counter to the Sakai design and cannot be incoporated, then the corresponding Bug or Task issue will be and maybe marked as Won't Fix and an explanation as to why provided. In this case, the contributor of the Patch may choose to continue developing the patch for future versions of Sakai.
  • When the Bug or Task is addressed, either by integrating the patch into Sakai or develop another solution with the same outcome, the Bug or Task is Resolved as normal and goes on to QA. The oringal Contributed Patch issue can be Closed at this point with a comment pointing to the Resolved issue.
  • Until the patch is integrated in Sakai, the community encourages the contributor to be responsive to comments and feedback provided by other users of the patch and to continue to update the patch to current versions of Sakai.

General Workflow by Task



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


  1. Assign a Bug or Task to yourself to work on.
  2. Work on the issue, updating, modifying, commenting, 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".
    • Notes on setting Fix Version:
      • In general set the Fix Version to "Nightly/SVN-Trunk", unless you know a fix is intended for and will be included in a specific version, then use that.
      • At Feature Freeze, all the resolved issues are evaluated for inclusion in the release, and those that are selected have their Fix Version updated, if necessary, from Nighlty to the first interim QA release (e.g.,
      • After Feature Freeze, and during QA, if an issue is intended for a specific interim release, then the Fix Version can be set appropriately (e.g.,, or, if it is unclear, set it to Nightly/SVN-Trunk (and the release team or QA team will update it as necessary).
    (or to "Unknown", if you did not fix it.)
  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 verifying it passes testing, (or Reopen it for further development, if they discover problems.)

Quality Assurance
Quality Assurance
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
    • if the orginal problem is still present.
    • Some issues can not be easily verified and may require special testing
    • condtions or input from developers
    , and further discussion is conducted as necessary
    • .
  3. If it the issue passes verification:
      • Verify the Fix Version is correct. (Note that an issue can have more than one Fix Version, such as being fixed in the next release plus in another version's Maintenance Branch.)
      • Close the issue. This will move the issue from the "Awaiting Verification" to the "Verified" list in Jira.
  4. If it fails verification:
      • Update Affects Version to include version tested.
      • Reopen issue and re-assign to project team leader. If is not clear to whom the issue needs to be re-assigned, then assign it to default.


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.