This is a proposed lightweight policy for adding sites to the UA string
override list. (Follow up to dev-platform; let me know if I've not
spread this wide enough.)
I propose that we agree this policy, then switch the B2G default UA back
to the OS-agnostic one (no "Android"; bug 787054). If we hit problems
with specific sites, we file bugs, run through this process, and get an
override in place if appropriate. It's important for a number of reasons
to fix the B2G UA ASAP, and I suspect that if we resolve it for v1 to
include "Android", we'll never manage to get it out of there, with all
of the problems that will entail long term.
We want to balance the ability to react to problems users are
experiencing, with a requirement to check that we are aiming before
shooting, that we don't actually degrade user's UX (e.g. by bypassing a
check which kept them from a very broken site) and that we are making
sure the list does not grow without any organized efforts to shrink it
again.
Sites should be added to the list if/when:
1) An evangelism bug has been opened and the site has been contacted;
2) The site has proved unresponsive or unwilling to accommodate us (how
long we wait for this will depend on factors such as the popularity of
the site and the extent of breakage);
3) There is a specific proposed alternative UA for each broken product
which has minimal changes from the default;
4) Either: Deep testing (not just the front page) has shown that a UA
override for that UA in that product leads to a significant UX
improvement on the site; or we know that the fix works because it
restores a UA which that product was previously using;
5) The override is only for the broken products;
6) The entry in the prefs file comes with a comment with a reference to
the bug in question.
Criterion 2 and criterion 4 are the only ones which could potentially
lead to significant delay. 4 is unavoidable; we don't want to be doing
an override without checking that it actually improves things. Sites
required by teams for functional testing or demoing of B2G would have a
very short timeout for criterion 2.
Sites should be removed from the list, for all active branches (I
propose: including stable and ESR), once the site has confirmed that
they have fixed it, or deep testing makes us believe they have.
Does this strike the right balance?
Gerv
_______________________________________________
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
