Checklist for Project Paperwork

This is a condensed, outline-format checklist of the paperwork requirements to reach the various CNCF Graduation Levels. It does not substitute for the full documentation or full requirements, but is a useful quick reference if your project is planning to join the CNCF or graduate levels.

Entering Sandbox

• Requirements:
  • CNCF Code of Conduct
    • Template
    • Decide if COC enforcement will be handled by the project or by the CNCF
      • CNCF is a good option for young/small projects. They will provide contact.
    • If handling it yourself: decide who are the contacts and how to deal with a maintainer being reported, or a contact being reported. Need more than one contact.
      • CNCF can provide training in COC report handing, on request by a project
      • If the COC enforcement body is your maintainers, then you need to have a policy to escalate to CNCF if the report is against a maintainer.
  • Adhere to CNCF IP Policy
  • CONTRIBUTING.md containing basic “how to contribute” ( Harbor example)
    • Template
  • Light project roadmap, at least an easily findable list of TODO items or issues
  • LICENSE
    • Template
      • You need to edit “Copyright [yyyy] [name of copyright owner]”.
      • Replace [yyyy] with the current year.
      • Replace [name of copyright owner] with “The PROJECT Authors”, e.g. “The Kubernetes Authors” or “The Helm Authors”.
    • CNCF strongly recommends Apache 2.0
• Good to Have:
  • Governance.md with details about leadership ( CoreDNS example)
  • OWNERS.md file ( Helm example)
    • Explain what is it, how it’s used, what needs to be in it and if you can reference another source of truth

Entering Incubation

• Additional Requirements:
  • Governance.md showing the leaders and how they are selected
    • Include full election docs if there are elections
    • Governance process must be employer-neutral
  • File showing who the end users are
    • Implies existence of end-user discussion forum
    • Does not have to be 100% public at this stage, the way it does with Graduated
    • If it is public, use an ADOPTERS.md file
  • Clear versioning scheme ( Harbor example)
    • Implies, but does not require, a release process
• Good To Have:
  • Contributor ladder process in CONTRIBUTOR_LADDER.md
  • Project logo/trademark (CNCF helps with this)

Applying for Graduation

• Additional Requirements:
  • “Committers” from at least 2 organizations.
    • This is a complicated requirement.
    • Requires recruitment of new contributors/reviewers from outside original project founders
  • CII Best Practices Badge
    • This requires meeting many criteria for how the project runs repositories. Requirements are extensive and may take some time to meet.
  • 3rd Party Security Audit published ( Envoy example)
    • CNCF arranges the audits
  • Explicitly defined project governance and committer process in a governance.md file with references to OWNERS.md files
    • Includes contributor ladder
    • Implies automation for contributor rights
    • Example: Helm maintainers, OWNERs
  • ADOPTERS.md contains a public list of project adopters ( Jaeger example)
    • This is now public, so you need users who can be referenced

Nice To Have at Any Level

• Security report handling process ( CoreDNS example)
  • Realistically, this will end up being required for CII/Security Audit
• Documented release process ( Envoy example)
• Conformance process/definition/requirement ( Kubernetes example)
  • As in “what is $project and what is it not”