[Graduation] Knative Graduation Application

[dprotaso]

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- prefix

Project points of contacts: steering@knative.team, Steering Committee Members

• (Post Graduation only) Book a meeting with CNCF staff to understand project benefits and event resources.

Graduation Criteria Summary for Knative

Application Level Assertion

• 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.

  • TAG provides insight/recommendation of the project in the context of the landscape
    • TAG Runtime - Presentation Feb 3rd, 2022 (notes, video)
    • TAG App Delivery - Presentation Nov 8th, 2023 (slides)

• 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

    • Incubation: Adding Knative proposal for incubation #762
    • Graduation: this document

  • 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.

  • Installation Documentation - https://knative.dev/docs/install
  • Contributing/Community Documentation - https://knative.dev/docs/community
  • Knative Incubation Due Diligence Document

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.

  • 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.
      • ref: Combine Steering and TO Committees knative/community#1587

Required

• Clear and discoverable project governance documentation.

  • Governance documentation is present in our knative/community repository.

• Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

  • Steering Committee details are present in the knative/community repo
  • Committee activities are tracked as GitHub Issues
  • Committee meetings are public and notes are taken. See the community calendar for times
  • Elections are documented and tracked

• Governance clearly documents vendor-neutrality of project direction.

  • Vendor neutrality is enforced by limiting company representation in our Steering Committee.

• Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

  • Leadership positions change through an annual election process. It has clear eligibility guidelines, documented voting procedures and composition guidelines.
  • Decisions by leadership requires quorum among members and is documented here.
  • Changes to the charter follow a pull-request process to make changes.

• 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.
  • Within a working group we have documented distinct contributor roles and requirements .

• Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

  • Active Steering Committee Members
  • Active Working Groups and their leads

• A number of active maintainers which is appropriate to the size and scope of the project.

  • There are nine (9) active Steering Committee Members
  • There are fifteen (15) active Working Groups Leads
  • 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).

  • Within a working group we have documented distinct contributor roles and requirements .
  • We leverage Peribolos & Prow OWNER files to assign individuals to working groups.
  • 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.

  • Pull requests are made to the peribolos configuration and markdown files to manage maintainer lifecycle.

• Project maintainers from at least 2 organizations that demonstrates survivability.

  • There are nine (9) different organizations with members in Knative leadership positions. See above.

• Code and Doc ownership in Github and elsewhere matches documented governance roles.

  • Peribolos + Prow OWNER files are kept in-sync with governance roles. See above 'maintainer lifecycle' question

• Document adoption of the CNCF Code of Conduct

  • Documented in our own CODE-OF-CONDUCT.md files

• CNCF Code of Conduct is cross-linked from other governance documents.

  • Documented in our own CODE-OF-CONDUCT.md files

• All subprojects, if any, are listed.

  • Serving
  • Eventing
  • Functions & Client

• If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

  • Sub-project leadership is documented in WORKING-GROUPS.md
  • All subprojects are considered Generally Available according to the project's maturity levels

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Contributor ladder with multiple roles for contributors.
  • Within a working group we have documented distinct contributor roles and requirements

Required

• Clearly defined and discoverable process to submit issues or changes.

  • All Working Groups use GitHub Issues and Pull-Requests

• Project must have, and document, at least one public communications channel for users and/or contributors.

  • https://knative.dev/docs/community/#communication-channels

• 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.

  • CNCF Slack (https://knative.dev/docs/community/#communication-channels)
  • Knative Users Google Group - https://groups.google.com/g/knative-users
  • Knative Dev Google Group - https://groups.google.com/g/knative-dev
  • Knative Google Team Drive for meeting notes and proposals - (https://drive.google.com/drive/folders/0AM-QGZJ-HUA8Uk9PVA)

• Up-to-date public meeting schedulers and/or integration with CNCF calendar.

  • Knative Google Calendar
  • Calendar Import Instructions

• Documentation of how to contribute, with increasing detail as the project matures.

  • Each subproject has their own 'how to contribute'
  • Index of these is on the knative.dev website

• Demonstrate contributor activity and recruitment.

  • Knative within the CNCF in the past year has had 227 authors of commits.
  • See CNCF project velocity report

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.

  • 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.

  • A General Technical Review was completed/updated on 2022-01, and can be discovered at Knative to CNCF Due Diligence - Cloud Native Use Cases.

• 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.

  • A General Technical Review was completed/updated on 2022-01, and can be discovered at Knative to CNCF Due Diligence - Architectural design and feature overview.
  • User facing architecture docs are on the website
    • Serving

• Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:

  • Release expectations (scheduled or based on feature implementation)
    • Release schedule occurs quarterly
  • Tagging as stable, unstable, and security related releases
  • Information on branch and tag strategies
    • knative/release contains information regarding our release process and branching strategies
  • Branch and platform support and length of support
    • Support Window Policy
  • Artifacts included in the release.
    • This depends on the subproject.
    • Serving & Eventing produce Kubernetes YAML
    • 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.

• History of regular, quality releases.

  • Our website blog contains summaries of our releases - https://knative.dev/blog/

Security

Note: this section may be augmented by a joint-assessment performed by TAG Security.

Suggested

• Achieving OpenSSF Best Practices silver or gold badge.
  • https://bestpractices.coreinfrastructure.org/en/projects/5913

Required

• Clearly defined and discoverable process to report security issues.

  • Using GitHub SECURITY.md

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

  • Enabled in both our GitHub orgs knative,knative-extensions

• Document assignment of security response roles and how reports are handled.

  • Vulnerability Disclosure Response Policy
  • Early Disclosure of Security Vulnerabilities

• Document Security Self-Assessment.

  • https://github.com/cncf/tag-security/blob/main/community/assessments/projects/knative/self-assessment.md

• 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.
  • Security Audit
    • Announcement - 2023-12-05 - https://knative.dev/blog/events/security-audit-2023/
    • Report - https://github.com/knative/docs/blob/main/reports/ADA-knative-security-audit-2023.pdf

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

  • Passing criteria - https://www.bestpractices.dev/en/projects/5913

Ecosystem

Suggested

N/A

Required

• Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

  • Available in the knative/community repo

• 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
    • eg. Serving - Networking Layer
    • e.g Eventing - Channel & Broker

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.

[dprotaso]

This issue replaced the PR #1509

[dprotaso]

Also I have a document with adopter contact emails - let me know if you prefer I share that or you want me to submit the email using a form. cheers

x-post in cncf slack - https://cloud-native.slack.com/archives/C0MP69YF4/p1734057464986069

[angellk]

Please use the form @dprotaso

submit information for each adopter to the Adopter Interview Questionnaire form

[dprotaso]

Just finished submitting the adopter list through the form - thanks.

[angellk]

@dprotaso has the project completed the required self-assessment?

[dprotaso]

Which self assessment? If it's the security one a steering member was told it wasn't necessary if we have had a completed 3rd party security audit. Is that not the case?

[angellk]

The required self assessment:

• Document Security Self-Assessment

The joint assessment is optional. I'll reach out separately to understand the conflicting information received by your steering member.

[evankanderson]

The required self assessment:

• Document Security Self-Assessment

The joint assessment is optional. I'll reach out separately to understand the conflicting information received by your steering member.

We have the following document prepared between Justin Cappos' NYU seminar and the Knative-Security working group: https://github.com/cncf/tag-security/blob/main/community/assessments/projects/knative/self-assessment.md

I'll update a few items in the self-assessment, but I'm assuming that is the correct document?