forked from nodejs/modules
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
doc: add meeting notes for 2018-02-28
- Loading branch information
1 parent
198b66a
commit af7d918
Showing
1 changed file
with
179 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. |