[Go Faster] Do we want system add-ons to update without restarting?

Robert Helmer rhelmer at mozilla.com
Mon Sep 28 17:54:24 UTC 2015


I don't have all the answers here, but when I said "autonomous" I more
had in mind partners like Pocket, who are already working on their
own, with their own processes, and giving us code dumps. My impression
is that we're going to have more partner integrations in the future
and we want to try to improve the situation here.

The Hello team largely operates within normal Mozilla processes right
now as you describe. The release process is the only thing I imagine
them having more autonomy around.


On Mon, Sep 28, 2015 at 10:13 AM, Chris Hofmann <chofmann at mozilla.com> wrote:
>
>
> On Mon, Sep 28, 2015 at 6:53 AM, Laura Thomson <lthomson at mozilla.com> wrote:
>>
>>
>> > It allows teams
>> > working on these add-ons to be more autonomous and not have to sync to
>> > Firefox's release cycle (barring a dependency on a platform change).
>>
>> What Rob said, here.
>>
>> Laura
>> ==
>>
>
> I think its worthwhile defining what "Working Autonomously" means.   Its not
> listed as goal or anywhere in the PRD.
>
> There are several place where "Working Automously" might come in to play.
>
> During development of code.   - Developers work Autonomously on this now,
> they are able to land new code on there own development branch or central as
> wanted.
>
> During localization of code.  - Developers work autonomously on this now,
> they land strings and l10n-drivers and localization teams get the feature
> localized, sometimes within hours of code landing, and some times with some
> teams on the aurora or latter cycle.  We really don't have a definition of
> when localization work is "required" and we really don't require any
> developer involvement in the process in most cases other than than landing
> good and well thought out en-US strings and comply with well defined
> development practices that allow the efficient translation of the feature.
> Its been suggested that if we somehow allow features to ship only in en-US,
> or only in selected languages it will somehow increase developer autonomy,
> but it also works against the goal of a product built to reach all of our
> global audience.  If we are interested in maintaining and building global
> marketshare that ought to be an explicit goal.  The systems in place now
> both allow developer autonomy and meet the goal of reaching the widest
> possible audience.
>
> During testing, security checks, stability assessment and other evaluation,
> of code.   Developers don't work autonomously on this now.  They engage with
> QA and our testing community to get feedback and bugs to shape the feature.
> How are system addons intended to change automomy in this area?   Its been
> hinted at that developers might do this work, or make decisions that some of
> these tasks might not be needed or intentionally avoided in the interest of
> shipping sooner.  It would be good to figure out and make explicit if this
> is the case.
>
> During Release Management and over all Integration of the feature into the
> single browser product that we ship.   How it all hangs together is one of
> the most important things we assess and do.  It creates the unified browsing
> experience we want our users have.    Its also hard for me to see how
> individual developer autonomy helps in performing these tasks, and it
> appears that system addons is actually a distraction in getting that work
> accomplished, since they operate in a parallel distribution path.  The
> increase the amount of work to get done, the number or releases to
> administer and ship, and intern the more work and time spent actually causes
> us to go slower.
>
> These are just a few areas where autonomy might come into play.  Lets define
> and asses what autonomy means if its an important part of system addons.
>
> -chofmann


More information about the Gofaster mailing list