Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

When Triage Occurs

CCB sees all tickets classified as bugs.  For CCB to see a Task, Improvement, or New Feature request, you must use the Label CCB. To see the items currently waiting for CCB, see the CCB Filter.

CCB decisions are made during weekly GMAT meetings, at scheduled CCB meetings, or when appropriate via email/electronic discussions.  Early in a release cycle, formal CCB meetings are scheduled bi-weekly, late in the release cycle CCB may occur weekly and possibly daily.  CCB meetings are based on need and not held when not needed. Decisions are marked as CCB on the ticket. 

How CCB Evaluates Tickets

When ideas are brought to CCB, they are coarsely prioritized for consideration in the next release, they may be closed as something that will never be performed given the current goals of the project, or are put in the backlog for consideration in future releases. To see the items currently waiting for CCB, see the CCB Filter.   If a ticket is denied action or is not planned for attention in the “near” future, the FixBy field is set to Someday.  If CCB decides to take action on the ticket, FixBy is set to the next release and priority is set to either P1 or P2.  P1 and P2 are defined below with representative examples.

  • P1: Fix by Next Major Release
    • High value tickets mapped to goals
    • Feature mapped to key customer need
    • Crashes with high frequency of occurrence, or a cumbersome or non-existent work-around.
    • Unmet requirement.
    • Critical numeric error
    • Unacceptably low quality in highly visible component.
    • Critical loss of data.
    • Failed input validation with critical consequence
  • P2: Fix by Next Major Release if Time Permits
    • Hard to duplicate crashes.
    • Numeric issues regarding precision (agreement with truth is acceptable but would like it to be better).
    • Numeric issues when near a singularity.
    • Unclear/non-standard error messages in low visibility component.

Triaging Many Issues

There are times when many issues (hundreds) requiring triage.  Below is our approach for triaging large quantities of issues in a timely manner.

  • Organize tickets into two lists (each sorted by component)
    • Bugs:
    • Improvements/Tasks/Other:
  • Make a First Pass
    • If a ticket almost certainly needs to be addressed mark it as P1 (i.e. we would slip a release if not completed)
    • If there is almost no way we will do a ticket or it is simply too low value mark it as Someday or consider closing it as Won't Fix.  (This helps keep backlog focused on the best ideas)
    • If neither of the first two bullets above apply mark the ticket as P2 and label as below to help in second pass
      • Polish (cleans up rough edges in existing product)
      • Incremental improvement (small change to improve existing product)
      • Bug (no need to label as this is handled in JIRA ticket type
  • Make Second Pass
    • Select a doable amount of highest value P2 issues in each area
      • Polish
      • Incremental
      • Bug
    • Move all others tickets to Someday

Who Makes Decisions

The GMAT CCB is composed of senior project members (and soon customer representatives) that ensure a broad range of expertise on the board.   Decisions are usually delegated to a subset of CCB members with expertise in the area regarding decision to be made. 

  • No labels