gian/cubefs
1
0
Fork 0
mirror of https://github.com/cubefs/cubefs.git synced 2026-08-02 02:00:56 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

feat(docs): Update Governance related documentation

Browse Source 
1. Clarify the responsibilities of the TSC, maintainers, and committers.
2. Fix the issue in security reporting as incorrect email address for reporting vulnerabilities.
3. Clarify the governace of SIGs
4. Add a link to the governance section in README.md for emphasis.

Signed-off-by: leonrayang <chl696@sina.com>
This commit is contained in:
leonrayang 2024-08-15 19:36:38 +08:00 committed by leonrayang
parent 5ebd3e7e19
commit 2a041e7765
7 changed files with 505 additions and 276 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

292
GOVERNANCE.md
View File

@ -9,77 +9,100 @@ The CubeFS community adheres to the following principles:
- Transparent and accessible: Changes to the CubeFS organization, CubeFS code repositories, and CNCF related activities (e.g. level, involvement, etc) are done in public.
- Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, scope, and design principles.
## Expectations from The Steering Committee
## Expectations from The Technical Steering Committee(TSC)
The CubeFS project has a Steering Committee.
- The term of the Steering Committee position is one year, and individuals can serve multiple terms in this role.
- Steering Committee Member is responsible for the top-level design of projects, formulation of roadmaps, and community management
- The Steering Committee member is the core maintainer.
- The composition of the Steering Committee members consists of core maintainers from independent developers or vendors.
The CubeFS TSC is the governing body for the CubeFS project
- Providing decision-making and oversight related to its bylaws.
- Defines the project's values, structure.
- Responsible for the top-level design of projects, formulation of roadmaps, and community management.
- Approve the creation and dissolution of SIGs
- Establish and maintain the overall technical governance guidelines for the project.
- Make decisions by majority vote if consensus cannot be reached.
## The structure of the Technical Steering Committee
- The TSC from independent developers and vendors.
- To ensure fairness, efforts will be made to maintain a balanced representation among the personnel from different vendors.
- No single vendor can exceed 50% of the total number of personnel.
- The term of the Steering Committee is one year.
- The term of the TSC is two years.
- The TSC consists of 5 individuals.
## Changes in Steering Committee
## The TSC decision-making process
Changes in steering committee members are initiated by opening a github PR.
During the first year of the TSC term, if a TSC meeting lacks a quorum, an email voting procedure will be initiated. If email voting also fails to achieve a quorum within a week, the motion will be considered approved unless there are outstanding objections from TSC members.
Anyone from CubeFS maintainers can vote on the PR with either +1 or -1.
## Becoming a TSC Member
Only the following votes are binding:
1) Any maintainer that has been listed in the top-level [MAINTAINERS](MAINTAINERS.md) file before the PR is opened.
2) Any maintainer from an organization may cast the vote for that organization. However, no organization
should have more binding votes than 1/2 of the total number of maintainers defined in 1).
The term of the TSC position is two years, and individuals can serve multiple terms in this role.
Changes in TSC members are initiated by opening a github PR.
- **Criteria**: Nominees must be a maintainer, should have made significant contributions to the community during the last 2 years.Have sufficient reputation and influence in the community.
- **Nominations**:
- Each individual in a Selecting Group may nominate up to 2 people, at most 1 of whom may be from the same group of Related Companies. Each nominee must agree to participate prior to being added to the nomination list. Self nomination is allowed. Each nominee needs 2 more contributors’ endorsements from different organizations/companies.
- Nominations must be made public and should include the nominee's name, contact information, and a statement of experience.Current TSC shall determine the process and timeline for the nominations, qualification and election of new TSC members.
- **Elections**:
- If the number of Qualified Nominees is equal to or less than the number of TSC seats available to be elected, the Qualified Nominees shall be approved after the nomination period has closed.
- If there are more Qualified Nominees than open TSC seats available for election, then the Selecting Group shall elect the TSC members via a Condorcet vote.
- A Condorcet vote shall be run using the Condorcet-IRV method through the Cornell online service (https://civs.cs.cornell.edu/).
- Only the following votes are binding:
- Any maintainer that has been listed in the top-level [MAINTAINERS](MAINTAINERS.md) file before the PR is opened.
- Any maintainer from an organization may cast the vote for that organization. However, no organization should have more binding votes than 1/2 of the total number of maintainers defined in 1).
The PR should only be opened no earlier than 4 weeks before the end of the term.
The PR should be kept open for no less than 2 weeks. The PR can only be merged after the end of the
last term, with more +1 than -1 in the binding votes.
When there are conflicting PRs about changes in Steering Committee, the PR with the most binding +1 votes is merged.
The TSC will decide on and publish an election process within 3 months of formalizing this organizational structure. This will cover voting eligibility, eligibility for candidacy, the election process and schedule.
The Steering Committee member can volunteer to step down.
## Changes in TSC
- If a TSC member feels she/he can not fulfill the "Expectations from TSC", they are free to step down.
In such a case:
- A PR is required to update the person's TSC role in question to that of a normal maintainer.
- PR should be reviewed by TSC member.
- TSC member nominations can begin in 2 weeks, add a new TSC member and ensure the normal operation of the TSC.
## Changes in Project Governance
- Changes in project governance (GOVERNANCE.md) could be initiated by opening a github PR.
- Anyone from the CubeFS TSC can vote on the PR with either +1 or -1, and it will pass if it receives a majority of votes.
- The PR should be kept open for no less than 2 weeks.
## Expectations from Maintainers
Every one carries water...
Making a community work requires input/effort from everyone. Maintainers should actively
participate in Pull Request reviews. Maintainers are expected to respond to assigned Pull Requests
in a *reasonable* time frame, either providing insights, or assign the Pull Requests to other
maintainers.
Every Maintainer is listed in the top-level [MAINTAINERS](MAINTAINERS.md) file.
## Becoming a Maintainer
On the successful merge of a significant pull request or upon making significant contributions,
any current maintainer can reach to the author behind the pull request and ask them if they are willing to become a CubeFS maintainer.
Maintainers have the authority to nominate new maintainers by either sending an email to maintainers@cubefs.groups.io or opening a pull request.
Typically, new maintainers are selected from among the committers.The steering committee will review the proposal by majority votes,
and you will receive an invitation letter from the community after the review is passed.
- Project Governance: Setting policies and guidelines for the project, including contribution guidelines and code of conduct.
- Project Governance: Propose the policies and guidelines for the project, including contribution guidelines and code of conduct.
- Roadmap and Strategy: Propose the project roadmap and strategic direction, which includes deciding on the features to be developed and the priorities for the project.
- Release Management: Managing the release process, including setting release schedules, coordinating release activities, and ensuring that releases are properly tested and documented.
- Community Engagement: Building and fostering a positive community around the project, which includes welcoming new contributors, resolving conflicts, and promoting the project.
- Committer Management: Managing the committer group, which includes adding new committers, removing inactive ones, and handling disputes within the team.
Every Maintainer is listed in the top-level [MAINTAINERS](MAINTAINERS.md) file.
## The structure of the Maintainers
- The composition of the Maintainers consists from independent developers or vendors.
- No single vendor can exceed 50% of the total number of personnel.
- The Maintainers consists of 10~15 individuals.
## Becoming a Maintainer
- **Criteria**: Upon the successful merge of a significant pull request or upon making significant contributions,any current maintainer can reach to the author behind the pull request and ask them if they are willing to become a CubeFS maintainer.
- **Nominate**: Maintainers have the authority to nominate new maintainers by either sending an email to maintainers@cubefs.groups.io or opening a pull request.
- **Elections**: Typically, new maintainers are selected from among the committers.The TSC will review the proposal by majority votes,and you will receive an invitation letter from the community after the review is passed.
## Changes in Maintainership
If a Maintainer feels she/he can not fulfill the "Expectations from Maintainers", they are free to step down.
The steering committee will adjust the list of maintainers based on the following factors
- The activity level and contribution level of the maintainer in the past six months.
- Balance of personnel across modules
- Module changes, such as additions or deprecations
- Balance of personnel among vendors.
- If a Maintainer feels she/he can not fulfill the "Expectations from Maintainers", they are free to step down.
- The TSC will adjust the list of maintainers based on the following factors
- The activity level and contribution level of the maintainer in the past six months.
- Balance of personnel across modules
- Module changes, such as additions or deprecations
- Balance of personnel among vendors.
In such a case:
A PR is required to move the person in question from the maintainer entry to the retirement entry of the respective OWNERS file. The person in question must be mentioned in the body of the PR. This acts as a final contact attempt so that they can provide their feedback.
Only for core maintainers who are losing their status:
remove them from the core-maintainers team;
go to https://maintainers.cncf.io/ and open a PR to remove them under CubeFS;
remove them from the cubefs.groups.io/g/maintainers mailing list.
- A PR is required to move the person in question from the maintainer entry to the retirement entry of the MAINTAINERS.md. This acts as a final contact attempt so that they can provide their feedback.
- Maintainers who are losing their status:
- Go to https://maintainers.cncf.io/ and open a PR to remove them under CubeFS;
- Remove them from the cubefs.groups.io/g/maintainers mailing list.
## Expectations from Committers
@ -89,45 +112,30 @@ remove them from the cubefs.groups.io/g/maintainers mailing list.
- Bugs and Issues: Helping to triage and resolve bugs and other issues reported by users.
- Feature Development: Implementing new features based on the project roadmap and community feedback
Every Committer is listed in the top-level [MAINTAINERS](MAINTAINERS.md) file.
## Committer
Committer is an active contributor in the community who continuously makes contributions to the community by contributing codes, documentation, participating in community discussions, or answering community questions, etc.
Typically, they need to have a good understanding of the project to help more community users quickly join the project. Committer will be responsible for reviewing relevant issues or PRs, and your opinions are also extremely important to the community.
Every Committer is listed in the top-level [MAINTAINERS](MAINTAINERS.md) file.
## The structure of the Committers
- The composition of the Committers consists from independent developers or vendors.
- No single vendor can exceed 50% of the total number of personnel.
- The Committers consists of 10~15 individuals.
## Becoming a committer
If you are interested in becoming a committer, please email `maintainers@cubefs.groups.io` or opening a pull request,
and list your contributions.The steering committee will review the proposal by majority votes,
and you will receive an invitation letter from the community after the review is passed.
- **Criteria**: Upon the successful merging of a meaningful pull request or after making certain contributions
- **Nominate**:
- Any current maintainer can reach to the author behind the pull request and ask them if they are willing to become a CubeFS committer.
- Contributors can also nominate themselves to become committers, please email `maintainers@cubefs.groups.io` or opening a pull request,and list your contributions.
- **Elections**: The TSC will review the proposal by majority votes internally,and you will receive an invitation letter from the community after the review is passed.
## Changes in Commitership
If a committer feels she/he can not fulfill the "Expectations from Maintainers", they are free to step down.
The steering committee will adjust the list of maintainers based on the following factors
- The activity level and contribution level of the committer in the past six months.
- Balance of personnel across modules
- Module changes, such as additions or deprecations
- Balance of personnel among vendors.
- If a committer feels she/he can not fulfill the "Expectations from Maintainers", they are free to step down.
- The TSC will adjust the list of maintainers based on the following factors
- The activity level and contribution level of the committer in the past six months.
- Balance of personnel across modules
- Module changes, such as additions or deprecations
- Balance of personnel among vendors.
In such a case:
A PR is required to move the person in question from the committer entry to the retirement entry of the respective OWNERS file. The person in question must be mentioned in the body of the PR. This acts as a final contact attempt so that they can provide their feedback.
Only for core maintainers who are losing their status:
remove them from the core-maintainers team;
go to https://maintainers.cncf.io/ and open a PR to remove them under CubeFS;
remove them from the cubefs.groups.io/g/maintainers mailing list.
## Changes in Project Governance
- Changes in project governance (GOVERNANCE.md) could be initiated by opening a github PR.
- Anyone from CubeFS Steering Committee can vote on the PR with either +1 or -1.
- The PR should be kept open for no less than 2 weeks.
- A PR is required to move the person in question from the committer entry to the retirement entry of the MAINTAINERS.md. The person in question must be mentioned in the body of the PR. This acts as a final contact attempt so that they can provide their feedback.
- Remove them from the cubefs.groups.io/g/maintainers mailing list.
## Roadmap
@ -141,54 +149,98 @@ remove them from the cubefs.groups.io/g/maintainers mailing list.
- Engage in discussions with project users and contributors to gather feedback and understand their requirements. This can be done through channels such as mailing lists, forums, and social media.
### Changes in project Roadmap
- Changes in project Roadmap (ROADMAP.md) could be initiated by opening a github PR.
- Anyone from CubeFS Maintainers can vote on the PR with either +1 or -1.
- The PR should be kept open for no less than 2 weeks.
- TSC will collect all proposals from maintainers through internal meetings or the maintainers@cubefs.groups.io email group.
- Changes to the project roadmap (ROADMAP.md) should be initiated as a pull request on GitHub by a TSC member.
- TSC will make decisions based on a majority vote.
- The pull request should remain open for a minimum of 2 weeks.
## SIG
- Currently, CubeFS are gradually implementing [SIG grouping](https://github.com/cubefs/cubefs-community).
- CubeFS project establishes Special Interest Groups (SIGs) based on the needs of project development.
### Rules
- CubeFS project establishes Special Interest Groups (SIGs) based on the needs of project development. Each SIG is composed of individuals from multiple companies and organizations who share a common goal of advancing the project in specific areas. SIGs are permanent unless dissolved by the Technical Steering Committee (TSC).
- The objective is to achieve a distributed decision-making structure and code ownership, and provide a dedicated forum to complete work, make decisions, and onboard new contributors. Each identifiable part of the project (such as repositories, subdirectories, APIs, tests, issues, PRs) is intended to be owned by a specific SIG.
SIGs must have an open membership policy and always operate in an open environment. Changes in the leadership of SIGs (SIG chairs and technical leads) require approval from the Technical Steering Committee and can have varying durations.
### Expectations from SIGs
- The objective is to achieve a distributed decision-making structure and code ownership
- Provide a dedicated forum to complete work, make decisions, and onboard new contributors.
- Each identifiable part of the project (such as repositories, subdirectories, APIs, tests, issues, PRs) is intended to be owned by a specific SIG.
- SIGs must have an open membership policy and always operate in an open environment.
### Expectations from SIGs member
- SIG Chairs:
Each SIG must have at least one SIG chair, and there can be a maximum of two chairs simultaneously. SIG chairs are organizers and advocates responsible for the operation of the SIG, as well as communication and coordination with other SIGs and the broader community.
- Responsibilities:
- SIG's organizers and advocates, responsible for the operation of the SIG, as well as for establishing development goals for the SIG.
- Communication and coordination with other SIGs and the broader community.
- Each SIG must have at least one SIG chair, and there can be a maximum of two chairs simultaneously.
- Technical Leads:
Technical leads are responsible for leading the SIG to align with its technical coordination. This coordination includes both internal coordination within the SIG and external coordination across the entire project.
- Responsibilities: Technical leads are responsible for leading the SIG to align with its technical coordination, especilly at technical decision-making and execution
- SIG may have a technical lead or may not, depending on the nature of the SIG.
- Participants(member)
- Responsibilities: Actively contribute to the SIG, finish the work assigned by the technical leader.
RelationShip between Chairs and Technical Leads:
- Chairs are responsible for the goals and direction of the SIG, as well as for setting long-term plans and short-term objectives.
- Technical leads are responsible for implementing the goals and short-term objectives.
- In case of disputes, issues can be submitted to the TSC for decision-making.
### The RelationShip between SIG and other organization or role
- RelationShip with TSC
- SIGs follow the leadership of the TSC.
- RelationShip with Maintainer in Maintainer list:
- If the SIG is responsible for the main project module, all maintainers and committers associated with the module should be included in the maintainer list to prevent interruptions.
- Any disputes between the maintainer and the SIG group can be resolved through the TSC.
### Becoming a member of SIGs
- **Criteria**:
- The chairperson must be a maintainer member.This helps to reduce controversies regarding SIG governance strategies and overall community governance.
- The Technical Leads must be a maintainer or a committer.
- The participants(member) must be contributors who can actively contribute to the SIG.
- **Nominate**
- SIG Chairs:
- TSC members nominate maintainers internally via maintainers@cubefs.groups.io, and the nominations are approved by a majority vote, followed by a public review on GitHub by maintainers.
- Technical Leads:
- Depending on the overall size of the SIG, SIG chairs may nominate approximately two to three individuals to support the technical aspects of the group.
- SIG Chairs can independently decide whether to include technical leads in their charters.
- Participants:
- No need to nominate, added directly by chair or technical leader.
- **Elections**
- Nominate PR applications should be submitted by maintainers and approved by the TSC when there is a change in the chair or tech lead.
### Member Changes and Management in SIGs
- SIGs can independently decide whether to include technical leads in their charters. Depending on the overall size of the SIG, SIG chairs may nominate approximately two to three individuals to support the technical aspects of the group. In order to fulfill their responsibilities, technical leads should have the same authority as the chairs but need apply chairs's option if there's any controversies.
- The maintainer of a corresponding module is required to be part of the respective SIG group. Currently, we are gradually implementing SIG grouping. Maintainers still have full authority over the modules they are responsible for. Any disputes between the maintainer and the SIG group can be resolved through the TSC (Technical Steering Committee).
- The chairperson must be a maintainer member.This helps to reduce controversies regarding SIG governance strategies and overall community governance.
- PR applications should be submitted by maintainers and approved by the TSC once the chair or tec lead change.
- The internal management of SIGs can be determined by the SIG chairs according to the rules established by SIGs themselves.
- If a chair or tec leader feels she/he can not fulfill the "Expectations from SIGs", they are free to step down.
- The TSC will adjust the chair or tec leader based on the following factors
- The activity level and contribution level in the past six months.
- Balance of personnel among vendors.
- If participants cannot meet the requirements of the SIG, they can be removed directly by the chair or technical leader by opening a PR in the SIG and notifying the participant.
### SIG Lifecycle
- Formation:
- Any community maintainers and contributors can propose the creation of a SIG..
- Community discussion and feedback are gathered.
- Each SIG is composed of individuals from multiple companies and organizations who share a common goal of advancing the project in specific areas.
- Approval:
- The proposal is reviewed by the TSC to ensure it aligns with the project's objectives, make decisions by majority vote.
- If approved, the SIG is officially established, and members can be recruited.
- Active Phase:
- The SIG defines its goals, responsibilities, and processes.
- Members are recruited and roles are assigned.
- Regular meetings and communication are held to facilitate collaboration.
- Evaluation:
- The SIG periodically assesses its progress and contributions to the project.
- Feedback from the community is collected to improve operations.
- Maintenance:
- The SIG continues to work on its objectives, adapting to changes in community needs.
- New members may join, and roles may be adjusted as necessary.
- Closure:
- If a SIG is no longer needed or fails to meet its objectives, the SIG chair, tech leader, and TSC member can propose its closure.
- The TSC reviews and approves the closure, ensuring a smooth transition for any ongoing work.
## Vendor-neutrality
- Vendors share communication channels of the community, such as social media and messaging platforms.
- All vendors involved in the project are encouraged to actively participate in the topic selection process for public events.
- Vendors can apply to participate in open-source conferences and events. The invitation should be cc'ed to `maintainers@cubefs.groups.io`.
- The Steering Committee will review the application, and if it is approved, the Steering Committee can provide guidance on this matter.
- The TSC will review the application, and if it is approved, the TSC can provide guidance on this matter.
## Decision making process
Decisions are build on consensus between maintainers.
Proposals and ideas can either be submitted for agreement via a github issue or PR,
or by sending an email to `maintainers@cubefs.groups.io`.
In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved.
If a dispute cannot be decided independently, get a third-party maintainer (e.g. a mutual contact with some background
on the issue, but not involved in the conflict) to intercede.
If a dispute still cannot be decided, the Steering Committee can make the decision by majority votes.
Decision making process should be transparent to adhere to
the principles of CubeFS project.
All proposals, ideas, and decisions by maintainers or the Steering Committee should either be part of a github issue or PR, or be sent to `maintainers@cubefs.groups.io`.
## Github Project Administration
@ -198,6 +250,11 @@ The __cubefs__ GitHub project maintainers team reflects the list of Maintainers.
The sub-projects of CubeFS are closely related to the main project, serving as essential supplements that need to be released synchronously with the main version when necessary. Among other listed projects, some are for exploratory purposes while others are related to peripheral ecosystem products.
Current Sub-Projects:
- [CubeFS-Helm](https://github.com/cubefs/cubefs-helm):The CubeFS-Helm project helps deploy a CubeFS cluster orchestrated by Kubernetes.
- [CubeFS-CSI](https://github.com/cubefs/cubefs-csi):CubeFS Container Storage Interface (CSI) plugins.
- [CubeFS-Dashboard](https://github.com/cubefs/cubefs-dashboard):A web-admin for CubeFS.
The CubeFS organization is open to receive new sub-projects under its umbrella. To accept a project
into the __CubeFS__ organization, it has to meet the following criteria:
@ -213,6 +270,18 @@ The submission process starts as a Pull Request or Issue on the
[cubefs/cubefs](https://github.com/cubefs/cubefs) repository with the required information
mentioned above. Once a project is accepted, it's considered a __sub-project under the umbrella of CubeFS__.
## Product Security Committee(PSC)
The [Product Security Committee](https://github.com/cubefs/cubefs/blob/master/security/security-release-process.md#product-security-committee) is responsible for organizing the entire response including internal communication and external disclosure but will need help from relevant developers and release leads to successfully run this process.
## Contribute
[Details on Contributing to CubeFS](https://github.com/cubefs/cubefs/blob/master/CONTRIBUTING.md)
There is a clear definition of roles and their promotion paths.
- [Becoming a Committer](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#becoming-a-committer)
- [Becoming a Maintainer](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#becoming-a-maintainer)
- [Becoming a TSC Member](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#becoming-a-tsc-member)
## New Plugins
The CubeFS is open to receive new plugins as part of the CubeFS repo. The submission process is the same as a Pull Request submission. Unlike small Pull Requests though, a new plugin submission should only be approved by a maintainer not associated or affiliated with the author(s) of the plugin.
@ -231,4 +300,5 @@ The [CubeFS Code of Conduct](CODE_OF_CONDUCT.md) is aligned with the CNCF Code o
## Liaison Officer for CNCF
The liaison officer is responsible for daily communication with CNCF, including information updates, demand communication, community activity meetings, etc.
- The liaison officer is responsible for daily communication with CNCF, including information updates, demand communication, community activity meetings, etc.
- The liaison officer must be a TSC member recommended internally by the TSC. The term does not have a fixed duration and can be adjusted by the TSC when its members change.

346
GOVERNANCE_CN.md
View File

@ -5,173 +5,299 @@
CubeFS 社区遵循以下原则：
- 开放：CubeFS 是开源的。
- 欢迎和尊重：参见[行为准则](CODE_OF_CONDUCT.md)。
- 透明和可访问：CubeFS 组织、CubeFS 代码库和 CNCF 相关活动（如级别、参与等）的变更均在公开场合进行。
- 贡献：根据想法和贡献的技术价值及其与项目目标、范围和设计原则的对齐程度接受想法和贡献。
- 欢迎和尊重：请参阅 [行为准则](CODE_OF_CONDUCT.md)。
- 透明和可访问：对 CubeFS 组织、CubeFS 代码库和 CNCF 相关活动的变更（如级别、参与等）均在公开场合进行。
- 贡献：根据技术优点及与项目目标、范围和设计原则的一致性接受想法和贡献。
## 指导委员会的期望
## 技术指导委员会（TSC）的期望
CubeFS 项目有一个指导委员会。
- 指导委员会成员的任期为一年，个人可以连续多次担任此角色。
- 指导委员会成员负责项目的顶层设计、路线图的制定和社区管理。
- 指导委员会成员由来自独立开发者或供应商的核心维护者组成。
- 为确保公平，将努力保持不同供应商人员之间的平衡代表性。
- 单一供应商的人员不得超过总人数的50%。
- 指导委员会的任期为一年
CubeFS TSC 是 CubeFS 项目的管理机构：
- 提供与其章程相关的决策和监督。
- 定义项目的价值观和结构。
- 负责项目的顶层设计、路线图的制定和社区管理。
- 批准创建和解散特别兴趣小组（SIG）。
- 建立和维护项目的整体技术治理指南。
- 如果无法达成共识，通过多数票做出决定。
## 维护者的期望
## 技术指导委员会的结构
每个人都要努力...
- TSC 成员也是维护者，只有 TSC 成员可以被视为核心维护者。
- TSC 成员的组成包括来自独立开发者或供应商的维护者。
- 为确保公平，将努力保持来自不同供应商的人员的平衡代表性。
- 任一单一供应商的人员不得超过总人数的 50%。
- TSC 的任期为两年。
- TSC 由 5 人组成。
让社区运作需要每个人的投入和努力。维护者应积极参与拉取请求（Pull Request）的审查。维护者应在*合理*的时间内对分配的拉取请求做出回应，提供见解或将拉取请求分配给其他维护者。
每个维护者都列在顶层的[MAINTAINERS](MAINTAINERS.md)文件中。
## TSC 决策流程
## 提交者
在 TSC 任期的第一年，如果 TSC 会议缺少法定人数，将启动电子邮件投票程序。如果电子邮件投票在一周内也未能达到法定人数，则该议案将被视为通过，除非 TSC 成员有异议。
提交者是社区中的活跃贡献者，通过贡献代码、文档、参与社区讨论或回答社区问题等方式不断为社区做出贡献。
## 成为 TSC 成员
通常，他们需要对项目有良好的理解，以帮助更多的社区用户快速加入项目。提交者将负责审查相关问题或拉取请求，他们的意见对社区也非常重要。
TSC 职位的任期为两年，个人可以多次担任该角色。TSC 成员的变更通过打开 GitHub PR 进行。
每个提交者都列在顶层的[MAINTAINERS](MAINTAINERS.md)文件中。
- **标准**：提名者必须是维护者，在过去两年中对社区做出过重大贡献，并在社区中拥有足够的声誉和影响力。
- **提名**：
- 每个选择小组的个人可以提名最多 2 人，最多 1 人可以来自同一相关公司的组。每位提名者必须在被加入提名名单之前同意参与。允许自我提名。每位提名者需要来自不同组织/公司的其他 2 名贡献者的支持。
- 提名必须公开，并应包含提名者的姓名、联系信息和经验说明。当前 TSC 将确定提名、资格和新 TSC 成员选举的流程和时间表。
- **选举**：
- 如果合格提名者的数量等于或少于可选 TSC 座位的数量，则合格提名者将在提名期结束后获得批准。
- 如果合格提名者超过可选 TSC 座位的数量，则选择小组将通过 Condorcet 投票选举 TSC 成员。
- Condorcet 投票将通过康奈尔在线服务（https://civs.cs.cornell.edu/）使用 Condorcet-IRV 方法进行。
- 只有以下投票具有约束力：
- 在 PR 开启之前已在顶级 [MAINTAINERS](MAINTAINERS.md) 文件中列出的任何维护者。
- 任何组织的维护者可以为该组织投票。然而，任何组织的有效投票不得超过总维护者数量的 1/2。
## 成为提交者
PR 应在任期结束前不早于 4 周打开。PR 应保持开放不少于 2 周。PR 只能在最后任期结束后合并，并在有效投票中获得 +1 多于 -1 后。
如果您有兴趣成为提交者，请发送电子邮件至 `maintainers@cubefs.groups.io` 或打开一个拉取请求，并列出您的贡献。指导委员会将通过多数票审查提案，审查通过后，您将收到来自社区的邀请函。
TSC 将在正式化此组织结构后的 3 个月内决定并公布选举流程。这将涵盖投票资格、候选资格、选举流程和时间表。
## 成为维护者
## TSC 的变更
成功合并重要的拉取请求或做出重大贡献后，任何现任维护者都可以联系拉取请求的作者，询问他们是否愿意成为 CubeFS 的维护者。维护者有权提名新的维护者，可以通过发送电子邮件至 maintainers@cubefs.groups.io 或打开一个拉取请求。通常，新维护者从提交者中选出。指导委员会将通过多数票审查提案，审查通过后，您将收到来自社区的邀请函。
## 维护者身份的变更
如果维护者认为自己无法履行“维护者的期望”，他们可以自由卸任。指导委员会将根据以下因素调整维护者名单：
- 维护者在过去六个月的活动水平和贡献水平。
- 各模块人员的平衡。
- 模块变更，如增加或废弃。
- 各供应商人员的平衡。
- 如果 TSC 成员感到无法履行“对 TSC 的期望”，他们可以自愿辞职。
在这种情况下：
需要提交一个 PR 将相关人员从维护者条目移动到相应 OWNERS 文件的退休条目中。在 PR 正文中必须提到相关人员。这作为最后一次联系尝试，以便他们可以提供反馈。
仅适用于失去其身份的核心维护者：
从核心维护者团队中删除他们；
前往 https://maintainers.cncf.io/ 并打开一个 PR 将他们从 CubeFS 下删除；
从 cubefs.groups.io/g/maintainers 邮件列表中删除他们。
## 指导委员会的变更
指导委员会成员的变更通过打开一个 GitHub PR 发起。
CubeFS 的任何维护者都可以对 PR 投票，投票可以是 +1 或 -1。
只有以下投票是有约束力的：
1) 在 PR 打开前，已列在顶层[MAINTAINERS](MAINTAINERS.md)文件中的任何维护者。
2) 任何组织的维护者可以为该组织投票。但是，任何组织的有约束力投票数量不得超过维护者总数的1/2。
PR 不应早于任期结束前4周打开。
PR 应保持开放不少于 2 周。PR 只能在上一个任期结束后合并，并且需要在约束性投票中获得比 -1 更多的 +1 票。
当关于指导委员会变更的 PR 存在冲突时，拥有最多约束性 +1 票的 PR 将被合并。
指导委员会成员可以自愿卸任。
- 需要通过 PR 更新相关人员的 TSC 角色为普通维护者。
- PR 应由 TSC 成员审核。
- TSC 成员提名可在 2 周内开始，以增加新 TSC 成员并确保 TSC 的正常运作。
## 项目治理的变更
- 项目治理（GOVERNANCE.md）的变更可以通过打开一个 GitHub PR 发起。
- CubeFS 指导委员会的任何成员都可以对 PR 投票，投票可以是 +1 或 -1。
- 项目治理（GOVERNANCE.md）的变更可以通过打开 GitHub PR 来发起。
- 任何CubeFS TSC成员都可以对PR投票，票数达到大多数（即+1或-1）即可通过。
- PR 应保持开放不少于 2 周。
## 对维护者的期望
- 项目治理：提出项目的政策和指南，包括贡献指南和行为准则。
- 路线图和战略：提出项目路线图和战略方向，包括决定开发的功能和项目的优先级。
- 发布管理：管理发布过程，包括设置发布日程、协调发布活动，并确保发布经过适当测试和文档。
- 社区参与：建立和促进围绕项目的积极社区，包括欢迎新贡献者、解决冲突和推广项目。
- 提交者管理：管理提交者组，包括添加新提交者、移除不活跃者和处理团队内的争议。
每位维护者都列在顶级 [MAINTAINERS](MAINTAINERS.md) 文件中。
## 维护者的结构
- 维护者的组成由独立开发者或供应商组成。
- 任一单一供应商的人员不得超过总人数的 50%。
- 维护者由 10 到 15 人组成。
## 成为维护者
- **标准**：在成功合并一个重要的拉取请求后，或者在做出重大贡献后，任何现有维护者可以联系该拉取请求的作者，询问他们是否愿意成为 CubeFS 维护者。
- **提名**：维护者有权通过发送电子邮件至 maintainers@cubefs.groups.io 或打开拉取请求提名新维护者。
- **选举**：通常，新维护者是在提交者中选出的。TSC 将通过多数投票审查提案，审核通过后，您将收到社区的邀请信。
## 维护者身份的变更
- 如果维护者感到无法履行“对维护者的期望”，他们可以自愿辞职。
- TSC 将根据以下因素调整维护者名单：
- 维护者在过去六个月内的活跃水平和贡献水平。
- 跨模块的人员平衡。
- 模块变更，如新增或弃用。
- 供应商间的人员平衡。
在这种情况下：
- 需要通过 PR 将相关人员从维护者条目移动到 MAINTAINERS.md 的退休条目。这作为最后的联系尝试，以便他们提供反馈。
- 失去身份的维护者：
- 访问 https://maintainers.cncf.io/ 并打开 PR 以在 CubeFS 下移除他们；
- 从 cubefs.groups.io/g/maintainers 邮件列表中移除他们。
## 对提交者的期望
- 代码贡献：编写和提交对项目代码库的更改。
- 代码审查：审查和批准其他贡献者提出的代码更改，在合并到主分支之前。
- 文档：更新和维护与项目相关的文档。
- 缺陷和问题：帮助整理和解决用户报告的缺陷和其他问题。
- 功能开发：根据项目路线图和社区反馈实施新功能。
## Committers的结构
- Committers的组成包括来自独立开发者或供应商。
- 任何单一供应商的人数不得超过总人数的50%。
- Committers人数为10到15人。
## 成为提交者
- **标准**：在成功合并一个有意义的拉取请求后或在做出某些贡献后。
- **提名**：
- 任何现有维护者可以联系拉取请求的作者，询问他们是否愿意成为 CubeFS 提交者。
- 贡献者也可以自我提名，发送电子邮件至 maintainers@cubefs.groups.io 或打开拉取请求，并列出他们的贡献。
- **选举**：TSC 将在内部通过多数投票审查提案，审核通过后，您将收到社区的邀请信。
## 提交者身份的变更
- 如果提交者感到无法履行“对维护者的期望”，他们可以自愿辞职。
- TSC 将根据以下因素调整维护者名单：
- 提交者在过去六个月内的活跃水平和贡献水平。
- 跨模块的人员平衡。
- 模块变更，如新增或弃用。
- 供应商间的人员平衡。
在这种情况下：
- 需要通过 PR 将相关人员从提交者条目移动到 MAINTAINERS.md 的退休条目。相关人员必须在 PR 的正文中提及。这作为最后的联系尝试，以便他们提供反馈。
- 从 cubefs.groups.io/g/maintainers 邮件列表中移除他们。
## 路线图
### 规则
- 定义目标：清晰阐明项目的长期和短期目标。这些目标应与项目的愿景和价值观保持一致，同时满足用户或社区的需求。
- 优先排序：根据目标的重要性和紧迫性进行排序。考虑资源和时间限制，确保重点放在最关键的目标上。
- 基于时间的规划：将目标分解为里程碑或阶段任务。为每个阶段定义具体目标和可衡量的指标，以便稍后评估进展。
- 透明和沟通：与项目利益相关者（包括用户、贡献者和其他相关方）公开分享路线图。这有助于建立透明度，并使每个人都了解项目的方向和计划。
- 持续调整：开源项目的路线图应是一个动态文件，随着新见解的获得，可能需要进行调整和更新。定期审查和重新评估路线图，并根据需要进行修改。
- 方法：在创建路线图时，考虑社区的意见和建议，以确保项目的发展符合广泛的期望和需求。
- 与项目用户和贡献者进行讨论，收集反馈并了解他们的需求。这可以通过邮件列表、论坛和社交媒体等渠道进行。
- 确定目标：清晰阐明项目的长期和短期目标。这些目标应与项目的愿景和价值观保持一致，同时满足用户或社区的需求。
- 优先级：根据重要性和紧迫性对目标进行排名。考虑资源和时间限制，确保重点放在最关键的目标上。
- 时间规划：将目标分解为里程碑或阶段性任务。为每个阶段定义具体目标和可衡量指标，以便后续评估进展。
- 透明和沟通：与项目利益相关者（包括用户、贡献者和其他相关方）公开分享路线图。这有助于建立透明度并使每个人都了解项目的方向和计划。
- 持续调整：开源项目的路线图应是一个动态文档，可能需要随着新见解的获得进行调整和更新。定期回顾和重新评估路线图，并根据需要进行修改。
- 方法：在制定路线图时，考虑社区的意见和建议，以确保项目的发展与广泛的期望和需求保持一致。
- 与项目用户和贡献者进行讨论，以收集反馈并了解他们的需求。这可以通过邮件列表、论坛和社交媒体等渠道进行。
### 项目路线图的变更
- 项目路线图（ROADMAP.md）的变更可以通过打开一个 GitHub PR 发起。
- CubeFS 维护者的任何成员都可以对 PR 投票，投票可以是 +1 或 -1。
- PR 应保持开放不少于 2 周。
- TSC 将通过内部会议或 maintainers@cubefs.groups.io 邮件小组收集维护者的所有提案。
- 项目路线图（ROADMAP.md）的变更应由 TSC 成员在 GitHub 上打开拉取请求发起。
- TSC 将根据多数票做出决定。
- 拉取请求应保持开放至少 2 周。
## 特别兴趣小组（SIG）
- 目前，CubeFS 正在逐步实施 [SIG 分组](https://github.com/cubefs/cubefs-community)。
- CubeFS 项目根据项目开发的需求建立特别兴趣小组（SIG）。
### 规则
- CubeFS 项目根据项目发展的需要设立特别兴趣小组（SIG）。每个 SIG 由来自多家公司和组织的个人组成，他们在特定领域内共同推进项目的发展。SIG 是永久性的，除非由技术指导委员会（TSC）解散。
- 目标是实现分布式决策结构和代码所有权，并提供一个专门的论坛来完成工作、做出决策和引导新贡献者。项目的每个可识别部分（如代码库、子目录、API、测试、问题、PR）都旨在由特定的 SIG 负责。
SIG 必须有开放的成员政策，并始终在开放环境中运作。SIG 领导层的变更（SIG 主席和技术负责人）需要技术指导委员会的批准，并且可以有不同的任期。
### 对 SIG 的期望
- 目标是实现分布式决策结构和代码所有权。
- 提供专门的论坛以完成工作、做出决策并引导新贡献者。
- 项目中每个可识别部分（如代码库、子目录、API、测试、问题、PR）都旨在由特定的 SIG 拥有。
- SIG 必须具有开放的成员资格政策，并始终在开放环境中运作。
### SIG 成员的期望
- SIG 主席：
每个 SIG 必须至少有一名 SIG 主席，同时最多可以有两名主席。SIG 主席是组织者和倡导者，负责 SIG 的运作，以及与其他 SIG 和更广泛社区的沟通和协调。
- 职责：
- SIG 的组织者和倡导者，负责 SIG 的运作以及设定 SIG 的发展目标。
- 与其他 SIG 和更广泛的社区沟通和协调。
- 每个 SIG 至少必须有一个主席，同时最多可以有两个主席。
- 技术负责人：
技术负责人负责引导 SIG 与其技术协作。这种协作包括 SIG 内部的协调和整个项目的外部协调。
- 职责：技术负责人负责领导 SIG，以确保其技术协调，特别是在技术决策和执行方面。
- SIG 可以有技术负责人，也可以没有，这取决于 SIG 的性质。
- 参与者（成员）：
- 职责：积极贡献于 SIG，完成技术负责人分配的工作。
### SIG 成员变更和管理
- SIG 可以自主决定是否在其章程中包括技术负责人。根据 SIG 的整体规模，SIG 主席可以提名大约两到三名个人来支持小组的技术方面。为了履行其职责，技术负责人应具有与主席相同的权力，但在有争议时需要申请主席的意见。
- 对应模块的维护者需要成为相应 SIG 小组的一部分。目前，我们正在逐步实施 SIG 分组。维护者仍然对其负责的模块拥有完全的权力。维护者与 SIG 小组之间的任何争议可以通过 TSC（技术指导委员会）解决。
- 主席必须是维护者成员。这有助于减少关于 SIG 治理策略和整体社区治理的争议。
- PR 申请应由维护者提交，并在主席或技术负责人变更后由 TSC 批准。
- SIG 的内部管理可以由 SIG 主席根据 SIG 自身制定的规则决定。
主席与技术负责人之间的关系：
- 主席负责 SIG 的目标和方向，以及设定长期计划和短期目标。
- 技术负责人负责实施目标和短期目标。
- 在发生争议时，问题可以提交给 TSC 进行决策。
## 供应商中立性
### SIG 与其他组织或角色的关系
- 与 TSC 的关系：
- SIG 遵循 TSC 的领导。
- 与维护者名单中的维护者的关系：
- 如果 SIG 负责主要项目模块，则所有与该模块相关的维护者和提交者应包含在维护者名单中，以防止中断。
- 维护者与 SIG 组之间的任何争议可以通过 TSC 解决。
- 供应商共享社区的沟通渠道，如社交媒体和消息平台。
- 鼓励参与项目的所有供应商积极参与公共活动的主题选择过程。
- 供应商可以申请参加开源会议和活动。邀请函应抄送至 `maintainers@cubefs.groups.io`。
- 指导委员会将审查申请，如果批准，指导委员会可以在此事上提供指导。
### 成为 SIG 的成员
- **标准**：
- 主席必须是维护者成员。这有助于减少有关 SIG 治理策略和整体社区治理的争议。
- 技术负责人必须是维护者或提交者。
- 参与者（成员）必须是可以积极贡献于 SIG 的贡献者。
- **提名**：
- SIG 主席：
- TSC 成员通过 maintainers@cubefs.groups.io 内部提名维护者，提名需经多数票批准，然后在 GitHub 上进行公开审查。
- 技术负责人：
- 根据 SIG 的整体规模，SIG 主席可以提名大约两到三个人来支持该小组的技术工作。
- SIG 主席可以独立决定是否在其章程中包含技术负责人。
- 参与者：
- 无需提名，由主席或技术负责人直接添加。
- **选举**：
- 当主席或技术负责人发生变更时，提名 PR 申请应由维护者提交，并经 TSC 批准。
## 决策过程
### SIG 中的成员变更和管理
- 如果主席或技术负责人感到无法履行“对 SIG 的期望”，他们可以自愿辞职。
- TSC 将根据以下因素调整主席或技术负责人：
- 在过去六个月内的活跃水平和贡献水平。
- 供应商间的人员平衡。
- 如果参与者无法满足 SIG 的要求，主席或技术负责人可以通过在 SIG 中打开 PR 直接将其移除，并通知该参与者。
决策建立在维护者之间的共识基础上。
提案和想法可以通过 GitHub 问题或 PR 提交以供同意，或者通过发送电子邮件至 `maintainers@cubefs.groups.io`。
### SIG 生命周期
通常，我们更倾向于技术问题和维护者成员资格在相关人员之间友好解决。
如果争议无法自行决定，请寻找第三方维护者（例如，对问题有一些背景但未参与冲突的共同联系人）进行调解。
如果争议仍无法决定，指导委员会可以通过多数票做出决定。
- **成立**：
- 任何社区维护者和贡献者都可以提议创建一个 SIG。
- 收集社区讨论和反馈。
- 每个 SIG 由来自多个公司和组织的个人组成，他们在特定领域推动项目的共同目标。
决策过程应透明，以遵循 CubeFS 项目的原则。
- **审批**：
- 提案由 TSC 审查，以确保其与项目目标一致，通过多数投票作出决策。
- 如果获得批准，SIG 正式成立，可招募成员。
所有提案、想法和由维护者或指导委员会做出的决定应成为 GitHub 问题或 PR 的一部分，或发送至 `maintainers@cubefs.groups.io`。
- **活跃阶段**：
- SIG 定义其目标、职责和流程。
- 招募成员并分配角色。
- 定期召开会议和沟通，以促进协作。
- **评估**：
- SIG 定期评估其进展和对项目的贡献。
- 收集社区反馈以改进运作。
- **维护**：
- SIG 继续致力于其目标，适应社区需求的变化。
- 新成员可以加入，角色可根据需要进行调整。
- **关闭**：
- 如果 SIG 不再需要或未能实现其目标，SIG 主席、技术领导和 TSC 成员可以提议关闭。
- TSC 审查并批准关闭，确保任何正在进行工作的平稳过渡。
## 厂商中立性
- 厂商共享社区的沟通渠道，例如社交媒体和消息平台。
- 所有参与该项目的厂商都鼓励积极参与公开活动的主题选择过程。
- 厂商可以申请参加开源会议和活动。邀请应抄送至 `maintainers@cubefs.groups.io`。
- TSC 将审核申请，如果批准，TSC 可以提供指导。
## GitHub 项目管理
__cubefs__ GitHub 项目的维护者团队反映了维护者的名单。
__cubefs__ GitHub 项目的维护团队反映了维护者的名单。
## 其他项目
## 子项目
CubeFS 组织欢迎新的子项目加入其旗下。要接受一个项目加入 __CubeFS__ 组织，它必须满足以下标准：
CubeFS 的子项目与主项目密切相关，作为必要的补充，需要在必要时与主版本同步发布。在其他列出的项目中，有些用于探索性目的，而其他则与外围生态产品相关。
- 必须根据 Apache License v2.0 的条款进行许可。
当前子项目：
- [CubeFS-Helm](https://github.com/cubefs/cubefs-helm)：CubeFS-Helm 项目帮助部署由 Kubernetes 编排的 CubeFS 集群。
- [CubeFS-CSI](https://github.com/cubefs/cubefs-csi)：CubeFS 容器存储接口 (CSI) 插件。
- [CubeFS-Dashboard](https://github.com/cubefs/cubefs-dashboard)：CubeFS 的网页管理工具。
CubeFS 组织欢迎接收新的子项目加入其范围。要接受一个项目进入 __CubeFS__ 组织，必须满足以下标准：
- 必须根据 Apache 许可证 v2.0 的条款进行许可。
- 必须与 CubeFS 生态系统的一个或多个范围相关：
- CubeFS 项目工件（网站、部署、CI 等）
- 外部插件
- 其他存储相关主题
- 必须得到与子项目作者无关或无隶属关系的维护者的支持。
- 其他与存储相关的主题
- 必须由与子项目作者无关的维护者支持。
- 子项目可以拥有自己的代码库，但需遵循与主项目相同的治理机制。
提交过程从在 [cubefs/cubefs](https://github.com/cubefs/cubefs) 仓库上创建拉取请求或问题并提供上述所需信息开始。一旦项目被接受，它将被视为 CubeFS 旗下的子项目。
提交过程以 Pull Request 或 Issue 的形式开始，需在 [cubefs/cubefs](https://github.com/cubefs/cubefs) 仓库中提供上述所需信息。一旦项目被接受，便视为 __CubeFS__ 旗下的一个子项目。
## 产品安全委员会 (PSC)
[产品安全委员会](https://github.com/cubefs/cubefs/blob/master/security/security-release-process.md#product-security-committee) 负责组织整个响应，包括内部沟通和外部披露，但需要相关开发人员和发布负责人提供帮助，以成功运行此过程。
## 贡献
[有关贡献CubeFS的详细信息](https://github.com/cubefs/cubefs/blob/master/CONTRIBUTING.md)
明确的角色及其晋升路径如下：
- [成为提交者](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#becoming-a-committer)
- [成为维护者](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#becoming-a-maintainer)
- [成为技术监督委员会成员](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#becoming-a-tsc-member)
## 新插件
CubeFS 欢迎作为 CubeFS 仓库一部分的新插件。提交过程与拉取请求提交相同。然而，与小型拉取请求不同，新插件提交应仅由与插件作者无关或无隶属关系的维护者批准。
CubeFS 欢迎接收作为 CubeFS 仓库一部分的新插件。提交过程与 Pull Request 提交相同。与小型 Pull Request 不同的是，新插件的提交应仅由与插件作者无关的维护者批准。
## CubeFS 与 CNCF
CubeFS 可能参与 CNCF（或其他 CNCF 项目）相关的市场营销、活动或活动。任何维护者都可以帮助推动 CubeFS 的参与，只要她/他发送电子邮件至 `maintainers@cubefs.groups.io`（或创建 GitHub 拉取请求）以呼吁其他维护者参与。如果时间允许，“参与呼吁”应保持开放不少于一周，或者保持*合理*的时间框架，以允许维护者有机会自愿参与。
CubeFS 可能参与与 CNCF（或其他 CNCF 项目）相关的营销、活动或活动。任何维护者都可以帮助推动 CubeFS 的参与，只要她/他向 `maintainers@cubefs.groups.io` 发送电子邮件（或创建 GitHub Pull Request）以呼吁其他维护者参与。`呼吁参与` 应保持开放不少于一周的时间，若时间允许，或保持一个 _合理_ 的时间框架，以便维护者有机会自愿参与。
## 行为准则
[CubeFS 行为准则](CODE_OF_CONDUCT.md)与 CNCF 行为准则保持一致。
[CubeFS 行为准则](CODE_OF_CONDUCT.md) 与 CNCF 行为准则保持一致。
## CNCF 联络员
## CNCF 联络官
联络员负责与 CNCF 的日常沟通，包括信息更新、需求沟通、社区活动会议等。
## 致谢
本文档的部分内容借鉴了 [CoreDNS](https://raw.githubusercontent.com/coredns/coredns/master/GOVERNANCE.md)、[Fluentd](https://github.com/fluent/fluentd/blob/master/GOVERNANCE.md) 和 [Envoy](https://github.com/envoyproxy/envoy/blob/master/GOVERNANCE.md) 项目。
- 联络官负责与 CNCF 的日常沟通，包括信息更新、需求沟通、社区活动会议等。
- 联络官必须是由 TSC 内部推荐的 TSC 成员。任期没有固定期限，可以在 TSC 成员变更时进行调整。

103
MAINTAINERS.md
View File

@ -1,54 +1,63 @@
# Maintainers
This page listed the CubeFS main maintainers and their responsibilities.
# Technical Steering Committee(TSC)
| Name | Email | Duty | Organization |
|------------------------------------------------------------------------|-----------------------------------------------------------------|-----------------------------------------------------------------------------|--------------|
| Haifeng Liu ([@bladehliu](https://github.com/bladehliu)) | [bladehliu@qq.com](mailto:bladehliu@qq.com) | Sponsor, Software Architect, steering committee member | - |
| Weilong Guo ([@awzhgw](https://github.com/awzhgw)) | [guowl18702995996@gmail.com](mailto:guowl18702995996@gmail.com) | Software Architect, steering committee member | [JD.com] |
| Shuoran Liu ([@shuoranliu](https://github.com/shuoranliu)) | [shuoranliu@gmail.com](mailto:shuoranliu@gmail.com) | Client | [BEIKE] |
| Xiaochun He ([@xiaochunhe](https://github.com/xiaochunhe)) | [626148589@qq.com](mailto:626148589@qq.com) | Software Architect, steering committee member | [OPPO] |
| Mofei Zhang ([@mervinkid](https://github.com/mervinkid)) | [mofei2816@gmail.com](mailto:mofei2816@gmail.com) | Metadata, steering committee member | [JD.com] |
| Liang Chang ([@leonrayang](https://github.com/leonrayang)) | [chl696@sina.com](mailto:chl696@sina.com) | Resource Manager, steering committee member | [OPPO] |
| Xuewei Zeng ([@Victor1319](https://github.com/Victor1319)) | [834863182@qq.com](mailto:834863182@qq.com) | Data Storage | [OPPO] |
| Dr.Wei Ding ([@wding109](https://github.com/wding109)) | [wding109@gmail.com](mailto:wding109@gmail.com) | Strategy, Researching | [ByteDance] |
| Dr.Junyuan Zeng ([@jzeng4](https://github.com/jzeng4)) | [jzeng04@gmail.com](mailto:[jzeng04@gmail.com) | Authorization | [LinkedIn] |
| hooklee2000 ([@hooklee2000](https://github.com/hooklee2000)) | [hooklee2000@gmail.com](mailto:hooklee2000@gmail.com) | Project Building | [XFusion] |
| Zhendong Li ([@lizhendong666](https://github.com/lizhendong666)) | [lizhendong666@gmail.com](mailto:lizhendong666@gmail.com) | Yum Deployment | [JD.com] |
| Xiaobo Yu ([@cessory](https://github.com/cessory)) | [yxbstorm@gmail.com](mailto:yxbstorm@gmail.com) | Blobstore Architect | [OPPO] |
| Cloudstriff ([@Cloudstriff](https://github.com/Cloudstriff)) | [chenjiongwendao@qq.com](mailto:chenjiongwendao@qq.com) | Blobstore ClusterMgr | [OPPO] |
| slasher ([@sejust](https://github.com/sejust)) | [mcq.sejust@gmail.com](mailto:mcq.sejust@gmail.com) | Blobstore Access, Cli | [OPPO] |
| Name | Email | Organization |
|------------------------------------------------------------------------|-----------------------------------------------------------------|--------------|
| Haifeng Liu ([@bladehliu](https://github.com/bladehliu)) | [bladehliu@qq.com](mailto:bladehliu@qq.com) | - |
| Weilong Guo ([@awzhgw](https://github.com/awzhgw)) | [guowl18702995996@gmail.com](mailto:guowl18702995996@gmail.com) | [JD.com] |
| Xiaochun He ([@xiaochunhe](https://github.com/xiaochunhe)) | [626148589@qq.com](mailto:626148589@qq.com) | [OPPO] |
| Mofei Zhang ([@mervinkid](https://github.com/mervinkid)) | [mofei2816@gmail.com](mailto:mofei2816@gmail.com) | [JD.com] |
| Liang Chang ([@leonrayang](https://github.com/leonrayang)) | [chl696@sina.com](mailto:chl696@sina.com) | [OPPO] |
# Maintainers
| Name | Email | Organization |
|------------------------------------------------------------------------|-----------------------------------------------------------------|--------------|
| Haifeng Liu ([@bladehliu](https://github.com/bladehliu)) | [bladehliu@qq.com](mailto:bladehliu@qq.com) | - |
| Weilong Guo ([@awzhgw](https://github.com/awzhgw)) | [guowl18702995996@gmail.com](mailto:guowl18702995996@gmail.com) | [JD.com] |
| Shuoran Liu ([@shuoranliu](https://github.com/shuoranliu)) | [shuoranliu@gmail.com](mailto:shuoranliu@gmail.com) | [BEIKE] |
| Xiaochun He ([@xiaochunhe](https://github.com/xiaochunhe)) | [626148589@qq.com](mailto:626148589@qq.com) | [OPPO] |
| Mofei Zhang ([@mervinkid](https://github.com/mervinkid)) | [mofei2816@gmail.com](mailto:mofei2816@gmail.com) | [JD.com] |
| Liang Chang ([@leonrayang](https://github.com/leonrayang)) | [chl696@sina.com](mailto:chl696@sina.com) | [OPPO] |
| Xuewei Zeng ([@Victor1319](https://github.com/Victor1319)) | [834863182@qq.com](mailto:834863182@qq.com) | [OPPO] |
| Dr. Wei Ding ([@wding109](https://github.com/wding109)) | [wding109@gmail.com](mailto:wding109@gmail.com) | [ByteDance] |
| Dr. Junyuan Zeng ([@jzeng4](https://github.com/jzeng4)) | [jzeng04@gmail.com](mailto:jzeng04@gmail.com) | [LinkedIn] |
| hooklee2000 ([@hooklee2000](https://github.com/hooklee2000)) | [hooklee2000@gmail.com](mailto:hooklee2000@gmail.com) | [XFusion] |
| Zhendong Li ([@lizhendong666](https://github.com/lizhendong666)) | [lizhendong666@gmail.com](mailto:lizhendong666@gmail.com) | [JD.com] |
| Xiaobo Yu ([@cessory](https://github.com/cessory)) | [yxbstorm@gmail.com](mailto:yxbstorm@gmail.com) | [OPPO] |
| Cloudstriff ([@Cloudstriff](https://github.com/Cloudstriff)) | [chenjiongwendao@qq.com](mailto:chenjiongwendao@qq.com) | [OPPO] |
| slasher ([@sejust](https://github.com/sejust)) | [mcq.sejust@gmail.com](mailto:mcq.sejust@gmail.com) | [OPPO] |
# Committers
| Name | Email | Duty | Organization |
|---------------------------------------------------------------------------------|------------------------------------------------------------------|------------------------------|--------------|
| Hongyan Wang ([@jadewang198510](https://github.com/jadewang198510)) | [741773046@qq.com](mailto:741773046@qq.com) | Data Storage | [OPPO] |
| Chi He([@bboyCH4](https://github.com/bboyCH4)) | [hechi1014@126.com](mailto:hechi1014@126.com) | Client | [OPPO] |
| Jianxing Zhao ([@znlstar](https://github.com/znlstar)) | [znlstar@163.com](mailto:znlstar@163.com) | Metadata | [JD.com] |
| Yong Sheng ([@shyodx](https://github.com/shyodx)) | [shengyong2021@gmail.com](mailto:shengyong2021@gmail.com) | Client, SDK, Metadata | [BEIKE] |
| Zhengyi Zhu ([@zhuzhengyi](https://github.com/wding109)) | [zhengyi.zhu.hust@gmail.com](mailto:zhengyi.zhu.hust@gmail.com) | Mointoring | [BEIKE] |
| Lei Yin ([@yinlei-jinan](https://github.com/yinlei-jinan) | [297155992@qq.com](mailto:297155992@qq.com) | Client, SDK | [JD.com] |
| Liying Zhang ([@Vivian7755](https://github.com/Vivian7755)) | [zly7755@163.com](mailto:zly7755@163.com) | Product Management | [JD.com] |
| Xihao Xu ([@xxscott](https://github.com/xxscott)) | [xxscott@163.com](mailto:xxscott@163.com) | CSI, Kubernetes | [JD.com] |
| Wenjia Wu ([@wenjia322](https://github.com/wenjia322)) | [buaa1214wwj@126.com](mailto:buaa1214wwj@126.com) | Authorization | [JD.com] |
| pengtianyue ([@pengtianyue025](https://github.com/pengtianyue025)) | [pengtianyue025@gmail.com](mailto:pengtianyue025@gmail.com) | Blobstore Scheduler | [ByteDance] |
| baijiaruo ([@baijiaruo](https://github.com/baijiaruo)) | [505892459@qq.com](mailto:505892459@qq.com) | Metadata | [China United Telecommunications Co] |
| Tianjiong Zhang ([@tianjiongzhang](https://github.com/tianjiongzhang)) | [236556116@qq.com](mailto:236556116@qq.com) | Client | [Sangfor] |
| Zongchao Hu ([@JasonHu520](https://github.com/JasonHu520)) | [hastyjason500@gmail.com](mailto:hastyjason500@gmail.com) | Blobstore Proxy | [OPPO] |
| Tianpeng Li ([@Skypigltp](https://github.com/skypigltp)) | [skypigltp@gmail.com](mailto:skypigltp@gmail.com) | Data Storage, Raft | [VIVO] |
| Hongyin Zhu ([@zhuhyc](https://github.com/zhuhyc)) | [zzhniy.163.niy@163.com](mailto:zzhniy.163.niy@163.com) | Resource Manager | [JD.com] |
| Zhixiang Tang ([@xiangcai1215](https://github.com/xiangcai1215)) | [505892459@qq.com](mailto:505892459@qq.com) | Blobstore ClusterMgr, Access | [Xiaohongshu]|
| Yubo Li ([@yuboLee](https://github.com/yuboLee)) | [pangbolee@gmail.com](mailto:pangbolee@gmail.com) | S3 | [JD.com] |
| Tao Li ([@tomscut](https://github.com/tomscut)) | [tomleescut@gmail.com](mailto:tomleescut@gmail.com) | Master, MetaNode , Blobstore | [BIGO] |
| Junhao Guo ([@M1eyu2018](https://github.com/M1eyu2018)) | [857037797@qq.com](mailto:857037797@qq.com) | Master, MetaNode, Client | [BIGO] |
| Bingxing Liu ([@liubingxing](https://github.com/liubingxing)) | [liubbingxing@gmail.com](mailto:liubbingxing@gmail.com) | Master, MetaNode, Client | [BIGO] |
| Xiang Li ([@lixiang](https://github.com/lixiang)) | [960754123@qq.com](mailto:960754123@qq.com) | Client | [Sangfor] |
| Qing Li ([@qingli](https://github.com/liqingqiya)) | [liqing.qiya@gmail.com](mailto:liqing.qiya@gmail.com) | Blobstore Blobnode | [ByteDance] |
| Zhihao Wang ([@Cresc](https://github.com/zhihao-wang)) | [wzh07@hotmail.com](mailto:liqing.qiya@gmail.com) | Blobstore Blobnode | [ByteDance] |
| NaturalSelect([@NaturalSelect](https://github.com/NaturalSelect)) | [2145973003@qq.com](mailto:2145973003@qq.com) | Master, MetaNode | [Chengdu University of Information Technology] |
| setcy ([@setcy](https://github.com/setcy)) | [asetcy@gmail.com](mailto:asetcy@gmail.com) | Master, Cli | [Hangzhou Dianzi University] |
| Shuqiang Zheng ([@shuqiang-zheng](https://github.com/shuqiang-zheng)) | [782879301@qq.com](mailto:782879301@qq.com) | Master, DataNode, Client | [OPPO] |
| Chuanqing Zhang ([@zhangchuanqing5658](https://github.com/zhangchuanqing5658)) | [zhang691753540@gmail.com](mailto:zhang691753540@gmail.com) | Master, Metanode, Client | [JD.com] |
| Name | Email | Organization |
|---------------------------------------------------------------------------------|------------------------------------------------------------------|--------------|
| Hongyan Wang ([@jadewang198510](https://github.com/jadewang198510)) | [741773046@qq.com](mailto:741773046@qq.com) | [OPPO] |
| Chi He ([bboyCH4](https://github.com/bboyCH4)) | [hechi1014@126.com](mailto:hechi1014@126.com) | [OPPO] |
| Jianxing Zhao ([@znlstar](https://github.com/znlstar)) | [znlstar@163.com](mailto:znlstar@163.com) | [JD.com] |
| Yong Sheng ([@shyodx](https://github.com/shyodx)) | [shengyong2021@gmail.com](mailto:shengyong2021@gmail.com) | [BEIKE] |
| Zhengyi Zhu ([@zhuzhengyi](https://github.com/wding109)) | [zhengyi.zhu.hust@gmail.com](mailto:zhengyi.zhu.hust@gmail.com) | [BEIKE] |
| Lei Yin ([@yinlei-jinan](https://github.com/yinlei-jinan)) | [297155992@qq.com](mailto:297155992@qq.com) | [JD.com] |
| Liying Zhang ([@Vivian7755](https://github.com/Vivian7755)) | [zly7755@163.com](mailto:zly7755@163.com) | [JD.com] |
| Xihao Xu ([@xxscott](https://github.com/xxscott)) | [xxscott@163.com](mailto:xxscott@163.com) | [JD.com] |
| Wenjia Wu ([@wenjia322](https://github.com/wenjia322)) | [buaa1214wwj@126.com](mailto:buaa1214wwj@126.com) | [JD.com] |
| pengtianyue ([@pengtianyue025](https://github.com/pengtianyue025)) | [pengtianyue025@gmail.com](mailto:pengtianyue025@gmail.com) | [ByteDance] |
| baijiaruo ([@baijiaruo](https://github.com/baijiaruo)) | [505892459@qq.com](mailto:505892459@qq.com) | [China United Telecommunications Co] |
| Tianjiong Zhang ([@tianjiongzhang](https://github.com/tianjiongzhang)) | [236556116@qq.com](mailto:236556116@qq.com) | [Sangfor] |
| Zongchao Hu ([@JasonHu520](https://github.com/JasonHu520)) | [hastyjason500@gmail.com](mailto:hastyjason500@gmail.com) | [OPPO] |
| Tianpeng Li ([@Skypigltp](https://github.com/skypigltp)) | [skypigltp@gmail.com](mailto:skypigltp@gmail.com) | [VIVO] |
| Hongyin Zhu ([@zhuhyc](https://github.com/zhuhyc)) | [zzhniy.163.niy@163.com](mailto:zzhniy.163.niy@163.com) | [JD.com] |
| Zhixiang Tang ([@xiangcai1215](https://github.com/xiangcai1215)) | [505892459@qq.com](mailto:505892459@qq.com) | [Xiaohongshu]|
| Yubo Li ([@yuboLee](https://github.com/yuboLee)) | [pangbolee@gmail.com](mailto:pangbolee@gmail.com) | [JD.com] |
| Tao Li ([@tomscut](https://github.com/tomscut)) | [tomleescut@gmail.com](mailto:tomleescut@gmail.com) | [BIGO] |
| Junhao Guo ([@M1eyu2018](https://github.com/M1eyu2018)) | [857037797@qq.com](mailto:857037797@qq.com) | [BIGO] |
| Bingxing Liu ([@liubingxing](https://github.com/liubingxing)) | [liubbingxing@gmail.com](mailto:liubbingxing@gmail.com) | [BIGO] |
| Xiang Li ([@lixiang](https://github.com/lixiang)) | [960754123@qq.com](mailto:960754123@qq.com) | [Sangfor] |
| Qing Li ([@qingli](https://github.com/liqingqiya)) | [liqing.qiya@gmail.com](mailto:liqing.qiya@gmail.com) | [ByteDance] |
| Zhihao Wang ([@Cresc](https://github.com/zhihao-wang)) | [wzh07@hotmail.com](mailto:liqing.qiya@gmail.com) | [ByteDance] |
| NaturalSelect ([@NaturalSelect](https://github.com/NaturalSelect)) | [2145973003@qq.com](mailto:2145973003@qq.com) | [Chengdu University of Information Technology] |
| setcy ([@setcy](https://github.com/setcy)) | [asetcy@gmail.com](mailto:asetcy@gmail.com) | [Hangzhou Dianzi University] |
| Shuqiang Zheng ([@shuqiang-zheng](https://github.com/shuqiang-zheng)) | [782879301@qq.com](mailto:782879301@qq.com) | [OPPO] |
| Chuanqing Zhang ([@zhangchuanqing5658](https://github.com/zhangchuanqing5658)) | [zhang691753540@gmail.com](mailto:zhang691753540@gmail.com) | [JD.com] |
[OPPO]: https://www.oppo.com/en/

6
OWNERS.md Normal file
View File

@ -0,0 +1,6 @@
code approvers:
- maintainers
code reviewers:
- contributors && maintainers
docs:
- sig-docs

16
README.md
View File

@ -53,11 +53,25 @@ Some key features of CubeFS include:
## Community
- Homepage: [cubefs.io](https://cubefs.io/)
- Mailing list: users@cubefs.groups.io
- Mailing list: users@cubefs.groups.io.
- Please subscribe on the page https://groups.io/g/cubefs-users/ or send your email to cubefs-users+subscribe@groups.io to apply.
- Slack: [cubefs.slack.com](https://cubefs.slack.com/)
- WeChat: detail see [here](https://github.com/cubefs/cubefs/issues/604)
- Twitter: [cubefs_storage](https://twitter.com/cubefs_storage)
## Governance
[Governance documentation](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md) plays a crucial role in establishing clear guidelines, procedures, and structures within an organization or project
## Contribute
[Contributing to CubeFS](https://github.com/cubefs/cubefs/blob/master/CONTRIBUTING.md)
There is a clear definition of roles and their promotion paths.
- [Becoming a Maintainer](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#becoming-a-maintainer)
- [Becoming a committer](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#becoming-a-committer)
- [Becoming a TSC Member](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#becoming-a-tsc-member)
## Partners and Users
There is the list of users and success stories [ADOPTERS.md](ADOPTERS.md).

2
SECURITY.md
View File

@ -6,7 +6,7 @@ Join the [security@cubefs.groups.io](mailto:security@cubefs.groups.io) group for
We’re extremely grateful for security researchers and users that report vulnerabilities to the CubeFS Open Source Community. All reports are thoroughly investigated by a dedicated committee of community volunteers called [Product Security Committee](./security/security-release-process.md#product-security-committee).
To make a report, please email the private [security@cubefs.groups.io](mailto:security@cubefs.groups.io) list with the security details and the details expected for [all CubeFS bug reports](https://github.com/cubefs/cubefs/blob/master/CONTRIBUTING.md#bug-reports).Note: (Groups.io requires users to subscribe to relevant email groups before sending emails. This is to ensure that only group members can send and receive emails within the group, maintaining the security and privacy of the group. Therefore, according to Groups.io's regulations, you need to subscribe to an email group before being able to send emails)
To make a report, please email the private [cubefs-security-report@groups.io](mailto:cubefs-security-report@groups.io) list with the security details and the details expected for [all CubeFS bug reports](https://github.com/cubefs/cubefs/blob/master/CONTRIBUTING.md#bug-reports).Note
### When Should I Report a Vulnerability?

16
security/security-release-process.md
View File

@ -12,9 +12,7 @@ The initial PSC will consist of volunteers who have been involved in the initial
- Xiaochun He (**[@xiaochunhe](https://github.com/xiaochunhe)**)
- Liang Chang (**[@leonrayang](https://github.com/leonrayang)**)
- Yao Hu (**[@baijiaruo](https://github.com/baijiaruo)**)
- Weilong Guo (**[@awzhgw](https://github.com/awzhgw)**)
- Liying Zhang (**[@Vivian7755](https://github.com/Vivian7755)**)
- Mofei Zhang (**[@mervinkid](https://github.com/mervinkid)**)
The PSC members will share various tasks as listed below:
@ -32,9 +30,11 @@ Contact the team by sending email to [security@cubefs.groups.io](mailto:security
#### Joining
The PSC should be consist of 2-4 members. New potential members to the PSC can express their interest to the PSC members. These individuals can be nominated by PSC members or CubeFS maintainers.
If representation changes due to job shifts then PSC members are encouraged to grow the team or replace themselves through mentoring new members.
- The PSC should be consist of 2-4 members. New potential members to the PSC can express their interest to the PSC members.
- These individuals can be nominated by PSC members or CubeFS maintainers by opening a PR or using the internal email group. The steering committee will review the proposal by majority vote.
- If representation changes due to job shifts then PSC members are encouraged to grow the team or replace themselves through mentoring new members.
- PSC members should come from more than two vendors, with each vendor having no more than two members.
- PSC members typically do not have a term of duty.
##### Product Security Committee Lazy Consensus Selection
@ -42,7 +42,11 @@ Selection of new members will be done by lazy consensus amongst members for addi
#### Stepping Down
Members may step down at any time and propose a replacement from existing active contributors of CubeFS.
- Members may step down at any time and propose a replacement from existing active contributors of CubeFS.
- Members may step down if they cannot fulfill their responsibilities.
In such a case:A PR is required to move the person in question from the member list. The person in question must be mentioned in the body of the PR.
The steering committee will review the proposal by majority votes.This acts as a final contact attempt so that they can provide their feedback.
#### Responsibilities