This page is reminders and guidelines on the way we use JIRA for Daffodil.

First off, we use JIRA for the Daffodil primary libraries only, and it's related build infrastructure and documentation.

Other efforts under the Daffodil umbrella, including the Apache Daffodil Extension for VSCode, use github's trackers associated with those repositories. 

Priority 

By default, the issue tickets are assigned a priority of "Major". (Note that this is not a JIRA setting we can change.)

When creating a ticket this should be scrutinized somewhat carefully before just accepting the default. Guidelines for choosing the priority are given below. 

Note that new features and improvements are treated differently from bugs, and priority "Minor" does not mean that the issue will not be addressed. 

JIRA does not offer a separate severity ranking of tickets so the severity of an issue is captured by some blend of the concepts of priority and the choice of assignment of a "fix release" to the issue (or leaving this fix release unspecified.)

Bug Priorities

Blocker

JIRA's definition: Blocks development and/or testing work, production could not run

Also apply for: A safety-critical issue or regulatory violation. 

Notes: A blocker issue generally means not just creation of a release being blocked until it is fixed, but most likely suggests a patch release is needed. 

Critical

JIRA's definition: Crashes, loss of data/data corruption, severe memory leak.

Also apply for: Project deliverable/product is effectively inoperable, with no known workaround, or when the event/defect must be corrected by a specific deadline.

A critical issue will often result in a Field Notice (email to users/dev) about the issue to raise awareness.  

Major

JIRA's definition: (Default) Major loss of function

Also apply for: Project deliverable/product may become inoperable or severely degraded but is usable with a workaround.

Goal: Major (and higher priority) issues should either (1) be fixed in the next release or (2) be mentioned in a release note

Notes/Examples: an abort (with backtrace) is almost always a major issue. A poor quality diagnostic which provides no guidance or suggestion related to the problem is also a major bug. 

A diagnostic message which is at least about the right subject in the data/schema, but could be better is either a Minor/Trivial bug, or more likely is an Improvement request ticket, not a Bug. 

Minor

JIRA's definition:  Minor loss of function, or other problem where easy workaround is present.    

Also apply for: Project deliverable/product is fully operable, but deviates from required operation or user-friendly control sequences.

Trivial

JIRA's definition: Cosmetic problem like misspelt words or misaligned text.

Feature and Improvement Priorities

Use of priority for new features and improvements is different, it is about the priority of the improvement or feature for inclusion in a release.

Improvements are not necessarily user-visible. Code cleanups, reducing technical debt buildup, and infrastructure changes are all improvements and can be important to the definition of a release. 

This is all a function of the roadmap for the releases, and the goals of the community of Daffodil users and developers. 

PriorityDescription
Blocker

A primary theme and purpose of the release is to provide this feature/improvement.

Without the feature/improvement the value of the release, over the prior release, is minimal. 

Critical

While not primary/thematic, this feature/improvement is also important to the purpose of the release. 

Major

An important feature/improvement that should be targeted to the release, but is not thematic or a central part of the definition of the release. 

Without the feature/improvement the value of the release is decreased substantially. 

MinorA less consequential feature/improvement that should eventually be provided, but does not affect the value of the release in a major way. 
TrivialImprovements that are worth fixing, but in which release is less important. 
  • No labels