|
| 1 | +# Node.js Foundation Modules Team Meeting 2018-02-28 |
| 2 | + |
| 3 | +## Links |
| 4 | + |
| 5 | +* **Recording**: http://www.youtube.com/watch?v=PO07agjJ_1Y |
| 6 | +* **GitHub Issue**: https://github.com/nodejs/modules/issues/36 |
| 7 | +* **Minutes Google Doc**: https://docs.google.com/document/d/1ZA_0tK8ZKoo1Lh2kLl-DIckVnYb7rOV-ASjrsjEW3mI/edit |
| 8 | + |
| 9 | +## Present |
| 10 | + |
| 11 | +Myles Borins (@MylesBorins) |
| 12 | +Wesley Wigham (@weswigham) |
| 13 | +Bradley Farias (@bmeck) |
| 14 | +C J Silverio (@ceejbot) |
| 15 | +Torgny Bjers (@tbjers) |
| 16 | +Dan DuLeone (@dduleone) |
| 17 | +Lin Clark (@linclark) |
| 18 | +Gil Tayar (@giltayar) |
| 19 | +Gus Caplan (@devsnek) |
| 20 | +Guy Bedford (@guybedford) |
| 21 | +Rebecca Turner (@iarna) |
| 22 | +Hassan Sani (@inidaname) |
| 23 | +Matt DuLeone (@mduleone) |
| 24 | +Chris Dickinson (@chrisdickinson) |
| 25 | +Jeremiah Senkpiel (@Fishrock123) |
| 26 | +Michael Zasso (@targos) |
| 27 | +Benjamin Gruenbaum (@benjamingr) |
| 28 | +Daniel Rosenwasser (@DanielRosenwasser) |
| 29 | +Justin Fagnani (@justinfagnani) |
| 30 | +Matteo Collina (@mcollina) |
| 31 | +Ben Newman (@benjamn) |
| 32 | +John-David Dalton (@jdalton) |
| 33 | +Michael Dawson (@mhdawson) |
| 34 | +Jan Krems (@jkrems) |
| 35 | + |
| 36 | +## Agenda |
| 37 | + |
| 38 | +### Announcements |
| 39 | + |
| 40 | +* raising hands to talk (UI in participants list) |
| 41 | +* could use someone to take notes |
| 42 | +* post youtube link please |
| 43 | + |
| 44 | +### nodejs/modules |
| 45 | + |
| 46 | +* Online Module Summit [#9](https://github.com/nodejs/modules/issues/9) |
| 47 | + - Target date: end of March, beginning of April, post-upcoming-TC39 - meeting |
| 48 | + - Probably will be closer to UTC than other timezones. |
| 49 | + - Fill the Doodle if you want to attend! |
| 50 | + - You can suggest topics for discussion at the summit in the above issue. |
| 51 | + |
| 52 | +* doc: add meeting notes for Feb 14 2018 [#27](https://github.com/nodejs/modules/pull/27) |
| 53 | + - Notes from the last meeting |
| 54 | + - Any problems? |
| 55 | + - Nope. |
| 56 | + - Merged! |
| 57 | + |
| 58 | +* doc: move code of conduct to CODE_OF_CONDUCT.md [#29](https://github.com/nodejs/modules/pull/29) |
| 59 | + - Moves Code of Conduct out of the Governance document. |
| 60 | + - Objections? |
| 61 | + - Nope. |
| 62 | + - Merged! |
| 63 | + |
| 64 | +* Document quorum required in order to merge PRs [#26](https://github.com/nodejs/modules/pull/26) |
| 65 | + - Outstanding block from James Snell |
| 66 | + - Brad: background: wanted to seek quorum during meetings |
| 67 | + - James felt that we shouldn’t need to wait for meetings to merge PRs. |
| 68 | + - Could be okay to just wait for meetings to merge PRs given the small amount of time between meetings. |
| 69 | + - Editorial & Errata changes probably okay - don’t need a meeting to merge those types of PRs in. |
| 70 | + - Matteo: Can probably roll with this for now, but may want to revisit this to address James’ feedback. |
| 71 | + - Brad: Clarifying question: can’t merge into node itself, or nodejs/modules? |
| 72 | + - 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. |
| 73 | + - Myles: Have 3-4 items on agenda that will directly touch this; let’s move forward for now. |
| 74 | + - Objections? |
| 75 | + - Consensus, let’s merge it in. |
| 76 | + |
| 77 | +* doc: s/Google Hangouts/Zoom [#34](https://github.com/nodejs/modules/pull/34) |
| 78 | + - Concerns? |
| 79 | + - Silence |
| 80 | + - Conclusion: Landed |
| 81 | + |
| 82 | +* Governance and Membership Requirements [#8](https://github.com/nodejs/modules/issues/8) |
| 83 | + - 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. |
| 84 | + - 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. |
| 85 | + - Request to keep people around who didn’t get the chance to fill out the Doodle last time. |
| 86 | + - Perhaps we want to just keep everyone as members until we actually hit a problem? |
| 87 | + - Wesley: what percentage is quorum? |
| 88 | + - 1 person above 50% of total membership |
| 89 | + - But we only have the exact quorum of people here today |
| 90 | + - Actually we have 26! |
| 91 | + - We had 21 just a few minutes ago |
| 92 | + - That’s indeed why we had a concern originally. |
| 93 | + - Anyone who’s observer status: anyone have an objection to having been moved over? |
| 94 | + - LJHarb: may need a more comprehensive criteria of participation; lots of anxiety about what engagement means given other obligations. |
| 95 | + - Brad: Quorum PR had a timeline for how quickly PRs can be merged in; potentially should address concerns of participation? |
| 96 | + - Myles: proposal so that people moved to observer status can request to be moved back to participators |
| 97 | + - Jan: idea of moving people to observer status and then making them go through a process seems unnecessary |
| 98 | + - MichaelD: Either reverse or send an email to the list with the request to renew membership |
| 99 | + - Hassan: process was confusing, we need a more agreeable standard to move people to observer status |
| 100 | + - 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. |
| 101 | + - Objections? |
| 102 | + - None |
| 103 | + - Proceed. |
| 104 | + |
| 105 | +* maintain a summary document/website [#35](https://github.com/nodejs/modules/issues/35) |
| 106 | + - Let’s timebox to 5 minutes? |
| 107 | + - Gus C: community as a whole seems pretty disengaged from what’s going on, hard for people to keep track of node eps |
| 108 | + - Want to keep the community informed about where things stand here. |
| 109 | + - 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? |
| 110 | + - tbranyen: would be helpful to have an FAQ-style list to explain how things get to where they are. |
| 111 | + - Brad: will probably be months before we want to put anything on the website |
| 112 | + - 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? |
| 113 | + - Matteo: There’s definitely a need in the community to understand why things are the way which they are. |
| 114 | + - Rebecca: When we come to consensus on things, that’s probably the appropriate time to add it to this document. |
| 115 | + - Myles: maybe add something to document things like knowns, known unknowns, etc. |
| 116 | + - Gil: this sort of thing may slow us down |
| 117 | + - Wesley: context for why things are the way they are may be more important than just how things are. |
| 118 | + - Jeremiah: high level objectives might be good to put into that document. |
| 119 | + - Conclusion: kick it back to the repo, bring it up in the next meeting |
| 120 | + |
| 121 | +* Scope of team [#17](https://github.com/nodejs/modules/issues/17) |
| 122 | +* Guiding Design Principles [#11](https://github.com/nodejs/modules/issues/11) |
| 123 | +* initial GOALS declaration [#23](https://github.com/nodejs/modules/pull/23) |
| 124 | + - CJ: request a reset of the goals document |
| 125 | + - Would like the group to back up and take a more user-centric approach |
| 126 | + - List use-cases we want to support with ESM, with interop, and more. |
| 127 | + - Allows us to focus on the problem: how will Node users write with ES modules to write JS programs. |
| 128 | + - Implementations will fall out more easily given the use-cases we want to support. |
| 129 | + - Matteo: there is a spec which gives Node leeway, but a lot of behavior is dictated by the spec. |
| 130 | + - Can end up with Babel modules if we just go against the spec. |
| 131 | + - Brad |
| 132 | + - When we talk about “user-centric” goals, agree; we should remove any goals that are driven by implementation-details. |
| 133 | + - Would also like not to talk purely about how CommonJS works. |
| 134 | + - Have to think about how the web browsers work; we can’t dictate how browsers will work. |
| 135 | + - LJHarb |
| 136 | + - use-cases are best way to explain why we are making the decisions which we are. |
| 137 | + - Use-cases are also what motivated current implementation; see this as less of a reset, more of a review |
| 138 | + - 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 |
| 139 | + - Jan: use-cases can be motivated by how Node users use CommonJS today |
| 140 | + - 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 |
| 141 | + |
| 142 | +### nodejs/node |
| 143 | + |
| 144 | +* esm: Implement esm mode flag [#18392](https://github.com/nodejs/node/pull/18392) |
| 145 | + - https://docs.google.com/presentation/d/1xK1ana_TIxfAHX33CYVHFnJsV0If_YirLtRBBga9cv0/edit?usp=sharing |
| 146 | + - Builds on proposal of using .mjs a differentiator as well as wykatz’s “In Defense of .js” |
| 147 | + - Introduces a ‘module’ field to package.json |
| 148 | + - Problems with module field: Most build tools will use ambiguous syntax detection mechanisms in conjunction with the ‘module’ field. |
| 149 | + - 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. |
| 150 | + - Pros |
| 151 | + - Enables .js in Node for ES modules |
| 152 | + - Provides relatively simple interop in the ecosystem |
| 153 | + - Packages can upgrade to ES Modules as a non-breaking change. |
| 154 | + - Build tools already work similarly; integrating with that would be ideal |
| 155 | + - Myles |
| 156 | + - bring questions/comments/concerns to the PR itself |
| 157 | + - How do we want to interact with PRs in core itself? |
| 158 | + - Rebecca |
| 159 | + - Should discourage any module-related work in core. |
| 160 | + - Would feel bad for contributors if any work was overridden. |
| 161 | + - Brad |
| 162 | + - Have spent >4 years working on this; expect wasted work |
| 163 | + - With an implementation, we can see implementation problems themselves. |
| 164 | + - So don’t want to stop ongoing work |
| 165 | + - Myles: will open issue to discuss ways to deal with conflict within the group |
| 166 | + - Guy |
| 167 | + - keep in mind, things that might be considered a reset might actually be fairly small changes in practice |
| 168 | + - Also: please look at PR! Can be merged in, but lacks critical feedback currently. |
| 169 | + |
| 170 | +## Q&A, Other |
| 171 | + |
| 172 | +* Did not have time to do Q/A |
| 173 | + |
| 174 | +## Upcoming Meetings |
| 175 | + |
| 176 | +* **Node.js Foundation Calendar**: https://nodejs.org/calendar |
| 177 | + |
| 178 | +Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. |
0 commit comments