想了解更多关于开源的内容，请访问：

51CTO 开源基础软件社区

https://ost.51cto.com

为提升Issue和PR(Pull Request)的处理效率，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处理效率，比如当前缺少Issue责任人精准分配；缺少机制分配PR检视人，PR处理阶段不清晰；缺少处理超期时主动提醒功能等；对超期的Issue和PR不能自动处理等。

OpenHarmony社区为解决上述问题，对Issue和PR处理流程进行了优化，主要包含：

• 标记状态标签明确处理阶段责任人.
  通过标记状态标签识别处理责任阶段、明确处理人。如果Issue和PR提交不规范，会有标签显示当前处理责任人为提交人；如果提交的PR通过门禁测试，等待审核检视，当前处理责任人为committer；如果已分配检视人员，当前处理责任人就是代码检视人员，等等。
• 主动提醒责任人处理待办事项.
  CI Bot会发邮件每日提醒责任人处理名下的待办事项。是否接收邮件可以通过订阅配置。
• 超期问题自动处理.
  基于规则，对于一些可以自动处理的情况进行分析，进行自动化处理。比如，对于验收中的Issue，如果长期未确认，会自动进行关闭；对于门禁未通过等情况导致不符合合入标准的PR，超过一定时间，会自动关闭。

OpenHarmony社区通过这些流程优化来提升Issue和PR处理效率，下文会详细介绍流程的优化点和具体使用方法。

2、新流程介绍

以PR流程为例介绍新流程，如图1所示。我们按状态标签来分别讲解，也可以参考OpenHarmony社区Pull Request&Issue评论支持命令清单。

（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）Waiting_For_Review状态标签

当PR提交人评论start build（仓库配置门禁时使用该命令，如果未配置门禁，请使用code review命令），并且门禁构建成功后，PR的状态标签替代为Waiting_For_Review状态，表示表示当前的责任人为committer审核人员，需要由committer分配检视人员。CI Bot可以每日邮件定时提醒待办事项，催促分配检视人员。

（3）Reviewing状态标签

Committer可以通过assign [@gitee_id1 @gitee_id2...]分配检视人员，可以通过空格分割来指定多个检视人员；如果命令中不指定gitee_id，committer安排自己为检视人员。分配检视人员后，PR的状态标签替代为Reviewing状态，表示当前的责任人为代码检视人员。

分配的检视人员需参与检视，给出检视意见，然后评论命令check comment提醒PR提交人处理；无检视意见时，评论命令lgtm，提醒committer审核处理。

（4） Waiting_For_Merge状态标签

当所有检视人员均对分配的PR没有检视意见时，并在PR评论区评论命令lgtm后，CI Bot会提醒committer去审核该PR。此时，PR的状态标签变换为Waiting_For_Merge状态，表示当前的责任人为committer审核人员。

（5）Merged 状态标签

对于Waiting_For_Merge状态标签的PR， 当committer审核通过后，PR的状态标签会自动变换为Merged状态，表示该PR成功合入。

图1 PR审核处理流程图

3、流程处理实例讲解

本节以Pull Request处理流程来讲解，按PR的处理阶段分别来讲解。

（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。

（2）门禁构建

在门禁通过后，PR的状态标签会替代为Waiting_For_Review状态，如下图所示。此后，该PR的处理责任人为代码仓的Committer。Committer会负责分配检视人员或者审核该PR。

图3 门禁构建成功截图

（3）代码检视

当一个PR处于Waiting_For_Review状态时，Committer可以使用assign命令分配给检视人员进行检视，如下图所示。命令assign的具体用法，可以参考上一小节图片中的操作提示。当分配完毕检视人员，PR的状态标签会替代为Waiting_For_Review状态，当前的处理责任人为分配的检视人员。

图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提醒审核合入截图

（4）审核合入

当代码仓Committer认为PR满足合入要求，审核通过后，PR会合入，此时PR的状态标签会替代为Merged状态，PR成功合入。

图7审核合入截图

4、CI Bot待办提醒

通过状态标签识别当前处理责任人后，就可以获取责任人的待办事项。通过记录打标签的开始时间，就可以计算当前处理阶段停留时间，从而可以发邮件提醒及时处理待办事项，并能自动化处理超期无效的Issue和PR。发邮件功能可以自行选择是否订阅。

（1）每日待办提醒

如果您在社区有待办事项，社区会自动汇总并自动发邮件给您，提醒您及时处理。如果不想收到邮件，可以取消订阅。强烈推荐您保持订阅，可以及时收到在社区的待办事项。下图为收到的待办事项邮件示例。

图8 待办事项邮件截图

（2）自动超期处理

对于PR，审核检视人员需要及时响应处理；PR提交人也需要及时响应反馈的检视意见，如果长期未响应，不符合合入标准的PR，会在30天后被自动关闭。这样做是为了保持一个干净的社区贡献环境，也不用担心丢失代码，被关闭的PR也可以很容易被PR提交人重新打开。对于Issue，如果社区审核人员认为需要补充信息，非问题，以及需要issue验收确认时，如果issue提交人30天未响应，也会被自动关闭处理。在关闭之后，会提醒，请保持关注Issue和PR的变更信息。如下图所示：

图9 自动超期处理截图

5、小结

本文对OpenHarmony社区贡献流程优化点进行了介绍，包含新支持的一系列交互命令和状态标签，以及CI Bot的每日待办事项邮件、自动超期处理等。

想了解更多关于开源的内容，请访问：

51CTO 开源基础软件社区

https://ost.51cto.com