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, which may be selected for implementation in a future release of Sakai.
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="06c9fedc77c40d60-c6747aec-4ad94e4f-9c878b69-eac9c27a55ef6c12053b8b3f"><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!]
- A brief statement summarizing the issue. (Field is limited to < 255 characters.)
- A description of the Sakai enivronment in which the issues was encountered, e.g., web browser, operatings system on which Sakai is installed.
- For QA participants this is a good place to note on which test server the issue occurred (e.g., MIT Stable HSQL, MIT Stable Oracle, MIT Stable MysQL, Nightly)
- A detailed description of the issue, including the steps necessary for reproducing the issue.
- You can also add attachments, including screen shots to help illustrate the issue.
- The particular part or parts of Sakai related to the issue.
- Controls the visibility of the issue; currently toggles between viewable by anyone or by just the committers and testers (and the reporter of the issue).
General Workflow for Teams/Tasks Requirements/Design
The workflow for the requirements process (post Sakai 2.1 release) is being developed in the Sakai Working Group: Requirements Process.
Designers and Developers
|Designers and Developers|
|Designers and Developers|
- A Bug or Task issue is assigned to someone to work on.
- Work begins on issue. Issue is updated, modified, re-assigned, etc. as necessary to achieve resolution.
- When work is done, Issue is resolved as "Fixed" (or "Won't Fix" if necessary), and meta-data fields are updated accordingly:
- Fix Version:
- In general the Fix Version is set to "Nightly/SVN-Trunk".
- At Feature Freeze, all the resolved issues are evaluated for inclusion in the release, and those that are selected have their Fix Version updated to the first interim release (e.g., 2.1.0.001).
- Afater 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 (e.g., 2.1.0.002), or, if it is unclear to Nightly/SVN-Trunk (and the release team will update it as necessary).
Quality Assurance (QA)
- QA personnel select an appropriate issue from the list of issues "QA Awaiting Verification".
- An attempt is made to verify the issue.
- If it passes verification, then it is Closed.
- If it fails verification, then it is Reopened.
- 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.