Taro 贡献者晋级制度
为了建立更加完善、更加可持续的 Taro 开源生态，突出贡献者价值，我们参照成熟开源社区运行机制制定了《 Taro 贡献者晋级制度》，为热爱和喜欢 Taro 技术的开发者和贡献者提供更清晰的参与机制和荣誉激励机制。
晋升角色
![]()
如图包含 4 个晋升角色：个人贡献者&生态个人贡献者、助手、合作者&生态合作者、技术委员会委员，晋升机制通过提名+投票的方式进行共识决策，晋升路径如下：
- 个人贡献者 → 助手 → 合作者 → 技术委员会委员
- 个人贡献者 → 合作者 → 技术委员会委员
- 生态个人贡献者 → 生态合作者 → 技术委员会委员
对于一年内不活跃者，会进行自动进行降级，贡献突出者可申请荣休。
个人贡献者&生态个人贡献者（Individual Committer）
任何同意《 Taro 行为准则》的个人开发者，都可以基于《贡献者指南》进行 pull request 提交， bug 反馈&修复、新特性提议或 PR 均可，会在 Taro 官方文档中列为个人贡献者。当贡献者的有价值工作被其他合作者注意到后，可以被提名为合作者。
任何基于或围绕 Taro 生态进行的工具、插件、培训、教程等个人都会在 Taro 官方文档中列为生态个人贡献者。
助手（Triage）
负责 NervJS/taro、NervJS/taro-ui 仓库新 issues 的维护，负责给 issues 或 pull requests 打标签，以及负责评论、关闭和重新开启 issue 或 pull request，负责将 bug 或 feature 分流给具体工作组。
- 目的 旨在减少 issue 列表，保持 issue 及时跟踪，促进新人参与及贡献 pull request。
- 权益 Github NervJS 组 Member 权限，相关项目 Triage 权限，可以管理 issues 和 pull requests（没有写权限）。
- 申请方法 对 Taro 项目有全面了解和深度开发经验的任何人，可以在 NervJS/taro README.md 中提交一个 pull request，说明申请成为助手的动机并同意本项目的行为守则，经 2 名合作者同意即可通过。 申请 pull request 参考模版如下：
![]()
- 退出机制 对 6 个月不活跃的小助手进行定期移除。
合作者 & 生态合作者（Collaborator）
负责维护 NervJS/taro、NervJS/taro-ui 仓库，帮助用户和初级贡献者，参加具体工作组为当前项目贡献代码和文档，评审和评论 issues 和 pull requests。
- 目的 旨在不断丰富 Taro 特性、性能、安全等。
- 权益 Github NervJS 组 Member 权限，Github Write 权限，可以提交 commit 到 NervJS/taro 仓库，可以配置持续集成任务，负责 pull request 评审及合并，1 个 PR 合并需至少 2 名合作者或 1 名技术委员会成员同意即可进入观察期，观察期 3 个月即可正式成为合作者。
- 申请方法 合作者提名有突出贡献的个人贡献者，通过投票机制决定是否可以成为合作者。一名合格的合作者需具备：技术精进，业务精湛；沟通无障碍，至少读写无阻碍；人品优良，能钻研，不轻易半途而废；态度谦逊，能接受他人意见；Owner 心态，积极主动。 申请 pull request 参考模版如下：
![]()
- 退出机制 对不活跃的合作者，技术委员会有权进行移除或设置为荣休状态，荣休成员可以重新向技术委员会申请为活跃状态。如果一个合作者超过 6 个月无任何贡献，会自动设置成荣休状态。
技术委员会成员（Technical Steering Committee）
负责技术方向、项目管理、项目发布、贡献政策、仓库托管、行为准则、维护合作者列表，定期参加 TSC 活动，主席（主持人）会在线上主持活动，并做好活动记录并公布。
- 目的 解决难以达成共识的技术难题、新方向等。
- 权益 Github NervJS 组 Owner 权限。
- 申请方法 新增 TSC 成员需要由其他 TSC 成员提名并讨论投票。 申请 pull request 参考模版如下：
![]()
- 退出机制 在一季度内，缺席 75%的活动，且未参与任何一次投票，自动除名。成员可提出暂时”荣休“。
运行机制
![]()
如图运行机制包含技术委员会以及下设的 5 个团队（Core 团队、Plugins 团队、Platform 团队、创新团队、社区团队）。技术委员会由技术委员会委员组成，负责技术方向、项目管理、贡献政策、仓库托管、行为准则、维护合作者列表等，技术委员会主席负责定期组织会议。工作组由合作者成员组成，每个方向有一个 Owner，负责相关工作组的开发进展。
团队
- Core 团队
- Cli 工作组 主要负责 Taro 命令行工具的开发和维护工作。
- Compile 工作组 负责维护、优化小程序和 H5 的编译系统。
- Runtime 工作组 负责维护小程序运行时系统。
- Plugin 团队 负责维护各 Taro 插件，包括端平台插件，React、Vue DevTools 等。
- 端平台插件工作组 负责维护各端平台插件，包括对微信、支付宝、百度、字节跳动、QQ、京东、企业微信、飞书、快手、钉钉、小红书等厂商小程序的适配等。
- 混合开发组 负责维护 Taro 与原生小程序的相互调用功能、Taro 开发原生插件等。
- Platform 团队 负责 App、Web、Open Harmony 等跨平台开发。
- H5 工作组 负责维护 H5 的各模块，包括路由、组件库、API 库等。
- React Native 工作组 负责 React Native 适配核心、组件库、API 库等部分的开发。
- Open Harmony 工作组 负责鸿蒙适配核心、组件库、API 库等部分的开发。
- 快应用工作组
- 创新团队 Taro 创新特新、新方向探索，如 wasm、rust、vite、flutter、electron 等。
- UI 框架兴趣组 TaroUI、NutUI 等 UI 库和其他类型生态工具的研发与管理。
- 社区团队 负责 Taro 生态与运营，和 Taro 社区的运营推广工作。
技术委员会双周会
- 时间：每双周周四前，在 TSC issue 中预告下次会议的内容和日期。
- 议题：来自 Taro 下各项目中标注了 tsc-agenda 标签的事宜。会议结束后提交会议纪要 pull request。每次会议可邀请非委会参加，但无投票权。
基于共识决策的投票机制
各个晋升投票环节，基于共识决策原则，原则上达成多数一致。
- 待投票的议题需要在会议前周知各成员，给与成员足够调研思考时间
- 议题在即将达成一致时，在结题前必须询问“有人反对吗？”，以周知最后反对的机会
- 议题无法达成一致时，可以投票多数支持是否延期到下一个会议，否则必须继续讨论
- 议题满足“多数胜利”后即可通过，成员可以弃票
引导 / 培训机制
助手、合作者和技术委员会成员每个阶段，均提供相应的引导和培训，让新晋升者可以快速开展工作。
角色成员点击下面查看更多：
