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="651658b8dda89356-221d2b94-4bc74bb6-b2b9ad84-4dd027813fc558e8002d2c10"><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!]



Each Jira issue has an Affects Version and a Fix Version. Generally speaking Sakai uses these values to indicate:

  • Affects Version - Version in which an issue is observed. This should never be set to a "future" version of Sakai, e.g., Post-2.1.2; issues should only affect Sakai relative to a known existing version.
  • Fix Version - Version in which an issue is resolved. This could be a "future" version of Sakai, when indicating a future release you expect an issue to be resolved in.


Designers and Developers
Designers and Developers
Designers and Developers

  1. A Assign a Bug or Task issue is assigned to someone yourself to work on.
  2. Work begins on the issue. Issue is updated, modifiedupdating, modifying, re-assignedasssigning, etc. as necessary to achieve resolution.
  3. When work is donecomplete, Resolve the issue is Resolved as "Fixed" (or other appropriate resolution, such as "Won't Fix", if necessary) , and meta-data fields are updated accordingly: and set the Fix Version to "Nightly/SVN-Trunk".
    • Notes on setting Fix Version:
      • In general set the Fix Version is set 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 is set to the appropriate iterim release 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).
  4. For Tasks, the issue may further be Closed, if there is nothing explicit for the QA team to test. The succesful implementation of the new capabilities described in the Task will be exercised by QA functionality testing against the new feature set for the release, then please Close the issue. Otherwise, for Bugs, just leave the issue as Resolved, and the QA team will Close it after it passes testing, or Reopen it for further development.

Quality Assurance
Quality Assurance
Quality Assurance (QA)

  1. QA personnel select Select an appropriate issue from the list of issues "QA Awaiting Verification".
  2. An attempt is made Attempt to verify the issue. I(f in 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 for the orginal problem. Some issues can not be easily verified and may require special testing conidtions or input from developers, and further discussion is conducted as necessary.
    • If it passes verification, then it is Closed.:
      • 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.
    • If it fails verification, then it is Reopened. :
      • Update the Affects Version to include the version failing verificationtested.
      • 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.
    • Some issues can not be easily verified and may require special testing conidtions or input from developers, and further discussion is conducted as necessary.