CHARTER: Revise and update to modern conventions.

[cyphar]

This PR updates the OCI Charter to:

• [x] §12 Formalise the changelog process and the concept of a Charter version number.
• [x] §6 Clarify and unify the TOB voting rules so that all TOB decisions require a qualified super-majority. This is in contrast to the README, but it is how we've always run votes. This fixes #80.
• [x] §2 Refine the OCI Projects definition and scope to include Specifications, Reference Implementations, Conformance Suites, and Libraries. This also includes descriptions of the scope of each Category, and is the Charter side of #76.
• [x] §5 Refine the description of the TDC such that the TDC Contributors and TDC Maintainers are two distinctive groups. This also updates the Charter so that technically maintainers of projects other than the runtime-spec are considered TDC Maintainers (this was not the case before). This also better splits up the responsibilities of the TDC, to better establish what the Maintainers alone must do and what the entire TDC of a project must do.
• [x] §6 Clean up TOB section such that it follows modern conventions as well as clarify what the actual election process is (the election process we have followed for the past few elections is not actually established in the current Charter -- the Charter only describes the procedure for electing the initial TOB).
• [ ] §[everything] Clarify ambiguity around "Executive Director" to fix #85.
• [x] §6 Establish procedure around how to deal with TOB members becoming inelligible. Currently there is no process to deal with this (other than presumably making their seat vacant, but if 3 seats become vacant the TOB cannot pass any motions -- and technically if three TOB members become employed by the same employer they all arguably should be evicted to avoid prejudice against a single TOB member). This is needed to fix #84 and avoid the possibility of a "lame duck" TOB.

The following updates are also included, but they are likely more contentious and are not purely reflective of modern conventions (instead they are things I think we need to include in the Charter, but will likely require more active discussion). I'd be happy to split these out and move them to a separate PR, though that will mean we'll need multiple legal reviews by the Linux Foundation to complete this list.

• [x] §2 Explicitly mandate that OCI Reference Implementations must not implement features (except on an experimental basis) which overlap with the scope of the OCI Specification they implement. This is an attempt to avoid the "runc problem" when looking at #67 and #68. This does add an additional requirement that OCI Projects now have to have a clearly defined scope which will be maintained by the TOB (in the past this was entirely up to the TDC, but because this now affects multiple projects it requires TOB intervention).
• [x] §6 Add the concept of "No-Confidence Motions" by the Maintainership Coalition. This is would fix #82 but I'm not sure if that's a popular concept to include. I think we should have such a procedure, but I can understand the arguments against it.

Note that since this is a very substantial text change to the Charter, it will have to be reviewed by Linux Foundation lawyers (and I am willing to write up an explanation of the intent behind the changes so they can more effectively correct my draft). I've tried to avoid touching any sections that are "legally radioactive" (such as the IP Policy, Trademark Policy, Budget, Linux Foundation Rules, or Anti-Trust rules) since most of the issues are related to the day-to-day running of the OCI Projects, TDC, and TOB.

Charter Rework Explanatory Memorandum

Charter Rework Explanatory Memorandum

The purpose of the proposed changes is two-fold:

1. To modernise the OCI Charter so that it more accurately describes the scope and day-to-day operations of the OCI (which includes many projects and work that the original Charter did not explicitly authorise the OCI to undertake).

2. To defining several common-sense mechanisms which were left undefined in the original version of the Charter. Some of these mechanisms were already in use by the OCI, but lacked a formal description in the Charter.

We believe that these changes are reasonable and while fairly significant are in the best interests of the OCI. In order to avoid causing legal strife, none of the particularly "legally radioactive" parts of the Charter are modified by this proposal -- almost all of the changes involve the TOB and TDC having their roles and scope of work be better defined, as well as better-describing the mechanisms by which the TDC and TOB operate.

Detailed Proposals

The following specific changes to the Charter are being proposed:

1. Formalise the charter version and changelog scheme.

