[RFC] Add voting majority RFC

[adamgreig]

RFC to address #193.

Rendered.

[thejpster]

I like the idea of dropping it to 33% for two weeks, but I'm not sure I like the idea of dropping it lower after that. If you can't find 33% of the sub-group to actively type "LGTM" on your issue, is it something we want published in the working groups' name?

[awygle]

I said this before, but I didn't see it in the Alternatives section, so I'll mention it here:

I'd like for an absent vote (rather than a "no" vote or explicit abstention) to not count towards the total number of votes when calculating percentages. In other words, if only 3 out of 17 vote yes, but only 4 out of 17 have voted at all, that should count as 75% approval. I would decide when a vote is "over" using the "no new discussion" criteria used by the Rust team - some fixed period of time (say 2 weeks) after no one has anything new to say, the vote is over. We could also require that any proposal get at least some number (say 3) of "yes" votes to pass.

The reason for this is that there are many proposals which are simply not relevant to all members. I am a member of the MSP430 team. I have no opinion on the formation of a Cortex-A team (is it sufficiently different from Cortex-M and Cortex-R? does it really count as embedded? should there just be an ARM team? I have no answers to any of these questions because I don't know enough). Sure I can stop by and explicitly abstain from that vote, but I don't see what value that gives to the process. And my abstention certainly shouldn't count against the proposal.

This is just my opinion, I'll go along with whatever the team decides, but I wanted to state it here again because it wasn't present in this RFC.

[hannobraun]

I'm in favor of this proposal, but I have one concern: Notifying Members defines several administrative tasks to be performed, but doesn't say who's going to perform them. I wouldn't want to create new work that then falls to @japaric by default.

Suggestion: The proposer is responsible for adding their RFC to the meeting agenda and sending reminders.

@thejpster

I like the idea of dropping it to 33% for two weeks, but I'm not sure I like the idea of dropping it lower after that. If you can't find 33% of the sub-group to actively type "LGTM" on your issue, is it something we want published in the working groups' name?

Not everyone cares about every issue, and I expect the percentage of the group that cares about the average issue to fall as the group grows. @awygle makes a very good point in that regard.

@awygle

In other words, if only 3 out of 17 vote yes, but only 4 out of 17 have voted at all, that should count as 75% approval.

I agree with the rest of your comment, but I think this bit makes no sense. If one of the four votes against, that would presumably be counted as a concern, and would prevent the RFC from being passed until the concern is resolved. In essence, if we don't count non-participation, an RFC requires 100% approval.

[awygle]

@hannobraun

If one of the four votes against, that would presumably be counted as a concern, and would prevent the RFC from being passed until the concern is resolved. In essence, if we don't count non-participation, an RFC requires 100% approval.

Yes, I should have been clearer - while I think in that scenario 3 out of 4 "yes" votes counts as 75% approval, I did not intend to take a position on whether such a resolution would pass or not. Personally I'd say that if the fourth vote was an explicit abstention, it would pass, whereas if it was a "no", we would try to reach consensus (but possibly eventually decide that majority rules, depending).

[hannobraun]

@awygle

Yes, I should have been clearer - while I think in that scenario 3 out of 4 "yes" votes counts as 75% approval, I did not intend to take a position on whether such a resolution would pass or not. Personally I'd say that if the fourth vote was an explicit abstention, it would pass, whereas if it was a "no", we would try to reach consensus (but possibly eventually decide that majority rules, depending).

Makes sense. Thanks for clarifying!

[adamgreig]

Thanks for the feedback so far!

@thejpster

If you can't find 33% of the sub-group to actively type "LGTM" on your issue, is it something we want published in the working groups' name?

This includes the wg as a whole, so I can easily imagine some whole-wg issues still struggling to get 33% of a (larger, future) wg to vote. Do you think this concern is allayed by letting issues be blocked on an issue-by-issue basis if someone is concerned there are not enough approvals?

@hannobraun

Suggestion: The proposer is responsible for adding their RFC to the meeting agenda and sending reminders.

Adding to the meeting agenda makes sense I think (and therefore the meeting minutes), but I'd rather there was just a single email sent out with all reminders, rather than each proposer sending out emails. Once the reminders are in the meeting agendas, hopefully it's easy for whoever is chairing the meeting to also send the single email with the list from the minutes?

@awygle
I like the idea of people being able to effectively say "I've seen this and don't want to specifically approve/reject it", but I'm worried we'd just be spending time to get people to perform even that action, and I'm not sure it's meaningfully different to someone just not interacting with the issue at all. Do you have any ideas on what 'I'm voting but not approving or rejecting' would look like in practice?

[awygle]

I'm not 100% sure I understand the question but I basically see four scenarios when Alice files an RFC w.r.t. Bob:

1. Bob never votes on it. It's as though Bob was not part of the team at all - the RFC passes or fails based on other people's votes.
2. Bob votes "no" on it. Bob's concerns are taken seriously and Alice works to resolve them.
3. Bob votes "yes" on it. Hooray!
4. Bob comments on the thread and says "hey, I know you probably want to hear from me on this because it's my area of expertise, but I have no opinion one way or another, just so you know." The RFC passes or fails based on other people's votes.

Does that answer the question?

[cr1901]

I've been a bit out of the loop; why was the "minimum threshold" eliminated? Feels like any proposal (except msp430 related ones :P) will garner at least 25% of people interested.

I understand the finite bandwidth concerns of course.

[posborne]

Overall, I'm on board. Just to get a better feel for it the current all group (at the time of writing) has 22 people so getting >50% (12 people) to approve can be a challenge and I would not be surprised to see the overall membership to grow. People get busy and it is easy to miss RFCs on occasion. At current numbers >33% would be 8 people and >25% would be 6 approvals.

Going 50% (1 wk) > 33% (1 wk) > 25% (1 wk) seems pretty good for me when you work out what this means in terms of numbers. For the final period after that I think it would be good to have 2 other people approve rather than just 1 -- I think we can find enough people to read through and give it a LGTM to make that happen. I do think leaving this final period at 33% will result in more stalled RFCs that probably should be pushed through (but still less than at 50%).

[adamgreig]

@awygle

Does that answer the question?

I completely agree with your four scenarios, so I guess yes!

@cr1901

I've been a bit out of the loop; why was the "minimum threshold" eliminated?

The concern is that as the wg as a whole continues to grow, even a 33% threshold can leave RFCs languishing not due to objections but just due to people being busy or interested in every matter. Setting an eventual absolute (as opposed to proportional to membership) threshold would prevent this from being a problem.

@posborne

For the final period after that I think it would be good to have 2 other people approve rather than just 1 -- I think we can find enough people to read through and give it a LGTM to make that happen.

I'm very happy to make it 2 non-proposer approvals required too. Just a question of what the best number is.

[adamgreig]

I've updated the RFC to hopefully make it a bit more palatable: it now requires at least two approvals by members other than the proposer to accept a proposal, and I've removed the requirement to email members in preference to listing votes on the weekly meeting agendas, but with a requirement that this is done to advance the timer. It is explicitly the responsibility of the proposer to ensure the vote is listed on the agenda.

We've had a few more votes languish recently (#207, #223 at least). @rust-embedded/all: please could people move to vote on this, or request changes?

[therealprof]

LGTM!

[adamgreig]

@rust-embedded/all another ping to please review/comment/approve this PR!

[andre-richter]

Current WG count 24. Two more needed for majority.

[andre-richter]

Current WG count 24. Two more needed for majority.

[andre-richter]

Current WG count 24. Two more needed for majority.

[andre-richter]

Current WG count 24. Two more needed for majority.

[andre-richter]

Current WG count is 24. 10 approvals already. Three more needed for majority.

[japaric]

This is currently tied in terms of approvals / members (12 / 24) but all concerns have been addressed and the RFC has been for a long time so members have had plenty of time to comment.

So I'm going to use my casting vote to break the tie and approve the RFC.

@adamgreig Thanks again for working on this!

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push