[Enhancement]: cncf graduation checklist

[leonrayang]

Contact Details

No response

Is there an existing issue for this?

• I have searched all the existing issues

What would you like to be added?

Project Repo(s): https://github.com/cubefs/cubefs
Project Site: https://cubefs.io
Communication: cubefs.slack.com

Project points of contacts: leon chang, [email protected]

Graduation Criteria Summary for CubeFS

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:
ADOPTERS: link to md#section

Criteria

Application Process Principles

Required

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

Record of CubeFS presentation at the Storage TAG on April 24, 2024. link to video

• All project metadata and resources are [vendor-neutral].

• In CubeFS governance.md, we require vendur-neutrality: link to md#section

• Maintainers of CubeFS coming from JD, OPPO, BEIKE etc.: link to md#section

• Steering committee member: link to md#section

• Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.

  • Met during Project's application on DD-MMM-YYYY.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies 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.

CubeFS introduction documentation: link
CubeFS installation documentation: link
CubeFS end user documentation: link

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

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

• Update the Governance Document by most of maintainers: link to pr
• Update the Governance Document to eliminate the role of the leader:link to pr
• Update maintainer list according to activity and add steering commitee member: link to pr

Required

• Clear and discoverable project governance documentation.

CubeFS governance documentation: link to md#section

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

• CubeFS Meeting-Schedule: link

• 2024-Recruiting developers: link to issue

• The establishment of the Steering Committee and clarification of its members in CubeFS: link to issue

• Update the document of the roadmap to improve readability and include features that are in preparation but not yet scheduled: link to pr

• Governance clearly documents of project direction.

• Project Direction: link to md#section

• What can you build with CubeFS: link to md#section

• CubeFS roadmap 2024: link to md#section

• Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

• Decision making process on leadership roles: link to md#section

• Contribution acceptance: link to md#section

• Requests to the CNCF

  • CubeFS and cncf: link to md#section
  • Liaison officer for cncf: link to md#section

• Changes to governance or project goals

  • Changes to governance or project goals: link to md#section
  • Steering Committee Member is responsible for formulation roadmap: link to md#section

• Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

Product Security Committee Membership: Rules for assignment, onboarding, and removal.link to md#section

• Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

Details information about current maintainers: link to md#section

• A number of active maintainers which is appropriate to the size and scope of the project.

The maintainers are assigned to their respective modules, and the majority of maintainers have made a significant number of contributions in the past year.
Details information about current maintainers: link to md#section

• Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).

• How to become a maintainer: link to md#section

• Document changes in maintainership,onboarding, offboarding: link to md#section

• Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

Currently, the maintainers of CubeFS are generally balanced between major vendors and active contributors.
Some personnel changes have been made based on activity levels, and new key contributors need to be added to the maintainer list.

• The latest personnel changes are based on the new governance document and voting principles.link to pr

• Historical changes: New maintainers are being added because individuals have been the main contributors to the project.link to pr

• Historical changes: The maintainer update is due to insufficient activity levels from many individuals.link to pr

• Rules: How to become a maintainer.link to md#section

• Project maintainers from at least 2 organizations that demonstrates survivability.

Maintainers from JD, OPPO, BIGO, BEIKE, etc.link to md#section

• Code and Doc ownership in Github and elsewhere matches documented governance roles.

• Maintainers have expertise in the domain fields of the project and are listed in the maintainer documentation.link to md#section

• The top 6 contributors with the highest number of contributions are all maintainers.link

• Document agreement that project will adopt CNCF Code of Conduct.

Code of conduct of CubeFS: link to md#section

• CNCF Code of Conduct is cross-linked from other governance documents.

CubeFS Governance documents are interconnected with the CNCF Code of Conduct.link to md#section

• All subprojects, if any, are listed.

No subprojects

• If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

No subprojects

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Contributor ladder with multiple roles for contributors.
  Cubefs have multiple roles for contributors
• Commiter: link to md#section
• Maintainer: link to md#section
• Steering committee member: link to md#section

Required

• Clearly defined and discoverable process to submit issues or changes.

