|
| 1 | +# Node.js Technical Steering Committee (TSC) Meeting 2024-11-20 |
| 2 | + |
| 3 | +## Links |
| 4 | + |
| 5 | +* **Recording**: <https://youtube.com/live/ev_8e8UVfNY> |
| 6 | +* **Minutes Google Doc**: <https://github.com/nodejs/TSC/issues/1652> |
| 7 | + |
| 8 | +## Present |
| 9 | + |
| 10 | +* Antoine du Hamel @aduh95 (voting member) |
| 11 | +* Yagiz Nizipli @anonrig (voting member) |
| 12 | + |
| 13 | +* Ruben Bridgewater @BridgeAR (voting member) |
| 14 | +* Joyee Cheung @joyeecheung (voting member) |
| 15 | +* Marco Ippolito @marco-ippolito (voting member) |
| 16 | +* Matteo Collina @mcollina (voting member) |
| 17 | +* Michael Dawson @mhdawson (voting member) |
| 18 | +* Moshe Atlow @MoLow (voting member) |
| 19 | +* Richard Lau @richardlau (voting member) |
| 20 | +* Ruy Adorno @ruyadorno (voting member) |
| 21 | +* Paolo Insogna @ShogunPanda (voting member) |
| 22 | + |
| 23 | +## Agenda |
| 24 | + |
| 25 | +### Announcements |
| 26 | + |
| 27 | +* Marco: 20.18.1 just released, kudos to Antoine for helping to automate release process. |
| 28 | +* Matteo: GitHub program for security open source, we can get some $ if some of us go |
| 29 | + through some training. Good way to skill up on security issues. 5-10 hour commitment |
| 30 | + per week. Matteo will open an issue. |
| 31 | + |
| 32 | +### Reminders |
| 33 | + |
| 34 | +* Remember to nominate people for the [contributor spotlight](https://github.com/nodejs/node/blob/main/doc/contributing/reconizing-contributors.md#bi-monthly-contributor-spotlight) |
| 35 | + |
| 36 | +### CPC and Board Meeting Updates |
| 37 | + |
| 38 | +*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting. |
| 39 | + |
| 40 | +* Matteo, from the Board the biggest topic is planning for next year. The biggest expense will be |
| 41 | + the conference. CFP opening soon, need to discuss if we are going to do a collab summit |
| 42 | + there. |
| 43 | + * Express project is becoming an impact project as project has improved governance and level |
| 44 | + of activity. |
| 45 | + |
| 46 | +### nodejs/node |
| 47 | + |
| 48 | +* test: improve zlib tests [#55716](https://github.com/nodejs/node/pull/55716) |
| 49 | + * Yagiz: the pull request uses node tests where it was not used before. Reasoning |
| 50 | + for change -> we currently have two test runners, current test runner depends on things |
| 51 | + that other runtimes don’t have. Hard to do without node test. Since there are not |
| 52 | + requirements for naming and descriptions which has led to duplicate tests. |
| 53 | + * Michael, one question from last time. Using node:test to help let other runtimes run |
| 54 | + tests seems to be going into the opposite direction. |
| 55 | + * Joyee: took a brief look. Previously they were not wrapped in an async direction, don’t |
| 56 | + see how it's different/improved from my look at the tests that have been updated so far. |
| 57 | + * In terms of missing descriptions, we could just improve comments. Just because node-test |
| 58 | + requires a description does not mean that description will really be better as people |
| 59 | + could add a 1 letter description. |
| 60 | + * Yagiz, there are already tests that use node-test. See this as an opportunity to clarify |
| 61 | + what the future direction should be. |
| 62 | + * Joyee, have found it harder to find test failure with node-test. As far of these tests they |
| 63 | + don’t really look like porting them to node-test improves. |
| 64 | + * Yagiz, no requirement, but while working on these tests for workers, found it hard to work |
| 65 | + with them, and thought this will help the community tests. We could close this PR, but we |
| 66 | + need common discussion about the direction. |
| 67 | + * Michael, possibly add doc to collaborator doc to capture the direction, form consensus there. |
| 68 | + * Ruy, last code and learn had people moving to node-test. But seems like there was not |
| 69 | + necessarily consensus on that. |
| 70 | + * Yagiz, consensus on using external test runner? |
| 71 | + * Matteo, don’t think we do. In particular we should not test things it depends |
| 72 | + on with itself (for example process, etc.). For other things possibly ok |
| 73 | + * Matteo, promise with resolvers (currently available after 22.x), prefer if we hold back |
| 74 | + on that due to compatibility with older versions. |
| 75 | + * Yagiz, kind of agree with not using node test runner to test the dependencies. Can work |
| 76 | + around promise with resolvers by creating work around. |
| 77 | + * Joyee, have you checked what kind of stack trace you see with promise with resolves |
| 78 | + versus what we get with the common.must_not_call. If improves stack trace them more |
| 79 | + positive, if it makes the stack trace less useful then negative. |
| 80 | + * Yagiz open PR to contributor guidelines to document things like “don’t use node test runner |
| 81 | + for deps” and use it to build/document consensus. |
| 82 | + |
| 83 | +* assert: add partialDeepStrictEqual [#54630](https://github.com/nodejs/node/pull/54630) |
| 84 | + * added a while back as there was not consensus on the name |
| 85 | + * Ruben, name is agreed now but still work before it can land. |
| 86 | + * Marco, it does not work 100% yet, still some technical issues, proposal is to land |
| 87 | + as experimental and then iterate. |
| 88 | + * No longer blocker, can be removed from the agenda. |
| 89 | + |
| 90 | +### nodejs/nodejs.org |
| 91 | + |
| 92 | +* Add Vetted Courses [#7201](https://github.com/nodejs/nodejs.org/issues/7201) |
| 93 | + * Matteo, will PR in and we will discuss and deal with any blockers there. |
| 94 | + |
| 95 | +* feat: add streams guide [#7123](https://github.com/nodejs/nodejs.org/pull/7123) |
| 96 | + * Matteo planning to look in next week or so. Leave on the agenda for now. |
| 97 | + |
| 98 | +### nodejs/TSC |
| 99 | + |
| 100 | +* Clarify the Charter so that contractors are explicity counted as affialiated [#1650](https://github.com/nodejs/TSC/pull/1650) |
| 101 | + * On the agenda as FYI to the TSC. |
| 102 | + * No objections in the issue now, Matteo will take to the CPC for approval. |
| 103 | + |
| 104 | +* Let's talk about the CI situation [#1614](https://github.com/nodejs/TSC/issues/1614) |
| 105 | + * Nothing to chat about this week. |
| 106 | + |
| 107 | +* Open OpenCollective and Github Sponsors for Node.js [#1553](https://github.com/nodejs/TSC/issues/1553) |
| 108 | + * On agenda to get TSC members thinking about, discuss more based on situation next week. |
| 109 | + |
| 110 | +### nodejs/package-examples |
| 111 | + |
| 112 | +* Starting a team for the package examples initiative [#3](https://github.com/nodejs/package-examples/issues/3) |
| 113 | + * Good to mention in the TSC meeting, to better document EJS/CJS usage and provide |
| 114 | + better more up to date examples, similar to node-addon-examples. |
| 115 | + * Idea is to delegate to the package maintenance team and others who are interested |
| 116 | + Challenge is that we’ve had people join teams but then not be active. |
| 117 | + * Michael, if somebody becomes active enough they could join existing teams? As |
| 118 | + long as those teams agree, makes sense to me. |
| 119 | + * No objections |
| 120 | + |
| 121 | +### nodejs/bluesky |
| 122 | + |
| 123 | +* Who should have access for this repository? [#2](https://github.com/nodejs/bluesky/issues/2) |
| 124 | + * <https://github.com/nodejs/bluesky/issues/2> |
| 125 | + * Joyee, give access to some existing teams |
| 126 | + * Michael, model that would work the best is to define the content that is ok to post, and then |
| 127 | + Trust people to post the right thing. |
| 128 | + * Matteo, issue is that we also need people who will respond, best option is likely to delegate |
| 129 | + to the foundation to post/respond |
| 130 | + * Matteo, some specific things (like announce of new collaborator) less review for others |
| 131 | + we’d need a more detailed review. |
| 132 | + * Joyee, agree that similar to fast track process we can get some stuff out more quickly |
| 133 | + * In terms of replies we can also have some automation, also not everything would need to go |
| 134 | + through the repo, we can have additional access to foundation staff so they can post/reply |
| 135 | + directly as well. |
| 136 | + * Other issue about how many accounts. Seems like we can start with one, if there is energy |
| 137 | + about spinning off more. Keep in mind that we may have more in the future. |
| 138 | + * Michael, agree that starting with one makes sense, challenge before was belief that news |
| 139 | + about the project was not appropriate for the main Node.js account. |
| 140 | + * Matteo, believe current bluesky audience will be interested in what is going on in the project. |
| 141 | + * Joyee, social should be social, and should be more interactive. We can start with one and |
| 142 | + The we can poll for whether people want more or less content. |
| 143 | + * Michael, having the main account repost peoples posts would be an important part of the |
| 144 | + of our approach. |
| 145 | + * Joyee the sdk is quite flexible. |
| 146 | + |
| 147 | +## Strategic Initiatives |
| 148 | + |
| 149 | +## Upcoming Meetings |
| 150 | + |
| 151 | +* **Node.js Project Calendar**: <https://nodejs.org/calendar> |
| 152 | + |
| 153 | +Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. |
0 commit comments