Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: add information about CTC quorum rules #7813

Closed
wants to merge 4 commits into from
Closed

Conversation

Trott
Copy link
Member

@Trott Trott commented Jul 20, 2016

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.

@Trott Trott added doc Issues and PRs related to the documentations. meta Issues and PRs related to the general management of the project. labels Jul 20, 2016
better educate themselves about relevant issues. A vote is not valid unless
there is participation of a quorum of the CTC. A CTC quorum is more than half of
the CTC. Absentee votes may be cast in advance by commenting on the weekly CTC
agenda issue on GitHub. Explicit abtentions from voting constitute
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: abstentions

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo fixed! Thanks.

@Trott
Copy link
Member Author

Trott commented Jul 20, 2016

@nodejs/ctc

@ofrobots
Copy link
Contributor

This matches my understanding. LGTM.

@misterdjules
Copy link

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
Copy link
Member Author

Trott commented Jul 21, 2016

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
Copy link
Member Author

Trott commented Jul 21, 2016

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
Copy link
Member

indutny commented Jul 21, 2016

LGTM

@ChALkeR
Copy link
Member

ChALkeR commented Jul 21, 2016

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
Copy link
Member Author

Trott commented Jul 21, 2016

@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
Copy link
Member

ChALkeR commented Jul 22, 2016

@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
Copy link
Member

ChALkeR commented Jul 22, 2016

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
Copy link
Member Author

Trott commented Jul 22, 2016

@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
Copy link
Member

ChALkeR commented Jul 24, 2016

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

@misterdjules
Copy link

@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.

CTC quorum rules were not in writing. There was an informal
understanding between CTC members. Document the rules to avoid
differences in interpretation.
@Trott
Copy link
Member Author

Trott commented Jul 26, 2016

@misterdjules Updated!

@ChALkeR
Copy link
Member

ChALkeR commented Jul 27, 2016

LGTM

@misterdjules
Copy link

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
Copy link
Member

ChALkeR commented Jul 27, 2016

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

@Trott
Copy link
Member Author

Trott commented Jul 28, 2016

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 added a commit to Trott/io.js that referenced this pull request Jul 28, 2016
CTC quorum rules were not in writing. There was an informal
understanding between CTC members. Document the rules to avoid
differences in interpretation.

PR-URL: nodejs#7813
Reviewed-By: Сковорода Никита Андреевич <[email protected]>
Reviewed-By: Julien Gilli <[email protected]>
@Trott
Copy link
Member Author

Trott commented Jul 28, 2016

Landed in 96611d0

@Trott Trott closed this Jul 28, 2016
@cjihrig cjihrig mentioned this pull request Aug 8, 2016
cjihrig pushed a commit that referenced this pull request Aug 10, 2016
CTC quorum rules were not in writing. There was an informal
understanding between CTC members. Document the rules to avoid
differences in interpretation.

PR-URL: #7813
Reviewed-By: Сковорода Никита Андреевич <[email protected]>
Reviewed-By: Julien Gilli <[email protected]>
@cjihrig cjihrig mentioned this pull request Aug 11, 2016
MylesBorins pushed a commit that referenced this pull request Sep 9, 2016
CTC quorum rules were not in writing. There was an informal
understanding between CTC members. Document the rules to avoid
differences in interpretation.

PR-URL: #7813
Reviewed-By: Сковорода Никита Андреевич <[email protected]>
Reviewed-By: Julien Gilli <[email protected]>
MylesBorins pushed a commit that referenced this pull request Sep 28, 2016
CTC quorum rules were not in writing. There was an informal
understanding between CTC members. Document the rules to avoid
differences in interpretation.

PR-URL: #7813
Reviewed-By: Сковорода Никита Андреевич <[email protected]>
Reviewed-By: Julien Gilli <[email protected]>
rvagg pushed a commit that referenced this pull request Oct 18, 2016
CTC quorum rules were not in writing. There was an informal
understanding between CTC members. Document the rules to avoid
differences in interpretation.

PR-URL: #7813
Reviewed-By: Сковорода Никита Андреевич <[email protected]>
Reviewed-By: Julien Gilli <[email protected]>
MylesBorins pushed a commit that referenced this pull request Oct 26, 2016
CTC quorum rules were not in writing. There was an informal
understanding between CTC members. Document the rules to avoid
differences in interpretation.

PR-URL: #7813
Reviewed-By: Сковорода Никита Андреевич <[email protected]>
Reviewed-By: Julien Gilli <[email protected]>
@MylesBorins MylesBorins mentioned this pull request Oct 26, 2016
@Trott Trott deleted the quorum branch January 13, 2022 22:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations. meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants