openFuyao社区新功能开发流程规范
1. 概述
本文档描述了openFuyao社区在增加新功能时,从提案提交到最终代码合入的全过程。社区采用分层决策机制,提案需经过sig组决定评审路径。
2. 版本规划
本阶段旨在通过系统化的需求识别、评估与规划,将社区需求有序地纳入特定开发版本,确保项目发展路线清晰、资源分配合理,并为后续开发工作提供明确的目标和实现框架。
2.1 需求识别
- 新功能或改进需求首先在相关的SIG组内部被识别和讨论。
- SIG组对需求的合理性、价值和技术可行性进行初步评估。
2.2 需求登记
创建需求ISSUE
- 在release-management仓库创建需求类型的ISSUE
版本规划例会
- 在release-management例会中评审需求是否接纳
- 根据项目路线图和资源情况确定落地版本
- 记录版本规划与决策
2.3 需求状态跟踪
RM SIG跟踪当前版本需求的实现进度:
- 技术方案是否通过TC评审
- 需求是否可以按时完成
- 需求落地条件是否满足
- 详细请参考RM SIG和QA SIG的相关执行标准
3. 提案流程
本阶段规范了新功能或重大改进的提案提交与初步决策流程,确保所有变更在实施前均经过充分思考,为后续的技术评审奠定基础。
3.1 提案提交
- 在ofep仓库创建新的提案文档PR
- 使用模板编写提案内容
- 提案应包含:背景、目标、设计方案、影响评估等关键信息
3.2 提案评审路径决策
在提交提案后,需要咨询相关SIG的Maintainer,确定评审路径。
4. 评审流程
本阶段通过SIG组内评审与TC例会分层决策机制对提案的技术方案进行评估,SIG组内部评审后根据实际情况决定是否上升至TC例会评审,确保其技术合理性、架构一致性及社区价值。
4.1 SIG组内评审
会前准备
- 提案提交者提前与SIG Maintainer沟通,并将相关信息添加至SIG例会日程中
SIG 内部评审
- 在相关SIG组内进行技术评审
- SIG Maintainer负责组织评审并做出决策
- 评审通过后由SIG Maintainer确认技术方案达成共识,并开启后续开发流程
上升到TC例会评审
- 重大架构调整
- 多SIG组协作问题
- 需求方认为需要上升到TC例会进行评审决策
- TC要求的需要上会决策项
4.2 TC例会评审
会前准备
- 提案提交者提前在etherpad登记议题
TC例会评审
- 在TC例会上进行方案讲解并讨论需求是否接纳
- TC成员对提案进行评审和投票
- 记录评审意见和决策结果
评审结果
- 通过:进入后续流程
- 修改:根据反馈修改后重新评审
- 拒绝:终止流程,归档提案
5. 开发流程
本阶段指导开发者基于已通过的提案进行实际的代码开发与协作,通过规范的代码提交、评审和测试验证流程,确保代码质量、功能正确性以及与社区标准的一致性。开发详细步骤请参考此博客:openFuyao开源社区入门经验分享
5.1 代码开发
开发准备
- Fork上游仓库
- 在本地基于目标版本分支创建开发分支
- 遵循社区代码规范进行开发
PR提交
- 开发完成后提交PR
- 按照PR模板要求填写相关信息
- 关联相关ISSUE和提案
5.2 代码评审
SIG 组内评审
- 相关SIG的Maintainer和Committer进行代码评审
- 确保代码质量符合社区规范要求
测试验证
- 通过CI/CD流水线自动化测试,一般包括镜像构建检查、代码CodeCheck扫描、代码片段引用扫描等
- 必要时进行手动验证和集成测试
6. 合入与发布
本阶段旨在将已通过评审和测试的代码安全、规范地合入代码库,并经过最终的质量确认后,按照社区标准流程完成版本发布,确保新功能稳定、可靠地交付给社区用户。
6.1 代码合入
- 评审通过后由Maintainer合入代码
- 合入到规划的目标版本分支
6.2 需求完成确认
- 当代码合入、相关测试和文档工作全部完成后,该需求的状态将被提交至RM例会进行最终评审
- RM SIG根据QA SIG给的结论确认需求是否满足发布条件
6.3 版本发布
- 按照社区发布流程进行版本发布
- 更新相关文档和发布说明
7. 注意事项
沟通协作
- 及时在相关社区频道同步进展
- 重要决策在邮件列表中进行沟通
文档维护
- 及时更新相关设计文档和用户文档
- 保证文档与代码实现的一致性和可追溯性
变更管理
- 如果开发过程中需要变更设计方案,需要评估变更带来的影响
- 重大变更(如安全方面、不同SIG间协作等)需要在对应SIG例会上进行交流和决策,并重新进行需求评审流程
8. 联系信息
本文档会根据社区发展持续更新,最新版本请以社区官网文档为准。
本文由openFuyao社区首发,欢迎遵照CC-BY-SA 4.0协议规定转载。
