开发者如何参与贡献——从SIG参与到核心维护者的完整路径

开发者如何参与贡献——从SIG参与到核心维护者的完整路径

前言

截至2025年11月，Harmony开源项目代码量已超1.3亿行，开发者数量突破800万，形成了完整的开源贡献体系。社区共有51家共建单位，累计超过6200名贡献者产生24.2万多个PR，59个SIG（特别兴趣小组）活跃在各个技术领域。深开鸿作为核心共建单位，累计贡献代码超百万行，主导4个SIG，参与12个SIG共建。

这些数字背后，是一个怎样的社区治理模型在支撑？作为普通开发者，如何从零开始参与贡献？代码提交后经历了怎样的评审流程？又如何从Contributor成长为Committer乃至Maintainer？

本文将基于OpenHarmony官方治理文档、核心共建单位的实践经验以及社区贡献者的真实案例，系统梳理OpenHarmony社区治理模式，为想要参与开源贡献的开发者提供一份完整的行动指南。

第一部分：OpenHarmony社区治理架构

1.1 项目群定位与愿景

OpenHarmony项目群的愿景是打造一个开放的、全球化的、创新且领先的面向多智能终端、全场景的分布式操作系统，构筑可持续发展的开源生态系统。其使命是托管操作系统技术和架构的核心代码及组件，以开放治理的方式聚合各类开发者，持续发展代码使用者和共建者。

1.2 组织架构全景图

OpenHarmony项目群的组织架构采用多层治理结构，确保决策的科学性和执行的效率性：

┌─────────────────────────────────────────────────────────┐ │ 工作委员会（Board） │ │ （重大事项投票决策，一家单位一票） │ └─────────────────────────────────────────────────────────┘ │ ┌─────────────────────┼─────────────────────┐ ▼ ▼ ▼ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ 技术指导委员会 │ │ 项目管理委员会 │ │ 生态委员会 │ │ (TSC) │ │ (PMC) │ │ │ │ 技术方向决策 │ │ 版本计划与发布 │ │ 生态建设与推广 │ └───────────────┘ └───────────────┘ └───────────────┘ │ ▼ ┌─────────────────┐ │ SIG特别兴趣小组 │ │ （技术领域实体单位）│ └─────────────────┘

1.2.1 工作委员会（Board）

工作委员会由捐赠人、学术机构和非营利组织以及其他组织或个人构成。重大事项由工作委员会各成员单位代表用投票方式共同决定，投票权利均等，一家单位一票，遵循公开明确的项目群管理制度规则。

1.2.2 技术指导委员会（TSC）

技术指导委员会负责技术方向的指导和决策，是解决复杂技术问题的关键组织。TSC从全局视角审视技术架构的合理性，确保各SIG的技术演进方向与整体规划一致。

1.2.3 项目管理委员会（PMC）

PMC项目管理委员会负责版本计划制定和发布管理。版本决策遵循明确及公开的项目群管理制度，路标和版本计划由PMC决定，讨论过程公开透明。SIG需要定期向PMC汇报进展，PMC基于SIG运作情况给出指导建议。

1.3 决策机制

OpenHarmony社区的决策机制强调公开、透明、共识：

• 版本决策：路标和版本计划由PMC决定，讨论过程在邮件列表和例会中公开进行
• 技术决策：各SIG负责领域内的技术决策，重大变更需提交PMC审议
• API变更决策：API新增、变更、废弃需遵循严格的评审流程，由Committer、Maintainer、SIG分层评审

第二部分：SIG工作机制与参与路径

2.1 什么是SIG？

SIG全称Special Interest Group，即特别兴趣小组，是OpenHarmony社区贡献的基本单位。SIG在PMC项目管理委员会指导下，负责OpenHarmony社区特定子领域及创新项目的架构设计、开源开发及项目维护等工作。

截至2023年10月，OpenHarmony社区共有59个SIG，覆盖从内核、驱动、分布式软总线到ArkUI、图形图像等各个技术领域。

2.2 SIG的职责与运作方式

2.2.1 SIG的核心职责

1. 技术演进方向引领：负责领域技术竞争力分析和关键技术识别及决策
2. 架构设计与维护：负责领域内功能分解分配，模块间接口定义与维护管理
3. 开源开发组织：社区的工作实体是SIG组，从基础设施到OS部件，从测试系统到版本发布都是由不同SIG承担
4. 持续运作保障：SIG组需要通过周期例会来保持其有效运作，并定期向PMC委员会汇报进展

2.2.2 SIG的组织结构

每个SIG通常包含以下角色：

2.3 参与SIG的两种方式

开发者参与SIG贡献有两种主要路径：加入已有SIG和主导成立新SIG。

2.3.1 加入已有SIG

第一步：找到感兴趣的SIG

开发者可通过SIG列表查看感兴趣的SIG。OpenHarmony社区在community仓库维护了完整的SIG列表（https://gitee.com/openharmony/community/tree/master/sig）。

第二步：了解SIG动态

• 订阅邮件列表：通过SIG对应的邮件列表获取最新讨论动态
• 参与SIG会议：SIG定期召开例会，会议纪要在SIG仓库中归档
• 浏览Issue列表：查看SIG仓库中的good first issue或help wanted标签

第三步：认领任务并贡献

开发者通过认领SIG Leader发布的需求来承接共建任务，按照需求分析、功能设计、代码开发、功能测试、功能交付等步骤进行任务开发。任务开发完成后，提交PR把代码、文档等提交到社区，完成最终的开源贡献。

2.3.2 主导成立新SIG

如果开发者的技术方向不属于已有SIG，可以申请成立新SIG。成立SIG需要经过申请、孵化、毕业三个阶段。

阶段一：SIG成立申请

申请准备：

1. 在社区中寻找2-3个以上有共同兴趣及目标的人，确定SIG Leader
2. 参考SIG章程模板创建SIG Charter提案，包含以下要素：
   • 创建SIG的背景信息
   • 创建SIG的业务范围
   • 创建SIG的业务目标

适合申请创建SIG的情形：

• 发起孵化的技术项目，能代表某一个领域的技术方向，并最终能转化为OpenHarmony的新增部件

不适合的情形：

• 发起的申请属于OpenHarmony社区已有的技术方向，建议直接参与已有SIG共建

提交申请：

SIG Leader以[SIG-Charter-Proposal-XXX]为邮件标题，将申请材料以附件方式向dev@openharmony.io发送邮件，提交新建SIG申请。

PMC评审：

1. PMC邮件回复同意后，SIG发起人申报PMC例行会议新建SIG议题，按时接入PMC会议介绍待新建的SIG
2. PMC评审通过后形成会议纪要并附评审意见

提交PR：

收到PMC评审反馈后，执行以下操作：

1. fork OpenHarmony/community仓库到本地
2. 在OpenHarmony/community/sig仓库内新建SIG文件夹，文件夹名为“sig-XXX”
3. 创建README.md、OWNERS.md文档，参考其他SIG的格式
4. 更新sigs.json文档
5. 提交PR请求合入主干

sigs.json文件格式示例：

"sigs-List":[{"sig-name":"sig-python","projects":"https://gitee.com/openharmony-sig/python","project-path":"python/"},{"sig-name":"sig-updates","projects":["https://gitee.com/openharmony/startup_appspawn_lite","https://gitee.com/openharmony/startup_bootstrap_lite"],"project-path":["base/startup/appspawn_lite","base/startup/bootstrap_lite"]}]

阶段二：SIG孵化

SIG成立后进入孵化阶段，需要完成：

1. 启动开发：需求澄清、特性梳理、方案设计、代码开发、单元测试、功能测试
2. 自检完善：对照Check List，完成法务、门禁、OAT等问题自检

孵化项目的代码统一存放在OpenHarmony SIG组织，待孵化成熟后可申请合入OpenHarmony主库。

阶段三：SIG毕业

孵化项目满足毕业要求后，可申请毕业：

1. 向架构SIG申请新SIG毕业
2. 向QA SIG申请新SIG准出
3. 仓库owner移仓至OpenHarmony主组织

毕业评审需按照要求自检完成。

2.4 SIG实践案例：辅助工具SIG

深开鸿主导的辅助工具SIG是SIG成功运作的典型案例。该SIG的宗旨是“降低重复劳动，提高工作效率，让专业的人做专业的事”。

2.4.1 辅助工具SIG的三个核心工具

1. NAPI框架代码生成工具

痛点：

• NAPI框架代码重复率高：面对不同JS接口，开发者需实现相似度高的框架代码
• NAPI学习成本高：涉及JavaScript、C++语言及编译脚本
• NAPI需求量大：OpenHarmony已支持1万多个NAPI接口

解决方案：
工具将C++、JavaScript接口类型转换等代码抽取公共模块，自动生成编译脚本。开发者只需实现业务代码调用即可。

2. IDL转换工具

痛点：

• HDI开发难度大：开发者熟悉C语言的.h文件，不熟悉IDL语法
• HDI工作量大：各子系统均涉及

解决方案：
工具将开发者熟悉的.h文件自动转换为.idl文件，开发者不需要关心IDL语法。

3. 开机动画工具

