Add blog post about September SIP Meeting results #477

Closed
wants to merge 2 commits into
from

Projects

None yet

9 participants

@jvican
Member
jvican commented Sep 26, 2016

No description provided.

@jvican jvican Add blog post about September SIP Meeting results 8874f1b
@heathermiller
Member

Hey @dragos and @jsuereth could you guys provide your written feedback so we can publish this? We're waiting on all reviewers to release their feedback before we publish.

@soc

Can someone from the SIP committee explain the math behind "4 voted to accept, 2 voted to reject" -> "SIP-27 has been accepted?

(In my interpretation of math, 66.6% is less than 70%.)

@jvican
Member
jvican commented Sep 27, 2016

Hey @soc, thanks for asking. I'm the SIP Process lead.

70% of the Committee is 4.2 people. Here is what the regulations say:

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.

The regulations don't specify how rounding works. I took the liberty to round to the closest integer, which is 4 members in this case.

I admit that the regulations should be more clear on this detail. I will make sure to follow up and clarify the language.

@soc
Member
soc commented Sep 27, 2016

I think this after-the-fact rationalization is not acceptable. "Rounding" the results to whatever result is desired is not some small underspecified detail.

I think the whole process thing causes more harm than benefit, but the people who invented the process should now lie in the bed and follow it.
Otherwise, why even have them? Rubberstamping all proposals or flipping a coin would be more efficient.

Fact is that the proposal didn't achieve the required percentage.

