Vote on integration of Yarn.

[mhdawson]

In the TSC meeting today, those present agreed that we should call for a vote. This issue is to discuss with the full TSC since not all members were in attendance.

The issue driving the discussion is: deps: add Yarn 1.22.5 #37277 and the related issue is: https://github.com/nodejs/node/pull/35398

You can catch up on the discussion in the minutes: https://github.com/nodejs/TSC/pull/1011/

My first cut at the options for the vote based on the discussion in meeting are:

• we should integrate yarn/land 37277
• we should integrate corepack/land 35398
• my preference is that we integrate yarn, but if that does not get enough votes we should integrate corepack
• my preference is that we integrate corepack, but if that does not get enough votes we should land yarn
• I don't think we should land yarn or corepack
• I don't think we should land yarn or corepack because there is not enough information to make a good decision yet

The last 2 will both be counted together but would provide insight if a no vote is due to an objection or a lack of information (since it has been raise that more info may be necessary to make a good decision).

@nodejs/tsc please review and indicate if there are any objections to move to a vote, and suggestions for improvements/changes to the options suggested for the vote.

[jasnell]

These options look good. I'm +1 on moving to vote

[ChALkeR]

Moving to a vote and the set of options look good to me, though "land ABC" imo should be replaced with "target landing ABC", so that e.g. voting for 1-4 shouldn't imply an approval of the current state of those PRs without comments or be treated as a code review.

[ChALkeR]

Also, perhaps an explicit abstain option could be useful.

[gireeshpunathil]

+1 on moving to vote

[aduh95]

Would this issue be suitable for a Condorcet? That would allow TSC members to express more precision what they want for Node.js, and it's probably more "fair" than having to chose only one option. For a Condorcet vote, I think the options could be (in alphabetical order):

• Keep npm, integrate Corepack (not Yarn).
• Keep npm, integrate Yarn (not Corepack).
• Keep npm, integrate Yarn and Corepack.
• Keep npm, do not integrate Corepack nor Yarn.
• Remove npm, do not integrate Corepack nor Yarn.
• Remove npm, integrate Corepack (let npm and Yarn decide if they want to be in Corepack).
• Remove npm, integrate Yarn (do not integrate Corepack).

[ljharb]

Is “remove npm” even on the table?

[mcollina]

remove npm was not on the table during the last TSC meeting.

[aduh95]

Is “remove npm” even on the table?

Maybe I'm not wording it correctly, I mean stop bundling npm by default, not completely removing it of course. I remember some participants of last TSC meeting stating they'd rather do that than bundling yarn. IMHO it makes more sense to discuss the status of npm in Node.js along side yarn integration, but please disregard if that's off-topic.

My point was to suggest using Condorcet for this vote, not removing npm.

[mcollina]

+1 on condorcet.

[DerekNonGeneric]

+1 on making Yarn available w/o requiring users to have npm.

Either integrating it into the core repo as a dep or it being acquired via Corepack (which I assume means that the yarn command is a shim that makes a network connection setting up the files in the proper locations prior to running).

[ChALkeR]

Condorcet is not a single method but a group of similar methods.

More specifically: given N options, start with ranking each option on a relative preference scale (1-N, allowing duplicates). Then use some of the methods to rank those (those are different)

While there are methods that e.g. disallow duplicate rankings (simple ranking) in the voting process, there seems to be little benefits of that and that just complicates the decision process.

[nschonni]

+1 on making Yarn available w/o requiring users to have npm.

@DerekNonGeneric this issue is to "call the question" like in Roberts Rules https://jurassicparliament.com/how-do-you-call-the-question-in-roberts-rules/

The vote is only for TSC members AFIAK, not a general member vote. Those other issues are probably a better place to voice general support.

Feel free to hide my response as off topic

[mhdawson]

I'm wondering if Condorcet is going to let TSE members better express their opinion? It's going to take more work to set up/etc. so want to be sure pushing out the vote to do that is beneficial. In particular I'm not sure how it handles the "but only if X" does not win.

