diff --git a/doc/meetings/2018-02-28.md b/doc/meetings/2018-02-28.md new file mode 100644 index 0000000..1b8e2b2 --- /dev/null +++ b/doc/meetings/2018-02-28.md @@ -0,0 +1,179 @@ +# Node.js Foundation Modules Team Meeting 2018-02-28 + +## Links + +* **Recording**: http://www.youtube.com/watch?v=PO07agjJ_1Y +* **GitHub Issue**: https://github.com/nodejs/modules/issues/36 +* **Minutes Google Doc**: https://docs.google.com/document/d/1ZA_0tK8ZKoo1Lh2kLl-DIckVnYb7rOV-ASjrsjEW3mI/edit + +## Present + +Myles Borins (@MylesBorins) +Wesley Wigham (@weswigham) +Bradley Farias (@bmeck) +C J Silverio (@ceejbot) +Torgny Bjers (@tbjers) +Dan DuLeone (@dduleone) +Lin Clark (@linclark) +Gil Tayar (@giltayar) +Gus Caplan (@devsnek) +Guy Bedford (@guybedford) +Rebecca Turner (@iarna) +Hassan Sani (@inidaname) +Matt DuLeone (@mduleone) +Chris Dickinson (@chrisdickinson) +Jeremiah Senkpiel (@Fishrock123) +Michael Zasso (@targos) +Benjamin Gruenbaum (@benjamingr) +Daniel Rosenwasser (@DanielRosenwasser) +Justin Fagnani (@justinfagnani) +Matteo Collina (@mcollina) +Ben Newman (@benjamn) +John-David Dalton (@jdalton) +Michael Dawson (@mhdawson) +Jan Krems (@jkrems) +Jordan Harband (@ljharb) + +## Agenda + +### Announcements + +* raising hands to talk (UI in participants list) +* could use someone to take notes +* post youtube link please + +### nodejs/modules + +* Online Module Summit [#9](https://github.com/nodejs/modules/issues/9) + - Target date: end of March, beginning of April, post-upcoming-TC39 - meeting + - Probably will be closer to UTC than other timezones. + - Fill the Doodle if you want to attend! + - You can suggest topics for discussion at the summit in the above issue. + +* doc: add meeting notes for Feb 14 2018 [#27](https://github.com/nodejs/modules/pull/27) + - Notes from the last meeting + - Any problems? + - Nope. + - Merged! + +* doc: move code of conduct to CODE_OF_CONDUCT.md [#29](https://github.com/nodejs/modules/pull/29) + - Moves Code of Conduct out of the Governance document. + - Objections? + - Nope. + - Merged! + +* Document quorum required in order to merge PRs [#26](https://github.com/nodejs/modules/pull/26) + - Outstanding block from James Snell + - Brad: background: wanted to seek quorum during meetings + - James felt that we shouldn’t need to wait for meetings to merge PRs. + - Could be okay to just wait for meetings to merge PRs given the small amount of time between meetings. + - Editorial & Errata changes probably okay - don’t need a meeting to merge those types of PRs in. + - Matteo: Can probably roll with this for now, but may want to revisit this to address James’ feedback. + - Brad: Clarifying question: can’t merge into node itself, or nodejs/modules? + - CJ: Hard part will be identifying consensus and documenting clearly. Any work that is done before that is work that will potentially have to be backed out. + - Myles: Have 3-4 items on agenda that will directly touch this; let’s move forward for now. + - Objections? + - Consensus, let’s merge it in. + +* doc: s/Google Hangouts/Zoom [#34](https://github.com/nodejs/modules/pull/34) + - Concerns? + - Silence + - Conclusion: Landed + +* Governance and Membership Requirements [#8](https://github.com/nodejs/modules/issues/8) + - At the end of the last meeting, we reached quorum/consensus that people who haven’t filled in the Doodle would be moved into observer status. + - Some individuals felt that this was not in the spirit of the Node foundation; potentially a pre-optimization for a problem that hasn’t occurred. + - Request to keep people around who didn’t get the chance to fill out the Doodle last time. + - Perhaps we want to just keep everyone as members until we actually hit a problem? + - Wesley: what percentage is quorum? + - 1 person above 50% of total membership + - But we only have the exact quorum of people here today + - Actually we have 26! + - We had 21 just a few minutes ago + - That’s indeed why we had a concern originally. + - Anyone who’s observer status: anyone have an objection to having been moved over? + - LJHarb: may need a more comprehensive criteria of participation; lots of anxiety about what engagement means given other obligations. + - Brad: Quorum PR had a timeline for how quickly PRs can be merged in; potentially should address concerns of participation? + - Myles: proposal so that people moved to observer status can request to be moved back to participators + - Jan: idea of moving people to observer status and then making them go through a process seems unnecessary + - MichaelD: Either reverse or send an email to the list with the request to renew membership + - Hassan: process was confusing, we need a more agreeable standard to move people to observer status + - Myles: would like to move people from observer status back to participants, figure out what to do when we actually hit a problem with quorum. + - Objections? + - None + - Proceed. + +* maintain a summary document/website [#35](https://github.com/nodejs/modules/issues/35) + - Let’s timebox to 5 minutes? + - Gus C: community as a whole seems pretty disengaged from what’s going on, hard for people to keep track of node eps + - Want to keep the community informed about where things stand here. + - Brad: Originally tried to use a wiki for this, became a dumping ground for different interop ideas. Without a known state of things, does it make sense to explain the current state of things? + - tbranyen: would be helpful to have an FAQ-style list to explain how things get to where they are. + - Brad: will probably be months before we want to put anything on the website + - Myles: does it make sense to at least start thinking about where the site will live/what it will look like/what the copy will be like? + - Matteo: There’s definitely a need in the community to understand why things are the way which they are. + - Rebecca: When we come to consensus on things, that’s probably the appropriate time to add it to this document. + - Myles: maybe add something to document things like knowns, known unknowns, etc. + - Gil: this sort of thing may slow us down + - Wesley: context for why things are the way they are may be more important than just how things are. + - Jeremiah: high level objectives might be good to put into that document. + - Conclusion: kick it back to the repo, bring it up in the next meeting + +* Scope of team [#17](https://github.com/nodejs/modules/issues/17) +* Guiding Design Principles [#11](https://github.com/nodejs/modules/issues/11) +* initial GOALS declaration [#23](https://github.com/nodejs/modules/pull/23) + - CJ: request a reset of the goals document + - Would like the group to back up and take a more user-centric approach + - List use-cases we want to support with ESM, with interop, and more. + - Allows us to focus on the problem: how will Node users write with ES modules to write JS programs. + - Implementations will fall out more easily given the use-cases we want to support. + - Matteo: there is a spec which gives Node leeway, but a lot of behavior is dictated by the spec. + - Can end up with Babel modules if we just go against the spec. + - Brad + - When we talk about “user-centric” goals, agree; we should remove any goals that are driven by implementation-details. + - Would also like not to talk purely about how CommonJS works. + - Have to think about how the web browsers work; we can’t dictate how browsers will work. + - LJHarb + - use-cases are best way to explain why we are making the decisions which we are. + - Use-cases are also what motivated current implementation; see this as less of a reset, more of a review + - CJ: spec is a living document; spec shapes how we implement, but if we find a place where the spec is incompatible with the use-cases we have in mind, we should bring that to TC39 to explain how ECMA-262 is not allowing Node to provide those use-cases + - Jan: use-cases can be motivated by how Node users use CommonJS today + - Justin F: want to bring web perspective, think more about ergonomics about modules on the web, use this as a way to provide feedback to bring a solid experience to both ecosystems + +### nodejs/node + +* esm: Implement esm mode flag [#18392](https://github.com/nodejs/node/pull/18392) + - https://docs.google.com/presentation/d/1xK1ana_TIxfAHX33CYVHFnJsV0If_YirLtRBBga9cv0/edit?usp=sharing + - Builds on proposal of using .mjs a differentiator as well as wykatz’s “In Defense of .js” + - Introduces a ‘module’ field to package.json + - Problems with module field: Most build tools will use ambiguous syntax detection mechanisms in conjunction with the ‘module’ field. + - Idea: for a .js file, walk up to a package.json, see if it has “mode”: “esm”, treat it as an ES module if so. + - Pros + - Enables .js in Node for ES modules + - Provides relatively simple interop in the ecosystem + - Packages can upgrade to ES Modules as a non-breaking change. + - Build tools already work similarly; integrating with that would be ideal + - Myles + - bring questions/comments/concerns to the PR itself + - How do we want to interact with PRs in core itself? + - Rebecca + - Should discourage any module-related work in core. + - Would feel bad for contributors if any work was overridden. + - Brad + - Have spent >4 years working on this; expect wasted work + - With an implementation, we can see implementation problems themselves. + - So don’t want to stop ongoing work + - Myles: will open issue to discuss ways to deal with conflict within the group + - Guy + - keep in mind, things that might be considered a reset might actually be fairly small changes in practice + - Also: please look at PR! Can be merged in, but lacks critical feedback currently. + +## Q&A, Other + +* Did not have time to do Q/A + +## Upcoming Meetings + +* **Node.js Foundation Calendar**: https://nodejs.org/calendar + +Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.