[Go Faster] Hello-as-addon challenges

Axel Hecht axel at mozilla.com
Wed Sep 2 17:26:58 UTC 2015


I think that we should make decisions once, and then distribute the data 
to support them, rather than giving all the data and the decision logic 
to all clients, and then have them figure stuff out.

The real question here is still which decisions we're making, based on 
what data.
Which decisions are done by humans, and which decisions are done by bots.

And if we're opening up the dimension of per-locale decisions, what does 
that mean for our data processes?

I would think that we're not willing to open up per-locale-per-feature, 
as that'd contradict our scheme of only having known good 
feature-combinations shipping.

Axel

On 9/1/15 6:33 PM, Mike Connor wrote:
> We've done locale-limited features in the recent past ("Flare" search 
> UI rolled by locale through 34/35/36), via a locale-driven pref.  
> There's also absearch, which could be trivially extended/duplicated to 
> roll out other settings by language/region/etc.
>
> In an ideal world, system add-ons will be able to embed some sort of 
> flag to indicate locale/region compatibility, and Firefox will 
> determine whether to load the add-on at all based on that flag. If the 
> add-on strings get updated, we push a new update, Firefox sees that 
> the locale is now supported, and we can then load for those users.  We 
> could supplement with an absearch-like microservice if we want to do a 
> phased rollout.  (And I think we'll want to be able to do a non-binary 
> rollout of potential new features.)
>
> -- Mike
>
> On 1 September 2015 at 09:40, Armen Zambrano Gasparnian 
> <armenzg at mozilla.com <mailto:armenzg at mozilla.com>> wrote:
>
>     Can we deliver features to locales only if they have been
>     localized and signed off?
>     In other words, make a feature available only if we have marked
>     that the localization for it is ready for it.
>     It would be great if the browser would be able to determine at
>     what point a a feature has been localezied and signed off, fetch
>     the strings for that feature and enable it.
>     I believe this would give us all the ability to move forward and
>     localizers to catch up.
>
>     On 31 August 2015 at 17:50, Axel Hecht <axel at mozilla.com
>     <mailto:axel at mozilla.com>> wrote:
>
>         On 8/31/15 11:36 PM, Toby Elliott wrote:
>
>             On Aug 26, 2015, at 12:13 PM, Chris Hofmann
>             <chofmann at mozilla.com <mailto:chofmann at mozilla.com>> wrote:
>
>                 Yes, that's theortically possible, but leads to trying
>                 to manage 80+
>                 releases for each of the locales that we serve, and a
>                 very complex
>                 release management process in terms of commuication
>                 and execution.
>
>                 Ben, locales 4, 8, 10, and 22 are ready to go...
>                 please build and push those.
>                 Ben,  locales 25, 41, and 15 are ready to go... please
>                 push those.
>                 etc….
>
>             Couldn't this be "Ben, enough locales are in to ship this,
>             please push" followed by out-of-band string updates for
>             those other localizations as they come in?
>
>         So, 'enough' is undefined, see below ...
>
>             Do we simply refuse to ship a feature to a locale if the
>             translation hasn't come in? Or is it acceptable to have
>             fallback strings in parts of the browser when a more
>             obscure language hasn't been localized yet?
>
>             Toby
>
>
>         This is the real question: Is it OK to ship a string in
>         English in ... X?
>
>         The answer is gated on the question, really.
>
>         If the question is "are we gonna learn something useful out of
>         shipping this?", then the answer is only going to be yes if
>         the translations of that test are awesome. Otherwise you'll
>         just measure "oh my god, this isn't in my language", followed
>         by "oh my gosh, this is horrible grammar". The latter is
>         actually real feedback I just read the other day. You're not
>         going to see any signal in our data that's related to the
>         patch in question.
>
>         If the question is "is this feature good to ship in English?",
>         that's a VERY complicated question. Depends on culture, and
>         beyond that, user population within that culture. Can you say
>         "hey, buddy", literally, to me? Sure. Can you say that to my
>         mom? Hell no. Which brings us back to the question of what's
>         there to gain, and what's there to loose.
>
>         And lastly, there's some concrete lessons we've learned in the
>         past few years. If UI sucks and survives, it'll suck. If it
>         dies, it dies. The expectation that we'll "ship things as they
>         come in" doesn't match our real-life experience. And the lack
>         thereof makes total sense to me, at least in my cynical way of
>         thinking about human beings.
>
>         Axel
>
>         _______________________________________________
>         Gofaster mailing list
>         Gofaster at mozilla.org <mailto:Gofaster at mozilla.org>
>         https://mail.mozilla.org/listinfo/gofaster
>
>
>
>
>     -- 
>     Zambrano Gasparnian, Armen
>     Automation & Tools Engineer
>     http://armenzg.blogspot.ca
>
>     _______________________________________________
>     Gofaster mailing list
>     Gofaster at mozilla.org <mailto:Gofaster at mozilla.org>
>     https://mail.mozilla.org/listinfo/gofaster
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/gofaster/attachments/20150902/d6b3c666/attachment.html>


More information about the Gofaster mailing list