doc: add 2018-04-25 notes

doc/meetings/2018-04-25.md

@@ -0,0 +1,104 @@
+# Node.js Foundation Modules Team Meeting 2018-04-25
+
+* **Recording**:  https://www.youtube.com/watch?v=Qbgryil1hEY
+* **GitHub Issue**: https://github.com/nodejs/modules/issues/71
+* **Minutes Google Doc**: https://docs.google.com/document/d/1bSH1eP_FFigXgsH9nPOhZUkrG51OzoIeNoZYReqlU8Y
+
+## Present
+
+- Benjamin Gruenbaum (@benjamingr)
+- C J Silverio (@ceejbot)
+- Daniel Rosenwasser (@DanielRosenwasser)
+- Geoffrey Booth(@GeoffreyBooth)
+- Gil Tayar (@giltayar)
+- Gus Caplan (@devsnek)
+- Guy Bedford (@guybedford)
+- Hassan Sani (@inidaname)
+- Jeremiah Senkpiel (@Fishrock123)
+- John-David Dalton (@jdalton)
+- Jordan Harband (@ljharb)
+- Matt DuLeone (@mduleone)
+- Michael Dawson (@mhdawson)
+- Michael Zasso (@targos)
+- Myles Borins (@MylesBorins)
+- Rob Palmer(@robpalme)
+- Saleh A Motaal (@smotaal)
+- Sven Sauleau (@xtuc)
+- Torgny Bjers (@tbjers)
+- Wesley Wigham (@weswigham)
+
+
+## Agenda
+
+Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
+
+### Approving PRs (5 Minute Time Box)
+
+* doc: update membership list with ncu-team sync [#66](https://github.com/nodejs/modules/pull/66)
+  * Objections?
+    * None; rebased and merged
+    * Myles will take action item here
+
+* doc: add meeting notes for 2018-04-11 [#64](https://github.com/nodejs/modules/pull/64)
+  * No objections
+* doc: add meeting notes for 2018-03-28 [#53](https://github.com/nodejs/modules/pull/53)
+  * Objections to landing based on formatting.
+  * Will land once formatting is fixed (no objections).
+
+* doc: add meeting notes for 2018-03-14 [#50](https://github.com/nodejs/modules/pull/50)
+
+* Expand and Refine Membership rules [#59](https://github.com/nodejs/modules/pull/59)
+  * Closes: Membership requirements [#43](https://github.com/nodejs/modules/issues/43)
+  * Makes an explicit definition between observers and active members
+  * Observers are not counted towards quorum requirements when seeking consensus
+  * Observers are still able to reject, but don't have a vote when seeking consensus towards quorum
+  * Objections?
+    * None.
+
+### Approving Observers (3 minute timebox)
+
+* Add Geoffrey (@GeoffreyBooth) as an observer [#56](https://github.com/nodejs/modules/issues/56) and [#63](https://github.com/nodejs/modules/pull/63)
+  * No objections
+* Add Sven as an observer (@xtuc) [#65](https://github.com/nodejs/modules/pull/65)
+  * No objections
+* Can I observe (@smotaal) [#68](https://github.com/nodejs/modules/issues/68)
+  * No objections
+
+### Discussion
+
+* Use Cases and Features [#55](https://github.com/nodejs/modules/issues/55)
+  - 40 minute time box
+  - Use Cases Doc: https://docs.google.com/document/d/10BBsIqdAXB9JR2KUzQGYbCiVugYBnxE4REBakX29yyo/edit
+    - JDalton:
+      - Last week we transitioned from reviewing use-cases to extracting features from them.
+      - Have tried to take a "yes, *and*" approach; no feature blocking
+      - More use-cases added since
+    - Geoffrey: added 36-38
+      - (36) Users compile from CoffeeScript, some modules use CJS, some use ESM, need to interoperate among tests
+      - Side note: any time CoffeeScript is mentioned, feel free to substitute in something like "Babel". Same concepts apply
+      - (37) CoffeeScript has a tool called `coffee` that runs CoffeeScript code the same way `node` runs JavaScript code; however, `coffee` has no way of knowing whether a module has been written as an ES Module or a CommonJS module.
+      - (38) Want to be able to just be able to eval some code and have it work the same way async/await just started working when it was added to the language.
+    - Wesley Wigham
+      - Want to be able to change as little code as possible when updating it; same way that when touching a file, a user might want to move from constructor functions to classes, or promises to async functions
+      - Transparent fine-grained bidirectional interop with minimal required changes
+    - Guy Bedford
+      - (22) People are going to want to run this code in the browser as well; they will need to have some guidance and a way to build for the browser and Node that will run with as few edge-cases as possible?
+      - Whatever ends up happening, semantics should be consistent in the browser and via bundled code shipped to the browser.
+      - Saleh: having to use "browser-compatible paths" has been a general pain-point
+	(meant `import path from ‘path’` is an illegal specifier for browsers - alternatives?)
+        - Package name maps may actually address this issue.
+    - Rob Palmer
+      - (22) People don't like writing long sequences of `../../../[...]`.
+        - JDD: Probably fits under specifier resolution; maybe specifier resolution customization.
+      - (24) Also falls under the umbrella from custom specifier resolution
+      - Assertion: this should all work without a build tool.
+      - (25) Package encapsulation - ensuring only explicit named entrypoints/file can be importer by code outside the package
+      - (26) Would like to have an alternative resolution strategy; potentially a resolver plugin.
+    - (28) Want to be able to import dependencies and target the web without using any build tools
+    - (29) consistent understanding between development tools (IDEs, build tools, etc.)
+      - Could imagine that the resolution algorithm could be based around a plugin system
+    - (30) JDD: still belives this relates to resolution customization
+    - (31) Likely relates to transparent inteorp
+    - (33) Need to wait on Justin to confirm what he has in mind.
+
+  - Features Doc: https://docs.google.com/document/d/1HuH5E1d_mNuziBxPDRZVjpdfmUPhqVg0MUUcYDnqwn8/edit#heading=h.sm27azjyrwql