Development Team
Development Team
This page shows the development team members of Spring Cloud Alibaba. We are constantly expanding. Welcome to join the community.
Steering Committee Member
| Name | Github ID | Role | Company | |
|---|---|---|---|---|
| Jian Fang | fangjian0423 | Steering Committee Member | fangjian0423@gmail.com | Zoom |
| Jing Xiao | flystar32 | Steering Committee Member | flystar32@163.com | Alibaba |
| Xinxi Ma | mercyblitz | Steering Committee Member | mercyblitz@gmail.com | Freelance |
| Haojun Ren | HaojunRen | Steering Committee Member | 1394997@qq.com | Nepxion Community |
| Xi Chen | theonefx | Steering Committee Member | chenxilzx1@gmail.com | Alibaba |
| Zihao Rao | steverao | Steering Committee Member | zihaorao@126.com | Alibaba |
Committer
| Name | Github ID | Role | Company | |
|---|---|---|---|---|
| Chuntao Liao | chuntaojun | Committer | liaochuntao@live.com | Tencent |
| Huangbin Yu | yuhuangbin | Committer | danielyu96@163.com | ~ |
| Yihao Zhao | sczyh30 | Committer | sczyh16@gmail.com | Alibaba |
| Kaizhao Zhang | zkzlx | Committer | kiss_maple@163.com | Poizon |
| Liangwen Liu | DanielLiu1123 | Committer | llw599502537@gmail.com | Shenzhen Mengshi Technology Co., Ltd. |
| Lengleng | lltx | Committer | wangiegie@gmail.com | ~ |
| echooymxq | echooymxq | Committer | echooy.mxq@gmail.com | ~ |
| Xingyuan Cheng | complone | Committer | yuluoxinsheng@gmail.com | ~ |
| Sheng Ruan | ruansheng8 | Committer | chrisruans@gmail.com | ZoeSoft |
| Ziming Liu | 123liuziming | Committer | 448918299@qq.com | Graduate student at Peking University |
| Shiwen Ji | yuluo-yx | Committer | karashouk.pan@gmail.com | ~ |
| XiaoweiXu | xuxiaowei-com-cn | Committer | xuxiaowei@xuxiaowei.com.cn | ~ |
Community Roles and Promotion Mechanism
The Spring Cloud Alibaba community includes four roles: Contributor, Committer, Maintainer, and Steering Committee Member. Each role carries different responsibilities and permissions, and promotion is based on sustained contribution, community trust, and an open process.
Principles
The Spring Cloud Alibaba community is governed by the following principles:
- Merit and trust: roles are earned through sustained contribution, sound judgment, and trust from the community;
- Responsibility before privilege: additional permissions are granted to enable service to the project, not as a title or reward;
- Contributions beyond code: code, reviews, issue triage, design discussion, release work, documentation, examples, user support, community operations, and mentoring are all valued;
- Transparency: role changes should be proposed, discussed, and recorded in an open and auditable way;
- Reversibility: elevated roles may be adjusted when members become inactive, step down, or violate community standards;
- Respect: all participants are expected to follow the community code of conduct.
Community Roles
Contributor
A Contributor is any individual who has made a meaningful contribution to the project.
The baseline for becoming a Contributor is:
- submitting a pull request that is merged;
The community also values many other forms of contribution, including issue reporting, documentation, examples, tests, reviews, and user support. These contributions should be recognized in promotion decisions.
Contributors are encouraged to continue participating in reviews, discussions, and community activities.
Committer
A Committer is a trusted community member with repository write access who can merge pull requests and help maintain project quality.
Typical expectations for becoming a Committer:
- make sustained issue and pull request contributions over a long period;
- make important feature contributions to the community;
- participate in issue list maintenance, discussion of important features, community meetings, community sharing, and other community activities;
- participate in code review.
The Steering Committee may also consider practical signals such as:
- a sustained record of substantive pull requests and reviews;
- healthy collaboration, communication, and technical judgment;
- evidence of module familiarity, mentoring, or release support.
Typical responsibilities of a Committer:
- merge pull requests that meet project quality standards;
- participate in review, triage, and technical discussion on an ongoing basis;
- help enforce project conventions, backward compatibility expectations, and testing standards;
- help onboard new contributors and support potential Committer growth.
Committer approval process:
- nomination should be initiated by a Steering Committee Member; a Maintainer may recommend a candidate to the Steering Committee;
- the nomination should be posted publicly and remain open for at least 7 days;
- the nomination should include evidence of sustained contributions, reviews, and community participation;
- election requires no fewer than 3 affirmative votes from the Steering Committee.
Maintainer
A Maintainer is responsible for a module, subsystem, or key area. A Maintainer is normally also a Committer and serves as the day-to-day owner of a subsystem, integration, or cross-cutting capability.
Typical expectations for becoming a Maintainer:
- served effectively as a Committer for at least 6 months;
- sustained ownership of at least 1 module, subsystem, or cross-cutting area;
- a strong record of reviews, design leadership, and issue resolution in the last 12 months;
- demonstrated mentoring of Contributors or Committers;
- willingness to take responsibility for release readiness, backlog health, and module direction.
Typical responsibilities of a Maintainer:
- set module direction and make final calls when consensus cannot be reached at the module level;
- maintain review responsiveness and quality expectations for their area;
- coordinate significant design changes, deprecations, and compatibility decisions;
- help identify and develop future Committers and Maintainer candidates;
- participate in repository permission configuration when needed as the module owner.
Maintainer approval process:
- nomination must be proposed by at least 2 Maintainers, or at least 1 Steering Committee Member;
- the nomination should be posted publicly and remain open for at least 7 days;
- election requires approval from more than half of the active Steering Committee Members.
Steering Committee Member
The Steering Committee is responsible for cross-project technical governance, community process, major role appointments, and dispute resolution.
Typical expectations for becoming a Steering Committee Member include:
- completing the design and development of multiple key modules or projects and being a core developer of the project;
- showing sustained investment and passion, and actively participating in community, website, issue, pull request, and related maintenance work;
- having visible influence in the community and being able to represent Spring Cloud Alibaba in important community meetings and activities;
- having the awareness and ability to cultivate Committers and Contributors.
Steering Committee Members are normally selected from senior Committers, typically those who have already demonstrated Maintainer-level ownership and cross-project impact.
Typical responsibilities of a Steering Committee Member:
- define and evolve governance policy and community process;
- approve Committer, Maintainer, and Steering Committee nominations;
- resolve escalated cross-module disputes or priority conflicts;
- help represent the project in the broader open source ecosystem;
- maintain a healthy, diverse, and sustainable community.
Steering Committee approval process:
- nominations should normally come from active Steering Committee Members;
- the nomination should be discussed openly where appropriate;
- election requires approval from more than half of the active Steering Committee Members.
Promotion Rules
The following rules apply to all role promotions:
- role decisions should be based on sustained contribution over time rather than a single large pull request or event;
- numerical criteria are guidelines, not a substitute for judgment;
- non-code contributions must be considered alongside code contributions;
- the candidate’s employer, affiliation, or commercial background must not be a deciding factor;
- candidates should be informed before a nomination is made public and may decline the nomination;
- a nominee must not vote on their own promotion.
Activity, Inactive Status, and Emeritus Status
Meaningful activity includes code contributions, reviews, issue triage, design discussion, release work, mentoring, community meetings, and other visible project maintenance work.
Activity expectations:
- Committers, Maintainers, and Steering Committee Members who have no meaningful activity for 12 consecutive months may be marked inactive;
- Members who remain inactive for an extended period, normally 18 months, may be moved to Emeritus status by the Steering Committee.
Emeritus status:
- recognizes historical service to the project;
- does not include routine merge, approval, or governance responsibilities;
- may be reactivated through a lightweight review by the body that owns the role.
Members are always welcome to step down voluntarily. Voluntary transitions should be respected and recorded publicly.
Removal and Role Adjustment
Roles may be removed or adjusted when a member:
- requests to step down;
- becomes inactive for an extended period;
- repeatedly fails to meet role responsibilities;
- seriously violates the code of conduct or abuses project permissions.
Except in urgent situations involving safety or abuse, removal or downgrade of Committer, Maintainer, or Steering Committee roles should be discussed by the Steering Committee and recorded publicly.
Repository Permissions and Role Mapping
Community roles and repository permissions are related, but they are not identical.
Recommended mapping:
- Contributor: default repository access;
- Committer: repository write access;
- Maintainer: repository write or maintain access and responsibility as a module owner;
- Steering Committee Member: governance role; repository admin access should be granted only when operationally necessary.
Where practical, the project should maintain module ownership through CODEOWNERS or an equivalent public ownership mechanism. Committer, Maintainer, and Steering Committee rosters should be published and kept current.
Amendments
This document may be updated by the Steering Committee through public discussion and approval. Material changes should be announced to the community before they take effect.