+ report [here](https://github.com/scala/scala.github.com/pull/548).
+- [SIP-27: Trailing Commas](http://docs.scala-lang.org/sips/pending/trailing-commas.html).
+ The trailing commas proposal was acknowledged and numbered by the Committee
+ three months ago. This time, Dale Wijnand, his author, was invited as a
@dwijnand
dwijnand Sep 27, 2016 Member

s/his author/the author/

@jvican jvican Add link for Josh and Iulian's feedback 99e699b
+If you want to read all our previous minutes, head out to [the official website](http://docs.scala-lang.org/sips/minutes-list.html).
+
+Did you know that each month, we conduct these SIP meetings
+on-air? You can tune in and ask questions to the SIP committee, and have
@SethTisue
SethTisue Sep 27, 2016 Member

about live questions, I don't think we should allow/encourage this, actually. Community feedback should be provided in advance, it's too distracting to have it come in in the middle of a meeting. And in practice, we aren't actually doing it anyway.

@jvican
jvican Oct 21, 2016 Member

I agree Community feedback should be provided in advance. I think I have a formula for this... I'll try it out soon.

+ a more thorough environment analysis. Martin and Seth have left their
+ impressions on spores [here](http://disq.us/p/1c66wxe).
+- [SIP-26: Unsigned Integer Data Types](http://docs.scala-lang.org/sips/rejected/unsigned-integers.html).
+ Proposed by Sébastien Doeraene and Denys Shabalyn, unsigned integers have
@adriaanm
adriaanm Sep 27, 2016 edited Member

typo: "Denys Shabalin"

@dwijnand
Member

@soc

I'm reasonably sure that if @jsuereth hadn't left early he would've also voted accept, pushing the vote over 70%.

But then if @adriaanm had been present I would guess he would have voted against (just a guess). I'm not sure about @som-snytt having never seen him weigh in on the issue (to my recollection).

It does bring an interesting dynamic about who is present the day of the decision. So given how few yet very significant each vote is I wonder if it's perhaps a better representation of the committee's decision if everyone on the committee votes, even if it means the decision is revealed a few days later. The meetings are few and far between (once a month) so it's viable, and given how important the decisions are for the future of the language perhaps it's an improvement over the current process.

@sjrd
Member
sjrd commented Sep 27, 2016

So given how few yet very significant each vote is I wonder if it's perhaps a better representation of the committee's decision if everyone on the committee votes, even if it means the decision is revealed a few days later.

👍

@jvican
Member
jvican commented Sep 27, 2016

My job is to take decisions when things are not spec'ed, and then spec them to make sure the situation isn't repeated. The 70% rule exists to ensure that votes aren't simple majority votes; important decisions should be more than a 51%/49% split. However, the process doesn't consider the situation where we would 4% short of the 70%. Therefore, I decided on the fly the rounding strategy that fits better the spirit of the rule.

I want the SIP Process to be transparent. In this way, and because I admit that the rounding is an interpretation that should be decided by the whole Committee, I'm putting this proposal on hold. The Committee and I will discuss how to react before this situation in our next meeting.

I'm happy to revisit again how this voting procedure should be, and I hope to strike a balance and get a decision on which both the Community and the Committee members agree. Let's see what other people think about this.

@refried
Contributor
refried commented Sep 29, 2016

I don’t know anything about the SIP, just chiming in to suggest changing the number to 65% if that’s high enough. Or “at least one more than the number required for a simple majority”.

@dwijnand
Member

With the current rules for a proposal to be accepted it requires at least either 6/8 (75%), 5/7 (71%) or 5/6 (83%) accept votes.

With your proposal that changes the last one to 4/6 (67%), which is a simple majority.

But I do like the idea of changing the rule to "at least one more than the number required" instead of trying to pick a good percentage between 51-100%.

@soc
Member
soc commented Sep 30, 2016 edited

@refried I think the numbers should be much closer to 100% than to 70%. This is not some kind of election that you can repeat every few years and start from scratch again. Adding things has a high cost, and deprecating/removing things even more so.

@refried
Contributor
refried commented Sep 30, 2016

@soc That’s fine -- my suggestion was just to choose a policy and then abide by it. Not a very helpful suggestion, really.

@dwijnand
Member

@soc No progress will be made if you require 100%.

Think of the right-biased Either change, and how much back and forth happened there. If that had required a 100% acceptance it would have never happened.

@soc
Member
soc commented Sep 30, 2016

For me, the quality of proposals is more important than the quantity. I'd rather have three good proposals rejected than a bad one accepted.

(Also, I didn't say "require 100%", I said "closer to 100% than to 70%".)

I believe that rough consensus and running code will always be superior to committees, voting and paperwork.

@dwijnand
Member
dwijnand commented Oct 1, 2016

When you have 8 votes the cut-offs above 70% are 75%, 87.5% and 100%, so I just assumed you were after 100%. Were you thinking 87.5%? Ie. at most one person can disagree?

@soc
Member
soc commented Oct 1, 2016

Something like high 80% to low 90% seems to be about right. How that turns into persons-that-can-disagree will always vary, e. g. at the moment we are down two members, as all the community representatives have left the committee.

@SethTisue
Member

This PR has been sitting for a while now. I suggest revising it to say that the result of the vote was unclear and it'll get settled at the next meeting, and then go ahead and publish.

@SethTisue
Member

@jvican we need to do something here. what do you suggest?

@jvican
Member
jvican commented Oct 21, 2016 edited

@SethTisue I suggest we leave it open just in case some other community member wants to comment on the voting system that we will discuss in one week. I'm sure we can still great valuable insights. Regarding the release of this post, I would rather announce everything after our next SIP meeting (next Wednesday). Then, we close it.

@SethTisue
Member

ok, thanks for the update

@dwijnand
Member

For anyone here and not in the Gitter rooms, the next SIP meeting is tomorrow, Tuesday, not Wednesday.

@soronpo
soronpo commented Oct 27, 2016

Sorry I missed commenting here prior to the meeting, but I think I have a simplified formula for SIP acceptance. I also posted this here: https://groups.google.com/forum/#!topic/scala-sips/Pn2-hpFrwfA

P = Number of votes in favor
N = Number of votes opposed
T = Minimum for acceptance
(People can abstain)

So to accept the proposal the following formula must be true:

P - N > T

T is set as the required filter by the committee.
Suggestion: select T as half of the committee members.
Note: T can also be a constant

The logic behind this is that enough people should care to vote in favor, while not enough people care to vote against.

Example:
Committee of 8, so T = 4

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

Rounding when calculating T:
Considering that the condition is > in the formula, it is suggested that if indeed T is selected as half the members, then the number will be rounded down.
E.g: Number of committee members is 9, then T will be 4. So if 5 persons in favor with none against will accept the proposal.

@jvican
Member
jvican commented Oct 31, 2016

Thanks for the time invested in your proposal @soronpo!

I propose the discussion continues here: https://dev.scala-lang.org/t/sip-simplified-voting-acceptance-formula-suggestion/136.

@SethTisue
Member

@jvican closing just to get it out of the queue. assuming this in your own todo list somewhere

@SethTisue SethTisue closed this Nov 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment