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

Add CubeFS Graduation Due Diligence Report #1473

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

kevin-wangzefeng
Copy link
Member

This PR contains the due diligence for CubeFS to move to graduated status.

Project application issue: #1140

Overall, CubeFS meets all the necessary criteria for graduation. The project has demonstrated strong community engagement, active development, and a solid foundation of users and adopters. The project's maintainers have been responsive and collaborative throughout the review process.

Note: this PR is under TOC internal review

@kevin-wangzefeng kevin-wangzefeng changed the title add CubeFS Graduation DD report Add CubeFS Graduation Due Diligence Report Oct 30, 2024
Copy link
Contributor

@TheFoxAtWork TheFoxAtWork left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - 1 spelling correction, and the other is just a suggestion.

projects/chubaofs/cubefs-graduation-dd.md Outdated Show resolved Hide resolved
- TOC Reviewer recommends finalizing the ongoing Governance Review by the TAG Contributor Strategy to achieve a more comprehensive community governance.
- TOC Reviewer recommends to extend its current management rules to cover all repos under the GitHub organization, including non-subproject repos, and archive any repos that are no longer being maintained.
- Make full use of `cubefs-community` repo, as the canonical location for community governance-related documents.
- To better support project adopters, TOC Reviewer suggests keeping deep engagement with them and improving the project's extensibility and code history management. This will facilitate easier tracking of community updates.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be beneficial to further suggest an Adopters WG of the project that allows its adopters to collaborate on shared features and functionality to continue improving and enhancing the project. This would create a dedicated space for deep engagement as you suggested.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I revised this recommendation accordingly.

Copy link
Contributor

@angellk angellk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great @kevin-wangzefeng!

Left a comment re: the roadmap change process that needs clarifying as well as a comment on the release tagging that could be incorporated as a suggestion.

- Removed the Project Lead role, previously held by one individual and considered conflicting with community neutrality. And instead, established a Technical Steering Committee (TSC) with a defined number of seats and neutrality requirements.
- Updated the governance documents to clarify the management rules for subprojects.
- Added a [RELEASE.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/RELEASE.md) file, including updating the release process to reflect the latest engineering principles criteria.
- Updated the governance documents to include roadmap changing process.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kevin-wangzefeng For the roadmap change process - it would be good to cross reference the roadmap governance and change process on the ROADMAP.md so that it's easier to find for potential contributors.

Also, this statement in the Roadmap change process could imply that the roadmap is not determined in an open, community fashion but by a select few behind 'closed doors'. Considering the TSC is newly formed for the application for graduation - and it sounds like the roadmap was previously determined by a single project lead - could you please clarify?

TSC will collect all proposals from maintainers through internal meetings or the [email protected] email group.

- [x] **Tagging as stable, unstable, and security related releases**

CubeFS uses beta to mark their unstable releases. Ref: [RELEASE.md#types-of-releases](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/RELEASE.md#types-of-releases).
Security release process is documented at: [security-release-process.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/security/security-release-process.md)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kevin-wangzefeng from the fix development process documentation it looks like tagging isn't used for bug fixes or security fixes. Recommend the project use tagging so it's easier for end users to identify which releases are most important to upgrade to - especially for enterprise end users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: TOC Review
Development

Successfully merging this pull request may close these issues.

3 participants