快速掌握OpenHarmony社區(qū)貢獻(xiàn)新流程
想了解更多關(guān)于開源的內(nèi)容，請(qǐng)?jiān)L問：
為提升Issue和PR(Pull Request)的處理效率，OpenHarmony社區(qū)優(yōu)化了Issue和PR處理流程，新支持了一系列交互命令和狀態(tài)標(biāo)簽，用于明確處理階段和當(dāng)前處理責(zé)任人。社區(qū)CI Bot工具還提供了待辦事項(xiàng)提醒能力，并能自動(dòng)處理超期無效Issue和PR。流程交互更加友好，基于交互提示，可以獲知下一步需要如何操作。本文會(huì)對(duì)社區(qū)貢獻(xiàn)流程優(yōu)化點(diǎn)進(jìn)行介紹，不管您是社區(qū)貢獻(xiàn)的老專家還是初涉開源社區(qū)的新手，都有必要花幾分鐘快速熟悉下OpenHarmony社區(qū)貢獻(xiàn)流程的新優(yōu)化點(diǎn)。流程也在持續(xù)優(yōu)化中，如有變化，請(qǐng)以最新的為準(zhǔn)。
需要注意的是，流程優(yōu)化是為了輔助社區(qū)參與者提升處理效率，不會(huì)影響既有流程。如果不使用新支持的交互命令和狀態(tài)標(biāo)簽，也可以使用既有流程正常處理Issue和PR。但是強(qiáng)烈推薦大家使用這些新優(yōu)化功能，通過可以明確當(dāng)前處理人，讓Issue和PR更及時(shí)地得到響應(yīng)處理。
1、新流程能解決什么問題
先回顧下社區(qū)Issue和PR處理時(shí)存在的問題痛點(diǎn)。經(jīng)常關(guān)注社區(qū)的開發(fā)者會(huì)注意到，社區(qū)上未閉環(huán)的Issue和PR數(shù)量比較多，處理速度也比較緩慢。導(dǎo)致Issue和PR不能有效處理的原因主要是：社區(qū)Issue和PR未規(guī)范處理，比如Issue描述不規(guī)范，缺少詳細(xì)描述、驗(yàn)證步驟等關(guān)鍵信息；PR門禁編譯失敗、格式檢測(cè)失敗、門禁檢查失敗，DCO失敗、未參考檢視意見修改等導(dǎo)致不能合入。社區(qū)Issue和PR處理流程也存在一些改進(jìn)點(diǎn)，可以提升Issue和PR處理效率，比如當(dāng)前缺少Issue責(zé)任人精準(zhǔn)分配；缺少機(jī)制分配PR檢視人，PR處理階段不清晰；缺少處理超期時(shí)主動(dòng)提醒功能等；對(duì)超期的Issue和PR不能自動(dòng)處理等。
OpenHarmony社區(qū)為解決上述問題，對(duì)Issue和PR處理流程進(jìn)行了優(yōu)化，主要包含：
- 標(biāo)記狀態(tài)標(biāo)簽明確處理階段責(zé)任人.
通過標(biāo)記狀態(tài)標(biāo)簽識(shí)別處理責(zé)任階段、明確處理人。如果Issue和PR提交不規(guī)范，會(huì)有標(biāo)簽顯示當(dāng)前處理責(zé)任人為提交人；如果提交的PR通過門禁測(cè)試，等待審核檢視，當(dāng)前處理責(zé)任人為committer；如果已分配檢視人員，當(dāng)前處理責(zé)任人就是代碼檢視人員，等等。 - 主動(dòng)提醒責(zé)任人處理待辦事項(xiàng).
CI Bot會(huì)發(fā)郵件每日提醒責(zé)任人處理名下的待辦事項(xiàng)。是否接收郵件可以通過訂閱配置。 - 超期問題自動(dòng)處理.
基于規(guī)則，對(duì)于一些可以自動(dòng)處理的情況進(jìn)行分析，進(jìn)行自動(dòng)化處理。比如，對(duì)于驗(yàn)收中的Issue，如果長期未確認(rèn)，會(huì)自動(dòng)進(jìn)行關(guān)閉；對(duì)于門禁未通過等情況導(dǎo)致不符合合入標(biāo)準(zhǔn)的PR，超過一定時(shí)間，會(huì)自動(dòng)關(guān)閉。
OpenHarmony社區(qū)通過這些流程優(yōu)化來提升Issue和PR處理效率，下文會(huì)詳細(xì)介紹流程的優(yōu)化點(diǎn)和具體使用方法。
2、新流程介紹
以PR流程為例介紹新流程，如圖1所示。我們按狀態(tài)標(biāo)簽來分別講解，也可以參考OpenHarmony社區(qū)Pull Request&Issue評(píng)論支持命令清單。
（1）Waiting_On_Author狀態(tài)標(biāo)簽
PR提交人（社區(qū)貢獻(xiàn)者）創(chuàng)建PR后，PR的標(biāo)簽為Waiting_On_Author，表示當(dāng)前的責(zé)任人為PR提交人。CI Bot會(huì)提醒PR提交人及時(shí)處理該P(yáng)R。如果PR提交人長時(shí)期未處理該P(yáng)R，CI Bot會(huì)進(jìn)行自動(dòng)關(guān)閉。
如果PR提交人觸發(fā)門禁構(gòu)建，構(gòu)建失敗后，PR的標(biāo)簽依舊為Waiting_On_Author狀態(tài)。如果檢視人員或committer審核人員提交了檢視意見，PR的標(biāo)簽會(huì)被標(biāo)記為Waiting_On_Author狀態(tài)。
（2）Waiting_For_Review狀態(tài)標(biāo)簽
當(dāng)PR提交人評(píng)論start build（倉庫配置門禁時(shí)使用該命令，如果未配置門禁，請(qǐng)使用code review命令），并且門禁構(gòu)建成功后，PR的狀態(tài)標(biāo)簽替代為Waiting_For_Review狀態(tài)，表示表示當(dāng)前的責(zé)任人為committer審核人員，需要由committer分配檢視人員。CI Bot可以每日郵件定時(shí)提醒待辦事項(xiàng)，催促分配檢視人員。
（3）Reviewing狀態(tài)標(biāo)簽
Committer可以通過assign [@gitee_id1 @gitee_id2...]分配檢視人員，可以通過空格分割來指定多個(gè)檢視人員；如果命令中不指定gitee_id，committer安排自己為檢視人員。分配檢視人員后，PR的狀態(tài)標(biāo)簽替代為Reviewing狀態(tài)，表示當(dāng)前的責(zé)任人為代碼檢視人員。
分配的檢視人員需參與檢視，給出檢視意見，然后評(píng)論命令check comment提醒PR提交人處理；無檢視意見時(shí)，評(píng)論命令lgtm，提醒committer審核處理。
（4） Waiting_For_Merge狀態(tài)標(biāo)簽
當(dāng)所有檢視人員均對(duì)分配的PR沒有檢視意見時(shí)，并在PR評(píng)論區(qū)評(píng)論命令lgtm后，CI Bot會(huì)提醒committer去審核該P(yáng)R。此時(shí)，PR的狀態(tài)標(biāo)簽變換為Waiting_For_Merge狀態(tài)，表示當(dāng)前的責(zé)任人為committer審核人員。
（5）Merged 狀態(tài)標(biāo)簽
對(duì)于Waiting_For_Merge狀態(tài)標(biāo)簽的PR， 當(dāng)committer審核通過后，PR的狀態(tài)標(biāo)簽會(huì)自動(dòng)變換為Merged狀態(tài)，表示該P(yáng)R成功合入。
圖1 PR審核處理流程圖
3、流程處理實(shí)例講解
本節(jié)以Pull Request處理流程來講解，按PR的處理階段分別來講解。
（1）提交修改Pull Request
當(dāng)PR提交人提交一個(gè)PR后，CI Bot會(huì)自動(dòng)評(píng)論，如下所示。根據(jù)提示，如果代碼已經(jīng)開發(fā)完畢，PR提交人在PR評(píng)論區(qū)評(píng)論start build來觸發(fā)門禁。在觸發(fā)門禁前狀態(tài)標(biāo)簽為Waiting_On_Author，當(dāng)前的處理責(zé)任人為PR提交人。
圖2 新PR交互截圖
如果審核檢視人員為PR提交檢視意見后，PR的狀態(tài)標(biāo)簽變?yōu)閃aiting_On_Author，需要PR提交人優(yōu)化修復(fù)提交的代碼。當(dāng)處理完畢，重新推送代碼后，需要重新觸發(fā)門禁。
注意：如果代碼倉沒有配置門禁，提示的內(nèi)容稍有不同，需要評(píng)論的命令是code view。
（2）門禁構(gòu)建
在門禁通過后，PR的狀態(tài)標(biāo)簽會(huì)替代為Waiting_For_Review狀態(tài)，如下圖所示。此后，該P(yáng)R的處理責(zé)任人為代碼倉的Committer。Committer會(huì)負(fù)責(zé)分配檢視人員或者審核該P(yáng)R。
圖3 門禁構(gòu)建成功截圖
（3）代碼檢視
當(dāng)一個(gè)PR處于Waiting_For_Review狀態(tài)時(shí)，Committer可以使用assign命令分配給檢視人員進(jìn)行檢視，如下圖所示。命令assign的具體用法，可以參考上一小節(jié)圖片中的操作提示。當(dāng)分配完畢檢視人員，PR的狀態(tài)標(biāo)簽會(huì)替代為Waiting_For_Review狀態(tài)，當(dāng)前的處理責(zé)任人為分配的檢視人員。
圖4分配檢視人員截圖
如果檢視人員發(fā)現(xiàn)檢視的PR存在問題，提出檢視意見后，需要評(píng)論下check comment通知PR提交人根據(jù)檢視意見進(jìn)行修改。PR的狀態(tài)標(biāo)簽會(huì)替代為Waiting_On_Author狀態(tài)，當(dāng)前的處理責(zé)任人為PR提交人。
圖5提醒處理檢視意見截圖
如果PR不存在問題，檢視人員認(rèn)為可以合入，需要評(píng)論下lgtm即（look good to me）通知Committer審核合入該P(yáng)R。PR的狀態(tài)標(biāo)簽會(huì)替代為Waiting_For_Merge狀態(tài)，當(dāng)前的處理責(zé)任人為Committer。
圖6提醒審核合入截圖
（4）審核合入
當(dāng)代碼倉Committer認(rèn)為PR滿足合入要求，審核通過后，PR會(huì)合入，此時(shí)PR的狀態(tài)標(biāo)簽會(huì)替代為Merged狀態(tài)，PR成功合入。
圖7審核合入截圖
4、CI Bot待辦提醒
通過狀態(tài)標(biāo)簽識(shí)別當(dāng)前處理責(zé)任人后，就可以獲取責(zé)任人的待辦事項(xiàng)。通過記錄打標(biāo)簽的開始時(shí)間，就可以計(jì)算當(dāng)前處理階段停留時(shí)間，從而可以發(fā)郵件提醒及時(shí)處理待辦事項(xiàng)，并能自動(dòng)化處理超期無效的Issue和PR。發(fā)郵件功能可以自行選擇是否訂閱。
（1）每日待辦提醒
如果您在社區(qū)有待辦事項(xiàng)，社區(qū)會(huì)自動(dòng)匯總并自動(dòng)發(fā)郵件給您，提醒您及時(shí)處理。如果不想收到郵件，可以取消訂閱。強(qiáng)烈推薦您保持訂閱，可以及時(shí)收到在社區(qū)的待辦事項(xiàng)。下圖為收到的待辦事項(xiàng)郵件示例。
圖8 待辦事項(xiàng)郵件截圖
（2）自動(dòng)超期處理
對(duì)于PR，審核檢視人員需要及時(shí)響應(yīng)處理；PR提交人也需要及時(shí)響應(yīng)反饋的檢視意見，如果長期未響應(yīng)，不符合合入標(biāo)準(zhǔn)的PR，會(huì)在30天后被自動(dòng)關(guān)閉。這樣做是為了保持一個(gè)干凈的社區(qū)貢獻(xiàn)環(huán)境，也不用擔(dān)心丟失代碼，被關(guān)閉的PR也可以很容易被PR提交人重新打開。對(duì)于Issue，如果社區(qū)審核人員認(rèn)為需要補(bǔ)充信息，非問題，以及需要issue驗(yàn)收確認(rèn)時(shí)，如果issue提交人30天未響應(yīng)，也會(huì)被自動(dòng)關(guān)閉處理。在關(guān)閉之后，會(huì)提醒，請(qǐng)保持關(guān)注Issue和PR的變更信息。如下圖所示：
圖9 自動(dòng)超期處理截圖
5、小結(jié)
本文對(duì)OpenHarmony社區(qū)貢獻(xiàn)流程優(yōu)化點(diǎn)進(jìn)行了介紹，包含新支持的一系列交互命令和狀態(tài)標(biāo)簽，以及CI Bot的每日待辦事項(xiàng)郵件、自動(dòng)超期處理等。
