10分鐘快速掌握OpenHarmony社區(qū)貢獻新流程

先回顧下社區(qū)Issue和PR處理時存在的問題痛點。經(jīng)常關(guān)注社區(qū)的開發(fā)者會注意到，社區(qū)待處理的Issue和PR數(shù)量多的時候，處理速度會變得緩慢。導(dǎo)致Issue和PR不能有效處理的原因主要有：從社區(qū)貢獻者一側(cè)來分析，社區(qū)Issue和PR未規(guī)范提交，比如Issue描述不規(guī)范，缺少詳細(xì)描述和驗證步驟等關(guān)鍵信息；PR門禁編譯失敗、格式檢測失敗、門禁檢查失敗，DCO失敗、未參考檢視意見修改等，這些因素都會導(dǎo)致請求無法被處理而不能被合入。從社區(qū)貢獻流程側(cè)來分析，社區(qū)Issue和PR處理流程也存在一些改進點，比如當(dāng)前缺少Issue責(zé)任人精準(zhǔn)分配；缺少機制分配PR檢視人，PR處理階段不清晰；缺少處理超期時的主動提醒功能等；對超期的Issue和PR，系統(tǒng)不能自動處理等。

OpenHarmony社區(qū)為解決上述問題，對Issue和PR處理流程進行了優(yōu)化，主要包含：

●標(biāo)記狀態(tài)標(biāo)簽，明確處理階段責(zé)任人

通過標(biāo)記狀態(tài)標(biāo)簽識別處理責(zé)任階段、明確處理人。如果Issue和PR提交不規(guī)范，會有狀態(tài)標(biāo)簽顯示當(dāng)前處理責(zé)任人為提交人；如果提交的PR通過門禁測試，等待審核檢視，當(dāng)前處理責(zé)任人為Committer；如果已分配檢視人員，當(dāng)前處理責(zé)任人就是代碼檢視人員等。

●主動提醒責(zé)任人處理待辦事項

CI Bot會發(fā)郵件每日提醒責(zé)任人處理名下的待辦事項。強烈建議社區(qū)貢獻者訂閱Issue和PR的狀態(tài)變化通知，這樣就會接收系統(tǒng)的自動提醒。

●超期問題自動處理

基于規(guī)則，對于一些可以自動處理的情況進行分析，進行自動化處理。比如，對于驗收中的Issue，如果長期未確認(rèn)，系統(tǒng)會自動進行關(guān)閉；對于門禁未通過等情況導(dǎo)致不符合合入標(biāo)準(zhǔn)的PR，超過一定時間，也會自動關(guān)閉。

OpenHarmony社區(qū)通過這些流程優(yōu)化來提升Issue和PR處理效率，下文會詳細(xì)介紹流程的優(yōu)化點和具體使用方法。

以PR提交與審核流程為例，如圖1所示，我們按狀態(tài)標(biāo)簽進行講解，開發(fā)者們也可以參考

PR提交人（社區(qū)貢獻者）創(chuàng)建PR后，PR的標(biāo)簽為Waiting_On_Author，表示當(dāng)前的責(zé)任人為PR提交人。CI Bot會提醒PR提交人及時處理該PR。如果PR提交人長時期未處理該PR，CI Bot會進行自動關(guān)閉。

如果PR提交人觸發(fā)門禁構(gòu)建，構(gòu)建失敗后，PR的標(biāo)簽依舊為Waiting_On_Author狀態(tài)。如果檢視人員或Committer審核人員提交了檢視意見，需要社區(qū)貢獻者去查看、修復(fù)，PR的標(biāo)簽會被標(biāo)記為Waiting_On_Author狀態(tài)。

當(dāng)PR提交人評論命令start build（倉庫配置門禁時使用該命令，如果未配置門禁，請使用code review命令），并且門禁構(gòu)建成功后，PR的狀態(tài)標(biāo)簽替代為Waiting_For_Review狀態(tài)，表示當(dāng)前的責(zé)任人為Committer審核人員，需要由Committer分配檢視人員。CI Bot可以每日郵件定時提醒待辦事項，催促Committer分配檢視人員。

