opencontainers / opencontainers/tob

CHARTER: Two-thirds Voting Requirements

Open
#80 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
No language data
Stars
91
Forks
58
PR merge metrics
No merged PRs in 30d

Description

Okay, so the OCI Charter currently states that votes must pass with a super-majority (two-thirds). However, it seems that some sections conflict on the question of exactly how two-thirds are counted and I'd like to clarify whether these different voting rules are intentional:

Section 6 (n) states that all votes are passed with two-thirds of votes cast (this sentence is also phrased very strangely, mentioning the Trademark Board in the middle -- in fact I believe this is a copy-paste error from Section 4 (d) which uses very similar wording.) I also hasten to mention that it looks like voting on GitHub isn't actually okay according to the Charter but 🤷.

The intention is for the TOB to operate by consensus. However, if consensus cannot be achieved, the Trademark Board shall vote on a decision. All TOB Votes, either at TOB meetings, via email or electronic voting service, shall pass with a two-thirds vote of votes cast, on a one (1) vote per TOB member basis. An abstain vote equals not voting at all. [emphasis added]

However, Section 2 (c) appears to say that project approvals require a two-third vote of the entire TOB (so not voting counts as a vote against the motion). Maybe it's okay that this is a different rule, but this is one of the most important roles of the TOB and it's a bit odd that in a later section the rule appears to be contradicted by an unqualified "all".

Any Member can bring forward a new project proposal to the TOB for review. Approval of new OCI Projects requires a two-thirds vote of the TOB. [emphasis added]

And then Section 6 (h) also appears to say that changing the system of voting requires a two-third vote of the entire TOB (so not voting counts as a vote against the motion):

Initial elections of TOB members shall be run using the Condorcet-IRV method through the Cornell online service (http://civs.cs.cornell.edu/). The TOB may change the methodology or service used in future elections via a two-thirds approval vote of the then-serving TOB. [emphasis added]

And again in Section 6 (j)(ii) for calling meetings:

[The TOB shall meet on an as-needed basis, in a timely manner after issues are directed to the TOB from:] as the TOB determines via vote of at least two-thirds of the TOB members [empahsis added]

And yet again in Section 12 (a) for amending the Charter:

This Charter may be amended by a two thirds vote of the Technical Oversight Board, subject to veto by The Linux Foundation Board of Directors for reasonable cause, with thirty (30) days’ notice to the OCI Members before taking effect. [emphasis added]

So it seems like Section 6 (n) is simply an incorrect copy-paste of the Trademark Board's rules (there are literally no more references to TOB votes in the Charter other than the exceptions to Section 6 (n) I've listed). And from memory, we've always run votes as though Section 6 (n) didn't exist. So should we just remove it (as part of the cleanup I'm working on)?

This question is quite important when it comes to non-meeting votes (where we do not technically have to establish a quorum) because in such cases a two-thirds vote could be less than two-thirds of TOB members -- which seems like a bad idea.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the OCI Charter sections 2(c), 4(d), 6(h), 6(j)(ii), 6(n), and 12(a), then compare how each defines a two-thirds vote. Done means the TOB decides whether the rules are intentional, resolves the conflicting language, and publishes the clarified Charter text.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.