Skip to content

Issue Prioritization

Jump to bottom
Luigi Gentile Polese edited this page Jan 12, 2018 · 18 revisions

OpenStudio uses github issues to track both bugs and enhancement requests. Properly labeling github issues is crucial for managing and prioritizing the resolution of these issues. Please use the following labels to classify OpenStudio issues in github.

Bug Severity

All bugs should be assigned a severity describing the impact of a bug to the end users. The key here is impartiality and objectivity in judging the bug’s severity. Remember that all bugs seem urgent to you if they impact your own work or deadlines. However, personal preferences must not be a criteria for giving a bug its correct severity! The severity classification must be an impartial and a fair judgment of the impact/scope that the issue has or will have to the end user community as a whole, not you!

  • Blocker - total loss of functionality making the software unusable to the majority of the users, file corruption, severe memory leak, or any crashes. No workarounds, the software is mostly unusable.
  • Major - major loss of functionality, impacts a mainline (major) workflow or workflows (therefore impacts a large number of users), no workarounds available. Memory leaks, more or less severe. If a workaround exists or is found, then the severity of the issue must be immediately downgraded to "Normal".
  • Normal - some loss of functionality under specific circumstances or specific workflow/actions, may or may not have a workaround. State whether a workaround exists or not, and if one is found then provide details in the issue description.
  • Minor - minor loss of functionality, easy workaround may be available (provide details). This severity category also includes cosmetic issues, like misspelled words, misaligned text or icons, visually annoying issues or issues that do not affect functionality. Documentation issues should be labeled as minor severity (not to be confused with a missing documentation request - see below).

Enhancement Request

An enhancement request is used to label potential improvements to existing functionalities. Therefore, an enhancement request is not an issue, as the functionality was implemented according to the original intended design. A missing functionality which impedes a workflow must be labeled as an enhancement request and not a defect. If a feature was supposedly delivered but does not work properly according to intended functionality, then that is an issue. Since enhancement requests are not bugs, issues under this label receive less priority than actual code issues.

Documentation Request

A documentation request is used to label all issues related to missing documentation. A documentation issue related to existing documentation is treated the same as code issue (however, needs to be labeled with minor severity - see above).

Component

Each issue should be tagged with the component or components that the bug impacts or that the feature request is for. The list is not exhaustive and is subject to change:

  • Code - issue related to the core code base
  • Installer/Platform - issue related to the installer or is platform specific
  • Measures - issue is related to measures
  • OS App - issue is related to the OpenStudio application
  • PAT - issue is related to the Parametric Analysis Tool application
  • Radiance - issue is related to daylighting simulation with Radiance
  • ResultsViewer - issue is related to the ResultsViewer application
  • RunManager - issue is related to the RunManager application
  • SketchUp - issue is related to the OpenStudio SketchUp plug-in

In Progress

Apply this label when an issue has been scheduled for work in Pivotal.

Resolution

If the issue is closed but not fixed, label the final resolution and provide a note explaining the rationale.

  • Can't Reproduce - cannot reproduce the bug as reported
  • Duplicate - issue is a duplicate of another issue, add a note to the original issue
  • Won't Fix - issue will not be addressed for some reason, add a note with explanation (the affected component is to be deprecated, etc)
  • Works As Expected - the issue can be duplicated but the behavior is as designed, add a note explaining this

EnergyPlus Issue

If the issue relates to a bug or missing feature in EnergyPlus then apply this label, link to the EnergyPlus issue if it exists. If it does not exist, take specific steps to open an EnergyPlus issue.

High Demand

If an issue has been independently requested by several users then apply this label.

Low Frequency

If an issue is known to impact only a small number of users then apply the Low Frequency label.

Clone this wiki locally