Versions Compared

Key

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

...

  1. A user (anyone) creates an Issue (please see #Create Issue Detailed Instructions first)
    • Issue is automatically assigned to a Awaiting Review status
  2. CLE team member verifies the issue for accuracy (i.e. is it an actual issue) and completeness of details.
    • Complete and valid issues are set to status Open
    • The team member may resolve the issue as Duplicate, Incomplete, or Cannot Reproduce if appropriate (see #Resolution).
    • The issue may be linked to other related issues.
    • The issue will be and assigned to a user or group (e.g. Samigo Team or CLE Team) who can resolve it.
    • The Priority may be adjustedOther attributes may be changed as needed, (Components, Affects Version, Security Level, Original Estimate, etc.)team member may resolve the issue as Duplicate, Incomplete, or Cannot Reproduce if appropriate (see #Resolution).
  3. Assignee selects Start Progress and begins to work on the issue (as time and priorities allow)
    • Assignee selects Stop Progress if they are not going to work on the issue anymore for a few days and it is not resolved
  4. Assignee sets the issue to Resolved with the relevant #Resolution when work is completed
    • For tasks, if there is nothing explicit for the QA team to test, then the issue is Closed without testing.
  5. QA team selects Start QA and begins verifying the issue
    • QA team member selects Stop QA if they are not going to complete the testing on the issue within a short time frame
  6. QA team verifies resolution of the issue and adds a comment with details of the testing results and process.
    • If verification fails, then it is Reopened for further work (automatically re-assigned to the user who resolved it)
    • If verification succeeds then QA marks the status as Verified (indicating it has been Tested)
  7. Release Manager merges the issue (if it is a bug) to previous supported and affected releases
    • The associated version merge status is set to Resolved
    • The issue is Closed by the Release Manager when the last merge has been completed

...

Issue Type

Definition for Sakai

Bug

An error in design or implementation which directly impedes a user from achieving their expected result.

Task

A new capability being added to Sakai.

Feature Request

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="584e201b98d402fa-7d74ed06-4d68401f-aaa9858e-762e6e065c2d45905758918a"><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!]

]]></ac:plain-text-body></ac:structured-macro>

Branch

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.

...

Status

Definition for Sakai

Awaiting Review

Issue is waiting for investigation.

Image Added Open

Issue is under consideration and investigationvalid and ready to be worked on.

In Progress

Issue is actively being worked on.

Reopened

Issue was thought to be resolved, however, it did not pass QA and needs further work.

Resolved

Issue has been addressed and is ready for QA testing.

Image Added Tested

Issue has been tested and has passed. Ready for merging.

Closed

Work on issue is complete and has passed testing.
NOTE: Issue may still need to be merged into related branches. , no other activity.

  • (Awaiting Review)
    • Contributed patches should receive priority treatment.
    • The issue should be linked to other related issues.
    • Check the is assigned to a user or group (e.g. Samigo Team or CLE Team) who can resolve it.
    • Adjust the Priority depending on overall project and release goals
    • Other attributes should be changed as needed, (Components, Affects Version, Security Level, Original Estimate, etc.)
  • (Open)
    1. Open tickets should be worked on within 90 days or assigned back to Unassigned
    2. Open tickets which have seen no activity in 180 days will be moved back to Awaiting Review status
  • (Resolved) - General
    1. Resolved tickets which have had no activity in 180 days will be Closed without testing
    2. Details in #Resolution
  • (Tested) QA is complete on this ticket.
  • (Closed) No other activity should or will happen on this ticket

Anchor
Resolution
Resolution
Resolution

Resolution

Definition for Sakai

Unresolved

Issue is under consideration and/or actively being worked on.

Fixed

Issue has been addressed through changes to the design or code. When viewing an issue, the "Subversion Commits" tab provides specific details regarding code changes.

Won't Fix

Issue will not be addressed because it does not match project goals.

Non-Issue

Issue turned out not to be a problem with Sakai.

Duplicate

Issue is a duplicate of a previously submitted issue. A link to the other issue is added so that progress on the issue can be easily accessed.

Incorporated

Issue has been incorporated into another issue. A link to the other issue is added so that progress on the issue can be easily accessed.

Incomplete

Not enough information has been provided to identify the issue.

Cannot Reproduce

Issue cannot be reproduced and more details or steps need to be added before it can be reopened.

  • (Awaiting Review)
    1. TODO
  • (Open)
    1. TODO
  • (Fixed) Developers should do the following when fixing issues:
    1. All commits to subversion must include the corresponding JIRA number as the first word in the commit message. For example: svn commit -m "SAK-1234 fixed the uncaught NPE"
    2. If you are implementing a Feature Request or Contributed Patch, first use Move to covert the issue type to a Task
    3. If working in a branch, first merge your branch to trunk before resolving the issue
    4. Update Fix Version to the next major release version
    5. Add a Test Plan under "Testing"
    6. Add relevant "Release Notes"
    7. Check the boxes, if appropriate, for Property addition/change required and/or Conversion Script Required
    8. Selects Merge for previous supported and affected releases (e.g. 2.8 Status) for bugs only (features are NOT merged back)
  • (Reopened) If QA reopens an issue:
    1. QA sets the Affects Version to the version tested
    2. 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 original problem is still present.
    3. Some issues can not be easily verified and may require special testing conditions or input from developers.
  • (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 linked-to issue to track further progress
    3. Closed with a Resolution of "Duplicate"
    4. Fix Version and should be set to "Unknown"
  • (Incorporated) If it is incorporated into a previous issue, then the newly opened issue is:
    1. Linked to the original issue as "incorporated by"
    2. Commented with a note to look at the linked-to issue to track further progress
    3. Closed with a Resolution of "Incorporated"
    4. Fix Version and should be set to "Unknown"
  • (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 flaw, then it is Closed with a Resolution of "Non-issue"; otherwise, the design flaw could be captured to Bug or Feature Request.
    3. Fix Version should be set to "Unknown"
  • (Incomplete) If insufficient information is provided to describe the issue, then:
    1. A comment is added to ask the user to include the needed information (should list the information needed)
    2. The issue is closed with a Resolution of "Incomplete"; issue can always be Reopened.
    3. Fix Version should be set to "Unknown"
  • (Cannot Reproduce) If the issue cannot be reproduced on one of the QA test servers, then:
    1. A comment is entered to indicate what was attempted to reproduce the issue (e.g. "followed steps in issue")
    2. The issue is closed with a Resolution of "Cannot Reproduce"; issue can always be Reopened.
    3. Fix Version should be set to "Unknown"

...