[mhdawson]

@ChALkeR did you come across the use of Condorcet for non-elections ? I see most articles reference electing people versus making a decision?

[aduh95]

did you come across the use of Condorcet for non-elections ? I see most articles reference electing people versus making a decision?

I've seen used to pick a name. It's just a voting system, I don't think there is any difference if it's used for electing people vs choosing ideas.

I'm wondering if Condorcet is going to let TSE members better express their opinion? It's going to take more work to set up/etc. so want to be sure pushing out the vote to do that is beneficial. In particular I'm not sure how it handles the "but only if X" does not win.

From what I've read, it has some significant advantages including allow voter to express their opinion (instead of going all in for only 1 proposition, you rank them all, so you can better express where you stand on the issue), and you can add "but only if X" propositions to the list without splitting the votes. I reckon it does take more work to set it up, let me know if I can help, I think it would be useful to have some tooling to assist with that if we haven't a Condorcet voting system already (even if we end up not using it for this particular vote).

[mmarchini]

Would this issue be suitable for a Condorcet

In our last vote (Promise unhandled rejections) we used San Francisco RCV via OpaVote. Not saying we must use it again but it's a method we successfully used in the past that allows TSC members to express the full range of their choices instead of picking only one.

[mcollina]

I liked that

[mhdawson]

@mmarchini, I like re-using the same approach. We should probably document a standard way to setup the vote and what tool to use so that we don't have to think about it each time.

[ChALkeR]

