Firefox/SHIELD/DevelopmentPlan

From MozillaWiki
Jump to: navigation, search

Terminology

Action
A semantic thing that can be done by the browser, like "Display a survey" or "Highlight this menu item". Actions may be paired with executable code for self-repair, but other services may read the actions and implement them differently. Actions can be configured with arguments in the form of a JSON object.
Recipe
A set of eligibility rules determining who the recipe is sent to, and the action/arguments to execute if those rules match. For example, a recipe may check to see if a preference is set to a known-bad value, and offer to reset it for the user.
Eligibility Rule
A rule describing who a recipe should be sent to. For example, a survey may only be relevant to users in India, so the eligibility rules for that survey recipe will limit it to users located in India only. Other filters available include locale, sampling rate, and start/end dates.
Bundle
A bundle is a collection of recipes that are sent to Firefox. Bundles are built based on eligibility rules.

Phase 1

Summary

Phase 1 will consist of writing a server to replace the current statically-generated self-repair scripts. The server will be capable of sampling, timed releases of recipes, localized recipes, and geolocation.

Requirements

  1. Serve bundles of recipes to all Firefox instances, once per day, filtered by eligibility rules.
  2. Present webpage for creating and managing recipes and the rules determining who sees them.
  3. Control rollout of recipes with composable rules:
    • Distribute recipe starting on X date/time and/or ending on Y date/time.
    • Distribute recipe to X% of users.
    • Distribute recipe to users in a particular country.
    • Distribute recipe to users based on the locale of Firefox (Ex: ru, de, en-GB).
    • Distribute recipe to users on a specific release channel (including non-standard channels like funnelcake).
  4. Expose debugging view for previewing the set of recipes being sent to a specific browser/location configuration.

Measuring success

Without much of an existing system to measure against, our main success metric is shipping a survey via the Recipe Server that is restricted to a specific country via geolocation.

Bugs

Full Query
ID Summary Priority Status
1240962 Add CI for running tests on commit and on PR -- RESOLVED
1240965 Create recipe API endpoint -- RESOLVED
1240966 Create self-repair-compatible endpoint -- RESOLVED
1240968 Create API endpoint for submitting action implementations -- RESOLVED
1240969 Replace bundler with static storage -- RESOLVED
1240973 Create temporary dev server on Heroku -- RESOLVED
1240974 Add debugging view to see what recipes a given client will receive -- RESOLVED
1241973 Change LocaleFields into FKs into a locale table controlled by product_details -- RESOLVED
1243913 Make all S3 settings optional -- RESOLVED
1243916 Add setting to disable admin interface and views -- RESOLVED
1248263 Allow filtering by multiple countries and locales for a single recipe -- RESOLVED
1248264 User-friendly arguments editor for actions -- RESOLVED
1248265 Filter by release channel -- RESOLVED
1248327 Implement heartbeat action -- RESOLVED
1248668 Admin interface / Action API only available behind VPN -- RESOLVED
1249498 Fetch UUIDs from users properly -- RESOLVED
1251466 Add health check endpoint -- RESOLVED
1252643 Update product details on a regular basis on the dev server -- RESOLVED
1252696 [traceback] Locale matcher doesn't account for None locales -- RESOLVED
1253716 Hash functions for sampling should use action argument as salt -- RESOLVED
1253717 Keep history of changes to Actions / Recipes -- RESOLVED
1253722 Cloning recipes -- RESOLVED
1257007 Use DJANGO_CDN_URL in normandy for actions -- RESOLVED
1257263 Only have one action per recipe -- RESOLVED
1257658 Fetch bundle and self repair endpoints should make no DB queries in the common case -- RESOLVED
1257660 Include action implementation hash in implementation url -- RESOLVED
1259556 Sample rates smaller than 1% in Shield -- RESOLVED
1260581 Send the version and release channel in the self repair driver -- RESOLVED
1262617 Viewing a recipe revision creates a new revision -- RESOLVED
1262620 Geolocation on normandy.dev.mozaws.net doesn't work -- RESOLVED
1262889 [traceback] AttributeError: 'NoneType' object has no attribute 'received_at' -- RESOLVED
1262973 Set cache timeout to 0 on normandy-dev -- RESOLVED

32 Total; 0 Open (0%); 32 Resolved (100%); 0 Verified (0%);


Phase 2

Phase 2 (planned for 2016q2) will focus on developing and shipping the system addon that will pull from the recipe server and eventually replace self-repair within Firefox, as well as server-side improvements.

Bugs

Full Query
ID Summary Priority Status Resolution
1248666 Action peer review P2 RESOLVED WONTFIX
1257267 [Tracker] Implement custom recipe management interface -- RESOLVED FIXED
1257724 Support for SHIELD studies before SHIELD add-on lands -- RESOLVED FIXED
1261975 Do not show surveys to users who have cleared localStorage -- RESOLVED WONTFIX
1266885 Replace server-side filtering with client-side filter expressions -- RESOLVED FIXED
1268220 [Tracker] SHIELD post-launch fixes -- RESOLVED FIXED
1277994 Make hot-path APIs fast P2 RESOLVED FIXED

7 Total; 0 Open (0%); 7 Resolved (100%); 0 Verified (0%);


Future phases

Possible future improvements may include:

  • Distributing recipes to X users, then disabling it.
  • A debugging view for previewing a specific recipe's functionality.
  • Automatically modify sample rates to reach a certain minimum amount of users over time. For example, "Reach 500 users per day, spread out over the entire day".
  • Chain recipes with auto-disable rules, such that when one is disabled the next one is enabled.