Versions Compared

Key

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

...

Anchor
Definitions
Definitions
Definitions

...

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, 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="8e5f761c1db51029-809e4a06-4d5347fe-aa699383-8766830651cdb775aa490b20"><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!]

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

...

  1. Issue is Opened.
    • Affects Version:
      • This should be set to the version of Sakai in which the issue manifests itself.
      • Multiple versions can be specified.
  2. Issue is vetted for accuracy and completeness of information and linked to related issues.
    • (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 original issue to track progress
      3. Closed with a Resolution of "Duplicate"
    • (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 flawy, then it is Closed with a Resolution of "Non-issue"; otherwise, it maybe continue as a Bug or be turned into a Feature Request.
    • (Incomplete) If insufficient information is provided to describe the issue, then:
      1. An effort is made to obtain additional information.
      2. If insufficient information is provided in a reasonable time-frame, then the issue is closed with a Resolution of "Incomplete"; issue can always be Reopened.
    • (Cannot Reproduce) If the issue cannot be reproduced on one of the QA test servers, then:
      1. An effort is made to obatain additional information.
      2. If insufficient information is provided in a reasonable time-frame, then the issue is closed with a Resolution of "Cannot Reproduce"; issue can always be Reopened.
  3. Initial estimates of the scope of the bug and the resources required to address it are made and the reported Priority and Fix Version are updated accordingly.
  4. Issue is assigned to an appropriate individual.
  5. An issue may be re-assigned to others or Watchers added to facilitate discussion of its resolution. The Priority, Fix Version, Components, etc. may also be updated as necessary.
  6. Assignee Resolves issue with relevant Resolution, when work is completed, and updates Fix Version as necessary.
    • (Fixed) Most issues that reach this stage are resolved and their resolution is set to "Fixed".
    • (Won't Fix) Some issues are identified as conflicting with the expectations of the currently adopted design or are determined to represent techinical "impossibilities" and resolved as "Won't Fix". Some of these issues may become Feature Requeests for future consideration in re-designing the system.
  7. QA team verifies resolution of issue. (QA verification only occurs against known releases, not against the SVN Trunk.)
    • If it passes verification, then it is Closed.
    • If it failes verification, then it is Reopened and re-assigned for further work.

Anchor
Tasks
Tasks
Tasks

  • Issue is vetted for accuracy and completeness of information.

...

  • Issue is vetted for accuracy and completeness of information.
  • What exactly happens next to Feature Requests is being determined as part of our ongoing development of a community requirements process.

...

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.

...

  • The current practice is:
    • Feature Requests are evaluated by designers and developers for inclusion in a future Sakai release. This generally occurs right after a release is completed, though by no means is limited to this time-frame.
    • Feature Requests selected for incorporation are converted to one or more Tasks to track the actual implementation work.

...

Anchor
Contributed Patches
Contributed Patches
Image Added Contibuted Patches

  • Issue is vetted for accuracy and completeness of information.
  • A matching Bug or Feature Request issue is

...

  • generated to track Sakai's design and development progress on addressing the

...

  • issue and is linked to the original Contributed Patch issue.
  • What exactly happens next is being determined as part of our ongoing development of a community requirements process. The current practice is:
    • Contributed Patches, like Feature Requests, are evaluated for inclusion in a Sakai release.
    • In some cases, a Contributed Patch may run counter to the Sakai design and cannot be incoporated, then the corresponding Bug issue will be marked as Won't Fix and an explanation as to why provided.

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

  1. A Bug or Task issue is assigned to someone to work on.
  2. Work begins on issue. Issue is updated, modified, re-assigned, etc. as necessary to achieve resolution.
  3. 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 "NighltyNightly/SVN-Trunk".
      • At the Feature Freeze for a release, all the resolved issues are evaluated for inclusion in the release, and those that are incorporated selected have their Fix Version updated to the first interim release number (e.g., 2.1.0.001).
      • A Afater Feature Freeze, and during QA, if an issue is intended for a specific interim release, then the Fix Version is set appropriately to the appropriate iterim release (e.g., 2.1.0.002, 2.1.0.003, and so on...).
  • During QA
      • ), or, if it is unclear to Nightly/SVN-Trunk (and the release team will update it as necessary).

Quality Assurance (QA)

  1. QA personnel select an appropriate issue from the list of issues "QA Awaiting Verification".
  2. 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.