@mhdawson I have been always in favor of ranking each option instead of just selecting a single option (when we get to vote, which I prefer we don't). Preferably, even rank each option independently on some scale (which is mostly identical to a non-exclusive relative ranking for the purpose of Condorcet, but see below).

That collects more data about preferences on a single run, and can be used to run better choices than just a simple majority.

Simply picking the most "popular" option from a "pick a single option" vote can sometimes fail badly, and the Condorcet wiki page has examples of that.

Condorcet has it's pitfails too, so in case if the vote is done in a small group and in good faith and voters are able to use at least somewhat similar scales (which is hard), it might be better to simply maximize the preference score.

E.g., for the utility estimation table:	Voter	A	B	C
Alice	100	10	90
Bob	90	100	80
John	80	90	60
Maddy	60	20	50
Mike	10	90	80
Peter	40	20	90
Sarah	60	40	100

• In the system "Choose one", B wins being the most popular, with total 3/7 votes (with 2/7 for each of two other options), and a total estimated utility of 370.
• In the Condorcet system based on rankings, A is preferred over B by 4 (>50%) people, A is preferred over C by 4 people. It wins when ranked 1:1 against any other option. A wins with a total estimated utility of 440.
• But estimated utility is maximized by option C — it has total estimated utility of 550.

Given that the scale is (approximately) the same for each voter, option C is the least bad one in the example above.

Now, the hard part of the utility maximizer approach is that everyone should use the same scale, otherwise summing "utility" does not have any good meaning attached to it.

This is close to how the TSC time picker works, btw (but it has some further logic as the total participation is not the only factor). But we have a well-defined scale there, which is internally converted to "probablity that I'll attend a meeting at that time". It might be harder to do the same for more general questions.

I'm fine with Condorcet, but I would prefer us to collect the data in a form where each option is individually ranked on some scale (which should be at least 1-N for the purpose of Condorcet, but 0-20 might be better).

[mmarchini]

@ChALkeR any thoughts or objections on the method we used for unhandled rejections vote (San Francisco RCV)?

[DeeDeeG]

Hi folks, I'm not on TSC or too deeply involved with Node, so feel free to ignore... but I'm a bit of a voting systems nerd. I'd be 👍 for either RCV or Condorcet.

(I also like Approval voting, which is "Vote 'yes' on however many options you approve of" -- "pick n" instead of "pick 1".) But ultimately I support anything better than "pick 1".

Based on some voting systems nerd stuff I've been following (`reddit.com/r/EndFPTP` and `reddit.com/r/RankTheVote`) the consensus there seems to be: - Letting voters pick only one option is among the worst performers - "RCV" (such as the San Francisco RCV variant) is considered a substantial improvement over that - Other methods are considered at least a bit better than RCV, grouped around the "top" in terms of theoretical best-ish methods to pick the "ideal" winner. In no particular order: - Condorcet (a different ranking system than "RCV" -- requires a tie-breaker method. Many options for a tie-breaker, but essentially all are good performers. I suggest picking "Ranked Pairs" or "Schulze", or "Beatpath" which Debian uses. Ties are rare, so just picking one and sticking to it is the important thing, IMO.) - Approval (each voter may vote "yes" on however many options they like -- pick n instead of pick 1) - Score (each voter may give a score (say from 0-[max]) to each option.) - Some more obscure ones like STAR or 3-2-1. There is also a consensus that "Anything better than pick-one/FPTP" is an important improvement. Debates about which method is best seem to go on forever, though, and picking something is important. So I'd be 👍 for either RCV or Condorcet as were mentioned earlier in the thread, or shout out to my personal favorite, Approval voting.

(I also support "getting on with it," and I don't mean at all to derail, so I'm 👎 on accidentally derailing the thread, if possible.)

[ChALkeR]

@mmarchini re: SF RCV — basically the same problem as with Condorcet. If variant X is significantly worse than Y for a low subset of voters and variant X is slightly better than Y for a large subset of voters, X will still win.

E.g.:	Voter	X	Y
Alice	100	90
Bob	90	70
John	10	90
Maddy	95	80
Sarah	30	100

X has the majority with 3/5 and beats Y (even in RCV or Condorcet), but it has total utility of 325 vs Y which has 430. Unless we have the data how each voter rates each option individually, we can end up preferring an option that is considered being only slightly better by some but significantly worse by others.

I would prefer if we collected the data in a form of "rate each option from 0 to 20" (or from 0 to 100), which can be later analyzed in various ways, as it directly provides enough data to get build e.g. the preference order.

The tricky part is how to define a scale, and it should be defined to mean something. E.g. in order to run e.g. RCV, we need to specify which cutoff counts as "mostly in favor". In order to try to maximize the total utility, we need those values to be roughly additive. Also, everyone should be acting in good faith for this to work, i.e. actually inputting their real scores for each vote, not just placing e.g. 0 for everything they don't like. This might be hard to achieve in large groups, but I think we might succeed here. Also, depending on the scale, addition might be e.g. with a power of <1 to further prefer 50+50 instead of 10 + 90 (assuming that 90 and 100 are closer on the actual scale than e.g. 20 and 30).

[Trott]

I think there are diminishing returns to introducing more nuanced ranked voting than RCV. I'm happy to go along with whatever method is chosen, but the more complex the method, the harder it will be to get people to participate.

What I really want to avoid, though, is us taking weeks to discuss and select a voting method. There seems to be decent support for RCV and I think we should go for it. Anything involving scales is going to require a lot of thinking about getting it similar/identical for everyone. That seems both difficult and with a high risk of getting it wrong.

For that reason, I'm +1 on RCV. It's not that the Condorcet and rate options ideas are wrong. It's just that there's a cost/downside to going down that path at this time, and my judgment is that it's not worth it.

That said, what might be worth it is trying to figure out a voting system that will work for us generally and document it. If we don't do that, it will probably be RCV by default. If a better process is part of our documentation, then we don't have to discuss it every time a vote comes up (which fortunately is not that frequently).

[mhdawson]

I propose we just use RCV for this vote and try to schedule it for next week. +1 on documenting what we'd like to do longer term but I agree with @Trott that we should avoid delaying the current vote. Objections?

The other question is whether we should include options with respect to npm in the vote? If we did that I think questions could just be:

• add corepack
• add corepack, remove npm
• add yarn
• leave things as is
• remove npm

I know there are other combinations, but I don't think we've discussed them as options. If you think we need other options please comment to that effect.

If we don't include the question on npm it could be:

• add corepack
• add yarn
• leave things as is

[mmarchini]

Agree with @Trott and @mhdawson, we should go with RCV for this one and open a separate issue to discuss which voting method we should use moving forward.

[mmarchini]

Also I volunteer to create the voting on OpaVote again, unless someone else wants to do it.

[ljharb]

@mhdawson again, is removing npm supposed to even be on the table? https://github.com/nodejs/TSC/issues/1012#issuecomment-817147283 suggests it is explicitly not.

[Trott]

We should go with the simple three options rather than the five. If we add corepack, a decision can be made at a later date to install npm from a shim rather than bundling npm, but there's no need to make that decision either way at this time (although I'm sure many have strong opinions already, which is fine). Adding corepack could be a semver minor, but moving npm from bundled to installed-with-corepack would absolutely be a major, so treating the questions separately seems reasonable to me.