痛点：

• 资源格式要求高：OpenHarmony 2.0只支持raw文件
• 定制化需求大：不同产品需求不同

解决方案：
工具支持图片集或mp4等多种文件生成开机动画，支持设置分辨率，一键生成并支持在Windows上预览效果。

2.4.2 辅助工具SIG的共建方向

SIG提供三个共建方向供开发者选择：

2.5 SIG参与的核心价值

参与SIG贡献对开发者有多重价值：

1. 技术深耕：在特定技术领域持续深入，成为领域专家
2. 社区影响力：通过贡献积累声誉，获得社区认可
3. 职业发展：核心贡献者有机会晋升为Committer、Maintainer，甚至成为SIG Leader
4. 商业价值：参与根技术共建的企业可获得生态资源扶持

第三部分：代码提交与审查流程详解

3.1 环境准备与协议签署

在提交第一行代码前，需要完成以下准备工作。

3.1.1 注册码云账号

访问 https://gitee.com/ 注册账号，建议使用有意义的用户名（如姓名全拼）。

3.1.2 配置SSH公钥

# 生成SSH密钥（使用你的码云绑定邮箱）ssh-keygen-trsa-C"your_email@example.com"# 查看公钥（macOS/Linux）cat~/.ssh/id_rsa.pub# Windows用户在C:\Users\用户名\.ssh目录下找到id_rsa.pub

将公钥添加到码云“设置”→“安全设置”→“SSH公钥”中。验证是否成功：

ssh-Tgit@gitee.com# 返回 Welcome to Gitee.com, yourname! 即成功

3.1.3 签署DCO和开发者原创声明

DCO签署：

DCO（Developer Certificate of Origin）保证贡献者原创。签署前需确保：

• git全局配置的user.name与DCO签署姓名一致
• git全局配置的user.email与DCO签署邮箱一致（必须使用码云绑定邮箱）

# 配置git全局信息gitconfig--globaluser.name"你的名字"gitconfig--globaluser.email"你的gitee绑定邮箱"# 查看配置gitconfig--global--list

签署地址：https://clasign.osinfra.cn/sign/Z2l0ZWUlMkZvcGVuaGFybW9ueQ==

开发者原创声明：必须首先签署“开发者原创声明”，才能参与社区贡献。

3.2 完整代码提交流程

3.2.1 Fork代码仓到私仓

在目标仓库页面（如https://gitee.com/openharmony/napi_generator ），点击“Fork”将代码复制到自己的码云账号下。

3.2.2 克隆代码到本地

gitclone https://gitee.com/你的用户名/仓库名.gitcd仓库名

3.2.3 添加上游仓库

gitremoteaddupstream https://gitee.com/openharmony/仓库名.gitgitfetch upstream

3.2.4 创建功能分支

gitcheckout-bfeature/xxx# 功能开发# 或gitcheckout-bfix/issue-id-xxx# 缺陷修复

推荐的分支模型：

• main：永远保持可用，不在main上直接开发
• feature/<topic>：功能开发分支
• fix/<issue-id>-<keyword>：缺陷修复分支
• docs/<topic>：文档分支

3.2.5 本地开发和测试

在本地完成代码开发、单元测试和功能验证。

代码风格检查：提交前需确保代码符合项目规范。建议配置pre-commit钩子自动运行格式化+lint+基本测试。

3.2.6 Commit规范

Commit Message推荐采用Conventional Commits格式：

<type>(<scope>): <subject> <body> - 变更动机：为什么需要？ - 技术方案：如何实现？ - 兼容性：是否破坏性？ - 关联：Fixes #123

常用type：

• feat：新功能
• fix：修复
• perf：性能优化
• refactor：重构
• docs：文档
• test：测试
• build：构建
• ci：持续集成

签名要求：

gitcommit-s-m"fix(renderer): 修复纹理加载性能问题"# -s 添加Signed-off-by

3.2.7 推送代码到私仓

gitpush origin feature/xxx

3.2.8 创建Pull Request

1. 在Gitee上进入自己的私仓，点击“+ Pull Request”
2. 选择源分支（私仓的feature/xxx）和目标分支（上游的master/main）
3. 填写PR模板，包含：
   • 变更类型：Bugfix/Feature/Docs/Refactor
   • 问题背景：问题是什么，影响谁
   • 解决方案：核心思路、兼容性
   • 测试说明：覆盖用例、平台
   • 关联Issue：如Fixes #I1TVV4
4. 点击“创建Pull Request”

3.3 门禁检查与CI流程

3.3.1 DCO检查

PR创建后首先进行DCO检查，验证提交记录中的Signed-off-by与签署信息一致。

