diff --git a/minutes/tc39-outreach-2019-01-07.md b/minutes/tc39-outreach-2019-01-07.md
new file mode 100644
index 0000000..85309ce
--- /dev/null
+++ b/minutes/tc39-outreach-2019-01-07.md
@@ -0,0 +1,112 @@
+Node/TC39 outreach call
+
+January 7, 2019, 17:00 UTC
+
+Attendees:
+
+Daniel Ehrenberg
+
+Myles Borins
+
+Thomas Gentilhomme
+
+Sakthipriyan Vairamani
+
+Matteo Collina
+
+Michael Dawson
+
+Bradley Farias
+
+Gus Kaplan
+
+Joyee Cheung
+
+Ahmad Bamieh
+
+
+### Agenda and notes
+
+* Introductions (if necessary)
+* Purpose of this meeting
+    * Node has already been providing helpful feedback to TC39 (e.g., motivation for BigInt and private fields/methods), and I'd like to build on this
+    * Discuss how TC39 should collect and act on feedback from Node.js
+    * (If time allows) Technical review of some TC39 proposals
+
+## Organizational
+
+* Scope: Just TC39 standards
+    * Let's discuss Web platform APIs in [https://github.com/littledan/js-shared-interfaces/](https://github.com/littledan/js-shared-interfaces/) and [https://github.com/nodejs/open-standards/](https://github.com/nodejs/open-standards/) 
+* Interaction with the TC39 stage process
+    * Input on direction/priorities
+    * Feedback on Stage 2 or earlier proposals
+    * Distribute information about TC39, Stage 3+ proposals, etc
+    * Expose opportunities to get involved (in GitHub, docs, etc)
+* Initially discussion; in some cases, we could find agreement on something and jointly write a short summary for TC39
+
+### Discussion topics
+
+#### [Temporal proposal](https://github.com/tc39/proposal-temporal)
+
+* Introduction on Temporal
+    * Comprehensive, modern date-time library, as a built-in standard
+    * Multiple types
+    * Probably useful on the server side, both in Node Core and in the Node.js ecosystem
+    * How should we get a comprehensive review?
+* MD: what does Civil mean?
+    * BF & DE: not being timezone-specific
+    * Looking for details on the server-side environment, and feedback about the polyfill running on the servers
+* MC: is there a way to change the timezone on the server side
+    * DE: it’s system specific and handled by v8
+    * JC: there is an environment variable (forgot what that is) that you can change to have this effect
+    * GC: that’s process.env.TZ
+* MC: Is there an implementation?
+    * GC: [https://github.com/pipobscure/tc39-proposal-temporal](https://meet.google.com/linkredirect?authuser=0&dest=https%3A%2F%2Fgithub.com%2Fpipobscure%2Ftc39-proposal-temporal)
+    * MC: Can we potentially ship temporal as experimental in Node.js when it gets to Stage 3?
+    * GC: i think V8 would ship it, not node
+    * DE: Node should probably not in the shipping pipeline; it can be in npm and then in V8.
+    * BF: Node has some APIs which take numbers in milliseconds; if it's shipping in experimental, then we can apply usage of the new stdlib feature to Node Core, either in existing APIs or in a new APIs.
+    * DE: In those cases, would it make sense for Node to take a dependency on the npm module?
+    * QZ: It would be difficult to ship a new type in Node, given our strong compatibility guarantee. It'd be hard to go through the experimental process with this.
+    * BF: I agree, we should just create modules as examples of using host APIs with these new data types. We should probably figure out a process for, when new datatypes are added to JavaScript, how we want to prune things that are overlapping/similar. Luckily this is small for time in Node.
+* MD: is there a better channel to get feedback from Node, for example, broadcast about that from the Node.js twitter account?
+    * MB: We could tie into the CommComm user feedback initiative
+    * MD: We could explain to people what it is, how to use it, what it's for, etc, and we could collect the feedback and figure out next steps. We haven't found the best way to contact all the end users, but one thing we need is topics.
+    * DE: Maybe we could use this meeting to figure out how to set that feedback mechanism up.
+
+Concrete next steps:
+
+* MD: Bradley's suggestion is good; we need to find a volunteer (e.g., open an issue) to drive looking into this.
+* QZ: I think we can make a list, for specific proposals that may need some experimental examples that may need APIs built, we can make a list in the open standards repo, and try to get some help from there
+* MD: +1. Also, we can think about what different kinds of feedback--if we want to get more feedback from the Node.js collaborator base, we can open an issue at the right key point, or try to get it more broadly from end users (e.g., in the user feedback working group repo)
+* DE: Maybe we have a general framework here, 1. Experimental module 2. Gather feedback from collaborators 3. Gather feedback from the broader community.
+* MD: Experimenting would look different in different cases
+* BF: Here, there are existing date APIs, so that affects it. There's also the broad issue of, does this make it easier and harder to write programs, which we can do by examining existing ones. Node can make recommendations to champions about what to consider from Node Core, and leave it up to the champions for how to apply this advice.
+* MD: I think Joyee's issue about what's being requested is good, and then see if we can find people to volunteer to do that work.
+
+#### Built-in modules
+
+#### Top-level await
+
+#### Zones
+
+#### Realms
+
+#### [Observables](https://github.com/tc39/proposal-observable) (also [proposed](https://github.com/whatwg/dom/issues/544) in WHATWG)
+
+* Proposal is a bit dormant
+* Should we be pursuing this as a way to unify EventTarget with EventEmitter?
+* Or, another common event infrastructure?
+
+### Next steps
+
+* Would folks here be interested in following up and continuing to review TC39 proposals together?
+    * BF: I would love more meetings, but I would split it into two categories
+        * Document what kinds of feedback the champions want from Node before Node gives it back to champions, concretely how this affects Node Core, to give this to the champions. Counter-example is Zones, where Node disagrees with browsers, and it's a different kind of feedback
+        * Actually requesting specific feedback on specific proposals, so we can gather all the feedback on specific proposals, and pass it back to the champions.
+    * DE: How about we do this on GitHub mostly, and have a call for high-level coordination?
+        * BF: I'd be fine with just doing as-needed individual follow-up calls.
+    * MD: Do you have a regular meeting for open-standards?
+    * QZ: We don't have a regular meeting. I think I can create some lists for proposals that might be interesting for Node, with how to get involved, how to figure out what the related issues are; if we have enough momentum on a specific topic, people who are interested will naturally have calls.
+    * MD: I think people are definitely interested. Getting things started in GitHub first, and setting up a meeting
+    * QZ: I don't think it'd be productive for the group itself to have a call; not everyone in the group is interested in any one of them. I'd rather have calls focused on specific topics. When people are interested in the topic and think it's time to have a call, we can organize it. But beforehand, people should summarize different arguments and opinions, and set up an agenda to focus on working through the disagreements/areas where brainstorming is needed. I'll open up a process pull request to explain this model