Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

CHARTER: Revise and update to modern conventions. #86

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

cyphar
Copy link
Member

@cyphar cyphar commented Jun 9, 2020

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 [email protected]

This was referenced Jun 10, 2020
@cyphar cyphar marked this pull request as ready for review February 4, 2021 01:31
@cyphar
Copy link
Member Author

cyphar commented Feb 4, 2021

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

@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 cyphar force-pushed the charter-rework branch 2 times, most recently from 568b198 to 1ea76d1 Compare February 4, 2021 13:04
@cyphar
Copy link
Member Author

cyphar commented Feb 4, 2021

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

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

cyphar commented Apr 1, 2021

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

dmcgowan commented Apr 1, 2021

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

cyphar commented Apr 2, 2021

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

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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
@jdolitsky
Copy link
Member

@cyphar - can you rebase/fix conflicts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants