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="2690f02a52d77122-692e8962-415e4131-b3c9a919-3c35e742cfb7ad32836b24df"><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.


In practice, the Jira Priority field is utilized by Sakai at two times: during prioritization of requirements feature requests/branches/contributed patches for implementation or merging, and when making decisions on what will actually appear in a release. Initial priorities, when an issue is first reported, may be changed to reflect those needsneeds as a release moves forward and priorities evolve.

As a release date approaches, priorities will also be adjusted – and lowered, if necessary – to reflect the decreasing availability of time and resources.


  • Issue is vetted for accuracy and completeness of information.
  • The issue is evaluated by the appropriate project team, just like a Feature Request or RequirementBranch, for inclusion in a future release of Sakai.
    • In some cases, a Contributed Patch may run counter to the Sakai design and cannot be incorporated, 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.
  • 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.


  1. Issue is vetted for accuracy and , completeness of information.
  2. 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.
  3. Project team evaluates and discusses the issue as needed to determine whether to work on it.


  1. , relevance to Sakai's overall design, etc.
  2. Assigned to appropriate Project Team or Working Group lead, The will evaluate and discuss such issues periodically, when the group reaches an appropriate point in the release cycle to adsorb community input.
  • If the decision is made to no address the issue, then it should be resolved as "Won't Fix" with appropriate comments.


  1. Assign the issue to yourself to work on.
  2. If you are implementing a Feature Request , Requirement, or Contributed Patch, first use Move to covert the issue type to a Task and set the Target Version to reflect for which version you expect to complete your work.
  3. Work on the issue, updating, modifying, commenting, re-assigning, etc. as necessary to achieve resolution.
  4. When work is complete, and if the resolution of the issue is Fixed, then Resolve the issue and set the Fix Version to Nightly/SVN-Trunk. If the resolution is other than Fixed (e.g., Duplicate, Non-Issue, Cannot Reproduce), then set the Target and Fix Version to Unknown.
    • For Tasks, if there is nothing explicit for the QA team to test, then please Close the issue.
    • For Bugs, just leave the issue as Resolved, and the QA team will Close it after verifying it, or Reopen it for further development if the original issue was not resolved.