3.3.2 手动触发门禁

OpenHarmony社区有一个特别流程：需要在PR评论中手动输入“start build”来触发门禁检测。

这是OpenHarmony社区比较特别的一点，在其他开源项目中少见。

3.3.3 门禁检测内容

门禁检测包括：

• 静态检查：代码风格、潜在错误
• 代码编译：能否成功编译
• 功能测试：自动化测试用例执行

3.3.4 CI门户

OpenHarmony提供了CI门户（http://ci.openharmony.cn/ ）方便开发者查看门禁和每日构建的执行结果。每日构建用于提前发现代码静态检查、编译、功能等方面的问题。

3.4 代码审查流程

3.4.1 角色与权限

根据OpenHarmony API治理章程，代码审查涉及以下角色：

3.4.2 评审流程

API评审流程（对其他代码修改也有参考价值）：

1. Contributor提交：代码+API设计文档（涉及API变更时）
2. Committer预审：Review+1
   • 如果一次提交涉及多个领域，需所有对应领域Committer都Review+1
3. Maintainer评审：
   • 新增API：Maintainer Review+2即可合入（多个领域只需一个Maintainer通过）
   • 变更API：Maintainer Review+1（预审），进入下一环节
4. SIG评审（仅变更API）：SIG Review+2
5. 评审完成：代码合入

3.4.3 评审关注点

评审者主要关注：

• 正确性：代码是否解决了问题
• 设计合理性：方案是否优雅、可扩展
• 兼容性：是否破坏已有功能
• 测试覆盖：是否有足够测试用例
• 性能/安全：是否有潜在风险
• 代码风格：是否符合规范

3.4.4 评审文化

社区评审文化强调“被Review是礼物，别把‘挑刺’当冒犯”。维护者通常是志愿者或“业余维护”，需要耐心等待。遇到问题用事实和数据说话（基准、日志、规范链接）。

3.5 代码合入与关闭Issue

代码审查通过后，由Committer或Maintainer合入主干。PR合并后，回到关联的Issue中总结并关闭，给后来者留下清晰的路标。

第四部分：从社区贡献者到核心维护者之路

4.1 贡献者的成长路径

OpenHarmony社区的贡献者成长路径可以概括为三阶成长模型：

入门阶段 → 成长阶段 → 成熟阶段 Contributor Committer Maintainer/PMC

4.2 入门阶段：迈出第一步

4.2.1 选择适合的起点

对于开源新手，推荐选择good first issue或help wanted标签的任务。这类任务难度低、范围明确，多为：

• 文档修复（错别字、断链）
• 示例代码优化
• 简单的UI显示问题
• 测试用例补充

4.2.2 建立开发环境

建议采用“虚拟机+开发板”组合方案：

• 虚拟机：用于代码编译与调试
• 开发板（如润和Hi3516）：用于真机验证

4.2.3 完成首次贡献

按照第三部分的流程，完成从Issue认领到PR合入的全过程。首次贡献的目标不是代码量，而是熟悉整个协作流程。

4.3 成长阶段：成为Committer

4.3.1 深度参与核心模块

积累一定经验后，进入深度贡献阶段，重点参与核心模块开发与社区讨论。此时需结合自身技术专长选择方向，如分布式技术、安全架构、AI能力等。

4.3.2 从代码贡献到社区贡献

贡献不仅限于写代码：

金句：写文档和测试是“神中神”的贡献；它们让项目可维护、可扩展。

4.3.3 参与代码评审

参与他人代码评审是提升能力的重要途径：

• 通过评审他人代码，学习优秀编码技巧
• 从评审反馈中发现自身不足
• 逐步建立社区影响力

4.3.4 成为Committer的条件

成为Committer通常需要：

• 持续高质量贡献（代码量、评审参与度）
• 在特定领域展现技术深度
• 获得现有Committer/Maintainer认可
• SIG Leader提名，PMC确认

参与社区贡献的成员，根据贡献度大小，可以晋升为社区Committer或PMC，拥有社区正式身份，甚至拥有主干代码写权限和社区重要事务投票权限。

4.4 成熟阶段：成为Maintainer与生态共建者

4.4.1 Maintainer的职责

Maintainer是SIG的核心维护者，主要职责包括：

• 新增API评审（Review+2）
• 代码合入决策
• 技术方向把控
• 社区人才培养

4.4.2 主导SIG或项目

当贡献者成长为领域专家后，可以：

• 主导现有SIG的技术演进
• 申请成立新SIG（参考2.3.2节）
• 孵化创新项目

4.4.3 生态共建与价值转化

成熟阶段的核心是从“技术贡献者”向“生态引领者”转变：

