Compatibility/System Addon/Override Policies and Workflows: Difference between revisions

→‎Override or not?: update override or not section
(→‎Preamble: Update language in preamble)
(→‎Override or not?: update override or not section)
Line 7: Line 7:
== Override or not? ==
== Override or not? ==


We try to make this decision mainly based on the sites popularity. There is no point in adding an override for a small site with a high likelihood our suggestions will never be implemented. Ultimately, all overrides should be a '''temporary measure, not a long-term fix'''.
Our goal is to fix top sites, or sites that will have the most impact for Firefox users.


* If a site is very popular, a lot of users may be affected by the bug and we should put an override in place before going into outreach (or, even better, do both at the same time) to reduce the user impact.
* It's important to consider a site's popularity on a by-country level, in addition to global level.
* We have no fixed threshold on the sites rank that qualifies for an override. However, we might set a soft limit in the future if we have some experience.
* We have no fixed threshold on the sites rank that qualifies for an override. However, we might set a soft limit in the future when we have more experience deploying site patches.
* It's important to consider a site's popularity on a by-country level, not a global level. Some sites may be very popular in one market, but completely irrelevant to others. While this particular case might not have a huge global impact, losing users from one market can be painful.
* Trending sites should also be considered, even when they don't rank highly in global usage metrics.
* Some sites may be very popular for a short period of time, but not popular at all in a global statistic. Examples are marketing sites for events, projects from raising startups, ... It's important to consider those as well.


== Generic Process of adding an override ==
== Generic Process of adding an override ==
Confirmed users
796

edits