> 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 had previously; > > 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?
I think this is a good list. Unless someone has a glaring issue I suggest that we run with this list and tweak it in the future if need be. As was raised in another response, I expect that as we get closer to the release we will continue to lower the bar for #2. Lawrence _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
