[Go Faster] Hello-as-addon challenges
mconnor at mozilla.com
Wed Sep 9 01:37:09 UTC 2015
So, let's unpack this:
* We're not really giving clients a "decision logic" in this case. We're
providing the data to apply the decision we make, i.e. by marking an add-on
as only compatible with a subset of locales or regions.
* I don't think "known good only" and "unstable/beta add-ons" are mutually
possible. In the general case, a core system add-on should not have any
dependency or conflict with another core system add-on. The model has to
be flexible, and we have to manage dependencies cleanly.
* Virtually all new features we ship via this mechanism will be
locale-constrained (in that we won't have stable strings) for some period
of time. We're not going to wait on all 80 locales to roll something out
to a wider audience. Just like I don't expect we'll roll a feature to 100%
of users off the bat. We'll have to manage those tradeoffs smoothly, but
the goal here is to go faster and avoid the delays of all-or-nothing
* I expect that our data processes will continue to be the same. To my
knowledge, we have yet to have a data practice that was not globally
acceptable from the beginning, so this shouldn't change anything. I don't
think anything I'm suggesting would run counter to that practice.
On 2 September 2015 at 13:26, Axel Hecht <axel at mozilla.com> wrote:
> 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
> 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
> -- Mike
> On 1 September 2015 at 09:40, Armen Zambrano Gasparnian <
> <armenzg at mozilla.com>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>
>> 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>
>>>>> 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
>>>>> Ben, locales 25, 41, and 15 are ready to go... please push those.
>>>> 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?
>>> 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.
>>> Gofaster mailing list
>>> Gofaster at mozilla.org
>> Zambrano Gasparnian, Armen
>> Automation & Tools Engineer
>> Gofaster mailing list
>> Gofaster at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gofaster