GitHub擴大PR封存權限：整理佇列時先停止自動留言
Dev
瀏覽 2
triage負責人現在不必找管理員即可封存PR。整理佇列前，先檢查仍準備傳送結果、提醒與進度的機器人。
已確認的範圍
GitHub於2026年10月8日宣布triage及以上角色可封存與取消封存。封存會關閉PR並禁止留言、反應及自動留言。10月9日補充說明：公開檢視會隱藏PR，triage、write、maintain、admin仍可查看。取消封存不會重新開啟PR。
留言前讀取目前狀態
建議對已確認封存的目標結束任務，於內部記錄原因，別反覆重送。核對整合實際提供的狀態與回應；這裡不承諾新增API欄位。封存、權限不足與網路失敗應分別記錄。
整理前保留審查依據
清理垃圾或重複PR不同於封存尚待決定的實作。先記下原因、最後驗證、相關issue與基準PR。外部讀者可能看不到封存內容，必要公開依據應放在合適紀錄中，不能因此公開私人資訊。
triage委派與程式修改權限分開
委派日常整理仍需選擇標準。正在審查或有未解答提問的PR應由人判斷。取消封存後仍關閉，若要恢復開發，應另行確認是否重新開啟。
核對實際角色，並在合適目標測試自動留言的結束處理。留言失敗不能成為建立替代PR的理由。產品行為已確認，營運規則是本文建議；不由討論推測採用規模或效益。
官方來源與討論
一起檢查封存標準與機器人任務結束規則。