diff --git a/ember.js/2016-09/september-30.md b/ember.js/2016-09/september-30.md
new file mode 100644
index 00000000..cee1df54
--- /dev/null
+++ b/ember.js/2016-09/september-30.md
@@ -0,0 +1,51 @@
+# Ember Core Team 2016-09-30
+
+### Agenda
+
+(please note (private) or (public))
+
+- (public) Action items for pushing Module Alchemist forward (TD)
+- (public) [Ember Inspector Video](https://www.youtube.com/watch?v=6Yl1j2thKac) feedback (LS)
+- (public) Nesting Guides and/or API under Learn in website nav (LS)
+- (public) ES6 Module API/RFC (TD)
+- (public) ember-core package name (DG)
+- (public) restart module unification FCP? (DG)
+- (public) TC39 Update from the Gentleman from Portland
+
+### Attendees
+
+LS, YK, GC, EB, KS, RJ, EF, TD, MM, DG
+
+### Minutes
+
+#### Module Alchemist
+
+TD: RFC for standardizing on layout and module format/builds. Are there open concerns on the core team or can I start moving this to FCP? [https://github.com/emberjs/rfcs/pull/155](https://github.com/emberjs/rfcs/pull/155)
+
+RJ: I would like the RFC to specifically note that `dist/` does not get checked in.
+
+#### Ember Inspector Video
+
+LS: Feedback on Gavin's new video? [https://www.youtube.com/watch?v=6Yl1j2thKac](https://www.youtube.com/watch?v=6Yl1j2thKac). We want to start adding these videos to the website.
+
+Everyone: Looks good.
+
+#### Unifying Guides and API Links
+
+LS: Learning team wanted to merge API and Guides link into a single "Learn" link, with API and Guides as sub-items. There was concern that people looking for the API specifically would be confused because it's somewhat unique terminology, and also that API is just very commonly what people are looking for. So the compromise position is that we'll nest Guides under Learn, so we have that main Learn directory page with resources and things, and while API will be one of the things that page directs to, API will still *also* maintain it's top level link in the nav bar. Thumbs up all around.
+
+#### ES6 Module Public API
+
+TD: I signed up for writing the RFC for what the module API is going forward (named exports, default exports, package names, etc.) Two proposals that people were against when we discussed informally at the F2F were:
+
+``` js
+import { Component, computed, get, set } from "ember";
+```
+and:
+
+``` js
+import get from "ember-get";
+import set from "ember-set";
+import computed from "ember-computed";
+import Component from "ember-component";
+```
diff --git a/ember.js/2016-10/october-07.md b/ember.js/2016-10/october-07.md
new file mode 100644
index 00000000..66e2b371
--- /dev/null
+++ b/ember.js/2016-10/october-07.md
@@ -0,0 +1,133 @@
+# Ember Core Team 2016-10-07
+
+### Agenda
+
+- (public) Issue triage policies: [emberjs/ember.js#14339](https://github.com/emberjs/ember.js/pull/14339) (RJ)
+- (public) [ember-cli blueprint for computed macros](https://github.com/ember-cli/rfcs/pull/67) (RJ)
+- (public) https://github.com/emberjs/ember.js/pull/14410 (RJ, GC, YK)
+- (public) follow-up about convo with @locks (YK)
+- (public) Review [RFCs in FCP](https://github.com/emberjs/rfcs/labels/Final%20Comment%20Period) (DG)
+- (public) ember-source vs ember-core npm module (SP)
+- (public) any opposition to ship ember-core/source? (SP)
+
+### Attendees
+
+YK, MB, TD, SP, RJ, MM, KS, GC, EB, DG, EF, LS
+
+### Minutes
+
+##### PR #14339, triage team policies
+
+TD: I think it is good if we can have boilerplate responses. Not "we don't care" but it is in alignment with our policies.
+
+RJ: I didn't want to merge w/o discussion but I'm in favor. We've tweaked the communication style with individuals in the past, but a policy is generally good. I will review the words again and make it look good. Does core want to be in the loop on the exact wording?
+
+SP: I think we should do a FCP style thing confirming the form of the communication
+
+YK: the rust project has been trying to automate the consensus process and such. I have a wycats dashboard where I am told where to look etc. I will share more in the chat.
+
+#### Ember-CLI RFC #67, CP macro blueprint
+
+RJ: We suggested before that new blueprints should do through the RFC process, the cli team discussed, stef?
+
+SP: I do not have a strong opinion. Do we want to encourage people to create a custom computed property or not? I like CP macros.
+
+TD: I don't love the term "macro" being part of the learning experience. They aren't part of the core ember learning experience. I would prefer that this be moved to the ember cpm addon instead.
+
+SP: I find that convincing. Tom please leave a comment.
+
+TD: Yes will do.
+
+#### PR #14410 - Concept of "rendering" changing in 2.9
+
+RJ: I want to apologize for using the word "bet" in this discussion.
+
+YK: A difficulty is that when we use a poor term it is often taken up as more meaningful/intended than anticipated.
+
+GC: I'll try to explain the technical side. Imagine we added a feature for a long time where when any shallow property changes an observer fires, imagine we use that in the template system. It isn't a feature that we have "star" observers, but for the purposes of this discussion you can think of the new rendering engine using them. The consequence is that if you have a component and you are pasing properties to a downstream child components and you set a property that is none of the properties you are pasing down, the rendering will fire although the properties passed didn't change.
+
+YK: This was an intentional change. The React model is that you rerender every time, and that works to an extent. However Ember apps are bigger and we don't want to make people learn shouldComponentUpdate, so the solution is that when you `set` we bump the tag on the object and during rendering we do a comparison of the tag.
+
+(further discussion)
+
+KS: On this whole issue I want to give people workaround, but I could not always track what they were worried about. I went back to look at old behavior before 2.9 and it was sometimes the same. If you have an expensive thing, you should check it on your own.
+
+MB: However this is a new challenge for Ember devs that didn't exist before. We've historically taken care of all the fine-grained observation ourselved, and there must be communication that the model is changing, and why.
+
+RJ: We must decide if this is a breaking change or not. Right now the topics are potentially toxic, we need to collectively decide that the official explanation is.
+
+TD: I think we need to pitch the benefits of the pull-based architecture. GC how is the book going?
+
+GC: The book is more about the implementation of the reference system vs. the benefits. We also need to get specific examples of what issues are. We can make some cases faster, but we may regress real world cases where other work is being done.
+
+KS: chaining through the hash object is probably messing people up. The only reason chains fire a change event when they don't change in value is b/c before it already promised that it will change. And the whole setup/teardown of the array proxy relies on this. If we can eliminate that case we can just remove the will/did and notification. And delete a lot of code that attempts to pair those hooks.
+
+YK: I want to give some more precision about CPs. CPs do memoization, but they are doing an opportunistic thing. If I have thousand CPs Ember will try to not run all of them, but I should try to avoid those functions have side-effects are ensure they are relatively fast. It is about amoritzing cost. If I have a thousand and only a hundred run (though I cannot control what hundred) it was still good to save the 900.
+
+RJ: Right but people think that the dependencies changing is the only thing that invalidates the CPs, even though we all know it has not been true. Ever. We need to make the docs clear to say it will be called when dependencies change, but it may *also* be called more often than just when they change.
+
+(lots of comments on bloom filters and amortized cost)
+
+TD: there is a narrative we have moved away from fine-grained observation and this fits in, but we need to communicate it beyond just docs (perhaps a blog post). I think we need to all be blogging more in general. So much of what we do is ephemeral, I think having to distill into a blog post is helpful.
+
+RJ: Last time I tried to get into blogging I just ended up becoming a super involved contributor to a blogging framework....
+
+(discussion)
+
+TD: Standing offer to help people with perf or optimization hooks etc. Happy to help wordsmith. I think it just needs to be tag teamed.
+
+KS: Generally I don't think we should merge this PR. I can't imagine it being faster if you benchmarked it.
+
+RJ: I agree it is a lot of code. I think there are smaller things you can do in your code to protect against the issues caused by the new behavior.
+
+GC: I don't know if you could actually do this, but I think yehuda and I need to do a thing.
+
+TD: Can you benchmark it?
+
+GC: There is a jsbin that shows it is actually slower, but I'm not sure even if you fix that if there is a global win. Basically there are pathological cases in the system and you can exaggerate them.
+
+EF: Yeah there is a real problem in his app though, we should try to see what it is.
+
+RJ: there are some observers etc
+
+YK: Right, if we do all the bookkeeping to do this the problem is you regress the initial render. If you do it in a few hot spots it is fine though. We just can't do the fine-grained observation through the whole system, this is a thing we learned from looking at React comparisons where we used to be slower on initial boot and way faster on updates.
+
+RJ: I think this dovetails with users wanting to use real getters etc.
+
+YK: and we're not saying it is like react and we will rerender/run things all the time.
+
+EF: I will craft a response, and I think some benchmarks will show the initial boot has a cost to it
+
+KS: this is my gut feeling as well
+
+#### shipping ember-source
+
+SP: I want to ship and ember npm module we've talked about for months. It will be named ember-source, are we gtg?
+
+RJ: I would like the next stable version of ember-cli to be able to ship with this.
+
+SP: and the next version of Ember?
+
+RJ: No I don't think we should backport it. 2.10 would be the ember version.
+
+=SP: so ember-core is the current name, becomes ember-source
+
+RJ: Right, ember-core is basically to be reserved for a future project.
+
+RJ: I want to align travis builds for ember beta/stable and ember-cli beta/stable, we should sidebar.
+
+#### three RFCs
+
+RJ: No new information that changed things
+
+YK: I have one thing- I disagree with the general purpose dynamic variable lookup thing in the routing service. I would accept another proposal and perhaps be convinced.
+
+EF: We are covered, there is an alternative API in the RFC. Sound good.
+
+KS: you think the commnunity was supportive of the titlebar thing?
+
+RJ: right people have been working on the editor plugins etc
+
+TD: right that is a sign they are supporting it
+
+(some discussion over titlebar etc)
diff --git a/ember.js/2016-10/october-14.md b/ember.js/2016-10/october-14.md
new file mode 100644
index 00000000..2dd92cb0
--- /dev/null
+++ b/ember.js/2016-10/october-14.md
@@ -0,0 +1,105 @@
+# Ember Core Team 2016-10-14
+
+### Agenda
+
+(please note (private) or (public))
+
+- (public) Review [RFCs in FCP](https://github.com/emberjs/rfcs/labels/Final%20Comment%20Period) (DG)
+- (public) Glimmer 2 Status - Should we push 2.9.0 back a week (to 2016-10-24) or defer Glimmer in Ember until 2.10? (RJ, YK, GC)
+- (public) `ember-welcome-page` (high priority Learning Team issue) (YK, LS)
+- (public) Review ongoing Query Params cleanup work (RJ / AM)
+    - Targeting 2.10 - Add an assertion when using `(query-params foo="bar"` or `.transitionTo(..., { queryParams: { foo: 'bar' } })` if `foo` is ambiguous (either because two controllers use it as a local property alias, or because one is using a local `foo` property as an alias and there is also a URL key for `foo`)
+    - Targeting some future version (> 2.10) - add a deprecation when using anything other than a URL key with `(query-params` or `transitionTo`
+
+
+### Minutes
+
+#### Glimmer 2 and Ember 2.9 Stable
+
+YK: Update on Glimmer 2 and beta. We moved Glimmer to beta because we had fixed compatibility issues in canary that we knew of and needed a bigger testing group, which beta got us. Since then, things have gone really well and compatibility has been exceptionally good.
+
+YK: There are still two issues remaining that affect compatibility that we feel need to be addressed. The first issue is around dirtying. We implemented an optimization that improves first time render, but in some Ember apps can cause re-renders to get significantly slower in some cases. Initially we thought this was very rare and not worth giving up the optimization, but eventually everyone who saw it agreed that it could have a negative impact on many apps.
+
+YK: Godfrey and I have implemented a fix, which causes a 1.5% dip in performance in our rael world app benchmark suite across the board. This seems worth it because it prevents many pathological cases that would be far more noticeable than 1.5%. However, we realized that our fix would not cover Proxy cases. Chad is currently working on fixing that now.
+
+YK: The other issue is with ember-wormhole. Even though we had updated ember-wormhole to add compatibility for Glimmer 2, there were a few other cases discovered where wormholes would not work correctly depending on how they were used. There was an "intimate API" added in the last few days to address this, but Godfrey believes the fix is not correct and needs further work, and I am nervous about adding in an untested, intimate API a few days before cutting production.
+
+MB: Stanley has raised an issue with helper destruction as well.
+
+YK: If that is a blocking issue I would be nervous about putting the fix in for that right now as well.
+
+YK: So it seems like we have three options. Say "damn the torpedos" and go full steam ahead with the release and deal with the compatibility fallout. Option 2 is to defer the release by a week, which I am not in favor of but am open to persuasion. Option 3 is to punt Glimmer to 2.10 beta, cherry-pick the most critical fixes into the 2.8 release version and that becomes 2.9 release.
+
+YK: If we do do the "damn the torpedos" approach, we can tell people who care about stability to use the LTS. But I am very nervous about saying that non-LTS releases are not that stable.
+
+RJ: We have shipped releases with regressions before.
+
+EF: Let's not turn this into a meta-debate.
+
+RJ: Regarding the wormhole fix, my understanding is that there is a specific case that it does not work in.
+
+KS: If there is a `TryOpcode` before the wormhole, it will not work. We missed it because all of the wormhole tests are inside an element.
+
+YK: The bottom line for me is that we can definitely find a fix for this, but we're only two days before the release.
+
+RJ: I think the majority of users will be okay. A bunch of people are already running on the 2.9 beta today, and we have not received any reports of malfunctioning apps. The vast, vast majority of issues people have raised were due to the performance regression/property dirtying issue that we've already discussed. To me that is a way way bigger deal.
+
+MB: If we do use the 2.8 release as the basis for the 2.9 release, what other things would we be giving up? Any of the router stuff?
+
+RJ: All of the encoding stuff was already in.
+
+RJ: If we decide to this, is anyone opposed to me resetting the beta branch to the 2.8 master, and then bring things back in? Then we will reset the new beta branch to canary for 2.10.
+
+DG: Have we considered reducing the length of the next cycle so we have a Glimmer 2-enabled release sooner than 6 weeks?
+
+TD: I am opposed to anything that pushes off the regular release train. The entire point of regular release cycles is so that if you miss one train you just catch the next train, and it shouldn't feel too emotionally bad. If people are feeling very emotionally bad about missing the train, we should either stop feeling emotionally bad or make the cycles shorter. But I don't think that's realistic.
+
+RJ: Is anyone opposed to not deferring Glimmer 2 until 2.10?
+
+*deafening silence*
+
+MB: Addons will break if they are checking the Ember version string to determine whether Glimmer 2 is available or not.
+
+RJ: Liquid Fire is one example of this, but there are probably other addons that have added Glimmer 2 compatibility using private APIs that will be affected.
+
+RJ: Perhaps we should defer a week to allow addons that check the version string to update.
+
+MB: I don't think it would even take a week to get it done. It's a handful of addons, but they are important ones.
+
+RJ: Me and Martin have the top 1000 addons saved locally on our machines, we can take a look to see how bad it is.
+
+YK: Me and Tom will work on how to communicate this to everyone.
+
+EF: I don't think it's too hard to message; it's an example of the release train model working exactly as intended. People will be happy about compatibility.
+
+YK: Maybe Matthew can do an initial draft of the release blog post and we can help massage the messaging.
+
+MB: We need to communicate this before the release blog post. The next, last beta will not have Glimmer 2, and that could potentially break anyone using beta with addons that have the version check issue. That will happen before the release.
+
+YK: Ah, yeah, you're right.
+
+YK: I have another important topic to bring up. Are we all in consensus then?
+
+*Yes, we have consensus on the plan.*
+
+#### Helping the Learning Team
+
+YK: There was an issue with the welcome page in a new Ember app and the `application.hbs` not being there. The last time we discussed this I thought we had consensus. Robert's objection to including the component in the `application.hbs` is that it would include the assets in production, which I agree is bad. Ed pointed out that if the user doesn't remove it, we can just not emit the assets in production builds. I also realized we could pretty easily lint for using this component. The bottom line though is that the time is ticking and I want to bring back the `application.hbs`. If we wait longer then tutorials will update to assume no template is generated, and then reverting the change itself becomes breaking.
+
+RJ: I disagree. There are a few other issues with the addon today. These bugs can be fixed but so far no one has taken the time to fix them, although I have explained them to a few different people. But if we strip out the assets during production, then someone using the component will cause the app to crash in production but not in development.
+
+TD: What is the case where someone would be using the welcome component in a production environment? You wouldn't accidentally leave it in because it will totally screw up your UI.
+
+*YK angrily closes his Chrome tab*
+
+YK: The high-level point is that people who know JavaScript but not Ember don't know where to start working. Having the first page that you load tell you where to go to start editing is incredibly important.
+
+RJ: If the point is telling people where to start, why not just put that in the addon and make the instruction to remove the package from `package.json`?
+
+#### Module Unification FCP
+
+Are we ready to merge?
+
+EF: Yes, no new objections have been raised since the last FCP process. There was a very robust community discussion and I am very grateful so many people gave us excellent feedback.
+
+EF: The routing RFC has been relatively quiet.
diff --git a/ember.js/2016-10/october-28.md b/ember.js/2016-10/october-28.md
new file mode 100644
index 00000000..9276a142
--- /dev/null
+++ b/ember.js/2016-10/october-28.md
@@ -0,0 +1,34 @@
+# Ember Core Team 2016-10-28
+
+### Agenda
+
+(please note (private) or (public))
+
+- (public) CFP Update (LS)
+- (public) Modules RFC Implemention Work (RJ)
+
+### Attendees
+
+Dan Gebhardt, Erik Bryn, Godfrey Chan, Robert Jackson, Leah Silber, Alex Matchneer, Kris Selden, Peter Wagenet, Stef Penner
+
+### Minutes
+
+#### EmberConf CFP
+
+LS: The EmberConf CFP has been open for a little while and proposals are flowing in. We've got some new folks on the program committee this year and almost all proposals that are already in have *already* gotten some feedback and are iterating. So let people know, earlier means more value, we'll help them iterate!
+
+LS: [The CFP Brainstorming session we did last year](https://s3.amazonaws.com/emberconf-2016/11-22-hangout.mp4) has been scheduled for Wednesday, November 9th at 12pm Pacific / 3pm Eastern / 8pm London. If anyone else on the core team is up for showing up as an invited expert please let me know, it'll be a mix of core team and program committee folk. Was REALLY great last year, many of the best talks came out of ideas that were discussed and proposed on that call.
+
+#### Glimmer 2 Update
+
+GC: I fixed the issue with class-based helper, and also make local variables win over helpers. The class-based helper issues was probably by far the biggest blocker for shipping. There are two issues on my radar – hasBlock not working in partials and block params named `|component|` does not work. Those are relatively minor issues and I believe we already know how to fix. Will pick it up soon if no one else does. We should probably get back to doing some performance investigations once these are fixed, but for now bug fixes takes priority.
+
+#### Modules RFC Implementation Work
+
+RJ: The 201-created folks have been doing good work on prototyping an initial implementation of the new resolver rules. There are still a number of known issues to address (listed in an issue in their repo), but once those are addressed I'd like to advocate for shipping an MVP (possibly as non-default in new ember-cli apps until we are all :+1:). The MVP would still be dynamic at runtime (no build time mapping), but would allow us to start actually using the new system.
+
+DG: I haven't looked into their implementation in detail yet, but I'd be happy to work together on the remaining issues next week.
+
+SP: We should be careful to not assume that a build time mapping is guaranteed to be better, it is quite likely that the map itself would be prohibitive for large applications.
+
+RJ: OK, so it sounds like we agree that we can probably ship the initial version as runtime only, and start investigating build time map structures that would work well for us.
diff --git a/ember.js/2016-11/november-04.md b/ember.js/2016-11/november-04.md
new file mode 100644
index 00000000..26c0d94e
--- /dev/null
+++ b/ember.js/2016-11/november-04.md
@@ -0,0 +1,46 @@
+# Ember Core Team 2016-11-04
+
+### Agenda
+
+(please note (private) or (public))
+
+- (public) [RFC #50](https://github.com/ember-cli/rfcs/pull/50) Stripping assert and friends from app builds (MB)
+- (public) discuss issues with Needs Team Discussion
+- (public) Want to submit [Module RFC](https://github.com/tomdale/rfcs/blob/js-modules/text/0000-javascript-module-api.md) (TD)
+- https://github.com/emberjs/ember.js/issues/14314
+
+### Attendees
+
+Robert, Matt, Stef, Alex, Dan, Yehuda, Martin, Tom, Erik, Igor
+
+### Minutes
+
+#### RFC #50, assert stripping
+
+RJ: Basically the same as what we do in Ember
+
+(some discussion, outcome in: https://github.com/ember-cli/rfcs/pull/50#issuecomment-258503562)
+
+#### Needs Team Discussion GG Label
+
+KS: I worry issues go here to die. There is an issue where we removed some private API. I didn't think it raised to the level of "intimate API", but it needs discussion.
+
+SP: This is a discussion about the challenge in general though
+
+KS: Yes I want to know what the process is here.
+
+TD: I think these issues can often need a champion to advance
+
+SP: So in this case kris would be the champion to discuss this item
+
+YK: I think needs team response is useful, and needs team discussion is a good second level. needs team discussion needs a conceptually untriaged state.
+
+KS: If any of us reviews an issue we should at least comment that we were there and looked at the issue.
+
+SP: I think that is good messaging on the issue as well.
+
+#### Module RFC
+
+RJ: I have some comments, but this is well done and you should submit it so we can discuss.
+
+TD: I want to be sure we have consensus b/c it will be unproductive to have significant divergence of opinion on the actual RFC thread.