This also allows us (if we go the corepack route) to see how well corepack works for a large number of users before deciding if it's appropriate to try to use it for npm. More information before making a decision is good.

[Trott]

I can't imagine anyone on the TSC is for removing npm. Moving npm from bundled to distributed via corepack? Eh, maybe (although maybe corepack already depends on npm in which case we should keep bundling npm). But flat out removal of npm? Putting that as an option sends the signal that it's a realistic outcome of this vote when it is not. Let's not give people an excuse to freak out.

[jasnell]

I can't imagine anyone on the TSC is for removing npm

Well, I am, but I know I'm in the minority and don't feel like fighting that battle. corepack does not depend on npm, fwiw, and corepack intentionally currently does not do anything with npm, although later it could.

[Trott]

I can't imagine anyone on the TSC is for removing npm

Well, I am, but I know I'm in the minority and don't feel like fighting that battle. corepack does not depend on npm, fwiw, and corepack intentionally currently does not do anything with npm, although later it could.

@jasnell Note the five options Michael laid out:

• add corepack
• add corepack, remove npm
• add yarn
• leave things as is
• remove npm

You are, if I understand correctly, advocating for the second one. I'm saying that the last one is totally off the table. No one on the TSC is even considering that as a realistic or reasonable option.

[jasnell]

Correct, while I would absolutely be in favor of the remove npm option, I don't consider it a realistic option because I know that I am in the minority and it would never happen. It should not be included as an option in the vote.

[Trott]

Correct, while I would absolutely be in favor of the remove npm option,

I don't want to get too off topic here, but how do you see this working in absence of something like corepack? People would have to install a package manager separately if they needed it? Sort of the way they install nvm if they need it (with a shell script)?

[jasnell]

I don't want to get too off topic here, but how do you see this working in absence of something like corepack?

Not a conversation I'm going to have here and not relevant to the vote. Catch me offline sometime ;-)

[mhdawson]

@mmarchini thanks for volunteering to put together the vote, greatly appreciate that!

[mhdawson]

@ljharb my preference is that we don't include it, but did not want to ignore the question posted earlier so asked the question to the TSC members.

Based on @jasnell's input I suggest we go with:

add corepack add yarn leave things as is

for the questions. This keeps us to the point of original question about landing yarn, and as @Trott says keeps it to an outcome that is SemVer minor and easier to implement.

[MylesBorins]

due to my employment with github and work I do on npm I'll be abstaining from this vote.

I do request if there is to be any votes that include removing npm, or distributing it via core pack, that the npm team be consulted on the decision and be given the opportunity to review the options and propose solutions before a vote.

It doesn't seem like voting on removal of npm is on the table, but if we want to continue to explore this option I think there is quite a bit of work to be done before we decide we need to vote on it.

[jasnell]

