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

Session Proposal: Node.js PMWG & Version Management Working Session #400

Closed
4 of 6 tasks
wesleytodd opened this issue Mar 25, 2024 · 20 comments
Closed
4 of 6 tasks
Assignees
Labels
Collaborator Summit London 2024 Collab Summit at Apr 3rd 2024 in London Session Proposal A session proposal for the Collaboration Summit

Comments

@wesleytodd
Copy link
Contributor

wesleytodd commented Mar 25, 2024

Proposal

Topic of the session

Working session for the Node.js Package Maintenance Working Group to advance discussions around version management tools within Node.js. This includes discussion of corepack scope, as well as alternatives, more official documentation for the relationship with npm and chartering the group for ownership of this domain.

Type of the session

  • Collaborate
  • Workshop
  • Talk

Estimated duration of the session

1 hour (open for discussion, might need longer?)

Date and Time of the session

Level

  • Beginner
  • Intermediate
  • Advanced

Pre-requisite knowledge

Describe the session

We will start with a re-cap of the history of discussions around shipping a version manager for node, corepack and npm, and the current discussions around the contentious topic. After that we will discuss goals for a proposed version manager for both Node.js and package managers. Lastly we will attempt to arrive at a decision if chartering the PMWG to own this domain is a good path forward.

Session facilitator(s), Github handle(s) and timezone(s)

@wesleytodd
@aduh95
@ruyadorno

Meeting notes and Virtual Meeting Link

Follow-up / Set-up sessions (if any)

Additional context (optional)


@GeoffreyBooth
Copy link
Contributor

I would love to call into this if a video link can be made available, and at a time that’s reasonable for US Pacific (so as late in the day/evening as possible ideally).

@ruyadorno
Copy link
Member

we should pb ask for a 2 hour block, I don't think 1h will be enough to make meaningful progress.

@wesleytodd
Copy link
Contributor Author

Updated to 2h.

@wesleytodd
Copy link
Contributor Author

So for the agenda, I was thinking something like this (assuming we do 2 hours):

  1. Do a small history recap (10 min)
  2. Goal brainstorming session (30min)
  3. Dive into technical requirements based on our goals (30min)
  4. To charter or not? (20min)
  5. Working time. Either continue other discussions or actually try to write some docs or code to move foward (30min)

Thoughts on this?

@darcyclarke
Copy link
Member

darcyclarke commented Mar 27, 2024

Just wanted to note I'd like to attend this virtually if possible. My timezone is EST. No longer relevant as I'll be attending in-person now.

@joyeecheung
Copy link
Collaborator

joyeecheung commented Mar 27, 2024

