10分钟快速掌握OpenHarmony社区贡献新流程
点击蓝字 ╳ 关注我们
开源项目 openharmony是每个人的 openharmony
为提升issue和pr（pull request）的处理效率，openatom openharmony(以下简称openharmony)社区优化了issue和pr处理流程，新支持了一系列交互命令和状态标签，用于明确处理阶段和当前处理责任人。社区ci bot工具还提供了待办事项提醒能力，并能自动处理超期无效issue和pr。流程交互更加友好，基于交互提示，还可以获知下一步需要如何操作。本文会对社区贡献流程优化点进行介绍，不管你是社区贡献的专家还是初涉开源社区的新手，都有必要花几分钟快速熟悉下openharmony社区贡献流程的新优化点。流程也在持续优化中，如有变化，请以最新的为准。需要注意的是，流程优化是为了辅助社区参与者提升效率，不会影响既有流程。如果不使用新支持的交互命令和状态标签，也可以使用既有流程正常处理issue和pr。但是，强烈推荐大家使用这些新优化后的功能，这样可以明确当前处理责任人人，让issue和pr更及时地得到响应处理。
1、新流程能解决什么问题
先回顾下社区issue和pr处理时存在的问题痛点。经常关注社区的开发者会注意到，社区待处理的issue和pr数量多的时候，处理速度会变得缓慢。导致issue和pr不能有效处理的原因主要有：从社区贡献者一侧来分析，社区issue和pr未规范提交，比如issue描述不规范，缺少详细描述和验证步骤等关键信息；pr门禁编译失败、格式检测失败、门禁检查失败，dco失败、未参考检视意见修改等，这些因素都会导致请求无法被处理而不能被合入。从社区贡献流程侧来分析，社区issue和pr处理流程也存在一些改进点，比如当前缺少issue责任人精准分配；缺少机制分配pr检视人，pr处理阶段不清晰；缺少处理超期时的主动提醒功能等；对超期的issue和pr，系统不能自动处理等。
openharmony社区为解决上述问题，对issue和pr处理流程进行了优化，主要包含：
●标记状态标签，明确处理阶段责任人
通过标记状态标签识别处理责任阶段、明确处理人。如果issue和pr提交不规范，会有状态标签显示当前处理责任人为提交人；如果提交的pr通过门禁测试，等待审核检视，当前处理责任人为committer；如果已分配检视人员，当前处理责任人就是代码检视人员等。
●主动提醒责任人处理待办事项
ci bot会发邮件每日提醒责任人处理名下的待办事项。强烈建议社区贡献者订阅issue和pr的状态变化通知，这样就会接收系统的自动提醒。
●超期问题自动处理
基于规则，对于一些可以自动处理的情况进行分析，进行自动化处理。比如，对于验收中的issue，如果长期未确认，系统会自动进行关闭；对于门禁未通过等情况导致不符合合入标准的pr，超过一定时间，也会自动关闭。
openharmony社区通过这些流程优化来提升issue和pr处理效率，下文会详细介绍流程的优化点和具体使用方法。
2、新流程介绍
以pr提交与审核流程为例，如图1所示，我们按状态标签进行讲解，开发者们也可以参考
https://gitee.com/openharmony/community/blob/master/zh/infrastructure/build_command.md
图1 pr审核处理流程图
2.1 waiting_on_author状态标签pr提交人（社区贡献者）创建pr后，pr的标签为waiting_on_author，表示当前的责任人为pr提交人。ci bot会提醒pr提交人及时处理该pr。如果pr提交人长时期未处理该pr，ci bot会进行自动关闭。
如果pr提交人触发门禁构建，构建失败后，pr的标签依旧为waiting_on_author状态。如果检视人员或committer审核人员提交了检视意见，需要社区贡献者去查看、修复，pr的标签会被标记为waiting_on_author状态。
2.2 waiting_for_review状态标签当pr提交人评论命令start build（仓库配置门禁时使用该命令，如果未配置门禁，请使用code review命令），并且门禁构建成功后，pr的状态标签替代为waiting_for_review状态，表示当前的责任人为committer审核人员，需要由committer分配检视人员。ci bot可以每日邮件定时提醒待办事项，催促committer分配检视人员。
2.3 reviewing状态标签committer可以通过命令assign [@gitee_id1 @gitee_id2...]分配检视人员。使用该命令时，committer可以通过空格分隔来指定多个检视人员；如果命令中不指定gitee_id，committer则安排自己为检视人员。分配检视人员后，pr的状态标签变换为reviewing状态，表示当前的责任人为代码检视人员。
分配的检视人员需参与检视，给出检视意见，然后评论命令check comment提醒pr提交人处理；无检视意见时，评论命令lgtm，提醒committer审核处理。
2.4 waiting_for_merge状态标签当所有检视人员均对分配的pr没有检视意见时，并在pr评论区评论命令lgtm后，ci bot会提醒committer去审核该pr。此时，pr的状态标签变换为waiting_for_merge状态。
2.5 merged 状态标签对于waiting_for_merge状态标签的pr， 当committer审核通过后，pr的状态标签会自动变换为merged状态，表示该pr成功合入。
3、流程处理实例讲解
本节以pull request处理流程为例，按处理阶段分别进行讲解。
3.1 提交修改pull request当pr提交人提交一个pr后，ci bot会自动评论，如下图所示。根据提示，如果代码已经开发完毕，pr提交人在pr评论区评论start build来触发门禁。在触发门禁前状态标签为waiting_on_author，当前的处理责任人为pr提交人。
图2 新pr交互截图
如果审核检视人员为pr提交检视建议后，pr的状态标签变为waiting_on_author，需要pr提交人处理建议，优化修复提交的代码。当处理完毕，重新推送代码后，需要重新触发门禁。
注意：如果代码仓没有配置门禁，提示的内容稍有不同，需要评论的命令是code view。
3.2 门禁构建在门禁通过后，pr的状态标签会替换为waiting_for_review状态，如下图所示。此后，该pr的处理责任人为代码仓的committer。committer会负责分配检视人员或者审核该pr。
图3 门禁构建成功截图
3.3 代码检视当一个pr处于waiting_for_review状态时，committer可以使用assign命令分配给检视人员进行检视，如下图所示。命令assign的具体用法，可以参考上一小节图片中的操作提示。当分配完毕检视人员，pr的状态标签会替换为reviewing状态，当前的处理责任人为分配的检视人员。
图4分配检视人员截图
如果检视人员发现检视的pr存在问题，提出检视意见后，需要评论下check comment通知pr提交人根据检视意见进行修改。pr的状态标签会替代为waiting_on_author状态，当前的处理责任人为pr提交人。
图5提醒处理检视意见截图
如果pr不存在问题，检视人员认为可以合入，需要评论下lgtm（即：look good to me）通知committer审核合入该pr。pr的状态标签会替代为waiting_for_merge状态，当前的处理责任人为committer。
图6提醒审核合入截图
3.4 审核合入当代码仓committer认为pr满足合入要求，审核通过后，pr会被合入，此时pr的状态标签会替代为merged状态，则pr成功被合入。
图7审核合入截图
4、ci bot待办提醒
通过状态标签识别当前处理责任人后，就可以获取责任人的待办事项。通过记录打标签的开始时间，就可以计算当前处理阶段停留时间，从而可以发邮件提醒及时处理待办事项，并能自动化处理超期无效的issue和pr。发邮件功能可以自行选择是否订阅。
4.1 每日待办提醒如果你在社区有待办事项，社区会自动汇总并自动发邮件给你，提醒你及时处理。如果不想收到邮件，可以取消订阅。但强烈推荐你保持订阅，可以及时收到在社区的待办事项。下图为收到的待办事项邮件示例。
图8 待办事项邮件截图
4.2 自动超期处理对于pr，审核检视人员需要及时响应处理；pr提交人也需要及时响应反馈的检视意见，如果长期未响应，不符合合入标准的pr，会在30天后被自动关闭。这样做是为了保持一个干净的社区贡献环境，也不用担心丢失代码，被关闭的pr也可以很容易被pr提交人重新打开。对于issue，如果社区审核人员认为需要补充信息，或不能算做问题，以及需要issue验收确认时，如果issue提交人30天未响应，也会被自动关闭处理。在关闭之前，系统会发送提醒。请保持关注issue和pr的变更信息。如下图所示：
图9 自动超期处理截图
5、小结
本文对openharmony社区贡献流程优化点进行了介绍，包含新支持的一系列交互命令和状态标签，以及ci bot的每日待办事项邮件、自动超期处理等。如有疑问，欢迎随时来社区反馈。
原文标题：10分钟快速掌握openharmony社区贡献新流程
文章出处：【微信公众号：openatom openharmony】欢迎添加关注！文章转载请注明出处。
运动DVBGA芯片底部填充胶应用案例分析
如何围绕SIMO核心转换器量身定制的集成式电源管理方法
浪潮信息以新一代存储核心构建新一代集中式和分布式存储平台
英威腾光伏助力兰顺科技用光线“织”出绿色未来
科学家用无人机清洁医院，减少传染性疾病
10分钟快速掌握OpenHarmony社区贡献新流程
坐标转换的计算公式
基于HMC1022和HMC1021三轴磁阻传感器模块设计
对PLD进行边界扫描（JTAG）故障诊断
Qi标准v1.2.4最新版本发布，无线充电方案再解读
联电豪华律师团成晋华案致胜关键！
笔记本概述
小米27英寸电竞显示屏上架：支持165Hz高刷新率
卡萨帝的超速增长动力 来自超预期的产品力
基于AT89C51单片机在变频调速恒压供水系统中的应用
自整流V型皮托管式流量计的特点
沐渥剖析2022年线路板最新生产工艺流程
Mislatel财团已获得CPCN电信运营牌照将成为菲律宾第三大电信运营商
Ubuntu官方发布适配全志D1-H哪吒开发板的镜像
腾讯医典公布了一季度短视频供应商排行榜
开源项目 openharmony是每个人的 openharmony
为提升issue和pr（pull request）的处理效率，openatom openharmony(以下简称openharmony)社区优化了issue和pr处理流程，新支持了一系列交互命令和状态标签，用于明确处理阶段和当前处理责任人。社区ci bot工具还提供了待办事项提醒能力，并能自动处理超期无效issue和pr。流程交互更加友好，基于交互提示，还可以获知下一步需要如何操作。本文会对社区贡献流程优化点进行介绍，不管你是社区贡献的专家还是初涉开源社区的新手，都有必要花几分钟快速熟悉下openharmony社区贡献流程的新优化点。流程也在持续优化中，如有变化，请以最新的为准。需要注意的是，流程优化是为了辅助社区参与者提升效率，不会影响既有流程。如果不使用新支持的交互命令和状态标签，也可以使用既有流程正常处理issue和pr。但是，强烈推荐大家使用这些新优化后的功能，这样可以明确当前处理责任人人，让issue和pr更及时地得到响应处理。
1、新流程能解决什么问题
先回顾下社区issue和pr处理时存在的问题痛点。经常关注社区的开发者会注意到，社区待处理的issue和pr数量多的时候，处理速度会变得缓慢。导致issue和pr不能有效处理的原因主要有：从社区贡献者一侧来分析，社区issue和pr未规范提交，比如issue描述不规范，缺少详细描述和验证步骤等关键信息；pr门禁编译失败、格式检测失败、门禁检查失败，dco失败、未参考检视意见修改等，这些因素都会导致请求无法被处理而不能被合入。从社区贡献流程侧来分析，社区issue和pr处理流程也存在一些改进点，比如当前缺少issue责任人精准分配；缺少机制分配pr检视人，pr处理阶段不清晰；缺少处理超期时的主动提醒功能等；对超期的issue和pr，系统不能自动处理等。
openharmony社区为解决上述问题，对issue和pr处理流程进行了优化，主要包含：
●标记状态标签，明确处理阶段责任人
通过标记状态标签识别处理责任阶段、明确处理人。如果issue和pr提交不规范，会有状态标签显示当前处理责任人为提交人；如果提交的pr通过门禁测试，等待审核检视，当前处理责任人为committer；如果已分配检视人员，当前处理责任人就是代码检视人员等。
●主动提醒责任人处理待办事项
ci bot会发邮件每日提醒责任人处理名下的待办事项。强烈建议社区贡献者订阅issue和pr的状态变化通知，这样就会接收系统的自动提醒。
●超期问题自动处理
基于规则，对于一些可以自动处理的情况进行分析，进行自动化处理。比如，对于验收中的issue，如果长期未确认，系统会自动进行关闭；对于门禁未通过等情况导致不符合合入标准的pr，超过一定时间，也会自动关闭。
openharmony社区通过这些流程优化来提升issue和pr处理效率，下文会详细介绍流程的优化点和具体使用方法。
2、新流程介绍
以pr提交与审核流程为例，如图1所示，我们按状态标签进行讲解，开发者们也可以参考
https://gitee.com/openharmony/community/blob/master/zh/infrastructure/build_command.md
图1 pr审核处理流程图
2.1 waiting_on_author状态标签pr提交人（社区贡献者）创建pr后，pr的标签为waiting_on_author，表示当前的责任人为pr提交人。ci bot会提醒pr提交人及时处理该pr。如果pr提交人长时期未处理该pr，ci bot会进行自动关闭。
如果pr提交人触发门禁构建，构建失败后，pr的标签依旧为waiting_on_author状态。如果检视人员或committer审核人员提交了检视意见，需要社区贡献者去查看、修复，pr的标签会被标记为waiting_on_author状态。
2.2 waiting_for_review状态标签当pr提交人评论命令start build（仓库配置门禁时使用该命令，如果未配置门禁，请使用code review命令），并且门禁构建成功后，pr的状态标签替代为waiting_for_review状态，表示当前的责任人为committer审核人员，需要由committer分配检视人员。ci bot可以每日邮件定时提醒待办事项，催促committer分配检视人员。
2.3 reviewing状态标签committer可以通过命令assign [@gitee_id1 @gitee_id2...]分配检视人员。使用该命令时，committer可以通过空格分隔来指定多个检视人员；如果命令中不指定gitee_id，committer则安排自己为检视人员。分配检视人员后，pr的状态标签变换为reviewing状态，表示当前的责任人为代码检视人员。
分配的检视人员需参与检视，给出检视意见，然后评论命令check comment提醒pr提交人处理；无检视意见时，评论命令lgtm，提醒committer审核处理。
2.4 waiting_for_merge状态标签当所有检视人员均对分配的pr没有检视意见时，并在pr评论区评论命令lgtm后，ci bot会提醒committer去审核该pr。此时，pr的状态标签变换为waiting_for_merge状态。
2.5 merged 状态标签对于waiting_for_merge状态标签的pr， 当committer审核通过后，pr的状态标签会自动变换为merged状态，表示该pr成功合入。
3、流程处理实例讲解
本节以pull request处理流程为例，按处理阶段分别进行讲解。
3.1 提交修改pull request当pr提交人提交一个pr后，ci bot会自动评论，如下图所示。根据提示，如果代码已经开发完毕，pr提交人在pr评论区评论start build来触发门禁。在触发门禁前状态标签为waiting_on_author，当前的处理责任人为pr提交人。
图2 新pr交互截图
如果审核检视人员为pr提交检视建议后，pr的状态标签变为waiting_on_author，需要pr提交人处理建议，优化修复提交的代码。当处理完毕，重新推送代码后，需要重新触发门禁。
注意：如果代码仓没有配置门禁，提示的内容稍有不同，需要评论的命令是code view。
3.2 门禁构建在门禁通过后，pr的状态标签会替换为waiting_for_review状态，如下图所示。此后，该pr的处理责任人为代码仓的committer。committer会负责分配检视人员或者审核该pr。
图3 门禁构建成功截图
3.3 代码检视当一个pr处于waiting_for_review状态时，committer可以使用assign命令分配给检视人员进行检视，如下图所示。命令assign的具体用法，可以参考上一小节图片中的操作提示。当分配完毕检视人员，pr的状态标签会替换为reviewing状态，当前的处理责任人为分配的检视人员。
图4分配检视人员截图
如果检视人员发现检视的pr存在问题，提出检视意见后，需要评论下check comment通知pr提交人根据检视意见进行修改。pr的状态标签会替代为waiting_on_author状态，当前的处理责任人为pr提交人。
图5提醒处理检视意见截图
如果pr不存在问题，检视人员认为可以合入，需要评论下lgtm（即：look good to me）通知committer审核合入该pr。pr的状态标签会替代为waiting_for_merge状态，当前的处理责任人为committer。
图6提醒审核合入截图
3.4 审核合入当代码仓committer认为pr满足合入要求，审核通过后，pr会被合入，此时pr的状态标签会替代为merged状态，则pr成功被合入。
图7审核合入截图
4、ci bot待办提醒
通过状态标签识别当前处理责任人后，就可以获取责任人的待办事项。通过记录打标签的开始时间，就可以计算当前处理阶段停留时间，从而可以发邮件提醒及时处理待办事项，并能自动化处理超期无效的issue和pr。发邮件功能可以自行选择是否订阅。
4.1 每日待办提醒如果你在社区有待办事项，社区会自动汇总并自动发邮件给你，提醒你及时处理。如果不想收到邮件，可以取消订阅。但强烈推荐你保持订阅，可以及时收到在社区的待办事项。下图为收到的待办事项邮件示例。
图8 待办事项邮件截图
4.2 自动超期处理对于pr，审核检视人员需要及时响应处理；pr提交人也需要及时响应反馈的检视意见，如果长期未响应，不符合合入标准的pr，会在30天后被自动关闭。这样做是为了保持一个干净的社区贡献环境，也不用担心丢失代码，被关闭的pr也可以很容易被pr提交人重新打开。对于issue，如果社区审核人员认为需要补充信息，或不能算做问题，以及需要issue验收确认时，如果issue提交人30天未响应，也会被自动关闭处理。在关闭之前，系统会发送提醒。请保持关注issue和pr的变更信息。如下图所示：
图9 自动超期处理截图
5、小结
本文对openharmony社区贡献流程优化点进行了介绍，包含新支持的一系列交互命令和状态标签，以及ci bot的每日待办事项邮件、自动超期处理等。如有疑问，欢迎随时来社区反馈。
原文标题：10分钟快速掌握openharmony社区贡献新流程
文章出处：【微信公众号：openatom openharmony】欢迎添加关注！文章转载请注明出处。
运动DVBGA芯片底部填充胶应用案例分析
如何围绕SIMO核心转换器量身定制的集成式电源管理方法
浪潮信息以新一代存储核心构建新一代集中式和分布式存储平台
英威腾光伏助力兰顺科技用光线“织”出绿色未来
科学家用无人机清洁医院，减少传染性疾病
10分钟快速掌握OpenHarmony社区贡献新流程
坐标转换的计算公式
基于HMC1022和HMC1021三轴磁阻传感器模块设计
对PLD进行边界扫描（JTAG）故障诊断
Qi标准v1.2.4最新版本发布，无线充电方案再解读
联电豪华律师团成晋华案致胜关键！
笔记本概述
小米27英寸电竞显示屏上架：支持165Hz高刷新率
卡萨帝的超速增长动力 来自超预期的产品力
基于AT89C51单片机在变频调速恒压供水系统中的应用
自整流V型皮托管式流量计的特点
沐渥剖析2022年线路板最新生产工艺流程
Mislatel财团已获得CPCN电信运营牌照将成为菲律宾第三大电信运营商
Ubuntu官方发布适配全志D1-H哪吒开发板的镜像
腾讯医典公布了一季度短视频供应商排行榜