写在最前面
openUBMC的组件代码仓库均被SIG组进行管理，按照不同的功能领域分为不同的SIG组进行管理。具体SIG组以及组件的管理范围请参考( SIG中心 | openUBMC)
社区上进行代码开发，那么避免不了提交PR。openUBMC社区提交代码PR需要满足以下条件：
- 提交的PR描述需要采用统一的范式
- 提交的PR必须关联issue
- 【可选】提交的PR涉及接口则需要在PR的描述中增加 interface SIG 的评审帖链接（评审帖必须是关闭状态）
PR描述范式
PR提交之时，意味着当前的代码仓库中的文件必定发生了变化，那么PR的描述上就要做到 言之有物。常见的变化场景有两种：
- 修复问题类：对于历史代码中存在的问题进行修复，情况包括但不限于：代码错误，拼写错误，文档资料错误，功能错误等
- 新增功能类：相比于历史代码，需要新增加代码来支持新的功能，情况包括但不限于：新的特性支持，新的规范支持，新的硬件支持，新的接口支持等
因此，针对上述两种场景，PR的描述范式参考如下：
- 修复问题类：
【修改描述】修复XXX问题，比如：修复Redfish查询版本的提示显示问题 - 新增功能类：
【修改描述】支持XXX功能，比如：支持Redfish接口查询BMC厂商
PR必须关联issue
PR提交之时，意味着当前的代码仓库中的功能必定发生了变化，那么PR在结构上就要做到 言之有据。因此对应的PR提交时必须要关联 issue。
关联 issue
具体的 PR 关联 issue 的地方如下图，点击之后会弹出当前组件仓库未关闭的 issue：
那么就有另外一个问题：如果当前未关闭的 issue 中没有当前 PR 需要的 issue 时如何处理？
答复就是：新建一个 issue
创建 issue
第一步，在对应的代码仓库的首页，进入到 issue 页面（如下图），然后点击 新建 issue：
第二步，选择对应的 issue 模板，如下图：
第三步，填写 issue 的内容，并且点击 创建，如下图：
填写说明：
- issue 类型：根据上面说的 #PR描述范式 来进行填写，如果是修复问题，则选择 缺陷；如果时新增功能，则选择 需求。（备注：当前 任务 类型暂时不需要选择）
- 负责人：可以配置自己，或者是期望谁来解决这个问题的人
- 标题：当前 issue 的标题，就一句话具体描述问题，或者需求（尽量描述成句子）
- 内容：当前 issue 具体的内容，如果是问题，则可以根据三要素原则（背景，现象，预期）描述当前的问题；如果是需求，则可以根据结构化进行描述（包括但不限于需求是什么，给谁用，怎么用，在哪儿用，有什么规格限制等）
【可选】接口的变更类PR关联评审纪要
常见的接口变更类型
- 资源协作接口，包括资源协作类，属性，方法，信号，错误引擎
- 北向接口，包括：CLI/Redfish/WebUI/WebRest/SNMP
- 配置类接口，包括：定制化项，配置导入导出项
- 其他接口，包括：协作接口或者私有类型的CSR配置，持久化配置
PR提交要求以及指导
对于接口的变更类PR（如：接口新增，修改，行为变化，返回信息，错误码等），在PR的描述中需要增加对应的 interface SIG 的评审帖子链接，PR合入的前提是帖子已经进行评审并且归档关闭。
- 接口变更评审以及处理 快速入口：>> 前往社区论坛接口评审专区
- 接口评审的要求可以参考：>> 前往接口评审流程
PR提交样例
PR：bmc.kepler.CertificateService.CA资源下新增RedfishSchemaVersion属性
