!583 update docs contribution guide

Merge pull request !583 from NEEN/master

README.md

@@ -14,11 +14,17 @@
 
 ### 最新版本
 
-master：最新开发版本。发布OpenHarmony 2.0 Canary预览版本，[了解版本详情](zh-cn/release-notes/OpenHarmony-2-0-Canary.md)。
+master：最新开发版本。  
+
+发布 OpenHarmony v2.2 Beta2版本，[了解版本详情](zh-cn/release-notes/OpenHarmony-v2.2-beta2.md)。
+
+发布OpenHarmony 2.0 Canary预览版本，[了解版本详情](zh-cn/release-notes/OpenHarmony-2-0-Canary.md)。
 
 ### 历史稳定版本
 
-OpenHarmony_v1.0.1_release：OpenHarmony 1.1.0 LTS稳定版本，[了解版本详情](zh-cn/release-notes/OpenHarmony-1-1-0-LTS.md)。
+OpenHarmony_v1.x_release：OpenHarmony 1.1.0 LTS稳定版本，[了解版本详情](zh-cn/release-notes/OpenHarmony-1-1-0-LTS.md)。
+
+[了解更多版本详情](https://gitee.com/openharmony/docs/blob/master/zh-cn/release-notes/)。
 
 
 

zh-cn/contribute/docs-release-process.md

+# 为发行版本撰写配套文档
+
+为了帮助开发者更高效使用OpenHarmony社区的每个Release版本，社区会根据每个版本规划的需求特性提供配套文档（如指南、API参考、开发示例、Release Notes、API Changelog、FAQ等）。有的需求涉及新增功能特性和文档，有的需求的是对现有特性和文档内容更新。
+
+## OpenHarmony社区文档开发流程
+
+每个SIG团队在规划功能特性需求时，需要判断该需求是否涉及新增开发者文档、或变更现有开发者文档，分解需求给SIG Docs 团队，便于文档需求跟踪闭环。SIG Docs团队会根据相关需求，提供文档设计意见，并配合各业务SIG团队完成开发者文档的评审、翻译和发布。社区文档完整开发流程如下：
+
+![OpenHarmony社区文档开发流程](figures/docs-sig.png)
+
+## 业务SIG团队成员或其他开发人员
+
+通过每个业务SIG团队为发行版本撰写配套文档基础稿，欢迎社区开发人员参与相关功能特性文档开发。
+
+### 分解文档需求
+
+1. 在业务SIG需求Issue中给出【配套文档】的分解，如果涉及开发者文档新增、更新，需要关联SIG-Docs。
+
+2. 在 [OpenHarmony社区版本发布计划](https://gitee.com/openharmony/release-management/blob/master/OpenHarmony-RoadMap.md)中查看对应版本的特性需求，此文档中给出了OpenHarmony的版本发布时间计划、各版本交付特性、特性状态，所属SIG。
+
+   如果该特性需求涉及文档交付，需要在对应的Need Docs列补充判断，SIG_Docs，便于SIG Docs团队闭环跟踪文档交付。
+
+
+### 开发文档
+
+如果你是某个业务SIG的成员，负责开发某一新特性，你需要与SIG Docs一起配合，确保在版本发布之前完成该新特性文档开发。否则，在最终的版本发布中未提供配套文档的特性可能被移除。
+
+如果你需要文档组织方面的帮助，请在`#SIG-Docs` ZULIK频道中提问求助。
+
+1. 参考[评审人沟通表](docs-reviewers.md)，联系SIG Docs资料作者，沟通文档设计建议。
+2. 获取[文档模板](template)，了解文档写作规范。
+3. 尽可能为功能特性提供详细的文档及使用说明，完成功能特性初稿后，提交PR并在PR描述中提供对应的需求Issue链接。
+
+### 提交PR评审
+
+所有新增内容的PR评审，为确保技术描述准确性需要指定相应业务SIG的技术专家参与技术评审，同时指定SIG Docs的资料专家评审文档规范性内容，请参考[评审人沟通表](docs-reviewers.md)在PR评论区@相关专家。也可以在`#SIG-Docs` ZULIK频道中反馈评审需求。
+
+在评审周期内，所有评审意见闭环修改后，该PR通过审核可以合并入仓的必要条件：
+
+- 技术评审专家审核后给出`TechApprove`的评论。
+- 文档规范性评审专家审核后给出`DocsApprove`的评论。
+
+### 提交测试
+
+文档随版本转测试，测试过程中的文档问题，由SIG Test团队测试人员以Issue形式提交到Docs仓，对应文档作者闭环确认测试意见并完成文档修改。
+
+### 提交翻译
+
+#### Docs仓文档翻译
+
+OpenHarmony社区为开发者提供中文、英文的官方文档，中文文档完成评审、测试定稿后，可提交翻译需求Issue，由SIG Docs团队的翻译专家完成英文文档。
+
+翻译专家通过PR提交英文文档，并在PR描述中提供对应的中文需求Issue链接。为确保技术翻译描述准确性需要指定相应业务SIG的技术专家参与技术评审，可以是中文文档作者，请参考[评审人沟通表](docs-reviewers.md)在PR评论区@相关专家。
+
+在评审周期内，所有评审意见闭环修改后，该PR通过审核可以合并入仓的必要条件：
+
+- 技术评审专家审核后给出`TechApprove`的评论。
+- 英文文档规范性评审专家审核后给出`DocsApprove`的评论。
+
+#### 非Docs仓文本类翻译
+
+针对OpenHarmony核心业务SIG的非Docs仓翻译需求（如API注释等），可提交翻译需求Issue到Docs仓，SIG Docs团队的翻译专家完成英文文档交付。
+
+提交翻译需求时，需确保：
+
+1. 相关中文文档为发布交付件质量标准。
+2. 提供中文文档PR或相关文档路径。
+3. 中文临时文件可提交至[SIG-Docs仓](https://gitee.com/openharmony/community/tree/master/sig/)。
+
+## Docs SIG团队成员或文档贡献者
+
+SIG Docs团队成员或文档贡献者或，配合各业务SIG团队，评审、优化相关文档输出，英文翻译，确保相关输出符合发布条件。
+
+### 了解发行版本规划特性
+
+想要了解对应发行版本规划的功能特性、发布计划，可以参加每双周周五例行组织的[SIG Release](https://gitee.com/openharmony/release-management/blob/master/README.md)例会。了解版本进度，需求交付进度，文档交付进度等。
+
+同时可以在 [OpenHarmony社区版本发布计划](https://gitee.com/openharmony/release-management/blob/master/OpenHarmony-RoadMap.md)中查看对应版本的特性需求，选择标识有SIG_Docs的相关特性Issue，及关联的文档PR。
+
+![版本特性清单](figures/sig-task.png)
+
+### 评审PR中提交的中文文档
+
+在评审对应特性文档时，建议从以下方面给出中肯的评审建议。
+
+#### 语言描述规范
+
+- 前后逻辑表达通顺，术语名词表述一致
+- 语言正式避免口语化
+- 避免使用侵犯第三方知识产权的风险词汇
+
+#### 内容易理解
+
+- 内容逻辑清晰，前后表达一致
+- 内容表达易读易理解，避免使用晦涩、生僻的词语
+- 步骤清晰，有效指导开发者完成相关任务开发
+
+#### 图表规范
+
+- 图片清晰、图文配合使用
+- 表格有表头、表标题，避免出现单行或单列表
+- 表格中无内容用“-"或者"NA"，避免出现空白单元格  
+
+#### 网站风格
+
+- 该PR变更涉及新增Markdown页面时，需确保：
+  - 该页面内容使用了正确的内容模板
+  - 该Markdown文件名称定义符合规范
+  - 该页面在整本手册Readme导航中正常显示
+
+- 删除Markdown页面、变更Markdown页面名称，需确保：
+  - 该页面对社区其他内容链接未产生影响，建议本地运行链接检查
+  - 整本手册Readme导航中更新目录   
+
+更多详细规范请参考OpenHarmony社区文档[写作规范](写作规范.md)。
+
+### 翻译英文文档
+
+社区的翻译需求Issue会由SIG Docs团队技术翻译专家完成翻译，也欢迎文档贡献者领取翻译需求任务，提交英文文档PR。
+
+
+

zh-cn/contribute/docs-reviewers.md

+# 开发者文档评审人
+
+## 文档规范评审人
+### 设备开发相关文档评审人
+
+| Feature      | Docs Reviewers                                               |
+| ------------ | ------------------------------------------------------------ |
+| 快速入门     | [@duangavin123](https://gitee.com/duangavin123)              |
+| 获取源码     | [@duangavin123](https://gitee.com/duangavin123)              |
+| 内核         | [@Austin23](https://gitee.com/Austin23)                      |
+| 驱动         | [@Qianchenya](https://gitee.com/Qianchenya)                  |
+| 设备开发指南 | [@Austin23](https://gitee.com/Austin23)                      |
+| 移植适配     | [@Austin23](https://gitee.com/Austin23)                      |
+| Bundle开发   | [@Qianchenya](https://gitee.com/Qianchenya)                  |
+| 隐私与安全   | [@Qianchenya](https://gitee.com/Qianchenya)                  |
+| 子系统       | [@Qianchenya](https://gitee.com/Qianchenya)                  |
+| 导读         | [@zengyawen](https://gitee.com/zengyawen)                    |
+| 术语         | [@bj9854](https://gitee.com/bj9854)                          |
+| 社区公共文档 | [@neeen](https://gitee.com/neeen)  [@yan-tingting666](https://gitee.com/yan-tingting666) |
+
+### 应用开发相关文档评审人
+
+| Feature      | Docs Reviewers                            |
+| ------------ | ----------------------------------------- |
+| JS参考规范   | [@zengyawen](https://gitee.com/zengyawen) |
+| 媒体         | [@zengyawen](https://gitee.com/zengyawen) |
+| 快速入门     | [@ge-yafang](https://gitee.com/ge-yafang) |
+| UI           | [@ge-yafang](https://gitee.com/ge-yafang) |
+| 应用开发导读 | [@zengyawen](https://gitee.com/zengyawen) |
+| 网络与连接   | [@RayShih](https://gitee.com/RayShih)     |
+
+## 技术正确性评审人---待补充
+
+
+

zh-cn/contribute/template/concept-overview-template.md

+# 概述
+
+*【 **写作要求】***
+
+*必选，描述本开发任务相关的基本概念，帮助开发者更好的理解开发任务。* *写作要求见下，完成写作后，请逐项自检。*
+
+| 内容要求 | 是否满足 |
+| -------- | -------- |
+| 业界通用的概念不用赘述。 |  |
+| 注意使用业界通用术语来表达，不用开发者无法理解的内部语言。 |  |
+
+
+【写作样例】
+
+
+XX系统音频模块支持音频业务的开发，提供音频相关的功能，主要包括音频播放、音频采集、音量管理和短音播放等。
+
+
+在进行应用的开发前，开发者应了解以下基本概念：
+
+
+- 采样
+  采样就是把模拟信号数字化的过程，所有的模拟信号都需要通过采样转换为可以用0101来表示的数字信号。
+
+- 采样率
+  采样率为每秒从连续信号中提取并组成离散信号的采样次数，单位用赫兹（Hz）来表示。通常人耳能听到频率范围大约在20Hz～20kHz之间的声音。常用的音频采样频率有：8kHz、11.025kHz、22.05kHz、16kHz、37.8kHz、44.1kHz、48kHz、96kHz、192kHz等。
+
+- 声道
+  声道是指声音在录制或播放时在不同空间位置采集或回放的相互独立的音频信号，所以声道数也就是声音录制时的音源数量或回放时相应的扬声器数量。
+
+- 音频帧
+  音频数据是流式的，本身没有明确的一帧帧的概念，在实际的应用中，为了音频算法处理/传输的方便，一般约定俗成取2.5ms~60ms为单位的数据量为一帧音频。这个时间被称之为“采样时间”，其长度没有特别的标准，它是根据编解码器和具体应用的需求来决定的。
+
+
+## 运作机制
+
+*【 **写作要求】***
+
+*可选。如果机制比较简单，通过前面基本概念就可以说清楚，此章节可以不用提供，删除标题即可。*
+
+*描述实现原理介绍机制，如关键步骤相关接口调用时机和触发时机，帮助开发者了解该功能的基本运作原理，以便更好的理解开发任务和定位问题。*
+
+* 写作要求见下，完成写作后，请逐项自检。*
+
+| 内容要求 | 是否满足 |
+| -------- | -------- |
+| 仅描述开发任务相关的原理。 |  |
+| 尽量图文配合，一般使用时序图、流程图等形式。文字描述与图形描述匹配。 |  |
+
+【写作样例-1】
+
+- 信号量初始化，为配置的N个信号量申请内存（N值可以由用户自行配置，受内存限制），并把所有的信号量初始化成未使用，并加入到未使用链表中供系统使用。
+
+- 信号量创建，从未使用的信号量链表中获取一个信号量资源，并设定初值。
+
+- 信号量申请，若其计数器值大于0，则直接减1返回成功。否则任务阻塞，等待其它任务释放该信号量，等待的超时时间可设定。当任务被一个信号量阻塞时，将该任务挂到信号量等待任务队列的队尾。
+
+- 信号量释放，若没有任务等待该信号量，则直接将计数器加1返回。否则唤醒该信号量等待任务队列上的第一个任务。
+
+- 信号量删除，将正在使用的信号量置为未使用信号量，并挂回到未使用链表。
+
+- 信号量允许多个任务在同一时刻访问同一资源，但会限制同一时刻访问此资源的最大任务数目。访问同一资源的任务数达到该资源的最大数量时，会阻塞其他试图获取该资源的任务，直到有任务释放该信号量。
+  
+
+  【写作样例-2】
+
+  **互斥锁运作原理**
+
+  多任务环境下会存在多个任务访问同一公共资源的场景，而有些公共资源是非共享的，需要任务进行独占式处理。互斥锁怎样来避免这种冲突呢？
+
+  用互斥锁处理非共享资源的同步访问时，如果有任务访问该资源，则互斥锁为加锁状态。此时其他任务如果想访问这个公共资源则会被阻塞，直到互斥锁被持有该锁的任务释放后，其他任务才能重新访问该公共资源，此时互斥锁再次上锁，如此确保同一时刻只有一个任务正在访问这个公共资源，保证了公共资源操作的完整性。
+
+
+
+## 约束与限制
+
+【写作要求】
+
+*必选。* *描述本开发任务过程中* *的约束条件，以及此操作约束带来相应的负面影响，包括但不限于如下几方面：*
+
+- **功能限制**：  
+  - 功能使用范围（明确不支持的场景）。
+  - 规格限制。
+
+* **操作限制**：
+
+  * 已知问题的操作。
+  * 潜在风险的操作（如引起性能降低）。
+  * 引起性能降低的操作。
+
+写作要求见下，完成写作后，请逐项自检。
+
+| 内容要求 | 是否满足 |
+| -------- | -------- |
+| 明确功能限制或操作限制。 |  |
+| 约束对指导任务开发有影响或体验有感知，否则不用体现。 |  |
+| 容易出错的操作在步骤里描述，不在此体现。 |  |
+
+**【写作样例】**
+
+**互斥锁的约束与限制：**
+
+- 两个任务不能对同一把互斥锁加锁。如果某任务对已被持有的互斥锁加锁，则该任务会被挂起，直到持有该锁的任务对互斥锁解锁，才能执行对这把互斥锁的加锁操作。
+
+- 互斥锁不能在中断服务程序中使用。
+
+- XXX作为实时操作系统需要保证任务调度的实时性，尽量避免任务的长时间阻塞，因此在获得互斥锁之后，应该尽快释放互斥锁。
+
+- 持有互斥锁的过程中，不得再调用LOS_TaskPriSet等接口更改持有互斥锁任务的优先级。

zh-cn/contribute/template/guide-template.md

+# 开发指导
+
+** *【写作要求】***
+
+
+*必选。* *描述各个场景下，开发者如何完成开发任务。* *可根据多场景任务增加章节。写作要求见下，完成写作后，请逐项自检。*
+
+
+| 内容要求 | 是否满足 |
+| -------- | -------- |
+| 如果有多个场景，请写起多个“开发指导”章节，如音频播放开发指导、音量管理开发指导、短音播放开发指导。 |  |
+| 标题尽量使用“动词+名词”的句式表述任务操作。 |  |
+
+
+## 场景介绍
+
+** *【写作要求】***
+
+*必选。* *描述在什么情景下解决什么问题，最终达到什么样的效果。*应用SCQA描述方法：
+
+- S：situation（情景），由大家都熟悉的的情景，事实引入。
+
+- C：complication（冲突），但是实际情况往往和我们的要求有冲突。
+
+- Q：question（疑问），怎么办？
+
+- A：answer（回答），我们的解决方案是 …
+
+*写作要求见下，完成写作后，请逐项自检。*
+
+| 要求项 | 内容要求 | 是否满足 |
+| -------- | -------- | -------- |
+| I.1.1 | 背景原因、什么时候在哪、做了什么操作、最终解决什么问题或操作效果都明确。 |  |
+
+**【写作样例】**
+
+音频播放的主要工作是将音频数据转码为可听见的音频模拟信号并通过输出设备进行播放，同时对播放任务进行管理。
+
+
+## 接口说明
+
+** *【写作要求】***
+
+*必选。* *描述本开发指导相关的接口有哪些，旨在要开发者在开发前有大体了解，提升开发效率。* *写作要求见下，完成写作后，请逐项自检。*
+
+| 内容要求 | 是否满足 |
+| -------- | -------- |
+| 不在本开发任务的接口无需提供。 |  |
+| 如果接口太多，超过10个，可以提供主要的接口 |  |
+
+**【写作样例】**
+
+音频播放开放能力如下：AudioRenderer类，具体的API详见接口文档。
+
+**表1**  音频播放API接口功能介绍
+
+| 接口名 | 描述 |
+| -------- | -------- |
+| AudioRenderer(AudioRendererInfo audioRendererInfo, PlayMode pm) throws IllegalArgumentException | 构造函数，设置播放相关音频参数和播放模式，使用默认播放设备 |
+| AudioRenderer(AudioRendererInfo audioRendererInfo, PlayMode pm, AudioDeviceDescriptor outputDevice) throws IllegalArgumentException | 构造函数，设置播放相关音频参数、播放模式和播放设备 |
+| boolean play() | 播放音频流 |
+| boolean write(byte[] data, int offset, int size) | 将音频数据以byte流写入音频接收器以进行播放 |
+
+
+## 开发步骤
+
+** *【写作要求】***
+
+ * 必选。描述*  *开发的整体过程，便于开发者快速完成开发。* * 具体 写作要求见下，完成写作后，请逐项自检下。*
+| 内容要求 | 是否满足 |
+| -------- | -------- |
+| **如何写好步骤** |  |
+| 步骤完整：提供必须的步骤，顺利指导完成操作，无缺失。 |  |
+| 脉络清楚：文档逻辑清晰、合理。文档前面的概述、准备、操作围绕一条线描述，不能章节断裂或前后矛盾的现象。 |  |
+| 任务句式：标题或句子尽量使用“动词+名词”的句式表述动作。 |  |
+| 预防提前：操作过程中的限制、易错的、有潜在风险的，要提前描述，使用DOCS平台的“插入> 说明 > 须知”描述。 |  |
+| 步骤清晰-1：无论步骤简单或复杂，都需要写步骤目的，即为什么做。 |  |
+| 步骤清晰-2：明确在什么环境下，使用什么工具，做什么操作，怎么做该操作。 |  |
+| 步骤具体：如果操作可选，要明确可选条件。 |  |
+| 在开发步骤执行完成后，及时明确操作正确的标准。 |  |
+| **如何写好代码段** |  |
+| 代码涉及开发者拷贝的命令，必须用可编辑的报文呈现，避免截图，使用代码片段包裹。 |  |
+| 代码中关键段用蓝色（RGB：0.0.255）突出显示，关键步骤要有注释说明。 |  |
+| 代码显示符合代码缩进要求。 |  |
+| 步骤涉及接口调用，清晰给出接口及其使用说明或示例代码，代码来源于具体实例。 |  |
+
+**【写作样例】**
+
+1. 构造音频流参数的数据结构AudioStreamInfo，推荐使用AudioStreamInfo.Builder类来构造，模板如下，模板中设置的均为AudioStreamInfo.Builder类的默认值，根据音频流的具体规格来设置具体参数。
+   ```
+   AudioStreamInfo audioStreamInfo = new AudioStreamInfo.Builder().sampleRate(    AudioStreamInfo.SAMPLE_RATE_UNSPECIFIED)    .audioStreamFlag(AudioStreamInfo.AudioStreamFlag.AUDIO_STREAM_FLAG_NONE)    .encodingFormat(AudioStreamInfo.EncodingFormat.ENCODING_INVALID)    .channelMask(AudioStreamInfo.ChannelMask.CHANNEL_INVALID)    .streamUsage(AudioStreamInfo.StreamUsage.STREAM_USAGE_UNKNOWN)    .build();
+   ```
+
+    以真实的播放pcm流为例：
+      ```
+      AudioStreamInfo audioStreamInfo = new AudioStreamInfo.Builder().sampleRate(44100)//44.1kHz    .audioStreamFlag(AudioStreamInfo.AudioStreamFlag.AUDIO_STREAM_FLAG_MAY_DUCK)//混音    .encodingFormat(AudioStreamInfo.EncodingFormat.ENCODING_PCM_16BIT)//16-bit PCM    .channelMask(AudioStreamInfo.ChannelMask.CHANNEL_OUT_STEREO)//双声道    .streamUsage(AudioStreamInfo.StreamUsage.STREAM_USAGE_MEDIA)//媒体类音频    .build();
+      ```
+
+2. 使用步骤1创建的音频流构建音频播放的参数结构AudioRendererInfo，推荐使用AudioRendererInfo.Builder类来构造，模板如下，模板中设置的均为AudioRendererInfo.Builder类的默认值，根据音频播放的具体规格来设置具体参数。
+   ```
+   AudioRendererInfo audioRendererInfo = new AudioRendererInfo.Builder().audioStreamInfo(audioStreamInfo)    .audioStreamOutputFlag(AudioRendererInfo.AudioStreamOutputFlag.AUDIO_STREAM_OUTPUT_FLAG_NONE)    .bufferSizeInBytes(0)    .distributedDeviceId("")    .isOffload(false)    .sessionID(AudioRendererInfo.SESSION_ID_UNSPECIFIED)    .build();
+   ```
+
+    以真实的播放pcm流为例：
+      ```
+      AudioRendererInfo audioRendererInfo = new AudioRendererInfo.Builder().audioStreamInfo(audioStreamInfo)    .audioStreamOutputFlag(AudioRendererInfo.AudioStreamOutputFlag.AUDIO_STREAM_OUTPUT_FLAG_DIRECT_PCM)//pcm格式的输出流    .bufferSizeInBytes(100)    .distributedDeviceId("E54***5E8")//使用分布式设备E54***5E8播放    .isOffload(false)//false表示分段传输buffer并播放，true表示整个音频流一次性传输到HAL层播放    .build();
+      ```
+
+3. 根据要播放音频流指定PlayMode，不同的PlayMode在写数据时存在差异，详情见步骤7，其余播放流程是无区别的。并通过构造函数获取AudioRenderer类的实例化对象。
+   ....
+
+4. 播放任务结束后，调用AudioRenderer实例化对象的release()释放资源。
+
+
+## 调测验证（可选）
+
+** *【写作要求】***
+
+*可选。* *描述开发完成后，进行调测验证，确保最终操作成功。* *操作步骤要求同“开发指导”，其他具体写作要求见下，完成写作后，请逐项自检下。*
+
+| 内容要求 | 是否满足 |
+| -------- | -------- |
+| 仅进行最后的业务调测，每个小任务的操作结果，在开发步骤执行完成后，及时验证操作结果。 |  |
+| 明确开发成功标准。 |  |
+
+

zh-cn/contribute/贡献文档.md

@@ -19,7 +19,23 @@
 
 ## 贡献方式<a name="section5723203852414"></a>
 
-## 简单更改<a name="section1433285372417"></a>
+### 反馈文档问题<a name="section133341053162416"></a>
+
+高质量的问题反馈有助于我们不断完善文档内容和质量，您提供的信息越详尽，对我们问题改进越有帮助。
+
+1.  在Gitee页面中，“Issue“页签中单击“新建Issue“，在标题栏中描述问题，在编辑框中添加详细问题描述。
+2.  单击“创建“按钮，提交Issue，耐心等待文档团队成员确认您的问题。
+
+>![](public_sys-resources/icon-note.gif) **说明：** 
+>**如何反馈一个高质量的问题？**
+>
+>-   提供问题的清晰描述，描述具体缺失、过时、错误的内容或者需要改进的文字。
+>-   解释该问题对用户的影响。
+>-   将给定问题的范围限定在一个具体内容、任务。如果问题牵涉的领域较大，可以将其分解为多个小一点的问题。例如："文档需要优化" 是一个过于宽泛的问题，而 "XX开发指南缺少对XXX步骤的介绍" 就是一个足够具体的、可操作的问题。
+>-   搜索现有问题的列表，查看是否已经有相关的或者类似的问题已被记录。
+>-   如果新问题与某其他问题或 PR 有关联，可以使用其完整 URL 或带 \# 字符的 PR 编号 来引用它。
+
+### 简单更改<a name="section1433285372417"></a>
 
 针对现有文档进行快速更改和修复，适合少量内容修改和补充。
 
@@ -28,7 +44,7 @@
 3.  修改完成后，可单击“预览“按钮，确认修改结果。
 4.  确认无误后，在“扩展信息框“中填写修改意见和补充信息、sign-off-by邮箱信息触发DCO校验，单击提交审核。
 
-    例如：Signed-off-by: NEEN < XXX@XX.com > //与DCO签署邮箱保持一致
+    例如：Signed-off-by: giteename < XXX@XX.com > //与DCO签署邮箱保持一致
 
     ![输入图片说明](https://images.gitee.com/uploads/images/2021/0625/095714_92d8e459_7756659.png "屏幕截图.png")
 
@@ -37,27 +53,18 @@
 
 更多内容可参考[贡献流程](贡献流程.md)。
 
-## 反馈文档问题<a name="section133341053162416"></a>
-
-高质量的问题反馈有助于我们不断完善文档内容和质量，您提供的信息越详尽，对我们问题改进越有帮助。
+### 为发行版本贡献文档
 
-1.  在Gitee页面中，“Issue“页签中单击“新建Issue“，在标题栏中描述问题，在编辑框中添加详细问题描述。
-2.  单击“创建“按钮，提交Issue，耐心等待文档团队成员确认您的问题。
+为了帮助开发者更高效使用OpenHarmony社区的每个Release版本，社区会根据每个版本规划的需求特性提供配套文档（如指南、API参考、开发示例、Release Notes、API Changelog、FAQ等）。有的需求涉及新增功能特性和文档，有的需求的是对现有特性和文档内容更新。
 
->![](public_sys-resources/icon-note.gif) **说明：** 
->**如何反馈一个高质量的问题？**
->-   提供问题的清晰描述，描述具体缺失、过时、错误的内容或者需要改进的文字。
->-   解释该问题对用户的影响。
->-   将给定问题的范围限定在一个具体内容、任务。如果问题牵涉的领域较大，可以将其分解为多个小一点的问题。例如："文档需要优化" 是一个过于宽泛的问题，而 "XX开发指南缺少对XXX步骤的介绍" 就是一个足够具体的、可操作的问题。
->-   搜索现有问题的列表，查看是否已经有相关的或者类似的问题已被记录。
->-   如果新问题与某其他问题或 PR 有关联，可以使用其完整 URL 或带 \# 字符的 PR 编号 来引用它。
+欢迎开发者参与贡献，详细参考：[为发行版本贡献文档](docs-release-process.md)
 
-## 创建新内容<a name="section12616152517159"></a>
+### 贡献经验分享内容<a name="section12616152517159"></a>
 
 鼓励开发者在学习、开发过程中，总结经验并创建技术内容帮助更多开发者快速上手。推荐输出各类How to教程、常见问题FAQ等。请参考如下写作模板：
 
--   [How to教程](tutorial-title-task-name.md)
--   [FAQ](faq-template.md)
+-   [How to教程](template/tutorial-template.md)
+-   [FAQ](template/faq-template.md)
 
 内容写作模板归档在Docs文档仓下contribute文件夹中。
 

zh-cn/device-dev/subsystems/subsys-security-communicationverify.md

@@ -41,7 +41,7 @@ IPC通信鉴权提供的API，仅供Samgr调用，开发者在开发服务时需
 
 本部分以BMS服务通过IPC通信方式对外开放接口为例，讲解如何通过IPC通信鉴权组件配置对应接口的访问策略。这里BMS在Samgr中注册的service为bundlems，为开放的接口注册的Feature为BmsFeature。
 
-1.  鸿蒙侧在源码路径下的头文件base/security/permission/services/permission\_lite/ipc\_auth/include/policy\_preset.h中配置相应的访问策略，产品侧独有的在vendor/hisilicon/产品名称/hals/security/permission\_lite/ipc\_auth/include/policy\_preset\_product.h中配置相应的访问策略，配置策略后将头文件中的宏POLICY\_PRODUCT 配置为1；访问策略主要有三种类型：
+1.  OpenHarmony侧在源码路径下的头文件base/security/permission/services/permission\_lite/ipc\_auth/include/policy\_preset.h中配置相应的访问策略，产品侧独有的在vendor/hisilicon/产品名称/hals/security/permission\_lite/ipc\_auth/include/policy\_preset\_product.h中配置相应的访问策略，配置策略后将头文件中的宏POLICY\_PRODUCT 配置为1；访问策略主要有三种类型：
 
     （1）type为RANGE类型：允许某个特定范围UID的进程访问，需要指定uidMin和uidMax；