doc: add information about CTC quorum rules

[Trott]

Checklist

• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

doc meta

Description of change

CTC quorum rules were not in writing. There was an informal
understanding between CTC members. Document the rules to avoid
differences in interpretation.

[addaleax]

typo: abstentions

[Trott]

Typo fixed! Thanks.

[Trott]

@nodejs/ctc

[ofrobots]

This matches my understanding. LGTM.

[misterdjules]

I find the distinction between a vote to schedule a vote and an actual vote on a specific issue unclear and confusing. I think I understood the differences after reading @Trott's comment, but I'm not 100% sure.

If indeed there are two different set of rules for votes to schedule a vote and actual votes, would it help to separate the rules for each of them in different sections of the document?

[Trott]

I find the distinction between a vote to schedule a vote and an actual vote on a specific issue unclear and confusing.

I agree. I'd like those rules to be basically the same, for simplicity and clarity. But that would mean changing the existing rules.

EDIT: Or it could mean forgetting the whole quorum thing altogether and saying that nothing is a ratified decision without a simple majority of all CTC members. That would certainly add gravity to the need to keep folks active, as it means every inactive member means decisions are harder to make.

[Trott]

If indeed there are two different set of rules for votes to schedule a vote and actual votes, would it help to separate the rules for each of them in different sections of the document?

That's a good idea. If we need to have two separate sets of rules, being really explicit about where one set ends and the next begins is probably helpful.

[indutny]

LGTM

[ChALkeR]

Sorry, but this doesn't look like an improvement to me. In the current form, it rasies more questions (see comments above by @addaleax and @Fishrock123 ).

The key question is: if there is no consensus and a final vote is being cast, where:

• ctcSize people are in the CTC,
• present of whom are participating in the meeting
• previously do not participate but expressed their opinion vote through GitHub comment in advance,
• countPositive — positive,
• countNegative — negative,
• countAbstained — abstained (officially),
• countIgnored — did not vote for some reason (just subtract them from present, I guess?),
• countPositive + countNegative + countAbstained + countIgnored === present + previously,
• present + previously <= ctcSize,

what would the result of the vote be?

The same question for a (more common) case when there is a consensus (i.e. countNegative === 0 or countPositive === 0) — things could be different in that case.

I'm not proposing to include the code or formulae into the Readme, but it could help us better understand how things should look like here, and express that in common English after that.

[Trott]

@ChALkeR For a motion to close discussion on a contentious issue and schedule a vote, there would need to be more than half of ctcSize as stated in the document currently.

For the actual vote on the contentious issue:

• countPositive is the total number of people who vote yes (whether they are present or whether they register their vote on GitHub with a "I won't be at the meeting but I vote for X" comment)
• countNegative is the total number of people who vote no (again, whether they are present or whether they vote "no" on GitHub)
• countAbstained is the total number of people who explicitly abstain (again, whether they are present or not)
• countDidNotVote is everybody who is on the CTC who does not fall into one of the above three categories. They are not at the meeting and did not leave a vote or abstention comment. So there opinion is basically unknown.
• The four count* variables above total ctcSize, which is the number of members in the CTC.

The decision is whichever is the greater of countPositive or countNegative but if and only if countPositive + countNegative + countAbstained >= (ctcSize / 2) + 1. If that condition is not met, then no decision has been made yet and more votes or abstentions will have to be sought from the people who make up countDidNotVote.

[ChALkeR]

@Trott Thanks. I don't think this could be justified, sorry.

For example, if ctcSize = 20, 6 people are present and vote positive — there is no resolution.
However, if 5 more people were present and voted in any way, including negative or explicit abstaning — that would be a positive resolution.
This is absurd.

The algorithm you described is in no way better than requiring that countPositive > countNegative and countPositive > ceil(0.25 * ctcSize - 0.5 * countAbstained) (or the other way around for countNegative) — i.e. requiring that the total minimum number of votes in favor of the resolution is not less than 25% of the CTC, subtracting 2 (not a mistype) from the CTC size for each person abstained. That should be identical to what you described, but auto-filling with negative (positive) votes if that would help result in a positive (negative) outcome.

Do we still want that?

For starters, I would propose to subtract 1 from the effective CTC size for each person abstained, not 2 — else abstaining means being in favor of the resolution. It requires auto-filling as above (aka limiting the number of persons voted in favor of the resolution, not the quorum), else this would make abstaining being more negative that negative votes in some cases.

As the second point, I doubt that 25% should be the minimum requirement.

[ChALkeR]

So,

• Let's not limit the number of people voted, instead introduce a minimum required number of people in favor of the resolution. This is identical to «auto-filling» described above.
  The «quorum» would be the minimum number of people who theoretically could vote in a way that results in a resolution — so it's virtual, i.e. not reaching the quorum would result in no resolution, but reaching the quorum would not make any outcome of the vote a valid resolution.
• Let's subtract 1 from the effective CTC size for each person abstained, not 2.
• Are we sure about 25%? Shouldn't it be, like, 50%? 😉

Combining all of the above: «to get a resolution, more than 50% of the CTC size excluding the number of abstained members should be in favor of the resolution». How is that?

[Trott]

@ChALkeR wrote:

«to get a resolution, more than 50% of the CTC size excluding the number of abstained members should be in favor of the resolution».

That works for me.

[ChALkeR]

This probably should be at least mentioned on the CTC meeting again.

[misterdjules]

@Trott Is some of the feedback that was given in this PR ready to be integrated? That might help move the discussion forward, especially if this issue comes up in the next CTC meeting.

[Trott]

@misterdjules Updated!

[ChALkeR]

LGTM

[misterdjules]

Some of the concepts could be further clarified, like how one would "indicate that they abstain", but it looks like it's already an improvement. So LGTM, and we can always incrementally clarify this further with future PRs.

[ChALkeR]

@ofrobots, @indutny — you posted LGTMs on the previous version, but this PR was considerably revised. Could you take a look again, please?

[Trott]

Per the CTC meeting, I'm going to land this at this time. (We can always change it again if someone swoops in now with an objection.)

[Trott]

Landed in 96611d0