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.
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="cd4c84c11ade57d1-c99284b1-4d6a4c41-a9c7967c-13d7015c9261ccf45202358b"><ac:plain-text-body><![CDATA[
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!]
- Branch versions as Affects Versions (e.g., Nightly/SVN-Trunk, 2.3.x, 2.4.x) – Limit the use of a branch version as an Affects Version to when the same issue is known to not be present in a previously tagged version. This is important because branch versions are moving targets, what is Nightly/SVN-Trunk one day is not necessarily the same the next, so it is genereanlly more important to know if an issue affects a released version. Also, such issues are treated as transient issues and will not necessarily need to consume valuable QA resources once they are resolved.
*Branch versions as Fix Versions* (_e.g._, Nightly/SVN-Trunk, 2.3.x, 2.4.x)
-- As fixes are checked into a branch, they should have their Fix Version updated from the version the issue was estimated to be addressed in (_e.g._, "2.4.0 \[Tentative\]") to the branch's version (_e.g._, Nighlty/SVN-Trunk). Generally, the only branch version a developer needs to be concerned with is Nightly/SVN-Trunk. Only the Branch Manager or project team members dealing with maintenance branches will need to worry about adding other branch versions (_e.g._, 2.3.x, 2.4.x) as Fix Versions; and, those versions should only be used when the fix is actually checked-in to the branch, it should not be used as an indication that one would like a fix checked-in. This will ensure that the issue continues to appear listed in the correct place in the shared Jira filters.
Maintenance Branch Version Numbers
- As new issues come in and as you periodically review the status of existing issues, use the Fix Version to indicate for what version you expect to implement a solution for the issue.
- Notes on future versions:
- Leave the Fix Version as Unknown if you are not sure what version the issue will be addressed for.
Set the Fix Version to the *general release version* (_e.g._, "2.4.0 \[Tentative\]") to indicate an issue will be addressed for that release.
- Notes on future versions:
Addressing an Issue
- Assign the issue to yourself to work on.
- 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 Fix Version to reflect for which version you expect to complete your work.
- Work on the issue, updating, modifying, commenting, re-asssigning, etc. as necessary to achieve resolution.
- 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 resoultion is other than Fixed (e.g., Duplicate, Non-Issue, Cannot Reproduce), then set the 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.)