CHARTER: Revise and update to modern conventions.

[cyphar]

This PR updates the OCI Charter to:

• §12 Formalise the changelog process and the concept of a Charter version number.
• §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 CHARTER: Two-thirds Voting Requirements #80.
• §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 Draft of a "getting started" document for the OCI #76.
• §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.
• §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 CHARTER: Executive Director Ambiguity? #85.
• §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 CHARTER: Procedure in Case of s6(e) Violation #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.

• §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 projects: add umoci proposal #67 and projects: add ORAS proposal #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).
• §6 Add the concept of "No-Confidence Motions" by the Maintainership Coalition. This is would fix CHARTER: No Confidence Motions? #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 cyphar@cyphar.com

[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?