Graduation criteria for Tekton #157
Comments
|
After further consideration, I propose to exclude Catalog from the list of projects that need to comply with the OpenSSF requirements. The catalog is undergoing a significant restructuring. In a nutshell, we will have a new GitHub org (tektoncd-catalog) which will host individual or small group of tasks in dedicated repos, maintained by the Tekton maintainers - see TEP-0115 for details. In the new organisation the Tekton community will take direct ownership of a few repos that host common tasks and work on achieving OpenSSF badge for each of them. Given the transition in progress I propose we do not hold the overall Tekton graduation on this, and instead provide regular project updates to the TOC about this work. |
|
I mapped the list of requirements to a GitHub project: https://github.com/orgs/tektoncd/projects/24/views/2 |
AFAICT the Catalog is the Tekton infrastructure part and not a deliverable installed by users. I beloeve it is safe to exclude, +1 from me |
|
@oleg-nenashev OK to close this one as we agreed on the criteria? |
|
Yes, closing it as discussed |
Dear TOC,
This issue is about clarifying the graduation criteria for the Tekton project.
The Tekton project has matured significantly over the years, and now has a good number of adopters, including high-profile cloud vendors. As discussed in the latest Tekton Governance and Community meeting on Aug 16, 2022, the Tekton project would like agree with the TOC on the exact criteria for project graduation, so that we may focus our efforts to reach that target.
Introduction
The graduated stage documentation leaves some room for project specific criteria to be defined. On top of that, we would like to clarify how some of the criteria apply to the Tekton project: Tekton is composed of a group of projects and some of the most recent projects have a different level of maturity.
Tekton Projects and their relevance for graduation
This table is work in progress, but I include it here to get an idea of the number of projects in Tekton and which we would indicatively consider relevant for graduation.
MaybeYesYesNoStandard acceptance criteria
Have a defined governing body which consists of members from at least 2 different companies.
This is satisfied today, and should not require any further clarification.
Have a documented and publicly accessible description of the project's governance, decision-making, and release processes.
The project governance is documented and publicly accessible.
The decision-making process of the governing board is documented, as well as the community process to decide on new features, known as Tekton Enhancement Proposal or TEP.
The release process documentation needs some refinement.
Have a healthy number of committers from at least two organizations. A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project.
This requirement is clear and met
Explicitly define a project governance and committer process. This is preferably laid out in a GOVERNANCE.md file and references a CONTRIBUTING.md and OWNERS.md file showing the current and emeritus committers.
We have a community wide CONTRIBUTING.md and most projects define their own mode specific version.
We document community processes and contribution ladder.
We have GitHub teams defined as code and OWNERs files for each repo.
Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website).
We have today the Tekton Friends repo, and we are working on a list of adopters and logos for the website.
Note The list of Tekton components used by each adopter may vary, for instance some users may rely on the operator and other may not.
Have achieved and maintained a Core Infrastructure Initiative Best Practices Badge.
Only a subset of Tekton repositories are applicable for the badge.
Other metrics as defined by the applying Project during the application process in cooperation with the TOC.
Examples of project specific metrics from the TOC document are:
Projects that have publicly documented release cycles and plans for Long Term Support ("LTS").
This requirement could be used for Tekton.
Documented release cycles would apply only to a subset of the repos (see table above).
Tekton relies on Kubernetes, and while we have a more frequent release schedule, we depend on Kubernetes decision in terms of LTS. A dedicated working group was formed in the past in the Kubernetes community to discuss LTS, and the final outcome was what is documented today on the top of kubernetes release pages.
Our proposal for Tekton to meet this requirement is to create a similar releases page (one for each relevant project) where we document, for each release:
We already have most of this information publicly available, we will need to decide and include information about "end of life".
Projects that have themselves become platforms for other projects.
This requirement could be used for Tekton.
Jenkins X and Openshift Pipelines are two open source projects that rely on Tekton.
Projects that are able to attract a healthy number of committers on the basis of its production usefulness (not simply 'developer popularity').
This requirement could be used for Tekton.
Several companies that run production services based on Tekton contribute to Tekton upstream.
This could be documented as part of the "adopters" file.
Projects that have several, high-profile or well known end-user implementations.
This requirement could be used for Tekton.
Again we could rely on data from the "adopters" documentation.
Receive a 2/3 supermajority vote from the TOC to move to Graduated stage.
Conclusion
The list of requirements above include all the acceptance criteria as well as all the proposed examples from the TOC graduation process. We would like to learn from the TOC whether this list would be satisfactory, when met, for graduation application for the Tekton project.
The text was updated successfully, but these errors were encountered: