Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Tip
titleJira Account

Jira and Confluence share user accounts. You can obtain an account for both by self-registering. (Note that this account is separate from your Sakai account on Collab, http://collab.sakaiproject.org, and any account you may have associated with the Sakai website, http://www.sakaiproject.org.)

Jira

Sakai uses Atlassian's Jira software for issue management. It is used to track a variety of issues, including bug reports, suggestions for new functionality, tasked work, and community contributions. Outlined below are the general practices, procedures, and definitions adopted by the Sakai community for using Jira.

Anchor
Definitions
Definitions
Definitions

Anchor
Issue Type
Issue Type
Issue Type

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/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="62382442cd99cfca-46830ffd-4b3e4e98-8ccd920e-60ada964961e7ec1fcae72cd"><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>

Anchor
Status
Status
Status

Status

Definition for Sakai

Open

Issue is under consideration.

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 testing.

Closed

Work on issue is complete and has passed testing.

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. Such an issue might become a Feature Request.

Non-Issue

Issue turned out not to be a problem with Sakai. Such an issue might result in a Feature Request or become an entry in the Sakaipedia if it is a common point of confusion.

Duplicate

Issue is a duplicate of a previously submitted issue. A link to the original 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. Perhaps it was a non-Sakai problem or it was resolved as a by-product of other work.

Anchor
Version
Version
Version

Each Jira issue has an Affects Version and a Fix Version. Generally speaking Sakai uses these values to indicate:

...

After a release is made, the interim QA release versions are merged into the last QA version number for clarity, (i.e., 2.1.0.001, 2.1.0.002, 2.1.0.003, 2.1.0.004 and 2.1.0.005 were merged into 2.1.0.006), and that version is renamed to the release version (i.e., 2.1.0).

Further notes on Version Numbers

When development work predominates on a branch – prior to a the branch entering QA – the version number to report issues against is basically a moving target. In other words, as fixes are checked into a branch, there is currently no change in the version used to refer to that branch; the SVN revision number, however, does change, so use that if you need to track that level of granuliarty. For instance, for issues encountered on the trunk branch, report the Affects Version as "Nightly/SVN-Trunk. When such issues are resolved prior to QA, the Fix Version is similarly set, which helps identify potentially transient issues that might not need full attention during QA.

Anchor
Priority
Priority
Priority

The Priority field in Jira is used by Sakai to reflect a combination of issue characteristics, including:

...

Priority

Definition for Sakai

Blocker

Release will not be completed until issue is resolved.

Critical

Issue will most likely be resolved for release.

Major

Issue should be resolved for release.

Minor

Issue may be resolved for release.

Trivial

Issues that might be resolved before a release.

Anchor
Summary
Summary
Summary

  • A brief statement summarizing the issue. (Field is limited to < 255 characters.)

Anchor
Environemnt
Environemnt
Environment

  • 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)

Anchor
Desription
Desription
Description

  • 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.

Anchor
Component
Component
Component

  • The particular part or parts of Sakai related to the issue.

Anchor
Security Level
Security Level
Security Level

  • 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).

Anchor
Workflow
Workflow
General Workflow

What happens when an issue is created in Jira? The workflow for a given issue is dependent on what type of issue it is. The sections below describe the overall path an issue of given type will follow. Guidelines are also presented for the variours groups interactig with issues, such as Designers, Developers and QA, and discuss when and how to adjust an issue's status, resolution, versions, etc.

General Workflow by Issue Types

Anchor
Bugs
Bugs
Image Modified Bugs

  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
Image Modified Tasks

  • Issue is vetted for accuracy and completeness of information.

Anchor
Feature Requests
Feature Requests
Image Modified Feature Requests

  • Issue is vetted for accuracy and completeness of information.
  • What exactly happens next is being determined as part of our ongoing development of a community 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
Requirements
Requirements
Image Modified Requirements

The requirements process is still under development. During the the first requirements gathering phase over 300 issues were submitted. A rough attempt to clump and cluster related requirements resulted in over 200 requirements put forth to the greater Sakai community and the Sakai Institutional Reprsentatives for polling on relative importance; see results.

Requirement Issues which are adopted by existing Project Management Committees or Project Teams will be handled as Feature Requests are above; coverted to one or more Tasks in the Sakai Jira project to track its implementation. For requirements which are being worked on by volunteers in collaboration with existing Project Teams, the Requirements should be converted to either one or more Tasks or a Contributed Patch, depending the level of intereaction and commitment to integration with Sakai in the desired time-frame.

Anchor
Contributed Patches
Contributed Patches
Image Modified 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 by Task

Anchor
Requirements
Requirements
Requirements/Design

The workflow for the requirements process (post Sakai 2.1 release) is being developed in the Sakai Working Group: Requirements Process.

Anchor
Designers and Developers
Designers and Developers
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, the 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).
      • After 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).
  4. For Tasks, the issue may further be Closed, if there is nothing explicit for QA to test. The succesful implementation of the new capabilities described in the Task will be exercised by QA functionality testing against the new feature set for the release.

Anchor
Quality Assurance
Quality Assurance
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. I(f in the process of verifying the issue you discover a different problem, create a new issue to capture it, rather than re-opening the current issue and re-using it.)
    • If it passes verification, then it is Closed.
    • If it fails verification, then it is Reopened.
      • Update the Affects Version to include the version failing verification.
      • 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.

Anchor
Notifications
Notifications
Notifications

Anchor
Email Summaries of Jira Filters
Email Summaries of Jira Filters
Email Summaries of Jira Filters

You can subscribe to filters in Jira and receive an email summary of the filter's contents at a time interval you specify.

For folks interested in a daily summary of updates in the Sakai project in Jira, you should subscribe to the "Updated in Last 24 Hours" filter, and specify a 24-hour or 1-day time interval. (Note that the time of day when you subscribe is the time of day when Jira will send the digest, so you probably want to subscribe to the filter early one morning.)

Anchor
On-Event Automated Notifications
On-Event Automated Notifications
On-Event Automated Notifications

Jira can also send on-event notification emails, such as whenever an issue is created, updated, resolved, closed, etc. If you are interested in receiving such emails, then please contact Peter A. Knoop