Do we even need an acronym? as you said - its our architecture now and we are moving other apps in that direction - we should not spend time thinking what its called and define what needs to be done to evolve all our core functionality to our updated architecture.
wilfred --- FxOS Product Management Mozilla Corp., UK > On 3 Nov 2015, at 18:49, Sam Foster <[email protected]> wrote: > > NGA seemed to work well at the definition/proposal stage. But now that we > have concrete implementations I think it does need a new name. Apart from > anything else, any name with "new" in it just punts the naming problem. As of > 2.5 its no longer "new", its current. And maybe in a year or more it will be > old and we'll have an Even Newer Gaia Architecture proposal. Is there not > some cleaning product backcronym we can come up with? :) > > /Sam > > > On Tue, Nov 3, 2015 at 2:58 AM, Salvador de la Puente > <[email protected] <mailto:[email protected]>> wrote: > Well summarized David! > > Just for the records, we already have a wiki page for NGA > (https://wiki.mozilla.org/Gaia/Architecture_Proposal > <https://wiki.mozilla.org/Gaia/Architecture_Proposal>) and we already have > the split into goals the NGA is pursuing > (https://wiki.mozilla.org/Gaia/Architecture_Proposal#Design_Goals > <https://wiki.mozilla.org/Gaia/Architecture_Proposal#Design_Goals>). > > It could be great if we update this wiki with our acquired experience. > > On Tue, Nov 3, 2015 at 11:45 AM, David Scravaglieri > <[email protected] <mailto:[email protected]>> wrote: > I do agree with Justin and Marcus. > > NGA is the hat of a set of recommendations for building better apps for > Firefox OS. Unfortunately it is easy to use the "NGA" shortcut when devs are > implementing any of these recommendations. This can be confusing and drives > to miscommunication. > > As for me using the NGA shortcut is fine when we speak about an app being in > process of transitioning to the full NGA recommendation. But we absolutely > need to be more specific when it's about commitment and delivery. > > In Whistler, When I committed Engineering to split BE/FE, I paid attention to > not commit to "NGA" but specifically to "split BE/FE for SMS, Music and > Contacts as part of NGA". > > We should definitely do a better job for defining glossary, documenting NGA > and all the recommendation that will make an app "NGA" compliant. > > In addition to that I would love to see some documentation, best practices > and recipes for using bridge.js, split views, use ServiceWorkerWare etc.. > coming from the developers who were engaged in Music, SMS and Contact road to > NGA. They actually did more that "separation of view logic", they all > explored different side of the NGA recommendations and their feedback would > be valuable to everyone. > > > --- > David Scravaglieri > Mozilla - Firefox OS > > > On Tue, Nov 3, 2015 at 6:15 AM, Marcus Cavanaugh <[email protected] > <mailto:[email protected]>> wrote: > Spark, Ignite, NGA, Mulet, PVT... code names work well only if there's an > easy way to discover what each name stands for. I'd prefer that we use less > opaque names, but I think a more accessible glossary and wiki would be > equally useful. Google had a centralized user-editable glossary of terms; we > might benefit from something similar as well, e.g. have acronyms in Bugzilla > fields automatically hover-link toward the glossary page. > > On Nov 2, 2015, at 8:44 PM, Justin D'Arcangelo <[email protected] > <mailto:[email protected]>> wrote: > >> I think we should just do a better job of documenting and explaining what >> NGA is. It would be nice to have a central place to go where people can >> learn about the app architecture as well as get links to all the related JS >> libraries we have developed like ServiceWorkerWare, Bridge.js, etc. >> >> Also, if contributors are more aware of NGA, it is actually clearer and less >> verbose to just say “NGA” versus “separation of view logic”, which is >> actually somewhat vague. Pretty much every good app architecture involves >> “separation of view logic” and the migration to NGA is much more than just >> separating view logic. Another way to look at it is, if we were migrating >> apps to an existing 3rd-party framework like Angular or React, we would >> likely be referencing the framework/architecture by its name when we talk >> about it. >> >> I just think if we had better documentation to call out what NGA is, this >> would be a non-issue. Perhaps once we get together to recap the NGA work >> from v2.5, we can talk about putting together a simple GH-pages website with >> documentation, libraries and a downloadable skeleton project for building >> new “NGA” apps. >> >> -Justin >> >> >>> On Nov 2, 2015, at 8:16 PM, Tim Guan-tin Chien <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I would like to know what David and Vivien think. >>> >>> On Tue, Nov 3, 2015 at 12:11 AM, Candice Serran <[email protected] >>> <mailto:[email protected]>> wrote: >>> Agreed...the team working on the entire NGA program will be conducting a >>> retrospective and plan forward next week (Nov 9-Nov 13). We'll make sure >>> specific actions regarding the overall program are explicitly communicated >>> and broken out. >>> >>> Thanks! >>> >>> On Mon, Nov 2, 2015 at 6:13 AM, Wilfred Mathanaraj <[email protected] >>> <mailto:[email protected]>> wrote: >>> That would definitely help internally as well - plus it would valuable for >>> us to understand all the outstanding tasks and plan ahead for the >>> completion of work. >>> >>> Wilfred >>> >>> --- >>> FxOS Product Management >>> Mozilla Corp., UK >>> >>> >>> >>> >>>> On 2 Nov 2015, at 12:00, Michael Henretty <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi all, >>>> >>>> I suggest that we stop using the term NGA when talking about feature work >>>> in Gaia. The problem is that there are many facets to NGA, and using that >>>> term only confuses what we are actually working on. So in the future, >>>> instead of saying that we landed NGA in the SMS app for instance, let's >>>> say "we landed separation of view logic and threads.js in SMS." This is >>>> much more contributor friendly, and even helps core developers understand >>>> what is truly being worked on. >>>> >>>> Thanks, >>>> Michael >>>> _______________________________________________ >>>> dev-fxos mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.mozilla.org/listinfo/dev-fxos >>>> <https://lists.mozilla.org/listinfo/dev-fxos> >>> >>> >>> _______________________________________________ >>> dev-fxos mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.mozilla.org/listinfo/dev-fxos >>> <https://lists.mozilla.org/listinfo/dev-fxos> >>> >>> >>> >>> >>> -- >>> >>> >>> Candice Serran >>> Sr Mgr - FxOS Engineering Pgm Mgmt >>> [email protected] <mailto:[email protected]> >>> irc: cserran >>> mobile: 303.588.1101 <tel:303.588.1101> >>> >>> _______________________________________________ >>> dev-fxos mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.mozilla.org/listinfo/dev-fxos >>> <https://lists.mozilla.org/listinfo/dev-fxos> >>> >>> >>> _______________________________________________ >>> dev-fxos mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.mozilla.org/listinfo/dev-fxos >>> <https://lists.mozilla.org/listinfo/dev-fxos> >> >> _______________________________________________ >> dev-fxos mailing list >> [email protected] <mailto:[email protected]> >> https://lists.mozilla.org/listinfo/dev-fxos >> <https://lists.mozilla.org/listinfo/dev-fxos> > > > _______________________________________________ > dev-fxos mailing list > [email protected] <mailto:[email protected]> > https://lists.mozilla.org/listinfo/dev-fxos > <https://lists.mozilla.org/listinfo/dev-fxos> > > > > > -- > <salva /> > > _______________________________________________ > dev-fxos mailing list > [email protected] <mailto:[email protected]> > https://lists.mozilla.org/listinfo/dev-fxos > <https://lists.mozilla.org/listinfo/dev-fxos> > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
