View source for Firefox/Go Faster/When To Use System Add-ons

=== You should not use a System Add-on if ===

* It is a raw experiment of new functionality -> [[Firefox/Go_Faster#Test_Pilot|Use Test Pilot]]
* It is attempting to answer a summary from a segment of our users -> [[Firefox/Go_Faster#Recipe_Server_.28SHIELD_.2B_Variants.29|Use Shield / Recipes]]
* If it is not under rapid development/is unlikely to need out-of-cycle updates.

=== You might want to consider System Add-ons for ===

* A confirmed feature (i.e. has been through test pilot) that is still under rapid development
** Would like to be able to ship updates faster than the release train to get a better development/user feedback cycle.
* May need to update parts of it off-cycle, for example:
** e10s rollout needed to be updated off-cycle to push out to different amounts of release populations.
** Form autofill may need to be modified to account for changes in active websites.
* It is being pushed out to older users, for example:
** To try and get them to update
** To fix issues discovered that might block them updating.
* It is being pushed out to fix issues for release users, i.e. replacing the hotfix mechanism.
* You need to measure network conditions that only users see. However, anytime you're thinking of [[Firefox/Making Network Requests From Firefox|Making Network Requests From Firefox]], there is specific guidance to follow.

=== Additional Considerations ===

* System add-ons are not just a way to skip the release trains
* System add-ons must be covered well with automated tests to give confidence when shipping
* Testing & release cycles will need to be considered and planned
* Developing within mozilla-central
** Any L10n requirements/changes will be constrained by the existing release train.
** You will need to ensure that any changes are complete at the end of the release train cycle, ready for uplift
**** Hello had lots of feature based development, which wasn't always complete at the end of a cycle.
* Developing outside mozilla-central
** L10n is not constrained by the release train, but the methods used are likely to lead to a smaller proportion of locales having complete localisation
** You're not constrained by release cycles - you can choose when to release to mozilla-central (and then uplift/push to release if required).
** You'll need to consider reviews - Firefox changes typically need to be reviewed by a Firefox peer. Would this be suitable for snapshot based releases?
** There's more flexibility for the build system - you can use npm/libraries and ship only the output to the add-on in mozilla-central
*** Of course, this may change for mozilla-central in the future.
** Hello also had its own "beta" add-on hosted on AMO, for testing out changes with a much smaller population before pushing to mozilla-central
*** There was also a developer channel one for L10n people.
* There should be a way (via metrics, whatever) to assess whether a system add-on was successfully delivered. Both for individual users who report new issues, and to know whether we expect a certain percent of the population to never received it.
** Related: https://public.etherpad-mozilla.org/p/gofaster-measurements