7.6 KiB
7.6 KiB
SIG孵化项目毕业评审组织
简体中文 | English
- SIG孵化项目成熟并满足项目毕业要求后，可申请合入OpenHarmony组织代码主库。
- SIG Leader通过向dev@openharmony.io发送邮件，提交孵化项目毕业申请，请按照表格内容填写议题。
- QA SIG组组织孵化项目准出，发布评审纪要并归档
参加人：
| 角色 | 参加人 | 联系方式 |
|---|---|---|
| PMC | 董金光 | dongjinguang |
| PMC | 梁克雷 | xzmu |
| PMC | 黄明龙 | minglonghuang |
| 架构 SIG | 任革林 | im-off-this-week |
| 安全 | 张阿东 | zhangadong |
| 测试 SIG | 聂欣 | nie-x |
| 测试 SIG | 王俊涛 | wangjuntao |
| 基础设施SIG | 王意明 | youthdragon |
| API SIG | 张勇智 | zhangyognzhi |
| 编译框架SIG | 王兴 | wangxing |
| 合规代表 | 陈雅旬 | jalenchen |
| 运营代表 | 刘果 | guoguoliu |
| QA SIG | 邢文华 | xhuazi |
| 孵化项目负责人 | ||
| 孵化项目相关SIG组 |
SIG孵化项目毕业评审检查项：
| 大类 | 子类 | 要求 | 审查方式 | 审查方式 |
|---|---|---|---|---|
| 基础 | 资料 | 项目首页简明扼要地描述本项目的功能，并显示项目的孵化状态。 | 工具+人工：通过社区OAT工具门禁，检查README文档命名及归档位置；人工检查README文档内容是否清晰描述本项目的功能 | DOC SIG |
| 基础 | 资料 | 项目在清晰的位置提供构建本项目的指导文档。 | 人工：检查README是否包含构建指导 | DOC SIG |
| 基础 | 资料 | 项目在清晰的位置提供本项目的对外接口文档，如果该项目可供最终用户直接使用，需要提供对应的用户指南。 | 人工：检查是否包含对外API文档及用户指南 | DOC SIG |
| 基础 | 资料 | 提供英文文档，并能处理反馈的英文问题。 | 人工：检查英文资料以及Issue中英文问题的答复 | DOC SIG |
| 法务 | 知识产权 | 项目的所有源码必须包含许可头与版权声明。 | 工具：通过社区OAT工具门禁，检查项目所有文件是否包含正确的许可头与版权头 | QA SIG |
| 法务 | 知识产权 | 项目新开发代码为独立自主开发,当提交第三方贡献时，提交备注中要包含可靠的代码来源信息 | 工具：通过社区FOSSSCAN门禁扫描自研代码，不存在三方代码片断 | QA SIG |
| 法务 | 知识产权 | 项目Committer都签署DCO协议 | 工具+人工：工具检测代码提交者是否签署DCO，人工审核DCO协议签署 | QA SIG |
| 法务 | 许可证 | 项目包含的许可证为OSI批准的，且其许可证及其依赖软件的许可证不会比OpenHarmony项目的许可证添加更多的限制。 | 工具+人工：通过社区OAT工具门禁，检查项目的许可证兼容性，如果存在问题人工与律师确认 | QA SIG |
| 法务 | 许可证 | 项目依赖的库必须是开源软件，可公开获得。 | 工具+人工：通过社区FOSSSCAN门禁扫描三方代码匹配度，人工确认是否是开源软件 | QA SIG |
| 法务 | 许可证 | 项目的许可证文件在项目仓库中的标准位置并且命名符合社区规范。 | 工具：通过社区OAT工具门禁，检查项目的LICENSE文件 | QA SIG |
| 项目运作 | 问题响应 | 项目必须提供Issues跟踪所有问题，并对登记的issue应进行合理的分类、分级。 | 人工：审核Issues清单 | SIG Owner |
| 项目运作 | 问题响应 | 项目必须响应过去2~12个月的大多数Issues（>80%)。 | 工具+人工：社区Issue平台统计问题关闭情况，人工审核 | SIG Owner |
| 项目运作 | 问题响应 | 项目在过去6个月收到的本项目涉及的三方软件的任何漏洞报告的初始响应时间必须小于或等于14天。 | 人工：审核漏洞报告的响应记录 | SIG Owner |
| 协作 | 文化 | 项目维护一个具备决策权的贡献者的公开列表，项目的所有重要讨论都以书面方式记录在项目的正式沟通渠道上，对于讨论不充分或意见不完全一致的问题，基于社区公开的投票规则建立共识。 | 人工：审核项目会议纪要 | SIG Owner |
| 质量 | 可构建 | 项目必须支持从源代码构建出可工作的系统，且应该仅使用业界可公开获得的构建工具。 | 工具+人工：参考构建指导即可快速完成自动化构建 | CompileRuntime SIG |
| 质量 | 可构建 | 支持与社区现有工具链集成。 | 人工：审核CI构建结果 | QA SIG |
| 质量 | 可测试 | 项目必须提供完备的测试用例，覆盖大部分逻辑分支及所有外部接口，且支持OpenHarmony社区测试套件实现构建自动测试。 | 工具：自动化测试套件，覆盖率>85% | Test SIG |
| 质量 | 兼容性 | 项目高度重视后向兼容，明确记录了任何不兼容的变更，并提供工具和文档帮助用户升级。 | 工具：自动化测试套件 | Test SIG |
| 质量 | 代码 | 项目编码必须满足社区编码规范，通过社区代码质量扫描。 | 工具：通过社区代码基础质量门禁 | QA SIG |
| 配置管理 | 变更控制 | 项目的源代码库必须记录所有的变更，包括什么人什么时候修改了什么，所有代码必须明确记录其来源，对于贡献者的提交要详细记录其代码来源信息。 | 人工：人工审核代码变更日志 | QA SIG |
| 配置管理 | 版本说明 | 项目发布的版本都必须提供清晰明了的版本变更说明，明确升级带来什么影响，以便用户决定是否升级。如涉及安全漏洞修复，须明确列举修改了哪些公开的漏洞。 | 人工：审核RELEASE NOTES | DOC SIG |
| 配置管理 | 版本签名 | 项目发布的版本需要进行数字签名或带有哈希摘要，以校验下载包的完整可靠 | 工具+人工：参考指导生成哈希值并与发布的哈希值对比 | Infrastructure SIG |
| 配置管理 | 版本签名 | 发布要包含源代码，分发时需要采用标准开放的打包格式，以便长期保持可读性 | 人工：审核发布包内容 | Infrastructure SIG |
| 配置管理 | 版本签名 | 项目的发布过程是文档化的，且可重复发布生成一致的发布包。 | 工具+人工：参考指导生成哈希值并与发布的哈希值对比 | Infrastructure SIG |
| 质量 | 安全 | 项目使用的加密算法必须是安全的、公开的加密算法及协议，不得使用已被破解的加密算法及协议。 | 工具：安全扫描工具 | Security SIG |
| 质量 | 安全 | 项目必须使用密码学安全的随机数生成器生成所有加密密钥和随机数，并且不得使用密码学不安全的生成器 | 工具：安全扫描工具 | Security SIG |
| 质量 | 安全 | 项目被公开超过60天的中等或更高严重程度的漏洞必须被修复，所有致命漏洞必须完成修复。 | 工具：安全扫描工具 | Security SIG |