快速掌握OpenHarmony社區貢獻新流程
為提升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的每日待辦事項郵件、自動超期處理等。
