How to deal with voting overhead?

[japaric]

In the last meeting it was mentioned that as the /all team grows it will take longer to approve proposals that require a voting majority from /all. /all currently has 19 members (and 2 pending invitations) so proposals need at least 10 votes to be approved.

This issue is to discuss ways to prevent this from becoming a problem in the future. We'll discuss this synchronously in the next meeting.

Any ideas?

cc @rust-embedded/all

[sekineh]

Current threshold is > 1/2 * 19.
The simple solution might be to try: 1/3, 1/4, 1/5, .....

Theoritically, too low threshold makes community hijacking easier.

[adamgreig]

We could have the threshold lower over time, e.g. 1/2 for week 1, then 1/3 for weeks 2-3, and perhaps as much as 1/4 thereafter.

Any concerns/rejections would veto the approval anyway, so if we have something sitting open with 1/3 approvals and no concerns raised in that time perhaps we could accept the smaller approval.

[adamgreig]

At the moment we don't seem to have the person who opened the PR vote on it, but assuming they are also a member of the appropriate group/the WG, should they be allowed to approve it as well? This might help push a number of RFCs over the majority threshold, and as far as I can tell is still in line with our majority definition.

[japaric]

Something I didn't get to mention during the meeting is that I think that notifying the people that they need to vote is a problem right now because the notifications get lost among other GH notifications.

So how about sending e-mail titled e.g. "[Action required] japaric has requested you to vote on this rust-embedded/wg issue" when we start a new voting process? Ideally this should be automatic but at least having a template to do it manually for now would be a good start. This would need the "@teams.rust-embedded.org" e-mails so it would be blocked on implementing that. And if we do the exponential backoff thing we could send new e-mails on the subsequent weeks to the people that have not yet voted.

[nvll]

Something that works for us with board member votes for our corporation (it's a long, silly story) is the idea of voting members being placed in a 'hibernation' state if they miss enough votes, so that if folks become inactive the number needed for quorum doesn't become more difficult to reach. Depending on needs, you could adjust how quickly hibernation sets in, or factor in the hibernation occurring due to taking too long to vote.

The wording we use can be seen at https://github.com/BadIdeaFactory/corporate/blob/fce461f45e793387fb03960deadf2cde38177a2a/documents/operating.md#hibernating-corporate-overlords

Hibernating Corporate Overlords
A Corporate Overlord can go into hibernation. Hibernation does not remove their ownership of BIFFUD or their entitlement to profit share, but their role as a voting member of the Hive is temporarily revoked until they attend a plotting session. Quorum and voting calculations do not include Corporate Overlords in hibernation.

There are two ways for Corporate Overlords to enter hibernation:

If a Corporate Overlord fails to attend four scheduled plotting sessions in a row, regardless of whether or not Quorum was met, they are automatically considered to be hibernating.

If a Corporate Overlord provides written communication to the Overmind that they wish to be placed into hibernation.

A Corporate Overlord exits hibernation immediately by attending a plotting session.

[japaric]

RFC #206, which addresses this issue, has been approved and merged.