Firefox OS/Performance/Triage

Schedule

• Triage: Wednesdays from 11am - 12pm PT
• Vidyo: FxOS_Performance
• IRC: irc://irc.mozilla.org:6697/#fxos-perf

Queries

Blockers

• Queries
  • 2.0?
  • 2.0+
  • 1.4?
  • 1.4+

• Query Criteria:
  • Open Bugs
  • Products: Boot2Gecko Graveyard, Core, Firefox OS, Tech Evangelism, Testing, Toolkit
  • B2G blocking as labeled
  • Keywords: perf, mlk, footprint OR in the FxOS Performance component

• Triage Actions:
  • Ensure bugs have assignees, appropriate needinfos, or otherwise move forward
  • Add or modify Scrumbugs tags as needed. Use u=<release>, e.g. u=2.0

• Conventions
  • ...? = blocker nominations = bugs nominated as something that should block that release.
  • ...+ = blockers = bugs accepted as being a release blocker.
  • Blocking criteria can be found at: https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines
  • Additional blocking criteria for regressions.
    • Less than 50ms regression, not auto nom.
    • Between 50ms - 100ms regression, use your own discretion.
    • Greater than 100ms, auto nom.

New Candidates

• Query:
  • New Candidates (Untagged)

• Query Criteria:
  • Open Bugs
  • Product: Firefox OS
  • Not reviewed or tagged for Scrumbugs
  • Perf issue according to one of following
    • Summary containing delay, perf, slow, sluggish
    • Keyword containing mlk, perf, footprint
    • In the FxOS Performance component

• Triage Actions
  • Sort by ascending bug ID
  • Add perf keyword and Scrumbugs tags for all FxOS Performance issues.
  • Add perf-reviewed whiteboard for bugs that are not FxOS Performance issues.
  • Non-performance issues in the Firefox OS | Performance component should be moved elsewhere.

Unprioritized Backlog

• Query:
  • Unprioritized Backlog (All Open)

• Query Criteria:
  • Open Bugs
  • Products: Boot2Gecko Graveyard, Core, Datazilla, Developer Engagement, Firefox OS, Marketplace, Powertool, Tech Evangelism, Testing
  • Not prioritized
  • Has Scrumbugs tags
  • Keyword containing mlk, perf, footprint

• Triage Actions:
  • Set Priority for all bugs covered in each triage session.
  • Match [MemShrink:P?] priority when set unless bug is a release blocker.
  • Close bugs that no longer reproduce or that no longer match product requirements.
  • Identify blockers and relevancy.

Keywords

footprint

Add to bugs regarding memory footprint performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.

mlk

Add to bugs regarding memory leak/out-of-memory (OOM) performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.

perf

Add to bugs covering regarding all types of performance or performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.

regression

Add to bugs where a regression has occurred; previously working functionality has been broken or performance goal is no longer being met.

regressionwindow-wanted

Add to bugs where the commit that caused the regression needs to be identified.

qawanted

Add to bugs where performance needs to be verified (or re-verified) by QA. Specific instructions should always accompany this keyword.

This list is not comprehensive, and only includes keywords used very frequently by the FxOS Performance team during triage. For the full list of keywords and their descriptions see: https://bugzilla.mozilla.org/describekeywords.cgi

Whiteboard Entries

[perf-reviewed]

Add to bugs that appear in an Untagged triage but should not be tracked by the FxOS Performance team. Excludes from future triages.

[MemShrink]

Add to bugs that should be looked at by the MemShrink team responsible for maintaining efficient memory usage on FxOS.

This list is not comprehensive, and only includes whiteboard entries used very frequently by the FxOS Performance team during triage.

Prioritization

Prioritization of tasks is defined on a scale of decreasing priority from P1 to P5.

[P1]

Any bug that is designated a blocker. Can also be used on tasks that we deem critical for our team to complete.

[P2]

Bugs that are deemed important to solve but are not classified as blockers. Can also be used for critical engineering research tasks.

[P3]

Lower priority bugs. Can also be used for common engineering research tasks.

[P4]

Engineering research tasks for open schedules or down-time.

[P5]

Dated bugs that have not been followed up on recently.

Scrumbugs Tags

Scrumbugs tags are added to the Whiteboard field in Bugzilla, but are actually directives to Scrumbugs for how to organize the bugs within sprints and backlogs.

The tags follow the format:

[c=<component> p=<points> s=<sprint> u=<milestone>]

Brackets are optional, but will help keep the tags from being accidentally mixed up with other whiteboard entries and not parsed by Scrumbugs. Spacing is significant; no spaces should be on either side of the equals. Order is not significant.

Tags may appear but be left empty, e.g. [c= p= s= u=]. This will be sufficient to direct Scrumbugs to track the bug. Other valid values for tags are explained below.

Not all tags must appear, but our queries expect that any bug tracked by the FxOS Performance team will have the Component tag at minimum.

More information about Scrumbugs can be found on the Scrumbugs Help Page. Examples may be found on the FxOS Performance team's Scrumbugs page.

c= Component

The FxOS Performance team is generally less concerned about what module of code a bug affects (the Bugzilla component) than what kind of performance the bug impacts. Components are typically overridden via the Component tag to refer to particular user stories representing broad performance targets.

(no value)

use the component from Bugzilla

automation

Automation-related

benchmark

Performance Benchmarks

boot

Boot Sequence (boot-2-homescreen)

cpu

Excessive CPU usage

devtools

Development Tools

documentation

Documentation

effect

Perception of cause & effect

handeye

Hand-Eye coordination

hardware

Hardware interfacing performance issues.

memory

Memory leaks or footprint.

power

Power Management

profiling

Profiling tools

progress

Perception of progress

regression

Broken functionality that previously worked

startup

Start up time optimizations

uniformity

Frame Uniformity

graphics

Uncategorized graphics issue

More information may be found at Firefox OS/Performance/UserStories.

p= Points

Point values are estimates of effort ranging from 1 to 5 set during Sprint Planning. They can be adjusted during a sprint cycle as their related issues become better understood. Point values are not usually set during triage.

Points	Meaning
(no value)	Unestimated
1	Clearly understood and trivial.
2	Clearly understood and non-complex.
3	Average, requiring investigation but not significant effort.
4	Difficult, requiring non-trivial investigation and implementation expected to take half or more of a sprint.
5	Very difficult, requiring significant investigation and implementation requiring an entire sprint.

Issues requiring more time than a sprint cycle must be broken into smaller issues that can each be accomplished within a sprint.

s= Sprint

The Sprint tag is used to direct Scrumbugs to include the bug into a particular sprint.

The value of this tag, if set, refers to the name of a Scrumbugs sprint. FxOS Performance team sprints follow a date format YYYY.MM.DD, where the date refers to the day the sprint ends in the Pacific Time timezone.

If the tag is included with an unset value, it has no effect.

This tag should not be used with a set value on open bugs, as it interferes with Scrumbugs' ability to migrate the bug from one sprint to the next when necessary. Once specified this way, the bug will always need to be manually managed within Scrumbugs, even if the tag is subsequently removed.

A value should only be set for this tag to insert an otherwise untracked bug into the current sprint after the bug has already been resolved.

u= Milestone

The Milestone tag is actually a repurposing of the Scrumbugs User tag. For the purposes of the FxOS Performance team, it is used to indicate the FxOS Release(s) and/or Device(s) for which the bug is targeted (e.g., 1.2, 1.3, tarako, etc.)

The value, if set, will be reflected in the User column of Scrumbugs. If the value is unset, the tag has no effect and the column will remain empty.

Cc

To Cc (Carbon Copy) the perf team in Bugzilla, use perf@fxos-perf.bugs as the address. People interested just need to watch that user in bugzilla. Don't Cc the team list.