Voting on the default behavior for Promise unhandled rejections

[mmarchini]

v15 Semver Major Cutoff: 2020-09-22

As discussed in the last TSC meeting, we should vote on this issue so we can remove the deprecation warning on v15, so the next step is to decide the voting format. My suggestion is:

• have the vote async instead of during a meeting so we can ensure folks have the opportunity to cast their votes
• private voting instead of voting on a public issue
  • this is a polarizing issue, might be good to try to avoid backlash on any TSC members because of their votes
  • public voting means folks will know the preliminary results before voting, which could influence their votes. Private voting doesn't have that issue
• TSC charter says we needs simple majority (winner needs 50%+ of votes) for a vote to pass, which works fine for yes/no votes, but since this is a multiple choices vote we might end up with no choices having more than 50% votes. My suggestion is to have a second vote if that happens with the two options with most votes

Any objections on using this format?

[mmarchini]

Also I'll share the raw responses and some extra analysis shortly

[mmarchini]

Added label for visibility, but preferably we should decide the format before the next meeting. If we haven't decided before the meeting we can discuss and decide the format during the meeting.

[benjamingr]

Just expressing my opinion, I am one person.

I think that given the survey, the older netflix survey, talking to users, the promises work from the 2018 and 2019 summits and usage from users as well as playing around with options I lean heavily towards throw as the behavior I'd like. My reasons are:

• It seems like it aligns with user expectation.
• It's one less things users have to remember since sync and async errors behave similarly.
• The thing I'm most concerned about is the fact the current behavior is easy to ignore since the warning is logged to stderr which makes it easy to swallow errors in production and cause cascading failures.
• I have seen a lot of bugs where having this default would have helped.
• It's very very easy to opt out of in multiple ways and a single line of code.

I am happy to elaborate on this further - feel free to reach out in person or in chat if you want to debate this.

I just wanted to say thank you to all the people involved in these discussions (namely Matteo, Ruben, Mary, Jordan, Julien, Gus and a few others as well as the people who helped at the start like Kris, Domenic, Stephan, Mark and Petka) for educating me on various bits and helping me formulate a much more informed opinion on the topic.

[mmarchini]

@benjamingr thanks for sharing. As I think we'll go to a vote anyway, it might be best for us to focus on the voting format now so we can have the vote sooner. We could try to go for consensus on one mode or the other, but chances are someone will object and we'll have delayed the vote for another week or so.

Also, if possible I'd like to keep this issue focused on the vote format, as I believe we have exhausted all possible arguments on both sides for that topic :)

[benjamingr]

Ok:

but since this is a multiple choices vote we might end up with no choices having more than 50% votes. My suggestion is to have a second vote if that happens with the two options with most votes

This sounds reasonable for me, I think it's a reasonable system arrow-theorem-wise given our alternatives.

[mmarchini]

Which tool do we use for private voting? Is there any tool the TSC has used in the past that worked for us, or should I reach out to OpenJSF to ask access to some tool?

edit: I'm reaching out pre-emptively so we won't delay it, but happy to use something already familiar if we have it

[MylesBorins]

In most non-controversial cases we've just voted publicly (for non-electoral votes). Often it is a yes / no majority vote type of situation. It seems like you are proposing that we vote on a matrix of possibilities, and that potentially we could have multiple votes... which to me seems like approval voting

https://en.wikipedia.org/wiki/Approval_voting

I believe that helios supports approval voting if we want to go in that direction... although depending on how many options we have we could use an issue + emoji or simply write in

[mmarchini]

It seems like you are proposing that we vote on a matrix of possibilities, and that potentially we could have multiple votes... which to me seems like approval voting

We have 5 possible resolutions for this issue, so it'll be a matrix. The second vote suggestion is to ensure the option chosen has support from 50%+ of TSC voters (if we get 50%+ in one option on the first round we won't need the second). I don't think what I suggested is the same thing as approval voting (not according to the wikipedia article), although approval voting could work as well?

FWIW this is what I'm proposing:

First round we'll be able to cast one vote for A, B, C, D or E. If A gets 25% valid votes, B gets 20%, C gets 14%, D gets 26% and E gets 15%. In this case, we'll have a second round between A and D.

I don't know how this voting system is called 😅, but I think I'm fine going with it or with approval voting.

In most non-controversial cases we've just voted publicly

This is a highly controversial and polarizing issue, so I still think having the vote in private would be ideal. I also think it's a good idea to remove the risk of early voters from influencing later votes (which could happen unintentionally in public voting because the votes are available before the results are shared). If we decide to have the vote public anyway, IMO we should lock the issue preemptively.

[benjamingr]

Just a comment on the name of the voting system - so I'm hiding it to keep discussion on the topic Mary requested.

I actually did several courses on voting systems (fun fact).

Some common rules are:

• Copeland (You choose the candidate who wins the most other characters in pairwise elections)
• Borda count (Each voter submits preferences over the alternatives, points are then given (from 0 to n-1 for each voter). Highest total wins. (Violates Condorcet winner))
• Single Transferable Vote (Candidate with the least points is eliminated at each round)
• Anti Plurality (Choose the least unliked candidate (the one the least agents placed last)).
• Sequential pairwise voting (Each time two candidates are placed against one another).

There are many others - the method you are describing is simply called Two-round or "runoff voting". It's fine for us.

[mhdawson]

I understand the suggestion for the vote being private due to the polarizing issue, but I'm wondering if it should be public to tsc members but private outside that group. Understanding the positions of other TSC members does factor into what I personally think we should do.

[mmarchini]

From TSC meeting today, we're going to try to reach consensus one more time in the TSC before going to a vote. Failing that we're going to a private runoff voting conducted through the TSC mailing list. I'll update the issue here as soon as we have an update on the consensus reaching attempt.

[mmarchini]

Consensus not reached, we started the voting process privately using OpaVote. Vote format will be San Francisco RCV. I didn't set a timeline but hopefully we'll get a result within the next few days (that's not a promise though)