SIG全称Special Interest Group，即特别兴趣小组，专注一个特定的技术领域，负责该领域技术竞争力分析和关键技术识别及决策，引领技术演进的方向，也是共建单位及个人开发者进行开源贡献的基本单位。

通过SIG组参与开源共建的两种方式

参与者需要注册自己的官方账号，签订协议后，才能通过认领SIG leader发布的需求来承接共建任务。领完需求后是标准的开发过程，包括需求分析、功能设计、代码开发、功能测试、功能交付等步骤；任务开发完成后，需要提交PR，将代码、文档等提交到社区，完成最终的开源贡献。

1、成立SIG

选取共建技术领域并给出规划 → 向PMC例会提交议题并通过评审 → 通过架构SIG例会评估后建立新的代码仓。

2、孵化SIG

启动需求澄清、特性梳理方案设计、代码开发、单元测试、功能测试等流程，完成SIG项目开发 → 对照Check List，完成法务、门禁、OAT等问题自检。

3、毕业SIG

向架构SIG申请新SIG毕业 → 向QA SIG会申请新SIG准出 → 仓库owner移仓。

成立辅助工具SIG组的宗旨是“降低重复劳动，提高工作效率，让专业的人做专业的事”。 NAPI框架代码生成工具、IDL转换工具和开机动画工具都是围绕着这个宗旨开发而成的。

NAPI是标准设备上的JS API实现方式，实现了JS语言到框架C 层的调用，在OpenHarmony系统中，APP调用是调用JS语言的接口函数，最终具体功能是用C 语言来实现。

NAPI存在三个开发痛点需要解决：

1) NAPI框架代码的重复率高：面对不同的JS接口，开发者要实现相似度高的框架代码。

2) NAPI框架的学习成本高：框架机制涉及JavaScript、C 语言，以及编译脚本工具。

3) NAPI 需求量大：OpenHarmony系统功能均是通过NAPI接口体现，目前已经支持1万多个NAPI接口。

针对以上三个痛点，NAPI框架代码生成工具将C 、JavaScript接口类型转换等代码抽取公共模块，并且自动生成编译脚本。开发者使用工具自动生成NAPI框架代码，只需实现业务代码调用即可，避免了大量重复的工作。

OpenHarmony使用的是HDF驱动框架，驱动相应的硬件信息需要IDL文件来描述。

IDL存在两大开发痛点需要解决：

1) HDI开发难度大：HDI开发者比较熟悉C语言，习惯在.h文件中定义HDI接口，而对于IDL文件结构、语法并不是很熟悉，学习曲线相对较长。

2) HDI工作量大：HDI接口是驱动对外提供服务的必要条件，各个子系统均涉及，故HDI工作量较大。

针对以上痛点，深开鸿设计的IDL转换工具将开发者熟悉的.h文件自动转换为idl文件，开发者只需要在头文件中定义自己的接口即可，工具自动实现.h头文件到IDL文件转换，开发者不需要关心IDL语法，大大降低工作量。

提交过程中要注意格式要求，必须写清楚提单过程中问题出现的条件，预期的结果和错误的结果，问题的定位信息等，有了这些信息后，领取这个问题单的开发也方便定位问题。

littlefs文件系统的共建过程：

1) 了解社区需求，社区目前对littlefs文件系统随机读写的速度不满意。

2) 了解到社区文件系统对随机读写需求的前提下，对littlefs随机读写IO性能瓶颈进行分析，找到能优化的代码点，采用了“以空间换时间”的思路。

3) 采用逐步优化的思路，明确方案后和社区负责人沟通，得到了社区负责人认可后，展开具体的代码工作。

littlefs第三方库代码完成后提交到社区的过程

1) littlefs第三方库repository路径，并fork到用户仓库。

2) git clone用户仓到本地。

3) 提交修改到用户仓。

4) 点击提交PR。

5) 填写PR单，PR单页需要按照既定模板填写，写清楚原始需求，如何解决这个问题，怎么解决这个问题以及具体修改点。

6) 在评论中添加“start build”点亮PR。这里有一个特别注意的点，需要在评论中是手动填写“start build”这2个英文单词，目的是触发后续的门禁检测。这是OpenHarmony社区比较特别的一点，其它开源项目中所没有的。

欢迎感兴趣的开发者多方位参与OpenHarmony开源贡献，成为OpenHarmony Contributor，也欢迎各位提出宝贵的意见，为OpenHarmony贡献一份力量。

附：文章中涉及的链接汇总：