CHARTER: Revise and update to modern conventions. #86
Conversation
|
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. |
cyphar
force-pushed
the
charter-rework
branch
from
7d1fa8d
to
b184e92
Compare
|
@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
force-pushed
the
charter-rework
branch
2 times, most recently
from
568b198
to
1ea76d1
Compare
Charter Rework Explanatory MemorandumCharter Rework Explanatory MemorandumThe purpose of the proposed changes is two-fold:
We believe that these changes are reasonable and while fairly significant are Detailed ProposalsThe following specific changes to the Charter are being proposed:
1. Charter Version and ChangelogThis change is fairly self-explanatory -- we have maintained a changelog and 2. Unify TOB Voting RulesCurrently the Charter has very inconsistent descriptions of what thresholds are In addiiton, the original Charter doesn't really allow for GitHub-style voting 3. OCI Projects ExpansionThe current Charter does not really give the OCI scope to include projects So, we add a definition for "OCI Projects" which includes three major
These categories are given far more explicit definitions, to better explain This change also includes explicit restrictions on reference implementations to 4. TDC ReworkThe TDC was originally only intended to include the runtime-spec (and maybe In addition, the responsibilities of the maintainers of OCI projects were In addition, the idea of a "TDC Maintainership Coalition" has been added to 5. TOB ReworkSeveral key procedures were left undefined in the Charter, most notably the TOB 6. No-Confidence MotionsWhile the TOB is elected by the Maintainership Coalition, there is no procedure 7. Member IneligibilityWhile the current Charter describes conditions under which a TOB member is So we add a by-election system (managed by the Executive Director as with all And finally, the qualified super-majority required for motions to pass does not |
|
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. |
|
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? |
|
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. |
|
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 <cyphar@cyphar.com>
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 <cyphar@cyphar.com>
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 <cyphar@cyphar.com>
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 <cyphar@cyphar.com>
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 <cyphar@cyphar.com>
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 <cyphar@cyphar.com>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
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 <cyphar@cyphar.com>
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 <cyphar@cyphar.com>
|
@cyphar - can you rebase/fix conflicts? |
This PR updates the OCI Charter to:
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.
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:
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).
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:
Formalise the charter version and changelog scheme.
Clarify and unify the TOB voting rules to match the manner in which all TOB
votes (for all matters) have been conducted.
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.
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.
Clarify the definition of the TOB, as well as enshrine the complete
election process in the Charter.
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.
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):
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