You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have reviewed the TOC's moving level readiness triage guide, ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.
ORAS Incubation Application
v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.
Yes. ORAS is utilizing vendor neutral resources for communication, testing , hosting and governance.
Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
Met during Project's application on 2021.07.13
Due Diligence Review.
To be done by TOC
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.
Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.
Suggested
Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.
Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.
ORAS project governance has iterated organically as it has gained experienced over the years. The Project has currently 15 active maintainers and it has received contributions from 267 contributors who come from different companies. The ORAS project holds bi-weekly community meetings (notes) where many topics, including those that are goverance related, are discussed.
Governance clearly documents vendor-neutrality of project direction.
ORAS is utilizing vendor neutral resources for communication, testing , hosting and governance
Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.
The ORAS project uses several open and transparent forums to discuss key project decisions, incluing leadership, contributions and governance
GitHub Issues in related project repositories (primairly within the community repository)
Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).
Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).
ORAS includes a thorough document which describes the Contribtor Ladder that outlines the roles and responsibilities within the project.
Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
ORAS demonstrates the lifecycle of maintainers by routinely promoting new maintainers and moving existing maintainers who no longer wish to retain their maintainer role of emeritus status. This can be seen in practice as described within this article.
OWNERS files are located in each project repository which illustrates the individuals who are currently repsonsible including those that have contributed in the past (Emeritus)
If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.
ORAS project includes several subprojects. OWNERS files are located within each subproject (Example: OWNERS)
GitHub Issues are used for discussions related to subprojects within each subproject repository
Additional discussions are held during bi-weekly community meetings
Required
Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.
ORAS Organization maintainers are documented in the Community repository OWNERS file
A number of active maintainers which is appropriate to the size and scope of the project.
ORAS has 15 active maintainers for all sub-projects.
Code and Doc ownership in Github and elsewhere matches documented governance roles.
ORAS project Contributor Guide includes details related to managing code and project ownership
Document adoption and adherence to the CNCF Code of Conduct or the project's CoC which is based off the CNCF CoC and not in conflict with it.
ORAS follows the CNCF Code of Conduct as detailed here
CNCF Code of Conduct is cross-linked from other governance documents.
List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.
Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This can also be satisfied by completing a General Technical Review.
Document what the project does, and why it does it - including viable cloud native use cases. This can also be satisfied by completing a General Technical Review.
**Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.
Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)
The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.
Review Project Moving Level Evaluation
ORAS Incubation Application
v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.
Project Repo(s): https://github.com/oras-project
Project Site: https://oras.land/
Sub-Projects:
Communication: https://cloud-native.slack.com/archives/CJ1KHJM5Z
Project points of contacts:
Application Level Assertion
Adoption Assertion
ORAS adopters has been listed at https://oras.land/adopters
Application Process Principles
Suggested
N/A
Required
Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.
TAG provides insight/recommendation of the project in the context of the landscape
All project metadata and resources are vendor-neutral.
Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
Met during Project's application on 2021.07.13
Due Diligence Review.
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
Governance and Maintainers
Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.
Suggested
Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.
Clear and discoverable project governance documentation.
Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.
Governance clearly documents vendor-neutrality of project direction.
Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.
Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).
Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).
Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.
Required
Code and Doc ownership in Github and elsewhere matches documented governance roles.
Document adoption and adherence to the CNCF Code of Conduct or the project's CoC which is based off the CNCF CoC and not in conflict with it.
CNCF Code of Conduct is cross-linked from other governance documents.
All subprojects, if any, are listed.
Contributors and Community
Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.
Suggested
Required
Clearly defined and discoverable process to submit issues or changes.
Project must have, and document, at least one public communications channel for users and/or contributors.
List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.
Up-to-date public meeting schedulers and/or integration with CNCF calendar.
Documentation of how to contribute, with increasing detail as the project matures.
Demonstrate contributor activity and recruitment.
Engineering Principles
Suggested
Roadmap change process is documented.
History of regular, quality releases.
Required
Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This can also be satisfied by completing a General Technical Review.
Document what the project does, and why it does it - including viable cloud native use cases. This can also be satisfied by completing a General Technical Review.
Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.
Depending on the complexity of the project, the public roadmap is maintained with either github milesstones or issues:
**Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.
Document the project's release process.
Security
Suggested
N/A
Required
Note: this section may be augmented by a joint-assessment performed by TAG Security and Compliance.
Clearly defined and discoverable process to report security issues.
Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)
Document assignment of security response roles and how reports are handled.
Document Security Self-Assessment.
Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.
Ecosystem
Suggested
N/A
Required
Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)
Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)
The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.
TOC verification of adopters.
Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.
These information has been documented in https://oras.land/adopters.
Additional Information