Fwiw, with the corepack option, it would need to be the npm team that implements the ability for corepack to install it, so that would never happen without direct involvement from npm.

[mmarchini]

Quick question: are the newly nominated folks already onboarded or are we waiting on anything? Will they participate in the vote? If they are not, should we wait until they are onboarded before voting?

[mmarchini]

Preview page for the vote (vote is not open yet, actual link for the vote will be sent directly to TSC members emails):

I tried to keep the summary short, but we can write something more elaborate if folks think it'll be helpful.

The setting I'm using are listed below. Please let me know if there's anything folks thing should be changed.

[ChALkeR]

@Trott

I think there are diminishing returns to introducing more nuanced ranked voting than RCV.

Offtopic on meta

To me, RCV looks more complex that simple scoring, because it entangles options between each other. I would have preferred something like this instead:

Which provides the data that we need, and for me looks easier to both use as a data source (reasons above) and to fill in, because it avoids entangled options, i.e. comparing them to each other, and instead asks a simpler more grounded question.

That said, I'm ok with RCV for the sake of continuing this, perhaps we could move the meta discussion (for future) to some other channel from this PR. I hid that under a spoiler, hope that's ok.

[mmarchini]

Vote link sent to @nodejs/tsc members via email listed on https://github.com/nodejs/node#tsc-technical-steering-committee. If you didn't receive an email, please let me know and I'll send you a code to vote. Being a free vote session on OpaVote means we have 7 days to finish the vote, so please vote ASAP. If you are going to abstain, please vote without selecting any options so we know you're aware of the vote.

I'll try to send daily emails to members who didn't vote yet to make sure everyone has a chance to vote.

[mmarchini]

Daily update: 14 voted so far, 8 remaining.

[mmarchini]

Daily update: 17 voted, 5 remaining.

[Trott]

This is hopefully obvious and may already be covered above somewhere that I'm not seeing in a quick skim, but I want to make sure we all agree that a vote for including corepack or bundling yarn is not a vote for any particular implementation. For example, hypothetically, I may be in favor of shipping corepack, but only if we can do it in a way that does not change anything for existing npm users--in other words, it can't introduce any additional friction/burden for existing users and CI automation and whatever else. So I might be in favor of corepack but opposed to a specific PR that adds it.

[mmarchini]

Daily update: 20 voted, 2 remaining.

[mmarchini]

Daily update: 21 voted, 1 remaining.

[mhdawson]

@Trott to confirm from the minutes of the last TSC meeting:

• Vote is on general direction, not land as is, PR’s need work/review/and may be experimental

[mmarchini]

Still 1 remaining. I sent a final reminder to them and will close the vote in 24 hours. Unfortunately I don't know if their email is up to date on our mailing list (see #1022) and I don't want to ping them directly here without their consent (but I also can't reach them anywhere else). So I'm going to cc @nodejs/tsc once more just in case

[mmarchini]

Vote is closed. Winner is "add corepack" with 63.2% of votes as first choice. Ballouts have been shared with TSC members in private.

OpaVote Election Results (https://www.OpaVote.com/)

Vote on integration of Yarn

There are 3 candidates competing for 1 seats. The number of voters is 21 and
there were 19 valid votes and 2 empty votes.

Counting votes using San Francisco RCV.

 R|Add corepack      |Add yarn          |Leave things as is|Exhausted         
  |                  |                  |                  |                  
==============================================================================
 1|                12|                 2|                 5|                 0
  |---------------------------------------------------------------------------
  | Count of first choices.
==============================================================================
 2|                18|                  |                  |                 1
  |---------------------------------------------------------------------------
  | Count after eliminating Add yarn and Leave things as is and transferring
  | votes. All losing candidates are eliminated. Candidate Add corepack is
  | elected.

Winner is Add corepack.

This means we're not moving forward with #37277. We can revisit nodejs/node#35398 to see if there are any technical concerns left before landing.