We use analytics and cookies to understand site traffic. Information about your use of our site is shared with Google for that purpose. Learn more.
Knative Repository Guidelines
This document outlines a structure for creating and associating code repositories with the Knative project. It also describes how and when repositories are removed.
Core repositories are considered core components of Knative. They are utilities, tools, applications, or libraries that form or support the foundation of the project.
Core repositories are all those located under the github.com/knative organization.
Core Repository Requirements
- Repository must live under github.com/knative/project-name.
- Must adopt the Knative Code of Conduct.
- All code projects must use the Apache License version 2.0.
- Documentation repositories must use Creative Commons License version 4.0.
- All OWNERS must be members of the Knative community.
- Repository creation must be approved by the Technical Oversight Committee.
Requirements for Repository Donation
The Technical Oversight Committee may allow repositories to be donated to the Knative project. In addition to meeting the core repository requirements, donated repositories must:
- Adopt the Google CLA bot.
- All contributors to the donated repository must have signed the Google CLA.
- All code must adopt the standard Knative header, attributing copyright as
"Copyright <year> The Knative Authors"
- Additions of the standard Knative header to code created by the contributors can occur post-transfer, but should ideally occur shortly thereafter.
AUTHORSfile should be created in the repo root, if one does not already exist, that includes the original authors of the code. See knative/serving AUTHORS for reference.
- Note that copyright notices should only be modified or removed by the people or organizations named in the notice.
As important as it is to add new repositories, it is equally important to prune repositories when necessary. See Grounds for removal.
It is important to the success of Knative that all Knative repositories stay active, healthy, and aligned with the scope and mission of project.
Grounds for removal
Core repositories may be removed from the project if they are deemed inactive. Inactive repositories are those that meet any of the following criteria:
- There are no longer any active maintainers for the project, and no replacements can be found.
- All PRs and issues have gone un-addressed for longer than six months.
- There have been no new commits or other changes in more than a year.
- The contents have been folded into another actively maintained project.
Procedure for removal
When a repository has been deemed eligible for removal, we take the following steps:
- A proposal to remove the repository is brought to the attention of the
Technical Oversight Committee through a GitHub issue posted in the
- Feedback is encouraged during a Technical Oversight Committee meeting before any action is taken.
- Once the TOC has approved of the removal, if the repo is not moving to another
actively maintained project:
- The repo description is edited to start with the phrase “[EOL]”
- All open issues and PRs are closed
- All external collaborates are removed
- All webhooks, apps, integrations, or services are removed
- GitHub pages are disabled
- The repo is marked as archived using GitHub’s archive feature
- The removal is announced on the knative-dev mailing list
This procedure maintains the complete record of issues, PRs, and other contributions. It leaves the repository read-only and makes it clear that the repository is retired and no longer maintained.
Additional / Experimental Repositories
We want Knative working groups to be able to own code outside the core
organization, which is kept intentionally small and has a high bar for entry.
knative-sandbox github organization was created for this purpose.
knative-sandbox are intended to give working groups more
latitude to experiment with new ideas and to self-organize and manage
contributions which may be important to the project but which do not need the
level of governance of the core project.
knative-sandbox is not an incubation area for projects entering
the core; in some cases, projects in the sandbox will remain there for the
entire duration. Promotion from the sandbox into core will be handled on a
case-by-case basis by joint decision of the Steering Committee and the Technical
Mechanics of working-group owned repositories in
Note: prior art here from the Kubernetes community.
Working groups should be able to create repositories that meet the following bar:
Vendor independent (no direct links to specific clouds, no required dependencies on vendor-specific tools)
Homed within an existing working group (if you want a new working group too, create the working group first)
Must adopt the Knative CLA
Must adopt the Knative code of conduct
Must adopt the Apache 2.0 license
Must be sponsored by a specific working group, which should be designated in the
README.mdfor the repo. In addition, at least one WG lead must be in the root-level OWNERS file.
Copyright assigned to The Knative Authors
Document clear release and install processes.
Clearly document the stability and API guarantees (both in the top-level
README.mdand by using appropriate API versioning for Kubernetes apigroups).
Kubernetes APIs must be homed in a valid group with a DNS prefix approved by the Steering Committee.
Be under a subdomain managed by the owning Working Group (e.g.
knative.dev). The TOC is considered the authority for assigning subdomains to working groups.
Coordinate with the Working Group in API naming to avoid collisions or confusing naming. This also includes API review by the responsible Working Group to ensure consistency and alignment with duck-type field naming.
Working groups must designate the repositories they own (specifics TBD).
Repositories owned by working groups are encouraged to embrace the project value of pluggability.
The following are not required to create a working-group-owned repository:
- Steering approval (see “the fine print”)
- TOC approval
- Solving an unique problem (exploring different approaches to problems outside the core is actively encouraged!)
The fine print
Steering reserves the right to require that repos be removed or transferred out
knative-sandbox organization (and API groups to be renamed). This is
intended to simplify the process in the common case, while giving Steering the
ability to step in and rectify problems that may arise.
Working groups are responsible for the upkeep of their repositories and are
expected to keep a high quality bar. Inactive repositories should be archived,
deleted, or moved out of the
Contents of this page are adopted from the Kubernetes repository guidelines, which is licensed under Apache License 2.0.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.