2. Clarify and unify the TOB voting rules to match the manner in which all TOB votes (for all matters) have been conducted.

3. Expand on the definitions of OCI Projects, and permit the OCI to legitimately house projects other than runc and the runtime-spec. This also adds explicit restrictions for OCI Reference Implementations (with the exception of runc) to avoid the runc issue where the reference implementation becomes a de-facto specification.

4. Clarify the definition of the TDC, and update the description of TDC Maintainers (as include the concept of the Maintainership Coalition) to more accurately describe maintainership patterns of OCI projects.

5. Clarify the definition of the TOB, as well as enshrine the complete election process in the Charter.

6. Give the TDC Maintainership Coalition the power to submit a No-Confidence Motion to the TOB and force a re-election of the entire TOB.

7. Define a mechanism for dealing with a member becoming incapable of holding their seat during their tenure, by providing for automatic seat vacancies and by-elections. In addition, define a mechanism for dealing with a member-elect becoming incapable of holding their seat before they are seated in the TOB.

1. Charter Version and Changelog

This change is fairly self-explanatory -- we have maintained a changelog and Charter versions, but neither is described as a concept by the Charter. Defining this concept in the Charter will ensure future changes are included in the top-level changelog and ensures consistency in versioning.

2. Unify TOB Voting Rules

Currently the Charter has very inconsistent descriptions of what thresholds are required for the TOB to pass a motion. The general rule is supposed to be two-thirds of votes cast, but every other mention of voting on motions describe a qualified super-majority (two-thirds of all seats). These two methods for counting votes are in contradiction with one another, and we have always required a qualified super-majority for votes.

In addiiton, the original Charter doesn't really allow for GitHub-style voting (as we have conducted several times) so the Charter is also updated to broadly allow the Executive Directory to organise votes outside of TOB meetings as long as they have a well-defined deadline and they announce the results after they are tallied.

3. OCI Projects Expansion

The current Charter does not really give the OCI scope to include projects outside of runc and runtime-spec. The OCI Mission change in Charter v1.2 was a short-term change to allow us to move forward on voting on reference implementations, but this is not an ideal solution.

So, we add a definition for "OCI Projects" which includes three major categories (as agreed upon in previous TOB meetings):

• Specifications (runtime-spec, image-spec, distribution-spec, artefacts).
• Reference Implementations (runc, umoci).
• Libraries (go-digest, selinux).

These categories are given far more explicit definitions, to better explain what kinds of projects belong in the OCI as well as defining a far more rigid scope for what each type of project may do.

This change also includes explicit restrictions on reference implementations to make sure that we don't repeat the mistakes of runc (where runc behaviour became a de-facto standard, bypassing the runtime-spec standardisation process). runc is given an explicit carve-out for historical reasons, but any other reference implementation does not have such a carve-out.

4. TDC Rework

The TDC was originally only intended to include the runtime-spec (and maybe runc). This means that technically maintainers of projects other than runtime-spec were not permitted to vote in TOB elections, and the TDC rules did not apply to those projects. This was not the practice followed, so this has been updated to include all OCI projects in the TDC umbrella.

In addition, the responsibilities of the maintainers of OCI projects were merged with the responsibilities of the TDC of each project. This made it unclear what the maintainers were actually responsible for, so the roles have been explicitly split.

In addition, the idea of a "TDC Maintainership Coalition" has been added to describe the grouping of all maintainers from all OCI projects. This is distinct from the set of maintainers for a single project, and is a necessary distinction to allow for TOB action on a single project or on a collection of projects, as well as better defining the TOB election procedure.

5. TOB Rework

Several key procedures were left undefined in the Charter, most notably the TOB election procedure. To correct this, we simply define the current TOB election procedure with the Executive Director managing the process and using Condorcet-IRV.

6. No-Confidence Motions

While the TOB is elected by the Maintainership Coalition, there is no procedure for the TDC to replace a TOB which they feel is not representing their views. While thankfully this problem has never come up in practice, it seems prudent to have a mechanism for the Maintainership Coalition to expel the TOB and force a new election. Without this mechanism, the TDC would have to appeal to the Linux Board of Directors or Executive Director.

