OpenHarmony社区治理模式：开发者如何参与贡献——从SIG参与到核心维护者的完整路径

前言

截至2025年11月，OpenHarmony开源项目代码量已超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通常包含以下角色：

角色 职责 产生方式
SIG Leader 负责SIG整体运营、例会组织、对外汇报 由SIG发起人或核心贡献者担任
Committer 负责代码评审、任务分配、社区答疑 由SIG Leader提名，PMC确认
Contributor 参与具体任务开发、提交代码 任何开发者均可成为

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提供三个共建方向供开发者选择：

方向 适合人群 具体工作
文档资料 擅长文档编撰 使用指导、开发指导、集成指导
测试用例 测试人员 UI用例、ST用例、测试框架
工具开发 开发者 工具能力增强、VSCode插件、IntelliJ插件

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 -t rsa -C "your_email@example.com"

# 查看公钥（macOS/Linux）
cat ~/.ssh/id_rsa.pub

# Windows用户在C:\Users\用户名\.ssh目录下找到id_rsa.pub

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

ssh -T git@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全局信息
git config --global user.name "你的名字"
git config --global user.email "你的gitee绑定邮箱"

# 查看配置
git config --global --list

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

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

3.2 完整代码提交流程

3.2.1 Fork代码仓到私仓

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

3.2.2 克隆代码到本地
git clone https://gitee.com/你的用户名/仓库名.git
cd 仓库名
3.2.3 添加上游仓库
git remote add upstream https://gitee.com/openharmony/仓库名.git
git fetch upstream
3.2.4 创建功能分支
git checkout -b feature/xxx  # 功能开发
# 或
git checkout -b fix/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：持续集成

签名要求：

git commit -s -m "fix(renderer): 修复纹理加载性能问题"  # -s 添加Signed-off-by
3.2.7 推送代码到私仓
git push 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治理章程，代码审查涉及以下角色：

角色 API治理职责 权限标识
Contributor API设计和交付主体，提交代码与设计文档 提交代码
Committer API代码预审 Review+1
Maintainer 新增API评审（Review+2）；变更API预审（Review+1） Review+2（新增）
SIG 变更API评审 Review+2（变更）
PMC API Version计划发布、章程修订 最终决策
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 从代码贡献到社区贡献

贡献不仅限于写代码：

贡献类型 具体内容
代码 修Bug、开发特性、性能优化
文档 完善README、教程、FAQ
测试 补充单元测试、集成测试
社区 答疑、代码评审、Roadmap讨论
生态 适配器、插件、工具链开发

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

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社区提供多种沟通渠道：

渠道 地址 用途
开发邮件列表 dev@openharmony.io 开发讨论、技术交流
CI邮件列表 cicd@openharmony.io CI构建通知
PMC邮件列表 pmc@openharmony.io PMC内部讨论
安全问题邮箱 scy@openharmony.io 安全漏洞上报
文档邮件列表 docs@openharmony.io 文档相关讨论
开发者论坛 https://forums.openharmony.cn 技术问答、经验分享

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 官方资源

资源 地址 用途
OpenHarmony官网 https://www.openharmony.cn 项目信息、下载
开发者文档 https://docs.openharmony.cn 开发指南、API参考
代码仓库 https://gitee.com/openharmony 源码浏览、下载
社区治理仓库 https://gitee.com/openharmony/community SIG列表、治理文档
CI门户 http://ci.openharmony.cn 构建状态查看

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开源社区，从今天开始，迈出贡献的第一步。

附录：术语表

术语 全称 中文含义 简要说明
SIG Special Interest Group 特别兴趣小组 社区贡献的基本单位，负责特定技术领域
PMC Project Management Committee 项目管理委员会 负责版本计划、发布管理等
TSC Technical Steering Committee 技术指导委员会 负责技术方向决策
PR Pull Request 拉取请求 代码贡献的提交方式
DCO Developer Certificate of Origin 开发者原创证明 保证代码原创性的签署机制
CI Continuous Integration 持续集成 自动化代码检查与构建
Maintainer - 维护者 有代码合入权限的核心贡献者
Committer - 提交者 有代码评审权限的贡献者
Contributor - 贡献者 参与贡献的开发者
# 华为 # harmonyos
Logo
开源鸿蒙跨平台开发者社区

开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。

更多推荐

cover

在 Ubuntu 中搭建鸿蒙 PC 三方库交叉编译构建开发环境

avatar 开源鸿蒙跨平台开发者社区
cover

ReactNative项目OpenHarmony三方库集成实战：react-native-camera

avatar 开源鸿蒙跨平台开发者社区
cover

在 macOS 中搭建鸿蒙 PC 三方库交叉编译开发环境

avatar 开源鸿蒙跨平台开发者社区