-
Notifications
You must be signed in to change notification settings - Fork 632
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
base: main
Are you sure you want to change the base?
Add CubeFS Graduation Due Diligence Report #1473
Conversation
Signed-off-by: Kevin Wang <[email protected]>
Signed-off-by: Kevin Wang <[email protected]>
82433c1
to
59bd758
Compare
Signed-off-by: Kevin Wang <[email protected]>
59bd758
to
9487b39
Compare
There was a problem hiding this 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.
- 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Co-authored-by: Emily Fox <[email protected]> Signed-off-by: Kevin Wang <[email protected]>
Signed-off-by: Kevin Wang <[email protected]>
5e54ad8
to
f0a40f4
Compare
There was a problem hiding this 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. |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
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