7. Member Ineligibility

While the current Charter describes conditions under which a TOB member is ineligible for their position, it has no mechanism to deal with a TOB member becoming ineligible during their tenure. It's also difficult to tell how such a scenario will be resolved -- if the TOB votes on it, then that member will be able to vote on how their own ineligibility will be handled.

So we add a by-election system (managed by the Executive Director as with all other elections), and members are automatically expelled if they become ineligible. In addition, if a member-elect becomes ineligible before they take their seat, they are removed from the member-elect list and their would-be seat becomes vacant and will be filled after the new TOB is seated.

And finally, the qualified super-majority required for motions to pass does not count vacant seats, to avoid deadlocks and "lame duck" TOBs.

Signed-off-by: Aleksa Sarai [email protected]

[cyphar]

I think the only thing remaining is the Executive Director stuff (#85) but I would like to know what @caniszczyk wants to be done on that front. And we should probably have a call to discuss these charter changes -- I'll write up a small explanatory memorandum for each of the changes.

[caniszczyk]

@cyphar let's sync up on these changes in the coming weeks after we get a TOB chair elected

we can do a governance cleanup after that

[cyphar]

Charter Rework Explanatory Memorandum

Charter Rework Explanatory Memorandum

The purpose of the proposed changes is two-fold:

1. To modernise the OCI Charter so that it more accurately describes the scope and day-to-day operations of the OCI (which includes many projects and work that the original Charter did not explicitly authorise the OCI to undertake).

2. To defining several common-sense mechanisms which were left undefined in the original version of the Charter. Some of these mechanisms were already in use by the OCI, but lacked a formal description in the Charter.

We believe that these changes are reasonable and while fairly significant are in the best interests of the OCI. In order to avoid causing legal strife, none of the particularly "legally radioactive" parts of the Charter are modified by this proposal -- almost all of the changes involve the TOB and TDC having their roles and scope of work be better defined, as well as better-describing the mechanisms by which the TDC and TOB operate.

Detailed Proposals

The following specific changes to the Charter are being proposed:

1. Formalise the charter version and changelog scheme.

2. Clarify and unify the TOB voting rules to match the manner in which all TOB votes (for all matters) have been conducted.

3. Expand on the definitions of OCI Projects, and permit the OCI to legitimately house projects other than runc and the runtime-spec. This also adds explicit restrictions for OCI Reference Implementations (with the exception of runc) to avoid the runc issue where the reference implementation becomes a de-facto specification.

4. Clarify the definition of the TDC, and update the description of TDC Maintainers (as include the concept of the Maintainership Coalition) to more accurately describe maintainership patterns of OCI projects.

5. Clarify the definition of the TOB, as well as enshrine the complete election process in the Charter.

6. Give the TDC Maintainership Coalition the power to submit a No-Confidence Motion to the TOB and force a re-election of the entire TOB.

7. Define a mechanism for dealing with a member becoming incapable of holding their seat during their tenure, by providing for automatic seat vacancies and by-elections. In addition, define a mechanism for dealing with a member-elect becoming incapable of holding their seat before they are seated in the TOB.

1. Charter Version and Changelog

This change is fairly self-explanatory -- we have maintained a changelog and Charter versions, but neither is described as a concept by the Charter. Defining this concept in the Charter will ensure future changes are included in the top-level changelog and ensures consistency in versioning.

2. Unify TOB Voting Rules

Currently the Charter has very inconsistent descriptions of what thresholds are required for the TOB to pass a motion. The general rule is supposed to be two-thirds of votes cast, but every other mention of voting on motions describe a qualified super-majority (two-thirds of all seats). These two methods for counting votes are in contradiction with one another, and we have always required a qualified super-majority for votes.

In addiiton, the original Charter doesn't really allow for GitHub-style voting (as we have conducted several times) so the Charter is also updated to broadly allow the Executive Directory to organise votes outside of TOB meetings as long as they have a well-defined deadline and they announce the results after they are tallied.

3. OCI Projects Expansion

The current Charter does not really give the OCI scope to include projects outside of runc and runtime-spec. The OCI Mission change in Charter v1.2 was a short-term change to allow us to move forward on voting on reference implementations, but this is not an ideal solution.

So, we add a definition for "OCI Projects" which includes three major categories (as agreed upon in previous TOB meetings):

• Specifications (runtime-spec, image-spec, distribution-spec, artefacts).
• Reference Implementations (runc, umoci).
• Libraries (go-digest, selinux).

These categories are given far more explicit definitions, to better explain what kinds of projects belong in the OCI as well as defining a far more rigid scope for what each type of project may do.

This change also includes explicit restrictions on reference implementations to make sure that we don't repeat the mistakes of runc (where runc behaviour became a de-facto standard, bypassing the runtime-spec standardisation process). runc is given an explicit carve-out for historical reasons, but any other reference implementation does not have such a carve-out.

4. TDC Rework

The TDC was originally only intended to include the runtime-spec (and maybe runc). This means that technically maintainers of projects other than runtime-spec were not permitted to vote in TOB elections, and the TDC rules did not apply to those projects. This was not the practice followed, so this has been updated to include all OCI projects in the TDC umbrella.

In addition, the responsibilities of the maintainers of OCI projects were merged with the responsibilities of the TDC of each project. This made it unclear what the maintainers were actually responsible for, so the roles have been explicitly split.

In addition, the idea of a "TDC Maintainership Coalition" has been added to describe the grouping of all maintainers from all OCI projects. This is distinct from the set of maintainers for a single project, and is a necessary distinction to allow for TOB action on a single project or on a collection of projects, as well as better defining the TOB election procedure.

5. TOB Rework

Several key procedures were left undefined in the Charter, most notably the TOB election procedure. To correct this, we simply define the current TOB election procedure with the Executive Director managing the process and using Condorcet-IRV.

6. No-Confidence Motions

While the TOB is elected by the Maintainership Coalition, there is no procedure for the TDC to replace a TOB which they feel is not representing their views. While thankfully this problem has never come up in practice, it seems prudent to have a mechanism for the Maintainership Coalition to expel the TOB and force a new election. Without this mechanism, the TDC would have to appeal to the Linux Board of Directors or Executive Director.

7. Member Ineligibility

While the current Charter describes conditions under which a TOB member is ineligible for their position, it has no mechanism to deal with a TOB member becoming ineligible during their tenure. It's also difficult to tell how such a scenario will be resolved -- if the TOB votes on it, then that member will be able to vote on how their own ineligibility will be handled.

So we add a by-election system (managed by the Executive Director as with all other elections), and members are automatically expelled if they become ineligible. In addition, if a member-elect becomes ineligible before they take their seat, they are removed from the member-elect list and their would-be seat becomes vacant and will be filled after the new TOB is seated.

And finally, the qualified super-majority required for motions to pass does not count vacant seats, to avoid deadlocks and "lame duck" TOBs.

[dmcgowan]

Is it possible to break this up into separate PRs. Some of these are straightforward clarifications, some are additions which have already reached a rough consensus, and some likely need further discussion. I think the order @cyphar outlined makes sense to move forward with.

[cyphar]

I can split it up into multiple PRs, though it's not clear to me whether separate PRs would constitute separate changes and thus separate versions of the Charter? Given that all previous charter changes were a per-PR thing, I'm not sure if there is a "draft" concept of the Charter?

[dmcgowan]

The draft and version concepts are being introduced here. I think it makes sense to just define versioning in the first PR, it shouldn't matter how much the version increments since each would resemble a different change.

[cyphar]

Yup, I'll do it that way then. I'll send the separate PRs next week after Easter.

[jdolitsky]

@cyphar - can you rebase/fix conflicts?