From b500eaf9d299195aba1136aedd3eb7caa8d82a1e Mon Sep 17 00:00:00 2001 From: Aleksa Sarai Date: Thu, 4 Jun 2020 14:09:59 +1000 Subject: [PATCH 1/9] CHARTER: s12(c): formalise charter versions and changelog We have version numbers (and a changelog) in the Charter, so we should probably actually enshrine that in the Charter. In addition, clean up the changelog format so that it's easier to understand. This change does introduce new requirements for the editors of the Charter, but it simply mirrors the current convention applied to Charter amendments. In addition, define the concept of a "draft Charter version" so that we can make iterative changes to the charter through separate PRs without having to enact each minor change separately. Signed-off-by: Aleksa Sarai --- CHARTER.md | 32 +++++++++++++++++++++++++------- 1 file changed, 25 insertions(+), 7 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 0384ef0..6d1b1f8 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -1,12 +1,18 @@ -# Open Container Initiative Charter v1.2 +# Open Container Initiative Charter v1.2+DRAFT -| Comment | Effective Date | -| ---------------- |:----------------:| -| Initial release | 13 November 2015 | -| Update | 18 May 2020 | -| Update (simplify)| 4 June 2020 | +| Version | Notice Date | Effective Date | Changes | +| --------- | ----------- | -------------- | ---------------------------------------- | +| 1.0 | 2015-11-13 | 2015-11-13 | *Initial release.* | +| 1.1 | 2020-05-06 | 2020-06-05 | • *(Section 1)* Remove scope table. | +| 1.2 | 2020-06-04 | 2020-07-04 | • *(Section 1)* Simplify mission. | +| 1.2+DRAFT | | | • *(Section 12)* Formalise changelog, version numbers, and draft charter versions. | -## 1. Mission of the Open Container Initiative (“OCI”). +> **NOTE**: The "notice date" is the date at which OCI Members were given +> notice regarding the relevant changes, and the "effective date" is the date +> when the respective version of the Charter came into effect -- in accordance +> with Section 12 (a) of this Charter. + +## 1. Mission of the Open Container Initiative ("OCI") The Open Container Initiative provides an open source technical community within which industry participants may easily contribute to building @@ -459,3 +465,15 @@ b. A Member may resign within such thirty-day notice period, or within the not have any effect on commitments made by the OCI Member or participant during the term of membership. Resignation may be made by email to the Executive Director of the Linux Foundation. + +c. Each version of this Charter will have a distinguishing version number, with + a changelog included in the preamble describing material changes to the + Charter. + +d. In order to facilitate collaborative development of this Charter, draft + versions of this Charter may be indicated by the suffix "+DRAFT" added to + the version number. These Charter versions are not enforceable, and the most + recently published non-draft Charter remains in effect until a newer + non-draft Charter is published. For the avoidance of doubt, amendments to a + draft Charter still must go through the same process as amendments to a + non-draft Charter (as described in Section 12 (a) of this Charter). From 9e008209ddccd770ee4227d1dab2ad29a531554e Mon Sep 17 00:00:00 2001 From: Aleksa Sarai Date: Fri, 5 Jun 2020 17:55:15 +1000 Subject: [PATCH 2/9] CHARTER: s6(n): clarify and unify TOB voting rules Section 6 (n) conflicted with all of the other mentions of TOB votes and TOB decisions, and we have always required a qualified super-majority for all TOB votes -- so it is best to properly codify that requirement in the Charter. In addition, Section 6 (n) appears to have had a copy-paste error which made the paragraph nonsensical (the Trademark Board has nothing to do with TOB votes). This has also been corrected. In addition, it is unnecessary to have a special carve-out for changing voting systems in Section 6 (h) because the TOB can simply amend the Charter to change the electoral system for TOB elections (which requires the same qualified super-majority -- and would likely be needed purely to allow TOB candidates to understand how the voting system operates). This change does (on paper) change the procedure for TOB votes, but the intention is to simply mirror the current convention of the TOB when it comes to voting on motions. It also removes an apparent mistake in the original Charter, as I do not believe it was ever intended that the Trademark Board be involved in TOB decisions. Signed-off-by: Aleksa Sarai --- CHARTER.md | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 6d1b1f8..dc167ae 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -5,6 +5,7 @@ | 1.0 | 2015-11-13 | 2015-11-13 | *Initial release.* | | 1.1 | 2020-05-06 | 2020-06-05 | • *(Section 1)* Remove scope table. | | 1.2 | 2020-06-04 | 2020-07-04 | • *(Section 1)* Simplify mission. | +| 1.2+DRAFT | | | • *(Section 6)* Unify TOB voting rules to always require a qualified super-majority for decisions. | | 1.2+DRAFT | | | • *(Section 12)* Formalise changelog, version numbers, and draft charter versions. | > **NOTE**: The "notice date" is the date at which OCI Members were given @@ -42,7 +43,8 @@ b. OCI Projects may be modified by the Technical Oversight Board so long as reference implementation for an optional layer item. c. 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. + Approval of a new OCI Project requires the TOB to decide in favour of the + proposal, following the process outlined in Section 6 (n) of this Charter. d. A project need not be contributed to the OCI in order to be deemed compliant with an associated OCI specification. For avoidance of doubt, a runtime can @@ -270,10 +272,8 @@ g. The initial TOB shall be established through a nomination and election nominated and elected by the OCI Members and serve for a period of two (2) years. Each OCI Member may nominate one (1) candidate for election. -h. 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. +h. Elections of TOB members shall be run using the Condorcet-IRV method + through the Cornell online service (http://civs.cs.cornell.edu/). i. The TOB shall elect a TOB Chair. The nominee with the most votes from the TOB members shall win the Chair position for a term of one (1) year. In the @@ -287,9 +287,9 @@ j. The TOB shall meet on an as-needed basis, in a timely manner after issues - i. the TDC by a simple majority vote of the maintainers when there is an issue that needs the resolution to assist the TDC to move forward, - - ii. as the TOB determines via vote of at least two-thirds of the TOB - members - - iii. the TOB Chair determines a meeting is necessary. + - ii. the TOB via a decision made using the process outlined in Section 6 + (n) of this Charter; or + - iii. the TOB Chair if they determine a meeting is necessary. k. TOB meetings may be held in-person or via telephone or electronic conferencing. @@ -306,10 +306,12 @@ m. Quorum for holding meetings shall be established when two-thirds of TOB members are present. n. 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. + cannot be achieved, the TOB shall vote on a decision. All TOB votes, either + at TOB meetings, via email or electronic voting service, shall pass with a + qualified super-majority (a two-thirds vote of the entire TOB membership in + favour of the motion in question), on a one (1) vote per TOB member basis. + For the avoidance of doubt, an abstain vote (or not voting) equals a vote + against the motion in question. o. Any issues that cannot be resolved by the TOB shall be referred to The Linux Foundation Executive Director for mediation, and, if necessary, for @@ -453,10 +455,10 @@ g. operate under such rules and procedures as may from time to time be approved ## 12. Amendments and Notice -a. 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. +a. This Charter may be amended by a TOB decision using the process outlined in + Section 6 (n) of this Charter, 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. b. A Member may resign within such thirty-day notice period, or within the period provided for in Section 8 (d) of this Charter, to avoid undertaking From efce6a6b6b187a0af0e1af2c3de6e650bfc9b0a9 Mon Sep 17 00:00:00 2001 From: Aleksa Sarai Date: Sat, 6 Jun 2020 06:03:58 +1000 Subject: [PATCH 3/9] CHARTER: s2: refine OCI Projects definition and scope We already have more than one type of project, but Section 2 (as written) doesn't appear to have a clear way of describing the different types of projects that exist. Given the "getting started" document's selection of "project buckets", we need to reflect those views in the Charter. This change does rearrange some parts of this Section of the Charter (and introduces several new concepts), but it is intended to primarily mirror the existing conventions of the OCI. In fact, it legitimises most of the projects which have been included after the initial Charter came into effect. This change *does not* add any additional restrictions to existing projects or potential OCI projects, as that will be handled in a separate patch. An additional restriction is added to OCI Conformance Suites, but that was a restriction which had already been followed in practice by the respective OCI Conformance Suite projects, so it simply is mirroring existing convention. Signed-off-by: Aleksa Sarai --- CHARTER.md | 171 ++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 117 insertions(+), 54 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index dc167ae..b4260b0 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -5,6 +5,7 @@ | 1.0 | 2015-11-13 | 2015-11-13 | *Initial release.* | | 1.1 | 2020-05-06 | 2020-06-05 | • *(Section 1)* Remove scope table. | | 1.2 | 2020-06-04 | 2020-07-04 | • *(Section 1)* Simplify mission. | +| 1.2+DRAFT | | | • *(Section 2)* Simplify OCI Project definition and clarify scope. | | 1.2+DRAFT | | | • *(Section 6)* Unify TOB voting rules to always require a qualified super-majority for decisions. | | 1.2+DRAFT | | | • *(Section 12)* Formalise changelog, version numbers, and draft charter versions. | @@ -27,42 +28,103 @@ standardizing technical areas undergoing innovation and debate. ## 2. OCI Projects -a. The OCI will maintain a collection of projects to execute its Mission (“OCI - Projects”). The initial OCI Projects shall be the specification (“OCI - Specification”) and runtime (“runc”) projects. When an OCI Project claims - that a feature is provided from the OCI Specification, all of its - constituent parts shall comply with the OCI Specification. An OCI project - may have additional capabilities that are not reflected in the associated - specification. In this case, it is understood that the specification (and - any associated test suites) are the standard for judging compliance, not the - reference implementation. - -b. OCI Projects may be modified by the Technical Oversight Board so long as - such modifications are in the spirit of the original charter. For example, - the TOB may choose to add a top level Compliance Test Suite project or a - reference implementation for an optional layer item. - -c. Any Member can bring forward a new project proposal to the TOB for review. - Approval of a new OCI Project requires the TOB to decide in favour of the - proposal, following the process outlined in Section 6 (n) of this Charter. - -d. A project need not be contributed to the OCI in order to be deemed compliant - with an associated OCI specification. For avoidance of doubt, a runtime can - be compliant with the OCI Specification even if: a)it differs substantially - from runC, b)it is housed outside the OCI, c)it is licensed differently from - runC, including if it is licensed under a proprietary license. - -e. In order to support d. above, it is expected that: - - - i. there may be functionality in runC that is not included in the - specification, provided that such functionality does not compromise - compliance with the specification, and - - ii. there may be multiple other implementations of the specification that - also contain functionality not included in the specification, and - - iii. there will be a strong bias to exclude items from the specification - in technical areas undergoing significant innovation and debate, - especially if those areas are likely to be the basis of differentiation - between competing implementations. +a. The OCI will maintain a collection of projects ("OCI Projects") to execute + its Mission as outlined in Section 1 of this Charter. + +b. Each OCI Project must belong to a category (hereafter "Project Category" in + this Section), meaning it must be categorised as: + + - i. a specification ("OCI Specification"), which describes an industry + standard that the OCI maintains, which must be within the scope of the + OCI's Mission as described in Section 1 of this Charter; or + - ii. a reference implementation ("OCI Reference Implementation"), which + implements an OCI Specification; or + - iii. a conformance test suite ("OCI Conformance Suite"), which can be used + to validate whether a (possibly third-party) project implements an OCI + Specification correctly, and may be used as a basis for judging + conformance to an OCI Specification (notwithstanding Section 2 (c) of this + Charter); or + - iv. a library ("OCI Library"), which is small, reusable, and can assist + other projects in implementing an OCI Specification. + +c. The initial OCI Projects shall be: + + - i. an OCI Specification for container runtimes ("OCI Runtime + Specification"); and + - ii. an OCI Reference Implementation of the OCI Runtime Specification + ("runc"). + +d. When an OCI Project claims that a feature is provided from an OCI + Specification, all of its constituent parts shall comply with the OCI + Specification. An OCI Project may have additional capabilities that are not + reflected in the associated OCI Specification. In this case, it is + understood that the OCI Specification (and any associated OCI Conformance + Suites) are the standard for judging compliance, not the OCI Project. For + the avoidance of doubt, this means that if there is a real or perceived + conflict between an OCI Specification and an OCI Conformance Suite, the OCI + Specification has precdence as the basis for conformance. + +e. The set of OCI Projects may be modified by the TOB using the process + outlined in Section 2 (e) of this Charter, so long as such modifications are + in the spirit of this Charter and are in accordance with Section 2 (a) of + this Charter. + +f. Any TDC member may bring forward a proposal to the TOB for a new or existing + project to be included in the set of OCI Projects. Approval of a new OCI + Project requires the TOB to decide in favour of the proposal, following the + process outlined in Section 6 (n) of this Charter. For the avoidance of + doubt, any project (once included in the OCI Projects) will be governed + under the rules of this Charter. + +g. A project need not be contributed to the OCI in order to be deemed compliant + with an OCI specification, nor need it only implement the set of features + defined in an OCI Specification. For the avoidance of doubt, a project can + be compliant with an OCI Specification even if: + + - i. it differs substantially from any associated OCI Reference + Implementation; or + - ii. it is not an OCI Project; or + - iii. it is licensed differently to any OCI Project, including if it is + licensed under a proprietary license; or + - iv. it implements features which are not included in the associated OCI + Specification. + +h. In order to facilitate Section 2 (g) of this Charter, + + - i. OCI Specifications: + + a. must have a strong bias to exclude items from the specification in + technical areas undergoing significant innovation and debate, especially + if those areas are likely to be the basis of differentiation between + competing implementations; and + + b. must establish a clear scope of the specification (hereafter + "Specification Scope" within this Section), which once established may + only be changed via a TOB decision, following the process outlined in + Section 6 (n) of this Charter. + + - ii. OCI Reference Implementations: + + a. may implement functionality outside of the Specification Scope of the + associated OCI Specification, but any such features must not compromise + compliance with the OCI Specification. + + - iii. OCI Conformance Suites: + + a. must only test for strict conformance with the OCI Specification + (meaning that they must not place requirements on any features + permitted under Sections (g)(i) and (g)(iv) of this Charter); and + + b. must not emit a conformance test failure for any optional features + within an OCI Specification (though they may produce a non-fatal + warning if the tested project does not follow a specific recommendation + given by the OCI Specification). + +i. Both the Project Category and Specification Scope of each OCI Project will + be maintained in [the TOB's repository](https://github.com/opencontainers/tob). + Changing an OCI Project's category requires a TOB decision in favour of the + change, following the process outlined in Section 6 (n) of this Charter, + with thirty (30) days’ notice to the OCI Members before taking effect. ## 3. Membership. @@ -117,8 +179,8 @@ e. The Trademark Board is intended to provide a minimalist governance structure responsible for: - i. creating the OCI trademarks associated with OCI Projects (including the - OCI Specification Project), the Open Container Format (OCF) or OCI - certified solutions. + OCI Specifications), the Open Container Format (OCF), or OCI certified + solutions. - ii. creating a certification program establishing the requirements for achieving the status of an “OCI Certified Solution” and defining the terms for using any OCI trademark(s) for an OCI Certified Solution; @@ -162,10 +224,10 @@ a. The OCI hosts and supports the participation of a technical development b. The OCI TDC has an established scope of work focused on: - - i. Creating and maintaining formal specifications (the OCI Specification - project) for container image formats and runtime, which will allow a - compliant container to be portable across all major, compliant operating - systems and platforms without artificial technical barriers; + - i. Creating and maintaining formal specifications (the OCI Specifications) + for container image formats and runtime, which will allow a compliant + container to be portable across all major, compliant operating systems and + platforms without artificial technical barriers; - ii. Ensuring that OCI Specifications incorporate and align to the OCI Values, as defined in Section 8 below; - iii. The TDC will look to agree on a standard set of container actions @@ -193,9 +255,9 @@ b. The OCI TDC has an established scope of work focused on: - xiii. Attempting to harmonize the OCI Specifications with other proposed standards, including, but not limited to, the appc specification; - xiv. Ensuring that the scope of technologies promulgated and proposed as - standard elements of OCI Projects (including the OCI Specification) are - those that are sufficiently widespread and sufficiently mature and stable - so as to warrant establishment in the specification; + standard elements of OCI Projects (including OCI Specifications) are those + that are sufficiently widespread and sufficiently mature and stable so as + to warrant establishment in the specification; - xv. Referring to the Technical Oversight Board any issues that deal with failure to follow established technical governance, issues that impact multiple OCI Projects or specifications, or conflicts that cannot be @@ -369,15 +431,16 @@ c. If an alternative inbound or outbound license is required for compliance contributions on an exception basis. Please email tob@opencontainers.org to obtain exception approval. -d. Upon finalization and release of a new version of any OCI specification, OCI - will notify all Members in writing using the contact information provided in - Exhibit A. As set forth in Section 12 of this Charter, Members may resign - from membership in OCI at any time within thirty (30) days following such - notification to avoid undertaking further obligations with respect to such - specification. All Members on the date thirty (30) days following such - notification will, without further action, be subject to the obligations set - forth in the Open Web Foundation Final Specification Agreement (OWFa 1.0) - (Patent Only) with respect to such specification. +d. Upon finalization and release of a new version of any OCI Specification, the + Executive Director will notify all Members in writing using the contact + information provided in Exhibit A. As set forth in Section 12 of this + Charter, Members may resign from membership in OCI at any time within thirty + (30) days following such notification to avoid undertaking further + obligations with respect to such specification. All Members on the date + thirty (30) days following such notification will, without further action, + be subject to the obligations set forth in the Open Web Foundation Final + Specification Agreement (OWFa 1.0) (Patent Only) with respect to such + specification. http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0—patent-only e. On the effective date of their membership, all Members will, without further From f2a32bfd24a5767e7c49e4e1a6d04c49ca3d8392 Mon Sep 17 00:00:00 2001 From: Aleksa Sarai Date: Sat, 6 Jun 2020 21:39:34 +1000 Subject: [PATCH 4/9] CHARTER: s5: rework TDC description and scope The TDC has been a fairly confusing concept from the outset, and the statement of the scope of the TDC was quite difficult to follow (not to mention that it contained some text which was only relevant to the runtime-spec). The text has been refreshed and now has a more general description of the role of the TDC now that the OCI has a pretty large variety of projects under its belt, and explicitly defines the Maintainership Coalition (the set of all maintainers across all projects). Previously, a literal reading of the Charter would have you believe that only runtime-spec maintainers had certain rights under the Charter. This change does redefine some aspects of the TDC, and technically changes the roles of different TDC elements, but broadly this is in keeping with existing conventions within the TDC of OCI Projects and doesn't majorly change the role of the TDC within the OCI. Signed-off-by: Aleksa Sarai --- CHARTER.md | 162 ++++++++++++++++++++++++++++++++--------------------- 1 file changed, 98 insertions(+), 64 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index b4260b0..bcecd6a 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -6,6 +6,7 @@ | 1.1 | 2020-05-06 | 2020-06-05 | • *(Section 1)* Remove scope table. | | 1.2 | 2020-06-04 | 2020-07-04 | • *(Section 1)* Simplify mission. | | 1.2+DRAFT | | | • *(Section 2)* Simplify OCI Project definition and clarify scope. | +| 1.2+DRAFT | | | • *(Section 5)* Simplify TDC description and enshrine all maintainers of OCI Projects as TDC Maintainers. | | 1.2+DRAFT | | | • *(Section 6)* Unify TOB voting rules to always require a qualified super-majority for decisions. | | 1.2+DRAFT | | | • *(Section 12)* Formalise changelog, version numbers, and draft charter versions. | @@ -213,72 +214,105 @@ h. For avoidance of doubt, OCI membership does not convey any rights to influence will come through code and specification contributions to the technical projects. -## 5. Technical Developer Community - -a. The OCI hosts and supports the participation of a technical development - community (“OCI TDC”) in OCI Projects. The OCI TDC shall be open to any - developer, end user or subject matter expert that chooses to participate in - the activities of OCI, regardless of whether the participant is employed by - an OCI Member company so long as his or her contributions and conduct comply - with this Charter. - -b. The OCI TDC has an established scope of work focused on: - - - i. Creating and maintaining formal specifications (the OCI Specifications) - for container image formats and runtime, which will allow a compliant - container to be portable across all major, compliant operating systems and - platforms without artificial technical barriers; - - ii. Ensuring that OCI Specifications incorporate and align to the OCI - Values, as defined in Section 8 below; - - iii. The TDC will look to agree on a standard set of container actions - (e.g. start, exec, pause) as well as a runtime environment associated with - the container runtime; - - iv. Creating and maintaining test cases that shall serve as the testing - functions for achieving certification as an OCI Certified Solution; - - v. Engaging end users for feedback or input on OCI Projects, including, - but not limited to, relating to usability; - - vi. Ensuring that all OCI Projects follow and adhere to the OCI IP Policy; - - vii. Approving releases by OCI Projects; - - viii. Creating, maintaining and enforcing governance guidelines for the - TDC, approved by the maintainers, and which shall be posted visibly for - the TDC. The guidelines shall cover the following: - - ix. establishing and defining roles and responsibilities (at a minimum, a +## 5. Technical Developer Community (TDC) + +a. The OCI shall host and support the participation of a technical development + community ("TDC"), encompassing all OCI Projects. The TDC consists of two + groups: + + 1. TDC Contributors, membership of which shall be open to any developer, end + user or subject matter expert that chooses to participate in the + activities of any OCI Project, regardless of whether the participant is + employed by an OCI Member company so long as their contributions and + conduct comply with this Charter. + 2. TDC Maintainers (hereafter "Maintainers"), which are the set of + maintainers for a given OCI Project (as listed in the top-level + MAINTAINERS file of the OCI Project). For the avoidance of doubt, all + Maintainers are also necessarily TDC Contributors. In addition: + + - i. an individual may only become a Maintainer of an OCI Project + after approval by whatever procedure that OCI Project's Maintainers + have established under Section 5 (b)(iii) of this Charter; and + - ii. only the Maintainers of an OCI Project may modify the set of + Maintainers for that OCI Project. No OCI Member, the TOB, the + Maintainers of different OCI Project, nor the Trademark Board may + modify the set of Maintainers for a given OCI Project (except in cases + where an existing Maintainer's contributions or conduct have not + complied with this Charter); and + - iii. the collection of Maintainers for all OCI Projects shall be + referred to in this Charter as the "Maintainership Coalition". + +b. The Maintainers of each OCI Project have a responsibility to create, + maintain and enforce governance guidelines for the TDC of their OCI Project, + which shall be posted visibly for the TDC. The guidelines shall cover: + + - i. establishing and defining roles and responsibilities (at a minimum, a role for committers or maintainers authorized to commit code to the - codebase); - - x. defining the process or requirements to take on a role in the TDC (e.g. - how to become a contributor, or how to become a maintainer); - - xi. the process by which participants in the TDC may give up or be revoked - of their roles (e.g. how to remove maintainers); the rules for decision - making in the TDC; and - - xii. any workflow or processes participants are expected to follow in - making or merging contributions. - - xiii. Attempting to harmonize the OCI Specifications with other proposed - standards, including, but not limited to, the appc specification; - - xiv. Ensuring that the scope of technologies promulgated and proposed as - standard elements of OCI Projects (including OCI Specifications) are those - that are sufficiently widespread and sufficiently mature and stable so as - to warrant establishment in the specification; - - xv. Referring to the Technical Oversight Board any issues that deal with - failure to follow established technical governance, issues that impact - multiple OCI Projects or specifications, or conflicts that cannot be - resolved within the TDC. Issues shall be referred to the TOB according to - the requirements in Section 6.; and - - xvi. Any issues of non-compliance with the OCI IP Policy shall be - immediately referred to The Linux Foundation. - -c. The maintainers and contributors shall set the technical direction of the - OCI Projects, with minimal interference by the Technical Oversight Board; - -d. The TDC will only accept influence through contribution. The primary means + codebase); and + - ii. defining the process or requirements to take on a role in the TDC + (including but not limited to how to become a contributor and how to + become a maintainer); and + - iii. the process by which participants in the TDC may give up or be + revoked of their roles (including but not limited to how to remove + maintainers); + - iv. the rules for decision making in the TDC; and + - v. any workflow or processes participants are expected to follow in + making or merging contributions; and + - vi. the procedure for approving and publishing releases of the OCI + Project. + +c. The TDC has an established scope of work for all OCI Projects. For each OCI + Project, the TDC has a responsibility to: + + - i. ensure that the OCI Project adheres to the general requirements for + OCI Projects and the specific requirements for their project's Project + Category, as outlined in Section 2 of this Charter; and + - ii. ensure that the OCI Project incorporates and aligns with the OCI + Values, as defined in Section 7 of this Charter; and + - iii. ensure that the OCI Project follows and adheres to the OCI IP Policy, + as outlined in Section 8 of this Charter. Any issues of non-compliance + with the OCI IP Policy shall be immediately referred to The Linux + Foundation; and + - iv. create and maintain the OCI Project such that it is portable across + all major, compliant operating systems and platforms without artificial + technical barriers; and + - v. engage end users for feedback or input on the OCI Project, including, + but not limited to, relating to usability. + +d. In addition to the responsibilities outlined in Section 5 (b) of this + Charter, Maintainers of OCI Specifications have a responsibility to: + + - i. attempt to harmonize the OCI Specification with other proposed + standards, including, but not limited to, the AppC specification; and + - ii. ensure that the scope of technologies promulgated and proposed as + elements of the OCI Specification are those that are sufficiently + widespread and sufficiently mature and stable so as to warrant + establishment in the specification; and + - iii. in addition to Section 5 (b)(vi) of this Charter, require a qualified + super-majority vote of Maintainers of the OCI Specification in order to + approve any release of the OCI Specification. + +e. In addition to the responsibilities outlined in Section 5 (b) of this + Charter, Maintainers of OCI Conformance Suites have a responsibility to + create and maintain test cases that shall serve as the testing functions for + achieving certification as an OCI Certified Solution. + +f. Notwithstanding Section 2 (i) of this Charter, the TDC Members and + Maintainers shall set the technical direction of the OCI Projects, with + minimal interference by the TOB. However, any issues that deal with failure + to follow established technical governance, issues that impact multiple OCI + Projects or specifications, or conflicts that cannot be resolved within the + TDC shall be referred to the TOB using the procedure outlined in Section 6 + of this Charter. Once an issue is referred to the TOB, the TOB is empowered + to resolve it (though such resolutions should be made in consultation with + the relevant Maintainers or the Maintainership Coalition). + +g. The TDC will only accept influence through contribution. The primary means for any organization to influence the technical direction of the OCI - Projects is via contribution or service as maintainers. OCI Members - specifically disclaim any right to influence technical direction either on - the basis of their financial contributions or their existence as OCI - Members; - -e. The maintainers of the TDC shall be those listed in the MAINTAINERS file in - the project repository, available at - (https://raw.githubusercontent.com/opencontainers/specs/master/MAINTAINERS). + Projects is via contribution as TDC Members or service as Maintainers. OCI + Members specifically disclaim any right to influence technical direction + either on the basis of their financial contributions or their existence as + OCI Members. ## 6. Technical Oversight Board (TOB) From f1cf8dd77d053bf03d193321fc06b7e3c910f2c1 Mon Sep 17 00:00:00 2001 From: Aleksa Sarai Date: Tue, 9 Jun 2020 16:50:15 +1000 Subject: [PATCH 5/9] CHARTER: s6: rework TOB description and procedures The description of the TOB had several pretty large omissions such as the election procedure (only the initial TOB election is described, and it doesn't match the procedure in use today) as well as a lack of clarity around which group of maintainers need to vote to raise an issue with the TOB. This change does introduce new requirements for the TOB and the Executive Director, but the purpose of this change is to simply bring it in line with the existing procedure employed by the TOB. Signed-off-by: Aleksa Sarai --- CHARTER.md | 169 ++++++++++++++++++++++++++++++++--------------------- 1 file changed, 104 insertions(+), 65 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index bcecd6a..7e1e4ce 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -8,6 +8,7 @@ | 1.2+DRAFT | | | • *(Section 2)* Simplify OCI Project definition and clarify scope. | | 1.2+DRAFT | | | • *(Section 5)* Simplify TDC description and enshrine all maintainers of OCI Projects as TDC Maintainers. | | 1.2+DRAFT | | | • *(Section 6)* Unify TOB voting rules to always require a qualified super-majority for decisions. | +| 1.2+DRAFT | | | • *(Section 6)* Update TOB procedures, codify election process, and remove outdated sections. | | 1.2+DRAFT | | | • *(Section 12)* Formalise changelog, version numbers, and draft charter versions. | > **NOTE**: The "notice date" is the date at which OCI Members were given @@ -316,12 +317,11 @@ g. The TDC will only accept influence through contribution. The primary means ## 6. Technical Oversight Board (TOB) -a. The TOB is responsible for managing conflicts, violations of procedures or - guidelines and any cross-project or high-level issues that cannot be - resolved in the TDC for OCI Projects. The TOB shall also be responsible for - adding, removing or reorganizing OCI Projects. The TOB shall not dictate or - interfere with the day-to-day work of individual OCI Projects or their - decisions. +a. The OCI shall have a Technical Oversight Board ("TOB"), which is responsible + for managing conflicts, violations of procedures or guidelines and any + cross-project or high-level issues that cannot be resolved by the TDC. The + TOB shall not dictate or interfere with the day-to-day work of individual + OCI Projects or their decisions. b. The TOB shall be responsible for adopting any policies related to the scope of the TOB and ensuring they are documented publicly. @@ -337,79 +337,118 @@ c. The TOB shall operate transparently with any discussions and mailing lists shall also require a representative from The Linux Foundation to ensure this option is not being abused. -d. While the initial TDC shall have one TDC, as the OCI evolves, the TOB may - decide to establish a TDC per OCI Project, requiring contributors to earn - maintainer status independently within each OCI Project in which they wish - to participate. - -e. The TOB shall be composed of nine (9) individuals elected for their - expertise, contribution to the advancement of container technologies and are - considered to be thought leaders in the OCI ecosystem. Anyone may be elected - to the TOB, regardless of whether the individual is an employee of an OCI - Member, so long as they are an OCI TDC participant. A TOB member is elected - as an individual and not as a representative of his or her employer. No more - than two (2) TOB members may be employed by the same entity or its - affiliates. Affiliates shall be defined as entities owning 50% or more of an - entity, or owned by or under common ownership with each other. TOB members - may not designate alternative representatives. - -f. TOB members shall be split into two (2) groups, serving for a term of two - (2) years on a staggered basis, where one group is elected each year. The - initial TOB will have four (4) TOB members who will only serve for a term of - one year and five (5) TOB members that serve for a term of two (2) years. - -g. The initial TOB shall be established through a nomination and election - process. The first group from which four (4) TOB members shall be elected, - will be nominated and elected by the current TDC maintainers, initially - identified in Section 4(e), and serve for a period of one (1) year. Each TDC - maintainer may nominate up to two (2) candidates for election, except that - only one (1) nominee may be employed by the TDC maintainer’s own company. - The second group from which five (5) TOB members shall be elected, will be - nominated and elected by the OCI Members and serve for a period of two (2) - years. Each OCI Member may nominate one (1) candidate for election. - -h. Elections of TOB members shall be run using the Condorcet-IRV method - through the Cornell online service (http://civs.cs.cornell.edu/). - -i. The TOB shall elect a TOB Chair. The nominee with the most votes from the - TOB members shall win the Chair position for a term of one (1) year. In the - event of a tie vote, a random selection process (e.g. coin toss) shall be - used to determine the winner. The TOB Chair shall have the responsibility to - call meetings of the TOB and set TOB meeting agendas with input from TOB - members. - -j. The TOB shall meet on an as-needed basis, in a timely manner after issues - are directed to the TOB from: - - - i. the TDC by a simple majority vote of the maintainers when there is an - issue that needs the resolution to assist the TDC to move forward, - - ii. the TOB via a decision made using the process outlined in Section 6 +d. The TOB shall be composed of nine (9) individuals elected by the + Maintainership Coalition for their expertise, contribution to the + advancement of container technologies and are considered to be thought + leaders in the OCI ecosystem. A TOB member is elected as an individual and + not as a representative of his or her employer. TOB members may not + designate alternative representatives. + +e. An individual is incapable of being a member of the TOB if they at any point + during their tenure they: + + - i. are not a member of the TDC; or + - ii. become unable to exercise their duties as a TOB member; or + - iii. are employed by the same entity or affiliate as two (2) or more other + TOB members. Affiliates shall be defined as entities owning 50% or more of + an entity, or owned by or under common ownership with each other. + +f. TOB members shall be split into two (2) groups counting four (4) and five + (5) members each, both serving for a term of two (2) years on a staggered + basis, with an election being held each year alternating between which + group's seats are up for election. + +g. The TOB membership shall be chosen through a nomination and election + process, organised by the Executive Director. The procedure for nomination + and election of seats shall be: + + 1. The Executive Director shall publicly call for nominations no less than + four (4) weeks before the expiry of the current group of TOB seats, or + immediately if the seats have already become vacant. The nomination + period shall last a minimum of two (2) weeks. + 2. Each member of the Maintainership Coalition may privately nominate up to + two (2) candidates, with no more than (1) nominated candidate being + employed by the same entity or affiliate as the Maintainer. Affiliate + shall be defined as in Section 6 (e)(iii) of this Charter. Information + about which member nominated which candidate must remain private. + 3. The Executive Director shall call for a vote for the TOB seats with all + nominated candidates (who are elligible under Section 6 (e) of this + Charter) being included as choices on the ballot, using the voting + procedure prescribed in Section 6 (j) of this Charter. Each member of the + Maintainership Coalition is entitled to only one (1) vote, regardless of + whether the individual is a Maintainer of a single or multiple OCI + Projects. The voting period shall last a minimum of two (2) weeks. + 4. Upon the conclusion of the election, the members-elect shall become TOB + members upon expiry (or vacancy) of the TOB seats. + +h. Notwithstanding Section 6 (f) through (g) of this Charter, the initial TOB + shall have its four (4) member group only serve a term of one (1) year and + will be nominated and elected by OCI Members, with each OCI Member being + permitted to nominate one (1) candidate for election and being given one (1) + vote. For the avoidance of doubt, this procedure only applies to the initial + TOB, and the five (5) member group of the initial TOB shall serve a term of + two (2) years and be nominated and elected through the procedure defined in + Section 6 (g) of this Charter. + +i. After each election the TOB shall, before the dispatch of any other + business, elect one (1) TOB member (using the procedure described in + Section 6 (g) of this Charter) to be the TOB Chair, who shall hold that + position for a term of one (1) year. In the event of a tie vote, a random + selection process (such as a fair coin toss) shall be used to determine the + winner. The TOB Chair shall have the responsibility to call meetings of the + TOB and set TOB meeting agendas with input from TOB members. + +j. Elections of TOB members and the TOB chair shall be run by the Executive + Director, using the Condorcet-IRV method through the [Condorcet Internet + Voting Service](https://civs.cs.cornell.edu/). Upon the completion of any + vote using this procedure, the Executive Director must announce the results + of the vote publicly. + +k. The TOB shall meet on an as-needed basis to discuss any agenda set by the + TOB Chair, who may set such an agenda at any time if they determine a + meeting is necessary. Members of the TDC outside of the TOB may attend and + participate in TOB meetings, but cannot vote on motions nor raise issues + which are not part of the meeting agenda. + +l. In the case of any issues being directed to the TOB, the TOB Chair must call + a meeting in a timely manner with an agenda including the issues directed to + the TOB, so that the TOB may resolve them. An issue may be directed to the + TOB from: + + - i. the Maintainers of one (1) or more OCI Projects, by a qualified + majority vote of the set of Maintainers of the given OCI Projects, for an + issue involving only the given OCI Projects; or + - ii. the Maintainership Coalition, by a qualified majority vote; or + - iii. the TOB via a decision made using the process outlined in Section 6 (n) of this Charter; or - - iii. the TOB Chair if they determine a meeting is necessary. + - iv. the TOB Chair if they determine a meeting is necessary. -k. TOB meetings may be held in-person or via telephone or electronic - conferencing. - -l. Issues should be referred to the TOB sufficiently in advance of a meeting to +m. Issues should be referred to the TOB sufficiently in advance of a meeting to provide an appropriate time for TOB members to evaluate the issues, and the positions of the TDC, the positions of users, as well as sufficient time to explore compromise solutions. It is expected an appropriate review should - require at least a two-week review period, though it is recognized some - timecritical circumstances may call for a shorter review (e.g. security + require at least a two (2) week review period, though it is recognized some + time-critical circumstances may call for a shorter review (such as security issues). -m. Quorum for holding meetings shall be established when two-thirds of TOB - members are present. +n. TOB meetings may be held in-person or via telephone or electronic + conferencing. Quorum for holding meetings shall be established when + two-thirds of TOB members are present. If the TOB is unable to form a + quorum, the TOB Chair must call subsequent meetings in a timely manner with + the same agenda until a quorum is formed. -n. The intention is for the TOB to operate by consensus. However, if consensus +o. The intention is for the TOB to operate by consensus. However, if consensus cannot be achieved, the TOB shall vote on a decision. All TOB votes, either at TOB meetings, via email or electronic voting service, shall pass with a qualified super-majority (a two-thirds vote of the entire TOB membership in favour of the motion in question), on a one (1) vote per TOB member basis. For the avoidance of doubt, an abstain vote (or not voting) equals a vote - against the motion in question. + against the motion in question. If a vote is conducted outside of a TOB + meeting, the vote will be organised by the Executive Director and must have + a clearly established deadline at which point the votes will be tallied and + announced by the Executive Director. -o. Any issues that cannot be resolved by the TOB shall be referred to The Linux +p. Any issues that cannot be resolved by the TOB shall be referred to the Linux Foundation Executive Director for mediation, and, if necessary, for resolution by The Linux Foundation Board of Directors. From b5d95cab33f61eec8de07a38391af85ad61dd0c3 Mon Sep 17 00:00:00 2001 From: Aleksa Sarai Date: Sat, 6 Jun 2020 13:44:28 +1000 Subject: [PATCH 6/9] CHARTER: s2(h)..(j): restrict OCI Reference Implementations scope A common problem we've had with runc is that we have ended up implementing a lot of features that are technically within the scope of the OCI Runtime Specification but are not defined by that specification. As a result, users end up depending on runc's particular behaviour rather than the behaviour outlined in the specification. This hopefully establishes a middle-ground between allowing for experimental development within an OCI Reference Implementation, and the anarchy that is allowing for features to become depended on within an OCI Reference Implementation without the prerequisite OCI Specification work. Unfortunately, this problem already exists within runc so we cannot mandate it to no longer be the case (sadly that's not how technology works). But the next best thing we can do is mandate it for any future OCI Reference Implementations, and provide a one-time carve-out for the runc project (to avoid this Charter update from bringing into question the validity of the runc project within the OCI). This change does introduce new restrictions for OCI Reference Implementations which were not an existing convention for runc, though in my view this would've been the convention for future OCI Reference Implementations without this Charter change. Signed-off-by: Aleksa Sarai --- CHARTER.md | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 7e1e4ce..f5340c9 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -6,6 +6,7 @@ | 1.1 | 2020-05-06 | 2020-06-05 | • *(Section 1)* Remove scope table. | | 1.2 | 2020-06-04 | 2020-07-04 | • *(Section 1)* Simplify mission. | | 1.2+DRAFT | | | • *(Section 2)* Simplify OCI Project definition and clarify scope. | +| 1.2+DRAFT | | | • *(Section 2)* Restrict out-of-specification features in OCI Reference Implementations. | | 1.2+DRAFT | | | • *(Section 5)* Simplify TDC description and enshrine all maintainers of OCI Projects as TDC Maintainers. | | 1.2+DRAFT | | | • *(Section 6)* Unify TOB voting rules to always require a qualified super-majority for decisions. | | 1.2+DRAFT | | | • *(Section 6)* Update TOB procedures, codify election process, and remove outdated sections. | @@ -58,13 +59,14 @@ c. The initial OCI Projects shall be: d. When an OCI Project claims that a feature is provided from an OCI Specification, all of its constituent parts shall comply with the OCI - Specification. An OCI Project may have additional capabilities that are not - reflected in the associated OCI Specification. In this case, it is - understood that the OCI Specification (and any associated OCI Conformance - Suites) are the standard for judging compliance, not the OCI Project. For - the avoidance of doubt, this means that if there is a real or perceived - conflict between an OCI Specification and an OCI Conformance Suite, the OCI - Specification has precdence as the basis for conformance. + Specification. Section 2 (g) of this Charter notwithstanding, an OCI Project + may have additional capabilities that are not reflected in the associated + OCI Specification. In this case, it is understood that the OCI Specification + (and any associated OCI Conformance Suites) are the standard for judging + compliance, not the OCI Project. For the avoidance of doubt, this means that + if there is a real or perceived conflict between an OCI Specification and an + OCI Conformance Suite, the OCI Specification has precdence as the basis for + conformance. e. The set of OCI Projects may be modified by the TOB using the process outlined in Section 2 (e) of this Charter, so long as such modifications are @@ -109,7 +111,12 @@ h. In order to facilitate Section 2 (g) of this Charter, a. may implement functionality outside of the Specification Scope of the associated OCI Specification, but any such features must not compromise - compliance with the OCI Specification. + compliance with the OCI Specification; and + + b. must not implement functionality within the Specification Scope of the + associated OCI Specification, without clearly marking such features as + experimental and subject to change in response to any future + developments within the OCI Specification. - iii. OCI Conformance Suites: @@ -128,6 +135,11 @@ i. Both the Project Category and Specification Scope of each OCI Project will change, following the process outlined in Section 6 (n) of this Charter, with thirty (30) days’ notice to the OCI Members before taking effect. +j. Due to historical considerations, the OCI Runtime Reference Implementation + ("runc") project is exempt from the requirements of Section 2 (h)(ii)(b) of + this Charter. For the avoidance of doubt, no other OCI Reference + Implementations are granted such an exemption. + ## 3. Membership. a. The Open Container Initiative shall be composed of: From 650a499698404379999fd415fa6f357bfedd277b Mon Sep 17 00:00:00 2001 From: Aleksa Sarai Date: Tue, 9 Jun 2020 18:57:18 +1000 Subject: [PATCH 7/9] CHARTER: s6(q)..(s): add No-Confidence Motions to dissolve TOB Signed-off-by: Aleksa Sarai --- CHARTER.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/CHARTER.md b/CHARTER.md index f5340c9..6f1549a 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -10,6 +10,7 @@ | 1.2+DRAFT | | | • *(Section 5)* Simplify TDC description and enshrine all maintainers of OCI Projects as TDC Maintainers. | | 1.2+DRAFT | | | • *(Section 6)* Unify TOB voting rules to always require a qualified super-majority for decisions. | | 1.2+DRAFT | | | • *(Section 6)* Update TOB procedures, codify election process, and remove outdated sections. | +| 1.2+DRAFT | | | • *(Section 6)* Add No-Confidence Motions to allow the Maintainers Coalition to dissolve the TOB. | | 1.2+DRAFT | | | • *(Section 12)* Formalise changelog, version numbers, and draft charter versions. | > **NOTE**: The "notice date" is the date at which OCI Members were given @@ -464,6 +465,29 @@ p. Any issues that cannot be resolved by the TOB shall be referred to the Linux Foundation Executive Director for mediation, and, if necessary, for resolution by The Linux Foundation Board of Directors. +q. If the Maintainership Coalition feels that the TOB does not represent their + interests, they may raise a No-Confidence Motion by a qualified majority + vote. Votes for No-Confidence Motions must be announced publicly and will be + administered by the Executive Director using the procedure in Section 6 (j) + of this Charter. If a No-Confidence motion is passed, then the entire TOB is + immediately dissolved and an election is held to replace all of the TOB + seats. + +r. The procedure for an election under Section 6 (q) of this Charter is + identical to that of Section 6 (g) of this Charter, except that the four (4) + member group of the TOB will only hold their seat for one (1) year in order + to maintain the staggered terms outlined in Section 6 (f) of this Charter. + The four (4) member group will be chosen as being the least-favoured choices + in the election who cleared the threshold for election. In the case of any + ambiguity (such as a tie for 5th place), a random selection process (such as + a fair coin toss) shall be used to select which member-elect will be part of + the four (4) member group. + +s. In order to avoid abuse of No-Confidence Motions, they cannot be announced + within two (2) weeks before or after a TOB election nor within ninety (90) + days of a previous No-Confidence Motion (even if the previous motion was not + successfully passed). + ## 7. OCI Values. The TDC and TOB shall strive to reflect and adhere to the following values From 6a44e5533b81d5a098b7bac71c9d33155df1f151 Mon Sep 17 00:00:00 2001 From: Aleksa Sarai Date: Thu, 4 Feb 2021 12:11:33 +1100 Subject: [PATCH 8/9] CHARTER: s6(k): outline by-elections Previously there was no procedure to deal with members becoming incapable during a TOB term. Luckily we've never run into this issue but the IBM/RedHat merger could've easily triggered this problem, so it's a good idea to resolve this now if we can. Signed-off-by: Aleksa Sarai --- CHARTER.md | 44 +++++++++++++++++++++++++++++--------------- 1 file changed, 29 insertions(+), 15 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 6f1549a..33466e3 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -11,6 +11,7 @@ | 1.2+DRAFT | | | • *(Section 6)* Unify TOB voting rules to always require a qualified super-majority for decisions. | | 1.2+DRAFT | | | • *(Section 6)* Update TOB procedures, codify election process, and remove outdated sections. | | 1.2+DRAFT | | | • *(Section 6)* Add No-Confidence Motions to allow the Maintainers Coalition to dissolve the TOB. | +| 1.2+DRAFT | | | • *(Section 6)* Describe the procedure for by-elections. | | 1.2+DRAFT | | | • *(Section 12)* Formalise changelog, version numbers, and draft charter versions. | > **NOTE**: The "notice date" is the date at which OCI Members were given @@ -77,7 +78,7 @@ e. The set of OCI Projects may be modified by the TOB using the process f. Any TDC member may bring forward a proposal to the TOB for a new or existing project to be included in the set of OCI Projects. Approval of a new OCI Project requires the TOB to decide in favour of the proposal, following the - process outlined in Section 6 (n) of this Charter. For the avoidance of + process outlined in Section 6 (o) of this Charter. For the avoidance of doubt, any project (once included in the OCI Projects) will be governed under the rules of this Charter. @@ -106,7 +107,7 @@ h. In order to facilitate Section 2 (g) of this Charter, b. must establish a clear scope of the specification (hereafter "Specification Scope" within this Section), which once established may only be changed via a TOB decision, following the process outlined in - Section 6 (n) of this Charter. + Section 6 (o) of this Charter. - ii. OCI Reference Implementations: @@ -133,7 +134,7 @@ h. In order to facilitate Section 2 (g) of this Charter, i. Both the Project Category and Specification Scope of each OCI Project will be maintained in [the TOB's repository](https://github.com/opencontainers/tob). Changing an OCI Project's category requires a TOB decision in favour of the - change, following the process outlined in Section 6 (n) of this Charter, + change, following the process outlined in Section 6 (o) of this Charter, with thirty (30) days’ notice to the OCI Members before taking effect. j. Due to historical considerations, the OCI Runtime Reference Implementation @@ -417,13 +418,24 @@ j. Elections of TOB members and the TOB chair shall be run by the Executive vote using this procedure, the Executive Director must announce the results of the vote publicly. -k. The TOB shall meet on an as-needed basis to discuss any agenda set by the +k. If at any point a TOB member becomes incapable of holding their seat (as + defined in Section 6 (e) of this charter), their seat shall become vacant + and a by-election shall be called using the procedure described in Section 6 + (g) of this Charter to fill the vacant seat. The newly elected TOB member + shall serve the outgoing TOB member's remaining term. For the avoidance of + doubt, if more than one TOB member becomes incapable of holding their seat + (such as a merger resulting in more than two TOB members being employed by + the same entity or affiliate as described in Section 6 (e)(iii) of this + Charter), all incapable TOB members' seats will become vacant simultaneously + and only one by-election will be held to fill all vacant seats. + +l. The TOB shall meet on an as-needed basis to discuss any agenda set by the TOB Chair, who may set such an agenda at any time if they determine a meeting is necessary. Members of the TDC outside of the TOB may attend and participate in TOB meetings, but cannot vote on motions nor raise issues which are not part of the meeting agenda. -l. In the case of any issues being directed to the TOB, the TOB Chair must call +m. In the case of any issues being directed to the TOB, the TOB Chair must call a meeting in a timely manner with an agenda including the issues directed to the TOB, so that the TOB may resolve them. An issue may be directed to the TOB from: @@ -433,10 +445,10 @@ l. In the case of any issues being directed to the TOB, the TOB Chair must call issue involving only the given OCI Projects; or - ii. the Maintainership Coalition, by a qualified majority vote; or - iii. the TOB via a decision made using the process outlined in Section 6 - (n) of this Charter; or + (o) of this Charter; or - iv. the TOB Chair if they determine a meeting is necessary. -m. Issues should be referred to the TOB sufficiently in advance of a meeting to +n. Issues should be referred to the TOB sufficiently in advance of a meeting to provide an appropriate time for TOB members to evaluate the issues, and the positions of the TDC, the positions of users, as well as sufficient time to explore compromise solutions. It is expected an appropriate review should @@ -444,13 +456,13 @@ m. Issues should be referred to the TOB sufficiently in advance of a meeting to time-critical circumstances may call for a shorter review (such as security issues). -n. TOB meetings may be held in-person or via telephone or electronic +o. TOB meetings may be held in-person or via telephone or electronic conferencing. Quorum for holding meetings shall be established when two-thirds of TOB members are present. If the TOB is unable to form a quorum, the TOB Chair must call subsequent meetings in a timely manner with the same agenda until a quorum is formed. -o. The intention is for the TOB to operate by consensus. However, if consensus +p. The intention is for the TOB to operate by consensus. However, if consensus cannot be achieved, the TOB shall vote on a decision. All TOB votes, either at TOB meetings, via email or electronic voting service, shall pass with a qualified super-majority (a two-thirds vote of the entire TOB membership in @@ -459,13 +471,15 @@ o. The intention is for the TOB to operate by consensus. However, if consensus against the motion in question. If a vote is conducted outside of a TOB meeting, the vote will be organised by the Executive Director and must have a clearly established deadline at which point the votes will be tallied and - announced by the Executive Director. + announced by the Executive Director. If any TOB seats have become vacant (as + outlined in Section 6 (k) of this Charter), they are not counted for the + purposes of the qualified super-majority. -p. Any issues that cannot be resolved by the TOB shall be referred to the Linux +q. Any issues that cannot be resolved by the TOB shall be referred to the Linux Foundation Executive Director for mediation, and, if necessary, for resolution by The Linux Foundation Board of Directors. -q. If the Maintainership Coalition feels that the TOB does not represent their +r. If the Maintainership Coalition feels that the TOB does not represent their interests, they may raise a No-Confidence Motion by a qualified majority vote. Votes for No-Confidence Motions must be announced publicly and will be administered by the Executive Director using the procedure in Section 6 (j) @@ -473,7 +487,7 @@ q. If the Maintainership Coalition feels that the TOB does not represent their immediately dissolved and an election is held to replace all of the TOB seats. -r. The procedure for an election under Section 6 (q) of this Charter is +s. The procedure for an election under Section 6 (q) of this Charter is identical to that of Section 6 (g) of this Charter, except that the four (4) member group of the TOB will only hold their seat for one (1) year in order to maintain the staggered terms outlined in Section 6 (f) of this Charter. @@ -483,7 +497,7 @@ r. The procedure for an election under Section 6 (q) of this Charter is a fair coin toss) shall be used to select which member-elect will be part of the four (4) member group. -s. In order to avoid abuse of No-Confidence Motions, they cannot be announced +t. In order to avoid abuse of No-Confidence Motions, they cannot be announced within two (2) weeks before or after a TOB election nor within ninety (90) days of a previous No-Confidence Motion (even if the previous motion was not successfully passed). @@ -628,7 +642,7 @@ g. operate under such rules and procedures as may from time to time be approved ## 12. Amendments and Notice a. This Charter may be amended by a TOB decision using the process outlined in - Section 6 (n) of this Charter, subject to veto by The Linux Foundation Board + Section 6 (o) of this Charter, 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. From 1d4be4bc5d1ddc21012e4503a03b8f9efcb238f6 Mon Sep 17 00:00:00 2001 From: Aleksa Sarai Date: Thu, 4 Feb 2021 12:18:44 +1100 Subject: [PATCH 9/9] CHARTER: s6(g)(5): exclude incapable TOB members-elect If a TOB member-elect becomes incapable of being a TOB member after the election, exclude them from the members-elect set and hold a by-election after the TOB seats expire. This avoids the problem of expelling 3 or more TOB members after an election due to a merger, and simply pretends as though the member had become inelligible before the election began. This is simpler and more fair to both voters and the members-elect than re-running the entire election or simulating a re-run of the election using the Condorcet results. Signed-off-by: Aleksa Sarai --- CHARTER.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/CHARTER.md b/CHARTER.md index 33466e3..f00d03d 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -394,6 +394,12 @@ g. The TOB membership shall be chosen through a nomination and election Projects. The voting period shall last a minimum of two (2) weeks. 4. Upon the conclusion of the election, the members-elect shall become TOB members upon expiry (or vacancy) of the TOB seats. + 5. If, after the election but before the TOB members-elect become TOB + members, it is found that any TOB members-elect are incapable of being + TOB members (as defined in Section 6 (e) of this Charter), the incapable + members-elect will not become TOB members and upon expiry (or vacancy) of + the TOB seats a by-election (as described in Section 6 (k) of this + Charter) shall be held to fill the vacant seats. h. Notwithstanding Section 6 (f) through (g) of this Charter, the initial TOB shall have its four (4) member group only serve a term of one (1) year and