The Confidential Containers is an open source organization and community that adheres to the following principles:
- Open - Confidential Containers is an open source project licensed under the Apache License, Version 2.0. We welcome all contributions
- Respectful and welcoming - See our Code of Conduct
- Transparent - All discussions leading to contributions to the project should be open to all and done in public. There maybe exceptions for preliminary effort (e.g. security related work) but the point of disclosure will still lead to a transparent discussion in public, either through our GitHub repositories or public meetings.
The Confidential Containers organization is composed of multiple projects.
A project is the primary unit of collaboration, therefore each project has its own repository and maintainers team. All projects follow the Code of Conduct.
Everyone is welcome to participate to the Confidential Containers projects, and there are 3 community member roles:
Anyone that contributed to one of the Confidential Containers projects within the last 12 months is a Contributor. Any merged Pull Request is considered a valid contribution.
Contributions are not limited to code alone. Adding or enhancing documentation, tests, tools, project artifacts are all valuable ways to contribute to a Confidential Containers project.
Project contributions will be reviewed by the project maintainers and should pass all applicable tests.
Each project has one or more Maintainer. Project maintainers are first and foremost active Contributors to the project and are responsible for:
- Setting technical directions for the project.
- Facilitating, reviewing and merging contributions. They have write access to the project repository.
- Creating and assigning project issues.
- Enforcing the Code of Conduct.
The list of maintainers for a project is defined by the project CODEOWNERS file placed at the top-level of each project's repository.
Existing maintainers may decide to elevate a Contributor to the Maintainer role based on the contributor established trust and contributions relevance. This decision process is not formally defined and is based on lazy consensus from the existing maintainers.
Any contributor may request for becoming a project maintainer by opening a pull request (PR) against the CODEOWNERS file, and adding all current maintainers as reviewer of the PR.
Maintainers may also pro-actively promote contributors based on their contributions and leadership track record.
The Steering Committee (SC) is the overall Confidential Containers organization governing body.
The SC provides decision-making and strategic oversight for the project. It also defines and enforces the project values and structure.
The scope and responsibilites of the SC is subject to changes, and SC members must adapt it to meet the project needs. Moreover, any technical responsibilities should be delegated to project Maintainers, although the SC can be consulted to help the with making technical decisions.
Based on that, the SC is responsible for:
- Defining the project high-level strategy and roadmap
- Managing and administrating the project, like e.g. preparing the weekly community meeting
- Building and growing a transparent and inclusive Confidential Containers community
- Onboarding and guiding Confidential Containers end-users
Further, as leaders in the community, the SC members will make themselves familiar with the material in the Linux Foundation's Open Source Community Orientation in order to help grow a healthy community.
The current members of the SC are:
- Larry Dewey (@larrydewey) and Ryan Savino (@ryansavino) - AMD
- Jiang Liu (@jiangliu) and Jia Zhang (@jiazhang0) - Alibaba
- James Magowan (@magowan) and Tobin Feldman-Fitzthum (@fitzthum) - IBM
- Peter Zhu (@peterzcst) and Fabiano Fidêncio (@fidencio) - Intel
- Pradipta Banerjee (@bpradipt) and Ariel Adam (@ariel-adam) - Red Hat
- Samuel Ortiz (@sameo) - Rivos
- Zvonko Kaiser (@zvonkok) - NVIDIA
- Vincent Batts (@vbatts) and Dan Mihai (@danmihai1) - Microsoft
- Dan Middleton dcmiddle (he/him)
The convention of the SC is for each organization that is significantly engaged in the project to be represented by one or two members. In addition to a company, an organization could also refer to a non-corporate institution such as school. Selection of the representatives of each organization is not within scope of the SC. The organization itself should select the individual(s) to represent it. Membership changes can fall into one of four categories, as described in the following sections. Each of these processes should be initiated by opening a PR against this document, explaining the motivations of the change and introducing any potential new members. Membership changes can be approved via GitHub and do not require an SC meeting.
The SC can be expanded if a new organization begins making significant contributions to the project. When evaluating requests for expansion, the SC will mainly consider whether the organization in question is making significant contributions to the community. There is no standard definition for significant contributions. The SC should prioritize including relevant stakeholders. The candidates from a organization are understood to represent that organization. The SC may do some basic checks to ensure that candidates are familiar with the project and represent relevant contributors. Expansion should be approved by at least 2/3rds of current SC members.
An SC member can replace themselves with another member from the same organization at will. This is understood to represent a decision by that organization. If the SC contains another member from the same organization, they must approve the replacement. Otherwise, unless there are significant concerns that the change does not represent the organization in question, a vote is not required to approve a replacement.
An individual can remove themselves from the SC at any time. A vote is not required for recusal.
A member can be removed from the SC in the case of gross violation of the Code of Conduct. This should be done only in exceptional circumstances and requires a unanimous vote of remaining SC members.
The SC routinely makes decisions, technical or not, sometimes as a consulting request from project Maintainers or Contributors.
The SC decision-making process is driven by consensus, i.e. the SC will try to reach consensus through discussions and potentially many revisions iterations for any given proposal. The main goal is not to get full agreement from all SC members on a final decision, but rather for most people to only be left with minor objections.
Voting on a decision proposal should be used as a last resort solution, as it can potentially leave several SC members major concerns unaddressed.
Some procedural decisions, such as expansion, can be approved without an SC meeting. This is done via GitHub and requires approval by 2/3rds of SC members. If an SC member feels that further discussion is required a meeting can be called, even if the PR has otherwise been approved. If a meeting is called, the above procedure should be followed.
Community members who are not on the SC are also welcome to submit non-binding feedback regarding any SC process.
The SC will determine an appropriate cadence for meeting and may schedule additional meetings when needed. Meeting time may change depending on the composition of the SC, in order to adapt to SC members local time zones. The meeting is public and recorded, and follows a publicly available agenda.
The SC meeting scope is different from the weekly Confidential Containers community meeting, the latter being mostly focused on specific and technical details of one or more Confidential Containers project.
Each SC member is expected to attend the SC meetings, and the following guidelines are used to determine if quorum is reached:
- Quorum to meet is 1/2 (5/10)
- Quorum to vote is 2/3 (7/10)