Firefox OS/Performance/Triage: Difference between revisions
Line 18: | Line 18: | ||
** [http://mzl.la/1kcvnhX 1.3?] | ** [http://mzl.la/1kcvnhX 1.3?] | ||
** [http://mzl.la/IP2FbM 1.3+] | ** [http://mzl.la/IP2FbM 1.3+] | ||
** [http://mzl.la/1hgZzua 1.4?] | |||
** [http://mzl.la/ODfM2U 1.4+] | ** [http://mzl.la/ODfM2U 1.4+] | ||
Revision as of 19:05, 26 February 2014
Schedule
- Triage: Wednesdays from 11am - 12pm PT
- Vidyo: FxOS_Performance
- IRC: irc://irc.mozilla.org:6697/#fxos-perf
Queries
Blockers
- 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#Release_Triage
- Queries
Candidates
- Untagged
- Add perf keyword and Scrumbugs tags for all FxOS Performance issues.
- Add perf-reviewed whiteboard for bugs that are not FxOS Performance issues.
- Sort by ascending bug ID
Backlog
- All Open
- Sort by ascending bug ID
- Set Priority for all bugs covered in each triage session.
- Close bugs that no longer reproduce or that no longer match product requirements.
- Identify blockers and relevancy.
- Update the "greater than" bug number in the triage URL to exclude previously triaged bugs ("v1=######")
Keywords
- perf
- Add to bugs regarding 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.
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
- effect
- Perception of cause & effect
- handeye
- Hand-Eye coordination
- power
- Power Management
- progress
- Perception of progress
More information may be found at Firefox OS/Performance/UserStories.
p= Points
Point values are estimates of effort, ranging from 1 to 5. They are typically set during planning, and often left empty when set during triage.
Roughly speaking, point values have meaning as follows:
Points | Meaning |
---|---|
(no value) | Unestimated |
1 | <tbd> |
2 | <tbd> |
3 | <tbd> |
4 | Half of a sprint |
5 | A full sprint or more |
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 version for which the bug is targeted (e.g., 1.2, 1.3, 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.