Refactor governance. #225
Refactor governance. #225
Conversation
|
/assign @qiujian16 |
Signed-off-by: xuezhaojun <[email protected]>
xuezhaojun
force-pushed
the
refactor-goverance
branch
from
5568bbc to
17c451e
Compare
xuezhaojun
changed the title
|
Hi @lbocinco, I’ve updated the PR. Could you review it again when you have time to confirm if it’s ready for a community vote to merge? Thanks! |
| - Community feedback is considered valuable input but is non-binding | ||
| - Major decisions should be communicated to the community for comment before implementation | ||
|
|
||
| ### Adding to Core Project |
There was a problem hiding this comment.
| ### Adding to Core Project | |
| ### Adding Core Project components |
There was a problem hiding this comment.
The preposition "to" clearly indicates the destination of the addition, following standard English grammar patterns. It precisely means "adding [components] to the Core Project" rather than the ambiguous "adding Core Project components." This structure maintains consistency with common technical documentation conventions like "Deploying to..." or "Migrating to...".
| Before submitting an application to the Steering Committee, the applying component must hold an internal consensus vote of all major contributors to join Open Cluster Management as part of the Core Project. The Steering Committee will then review the application, and decide whether or not to accept it. If accepted, the Committee will assign one person to assist the component in their integration and ensure compliance with core governance requirements. | ||
| Before submitting an application to the Core Project Maintainer Council, the applying component must hold an internal consensus vote of all major contributors to join Open Cluster Management as part of the Core Project. The Maintainer Council will then review the application through discussion and consensus, and decide whether or not to accept it. If accepted, the Council will assign one or more maintainers to assist the component in their integration and ensure compliance with core governance requirements. | ||
|
|
||
| ### Removing from Core Project |
There was a problem hiding this comment.
| ### Removing from Core Project | |
| ### Removing Core Project components |
There was a problem hiding this comment.
The preposition "from" provides clear syntax that explicitly indicates the source of removal, following standard English grammar. It precisely means "removing [components] from the Core Project" rather than the ambiguous "removing Core Project components." This structure aligns with common technical documentation patterns like "Migrating from..." or "Importing from...".
There was a problem hiding this comment.
Not my hill to die on, but the subject of the addition/removal is unclear in both section titles.
How about:
- Adding components to the Core Project
- Removing components from the Core Project
?
| Promising but incomplete projects may be accepted as Experimental Subprojects. Such projects will be marked as Experimental on the website and in code repositories to inform users. Experimental projects are considered part of the OCM ecosystem with limited governance expectations. The Steering Committee will review Experimental projects at least twice per year to determine if they have matured to full status. | ||
|
|
||
| ## Removing Projects | ||
| Promising but incomplete projects may be accepted as Experimental Subprojects. Such projects will be marked as Experimental on the website and in code repositories to inform users. Experimental projects are considered part of the OCM ecosystem with limited governance expectations. The Core Project Maintainer Council will review Experimental projects at least twice per year to determine if they have matured to full status. |
There was a problem hiding this comment.
Should we link to https://github.com/open-cluster-management-io/lab here?
There was a problem hiding this comment.
Good question! I don't think we need to link the lab repo because when a project in the lab matures, we'll consider spinning it out independently. The lab serves as a transitional stage for subprojects, not a permanent location.
What do you think? @qiujian16 @mikeshng
There was a problem hiding this comment.
seems to me when we talk about Experimental Subprojects, might be good to have a link on where such subproject will be located.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mikeshng, xuezhaojun The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/hold |
openshift-merge-bot
bot
merged commit 99412d6
into
open-cluster-management-io:main
This reverts commit 99412d6.
|
The previous PR was merged accidentally. This new PR will be used to track progress: #228 |
5 participants
Changes Made
This PR refactors the governance document structure to improve clarity and organization:
1. Renamed Section
2. Reorganized Project Management Sections
3. Separated Core vs Subproject Processes
4. Simplified Governance Structure
5. Updated Table of Contents
Benefits
This change makes the governance document more intuitive to navigate, eliminates governance complexity, and better reflects the unified leadership model where Core Project Maintainers serve as both technical and governance leaders.
Vote Tracker