SIP simplified voting acceptance formula suggestion

Scala Improvement Process
1

Hello,

I first posted this issue on scala-sips google group. I understood from @jvican that SIP process discussion will be moved to dev.scala-lang.org, so I decided to move the discussion here. This post will also be used to clarify and compare the my formula to the pre-October meeting formula, and post-October meeting formula.

Definitions

P = Number of votes in favor of a proposal.
N = Number of votes opposed to a proposal.
M = Total number of SIP committee members.
Q = Number of people in quorum (SIP meeting attendees).
We will treat Q as number of non-abstaining votes (either absent or abstaining),
So, Q == P+N

Existing acceptance formula (prior to October meeting)

From SIP Specification and Submission regulation:

The Committee will only vote on proposals if Committee members have the quorum.
The quorum is two thirds (2/3) out of the total number of members.

For a SIP to be accepted, it must fulfill two requirements:

  • 70% of the quorum votes in favor of it.
  • Martin Odersky does not veto it.

Formalizing this using the definitions above we get that for a SIP to be accepted, the following formulas must be true (neglecting the veto option):

Q/M >= 2/3
P/Q >= 70%

As discussed during the October meeting and here, these regulations have the following problems (IIUC):

  • Participants of a SIP meeting were not allowed to abstain. If you’re not for it, then you’re opposed to it.
  • Not all committee members can attend always, and it affects the quorum’s capability to accepts SIPs.

Post-October meeting formula

The committee decided to change the vote acceptance regulation to the following (IIUC):

  • Allowed a committee member to vote even if did not attend the SIP meeting.

  • Allowed a committee member to abstain from voting.

  • Changed the formula to the following (watch Matin’s suggestion):

    Q/M >= 2/3 (“two thirds of the vote cast”)
    P/Q >= 50% (“fifty percents of cast votes are pro votes”)

New formula suggestion

P - N > T, where T is the threshold filter set by the committee’s decision.
I suggest setting T = M/2

The logic behind this formula
Enough people should care to vote in favor, while not enough people care to vote against.
How much is enough? That is set by T!

Example
Committee of 8 (M = 8), so T = 4

  • Proposal A: 4 persons in favor, none opposed, the rest have no opinion and abstain. The proposal is rejected.
  • Proposal B: 5 persons in favor, none opposed, the rest have no opinion and abstain. The proposal is accepted.
  • Proposal C: 5 persons in favor, 1 opposed, the rest have no opinion and abstain. The proposal is rejected.

Note 1 - The logic of Energy
This is a very strict rule for acceptance, but is logical. It is a sum of energies. How much energy people are willing to invest to fight for or against an idea. The sum must reach a certain threshold-level for a proposal to come through.

Note 2 - T can be constant
Lets say the committee can be as many as 20 people around the world. With such a large number of members, maybe you don’t require a majority of pro-voters. Maybe you set T to be 7 in such a case, as in “If there are at least 7 more people for this proposal than against it, we have enough ‘energy’ in the community to accept this proposal”. In the more general case:

T = Min(M/2, C), where C is a constant to be decided

Note 3 - Relaxation & Rounding
The formula can also be P - N >= T (added the =), to relax the acceptance.
When setting T as M/2, rounding up or down is to be considered.

1 Like
2

I really don’t like this proposal for three reasons

First or foremost, there just was a meeting about voting procedures that settled on an outcome that nobody seems to be unhappy with. There does’t seem to be a good reason to change anything from my perspective.

Second, while this proposal aims to be simpler, I don’t think it succeeds in that. If I get it right, the proposal comes down to that for a proposal to pass, four times the number of support votes plus two times the number of abstentions must be greater than three times the total committee size. I may be a simple soul, but if I were in the committees shoes, I’d find that way too complex. It took me way longer than I’d like to get an actual “vote numbers table” from that.

Thirdly, when I did, eventually, the numbers that come out don’t seem to align with the numbers the committee would like to see.

For the current committee of 8 members, the minimal vote for acceptance under this method are

  • 0 abstentions: 7 - 1
  • 1 abstention: 6 - 1
  • 2 abstentions: 6 - 0
  • 3 abstentions: 5 - 0

For more than 3 abstentions a proposal can’t pass.

For the proposal under Note 3 this becomes

  • 0 abs -> 6 - 2
  • 1 abs -> 6 - 1
  • 2 abs -> 5 - 1
  • 3 abs -> 5 - 0
  • 4 abs -> 4 - 0

Even for the second version, this is a higher or equal threshold than the “old” 70% for all of them, and that’s the threshold that was lowered in the meeting. Proposing to raise it higher than the thing the meeting lowered doesn’t seem to be in the spirit of the outcome of the meeting.

So to sum it up

  • There is no indication the committee sees the scheme that’s been accepted is a problem that needs fixing at all
  • The proposed scheme is rather complex
  • The proposed scheme is not in the spirit of the outcome of the last meeting

Note that I personally like the numbers from your proposal with Note 3. Having a high bar seems the right thing to me. If there are abstentions, that should have weight in rejecting the proposal - per Adriaan, if members of the committee can’t be convinced it’s a good idea, that shows that it might not be a good enough idea to change the language for it.

But I also have faith in the committee to know what they’re doing. That’s their job - and they did it already last meeting.

3

Thank you for your detailed reply.

  1. For your first reason for objection, I understand completely. I’m sorry I missed the opportunity to suggest this prior to the meeting (I only learned that vote acceptance regulation will be discussed a day before the meeting). I’m not saying they must adopt this suggestion today. If voting will become an issue in the future, the suggestion is here for discussion and use. Note 2 gives example where this concept can also help in the future (although I have no idea if the committee is able to grow in such a fashion).
  2. Subjective perspective on complexity. The committee members agreed that the current regulations are more complex than they’d like. Whether my suggestion is more or less complex to them (or the rest of the ‘normal’ world), I have no idea. :slight_smile:
  3. I’m not saying that my formula produces equivalent results to the current one. I actually do think that the committee would rather have a more strict filter on accepted proposals. Personally, the only thing that I see trouble with is that a 6:2 vote is rejected. That is why I suggested a possible relaxation (you can also do it in other ways by applying a more complex T).

I too have faith in the committee. I suggest this formula, because no one else has considered or mentioned it. I don’t know if the committee would have liked this or not prior to their discussion. I am aware that chances of this new formula to be seriously discussed in a SIP meeting are very slim right after selecting a formula.

The suggestion is here nonetheless, either for now or for the future.

Oron

4

Thanks a lot to both of you for your time considering and discussing the best voting formula for the SIP Committee.

I have just submitted the formalized voting rules agreed in our last meeting. I believe that the formalization makes the rules more understandable than they were in the meeting. I invite you to have a look if you want to suggest improvements to the explanation/wording.

With regard to @soronpo’s proposal, I like the logic and idea behind it. I share some of the comments that @martijnhoekstra has made, and especifically it worries me how difficult is to get a proposal accepted. In my opinion, supermajority helps us make decisions with a safe acceptance percentage without defaulting to a “probably-reject” strategy that would discourage users from improving the language. Yet, I think it’s an interesting proposal. As the Committee has gone through a slow process to decide our current rules, and all the members have voted on them, I prefer to keep this proposal for the future. It may happen that our current rules are proven buggy or don’t work in real life, and if that’s the case we all will study this proposal in more detail. If this happens to be the case, I will get back to you for further discussion.

Have a nice day.

1 Like