CubeFS process to submit issues or changes: link to md#section

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

CubeFS communications channel: link

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

The communication channels for all CubeFS projects are shared: link

• Up-to-date public meeting schedulers and/or integration with CNCF calendar.

CubeFS meeting schedulers already added to CNCF calendar: link

• Documentation of how to contribute, with increasing detail as the project matures.

Documentation on the workflow of how to contribute: link to md#section

• Demonstrate contributor activity and recruitment.

Documentation of Contributor Recruitment: link to md#section

Engineering Principles

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

File storage and object storage are key in the storage domain. CubeFS is a file storage system that provides cloud-native file system capabilities and is compatible with object storage. Moreover, it offers a multitude of competitive features and capabilities.
The project’s differentiation is the main feature of CubeFS: link to md#section

• Document what the project does, and why it does it - including viable cloud native use cases.

CubeFS Introduction: link
Use Case: How CubeFS Accelerates AI training in Hybrid Cloud platform: link
Use Case: Co-creating the Future with CubeFS: BIGO's Practice and Reflection: link

• Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

CubeFS RoadMap: link to md#section

• Roadmap change process is documented.

In general, a roadmap is created by collecting input from maintainers, committers, and community users.
It involves selecting necessary items based on the dimensions of importance and urgency.
Additionally, the roadmap takes into account the current available resources and long-term planning considerations for the project.
CubeFS RoadMap Updated need agreement from Steering commitee: [link to pr]](#3358)

• Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.

• CubeFS Introduction: link

• Use Case: How CubeFS Accelerates AI training in Hybrid Cloud platform.link

• Use Case: Co-creating the Future with CubeFS: BIGO's Practice and Reflection.link

• Integration with Kubernetes: link

• K8s deployment: link

• Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:

  • Release expectations (scheduled or based on feature implementation)
    Releases: link to md#section
  • Tagging as stable, unstable, and security related releases
    Release schedule: link to md#section
  • Information on branch and tag strategies
    Types of branch: link to md#section
  • Branch and platform support and length of support
    Versioning support by CubeFS: link to md#section
  • Artifacts included in the release.
    Artifacts in the release: link to md#section
  • Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out.

• History of regular, quality releases.

All components of CubeFS have been adopted by multiple vendors in the community and have undergone validation through online operations.
Official Releases: link

Security

Note: this section may be augemented by a joint-assessment performed by TAG Security.

Suggested

• Achieving OpenSSF Best Practices silver or gold badge.

CubeFS achieved OpenSSF Best Practices gold badge： link

Required

• Clearly defined and discoverable process to report security issues.

CubeFS security documentation has the details. link

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

1）Maintainer account security, two-factor authentication, and GitHub login requiring Authenticator two-step verification.
2）CI integration includes ci-test-unit,ci-test-s3 and ci-sast link
3）Security scanning, static and dynamic scanning

• gofumpt

• golint:In file docker-compose.yml:469 link

• gosec:In file docker-compose.yuml:479 link

• [fuzzers:Fuzz testing]cubefs: add base fuzzers cncf/cncf-fuzzing#387

• Document assignment of security response roles and how reports are handled.

Please reference: link to md#section

• Document Security Self-Assessment.

CubeFS Best Security practice: link

• Third Party Security Review.

  • Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs.

CubeFS have passed the Third Party Security Review: link
Some advisories already be fixed link

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

CubeFS achieved OpenSSF Best Practices gold badge: link

Ecosystem

Suggested

N/A

Required

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

The Documentation of adopters: link

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

Adopters: link to md#section

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.

• JD.com/e-commerce

• OPPO/electronic product supplier

• NetEase/game publisher|portal website

• [] TOC verification of adopters.

Refer to the Adoption portion of this document.

• Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

The Documentation of integrations: link to md#section

Adoption

Adopter 1 - JD.com/e-commerce

Adopter 2 - OPPO/electronic product supplier

Adopter 3 - NetEase/game publisher|portal website

Why is this needed?

No response

Anything else?

No response

[leonrayang]

record governance requirement