Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node.js Technical Steering Committee (TSC) Meeting 2024-06-12 #1575

Closed
mhdawson opened this issue Jun 10, 2024 · 12 comments
Closed

Node.js Technical Steering Committee (TSC) Meeting 2024-06-12 #1575

mhdawson opened this issue Jun 10, 2024 · 12 comments
Assignees

Comments

@mhdawson
Copy link
Member

Time

UTC Wed 12-Jun-2024 15:00 (03:00 PM):

Timezone Date/Time
US / Pacific Wed 12-Jun-2024 08:00 (08:00 AM)
US / Mountain Wed 12-Jun-2024 09:00 (09:00 AM)
US / Central Wed 12-Jun-2024 10:00 (10:00 AM)
US / Eastern Wed 12-Jun-2024 11:00 (11:00 AM)
EU / Western Wed 12-Jun-2024 16:00 (04:00 PM)
EU / Central Wed 12-Jun-2024 17:00 (05:00 PM)
EU / Eastern Wed 12-Jun-2024 18:00 (06:00 PM)
Moscow Wed 12-Jun-2024 18:00 (06:00 PM)
Chennai Wed 12-Jun-2024 20:30 (08:30 PM)
Hangzhou Wed 12-Jun-2024 23:00 (11:00 PM)
Tokyo Thu 13-Jun-2024 00:00 (12:00 AM)
Sydney Thu 13-Jun-2024 01:00 (01:00 AM)

Or in your local time:

Links

Agenda

Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/node

  • module: allow module.register from workers #53200
  • src: make --env-file return warning when not found #53177
  • doc: deprecate NaN or negative number as delay to setTimeout and setInterval #53005
  • Ambassador program #52857

nodejs/TSC

  • Moderation Team annual certification #1569
  • Module customization hooks and worker threads #1566
  • Open OpenCollective and Github Sponsors for Node.js #1553
  • Coordinating nodejs security audit report finalization and publication #1546
  • New Strategic Initiative on Primordials #1439

nodejs/admin

  • Non-violent communication / strategic workplace conflict resolution training for the TSC and moderation team #877
  • Better process for communicating feedback to members by the TSC #876
  • Creation of an official Discord server for the Node.js project #872

nodejs/next-10

  • Next 10 - Funding Deep Dive #273

Invited

Observers/Guests

Notes

The agenda comes from issues labelled with tsc-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

Zoom link: https://zoom.us/j/611357642
Regular password

Public participation

We stream our conference call straight to YouTube so anyone can listen to it live, it should start playing at https://www.youtube.com/c/nodejs+foundation/live when we turn it on. There's usually a short cat-herding time at the start of the meeting and then occasionally we have some quick private business to attend to before we can start recording & streaming. So be patient and it should show up.


Invitees

Please use the following emoji reactions in this post to indicate your
availability.

  • 👍 - Attending
  • 👎 - Not attending
  • 😕 - Not sure yet
@mhdawson mhdawson self-assigned this Jun 10, 2024
@GeoffreyBooth
Copy link
Member

We can probably remove these from the agenda, I had tagged them just for awareness. (Unless anyone else involved in these threads wants to discuss them.)

@mhdawson
Copy link
Member Author

We only had 5 people make it to the meeting today so we cancelled. See everybody next week.

@mhdawson
Copy link
Member Author

@GeoffreyBooth I think unless you've had suggestions otherwise, since you tagged those items for the agenda you should be ok taking off the tag so they don't show up on the agenda for next week.

@benjamingr
Copy link
Member

benjamingr commented Jun 12, 2024

We only had 5 people make it to the meeting today so we cancelled. See everybody next week.

Sorry, ran late with the kids due to the holiday here, not that 6 people instead of 5 would've necessarily fixed things :]

@GeoffreyBooth
Copy link
Member

I would’ve joined late too but it’s fine. @mhdawson I’d already untagged them.

Maybe a meta-issue we want to discuss is whether there should be a team whose focus is on CLI stuff, that can be responsible for --env-file and related things. Then issues related to those features would have a place to be discussed besides the TSC, to avoid every disagreement rising to the TSC level.

Along those lines, there hasn’t been a loaders team for quite some time now; I’m the only one consistently attending the meetings anymore. I have no one to ask for guidance from for loaders issues other than the TSC.

@mhdawson
Copy link
Member Author

In terms of the --env-file would the @nodejs/tooling team make sense?

@anonrig
Copy link
Member

anonrig commented Jun 13, 2024

In terms of the --env-file would the @nodejs/tooling team make sense?

--env-file is currently blocked, therefore requires voting to be resolved. assigning a team to the CLI makes sense in the long term, but doesn't resolve the conflict we're facing right now.

@GeoffreyBooth
Copy link
Member

--env-file is currently blocked, therefore requires voting to be resolved. assigning a team to the CLI makes sense in the long term, but doesn’t resolve the conflict we’re facing right now.

The idea is that if there’s a team responsible for the feature, that team could have periodic meetings and talk through disagreements in an attempt to find a resolution. The recent loaders meeting with me, Paolo and Gabriel was very productive and we resolved all open questions (at least, open between the three of us) about how to handle the off-thread hooks/worker threads issue. Perhaps if the tooling team held a similar meeting where all interested parties could discuss this issue, and the group had a full hour on that one topic, a similar resolution could be achieved.

@anonrig
Copy link
Member

anonrig commented Jun 13, 2024

The idea is that if there’s a team responsible for the feature, that team could have periodic meetings and talk through disagreements in an attempt to find a resolution. The recent loaders meeting with me, Paolo and Gabriel was very productive and we resolved all open questions (at least, open between the three of us) about how to handle the off-thread hooks/worker threads issue. Perhaps if the tooling team held a similar meeting where all interested parties could discuss this issue, and the group had a full hour on that one topic, a similar resolution could be achieved.

@GeoffreyBooth the pull request is blocked for more than 17 days. we don't need more discussions. we need a resolution.

@GeoffreyBooth
Copy link
Member

@GeoffreyBooth the pull request is blocked for more than 17 days. we don’t need more discussions. we need a resolution.

I assume you’re referring to nodejs/node#53177? What about nodejs/node#53060, which was blocked first? The only justification you gave was

I’m -1 on this change. It makes the existing implementation harder to maintain for almost no gain. We should not throw on env-file instead.

If your only concern was the maintainability of the implementation, that sounds like something that could have been resolved by discussion and compromise. It seems like you actually just prefer an alternate behavior, which is fine, but then the question is why we can’t just have both via two flags, even if we flip the default (like if --env-file warns and --env-file-required throws). I’d guess that your position is that the complexity of two flags is not worth the maintenance cost, but if several collaborators are telling us that they want both behaviors, perhaps it’s not really “almost no gain”?

Even though there are a lot of comments on these PRs I don’t really see discussion like what often happens in team meetings. I don’t see much engagement with @BoscoDomingo to discuss ideas for how to achieve the use case he’s trying to support while still respecting your priorities. I don’t think this needs to be a situation where it’s zero-sum and we either choose one option or another, and one side has to win and another has to lose; there might be a compromise here, but I don’t see much attempt at reaching one. At the very least, a meeting where everyone can be heard would be a good start.

@mcollina
Copy link
Member

I’ve done plenty of meetings to
resolve technical issues, and those are often needed to resolve disagreements and find a common ground. However, there is also the way of not disagreeing in the first place. In other terms, what battles to fight and what battles not to fight.

There are also deep technical arguments where a debate is useful to understand differences. Having said that, these long debates could wear people out. I highly recommend we avoid them if possible. Voting is often better.

@BoscoDomingo
Copy link

I’ve done plenty of meetings to
resolve technical issues, and those are often needed to resolve disagreements and find a common ground. However, there is also the way of not disagreeing in the first place. In other terms, what battles to fight and what battles not to fight.

There are also deep technical arguments where a debate is useful to understand differences. Having said that, these long debates could wear people out. I highly recommend we avoid them if possible. Voting is often better.

@mcollina agree on keeping meetings to a minimum. We've probably got enough at our dayjobs, plus scheduling it in the first place could be a nightmare.

However, @GeoffreyBooth does bring up a great point with flipping my PR upside down, and making --env-file-required a thing. It's the perfect middle ground, where the default warns instead of throwing as @anonrig and others suggest, but we still keep the existing behaviour for those who prefer that. IMO we kill two birds with one stone, and appease everyone.

aduh95 added a commit that referenced this issue Jun 17, 2024
* Propose vote to unblock `--env-file` PRs

Refs: #1575 (comment)

* Apply suggestions from code review

Co-authored-by: Tobias Nießen <tniessen@tnie.de>

* Apply suggestions from code review

* Apply suggestions from code review

---------

Co-authored-by: Tobias Nießen <tniessen@tnie.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants