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.

If the triage team thinks that the bug should be mentioned in the release notes for the version in which it is fixed, they should add the "relnote-needed" keyword to the bug. Fixes that should be mentioned in release notes are those that change the current behavior of the SDK in a way that would surprise or confuse add-on developers (i.e. not just fixing something that is broken, but changing something to work in a different way) or those that add substantial new features that add-on developer might want to take advantage of.

Attending Triage

Anyone is welcome to attend the triage meetings to see how they are run and how the triage team make their decisions. They run most Thursdays at 11am PST in the Jetpack vidyo room. The generally aren't announced so if you're wondering if one is running check in the #jetpack IRC channel.

While anyone can attend, please understand that triaging by committee is a slow and painful process so while the triage team may ask for your input if you happen to be in the meeting and the bug at hand is relevant to you, ultimately the final decision on bug priorities rests with the triage team. Others are expected to observe for the most part and if we decide that you're interrupting us too much we may ask you to leave.

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.