-
Notifications
You must be signed in to change notification settings - Fork 94
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
WIP: Incubation Application #1662
Comments
Can't find initial Sandbox PR/application. Leaving reference to Onboarding PR cncf/sandbox#251 that might be potentially useful |
actual issue goes here: https://github.com/cncf/toc/issues/new?template=template-incubation-application.md |
@ytsarev this is 90-95% complete now, and ready for your review. Where you are @ mentioned are the places where your review is most needed 👍 |
Can be extended with @elohmrow email some of the core maintainers?
@abaguas is it good time to add Open Systems to the list?
Do we need to run a fresh demo for TAG or what is the best way to interpret this line?
Looks like something we can demonstrate with devstat metrics, e.g. https://k8gb.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1
We can enable UPD: I adjusted the machine user for 2FA and enabled 2FA requirement for the whole k8gb-io org. Ticking this requirement
We have the golden badge at https://www.bestpractices.dev/en/projects/4866 and it is linked on index page/main readme, so I am ticking this requirement :) |
@ytsarev thank you! I have further updated the WIP application with the info from your comments - 🙇 specifically:
I will reach out today and see what the expectation is around: (EDIT: I have now reached out - awaiting response)
EDIT: I think once we get that answer ☝️, we're ready to create the actual incubating issue 🎉 |
I have an answer wrt
We should reach out to the Network TAG and ask for a formal review, which will also be used later on during the due diligence process by the TOC. EDIT: hold on the following |
closing as complete via cncf/toc#1472 |
k8gb Incubation Application
v1.5
This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.
Project Repo(s): https://github.com/k8gb-io/k8gb
Project Site: https://github.com/k8gb-io/k8gb
Sub-Projects: None
Communication: https://cloud-native.slack.com/archives/C021P656HGB
Project points of contact:
Yury Tsarev (@ytsarev) [email protected]
@donovanmuller
@k0da
@kuritka
@jkremser
@abaguas
Bradley Andersen (@elohmrow) [email protected]
(Post Incubation only) Book a meeting with CNCF staff to understand project benefits and event resources.
Incubation Criteria Summary for k8gb
Adoption Assertion
The project has been adopted by the following organizations in a testing and integration or production capacity:
Application Process Principles
Suggested
N/A
Required
Give a presentation and engage with the domain specific TAG(s) to increase awareness
TAG provides insight/recommendation of the project in the context of the landscape
All project metadata and resources are vendor-neutral.
Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
Due Diligence Review.
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies 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.
Governance and Maintainers
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
Suggested
Clear and discoverable project governance documentation.
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.
Governance clearly documents vendor-neutrality of project direction.
Document how the project makes decisions on leadership, 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).
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.
If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.
Required
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.
Code and Doc ownership in Github and elsewhere matches documented governance roles.
Document agreement that project will adopt CNCF Code of Conduct.
CNCF Code of Conduct is cross-linked from other governance documents.
All subprojects, if any, are listed.
Contributors and Community
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
Suggested
Required
Clearly defined and discoverable process to submit issues or changes.
Project must have, and document, at least one public communications channel for users and/or contributors.
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.
Up-to-date public meeting schedulers and/or integration with CNCF calendar.
Documentation of how to contribute, with increasing detail as the project matures.
Demonstrate contributor activity and recruitment.
Engineering Principles
Suggested
Roadmap change process is documented.
History of regular, quality releases.
Required
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.
Document what the project does, and why it does it - including viable cloud native use cases.
Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.
Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.
Document the project's release process.
Security
Note: this section may be augmented by a joint-assessment performed by TAG Security.
Suggested
N/A
Required
Clearly defined and discoverable process to report security issues.
Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)
Document assignment of security response roles and how reports are handled.
Document Security Self-Assessment.
Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.
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.
Refer to the Adoption portion of this document.
Additional Information
The text was updated successfully, but these errors were encountered: