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
This project is currently Incubating, accepted on 2022-03-02, and applying to Graduate.
Adoption Assertion
Adopters of the Knative project that have chosen to share their adoption story publicly can be found in the ADOPTERS.md file in the community repository.
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.
This was completed and occurred on DD-MMM-YYYY, and can be discovered at $LINK.
TAG provides insight/recommendation of the project in the context of the landscape
Knative operates according to well defined vendor-neutral governance guided by our Steering Committee, and all project communication, messaging, and collaboration is vendor-neutral.
The Knative project has reviewed and understands the expectations as it has continued to move forward through the maturity levels as described in the process README and graduation criteria.
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies 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 TAG Contributor Strategy.
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.
The Knative project has been continuously reshaping governance. All the commits are present in our knative/community repository.
Prior to the CNCF incubation we had distinct Trademark, Steering and Technical Oversight Committees. As of Dec '24 we've consolidated the governance into a single Steering Committee.
Document how the project makes decisions on leadership roles, 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).
We leverage the concept of working groups to allow different project members to contribute in different functional areas of the project. We have documented processes for formation, running and dissolution of these groups.
The leadership of the project are part of nine (9) different companies/organizations. eg. Red Hat, Cisco, IBM, Staklok, Bloomberg, Diagrid, OCAD University, University of Toronto
Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).
When a leads leaves their role they are moved to emeritus status.
Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
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 requirement may also be satisfied by completing a General Technical Review.
A General Technical Review was completed/updated on 2022-01, and can be discovered at Knative to CNCF Due Diligence.
Document what the project does, and why it does it - including viable cloud native use cases. This requirement may also be satisfied by completing a General Technical Review.
Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.
All working groups following the same mechanics for managing roadmaps.
Roadmap can be found on GitHub with shortcuts available in our WORKING-GROUPS.md
Roadmap change process is documented.
In general working group leads are responsible for the roadmap of their respective area.
Users can influence the roadmap by writing a feature track
Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This requirement may also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.
Client/Func will produce binaries to run locally on end-user machines.
Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out.
Skipped as we've have completed a third-party security review. See below
Third Party Security Review.
Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs.
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.
Refer to the Adoption portion of this document.
Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.
Documented on our website under installation sections
We have a list of adopters and @dprotaso has compiled their contact information. A few have decided to remain anonymous until they get approval within their companies to disclose.
The text was updated successfully, but these errors were encountered:
Knative Graduation Application
v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Graduation Level Criteria.
Project Repo(s): github.com/knative, github.com/knative-extensions
Project Site: https://www.knative.dev
Sub-Projects: Serving, Eventing, Functions, Client
Communication: https://cloud-native.slack.com/
#knative
and various channels with#knative-
prefixProject points of contacts: [email protected], Steering Committee Members
Graduation Criteria Summary for Knative
Application Level Assertion
Adoption Assertion
Adopters of the Knative project that have chosen to share their adoption story publicly can be found in the ADOPTERS.md file in the community repository.
Application Process Principles
Suggested
N/A
Required
All project metadata and resources are vendor-neutral.
Knative operates according to well defined vendor-neutral governance guided by our Steering Committee, and all project communication, messaging, and collaboration is vendor-neutral.
Knative's social media principles enforces vendor neutrality in our communication
Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.
Met during project's proposal (Knative graduation proposal #1245) on 2024-01-19 and this continued issue application 2024-12-2024
Knative has demonstrated this understanding through all applications/proposals for each maturity level
The Knative project has reviewed and understands the expectations as it has continued to move forward through the maturity levels as described in the process README and graduation criteria.
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies 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.
Governance and Maintainers
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
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.
Required
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 roles, 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 complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.
A number of active maintainers which is appropriate to the size and scope of the project.
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.
Project maintainers from at least 2 organizations that demonstrates survivability.
Code and Doc ownership in Github and elsewhere matches documented governance roles.
Document adoption of the CNCF Code of Conduct
CNCF Code of Conduct is cross-linked from other governance documents.
All subprojects, if any, are listed.
If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.
Contributors and Community
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
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
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 requirement may 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 requirement may also be satisfied by completing a General Technical Review.
Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.
Roadmap change process is documented.
Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This requirement may also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.
Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:
History of regular, quality releases.
Security
Note: this section may be augmented by a joint-assessment performed by TAG Security.
Suggested
Required
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.)
knative
,knative-extensions
Document assignment of security response roles and how reports are handled.
Document Security Self-Assessment.
Third Party Security Review.
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.
Refer to the Adoption portion of this document.
Adoption
We have a list of adopters and @dprotaso has compiled their contact information. A few have decided to remain anonymous until they get approval within their companies to disclose.
The text was updated successfully, but these errors were encountered: