ops: hibernating

[japaric]

This PR proposes a process that lets members 'hibernate' themselves when busy /
absent with the goals of not having highfive assign PRs to them and reducing the
number of votes required to get voting majority.

[Disasm]

The problem is they will not be able to put themselves in "hibernation" state if they are absent or busy. The only way to enforce this is to automate the process of hibernation or at least to send a reminder time to time.

[hannobraun]

It's possible to be able to (barely) keep up, while at the same time being too busy to really participate. This is my current situation, and if this PR is accepted before that situation changes, I'm going to use this mechanism to retire myself.

It's already possible to remove team members without their participation: https://github.com/rust-embedded/wg/blob/master/rfcs/0136-teams.md#removing-members

[japaric]

The problem is they will not be able to put themselves in "hibernation" state if they are absent or busy

Sure, but the proposal says that members that will be busy or absent (in the future) should put themselves into hibernation (now). This proposal is for them. And as @hannobraun said people currently busy may still be able to hibernate themselves.

The only way to enforce this is to automate the process of hibernation

I don't think we should do this. Hibernation should be voluntary.

at least to send a reminder time to time.

I don't think we should do this either. Sending an e-mail (once) to /all when / if this (or any other significant change) occurs seems fine, though.

[hannobraun]

Will the member stay part of @rust-embedded/all? Would be nice to be able to keep up with internal discussions while you're away (although those happen rarely anyway).

[Disasm]

I think this can be achieved with tuning your notifications. We have "watch" button on each team page. So you can subscribe to /all and unsubscribe from everything else without any membership modifications.

[japaric]

@hannobraun no, /all is included in "their GitHub teams". We will not modify the member repository subscriptions, but IDK if removing someone from a team has any effects on their repository subscriptions.

[TeXitoi]

What is the problem this modification want to solve? Because hibernating looks like a heavy action.

For the problem of reaching a majority, the Google transit group have a different approach of voting: https://github.com/google/transit/blob/master/gtfs/CHANGES.md

TLDR:

• Call for vote, everyone have one week to vote.
• For vote to pass, you need at least 3 approvals and 0 rejection.
• rejections must be motivated.

Like that, everyone have the time to approve, and if you don't give your opinion within 1 week, you don't block the system. The 3 minimal approvals allow to validate that the proposition is not controversial and useful.

Now, the Google transit WG is much more fuzzy: there is no list of members and anyone can vote.

[japaric]

@TeXitoi

What is the problem this modification want to solve?

From the PR description:

"... with the goals of not having highfive assign PRs to them and reducing the number of votes required to get voting majority."

But more specifically the problem that this wants to solve is "you are busy and won't be able to participate for a while so you want to notify /all and be able to go absent without disrupting the operation of the EWG".

For the problem of reaching a majority

We already have a process to reduce the 50% voting majority.

FWIW, I think 1 week would be too fast for any kind of voting within the EWG. AFAIS most people tend to miss voting notifications and will only become aware of them at the weekly meetings.

[thejpster]

I'm happy with this. May need to use it myself this year...

[jamesmunns]

Thank you all! This has now been accepted.

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push