Committer可以通過命令assign [@gitee_id1 @gitee_id2...]分配檢視人員。使用該命令時，Committer可以通過空格分隔來指定多個檢視人員；如果命令中不指定gitee_id，Committer則安排自己為檢視人員。分配檢視人員后，PR的狀態(tài)標(biāo)簽變換為Reviewing狀態(tài)，表示當(dāng)前的責(zé)任人為代碼檢視人員。

分配的檢視人員需參與檢視，給出檢視意見，然后評論命令check comment提醒PR提交人處理；無檢視意見時，評論命令lgtm，提醒Committer審核處理。

當(dāng)所有檢視人員均對分配的PR沒有檢視意見時，并在PR評論區(qū)評論命令lgtm后，CI Bot會提醒Committer去審核該PR。此時，PR的狀態(tài)標(biāo)簽變換為Waiting_For_Merge狀態(tài)。

對于Waiting_For_Merge狀態(tài)標(biāo)簽的PR， 當(dāng)Committer審核通過后，PR的狀態(tài)標(biāo)簽會自動變換為Merged狀態(tài)，表示該PR成功合入。

本節(jié)以Pull Request處理流程為例，按處理階段分別進行講解。

當(dāng)PR提交人提交一個PR后，CI Bot會自動評論，如下圖所示。根據(jù)提示，如果代碼已經(jīng)開發(fā)完畢，PR提交人在PR評論區(qū)評論start build來觸發(fā)門禁。在觸發(fā)門禁前狀態(tài)標(biāo)簽為Waiting_On_Author，當(dāng)前的處理責(zé)任人為PR提交人。

如果審核檢視人員為PR提交檢視建議后，PR的狀態(tài)標(biāo)簽變?yōu)閃aiting_On_Author，需要PR提交人處理建議，優(yōu)化修復(fù)提交的代碼。當(dāng)處理完畢，重新推送代碼后，需要重新觸發(fā)門禁。

注意：如果代碼倉沒有配置門禁，提示的內(nèi)容稍有不同，需要評論的命令是code view。

在門禁通過后，PR的狀態(tài)標(biāo)簽會替換為Waiting_For_Review狀態(tài)，如下圖所示。此后，該PR的處理責(zé)任人為代碼倉的Committer。Committer會負(fù)責(zé)分配檢視人員或者審核該PR。

當(dāng)一個PR處于Waiting_For_Review狀態(tài)時，Committer可以使用assign命令分配給檢視人員進行檢視，如下圖所示。命令assign的具體用法，可以參考上一小節(jié)圖片中的操作提示。當(dāng)分配完畢檢視人員，PR的狀態(tài)標(biāo)簽會替換為Reviewing狀態(tài)，當(dāng)前的處理責(zé)任人為分配的檢視人員。

如果檢視人員發(fā)現(xiàn)檢視的PR存在問題，提出檢視意見后，需要評論下check comment通知PR提交人根據(jù)檢視意見進行修改。PR的狀態(tài)標(biāo)簽會替代為Waiting_On_Author狀態(tài)，當(dāng)前的處理責(zé)任人為PR提交人。

如果PR不存在問題，檢視人員認(rèn)為可以合入，需要評論下lgtm（即：look good to me）通知Committer審核合入該PR。PR的狀態(tài)標(biāo)簽會替代為Waiting_For_Merge狀態(tài)，當(dāng)前的處理責(zé)任人為Committer。

本文對OpenHarmony社區(qū)貢獻流程優(yōu)化點進行了介紹，包含新支持的一系列交互命令和狀態(tài)標(biāo)簽，以及CI Bot的每日待辦事項郵件、自動超期處理等。如有疑問，歡迎隨時來社區(qū)反饋。