Issue Prioritization

Properly labeling github issues helps everyone understand which issues are most important. Please use the following labels to classify OpenStudio issues in github. Issues should be assigned to milestones for tracking. Issues should be added to Pivotal when they are scheduled for work.

Severity

Describes the impact of a bug to the end user, i.e. how severe it is to an existing user or a user that has not experienced it yet but it may. The severity can be a number (1 being the most severe, 5 the least) or a word, like Bugzilla does. See below. The key here is impartiality and objectivity in judging the bug’s severity. Personal preferences are not a criteria for giving a bug a severity!

• Blocker (1) - Blocks development and/or testing work, crashes, major loss of data
• Major (2) - major loss of functionality
• Normal (3) - regular issue, some loss of functionality under specific circumstances
• Minor (4) - minor loss of function, or other problem where easy workaround is present

Priority

Describes the importance and order in which a bug should be fixed. This field is utilized by the project manager/release planner to prioritize the work to be done. The available priorities range from 1 (high priority) to 3 (low priority). When users report an issue the priority of that issue should be raised as we know this issue is impacting people.

• High (1) - stop all other work to fix this issue
• Normal (2) - this issue has same priority as other new work
• Low (3) - this issue has lower priority than other new work

Other Labels

• comp - the components that this issue impacts (e.g. SketchUp plug-in, OS App, Measures, etc)
• pivotal - apply this label when an issue is scheduled for work in Pivotal
• res - if the issue is closed but not fixed label the final resolution (e.g. duplicate, invalid, won't fix)