TSC
TSC copied to clipboard
nodejs
Open Corepack Vote
@nodejs/tsc ... as discussed on this TSC call today. Initiate a formal vote on the corepack discussion
Does the presence of this vote mean the PMWG has a deadline for our goals and corresponding proposal docs? I assume we would want to have a clear picture of our intended future goals before we make changes to the status quo, but maybe y'all are seeing it differently.
The idea is to start a vote but I don’t think we have a timeline for the vote. From the summit some ideas were proposed:
- Use the next-10 survey coming out this month to test the temperature in users
- Give the PMWG a few weeks to figure out a short-term strategy
I think for those who are not yet decided, it would be valuable to have more information before they cast their vote. But we should not stall this forever either, so a vote will happen soonish.
The idea is to start a vote but I don’t think we have a timeline for the vote
Thanks for the context @joyeecheung! We will work to get that asap. We have good progress happening today here already:
https://github.com/nodejs/package-maintenance/pull/597
How is the survey distributed?
More details here, including us working out the questions we want to ask in this regard. https://github.com/nodejs/next-10/pull/261
Does the presence of this vote mean the PMWG has a deadline for our goals and corresponding proposal docs? I assume we would want to have a clear picture of our intended future goals before we make changes to the status quo, but maybe y'all are seeing it differently.
I don't think this vote affects any potential future goals. IMHO, this vote can happen independently of PMWG's work. I don't see how they are strictly related. Unless the goals of the PMWG match the corepack's implementation exactly.
We have good progress happening today here already
Based on the collab summit and recent discussions, I think we might have consensus that we want to revise https://nodejs.org/en/download to prioritize the application developer use case, recommending installation via a version manager as the default method (see also https://github.com/nodejs/package-maintenance/issues/591).
It would probably be a technical necessity for that version manager to be installed separately from Node, which would mean that the default tab for the download page would be something like a list of instructions where there are separate installation steps for the version manager and then for Node. Once we have that, it follows that the package manager version manager (Corepack) would be one of those installation steps. In this approach, Corepack would be unbundled from Node (and therefore not managed by whatever version manager controls the Node distribution) but still provided for users as part of installation.
Converting to draft because the tool is ~not able to handle two open votes at once~ (EDIT: this has been fixed), and in the last TSC meeting there was consensus about giving more time to the package maintenance team before taking a decision.
It seems the discussions about corepack is getting some attention recently. Maybe we should restart the vote, or maybe it's still too early, I am not sure.
To pick up where we were left after the summit https://github.com/nodejs/TSC/pull/1527#issuecomment-2048228753
This is the Next-10 survey result: https://github.com/nodejs/next-10/blob/main/surveys/2024-04/Node%20Next%2010%20Survey%20Results%20OVERVIEW.pdf
- In "Q13 How do you manage the package manager for your project?", 25.24% respondents chose "I use a tool to pick a specific version per project (e.g. Corepack, asdf, …)"
- In "Q19 Are you using the following experimental features of Node.js?", 28.64% respondents checked corepack
I don't know what's the conclusion in the PMWG, have folks come up with the short-term strategy of corepack as requested in the summit? @wesleytodd
EDIT: I see that the PR in PMWG is https://github.com/nodejs/package-maintenance/pull/606 and folks are also asking about updates there.
Maybe we should restart the vote, or maybe it's still too early, I am not sure.
I think it is too early. That issue is continuing our discussion of next steps. And number 4 of our plan was added as a proposal from the discussion we had in slack, it is not yet reached consensus in the PMWG.
I don't know what's the conclusion in the PMWG, have folks come up with the short-term strategy of corepack as requested in the summit?
Those short term questions are actually was spurred the conversation in slack and this next follow up issue. I would say that we are still in the process of finding a recommendation which has a chance at reaching a consensus. There are a few loose ends which have prevented us from doing more sooner, but c'est la vie.
EDIT: Our meeting is in ~30min, please come and discuss.
@wesleytodd Number 4 already makes the decision and makes this voting obsolete. Am I missing something?
I replied in the conversation over there. That discussion is to produce a recommendation, it is not a decision itself. In fact we discussed locking these other issues temporarily to focus the discussion and reduce the spammy noise from the other threads until we have a recommendation with consensus from the PMWG, as agreed upon by the TSC in a former meeting.
If folks agree with the recommendation to temporarily lock all the related issues across the other repos, then I would suggest we start with this one for now. The goal is not to silence anyone, just to help keep the conversation focused and productive, and having it in many threads all at once does not help.
EDIT: it looks like @ovflowd already did have to in https://github.com/nodejs/node/pull/51981#issuecomment-2295283169, and I think this is the right move for now. So idk who would need to take this action but I do not have all the proper permissions to do it.
If folks agree with the recommendation to temporarily lock all the related issues across the other repos, then I would suggest we start with this one for now. The goal is not to silence anyone, just to help keep the conversation focused and productive, and having it in many threads all at once does not help.
This issue has not had external/problematic activity recently. Locking issues is a measure we take to prevent spam (typically from outside collaborators) and cool off heated discussions.
Before Yagiz's comment today there were 3 weeks of inactivity and Yagiz mostly just asked for the status. I'm not sure what locking it benefits us?
Yeah I totally agree this one has not been an issue. Those other ones were the target of our initial recommendation. This one just was the first one in my notifications inbox so it is where I commented it. As long as this one is not at risk of spiraling I am fine keeping it as it.
Please don't remove corepack from node defaults, installing package managers using bash scripts or another package manager (npm) was a completely idiotic situation with no reliable cross-platform, non-redundant solution. corepack fixed it, please don't lose it
This discussion has made it clearer than ever to me that we need an innovation in the governance of open-source systems. As a user of Node.js and a member of the community I find the way this discussion has been going to be very distressing and dissatisfying. Locking issues, WTF.
As pointed by @GeoffreyBooth here and during some of the meetings, inviting people to offer "comprehensive proposals" is a superior strategy to reducing the complexity of the decision making to "a voting" that targets simplistic binary decisions (which may easily lead to an incoherent/unfavorable situation).
I wonder if these comprehensive proposals can be offered by the community, as well as the bigger pool of contributors, vs. a smaller group such as a steering committee. This seems to me to be the only way to finding a good and a sustainable solution.
I have no affiliation with the project, but have you heard of Loomio? it is an open-source decision making platform that follows a more sane approach to consensus forming and sense checking. They have an online demo which is worth checking (Click "Try Loomo for free" and then install the sample data for a fictional oat company).
@diraneyya Not sure how you followed the discussions, but I think what you described had already effectively happened in https://github.com/nodejs/package-maintenance/pull/606 (PMWG is a group of community members and this thread has been asking them to reach consensus and present a short-term strategy, the request about locking issues also came from that community group).
With the possibility of biting my tongue, I don't believe that highly impacting technical decisions of an open-source project should be done through tools like Loomio or polls, or any vote-based system.
It should be open for any interested community member to join the discussion and be able to provide their opinions. Still, any real consensus-seeking must involve full-fledged discussions within the aforementioned group. It is essential that all parties surely understand what their vote and decisions mean. Blindly voting through such tools, which have just a field for adding your opinions, won't allow discussions to happen. Direct communication, either async or not, has worked for years.
In other words, such technical decisions require a long time to be crafted, with many experts being consulted, and long-standing discussions; Things get iterated over and over, and that's the nature of it.
I wonder if these comprehensive proposals can be offered by the community, as well as the bigger pool of contributors, vs. a smaller group such as a steering committee. This seems to me to be the only way to finding a good and a sustainable solution.
Seconding Joyee here, that this is precisely what we are doing here.
I find the way this discussion has been going to be very distressing and dissatisfying. Locking issues, WTF.
We asked that highly sensitive PRs that are in the draft stage get locked to internal contributors for the time being to prevent the common effect of "PR X" from getting shared on socials. Then we have numerous random people with 0 involvement with the project, or that haven't even read the material or the PR or the previous comment with "rage-inducing" or wildly "off-topic" or "spam/duplicated" comments that do not provide factual or any specific positive amendum to the space where the comment was provided.
Locking issues doesn't make us, the contributors, less aware of what the "community" wants; Which is also a questionable word choice, since platforms like X, or having a few hundred of people or whatnot liking or commenting on Tweets -- isn't really a scientifically or accurate way to assess "what the community wants" or "what is best for the community"
This is a long-standing rat-and-mouse paradigm in Open Source. Ultimately, the Node.js project reserved the right to make technical decisions that they believed fit the project. If they work out, great, but often any given technical decision must be followed-up or iterated, it is always the nature of any software development.
A little disclaimer: I am one of those with 0 involvement in the project. I am a developer and a long-term user of Node.js, and that is about it. However, I still think that an outsider's point of view can be helpful, especially when at a higher-level.
@joyeecheung you are absolutely right (here) in that it is difficult for people like me (who are effected by the decisions you guys make) to follow the conversation and meaningfully contribute to it. There is just too much noise and also the feeling that my points of view is never going to be informed enough for it to be worth voicing or sharing.
One of the main issues I can see in the case of the Corepack-vs-npm debate, is the conversational format for knowledge management throughout the decision-making process, which is very inefficient and makes it harder to follow along by enough people if the large solution space is to be sufficiently explored, and the needs of most users adequately met. It also makes it harder to make people accountable after months of debate.
A living-document is a much better format, for example, which is provided in the case of the much less controversial goals.
The goals are clear and take a few second to read and understand. I do not think anyone would disagree with them, yet, the governance process around them seems prone to leading to "agreements" that do not meet them well. This same observation has been meme'd as "how one asking for turning Corepack on by default led to a decision to de-bunde Corepack from NodeJS". It is not a criticism of the decision made, as much it is a criticism of the decision-making process.
@ovflowd I think you are mistaking voting systems in general with the social-media-inspired style of voting. Emojis (likes and dislikes) are not the only way to carry voting. However, you are absolutely right if what you mean is that voting exclusively with a "yes" or a "no" is unproductive and leads to suboptimal agreements.
But this not the only way to conduct voting, both synchronously (during a video meeting) or asynchronously (on a platform like Loomio). For example, check these hand signals developed by seedforchange, they present a very interesting approach and a tested alternative to the yes-or-no approach to voting.
The problem with voting using yes'es and no's is that some votes, coming from meritocratic leaders which carry so much weight get equated with votes from people with no merits, and no involvement, leading to incoherent and destructive decisions. Loomio, the platform I mentioned, offers a variety of tools to assess and prep for consensus, as well as offering seedforchange-style responses to consensus calls, as shown below:
Before attempting a consensus call, it is likely a good idea to carry what Loomio calls a sense-check, which has a different (but a well though out) set of responses as shown below:
In the case of a consensus call, and unliked a yes-or-no approach, people can step aside, agree, request changes to agree, admit to not knowing enough to give a meaningful vote, or block the change, which is an important instrument. Blocking allows people to impede decisions by offering compelling argument as to how these decisions work against the stated goals.
A tool like Loomio can create visibility to the decision making process in a more-efficient, living-document format. Conversations are still possible, but only to the end of providing a summary for later sense-checking and consensus calls.
This will allow everyone in the community to participate meaningfully without having to go through long pages of dialogue, which I think is important.
The reason I am compelled to writing this is because to me, NodeJS is different than most software projects in the sense that it always has been prototypical in nature and relied heavily on the community, with a price to pay, which is that it always had many issues and edge cases as a result, yet, it had been quite unique in how inclusive it had been to everyone's input. It invited and relied on contributions like no other project. This understandably can lead to novel governance challenges.
I do not think that I will say anything more because I feel a lot of responsibility not adding to the existing noise, but I thought this was worth sharing.
I appreciate the effort you've done putting this together. But realistically speaking, this issue is not the place for it, I encourage you to open another one. Second, even more realistically, I doubt Node as a project would change its current consensus seeking and governance model that has worked so well that many other projects like ESlint and Webpack have adopted it, to be changed to a 3rd party platform of possible who knows what and whatnot (with all due respect)
Just because it might work for a random project out there it doesn't mean it will for us; I'm not discarding it's feasibility, and I'm not knowledgeable on Loomio, but by going through their demos and examples, it just doesn't sound like something that would realistically improve our processes.
Also, think about, how many people you think have over the years fine tuned the current governance model; Is it really fair that we should listen to every person, long term user or not, about the current governance model being at fault here? How do one even reach such conclusions? 🤔
Just some food for thought.
A tool like Loomio can create visibility to the decision making process in a more-efficient, living-document format. Conversations are still possible, but only to the end of providing a summary for later sense-checking and consensus calls.
Visibility already exists. Also, given an example, TC39; they have one of the most visible, transparent and open processes out there; Yet just a handful of people even contribute and opinion to their proposals. We do very similarly here. I don't think that a tool like Loomio would help at all here, to the contrary it would discourage discussion.
I'll stop for now, and I unfortunately need to mark both yours and my comments as off-topic, because being honest, they are.
Have a good one!
Where is the right place for it? I would be willing to try to post it there.
Where is the right place for it? I would be willing to try to post it there.
https://github.com/nodejs/admin/issues/new
Where is the right place for it? I would be willing to try to post it there.
To discuss changing the way the project makes decisions, you can open a proposal in nodejs/admin.
If you meant participating in Corepack discussion specifically, that happens in PMWG repo, by opening an issue and/or attending the meeting.
Given https://github.com/nodejs/corepack/issues/627 I think we should go for a vote.
Corepack broke and users were able to work around it and most people added npm install -g corepack@latest to their CI.
This is the workaround suggested https://x.com/cramforce/status/1886421427340927152?t=tFcMvSoY9gQiBm5gvl_zTw&s=19.
Users can do that. Having to do a release to fix corepack puts unnecessary stress on releasers. If users can upgrade independently we can ship it outside node bundle. I would like this vote to happen.
The vote should be about removing corepack from the node bundle distribution.
If users can upgrade independently we can ship it outside node bundle.
@marco-ippolito The same statement can be held for npm, which indeed we updated Node because of a bug in npm even though people could install it directly. In fact we can use the same statement for any dependency (including undici)
If users can upgrade independently we can ship it outside node bundle.
@marco-ippolito The same statement can be held for npm, which indeed we updated Node because of a bug in npm even though people could install it directly. In fact we can use the same statement for any dependency (including undici)
Corepack is experimental while npm and undici are not. Undici is also bundled and exposes globals so its not possible. Npm is another topic, and I'm open to discuss in another issue😁
I agree but core pack is only experimental on paper. The usage alone makes the whole thing debatable. @marco-ippolito