|Release target||Firefox 7|
|Status note||Deployed, see arewesnappyyet.com|
|Product manager||Chris Blizzard|
|Directly Responsible Individual||Taras Glek|
|Lead engineer||Taras Glek|
|Security lead||Curtis Koenig|
|Privacy lead||Sid Stamm, Asa Dotzler|
|UX lead||Alex Limi|
|Product marketing lead||`|
|Additional members||Daniel Einspanjer (metrics), Graydon Hoare, Rob Sayre|
Stage 1: Definition
1. Feature overview
Telemetry allows Engineering to receive aggregate data of browser health in the field. Think cache hit rates, page load times across all browser instances or anything else we're interested in.
The goal for this feature is to give our developers the ability to know if changes they are making have wide-ranging positive and negative effects at scale. Are users seeing better performance?
Another goal of this is to give us easy-to-use infrastructure to learn about the structure of the Internet as a whole. That is, how do we tune our browser based on what the Internet and Web do?
2. Users & use cases
- Add UI (Mike Hommey)
See https://bugzilla.mozilla.org/show_bug.cgi?id=659396 for ongoing telemetry enhancements.
This is not a system for gathering feedback from individual users. It is a system for us to get aggregate health data about browsers in the field. It's also a chance for us to run lightweight tests if we want to learn how certain settings will affect browser performance or user experience. It is distinct from the Test Pilot program.
Stage 2: Design
5. Functional specification
6. User experience design
Stage 3: Planning
7. Implementation plan
Quality Assurance review
Stage 4: Development
Need: Services plan, deployment plan, early items to measure.
Stage 5: Release
10. Landing criteria
|Theme / Goal||`|
|Engineering team||Automation and Tools|
Team status notes
|Quality assurance||Signed off for release||`|