Jetpack/Triage Process

Bugs in the Add-on SDK component are aggressively triaged to make sure everyone can understand the importance the triage team (product manager, engineering manager, module owner and bugmaster) place on fixing the bug. The goal is transparency for the developers who file bugs and work on the SDK and developers who use the SDK and want to understand when things might be fixed.

All bugs that are filed should start with an empty priority (--) so the triage team see them at the next triage meeting and can evaluate the importance.

Triage Meeting

At least once a week the triage team will look at all unprioritised bugs and either close the bug or attempt to choose from one of the following priorities:

• P1 - Must have
• P2 - Need
• P3 - Would like to have
• P4 - Personal work, meta bugs, anything the triage team doesn't need to be concerned with

If more information is required to decide on priority the bug will be left unprioritised, [triage:followup] will be added to the whiteboard and the bug will be assigned to the SDK engineer who is in charge of finding answers to questions that the triage team have (this may involve wrangling answers from the reporter, attempting to reproduce, etc.). Once the engineer has answered the questions they may unassign themselves from the bug if they don't intend to continue and fix it at that time. Every week the triage team will re-visit the bug to see if a decision can be made about the bug's priority.

Critical Bugs

In cases where a bug is critical enough to impact the release of an SDK the target milestone will be set and an SDK engineer assigned to resolve the bug. All bugs like this will be looked at during the weekly public meeting to make sure they are progressing fast enough and to decide whether delaying the release or backing out new features will be necessary.

Serious bugs that we may consider including in a hotfix release should have [hotfix] added to the whiteboard. Some of these aren't critical enough to trigger a hotfix by themselves but may ride-along with other hotfixes or the combination of few of them may cause us to spin a hotfix. Whenever we spin a hotfix we should consider including all bugs with this tag.

Reprioritising

Over time the priority of a bug may become stale, either new information becomes available or the team's priorities shift. In this case the priority of a bug should be cleared so the triage team re-evaluate it at the next opportunity.