|
|
| (75 intermediate revisions by 15 users not shown) |
| Line 1: |
Line 1: |
| = Go Faster = | | = Overview = |
| Go Faster is a plan to change the way we ship Firefox for Desktop, and potentially other products. The end goal is to reduce the time it takes to deliver value to the user. This focuses on getting features and fixes to the user on a reduced cycle time, but includes reductions in time to download updates and new versions, and reductions in build and release time. | | We believe that building out tools and processes for shipping Go Faster add-ons will enable Mozilla's engineers to get features and fixes to a larger audience sooner. We will know this is true when we see widespread adoption of system add-ons as a mechanism for moving faster and updating faster than the standard trains. |
|
| |
|
| | ==Team== |
| | {| class="wikitable" |
| | |- |
| | ! Name !! Role |
| | |- |
| | | Laura Thomson || Product Owner |
| | |- |
| | | Rehan Dalal || Program Management |
| | |- |
| | | Robert Helmer || Technical Lead |
| | |} |
|
| |
|
| ==Meetings & Communications== | | ==KPI's== |
| <p> TBD </p>
| | * Number of projects using the tools. |
| | * All new features or improvements to existing features validated by go faster by the end 2016. |
|
| |
|
| =Development= | | ==Meetings== |
| <p> </p>
| | * [[Firefox/Go_Faster/Meetings|Meeting Notes]] |
| ==Schedule==
| | * Bi-Weekly Team Meeting |
| *[https://wiki.mozilla.org/Release_Management/TeamWiki Firefox main release schedule] is the master location for the dates when each Firefox version goes to Aurora, Beta, & Release. | | ** Every other Tuesday at 11:30 AM PST ([https://www.timeanddate.com/worldclock/converted.html?iso=20151124T0930&p1=224&p2=250&p3=0&p4=195 conversions]) |
| '''Firefox 41 Release'''
| | ** "GoFaster" Vidyo Room (extension 8557) |
| * '''Iteration 41.2:''' Tuesday May 26 - Monday June 8 | |
| * '''Iteration 41.3:''' Tuesday June 9 - Monday June 29 | |
| ** ''Note: IT 41.3 is a 3-week iteration.''
| |
| <p> </p>
| |
| '''Firefox 42 Release'''
| |
| * '''Iteration 42.1:''' Tuesday June 30 - Monday July 13
| |
| * '''Iteration 42.2:''' Tuesday July 14 - Monday July 27 | |
| * '''Iteration 42.3:''' Tuesday July 28 - Monday August 10 | |
| <p> </p>
| |
|
| |
|
| ==Themes== | | ==Communications== |
| As we plan what's coming next, we're focused on the themes outlined here. This is not a commitment to the next projects - just our scratch area, but it is in order of relative priority.
| | * [https://mail.mozilla.org/listinfo/gofaster Mailing List] (open to all, primarily used for sharing status) |
| *'''Ship features with service integrations as Add-ons:''' Decouple feature development of service integration features from 6 week Firefox software release train | | * IRC: #gofaster |
| *'''Ship Localizations Separately From Product:''' Have the installer or updater pull a langpack from AMO during the install or update process, and decouple langpack builds from our releases.
| |
| *'''Ship data separately from code:''' Pull data out and make it a separate download (transparent to the user) via the installer or updater.
| |
|
| |
|
| <p>
| | = Release Process and Mechanics = |
|
| |
|
| == Project 1: Ship features as system add-ons == | | == Process == |
|
| |
|
| Component: Addons manager in Firefox
| | Have something you want to ship through Go Faster? |
| Owner: Addons team (under Dave Camp, new team being formed - check with Dave for who)
| |
| Tasks:
| |
|
| |
|
| Make Firefox understand what a system add-on is
| | Start here: |
| | * [[Firefox/Go_Faster/System_Add-ons/Process]] |
|
| |
|
| How to install one
| | == Mechanics == |
|
| |
|
| How it should be signed
| | This page details the technological pieces involved in shipping system add-ons. |
|
| |
|
| Where it should be updated from
| | [[Firefox/Go_Faster/Releasing_an_add-on_mechanics|Releasing mechanics]]. |
|
| |
|
| That it can't be uninstalled, only disabled
| | The initial authors of this process are |
|
| |
|
| That it should be available across all profiles
| | {| class="wikitable" |
| | |- |
| | ! Name !! Role |
| | |- |
| | | needs:owner || Owner |
| | |- |
| | | Mark Banner || Hello/docs |
| | |- |
| | | Ian Bicking || Hello/docs |
| | |- |
| | | Rob Helmer || Client |
| | |- |
| | | Dave Townsend || Client |
| | |- |
| | | Ben Hearsum || Tools |
| | |- |
| | | Ritu Kothari || Tools |
| | |- |
| | | Lonnen || Tools |
| | |- |
| | | Axel Hecht || l10n |
| | |} |
|
| |
|
| Work with add-on updater team to figure out where to install these from.
| | = Projects = |
|
| |
|
| | These are the top-level projects defined for this program. |
|
| |
|
| Component: Updater in Firefox
| | == Morgoth == |
| Owner: Rob Strong? / Addons team? Check with dcamp for who
| |
| Tasks: Change the updater:
| |
|
| |
|
| Update system add-ons
| | [[Firefox/Morgoth|Morgoth]] |
|
| |
|
| Check compatibility/dependencies
| | * Project Owner: Benson Wong [:mostlygeek] |
|
| |
|
| Check signed appropriately
| | == Kinto == |
|
| |
|
| Update data files
| | A JSON storage service with synchronisation and sharing ability - allows the smart client to retrieve signed data from a dumb server. |
|
| |
|
| Separate the updater from the Firefox binary
| | <big>'''Team'''</big> |
| | {| class="wikitable" |
| | |- |
| | ! Name !! Role |
| | |- |
| | | Tarek Ziade || Owner |
| | |- |
| | | Mark Goodwin || OneCRL client, PKI work for the signing |
| | |- |
| | | Sebastian || Fennec Client |
| | |- |
| | | Jorge || our customer for the AMO blocklist |
| | |} |
|
| |
|
| | <big>'''Resources'''</big> |
| | * Tracking document: https://docs.google.com/document/d/1MHQNqJ--GAmNxXl2PODJ-YGU459l6vvDRmf9oEIRTms/edit |
| | * Tool: http://kinto.readthedocs.org |
|
| |
|
| Component: Services system add-on updater
| | == Recipe Server (SHIELD + Variants) == |
| Owner: ? - Potentially Les Orchard or Selena Deckelmann
| | A system that provides a fast and powerful way for Firefox to fix configuration problems, interact with users, and recommend features. |
| Tasks:
| |
|
| |
|
| Figure out if we want to serve system addons from AMO, from Balrog, or from somewhere else
| | <big>'''Team'''</big> |
| | {| class="wikitable" |
| | |- |
| | ! Name !! Role |
| | |- |
| | | Gregg Lind || Owner |
| | |- |
| | | Matt Grimes || Product Manager |
| | |- |
| | | Mike Kelly || Engineering Manager |
| | |} |
|
| |
|
| Build that.
| | <big>'''Resources'''</big> |
| | * [[Firefox/Recipe_Server|Recipe Server]] |
|
| |
|
| | == Test Pilot == |
| | A system that provides a fast and powerful way for Firefox to fix configuration problems, interact with users, and recommend features. |
|
| |
|
| Component: Build, release, QA pipeline
| | <big>'''Team'''</big> |
| Team: Selena Deckelmann for releng, Krupa Raj and Matt Brandt from WebQA, someone from desktop QA
| | {| class="wikitable" |
| Tasks:
| | |- |
| | ! Name !! Role |
| | |- |
| | | Javaun Moradi || Owner |
| | |- |
| | | Cory Price || Program Management |
| | |- |
| | | Wil Clouser || Engineering Manager |
| | |- |
| | | John Gruen || UX Lead |
| | |} |
|
| |
|
| Design a build and release pipeline for system add-ons (using existing tools) (Selena)
| | <big>'''Resources'''</big> |
| | * [[Test_Pilot|Test Pilot]] |
|
| |
|
| Decide/design the role of QA in CD for Firefox (QA teams)
| | = Shipping Pipeline = |
| | [https://docs.google.com/spreadsheets/d/1yOgiOTU8q2I709VFhjCYCLATmoyQueV8RttPzciFIkQ/edit Shipping Pipeline Spreadsheet] |
|
| |
|
| | The `how` for Go Faster are the top-level projects outlined above. The other important things to track are the individual features and fixes that are going to be launching ''through'' Go Faster. |
|
| |
|
| Component: l10n for systems addons
| | View the doc for a list of System Add-ons in flight. |
| Team: Pascal Chevrel? (haven't talked to him yet), Michael Kelly
| |
| Tasks:
| |
| | |
| Design and build a process for localizing system add-ons
| |
| | |
| | |
| Component: Hello as add-on
| |
| Owner: Adam Roach (WebRTC) + Mark Banner (Client Hello team)
| |
| Tasks:
| |
| | |
| Implement Hello as a system add-on
| |
| | |
| Create a migration path from Hello in product to Hello as system add-on
| |
| | |
| Dependencies:
| |
| | |
| Updater changes, build pipeline?
| |
| | |
| | |
| == Project 1a: Ship experiment features as add-ons from IdeaLab ==
| |
| | |
| Component: Universal Search as IdeaLab add-on
| |
| Owner: Jared Hirsch/Nick Chapman
| |
| Tasks:
| |
| | |
| Implement Universal Search as an experimental add-on (this can be served/updated from AMO or similar) (Jared/Les)
| |
| | |
| Implement first iteration of Firefox IdeaLab website (Nick Chapman/John Gruen)
| |
| | |
| Design and implement process for IdeaLab experiments
| |
| | |
| Dependencies:
| |
| | |
| None.
| |
| | |
| | |
| == Project 2: Pull data out of products and serve and update it separately ==
| |
| | |
| Tech lead/architect: Tarek Ziade
| |
| | |
| Component: Services data updater
| |
| Owner: French team (Tarek)
| |
| Tasks:
| |
| | |
| Serve updates to security policy
| |
| | |
| Serve datafiles for Fennec (dictionaries and fonts)
| |
| | |
| Dependencies:
| |
| | |
| Client updater changes (in project 1, above)
| |
| | |
| | |
| == Project 3: decouple l10n from product ==
| |
| I'm suggesting we do the other two things first, and plan on picking this up in q4 for resource contention reasons, but I may be persuaded otherwise.
| |
| | |
| Component: Build process
| |
| Owner: Chris AtLee / RelEng / RelMan
| |
| Tasks:
| |
| | |
| Remove l10n repacks from the release critical path
| |
| | |
| Work out how to add additional strings to locale packs
| |
| | |
| Automate uploading locale packs to AMO
| |
| | |
| Dependencies:
| |
| | |
| Installer/updater changes
| |
| | |
| | |
| Component: Installer/updater
| |
| Owner: Rob Strong or Add-ons team
| |
| Tasks:
| |
| | |
| Build stub installers for Windows and Linux
| |
| | |
| Change installer to pull locale pack from AMO as a separate download
| |
| | |
| Figure out how locale updates need to work
| |
| | |
| | |
| </p>
| |
| Things we want to do - but not starting until higher priorities are done:
| |
| *TBD - add as things come up
| |
| <p></p>
| |
| Other common Themes that will be mixed in the backlog as they come up:
| |
| *'''UX:''' this tag is less a theme - more a marker so UX knows we need something from them on that bug- it often lives with other Themes and the UX comes off when we get the info. Unless it's a unique UX bug - then UX stays.
| |
| *'''error:''' bug we've seen come in that we prioritize along side Theme work - often not Theme specific.
| |
| *'''tech-debt:''' work to make development smoother (test harness, dev tools, documentation, etc.)
| |
| *'''metrics:''' work specific to improving visibility into the product - but not required for a feature
| |
| *'''investigation''' or '''watch:''' needs investigation or just watching to see if it's reproducible and get an idea of the impact / cause.
| |
| <p></p>
| |
| At this point we are wrapping up other project work, risk is that it will carry over beyond 40.3. Need to clarify/set expectations for Search Suggestion timelines/features.
| |
| <p> </p>
| |
| | |
| ==Current==
| |
| ===Iteration - 41.2, through June 8===
| |
| User Story this iteration:
| |
| | |
| '''Details'''
| |
| *
| |
| | |
| <p> </p>
| |
| | |
| =Product Backlog=
| |
| Work related to the ongoing development of Go Faster are collected and prioritized in the Product Backlog. The goals of the Product Backlog are to:
| |
| * Improve work prioritization, so the team is always working on the most important features.
| |
| * Simplify continual planning, so the plan matches reality.
| |
| * Improve visibility so that the stakeholders make the best decisions about the direction of the product (call out risks early, relative priorities, trade-offs)
| |
| <p> </p>
| |
| <p> </p>
| |
| | |
| ==Triage Guidelines==
| |
| The Product Backlog is continually maintained by the Go Faster team to ensure new priorities are available for each Sprint Planning meeting.
| |
| * '''Priorities''' follow this Standard:
| |
| ** Priority 1 - Blocker, must-fix before shipping.
| |
| ** Priority 2 - Major impact, considering severity × probability. Not a blocker for shipping.
| |
| ** Priority 3 - Average Bug. definitely a problem, but doesn't stop someone from using the product.
| |
| ** Priority 4 - Minor or polish bugs that are real issues (especially in aggregate) and annoying.
| |
| ** Priority 5 - Low-impact. something we'd fix, but mostly only bothers the discerning user. Little impact on usability.
| |
| <p> </p>
| |
| *'''RANK''': As priority buckets start to have a large amount of bugs in them, the Rank field can be used to call attention to higher or lower rank and provide a way to sort easily in bugzilla. To have some rhyme/reason to the order - Rank should relate to Priority. The "Ranking" number does not need to be unique. Unless there is a reason to for a bug to be considered before (or after) others in the Priority bucket - default to mid-range value.
| |
| ** P1 Rank options=1-19, default 15
| |
| ** P2 Rank options=20-29, default 25
| |
| ** P3 Rank options=30-39, default 35
| |
| ** P4 Rank options=40-49, default 45
| |
| ** P5 Rank options=50-59, default 55
| |
| ** any that we don't think we can get to in the next 6 months should go in "backlog-" area
| |
| <p> </p>
| |
| *The '''Firefox-backlog''' flag is used to track bugs that are approved for the Backlog "+" (or Backlog - to not be looked at for a while)
| |
| *Add '''whiteboard''' tag to bugs [fxsearch] as bugs for this team may span Product:: Component areas.
| |
| *'''QE-Verify''' is a flag that developers should be setting on bugs they are working on. This is used for QE to filter which bugs they check
| |
| **"+" means that QE should look at the bug and it can be verified with human eyes
| |
| **"-" means QE should not look at
| |
| ***Typically goes with in-testsuite set to "+", to show testing via another method.
| |
| *'''Points''' should be set when known.
| |
| *'''Iteration''' should be updated when a bug is being worked on during a particular Iteration.
| |
| <p> </p>
| |
| | |
| ==Filing a bug==
| |
| ** Open a bug under Product:"___" || Component: "___" or "_____"
| |
| ** Team reviews for inclusion in Backlog every 2 weeks
| |
| *If there is a bug that should be considered for taking ASAP - you can mark "firefox-backlog"+ and set a Priority with a reason. This makes it simplest to triage those bugs quickly.
| |
| **Before it can be given a Rank it should:
| |
| *** be in an actionable state (for the team taking it)
| |
| *** for defects, the problem is ready for Engineering or UX: diagnosis, measurement, design, or fixing
| |
| *** for feature requests or enhancements, it means that there's a clear problem statement or suggestion
| |
| <p> </p>
| |
| | |
| =Project Health=
| |
| Include clear, executive level summary that will be included at the [[https://mana.mozilla.org/wiki/display/PM/Firefox+Program mana page overall view level]:
| |
| *for company goal x, we are in _____ state because ______. Please consider ______(propose fix or adjustment of goal).
| |
| *for release goal for ______ , we are in _____ state because ______. Please consider ______(propose fix or adjustment of goal).
| |
| | |
| ==Project Introduction==
| |
| * '''Team Mailing list:''' if applicable
| |
| * '''Team IRC Channel:''' where does this team "hang-out"
| |
| *[https://wiki.mozilla.org/Firefox/IterativeDevelopment Summary of our plans for this year]
| |
| **links back to main Firefox page - Marco to create a section on main page for team summaries.
| |
| **Quick high-level plans for the year for Desktop management and contributors.
| |
| ***Here's an example of the overview from [https://wiki.mozilla.org/Platform/Roadmap#WebRTC_.2F_WebAudio Platform team for webRTC]
| |
| * '''Dependencies:''' feature, partner, resource, etc. that impact this projects ability to succeed - put links to other project pages.
| |
| | |
| ==Links to Current info==
| |
| The [https://wiki.mozilla.org/Firefox/Go_Faster/links Links wiki page] is the central location for current focus, Roadmap, Metrics, UX, Marketing, tech-architecture, and more.
| |
| | |
| ==Roles and Responsibilities==
| |
| The [https://wiki.mozilla.org/Firefox/Contacts Contacts Page] has the Roles and Responsibilities for Firefox teams, partner teams, and external partners.
| |