Fenix Triage

Fenix Triage Captain + Feature Owner Process

Role of triage captain:

Go through every new issue that “needs triage”; ideally daily.

• Close any new issues as dupes (if known)
• Put feature labels on every issue possible + add to feature boards if it exists.
• If something doesn’t have bug label but is clearly a bug needs to have a 🐞 bug label on it (same with crash label)
• If it’s obvious that the issue needs GV, AC, etc and you feel comfortable, file a new issue with those teams to get those bugs triaged by other teams ASAP. Otherwise, just make sure it’s tagged with needs-GV, needs-AC, needs-AS, etc and the feature owner can do this.
• What to pull into group triage: ambiguous bugs, not sure which labels to put on, not sure severity
• Identify and raise only the most top priority issues - ie an insta crash to @here in #fyrefox-eng Slack channel and immediately pull into the sprint with confirmation from Product & feature owner
• Feature Requests should get correctly labeled and put into the Feature Request board (Fenix Product Backlog: https://github.com/mozilla-mobile/fenix/projects/45)

Role of Feature Owners:

• Check your labels + bug at least once a week
• Nominate top issues into the inbox so we can pull into the backlog before sprint planning
• Put your “needs:AC” tickets into the AC Top 10 for Sawyer to Triage.
• Put your “needs:gv” and “needs:gecko” tickets into the Fenix GeckoView board for Jeff to Triage.
• GeckoView tickets need a linked bugzilla ticket and ideally, a priority

Role of Product:

• Nominate issues by either pulling them into the Group Triage column of Triage board if needed or pulling tickets into the prioritized backlog to discuss at backlog grooming and sprint planning

Process

Phase 1 (Asynchronous)

This is a very quick triage, to help surface the highest severity issues. Label issues S1 if the issue is serious and impacts usage of Fenix for a large population of users. Otherwise, use the S1-not so we can re-triage it later.

Phase 2 (Asynchronous, if time)

Between group triage meetings the engineering team will take a “first pass” at the list to quickly triage all the low hanging fruit. Bubbling up items that need further cross-functional discussion to the “Group Triage” phase using the needs:group-triage label.

Phase 3 (Group Triage)

This is our regularly scheduled triage meeting. This potentially includes members of the UX, GeckoView or A-C team. We want to respect everyone’s time by only discussing the items that are bubbled up to this group.

How do we triage an issue?

During triage we want to make sure we understand every new issue that is coming in and add enough information to these issues so that we can decide which ones to work on in the next sprint. Triaging should be done from these lists:

Phase 1 - Quick Severity triage

Phase 2 - Priority triage

Is the issue a feature request?

If the feature request is a duplicate, link the original issue and close as a dup. If it is a new feature request, assign the 🌟 feature request label. This will allow PM's to then triage into the appropriate must, could, or should tag (pulled from this list).

Is the issue a bug?

We assign a priority to bugs. No priority is also valid, which means the bug is not actionable or needs to be part of a different process. We close issues that are not actionable, or are duplicates of an existing issue. We add labels to help categorize the issue. Making it easier to create smaller views into our issue list.

Labels we use

Type

We want to categorize the issue

• Crash - if the issue is a crash
• Bug - if the issue is a bug
• Feature Request - if the issue is a feature request

Feature area

We have a collection of labels prefixed with Feature:. This helps narrow down which component(s) an issue impacts.

Some examples are:

• Feature:Awesomebar
• Feature:Search
• Feature:Settings

Priorities

We four priority labels which are described as:

• P1 - Current sprint
• P2 - Upcoming release
• P3 - Some future sprint
• P5 - Never, but will accept a patch

How to decide on a priority:

Is it a crash?

• Is it high frequency? P2
• Is it low frequency or an edge case? P3

Is it a bug?

• Is the feature or product unusable because of this bug? P2
• Is this a regression found by QA? P2
• Is it an edge case? P3
• Is it something users can easily work around? P3

Severity

We have three levels to communicate how severe an issue is:

• S1 - Issue impacts usage of Fenix for a large population of users
• S2 - Issue is easily reproduced by large population but doesn’t affect usage
• S3 - Issue is an edge case
• S1-not - Issue is not an S1, and should be re-triaged later

Contributors

If a bug seems like an issue that would be good for a first time contributor to pick up, please add the good first issue label. If you think it'd be solid for a contributor in general, add the help wanted label.

Handing a bug over to other teams

If a bug is not actionable before another team has looked at it, add one of the following labels AND @mention an appropriate person to triage for their team:

• needs:ac
• needs:eng
• needs:as
• needs:qa
• needs:str
• needs:ux
• needs:review
• needs:sumo
• needs:strings
• needs:product
• needs:feature-triage
• needs:group-triage