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

[Incubation] KServe Incubation Application #1367

Open
39 of 44 tasks
yuzisun opened this issue Jul 5, 2024 · 5 comments
Open
39 of 44 tasks

[Incubation] KServe Incubation Application #1367

yuzisun opened this issue Jul 5, 2024 · 5 comments

Comments

@yuzisun
Copy link

yuzisun commented Jul 5, 2024

KServe 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/kserve
Project Site: https://github.com/kserve/website
Sub-Projects:
https://github.com/kserve/kserve
https://github.com/kserve/modelmesh-serving
https://github.com/kserve/open-inference-protocol
https://github.com/kserve/models-web-app

Communication: https://github.com/kserve/community?tab=readme-ov-file#questions-and-issues

Project points of contacts:
Dan Sun, [email protected]
Yuan Tang, [email protected]
Rachit Chauhan,[email protected]
Christian Kadner, [email protected]

Incubation Criteria Summary for KServe

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:

KServe adopters are tracked here

Application Process Principles

Suggested

N/A

Required

  • Give a presentation and engage with the domain specific TAG(s) to increase awareness

    • This was completed and occurred on 09-FEB-2023, and can be discovered at Feb 9th, 2023.
  • TAG provides insight/recommendation of the project in the context of the landscape

  • All project metadata and resources are vendor-neutral.

    • Yes. KServe is utilizing vendor neutral resources for communication, testing , hosting and governance.
  • Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.

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.

    KServe project Governance has iterated organically as it has gained experienced over the years. Contributor Roles and contributor ladder processes are streamlined over the past years as well as team member onboarding/offboarding process is well defined. The Project has currently 15 active committers and maintainers and it has received contributions from 267 contributors who come from different companies.

  • Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

    Governance is up to date and KServe project has been running bi-weekly community meeting for 5 years now. KServe also regularly promote contributors with the established voting and approval process.

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

    • The project decisions are discussed in open issues and we use gitvote process to make the final decision.
      For example: requests to the CNCF
  • Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

    • KServe uses the GitHub team to manage the roles and remembers, for example kserve-security team responses to the security issues.
  • Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).

    • The role promotion process is documented here
  • 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.

    • 15 active maintainers from Intuit, Bloomberg, IBM, Redhat, Nutanix, SAP, Idea2IT.
  • 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.

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

    KServe contribution guide

  • Project must have, and document, at least one public communications channel for users and/or contributors.

    KServe communication channels

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

    CNCF slack channels: #kserve #kserve-contributors #kserve-oip-collaboration

  • 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

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 augemented by a joint-assessment performed by TAG Security.

Suggested

N/A

Required

  • Clearly defined and discoverable process to report security issues.

    Security issue reporting process

  • 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.
    https://github.com/kserve/kserve/security
    Security scanning is enabled for the project and kserve-security is responsible for fixing the vulnerability issues.

  • Document Security Self-Assessment.

Ecosystem

Suggested

N/A

Required

  • Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

    • KServe adopters are tracked here
  • 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.

    • To be done by TOC

Refer to the Adoption portion of this document.

Additional Information

@terrytangyuan
Copy link
Contributor

terrytangyuan commented Dec 18, 2024

Governance review request for TAG Contributor Strategy: cncf/tag-contributor-strategy#750

@kevin-wangzefeng
Copy link
Member

In preparation for KServe to be picked up by a TOC member, please:

  • complete the application checklist, cleanup TODOs and make sure all the required items answered.
  • review the definition of an adopter
  • verify 5-7 project adopters that can and are willing to be interviewed by the TOC reviewer(s) and
    submit information for each adopter to the Adopter Interview Questionnaire form

@yuzisun
Copy link
Author

yuzisun commented Dec 25, 2024

Thanks @kevin-wangzefeng for the review!!
We have updated the checklist and only left with the TAG presentation which we did back in 2023 but we are requested do a new one which is scheduled on 2025 Feb 20. For the code of conduct we are currently linking to the one from LFAI as the project is currently hosted under there and we are transiting to CNCF. We have also asked adopters to submit the forms. Let us know if anything else is not complete.

@kevin-wangzefeng
Copy link
Member

No worries @yuzisun, I don't see other prerequisites as for now. In parallel, going through domain technical review by TAG (TAG Runtime is the one for Kserve, IIRC.) and governance review by TAG Contributor Strategy would help speed up creating the later on due diligence review report by the TOC sponsor.

@terrytangyuan
Copy link
Contributor

@kevin-wangzefeng Thank you for your heads-up on these requirements! @yuzisun and I will be following up with each of the items mentioned above.

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

4 participants