We plan to make it the last session of the first day of the summit (April 3). We should start leaving around 17:00 London time (procrastinating a bit is okay but for security reasons we can't stay later than 18:00). So looking at 15:15-17:00 with some break time in between.

@wesleytodd
Copy link
Contributor Author

Will we have all the setup in the room for streaming and remote participation or do we need to prepare to run that as the facilitators?

@joyeecheung
Copy link
Collaborator

Still need to figure it out. Current plan is to use Zoom (preferably the OpenJSF account), and we should have some microphones in the room, both people in the room and remote folks use Zoom to raise hands and we speak in turns.

@joyeecheung
Copy link
Collaborator

joyeecheung commented Mar 27, 2024

Streaming probably won't happen because of regulations (GDPR or something like that, those who appear on camera may also need to sign a form to give consent for the recording, or they should try to avoid the camera), but joining via Zoom is open.

@richardlau

This comment was marked as outdated.

@GeoffreyBooth
Copy link
Contributor

Maybe this can happen in the session, but I think it might help if beforehand each of the attendees can write down a list of use cases or problems they want solved? With more specificity than a vague notion like “Improve the experience of Yarn users.” I feel like part of the problem we’re facing is that we don’t have agreed-upon goals, so having a bunch of lists of what each person wants to achieve and seeing the common themes there might help us in finding that consensus.

In particular, I just don’t know what to do with requests like nodejs/node#51981 (comment) and nodejs/node#51981 (comment) that ask for a Corepack alternative without specifying either what’s wrong with Corepack or what they would prefer instead. A new Corepack . . . that’s better! 😄 I feel like the alignment of goals is by far the most important thing that needs to happen; implementation can happen async over time.

@wesleytodd
Copy link
Contributor Author

is that we don’t have agreed-upon goals

Agreed! I was hoping by having it start with brainstorming goals we would be better setup to have the deep discussions. If you think pre-work would help I am down, but I am not sure how reliable asking folks to do that will be.

that ask for a Corepack alternative without specifying either what’s wrong with Corepack or what they would prefer instead.

Yeah, lol, I have been a bit guilty of this myself. I have referenced a replacement without any specification on what that could even mean. I was going to write up a formal document on the session (hopefully tomorrow morning) and think adding this stuff would be good.

@GeoffreyBooth
Copy link
Contributor

I sketched out one possible alternative here: nodejs/package-maintenance#591 (comment)

For the use cases of:

  • I want an easy way to run different versions of Node.js for different projects that I develop.
  • I want an easy way to run different package managers and/or versions of package managers for different projects that I develop.

With the intended goals of:

  • Don’t reinvent the wheel: if there’s a solution out there that does what we need, let’s just reference or recommend it in our docs rather than building something new ourselves.
  • Small core: if the solution works without needing to be bundled with Node, don’t bundle it in our distribution.
  • Encourage competition: whenever possible, allow the user to choose between various approaches rather than picking a winner, to provide space for new alternatives to emerge in the future from the ecosystem.

cc @mcollina @BridgeAR

@gulbanana
Copy link

In particular, I just don’t know what to do with requests like nodejs/node#51981 (comment) and nodejs/node#51981 (comment) that ask for a Corepack alternative without specifying either what’s wrong with Corepack or what they would prefer instead. A new Corepack . . . that’s better! 😄 I feel like the alignment of goals is by far the most important thing that needs to happen; implementation can happen async over time.

I didn't read those comments as asking for a corepack alternative. It seems more likely that they're asking for corepack to not be removed because there is no alternative. This isn't a statement that there's something wrong with corepack.

@wesleytodd
Copy link
Contributor Author

This isn't a statement that there's something wrong with corepack.

Agreed those statements are not. The answers to "why not corepack" are in the threads in there. That said, I think the goal of this session is to get to the bottom of that question in a more approachable way for folks who were not able to read the pages and pages of comments across multiple issues and 4 years on this topic. Anyway, I don't think we should litigate the topic in the planning thread here, so please lets keep this to planning the sessions goals and structure.

@joyeecheung joyeecheung added the London 2024 Collab Summit at Apr 3rd 2024 in London label Mar 28, 2024
@joyeecheung
Copy link
Collaborator

For the remote participants: we've scheduled Zoom Webinars for the sessions, please register using the links provided in #387 and you'll get a link in an email to join the sessions. More info in the issue mentioned.

@joyeecheung
Copy link
Collaborator

You can also get invited to be a panelist beforehand to save the registration & promotion step. Ping in the OpenJS slack with your email or send a email to the email in my GitHub profile to get an invitation.

@trivikr
Copy link
Contributor

trivikr commented Apr 2, 2024

Time

UTC Wed 03-Apr-2024 15:00 (03:00 PM):

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

Or in your local time:

@joyeecheung
Copy link
Collaborator

joyeecheung commented Apr 6, 2024

BTW I just noticed that the comment above #400 (comment) gave incorrect times (we were using London time, not UTC, which had a 1 hour difference) and that was probably why some people missed the first hour of the session.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Collaborator Summit London 2024 Collab Summit at Apr 3rd 2024 in London Session Proposal A session proposal for the Collaboration Summit
Projects
None yet
Development

No branches or pull requests

10 participants