diff --git a/meetings/2024-11-20.md b/meetings/2024-11-20.md new file mode 100644 index 00000000..f9b33d55 --- /dev/null +++ b/meetings/2024-11-20.md @@ -0,0 +1,153 @@ +# Node.js Technical Steering Committee (TSC) Meeting 2024-11-20 + +## Links + +* **Recording**: +* **Minutes Google Doc**: + +## Present + +* Antoine du Hamel @aduh95 (voting member) +* Yagiz Nizipli @anonrig (voting member) + +* Ruben Bridgewater @BridgeAR (voting member) +* Joyee Cheung @joyeecheung (voting member) +* Marco Ippolito @marco-ippolito (voting member) +* Matteo Collina @mcollina (voting member) +* Michael Dawson @mhdawson (voting member) +* Moshe Atlow @MoLow (voting member) +* Richard Lau @richardlau (voting member) +* Ruy Adorno @ruyadorno (voting member) +* Paolo Insogna @ShogunPanda (voting member) + +## Agenda + +### Announcements + +* Marco: 20.18.1 just released, kudos to Antoine for helping to automate release process. +* Matteo: GitHub program for security open source, we can get some $ if some of us go + through some training. Good way to skill up on security issues. 5-10 hour commitment + per week. Matteo will open an issue. + +### Reminders + +* Remember to nominate people for the [contributor spotlight](https://github.com/nodejs/node/blob/main/doc/contributing/reconizing-contributors.md#bi-monthly-contributor-spotlight) + +### CPC and Board Meeting Updates + +*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting. + +* Matteo, from the Board the biggest topic is planning for next year. The biggest expense will be + the conference. CFP opening soon, need to discuss if we are going to do a collab summit + there. + * Express project is becoming an impact project as project has improved governance and level + of activity. + +### nodejs/node + +* test: improve zlib tests [#55716](https://github.com/nodejs/node/pull/55716) + * Yagiz: the pull request uses node tests where it was not used before. Reasoning + for change -> we currently have two test runners, current test runner depends on things + that other runtimes don’t have. Hard to do without node test. Since there are not + requirements for naming and descriptions which has led to duplicate tests. + * Michael, one question from last time. Using node:test to help let other runtimes run + tests seems to be going into the opposite direction. + * Joyee: took a brief look. Previously they were not wrapped in an async direction, don’t + see how it's different/improved from my look at the tests that have been updated so far. + * In terms of missing descriptions, we could just improve comments. Just because node-test + requires a description does not mean that description will really be better as people + could add a 1 letter description. + * Yagiz, there are already tests that use node-test. See this as an opportunity to clarify + what the future direction should be. + * Joyee, have found it harder to find test failure with node-test. As far of these tests they + don’t really look like porting them to node-test improves. + * Yagiz, no requirement, but while working on these tests for workers, found it hard to work + with them, and thought this will help the community tests. We could close this PR, but we + need common discussion about the direction. + * Michael, possibly add doc to collaborator doc to capture the direction, form consensus there. + * Ruy, last code and learn had people moving to node-test. But seems like there was not + necessarily consensus on that. + * Yagiz, consensus on using external test runner? + * Matteo, don’t think we do. In particular we should not test things it depends + on with itself (for example process, etc.). For other things possibly ok + * Matteo, promise with resolvers (currently available after 22.x), prefer if we hold back + on that due to compatibility with older versions. + * Yagiz, kind of agree with not using node test runner to test the dependencies. Can work + around promise with resolvers by creating work around. + * Joyee, have you checked what kind of stack trace you see with promise with resolves + versus what we get with the common.must_not_call. If improves stack trace them more + positive, if it makes the stack trace less useful then negative. + * Yagiz open PR to contributor guidelines to document things like “don’t use node test runner + for deps” and use it to build/document consensus. + +* assert: add partialDeepStrictEqual [#54630](https://github.com/nodejs/node/pull/54630) + * added a while back as there was not consensus on the name + * Ruben, name is agreed now but still work before it can land. + * Marco, it does not work 100% yet, still some technical issues, proposal is to land + as experimental and then iterate. + * No longer blocker, can be removed from the agenda. + +### nodejs/nodejs.org + +* Add Vetted Courses [#7201](https://github.com/nodejs/nodejs.org/issues/7201) + * Matteo, will PR in and we will discuss and deal with any blockers there. + +* feat: add streams guide [#7123](https://github.com/nodejs/nodejs.org/pull/7123) + * Matteo planning to look in next week or so. Leave on the agenda for now. + +### nodejs/TSC + +* Clarify the Charter so that contractors are explicity counted as affialiated [#1650](https://github.com/nodejs/TSC/pull/1650) + * On the agenda as FYI to the TSC. + * No objections in the issue now, Matteo will take to the CPC for approval. + +* Let's talk about the CI situation [#1614](https://github.com/nodejs/TSC/issues/1614) + * Nothing to chat about this week. + +* Open OpenCollective and Github Sponsors for Node.js [#1553](https://github.com/nodejs/TSC/issues/1553) + * On agenda to get TSC members thinking about, discuss more based on situation next week. + +### nodejs/package-examples + +* Starting a team for the package examples initiative [#3](https://github.com/nodejs/package-examples/issues/3) + * Good to mention in the TSC meeting, to better document EJS/CJS usage and provide + better more up to date examples, similar to node-addon-examples. + * Idea is to delegate to the package maintenance team and others who are interested + Challenge is that we’ve had people join teams but then not be active. + * Michael, if somebody becomes active enough they could join existing teams? As + long as those teams agree, makes sense to me. + * No objections + +### nodejs/bluesky + +* Who should have access for this repository? [#2](https://github.com/nodejs/bluesky/issues/2) + * + * Joyee, give access to some existing teams + * Michael, model that would work the best is to define the content that is ok to post, and then + Trust people to post the right thing. + * Matteo, issue is that we also need people who will respond, best option is likely to delegate + to the foundation to post/respond + * Matteo, some specific things (like announce of new collaborator) less review for others + we’d need a more detailed review. + * Joyee, agree that similar to fast track process we can get some stuff out more quickly + * In terms of replies we can also have some automation, also not everything would need to go + through the repo, we can have additional access to foundation staff so they can post/reply + directly as well. + * Other issue about how many accounts. Seems like we can start with one, if there is energy + about spinning off more. Keep in mind that we may have more in the future. + * Michael, agree that starting with one makes sense, challenge before was belief that news + about the project was not appropriate for the main Node.js account. + * Matteo, believe current bluesky audience will be interested in what is going on in the project. + * Joyee, social should be social, and should be more interactive. We can start with one and + The we can poll for whether people want more or less content. + * Michael, having the main account repost peoples posts would be an important part of the + of our approach. + * Joyee the sdk is quite flexible. + +## Strategic Initiatives + +## Upcoming Meetings + +* **Node.js Project Calendar**: + +Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.