开发行业解决方案：

• 智能家居领域：基于OpenHarmony开发设备互联互通协议
• 工业领域：开发工业控制解决方案
• 通过华为“鸿蒙生态合作伙伴计划”获得推广资源

开展行业合作：

• 与芯片厂商（瑞芯微等）合作优化驱动程序
• 与设备制造商（美的、格力等）合作开发搭载OpenHarmony的产品
• 华为提供技术对接和资源支持

参与生态推广：

• 撰写技术博客、录制教学视频
• 举办线下培训、技术沙龙
• 通过华为“开发者赋能计划”获得资金支持与品牌曝光

4.5 成长案例：深开鸿巴延兴

深开鸿资深OS框架开发工程师巴延兴是社区成长的典型代表：

• 参与OpenHarmony社区共建，带领一百余人提交PR
• 个人累计向主干提交1.5W+代码
• 在辅助工具SIG、内核SIG等核心领域深度共建
• 主导多个工具开发，解决社区痛点

他的经验表明：OpenHarmony是每个人的OpenHarmony，只要想参与共建，都可以利用自己对应的技能做贡献。

第五部分：社区沟通与礼仪

5.1 社区沟通渠道

OpenHarmony社区提供多种沟通渠道：

5.2 社区礼仪

有效的社区沟通需要遵循以下原则：

具体 & 可执行：提问时给出关键信息（系统版本、设备型号、日志、复现场景、期望vs实际）

先搜索：避免重复提问；在Issues/PR历史中找类似案例

尊重时间：维护者通常是志愿者，耐心等待，不要密集刷屏

接纳反馈：代码被指出问题是成长机会，不要情绪化；用事实和数据说话

正向循环：PR合并后，回到Issue中总结并关闭，给后来者留“清晰的路标”

5.3 Issue提交规范

高质量Issue应包含：

• 环境信息：OpenHarmony版本、设备/模拟器、构建信息
• 复现步骤：1, 2, 3…（可附脚本）
• 预期行为 vs 实际行为
• 日志：裁剪到关键片段，脱敏处理
• 截图/录屏：对UI问题极其有用
• 最小可复现代码或仓库（MRE）：能提供则离解决只差一步

5.4 PR描述规范

PR描述应包含：

• 原始需求：问题背景和影响
• 解决方案：如何解决、替代方案
• 具体修改点：变更的文件和内容
• 测试说明：覆盖用例、平台、结果
• 关联Issue：如Fixes #I1TVV4

第六部分：贡献者资源与工具

6.1 官方资源

6.2 辅助工具SIG代码仓

辅助工具SIG的核心工具代码仓：

• NAPI框架代码生成工具：https://gitee.com/openharmony/napi_generator
• IDL转换工具：https://gitee.com/openharmony/drivers_hdf_core/tree/master/framework/tools/idl-gen
• 开机动画工具：https://gitee.com/openharmony/graphic_graphic_2d/tree/master/frameworks/bootanimation/data/bootanimation_tool

6.3 贡献者清单模板

提交前检查清单：

• 代码已格式化（符合.editorconfig/clang-format）
• lint检查通过
• 单元测试通过且覆盖关键分支
• Commit message符合规范
• 已添加Signed-off-by
• PR描述完整（背景、方案、测试）
• 已关联相关Issue

第七部分：未来展望——OpenHarmony社区的演进

7.1 社区规模持续扩大

截至2025年11月，OpenHarmony开发者数量已突破800万。随着生态繁荣，社区治理机制也将持续优化。

7.2 治理机制演进方向

1. 更精细的SIG划分：随着技术领域扩展，SIG将更加专业化
2. 更便捷的贡献工具：辅助工具SIG将持续产出提效工具
3. 更完善的激励体系：贡献者成长路径更加清晰，商业价值转化通道更加通畅

7.3 从贡献者到生态共建者

未来的OpenHarmony社区，将涌现出更多从代码贡献起步，最终成为生态引领者的案例。正如深开鸿的开源策略：“从开源中来，到开源中去”。

结语：开源是一场长期主义

开源贡献不是“天才才行”的游戏，它是把细节做对、把节奏跑稳的长期主义。从签署DCO到提交第一行代码，从认领good first issue到主导SIG技术演进，每一步都在为OpenHarmony生态添砖加瓦。

参与OpenHarmony社区贡献，收获的不仅是技术能力的提升，更是与全球开发者协作的经验、在开源社区积累的影响力，以及见证国产操作系统成长的自豪感。

欢迎你加入OpenHarmony开源社区，从今天开始，迈出贡献的第一步。

附录：术语表