Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Graduation] Knative Graduation Application #1509

Open
51 of 55 tasks
dprotaso opened this issue Dec 13, 2024 · 4 comments
Open
51 of 55 tasks

[Graduation] Knative Graduation Application #1509

dprotaso opened this issue Dec 13, 2024 · 4 comments

Comments

@dprotaso
Copy link

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

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

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.

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

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

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

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

    • 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

  • 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

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.

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

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

Security

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

Suggested

Required

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.

Refer to the Adoption portion of this document.

  • Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

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
Copy link
Author

This issue replaced the PR #1509

@dprotaso
Copy link
Author

dprotaso commented Dec 13, 2024

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
Copy link
Contributor

angellk commented Dec 13, 2024

Please use the form @dprotaso

submit information for each adopter to the Adopter Interview Questionnaire form

@dprotaso
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: New
Development

No branches or pull requests

2 participants